Skip to content
←

필사 모드: AIエンジニアになる方法 完全ガイド2026 — LLM・RAG・エージェント・Evals・キャリアロードマップ

日本語
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 2026年、なぜAIエンジニアなのか

この3年間で最も急速に増えた職種名を一つ挙げるなら、間違いなくAIエンジニアです。

2023年にはほとんど存在しなかったこの肩書きが、今ではPreferred NetworksやSB Intuitionsの求人にも、東京のスタートアップにも、シリコンバレーの求人板にも並んでいます。

核心はシンプルです。モデルをゼロから作る人ではなく、すでに存在する強力な基盤モデルの上でプロダクトを作る人。その需要が爆発しました。

参入障壁は低く見えます。API呼び出し数行でデモができるからです。しかし、プロダクション品質のAIプロダクトはまったく別物です。検索品質、ハルシネーション抑制、評価体制、コスト管理、可観測性まで揃って、はじめてサービスになります。

この記事はそのギャップを埋めるロードマップです。役割の定義から必須スキル7つ、評価中心の開発、ツール選定、ポートフォリオ、採用市場、面接対策、転身経路まで、一つずつ見ていきます。

AIエンジニアの定義 — MLエンジニア、データサイエンティストと何が違うか

まず用語の整理から。3つの職種は重なる部分もありますが、重心が異なります。

職種中心となる問い主な成果物代表的なツール
データサイエンティストデータは何を語っているか分析レポート、予測モデルSQL、pandas、統計
MLエンジニアモデルをどう学習・デプロイするか学習パイプライン、モデルサービングPyTorch、Kubeflow、MLflow
AIエンジニア基盤モデルでどんなプロダクトを作るかRAGシステム、エージェント、AI機能LLM API、ベクトルDB、評価ツール

この区分を広めたのが、2023年6月のswyxのエッセイ「The Rise of the AI Engineer」です。要旨はこうです。モデルの学習は少数の研究組織に集中し、大多数のエンジニアはAPIの反対側で、モデルの能力をプロダクトに変える仕事をするようになる。

その予測は的中しました。AIエンジニアはモデルの重みをいじる代わりに、プロンプト、検索、オーケストレーション、評価というレバーを引きます。

ただし境界は次第に曖昧になっています。2026年のAIエンジニア求人には、LoRAファインチューニングやvLLMサービングの経験が歓迎要件としてよく登場します。APIしか使えない人と、必要ならモデルレイヤーまで降りられる人の報酬差は開き続けています。

2023年から2026年へ — 職務はこう進化した

この職種の3年間は、大きく4つの段階にまとめられます。

2023年 — ラッパーの時代。 ChatGPTの衝撃の後、誰もがデモを作りました。プロンプト一つで始まるいわゆるGPTラッパーが溢れ、差別化はほとんどありませんでした。

2024年 — RAGの標準化。 社内データとモデルをつなぐ検索拡張生成が事実上の標準アーキテクチャになりました。チャンキング、埋め込み、リランキングといった用語が実務の語彙として定着しました。

2025年 — エージェントとMCP。 ツールコーリングが安定し、モデルがループの中でツールを選んで使うエージェントが実務に入ってきました。Model Context Protocolがツール接続の共通規格として広がりました。

2026年 — 評価と信頼性の時代。 デモは簡単でプロダクションは難しい、という認識が業界全体に定着しました。求人票にevalsの経験が明記されるようになり、コスト最適化と可観測性が中核スキルに昇格しました。

この順序はそのまま学習ロードマップでもあります。API活用、RAG、エージェント、そして評価。以下で一つずつ扱います。

スキル1 — 言語: PythonとTypeScript

AIエンジニアの二大言語はPythonとTypeScriptです。

Pythonはデフォルトです。 モデル、データ、評価のエコシステムがすべてPythonにあります。FastAPIでバックエンドを立て、pydanticでスキーマを検証し、asyncioで並行呼び出しを処理できるレベルまでは必須です。型ヒントを習慣にすると、LLM出力のパースまわりの事故が大きく減ります。

TypeScriptはプロダクト側の半分です。 AI機能の多くは最終的にWeb UIで届けられます。ストリーミング応答を画面に流し、Vercel AI SDKのようなツールでチャットUIを素早く組み立てる能力は、フルスタック型AIエンジニアの強みになります。

推奨戦略は、一方を深く、もう一方を読んで直せるレベルに保つことです。バックエンド出身ならPythonを軸に、フロントエンド出身ならTypeScriptを軸にすればよいのです。

言語そのものより重要なのは、ソフトウェアエンジニアリングの基本です。バージョン管理、テスト、CI、ロギング。LLMがコードを書いてくれる時代ほど、何が良いコードかを判断する目が報酬を分けます。

スキル2 — LLM APIを正しく使いこなす

LLM APIの活用は単なる呼び出しではなく、信頼性エンジニアリングです。実務で必ず扱う要素は次のとおりです。

  • 構造化出力 — 自由テキストではなくスキーマが保証されたJSONを受け取り、パース失敗をなくします。
  • ストリーミング — 最初のトークンまでの時間を縮めて体感遅延を下げます。長い出力ではほぼ必須です。
  • ツールコーリング — モデルが関数を呼べるようにスキーマを設計します。エージェントの基礎部品です。
  • エラー処理 — レートリミット429、過負荷529への指数バックオフ再試行。SDK標準のリトライ挙動を理解しておきます。
  • プロンプトキャッシング — 繰り返される長いコンテキストをキャッシュして入力コストを大幅に削減します。

構造化出力の最小例です。Pydanticモデルをスキーマとして渡すと、検証済みオブジェクトが返ってきます。

# pip install anthropic pydantic
import anthropic
from pydantic import BaseModel

class Ticket(BaseModel):
    category: str   # "billing" | "bug" | "feature_request"
    urgency: int    # 1 (low) - 5 (critical)
    summary: str

client = anthropic.Anthropic()

def classify(text: str) -> Ticket:
    response = client.messages.parse(
        model="claude-opus-4-8",
        max_tokens=1024,
        system="You classify customer support tickets.",
        messages=[{"role": "user", "content": text}],
        output_format=Ticket,
    )
    return response.parsed_output

print(classify("I was charged twice this month. Please fix this ASAP."))

この程度の堅牢さが、あらゆるパイプラインの土台になります。自由テキストを正規表現で削っているコードが見えたら、そのシステムはまだプロトタイプです。

スキル3 — プロンプトエンジニアリングを勘ではなく工学に

プロンプトエンジニアリングはかつて笑い話でしたが、2026年には明確な実務技術として整理されました。原則は4つです。

第一に、システムプロンプトは仕様書である。 役割、入力形式、出力形式、禁止事項、例外処理をドキュメントのように書きます。曖昧な指示は曖昧な出力を生みます。

第二に、例示は形容詞より強い。 few-shotの例を2、3個入れるほうが、修飾語を10個並べるより出力品質を安定させます。形式を揃えたいときは特にそうです。

第三に、推論の余地を与える。 複雑な判断は結論から言わせず、根拠を先に整理させます。最新モデルの推論モードを使う場合でも、問題を明確に定義するほうが品質を左右します。

第四に、プロンプトはコードである。 リポジトリでバージョン管理し、変更はレビューを通し、デプロイ前に評価セットで回帰チェックを回します。チャット画面で場当たり的に直すチームと、評価で検証するチームの差は時間とともに開きます。

アンチパターンも知っておくべきです。大文字の強調を乱発するプロンプトは、最新モデルではかえって過剰反応を引き起こします。新しいモデルほど指示を文字どおりに守るため、強い命令口調を削り、条件を正確に書くほうが有効です。

スキル4 — RAG設計: チャンキング、埋め込み、ハイブリッド検索、リランキング

RAGは、モデルが知らない知識を検索で補強するアーキテクチャです。知識注入が必要な場面では、ファインチューニングよりRAGが先です。パイプラインは大きく4段階です。

1) チャンキング。 ドキュメントを検索単位に切ります。固定長よりも、段落や見出しといった構造の境界を尊重する再帰分割が基本です。1チャンク300–800文字、オーバーラップ10–15パーセントから始めて評価で調整します。表とコードは別扱いが必要です。

2) 埋め込み。 テキストをベクトルに変換します。日本語や韓国語が混ざるサービスなら、多言語性能が実証されたモデルを選ぶべきです。次元数はストレージコストに直結するので、大きいモデルが常に正解とは限りません。

3) ハイブリッド検索。 ベクトル検索は意味を捉えますが、固有名詞、エラーコード、製品名のような完全一致に弱い。BM25キーワード検索と組み合わせ、RRFで順位を融合するのが標準です。

4) リランキング。 広めに取った候補をクロスエンコーダで並べ直します。コストはかかりますが、上位精度を最も確実に上げる段階です。

4段階を圧縮したパイプラインの例です。

# pip install sentence-transformers rank-bm25 numpy
import numpy as np
from rank_bm25 import BM25Okapi
from sentence_transformers import CrossEncoder, SentenceTransformer

embedder = SentenceTransformer("BAAI/bge-m3")        # multilingual dense embeddings
reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")   # cross-encoder reranker

def chunk(text: str, size: int = 500, overlap: int = 80) -> list[str]:
    chunks, start = [], 0
    while start < len(text):
        chunks.append(text[start : start + size])
        start += size - overlap
    return chunks

docs = chunk(open("handbook.txt").read())
doc_vecs = embedder.encode(docs, normalize_embeddings=True)
bm25 = BM25Okapi([d.split() for d in docs])

def retrieve(query: str, k: int = 5) -> list[str]:
    # 1) dense: cosine similarity on normalized vectors
    q = embedder.encode([query], normalize_embeddings=True)[0]
    dense_rank = np.argsort(-(doc_vecs @ q))
    # 2) sparse: BM25 keyword scores
    sparse_rank = np.argsort(-np.array(bm25.get_scores(query.split())))
    # 3) hybrid: reciprocal rank fusion (RRF)
    rrf = np.zeros(len(docs))
    for rank, idx in enumerate(dense_rank):
        rrf[idx] += 1.0 / (60 + rank)
    for rank, idx in enumerate(sparse_rank):
        rrf[idx] += 1.0 / (60 + rank)
    candidates = np.argsort(-rrf)[: k * 4]           # wide candidate pool
    # 4) rerank candidates with the cross-encoder, keep top-k
    scores = reranker.predict([(query, docs[i]) for i in candidates])
    return [docs[candidates[i]] for i in np.argsort(-scores)[:k]]

この上に、クエリ書き換え、親ドキュメント検索、メタデータフィルタといった技法が載ります。しかし、どんな高度な技法も、次のセクションの評価なしには効果を判断できません。

RAGは評価が半分 — recall@kとMRR

RAG改善の出発点は常に計測です。検索と生成を分けて評価します。

検索の評価。 質問ごとに正解ドキュメントを付けたゴールデンセットを作り、recall@kとMRRを見ます。recall@5が低いなら、リランカーやプロンプトをいじる前に、チャンキングと検索を直すべきです。正解ドキュメントが候補にすら入っていなければ、後段の努力はすべて無駄になるからです。

生成の評価。 検索が正しくても答えが間違うことはあります。回答が検索結果に根拠を持つか(忠実性)、質問に実際に答えているか(関連性)をLLM判定で測ります。Ragasのようなライブラリがこれらの指標を提供しています。

検索評価はライブラリなしでも数行で書けます。

def recall_at_k(retrieved: list[str], relevant: set[str], k: int = 5) -> float:
    return len(set(retrieved[:k]) & relevant) / len(relevant)

def mrr(retrieved: list[str], relevant: set[str]) -> float:
    for rank, doc_id in enumerate(retrieved, start=1):
        if doc_id in relevant:
            return 1.0 / rank
    return 0.0

golden_set = [
    {"query": "How many vacation days do new hires get?",
     "relevant_ids": {"policy-041", "policy-007"}},
    # ... 50-200 more cases, curated from real user queries
]

scores = []
for case in golden_set:
    retrieved_ids = [doc_id for doc_id, _ in retrieve_with_ids(case["query"], k=10)]
    scores.append({
        "recall@5": recall_at_k(retrieved_ids, case["relevant_ids"], k=5),
        "mrr": mrr(retrieved_ids, case["relevant_ids"]),
    })

avg = {metric: sum(s[metric] for s in scores) / len(scores) for metric in scores[0]}
print(avg)  # e.g. recall@5 = 0.87, mrr = 0.79

ゴールデンセットは50–200件あれば方向性は掴めます。実際のユーザーの質問から作ることが肝心です。作り話の質問は実際の分布と一致しません。

スキル5 — エージェント構築: ツールコーリングループからMCPまで

エージェントとは、LLMがループの中でツールを選び、結果を観察し、次の行動を決めるシステムです。骨格は驚くほど小さい。

import anthropic

client = anthropic.Anthropic()

tools = [{
    "name": "search_orders",
    "description": "Search the order database by customer email.",
    "input_schema": {
        "type": "object",
        "properties": {"email": {"type": "string"}},
        "required": ["email"],
    },
}]

def run_agent(user_input: str) -> str:
    messages = [{"role": "user", "content": user_input}]
    while True:
        response = client.messages.create(
            model="claude-opus-4-8",
            max_tokens=4096,
            tools=tools,
            messages=messages,
        )
        if response.stop_reason != "tool_use":
            return next(b.text for b in response.content if b.type == "text")

        messages.append({"role": "assistant", "content": response.content})
        results = []
        for block in response.content:
            if block.type == "tool_use":
                output = execute_tool(block.name, block.input)  # your implementation
                results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": output,
                })
        messages.append({"role": "user", "content": results})

実務の勘所はループの外にあります。

  • ワークフロー vs エージェント。 手順が事前に決まる仕事は、コードでオーケストレーションするワークフローのほうが優れています。経路を事前に決められないオープンな問題にだけエージェントを使います。シンプルな設計が勝つことがほとんどです。
  • ツール設計が半分。 良い説明、厳密なスキーマ、いつ使うべきかの指針。ツールが多いほどモデルは迷うので、数は最小限に保ちます。
  • ガードレール。 取り返しのつかない操作は人間の承認を挟み、最大反復回数と予算上限を設定します。
  • MCP。 Model Context Protocolはツール接続のUSB-Cのような規格です。一度作ったMCPサーバーは複数のクライアントで再利用できます。2026年時点で、エージェントエコシステムの共通言語になりました。

スキル6 — ファインチューニング基礎: LoRA、QLoRA、DPO

ファインチューニングの最初の問いは、方法ではなく要否です。

やるべきとき — 出力のスタイルと形式を固定したいとき、ドメイン語彙が特殊なとき、大きなモデルの挙動を小さなモデルに蒸留してコストと遅延を下げたいとき。

やるべきでないとき — 知識を注入したいとき。新しい情報はRAGの仕事です。重みに知識を焼き込むと、更新のたびに再学習が必要になり、ハルシネーションもうまく抑えられません。

押さえるべき技法は3つです。

  • LoRA — 元の重みを凍結し、低ランクのアダプタ行列だけを学習します。学習パラメータが桁違いに減り、単一GPUでも学習可能になります。
  • QLoRA — ベースモデルを4ビットに量子化したままLoRAを学習します。コンシューマGPUで7–8Bモデルをチューニングできるようにした技法です。
  • DPO — 良い回答と悪い回答のペアで選好を直接最適化します。報酬モデルと強化学習が必要なRLHFよりはるかに単純で、アラインメント学習の実務デフォルトになりました。

Hugging FaceのTRLとPEFTを組み合わせた典型的な設定です。

# pip install torch transformers peft trl bitsandbytes datasets
import torch
from datasets import load_dataset
from peft import LoraConfig
from transformers import BitsAndBytesConfig
from trl import SFTConfig, SFTTrainer

lora_config = LoraConfig(
    r=16,               # rank: 8-64 is the usual range
    lora_alpha=32,      # commonly set to 2x rank
    lora_dropout=0.05,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    task_type="CAUSAL_LM",
)

bnb_config = BitsAndBytesConfig(   # QLoRA: 4-bit quantized base weights
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
)

trainer = SFTTrainer(
    model="Qwen/Qwen3-8B",
    train_dataset=load_dataset("json", data_files="train.jsonl", split="train"),
    peft_config=lora_config,
    args=SFTConfig(
        output_dir="checkpoints",
        per_device_train_batch_size=2,
        gradient_accumulation_steps=8,
        learning_rate=2e-4,
        num_train_epochs=2,
        model_init_kwargs={"quantization_config": bnb_config},
    ),
)
trainer.train()

絶対に守るべきことが一つ。チューニング前後を同じ評価セットで比較し、汎用能力が崩れていないかも確認することです。評価なしのファインチューニングはギャンブルです。

スキル7 — サービング: vLLMとTGI

オープンモデルを自前で運用すべき瞬間はいずれ来ます。データを外に出せないとき、トークン量が多くてAPI料金が逆転するとき、ファインチューニングしたモデルをデプロイするときです。

まず主要指標を整理します。

  • TTFT — 最初のトークンまでの時間。体感の応答性を左右します。
  • TPOT — トークンあたりの生成時間。出力速度です。
  • スループット — 秒あたりの処理トークン数。GPUコスト効率を決めます。

vLLMが事実上の標準です。PagedAttentionでKVキャッシュメモリをページ単位で管理して無駄をなくし、連続バッチングでGPUを遊ばせません。OpenAI互換APIを提供するのでクライアントの差し替えも簡単です。TGIはHugging Faceエコシステムとの統合が強みで、SGLangは構造化出力とプレフィックスキャッシュ活用に強い。ローカル開発とプロトタイプにはOllamaが手軽です。

pip install vllm

# OpenAI-compatible server with continuous batching + PagedAttention
vllm serve Qwen/Qwen3-8B \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching

# smoke test
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Qwen/Qwen3-8B", "messages": [{"role": "user", "content": "Hello"}]}'

量子化(AWQ、GPTQ、FP8)でメモリとスループットを調整する感覚、そして自分でベンチマークを回して遅延とスループットの曲線を描いた経験まで持てば、サービング力としては十分な出発点です。

Evals中心の開発 — LLM-as-Judgeとゴールデンデータセット

2026年のAIエンジニアを分けるスキルを一つ挙げるなら、評価です。優れたチームに共通するのは、華やかなアーキテクチャではなく、緻密な評価ループです。

機能する評価体制は3層で構成されます。

第1層 — プログラムによる検査。 コードで判定できるものすべて。JSONのパース成功、必須フィールドの存在、禁止表現、長さ制限。安くて速いので全件に適用します。

第2層 — LLM-as-Judge。 正確性、トーン、有用性のようにコードで測れない品質を、モデルがルーブリック基準で採点します。注意すべきバイアスがあります。ペア比較で先に出た回答を好む位置バイアス、自分の出力を好む自己選好バイアス。順序を入れ替えて2回聞き、人間のラベルとの一致率で判定者自体をキャリブレーションします。

第3層 — 人間のレビュー。 判定者の基準を作り検証する最終審級です。エラー分析、つまり失敗事例を自分で読んで分類する作業は、自動化がどれだけ進んでも消えません。

この3層をCIに組み込むと回帰ゲートになります。プロンプトやモデルを変えるたびに、ゴールデンセットのスコアが基準線を下回ればリリースを止めるのです。

import json
import anthropic

client = anthropic.Anthropic()

JUDGE_PROMPT = """You are grading an AI assistant's answer.

Question: {question}
Reference answer: {reference}
Assistant answer: {answer}

Score 1-5 for factual accuracy against the reference.
Reply with JSON only: {{"score": <int>, "reason": "<one sentence>"}}"""

def judge(question: str, reference: str, answer: str) -> dict:
    response = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=256,
        messages=[{"role": "user", "content": JUDGE_PROMPT.format(
            question=question, reference=reference, answer=answer)}],
    )
    text = next(b.text for b in response.content if b.type == "text")
    return json.loads(text)

def test_no_regression():
    golden = [json.loads(line) for line in open("golden.jsonl")]
    scores = []
    for case in golden:
        answer = my_rag_app(case["question"])  # system under test
        scores.append(judge(case["question"], case["reference"], answer)["score"])
    mean_score = sum(scores) / len(scores)
    print(f"mean judge score: {mean_score:.2f}")
    assert mean_score >= 4.2, "quality regression: below release threshold"

golden.jsonlは実際のユーザーの質問から出発して育て続けます。プロダクションで失敗事例が見つかるたびにゴールデンセットへ追加する習慣が、システムを複利で改善します。

フレームワークの地形図 — LangChain、LlamaIndex、DSPy、PydanticAI

フレームワーク選定は不毛な論争になりがちですが、2026年時点の実務地形は比較的明瞭です。

フレームワーク強みこんなときに
LangChain / LangGraph膨大な統合、グラフベースの状態オーケストレーション複雑なマルチステップワークフロー、チェックポイントが必要なエージェント
LlamaIndexドキュメント取り込みとインデックスの抽象化が成熟データソースが多いRAG中心のサービス
DSPyプロンプトを宣言し、オプティマイザでコンパイル評価セットがあり、プロンプト調整を自動化したいとき
PydanticAI型安全、薄い抽象化、テストしやすい軽く堅牢なプロダクションエージェントを作りたいとき

そして5番目の選択肢が最も重要です。フレームワークなしでSDKを直接使う。 学習段階ではこちらを強く勧めます。ツールコーリングループを自分で書いた人は、フレームワークが何を隠しているかを知っており、問題が起きたときにどこを掘ればいいかが分かります。

実務上の助言は3つ。抽象化の薄いツールを選ぶこと。オーケストレーションとLLM呼び出しを分離して差し替え可能に保つこと。フレームワークの流行より、自分の評価セットのスコアを信じることです。

ベクトルDBの選び方

ベクトルDB選定も過大評価されがちな悩みです。ドキュメント数百万件以下なら、ほとんどの選択肢が十分に速い。基準は性能よりも運用です。

選択肢性格こんなときに
pgvectorPostgres拡張すでにPostgresを使うチームのデフォルト。トランザクションやジョインと同居
Qdrantオープンソース専用エンジンメタデータフィルタが重く、性能要件が高いとき
Weaviateハイブリッド内蔵キーワード+ベクトルの融合検索を素早く立てたいとき
Milvus分散アーキテクチャ数億ベクトル以上の大規模
Pineconeフルマネージド運用要員なしでスケールが必要なとき
Chroma / LanceDB軽量、組み込み型プロトタイプ、ローカル開発、小規模アプリ

チェックリストは5項目です。規模(現実的な上限)、フィルタリング(権限、日付、カテゴリ条件の複雑さ)、ハイブリッド対応、運用負担(マネージドか否か)、コスト構造。

一つだけ罠に注意してください。権限フィルタリングの後付けは痛い。社内ドキュメントのRAGなら、ドキュメント単位のアクセス権メタデータを最初からスキーマに入れるべきです。

コスト最適化 — キャッシング、モデルルーティング、バッチ

AI機能が成功するほど請求書が問題になります。2026年のAIエンジニア面接でコストの質問が外れない理由です。効果順に整理します。

  1. プロンプトキャッシング。 システムプロンプト、ドキュメント、few-shotのような繰り返される接頭部をキャッシュすると、キャッシュ部分の入力コストが約10分の1に下がります。安定した内容を前に、毎回変わる内容を後ろに置くプロンプト構造設計が前提条件です。
  2. モデルルーティング。 すべてのリクエストに最上位モデルを使う理由はありません。安価なモデルが難易度を分類し、難しいものだけ上位モデルへ送ります。
  3. バッチAPI。 リアルタイム性が不要な大量処理はバッチエンドポイントに送ると通常半額です。
  4. プロンプトダイエット。 出力トークンは入力より数倍高い。冗長な出力を削る指示一つが、意外なほど大きな節約になります。
  5. セルフホスティングの損益分岐。 トークン量が一定水準を超えると、オープンモデルの自前サービングが安くなります。GPU費用と運用人件費まで入れて計算してこそ、正直な比較です。

キャッシングとルーティングを一度に見せる例です。

import anthropic

client = anthropic.Anthropic()

ROUTER_SYSTEM = "Classify the request. Reply with exactly one word: simple or complex."

def route_model(user_input: str) -> str:
    # step 1: a small, cheap model decides the tier
    verdict = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=8,
        system=ROUTER_SYSTEM,
        messages=[{"role": "user", "content": user_input}],
    )
    label = next(b.text for b in verdict.content if b.type == "text").strip().lower()
    return "claude-haiku-4-5" if label == "simple" else "claude-opus-4-8"

def answer(user_input: str, knowledge_base: str) -> str:
    response = client.messages.create(
        model=route_model(user_input),
        max_tokens=2048,
        system=[{
            "type": "text",
            "text": knowledge_base,                  # large, stable context
            "cache_control": {"type": "ephemeral"},  # cached reads cost ~10%
        }],
        messages=[{"role": "user", "content": user_input}],
    )
    return next(b.text for b in response.content if b.type == "text")

コスト最適化の前提も結局は評価です。ルーティングで品質が落ちていないことをゴールデンセットで証明できてこそ、安心して削減できます。

可観測性 — LangSmith、Langfuse、Braintrust

LLMシステムは従来のAPMだけではデバッグできません。応答がおかしいとき、どの検索結果が入ったか、プロンプトが正確にどうレンダリングされたか、何トークン使ったかを追跡できる必要があります。

基本概念はトレーシングです。一つのリクエストをトレースとして、その中の検索、リランキング、LLM呼び出し、ツール実行をスパンとして記録します。そこにトークン使用量、コスト、遅延、ユーザーフィードバックを紐付けます。

ツール性格備考
LangSmithLangChainチームのマネージドサービスLangChain利用時の統合が最もスムーズ
Langfuseオープンソース、セルフホスト可データ主権重視チームのデフォルト。プロンプト管理も内蔵
Braintrust評価中心プラットフォーム評価実験とログを一箇所で管理

OpenTelemetryのGenAIセマンティック規約が定着しつつあり、標準計装で収集してバックエンドを差し替える構成も一般的になりました。

実務のコツを3つ。初日から入れること、後から入れる可観測性はないのと同じです。プロダクションログから失敗事例を選んでゴールデンセットに昇格させるパイプラインを作ること。そしてユーザーフィードバックボタンをトレースにつなぐこと、これが最も安いラベリングパイプラインになります。

ポートフォリオプロジェクト5選

採用担当者が見たいのはチュートリアルの複製ではなく、判断の痕跡です。実際に作れて差別化できる5つを挙げます。

1) ドメイン特化RAGチャットボット。 自分が深く知るドメインのドキュメントで作ります。ハイブリッド検索、リランキング、出典引用まで入れ、何よりrecall@5と忠実性の数値をREADMEに書きます。デプロイまでやって完成です。

2) エージェント自動化。 GitHubのissueトリアージ、週次レポート作成のように、自分が実際に繰り返している仕事を自動化します。ツールコーリング、失敗リカバリ、人間の承認ゲートを備え、成功率を測定します。

3) 評価ハーネス。 公開タスクを一つ選び、ゴールデンセット、プログラム検査、LLM判定、CI回帰ゲートを備えた評価システムを作ります。判定者と人間ラベルの一致率まで報告すれば、上位数パーセントのポートフォリオです。

4) ファインチューニングプロジェクト。 小さなオープンモデルをQLoRAで特定タスク(構造化抽出、ドメイン要約)にチューニングします。ベースライン比の前後評価、学習コスト、vLLMデプロイまで記録します。

5) MCPサーバー。 よく知っているAPIやツールをMCPサーバーとして包んで公開します。エージェントエコシステムの理解を証明する、最も時宜を得た方法です。

共通原則は一つ。5つを浅くやらず、2、3個を深くやること。各リポジトリのREADMEに指標、アーキテクチャ上の決定とトレードオフ、失敗から学んだことを書いた瞬間、プロジェクトが履歴書になります。

採用市場2026 — 韓国

韓国市場は大きく3層に分かれます。

モデルを作る組織。 ネイバー(HyperCLOVA X)、LG AI研究院(EXAONE)、SKT(A.X)、カカオ(Kanana)、そしてSolarシリーズのUpstage。この層のリサーチ職は論文実績を求めることが多いですが、同じ組織内でモデルをサービスに変えるAIエンジニア職も増えています。

AIをプロダクトに載せる企業。 Toss、Coupang、Daangn、配達の民族のようなサービス企業。検索、推薦、カスタマーサポート、社内生産性ツールにLLMを組み込むポジションが継続的に開いています。採用ボリュームではこの層が最大です。

AIネイティブスタートアップ。 WrtnやReturnZeroをはじめ、法務、医療、教育、コマースといった特定ドメインにAIを売る企業群。手が速くフルスタックに近い人材を好みます。

年収は公開求人と年収情報サイトに基づく大まかな範囲で、ジュニアが5,000万–8,000万ウォン、経験3–7年が8,000万–1億5,000万ウォン、シニアとリードは1億5,000万ウォン以上に株式が乗る構造が一般的です。大手AI組織と上位スタートアップはこの範囲を上回ることもあります。

韓国市場の特徴を一つ。コーディングテスト文化が依然として強く、LLMスキルとは別にアルゴリズム対策が必要です。そして社内ドキュメントRAGやサポート自動化のような、実務課題に直結したプロジェクト経験が面接で最もよく通じます。

採用市場2026 — 日本とグローバル

日本。 国産モデルのエコシステムがはっきり存在します。Preferred Networks(PLaMo)、ソフトバンク傘下のSB Intuitions(Sarashina)、そして進化的モデルマージで注目を集めた東京のSakana AIが代表的なモデル開発組織です。ELYZA、rinna、Stockmarkが続き、CyberAgent、LINEヤフー、メルカリのようなサービス企業が応用ポジションを出しています。年収はおおよそ600万–1,200万円が一般的なレンジで、外資系やSakana AIのようにグローバル基準の報酬体系を持つ組織はそれ以上を提示します。日本語ができる人にとっては、相対的に競争の少ないニッチでもあります。

グローバル。 米国ビッグテックとAIラボのシニア総報酬は公開データ基準でUSD 300K–500K以上に達し、一般的なAIエンジニア職はUSD 150K–300Kのレンジが多い。levels.fyiのようなサイトで最新値を確認するのが正確です。リモート職はパンデミック直後より減りましたが、欧州とアジアを対象にしたリモート採用は今も存在します。

グローバル応募で決定的なのは、英語の証拠物です。英語のREADME、技術ブログ、オープンソース貢献がそのまま通貨になります。そしてどの市場でも、最も希少なのは同じ組み合わせです。プロダクションソフトウェアの経験と、LLMシステムの経験。

面接対策 — システムデザイン、コーディング、ML基礎

AIエンジニアの面接は、おおよそ4種類のラウンドで構成されます。

システムデザイン。 最も頻出の問題はこれです。「社内ドキュメント100万件に対するQ&Aシステムを設計せよ」。良い回答の骨格は次の順序です。

  1. 要件の明確化 — ユーザー数、遅延目標、ドキュメント更新頻度、アクセス権限の有無
  2. 取り込みパイプライン — パース、チャンキング戦略、埋め込み、インデックス更新
  3. 検索 — ハイブリッド、権限フィルタ、リランキング
  4. 生成 — プロンプト構成、出典引用、ハルシネーション抑制
  5. 評価 — ゴールデンセット、recall@k、忠実性、回帰ゲート
  6. 運用 — コスト見積もり、キャッシング、可観測性、障害モード

権限フィルタリングと評価を自分から口にする候補者は少なく、だからこそ際立ちます。

コーディング。 LeetCodeミディアム級のアルゴリズムに加え、実務型の問題が増えました。ストリーミング応答のパース、リトライロジックの実装、小さな検索パイプラインの組み立てといったものです。

ML基礎。 トランスフォーマーとアテンションの全体像、トークナイザ、temperatureとサンプリング、埋め込みとコサイン類似度、LoRAがなぜパラメータ効率的か、ハルシネーションの原因と緩和策。数式の導出までは不要でも、概念の因果を説明できる必要があります。

行動面接。 ポートフォリオの深掘りに備えて、各プロジェクトの決定とトレードオフ、失敗と学びを3分で話す練習をしておきましょう。

学習リソース — 講座、書籍、ニュースレター

全部見る必要はありません。各層から一つずつ選べば十分です。

基礎理解。 Andrej KarpathyのNeural Networks: Zero to Hero動画シリーズは、トランスフォーマーをコードで理解する最良の近道です。Hugging Faceの無料コース(LLM、エージェント)も堅実です。

実務スキル。 DeepLearning.AIの短期講座がRAG、エージェント、評価をテーマ別にカバーしています。評価については、Hamel HusainとShreya ShankarのAI Evals講座が実務者の間で標準のように通用しています。

書籍。 Chip HuyenのAI Engineering(2025)がこの職種の教科書に最も近い位置にあります。Sebastian RaschkaのBuild a Large Language Model from Scratchは内部原理を、Jay AlammarとMaarten GrootendorstのHands-On Large Language Modelsは応用全般を扱います。

流れを追う。 Latent Space(swyxのポッドキャストとニュースレター)、Simon Willisonのブログ、Interconnects、Sebastian RaschkaのAhead of AIあたりを購読すれば、ノイズに対するシグナルの比率が良好です。

コミュニティ。 AI Engineer World's Fairの発表動画は実務事例の宝庫です。スライドを流し見るだけでも、業界の現在の関心事が見えてきます。

キャリア転身の経路 — バックエンドから、データサイエンスから

この職種の良い知らせは、完全な未経験者より隣接職種からの転身者に有利だという点です。

バックエンドエンジニアから。 最も多く、最も速い経路です。API設計、データベース、デプロイ、信頼性の感覚がそのまま資産になります。補うべきはモデル感覚です。LLM API深掘り、RAG、評価に3か月ほど集中し、今いる会社でAI機能を一つ自ら引き受けるのが最良の転身戦略です。社内転身は履歴書転身の10倍簡単です。

データサイエンティストから。 実験設計と評価のマインドセットという最大の武器をすでに持っています。この記事の評価中心開発のセクションは、あなたには自然に読めるはずです。補うべきはプロダクションエンジニアリングです。ノートブックからサービスへ。APIサーバー、コンテナ、CI、可観測性を備えたプロジェクトを作り、デプロイ経験を証明しましょう。

フロントエンドから。 AIプロダクトエンジニアという有効な経路があります。ストリーミングUI、チャットインターフェース、楽観的更新のようなAI特有のUXをうまく作れる人は希少です。TypeScriptベースのAI SDKから始めてバックエンド側へ広げればよいのです。

MLOpsから。 LLMOpsへの自然な拡張です。モデルサービング、GPUインフラ、パイプラインの経験の上に、評価とプロンプト管理を載せれば完成します。

共通の助言を一つ。転身の証拠は修了証ではなく、デプロイされたプロジェクトとその指標です。

おわりに — 6か月ロードマップ

ここまでの内容を実行可能な順序に圧縮します。

  • 1か月目 — Pythonの整備とLLM APIの深掘り。構造化出力、ストリーミング、ツールコーリング、エラー処理を手に馴染ませ、小さなCLIツールを作ります。
  • 2か月目 — RAG。チャンキングからリランキングまで自分で実装し、ゴールデンセット50件でrecall@5を測りながら改善ループを回します。ポートフォリオ1号完成。
  • 3か月目 — エージェント。ツールコーリングループをフレームワークなしで書き、実際の繰り返し業務を一つ自動化します。MCPサーバーも一つ作って公開します。
  • 4か月目 — 評価の深化。LLM-as-Judgeハーネスを作り、CIに回帰ゲートを仕込みます。既存プロジェクト2つに評価レポートを追加します。
  • 5か月目 — ファインチューニングとサービング。QLoRAで小型モデルを一つチューニングし、vLLMでサービングして前後の指標を記録します。
  • 6か月目 — 仕上げと応募。READMEの整理、技術ブログ2–3本、面接準備(システムデザインの模擬練習)、応募開始。

最後にこれだけ覚えてください。2026年のAIエンジニアを差別化するのは、最新モデルのニュースに詳しいことではなく、測定して改善するループを作れることです。モデルは変わり続けます。評価の上に築いたシステムと、それを作った経験は変わりません。

References

현재 단락 (1/365)

この3年間で最も急速に増えた職種名を一つ挙げるなら、間違いなくAIエンジニアです。

작성 글자: 0자원문 글자: 21,867자작성 단락: 0/365