AI AgentがJSONなしでは動かない理由：Tool Calling・Function CallingからMCPまでのデータフロー

以前の記事AI エージェント が JSON スキーマ、関数呼び出し、MCP を使用する理由説明したなぜこの 3 つの層が存在するのか。この作品は、実際に移動するバイト1 回の実際の呼び出しで、ほぼすべての JSON が実行されます。

ユーザーには自然言語が表示されます。 エージェント は、インテントを JSON パラメータとしてエンコードし、ツールの結果を JSON メッセージとしてエンコードし、クロスプロセス プロトコルを JSON-RPC としてエンコードすることで作業を実行します。 JSON は装飾ではありません。これは、モデル、ホスト、および MCP サーバー間で相互に検証できる唯一の言語です。

3 つの名前、1 つの JSON ペイロード

ドキュメントには 3 つの用語が混在しています。これらは異なるレイヤーにありますが、ペイロードの形状はほぼ同じです。

One sentence: the model side uses JSON to pick a tool and fill parameters; the MCP side uses JSON to discover and execute tools. The host is the translator: MCP tools/list becomes the model tools array; model tool_calls become tools/call.

JSON でなければならない理由

エージェント は、次の 3 つの当事者を同時に満足させる必要があります。

• モデル: トレーニング データは JSON でいっぱいです。有効なオブジェクトを発行することは、protobuf バイトよりもはるかに簡単です
• プログラム: 成熟した解析、スキーマ検証、Diff、およびJSONパスツール
• プロトコル: OpenAPI、JSON-RPC、およびMCP inputSchema はすでに 1 つの型の説明を共有しています

単純な言語はフェイルファストできません。括弧、引用符、および混合言語は正規表現パーサーを破壊します。 YAML はインデントに脆弱です。バイナリ プロトコルは人間と LLM の両方にとって敵対的です。 JSON は、監査可能、検証可能、バージョン管理可能なデフォルトのワイヤ形式になります。このサイトのツールがすべて JSON を中心に展開しているのはそのためです。つまり、そのワイヤをデバッグしていることになります。

ホップ 1: ツール定義のスキーマ

The flow starts by telling the model which tools exist. Whether you use OpenAI-style tools or MCP tools/list, the core is a JSON Schema (or a subset):

{
  "name": "get_weather",
  "description": "Look up current weather for a city, read-only",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "City name, e.g. Shanghai" },
      "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
    },
    "required": ["city"]
  }
}

In MCP the same constraint lives in inputSchema. Schema feeds two paths: the validator rejects illegal parameters; model context uses description to decide when to call. The more the field text reads like a product spec, the fewer mistaken calls.

ホップ 2: 関数呼び出し / ツール呼び出し

ホストがメッセージ付きのツール リストを送信した後、モデルはコードを実行しません。構造化された呼び出しを返します。一般的な形状 (フィールド名はベンダーによって異なります):

{
  "role": "assistant",
  "tool_calls": [
    {
      "id": "call_01",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"city\":\"Shanghai\",\"unit\":\"celsius\"}"
      }
    }
  ]
}

Note that arguments is often a stringified JSON object: JSON.parse first, validate against Schema, then execute. Results flow back as a tool-role message:

{
  "role": "tool",
  "tool_call_id": "call_01",
  "content": "{\"city\":\"Shanghai\",\"temp_c\":31,\"condition\":\"sunny\"}"
}

This hop is how the model reaches out. With parallel tools, the array holds multiple tool_calls; the host may run them concurrently and match results by id.

ホップ 3: MCP JSON-RPC

ツールがホスト プロセスではなく、MCP サーバー (ファイル システム、GitHub、内部命令) にある場合、ホストとサーバーは JSON-RPC 2.0 を話します。読み取り専用クエリは、およそ 3 つのステップで構成されます。

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"host","version":"1.0"}}}
{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"get_weather","arguments":{"city":"Shanghai"}}}

A successful Server response is JSON too: content often has type: "text" whose text is another JSON string. That is JSON wrapping JSON — outer envelope vs inner business payload. When debugging MCP, split those layers, then Schema-validate the inner one.

トランスポートは、stdio または Streamable HTTP です。ペイロードは依然として JSON 行または JSON 本体です。 2026 トランスポートとサーバー コードを変更する必要があるかどうかについては、MCP 2026 年移行ガイド.

1 つの通話のエンドツーエンド トレース

ユーザーは「今日の上海はどれくらい暖かいですか?」と尋ねます。エンドツーエンド:

1. Host → MCP Server: tools/list returns tools with inputSchema (JSON)
2. Host → model API: mapped to tools[].parameters (still JSON Schema)
3. Model → Host: tool_calls with arguments {"city":"Shanghai"}
4. ホスト は以下を検証します:スキーマに対して。フィールドが欠落しているか型が間違っていると実行が拒否され、エラー JSON がモデルに戻されます
5. Host → MCP: tools/call with params.arguments as an object (not a string)
6. MCP → ホスト:天気結果 JSON
7. Host → model: role: tool content string
8. モデル→ユーザー:自然言語。ダウンストリーム システムが構造のみを必要とする場合は、出力スキーマを使用して最終的な JSON を制約します

User natural language
    │
    ▼
Host orchestration ──JSON Schema──► LLM Tool Calling
    │                                  │
    │                                  ▼
    │                             arguments JSON
    │                                  │
    ▼                                  ▼
MCP JSON-RPC ◄──────────── validate, then execute
    │
    ▼
Result JSON ──► tool message ──► model final reply

小さなスクリプトは、MCP をスキップし、ホストのローカル関数を呼び出す場合があります。エンタープライズ エージェントは、ほとんどの場合、Tool Calling + MCP をスタックします。エコシステムの選択については、を参照してください。2026 MCP サーバー ランキング.

検証の失敗がどのように逆流されるか

JSON は、障害も構造化できるため、エージェント の型システムとして機能できます。少なくとも 2 つのゲートを使用します。

開発では、スキーマと 2 つまたは 3 つの有効/無効なペイロードを git に保持し、ローカルの JSON Toolbox で検証します。これは、コンシューマがモデルである点を除き、JSON コントラクト テストと同じ考え方です。

よくある質問

まとめ

AI エージェント は JSON なしでは生きていけません。すべてのホップは機械可読でなければなりません: スキーマはツールを記述し、Tool Calling が呼び出しを実行し、MCP がJSON-RPC としてプロセス外に送信します。自然言語はユーザー側の端でのみ表示されます。中央は検証可能なオブジェクトです。

Start with one real tool: write the Schema → print and parse the model's arguments string → if the tool lives on an MCP Server, capture one tools/call. When those three JSON documents line up, the Agent is actually working. For the evolution story see 技術的なタイムライン. Validate Schema samples locally in JSON Toolbox before you ship.