AI Agent とは？2026 の仕組み、Tool Calling、Function Calling と JSON 完全ガイド

AI Agent とは：チャットとワークフローとの差

最小定義は三つ。目標（何を終わらせるか）、知覚（文脈とツール回执）、行動（どのツール、どの引数、または最終回答）。各ステップの行動はモデルが選び、実行と観察の書き戻しはランタイムが担う。ループもツールも検証できる引数形もなければ、それはチャットだ。

チャットボットとの差は商標ではなく停止条件だ。チャットは一轮で終わってよい。Agent はツール結果の前に完了を宣言すべきではない。請求書を探し、要約し、確認を求めるかもしれない。古典的ワークフローとの差は辺を誰が引くかだ。n8n / Temporal の次ホップは人が配線する。Agent の次ホップは今の JSON 観察からモデルが選ぶ。ワークフローは予測と再生がしやすい。Agent は柔軟で、「引数の誤り」を一等の障害にする。

2026 年の形：コーディング Agent（ファイル、テスト、パッチ）、サポートと運用（注文、チケット）、多 Agent 編成（計画役が専門 Agent に委譲）。契約は同じ。境界は JSON Schema、arguments と result は parse できる JSON。Apple は同じ関数を App Intent とモデルツールに出せる。Apple AI Agent と JSON。

2026 の仕組み：観察 → 判断 → 呼び出し → 再観察

デモ映像の「知能」を剥がすと、典型ループは五步だ。

1. ユーザ目標が文脈に入る（自然言語と任意のシステム制約）。
2. ランタイムがツール一覧を注入する。name、description、JSON Schema（parameters / inputSchema）。
3. モデルが tool_calls（関数名と arguments）または最終テキスト / Structured Output を返す。
4. ランタイムが arguments を JSON.parse し、ローカル関数、HTTP、または MCP tools/call を実行し、result JSON をメッセージへ戻す。
5. モデルが結果を見て次のツールか終了を選ぶ。maxSteps、ユーザ取消、Schema 失敗でも止まる。

ループの形自体を設定にできる。下の JSON は hops と停止条件だけを書く。業務フィールドは各ツールの Schema へ。

{
  "loop": "agent",
  "maxSteps": 8,
  "stopWhen": ["final_answer", "max_steps", "user_cancel", "schema_fail"],
  "hops": [
    { "kind": "model", "emits": "tool_calls | text" },
    { "kind": "runtime", "emits": "tool_result JSON" },
    { "kind": "model", "emits": "next_tool | final JSON" }
  ]
}

故障はほぼ 3→4 步に集中する。arguments が文字列なのにオブジェクト扱い、数値が文字列、required 漏れ、キャッシュした一覧とツール名がずれる。「賢いモデル」では契約のずれは直らない。ステートレス MCP はリクエストごとにプロトコルメタを付けるが、形は渡した Schema に依存する。

Tool Calling と Function Calling：同じ仕組みの二つの名前

工学的には同じだ。モデルはデータベースに触らず、「この関数をこの引数で呼んで」という構造化要求を出し、ランタイムが実行する。2023–2026 の製品名の対照：

OpenAI は後に functions を tools に収め、strict を付けた。Anthropic は tool_use / input_schema。Gemini は function declarations。MCP は JSON-RPC tools/call。名前は違っても arguments は JSON object だ。「Function Calling は廃れた」を移行理由にするのは大抵誤りだ。古いフィールド名が老いたのであり、仕組みではない。

同じ請求書検索を OpenAI strict tool で書く。strict ではすべての property を required に入れないと、デフォルトがあるつもりでもモデルは合法的に省略できる。

{
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "description": "Search invoices by date range and status",
    "strict": true,
    "parameters": {
      "type": "object",
      "properties": {
        "startDate": { "type": "string", "format": "date" },
        "endDate": { "type": "string", "format": "date" },
        "status": {
          "type": "string",
          "enum": ["draft", "sent", "paid", "void"]
        }
      },
      "required": ["startDate", "endDate", "status"],
      "additionalProperties": false
    }
  }
}

呼び出し時の典型的な tool_calls はこうなる。arguments は依然文字列だ。先に parse、次に検証。JSON.parse 失敗をすぐ「モデルが壊れた」にしない。構文壊と Schema 不合を分ける。分類はAI JSON エラーガイド。

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "arguments": "{\"startDate\":\"2026-01-01\",\"endDate\":\"2026-01-31\",\"status\":\"paid\"}"
  }
}

なぜ JSON が Agent の契約言語か

パイプラインには少なくとも三つの JSON があり、同じ canonical Schema から来るべきだ。

1. ツール定義：name / description / parameters（または MCP inputSchema）。
2. モデル arguments：選ばれたキー。tool_calls 内では文字列になりがち。
3. ツール結果：ランタイムが戻す ok / result または誤り封筒。次 hop の材料。

四つ目は任意。最終回答の Structured Output。ユーザや下流への答えの形であり、searchInvoices の入参ではない。文法は同じ、意味は違う。ファイルと版を分ける。AI Structured Output チュートリアル。

成功後は下流 HTTP 原文をそのままモデルへ投げない。安定した封筒を返す。下の result は業務に必要なキーだけ。原文はログへ。形が安定すると再試行と要約が予測できる。

{
  "toolCallId": "call_8f3a",
  "name": "searchInvoices",
  "ok": true,
  "result": {
    "count": 2,
    "items": [
      { "id": "INV-1042", "total": 1280.5, "currency": "USD" },
      { "id": "INV-1048", "total": 640.0, "currency": "USD" }
    ]
  }
}

2026 の各スタック：OpenAI、Anthropic、Gemini、MCP

万能 Schema はない。だが Tool Calling のデータは寄っている。arguments は JSON object、契約は JSON Schema の部分集合。

MCP は発見と伝送であり、型システムではない。inputSchema は形の宣言。Server はなお parse + Schema 検証する。フィールド対応と一份 Schema の三面再利用はMCP と JSON Schema。多 Agent の受け渡しは A2A の message/send。スキル一覧にも Schema が付く。それは Agent 対 Agent であり、モデル対ツールではない。対照A2A vs MCP。

ステートレス MCP は Session を外したあと水平拡張しやすい。arguments は自動では直らない。古い tools/list キャッシュは誤った形を書き込む。プロトコルはStateless MCP 解説。

現場の検証と JSONVue

各 hop は三步。parse → Schema → 業務規則。賢いモデルでもこの三步は代替できない。

1. arguments 文字列を JSON.parse。失敗なら raw と tool_call id を残し、再試行可能な誤り封筒を返す。
2. parameters / inputSchema で Draft 2020-12 検証。path と keyword を出す。
3. 業務ゲート：日付範囲、列挙と権限、外部キー。通ってから下流 API。

三つの JSON を並べる。モデルの arguments、MCP または HTTP に送る body、Server が実際に使ったオブジェクト。形が違えばほぼアダプタ層。ブラウザではJSON フォーマッタで parse を確認、JSON Schema 検証で arguments と Schema、JSON Diffでモデル arguments と下流 body を比べる。valid / missing-field / wrong-enum を CI と手作業で共有する。

関連：MCP と JSON Schema、Structured Output、AI JSON エラー、A2A vs MCP。

よくある質問

まとめと次の一手

2026 年の AI Agent は一文にできる。モデルがループで行動を選び、ランタイムがツールを実行し、JSON Schema が各 hop の形を書く。Tool Calling と Function Calling は同じ仕組みの製品名。MCP、A2A、Structured Output は違う hop を担う。一つのファイルを無理に共用しない。

次は具体的だ。システム内の三つの JSON（定義、arguments、result）が同じ Schema かを確認し、JSONVue で valid / 欠フィールド / 誤列挙を再生する。プロトコルは MCP 記事、最終形は Structured Output、失敗の層は JSON エラーガイド。