MCP とは？Model Context Protocol、JSON-RPC、AI Agent とツール呼び出し完全ガイド

MCP とは：モデルではなく、ツール接続のプロトコル

最小定義は三者。Host（エディタまたは Agent プロセス）、Client（Host 内で Server に話す側）、Server（ツール、リソース、プロンプトを出すプロセスまたは HTTPS 端点）。Client は Server に一覧を求め、name、description、inputSchema をモデル文脈へ入れ、モデルが呼ぶと決めたら tools/call を送る。MCP が見つけ方と呼び出しの形を担う。モデルの思考は見ない。

「AI プラグイン」は半分だけ正しい。ブラウザプラグインは一つの宿主にぶら下がる。MCP Server は複数 Client で再利用できる。同じ請求書検索を Cursor、Claude Desktop、自前の編成器に出せる。差は「関数を呼べるか」ではなく、一覧と呼び出し封筒が標準化されているかだ。自前の OpenAPI アダプタでも HTTP は呼べる。Client が増えるたびにアダプタを書き直す。MCP はその層をプロトコルに収める。公式の概念と仕様はModel Context Protocol ドキュメント。

年表では、Anthropic が 2024 年に MCP をオープンソース化し、2025 年末に Linux Foundation の Agentic AI Foundation（AAIF）へ入った。2026 年、各 Host はデモではなく既定のリモートツール通路として扱う。プロトコル版はリクエストの _meta に出る。2026-07-28 は「双方がこの意味に合意した」であり、「モデルが賢くなった」ではない。チャットボットや定期ワークフローとの差はAI Agent とはにある。ループも検証できる引数形もなければチャットだ。ループがあってもツールがローカル関数なら Agent ではあるが、標準のリモート一覧はない。

JSON-RPC 2.0：なぜこの封筒か

MCP は新しい RPC を発明していない。各プロトコル動作を JSON-RPC 2.0 の封筒に入れる。jsonrpc、id、method、params、または error。要求と応答は同じ id で揃える。通知は id がなくてよい。ゲートウェイとログには、独自のストリームフレームより分解しやすい。先に method、次に業務。フィールドの約束はJSON-RPC 2.0 仕様。

method はプロトコルの動詞であり、業務関数名ではない。tools/list が一覧、tools/call が呼び出し、resources/read が資源。業務名は params.name、引数は params.arguments。searchInvoices を method に書くのはよくある誤読だ。それは自前の JSON-RPC サービスであり、MCP ではない。標準の一覧要求はこうなる。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

封筒が解くのは三つ。多重化（複数の id を並列）、誤りの分類（parse 失敗、未知メソッド、業務拒否）、輸送の交換（stdio 子プロセスも Streamable HTTP も同じ JSON）。arguments の正否は解かない。合法な JSON-RPC でも、欠けたフィールドの arguments を Server へ渡せる。Server は自ら parse し、inputSchema で検証する。

AI Agent が MCP を使う流れ：発見 → 選択 → 呼び出し

デモ映像の「知能」を剥がすと、MCP を付けた Agent ループはなお五步だ。変わるのは 2 と 4 がローカル関数に固定されないことだ。

1. ユーザ目標が文脈に入る（自然言語と任意のシステム制約）。
2. Client が接続済み MCP Server へ tools/list を送り、返った一覧をモデルが読める tools / functions に変える。
3. モデルが tool_calls（関数名と arguments）または最終テキスト / Structured Output を返す。
4. ランタイムが arguments を JSON.parse し、MCP tools/call を送り、result をメッセージへ戻す。
5. モデルが結果を見て次のツールか終了を選ぶ。maxSteps、ユーザ取消、Schema 失敗でも止まる。

第 4 步の MCP 要求はこうなる。params.arguments はすでにオブジェクトであり、文字列ではない。プロトコル版は _meta に付け、ステートレス経路が読めるようにする。

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "searchInvoices",
    "arguments": {
      "startDate": "2026-01-01",
      "endDate": "2026-01-31",
      "status": "paid"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

Agent の定義は MCP に依存しない。ローカル関数、OpenAPI、自前 HTTP もツールになる。MCP の価値は、一つの Server を複数 Host が見つけられ、リモートでも一覧と呼び出し形が揃うことだ。採用の判断は「第二の Client がこのツール群を再利用するか」であり、「2026 らしく見えるか」ではない。ループの工学定義はAI Agent の仕組み。

モデルのツール呼び出し：tool_calls と tools/call

工学的には Tool Calling と Function Calling は同じ仕組みだ。モデルはデータベースに触らず、「この関数をこの引数で呼んで」という構造化要求を出す。MCP は次の hop だ。ランタイムがその要求を JSON-RPC tools/call に訳す。二つの hop のフィールド名はよく混ざる。

モデルが呼ぶとき、典型的な tool_calls はこうなる。arguments はなお文字列だ。ランタイムは先に parse し、オブジェクトを MCP の params.arguments へ置く。文字列をそのまま JSON-RPC に入れてはならない。「arguments という名前の文字列フィールド」になり、Server の Schema 検証が即失敗する。

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

各社の外壳は違う。OpenAI は tools[].function.parameters、Anthropic は input_schema、Gemini は function_declarations。MCP は Tool.inputSchema。名前は違っても canonical Schema は一份であるべきだ。フィールドの揃え方と、strict で required に全 property を入れる理由はMCP と JSON Schema。最終回答は Structured Output へ。ツール入参と同じファイルにしない。

2026 の地図：ローカル、リモート、ステートレス、A2A

輸送は二本。ローカル stdio は Host が子プロセスを起こし、標準入出力で JSON-RPC を流す。本機ファイルや本機 DB 向き。リモート Streamable HTTP は同じ封筒を HTTPS 端点へ POST する。共有の請求書、チケット、内部 API 向き。リモートはもう「先に握手して Session ID」に縛られない。2026-07-28 前後、要求はできるだけ自己記述し、ゲートウェイが method で制限できる。

ステートレスはプロトコル層だ。任意のインスタンスが任意の要求を受けられる。アプリ層にはなおデータベース、冪等キー、利用者身元がある。「プロトコルが無状態ならツール検証は不要」は逆だ。セッションキャッシュがなければ、前回の tools/list が生きていると思ってはならない。古い一覧は誤った形を tools/call に書く。プロトコルはステートレス MCP と JSON-RPC。

MCP は多 Agent プロトコルでもない。計画役が価格、コンプライアンス、物流の Agent に渡すのは A2A の message/send であり、tools/call ではない。各専門 Agent の内部はなお MCP で自分の DB を呼べる。プロトコル戦争という枠は大抵誤りだ。一层はツール、一层は Agent。対照はA2A vs MCP。仕様と実装はMCP GitHubにある。版の変更は仕様リポジトリを信じ、一つの Host のブログだけを写さない。

現場の検証と JSONVue

各 hop は三步。parse → Schema → 業務規則。MCP 封筒が合法でも arguments が合法とは限らない。賢いモデルでもこの三步は代替できない。

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

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

関連：AI Agent とは、MCP と JSON Schema、ステートレス MCP、A2A vs MCP。

よくある質問

まとめと次の一手

2026 年の MCP は一文にできる。JSON-RPC でツールを発見し呼び、結果をモデル文脈へ戻す。モデルではない。Agent ではない。A2A でもない。Tool Calling はモデルが関数を選ぶ層、MCP はランタイムがリモートツールを見つけて呼ぶ層、JSON Schema は各 hop の形を書く。

次は具体的だ。システム内の三つの JSON（モデル arguments、MCP params.arguments、下流 body）が同じ Schema かを確認し、JSONVue で valid / 欠フィールド / 誤列挙を再生する。プロトコルはステートレス MCP、フィールド揃えは Schema 記事、多 Agent は A2A 対照。