LLM、AIエージェントの
仕組みを理解する

10のパートで、LLM、AIエージェントを理解する

6つの質問で、境界線を引く

Hallucination はバグではなく性質

LLM は「次にもっともらしいトークン」を確率で埋めていく機械。「知らない」と返す機構を持っていない ―― なので堂々と嘘をつく。検索エンジンや DB との一番大きな違い。

LLMに、感情はあるのか?

現状の整理: 「感情表現」はできる、「感情体験」がある証拠はない、「感情とは何か」自体は未解決。

APIを叩くと、何が起きるのか

{
  "choices": [
    {
      "finish_reason": "stop",
      "index": 0,
      "message": {
        "content": "富士山の高さは、**3,776メートル**です。",
        "role": "assistant"
      }
    }
  ],
  "created": 1774969200,
  "id": "zdTuaejONoCnvr0P6L_cyQk",
  "model": "gemini-2.5-flash",
  "object": "chat.completion",
  "usage": {
    "completion_tokens": 23,
    "prompt_tokens": 17,
    "total_tokens": 40
  }
}

※ デモではAPIトークン(課金設定)が無くても手軽に試せるよう、無料枠で動く gemini-2.5-flash を採用(OpenAI互換APIで叩きやすい)。トークンを設定して最新モデルを使う場合は gemini-3.1-flash-preview などに差し替える。

最小リクエストは、たった2つの要素

{
  "model": "gemini-3.1-flash-preview",
  "messages": [
    { "role": "system", "content": "あなたは親切な日本語アシスタントです。" },
    { "role": "user",   "content": "富士山の高さは?" }
  ]
}

model — どのモデルに解かせるか
messages — 会話履歴。配列の順序が会話の順序を表す

messagesには、4種類のroleが入る

⚠ systemもuserも、LLMから見ればどちらもただの入力文字列。
systemは優先されるよう設計されているが、LLMはテキストを厳密に区別できないため、外部入力を指示として誤解し、結果的にsystemの意図が破られることがある (prompt injection)。

返ってくるJSONの、3つのメインフィールド

{
  "choices": [
    {
      "finish_reason": "stop",
      "index": 0,
      "message": {
        "content": "富士山の高さは、**3,776メートル**です。",
        "role": "assistant"
      }
    }
  ],
  "created": 1774969200,
  "id": "zdTuaejONoCnvr0P6L_cyQk",
  "model": "gemini-3.1-flash-preview",
  "object": "chat.completion",
  "usage": {
    "completion_tokens": 23,
    "prompt_tokens": 17,
    "total_tokens": 40
  }
}

応答はトークン単位で逐次送られてくる

完了を待たず、生成途中の delta を Server-Sent Events で受け取る。実プロダクトではほぼ必須。

POST /v1/chat/completions
{
  "model": "gpt-5.5",
  "stream": true,        // ← これだけ
  "messages": [...]
}

data: {"delta":{"content":"日"}}
data: {"delta":{"content":"本"}}
data: {"delta":{"content":"の"}}
data: {"delta":{"content":"首都"}}
data: {"delta":{"content":"は"}}
                  ...
data: {"finish_reason":"stop"}
data: [DONE]

補足: 中身は 通常応答と等価 ―― 全 delta を結合すれば普通の choices[0].message が再構築できる。

LLM APIは、完全にステートレス

LLM側に残るのは「受け取った文字列」と「学習済みの重み」だけ — セッションも履歴もサーバには無い。

temperature で、出力のランダムさを調整する

LLM は非決定論的ソフトウェア — 「賢い関数」として扱うと事故る

CPU / GPU は決定論的なのに、その上で softmax → sampling → temperature を通すことで、わざと非決定論的に振る舞わせている。テスト・再現・検証の設計が根本から変わる。

含意: LLM は 確定的なハードウェアの上に乗った非決定論的レイヤ。 既存のテスト・モニタリング・SLO の前提が崩れるので、エージェント設計では retry / fallback / eval / guardrail が必須になる。

ルールベースからAIエージェントへ

各世代で、人間が書くものが変わった

AIに任せられる範囲は広がり続けている — だからこそ、人間の設計はより重要になる。
抽象度が上がるほど、目的・制約・環境の設計が成果を左右する。今のエージェントも「完全自律」ではなく、ワークフローエンジン + LLM という構造。

時代ごとに、人間が書くコードはこう変わった

# 人間がルールを書く
if fever and cough:
  diagnosis = "flu"
elif fever and rash:
  diagnosis = "measles"
else:
  diagnosis = "unknown"

# 人間が特徴量を設計する
features = [
  age, bmi,
  blood_pressure,
  cholesterol_ratio,  # ← 人が考えた
]
model = SVM()
model.fit(features, labels)

# 人間がアーキテクチャを設計
model = Sequential([
  Conv2d(3, 64, 3),
  ReLU(),
  Conv2d(64, 128, 3),
  MaxPool2d(2),
  Linear(128, 10),
])

# 人間が目的と文脈を書く
response = llm.invoke({
  messages: [
    { role: "system",
      content: "医療アシスタント" },
    { role: "user",
      content: "頭痛と発熱が…" }
  ]
})

# 人間が制約・ツール・環境を設計する
agent = Agent(
  model  = "claude-sonnet",
  tools  = [search_db, send_email, calendar],  # ← 道具を選ぶ
  rules  = "RULES.md",                         # ← 行動規範
  guard  = [max_iter(10), no_delete],           # ← 安全制約
)
agent.run("来週の会議を設定して")                    # ← 意図だけ渡す

エージェントの80%は、普通のコード

エージェント開発 = AI開発ではない。大部分は従来のソフトウェア工学の延長。

state = messages 配列そのもの

他に隠されたstateは (基本的には) ない。LLM側は毎回はじめまして状態。

2ターン目には、1ターン目のメッセージも再送する必要がある

// ② turn 2 リクエスト
[
  { "role": "system", "content": "..." },
  { "role": "user",   "content": "じゃあ世界で何番目?" }
]

// ② turn 2 レスポンス
{
  "message": {
    "role": "assistant",
    "content": "何のことですか?"   // ← 文脈を失う
  }
}

// ② turn 2 リクエスト
[
  { "role": "system",    "content": "..." },
  { "role": "user",      "content": "富士山の高さは?" },     // ← 再送
  { "role": "assistant", "content": "3,776 メートルです。" },  // ← 再送
  { "role": "user",      "content": "じゃあ世界で何番目?" }
]

// ② turn 2 レスポンス
{
  "message": {
    "role": "assistant",
    "content": "標高では世界で約 50 位..."
  }
}

LLM側はステートレス → クライアントが過去の全メッセージを毎ターン再送。配列は毎ターン育ち続ける。

「記憶」は5つの層に分かれる

RAG — 必要な分だけ取ってきて messages に注入する

学習時に焼き込まれていない情報 (社内ドキュメント / 最新ニュース / プロダクト固有) を、埋め込みベクトルの近傍検索で取り出し、prompt に挿し込む。L4 メモリ層の中核。

位置づけ: RAG は tool calling の特殊形 — エージェント側が決め打ちで毎ターン検索ツールを叩く agent-driven パターンの典型例。

単純 RAG だけではなくなってきている

context window が 200k → 1M+ に拡張し、推論能力とtool callingが成熟したことで、「事前に chunk を取って貼る」以外の戦略が次々と現実的になっている。

含意: RAG は出発点であって最終形ではない。 LLM の能力が上がるたびに、「事前に貼る」から「能動的に取りに行く」「手順書として持つ」へと、知識の与え方そのものが変わり続けている。

LLMはサブワード単位でしか読めない

  "Hello, world!"
    │
    ▼ BPE tokenizer (cl100k_base)
    │
  [ "Hello", ",", " world", "!" ]   ← 4 tokens

• →よく出る語は 1トークン、珍しい単語は複数に分解される
• →" world" のようにスペースが単語の先頭にくっつく
• →何トークンかはモデルごとに違う — tokenizerが各社別々

コンテキストウィンドウは、全部の合計で決まる

ウィンドウは広いほど良いとは限らない

だから実務は「ウィンドウは大きいが、送る量は必要最小限」。

課金は トークン数 × 単価 — でも単価は 5種類ある

送ったトークンと返ってきたトークンの両方に課金。さらに cache / batch / reasoning で単価が変わる。エージェントは長文 + ツール連鎖でトークンが膨らむため、構造を理解しないとコストが暴走する。

原則: 「ウィンドウは大きいが、送る量は必要最小限」 ―― 自由に詰めると毎回がスポット契約になる。

リクエストに tools を足すだけ

{
  "model": "gemini-3.1-flash-preview",
  "messages": [ ... ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name":        "now",                                          // ← 識別子
        "description": "Return the current UTC time in ISO-8601.",  // ← LLMが読む
        "parameters": { "type": "object", "properties": {}, "required": [] }
      }
    }
  ]
}

LLMは description と parameters の両方を読むが、
型バリデーションではなく確率的に解釈する — 説明文が曖昧だと引数もズレる。

tool_calls の2往復

// → リクエスト: 「今何時?」
{
  "messages": [{ "role": "user", "content": "今何時?" }],
  "tools": [{ "name": "now", ... }]
}

// ← LLMの応答: 「nowを呼んで」
{
  "role": "assistant", "content": null,
  "tool_calls": [{ "id": "call_abc",
    "function": { "name": "now", "arguments": "{}" } }],
  "finish_reason": "tool_calls"
}

// → リクエスト: 履歴 + ツール結果を再送
{
  "messages": [
    { "role": "user",      "content": "今何時?" },
    { "role": "assistant", "tool_calls": [...] },
    { "role": "tool",      "tool_call_id": "call_abc",
      "content": "2026-04-11T02:28:00.000Z" }
  ]
}

// ← LLMの応答: 最終応答
{
  "role": "assistant",
  "content": "今は午前 11 時 28 分です。",
  "finish_reason": "stop"
}

2回のリクエストで 1 ターンが完結する。ツールを連鎖させると 3, 4, 5 往復と増えていく。

ツールの3要素

ツールはLLMの手足 — 単体では「知っていること」しか語れないLLMに、外の世界に触れる力を与える拡張レイヤ。

普段使っているコーディングエージェントは、ツールが驚くほど少ない

「高機能そうに見える」ものほど、実はプリミティブ数個の組み合わせで成立している。

差を生むのはツールの数ではなく、プロンプト設計 × モデルの賢さ × ループの回し方。
shell 1本あれば、cat も rg も git も curl も python も全部使える — プリミティブで十分。

汎用か専門か、でツール粒度の正解は変わる

Claude Code / Codex は「汎用」なので抽象度の高いプリミティブを選んでいる。専門エージェントなら話が別。

MCP — LLM への「ツール・コンテキスト接続」の共通インターフェース

Anthropic が提唱、JSON-RPC ベースのオープン仕様。「AI のための USB-C」 — ホスト(Claude Desktop / IDE / Agent) が、多様なサーバを同じ口で差し込める。

結果: AI ホストごとに独自プラグイン API を作る必要がなくなる。同じ MCP サーバを Claude / Cursor / Cline / 自作 Agent で使い回せる。

MCP のメリット / デメリット

実務的には: 「手元の開発はローカル MCP を積極的に、本番エージェントでは認可境界とコンテキスト圧迫を見て厳選」。

「Agent」とは何か — 3つの近傍概念と区別する

いま「Agent」は曖昧に使われている。自律的にツールを選択・実行し、状態を持ちながら目的を達成するシステム ―― ここを軸に近傍と比べる。

AIエージェントに対する考え方

エージェントは、7つの要素がループして動く

「LLMに聞く → ツールを叩く → 結果をmessagesに積む」を繰り返し、人へ回答か追加質問を返す。ユーザの返答でまたループが続く。

誰が、何を担当しているのか

1ターン ≠ 1 LLM呼び出し

1ターン = 1 user〜次の user まで。その間にAPIは 1〜N回 呼ばれる。

エージェントループは、単純なwhileループ

// 擬似コード
messages.push(userMessage)

loop:
  response = LLM.invoke(messages, tools)
  messages.push(response.assistant_message)

  if response.finish_reason == "stop":
    break                                    // ← 最終応答が出た

  if response.finish_reason == "tool_calls":
    for call in response.tool_calls:
      result = execute_tool(call)
      messages.push({
        role: "tool",
        tool_call_id: call.id,
        content: result
      })
    continue                                 // ← もう一度LLMに聞く

return messages[-1]

messagesは、こう育つ

// 初期状態
[ system, user: "今の時間を調べて、分に 15 をかけて" ]

// ITER 1 — LLM: now を呼びたい
+ assistant tool_calls: [{ name: "now", id: "c1" }]
+ tool      tool_call_id: "c1", content: "2026-04-11T02:28:00Z"

// ITER 2 — LLM: calc を呼びたい
+ assistant tool_calls: [{ name: "calc", args: "28*15", id: "c2" }]
+ tool      tool_call_id: "c2", content: "420"

// ITER 3 — LLM: 最終応答
+ assistant "現在UTC 02:28 なので、分の 28 × 15 = 420 です。"   finish_reason: stop

→ 3回のLLM呼び出し + 2回のツール実行 = 1ターン。コストは積算。

ループを止める、5つの終了理由

• 01finish_reason: "stop" — LLMが最終応答を返した（自然終了）
• 02finish_reason: "length" / "content_filter" — トークン上限超過 / コンテンツフィルタ発火
• 03maxIterations 到達 — エージェント側の反復上限。必須、無いとコスト暴走
• 04例外 — ツール実行エラー / LLM API失敗 (429 / 5xx / 400 / 401)
• 05明示的な終了シグナル — 専用の終了ツール（final_answer 等）/ ユーザー中断

01・02はLLMが返すfinish_reasonで判断。03〜05はエージェント側の判断。

ツール呼び出しには、3つの起動パターンがある

response = LLM.invoke(messages, tools)
if response.tool_calls:
  result = execute(response.tool_calls)
  messages.push(tool_result)
  // → もう一度LLMに聞く

// LLMの判断なしで毎回実行
context = search_db(user_query)
messages.push({ role: "system",
  content: context })
response = LLM.invoke(messages)

// LLMがコードを生成
program = LLM.generate_code(
  messages, tools)
// エージェントがまとめて実行
result = sandbox.exec(program)

実際のエージェントは組み合わせて使う。状況判断はLLM-driven、確実な前処理はagent-driven、複雑な連鎖はprogrammatic。

LLMがプログラムを書くことで、往復を減らす

// 往復 ① user → assistant(tool_calls: now)
// 往復 ② tool(時刻) → assistant(tool_calls: calc)
// 往復 ③ tool(計算結果) → assistant(tool_calls: format)
// 往復 ④ tool(整形済) → assistant(最終応答)

→ LLM API 4回呼び出し

// LLMが生成するプログラム:
time = call(now)
result = call(calc, { expr: time.min * 15 })
output = call(format, { value: result })
return output

→ LLM API 1回 + sandbox実行 1回

Anthropicのtool_use with code execution、OpenAIのCode Interpreterなどがこのパターン。

エージェントに、実行する義務はない

tool_calls は LLM の出力であって命令ではない。エージェント側でいくらでも介入できる。

7つの要素の掛け算が、エージェントの品質を決める

ここまでの7パートで基礎を押さえた。しかしエージェント技術は過渡期にあり、各要素が独立に急速進化している。
今日の講義では全てをカバーできないが、主要な進化軸を俯瞰しておく。

今日はこれらの基盤となる仕組みを理解することがゴール。各要素の最新動向は、この土台の上に積み上がる。

7つの要素のうち、最も重要なのは人間

エージェントは道具。どれだけ賢くても、使い方を間違えれば壊れる。人間の役割は「指示を出して待つ」だけではない。

「LLM + エージェント」に収束した世界を、3つの視点で見る

LLMには多くの分類軸がある

性能帯とモーダルで分類する

カテゴリは排他ではない。1つのモデルが複数に該当する（例: DeepSeek V4 = オープン + クラウド + フロンティア）。

分類軸の組み合わせで、モデルの性格が決まる

カテゴリは排他ではない。1つのモデルが複数に該当する。

ローカルで動かすには、どんなマシンスペックが必要か

モデルの重みをメモリ（GPU VRAM or 統合メモリ）に載せる必要がある。パラメータ数と量子化ビット数でサイズが決まる。

「ローカルで動く」と「データが外に出ない」は、別の話

プロバイダ選定は 学習利用 / ログ保持 / 外部送信 の3軸で見る。「ローカル = 安心」とは限らない。

判断軸: data residency / retention / egress。 ローカル LLM + ローカル MCP + ネット遮断、が最も閉じた構成。

誰がLLMを作り、誰がエージェントを作っているのか

ほぼ全員が「LLM + エージェント」の今、競争軸は モデル主導 vs エージェント主導 / ファースト vs サード の2軸。境界は流動的(② が自社LLM強化 / ③ が独自モデル投入 など)。

同じ会社でも、レイヤごとに別プロダクト

前ページの B(両方提供)から3社に絞る。会社名・モデル名・API名・チャットweb・コーディングエージェント・モバイルアプリはすべて別の固有名詞。混同すると話が噛み合わない。

エージェントはLLMを、選んだり切り替えたりできる

エージェントとLLMの提供元が同じか違うかで挙動が変わる。固有名詞は前ページの整理に従う。

3rd-partyエージェントがどうやって違うプロバイダのLLMを呼ぶのか — 答えは3経路。次から1つずつ見る。

Route 1 — 1st-party ネイティブAPI

Route 2 — 1st-party OpenAI互換

ChatGPT普及でOpenAI形式が事実上の標準になり、新規モデル投入の必須条件に近くなった。

Route 3 — 3rd-party アグリゲータ

どれが正解ではなく併用が現実 — 同じエージェントでも、モデルごとに Route 1 / 2 / 3 が混在する。

OpenAI API の遍歴

「OpenAI形式 = Chat Completions」が業界標準として固定化される一方、OpenAI 自身は次のAPI形態へ移り始めている。後発のものほどまだ普及途上。

含意: 互換エコシステムは Chat Completions に固定 されたまま、OpenAI 自身は Responses + built-in tools + Agents SDK に重心を移している。 他社が追従するかは未定 — Route 2 の射程の外。

下層は標準化、上層は差別化 — インターネット初期に近い構造

OpenAI / Anthropic / Google の API は messages・role・tools・streaming・temperature・top_p など基本部分が実質業界標準に寄っている。一方で高度機能は各社かなり独自。

基本 API は収束するが、上位機能はむしろ分化していく。

ChatGPT Plus や Claude Pro のサブスクリプションで サードパーティエージェントが使えない、制限される理由

サブスクは 人間がそのUIで使う 前提の定額プラン。サードパーティエージェントから自由に呼ばせると、提供側のビジネスとモデル品質の両方が崩れる。

結論: 「サブスクは人間用 / API は機械用」と、提供側は入口を分ける戦略で運用している。

例外: 会社間で金銭契約を結べば、サードパーティでも公式に動く

「サブスクで勝手に叩く」のは禁止だが、提携契約・収益分配・コミット買いを結べば、両者にとって良好な関係になる。

エージェントの品質は、3層から成る

3層は独立だが補完的。どれか1つだけ最適化しても全体は良くならない。

3層それぞれの最適化ポイント

3層はLLMを中心に包む構造になっている

テストが効かないなら、eval と observability で測る

単体テストは「同じ入力 → 同じ出力」が前提。LLM は出力が変わる以上、統計的合格率と本番トレースで品質を担保するしかない。

ローカルで動く AIスタック

基礎を構成する、7つのサービス

発展：+α のサービス

ドキュメント