AI AgentがJSON Schema・Function Calling・MCPを使い始めた理由：技術演进の全貌

2023 年、ChatGPT プラグインにより、API を呼び出すモデルが初めて世界に公開されました。 2024 年に、関数呼び出しがベンダー全体で標準になりました。 2025 年、Anthropic は MCP をリリースし、Cursor や Claude Desktop などの IDE がそれを採用しました。同じ弧を描いて、JSON はデータ交換形式からエージェントの形式に進化しました。型システムそしてハンドシェイクプロトコル。

RAG パイプライン、自動化ワークフロー、または Copilot スタイルの製品を構築している場合、最終的には次の 3 つの用語に遭遇することになります。JSONスキーマ(構造上の制約)、関数呼び出し(モデルはツールを選択し、パラメーターを入力します)、およびMCP(モデル コンテキスト プロトコル - 標準化されたツール接続)。この記事は、バックエンド、プラットフォーム、AI アプリケーションの開発者を対象としています。各レイヤーがなぜ出現したのか、どのような問題を解決するのか、それらがどのように組み合わされるのか、実際の選択方法について説明します。

エージェントに構造化インターフェースが必要な理由

初期の LLM アプリケーションの中心的なパターンは、ユーザーが質問する → モデルが自然言語を生成する → 実行のために結果を手動でコピーするというものでした。チャット シナリオにはこれで十分ですが、データベースの書き込み、電子メールの送信、インベントリのチェックなどを確実に実行することはできません。再現可能で監査可能自動化されたタスク。

Pure Prompt プロジェクトの ReAct (Reason + Act) モードでは、モデルでテキストに「Action: search(query=...)」を記述することができ、ホスト プログラムは通常の解析を使用します。実行は可能ですが、脆弱です。括弧のネスト、引用符のエスケープ、および複数言語の混合により解析エラーが発生します。本番環境に必要なものは、機械可読、検証可能、バージョン管理可能Markdown を解析するのに運に頼るのではなく、契約を結びます。

JSON は 3 つの要件を満たしています。LLM トレーニング データに大量に存在すること、人間とプログラムの両方で読み取ることができること、そして成熟したスキーマ検証エコシステムを備えていることです。その結果、JSON スキーマは、「モデルが出力するデータの形式」を記述するための事実上の標準になりました。関数呼び出しでは、「どの関数を呼び出し、どのパラメータを渡すか」も同じ JSON 構造に組み込まれます。

テクノロジー進化のタイムライン

この行に対する重要な変更は次のとおりです。「モデルがやりたいこと」を自然言語から入力された構造化メッセージに翻訳します。、ホスト プログラムまたは MCP サーバーによって安全に実行されます。

JSON スキーマ: エージェントの「型システム」

JSON スキーマは元々、API ドキュメントと構成検証 (OpenAPI、Kubernetes CRD など) に使用されていました。エージェントのシナリオでは、次の 2 種類の責任を負います。

• ツール入力パラメータ: Description search_products requires query (string) and limit (integer, default 10)
• モデル出力: たとえば、エンティティ、分類ラベル、承認結論などを抽出する場合、下流で使用するために固定フィールドを返す必要があります。

代表的なツールパラメータのスキーマ

{
  "type": "object",
  "properties": {
    "city": {
      "type": "string",
      "description": "City name, e.g. Beijing or Shanghai"
    },
    "unit": {
      "type": "string",
      "enum": ["celsius", "fahrenheit"],
      "description": "Temperature unit"
    }
  },
  "required": ["city"]
}

The description field is particularly important: it enters the context of the model and helps the model understand when to call and what the semantics of each parameter are - Schema also servesバリデーターそしてプロンプト。

構造化された出力とスキーマ

スキーマのみがプロンプトに書き込まれる場合、モデルにはまだ余分なフィールドや型エラーが存在する可能性があります。 OpenAI、Google などが提供する構造化出力 / JSON モードは、出力がスキーマに厳密に準拠するように、デコード段階でトークンを制限します。これは、「請求書 OCR → 構造化 JSON → 会計システム」タイプのパイプラインには必須です。

開発段階での提案: 最初に JSON ツールボックスなどのツールを使用します。ローカル検証スキーマ構文, and then use the sample payload to verify whether required and enum intercept illegal input as expected.

関数呼び出し: モデルとツール間のハンドシェイク

関数呼び出し (さまざまなベンダーではツール使用、ツール API とも呼ばれます) は、モデルとホスト間の通信を定義します。握手会:

1. ホストは、ツール リスト (名前、説明、パラメーター スキーマ) をメッセージとともにモデルに送信します。
2. The model does not directly execute the code, but returns tool_calls: selected tool name + JSON parameter string
3. The host executes the real function (check DB, adjust HTTP), and stuff the result back into the conversation as tool role message
4. モデルは、結果に基づいてエンド ユーザーに表示される回答を生成します。

ReActテキストモードとの比較

関数呼び出しは、エージェント フレームワーク (LangChain、AutoGen、Cursor Agent など) を排除しませんが、フレームワークとモデルの間のインターフェイスになります。薄いプロトコル層——フレームワークはオーケストレーション、再試行、メモリを担当します。モデル API は「どのツールを呼び出すかを決定する」責任があります。

MCP: プラグイン可能なツールのエコシステム

Function Calling は「モデル側で呼び出しをどのように宣言するか」という問題を解決します。しかし、ツールの数が増え、ソースが分散すると (GitHub、Slack、Postgres、ブラウザ、ファイル システム)、新たな問題が発生します。

• 各ホスト (IDE、チャット クライアント、自作エージェント) は、各ツールに適応したものを作成する必要があります。
• 権限、資格情報、stdio/HTTP トランスポート方法は相互に独立しています
• ユーザーは「MCP サーバーをインストールして、どこでも利用できるようにする」ことはできません。

モデルコンテキストプロトコル (MCP)2024 年後半に Anthropic によってオープンソース化され、ホストとツール プロバイダーの間の標準プロトコルとして位置付けられています。類推関係は大まかに次のとおりです。

MCP のコアコンセプト

• ホスト: 接続を開始したアプリケーション (Cursor IDE など)
• クライアント: ホスト内の MCP クライアント、サーバーとのセッションを維持
• サーバ: ツール、リソース、プロンプトを公開するプロセス (filesystem-mcp、github-mcp など)
• 能力: ツール リストは、プロンプトでハードコーディングされるのではなく、動的に検出されます。

MCP Tool's inputSchema itself is JSON Schema. Therefore, MCP does not replace Function Calling, but standardizes "tool implementation"; Host may still use MCP toolsマッピングモデルAPIの関数呼び出し形式。

3 つの連携方法

論理レイヤーを使用して、次の 3 つの関係を理解し​​ます。

┌─────────────────────────────────────────────┐
│  用户 / 业务系统                              │
└─────────────────────┬───────────────────────┘
                      ▼
┌─────────────────────────────────────────────┐
│  Agent Host（编排、权限、记忆）               │
│  ┌─────────────┐    ┌─────────────────────┐ │
│  │ LLM API     │◄──►│ Function Calling    │ │
│  │ (推理)      │    │ (tool_calls 消息)   │ │
│  └─────────────┘    └─────────────────────┘ │
│           ▲                    │              │
│           │ JSON Schema        ▼              │
│  ┌────────┴────────┐  ┌──────────────────┐  │
│  │ 输出 Schema     │  │ MCP Client       │  │
│  │ (Structured     │  │ ──stdio/SSE──►   │  │
│  │  Outputs)       │  │ MCP Server(s)    │  │
│  └─────────────────┘  └──────────────────┘  │
└─────────────────────────────────────────────┘

• JSONスキーマ: 各レイヤーを横断的に - ツールパラメータ、MCP inputSchema、モデル構造化出力
• 関数呼び出し: モデル ↔ ホスト呼び出し構文
• MCP:ホスト ↔ 外部世界のツールバス

小さなスクリプトには、関数呼び出しといくつかのローカル関数のみが含まれる場合があります。エンタープライズ レベルのエージェント プラットフォームでは、多くの場合、MCP クラスター + 統合スキーマ レジストリ + 監査ログが使用されます。

完全な通話リンクの例

ユーザーは「今日の上海の気温は何度ですか? ところで、GitHub にある私の json スキーマ関連のウェアハウスをチェックしてください。」と尋ねました。

1. ホストPull available tools from MCP: get_weather, github_search_repos
2. それぞれが JSON スキーマ パラメーターを含む、モデル API のツール配列に変換されます。
3. モデル2 つの tools_call を返します。パラメータは両方とも有効な JSON です。
4. ホストMCP 経由で天気サーバーと github サーバーを呼び出し、JSON 結果を収集します
5. 結果はツール メッセージとして返されます。モデルは自然言語応答を合成します
6. 作業指示システムに書き込む必要がある場合は、次を使用します。出力スキーマConstraint final JSON: { "summary", "temperature", "repo_count" }

ステップ パラメータがスキーマに準拠していない場合、ホストはそれを拒否し、実行前にモデルに再試行を要求できます。これはテキスト ReAct では困難です。フェイルファスト。

選択の比較とベストプラクティス

スキーマ設計のポイント

• Field description clearly writes business semantics, which can reduce miscalls better than type alone.
• required Better to be strict than loose; use default or explicitly nullable for optional fields
• Use string + description instead for large enumerations to avoid the enum list being too long and occupying the context
• スキーマは Git のバージョン管理に組み込まれており、コード レビューは API の変更と同じように行われます。

よくある質問

まとめと次のステップ

AI エージェントが「チャットできる」から「何かができる」への変換は、構造化された境界に層ごとに不確実性を固定することに依存しています。JSON スキーマは形状を定義し、関数呼び出しはモデルがどのように到達するかを定義し、MCP はツールがエコシステムに接続する方法を定義します。この 3 つはお互いの代わりになるものではありません。同じスタック上の異なるレイヤー。

次のステップの提案: 実際のビジネス ツール (注文の確認、通知の送信) を使用し、そのための JSON スキーマを作成します。 → 関数呼び出しに接続して 1 ラウンドを実行します。 次に、複数のホストを再利用するために MCP サーバーとしてカプセル化する価値があるかどうかを評価します。スキーマとサンプル データは、オンラインにする前に JSON ツールボックスでローカルに検証できます。