TECHNOLOGY EXPLAINER
Model Context Protocolとエージェント連携
― AIと外部のツール・データをつなぐ「共通の差し込み口」の、仕様・版・認可の読み方
AIアプリケーションが社内のデータベースや計測装置、業務システムを使うとき、システムごとに専用の接続部品を作っていては数が膨らみます。Model Context Protocol（MCP）は、その接続の取り決めを共通化する公開プロトコルです。ただし仕様は版で大きく変わります。2026-07-28 版では、接続の最初の握手（initialize）とセッションが取り除かれ、要求ごとに自己完結する方式に変わりました。 この記事では、MCP の構成（ホスト・クライアント・サーバー）、サーバーが出す3つの部品（ツール・リソース・プロンプト）、版の読み方、A2A など他のプロトコルとの関係、認可と権限の考え方を、公式の仕様ページで確認できた範囲で整理します。
- MCPとは何か（3行でつかむ）
- なぜ共通の規約が要るのか
- 構成：ホスト・クライアント・サーバー
- サーバーの3つの基本機能と、クライアントの機能
- 版の読み方 ― 2025-11-25 から 2026-07-28 で何が変わったか
- 他のプロトコルとの関係 ― A2A、AGENTS.md
- 認可と権限
- 運用上のリスクの考え方
- 素材技術者の視点：装置・データ・コスト
- 限界と、確認できなかったこと
- 評価・標準の読み方
- 用語集
- 参考資料（一次情報）
- 主張と出典の対応表（監査）
事実＝公式の仕様・発表・論文に記載のある内容（出典リンクあり）
本稿の計算＝明示した前提をもとに本記事が算出した値
未確定／将来＝草案・計画・改訂中であり、確定していない事項
このほか、読み取りは「解説」として区別しています。推測は太字で示します。
この分野は変化が速く、MCP の仕様は版ごとに互換性のない変更を含みます。本記事が読んだのは2026-07-28 版の仕様です。公式の版の説明ページは、確認日（2026年10月15日）時点で、この版を現行（Current）としています事実［参考資料5］。 この日付より後に新しい版が出ている可能性があります。導入や実装の前に、公式の仕様ページで最新の版を必ず確認してください。ここに書いた数値や要件は、特定の実装の動作を保証するものでもありません。
1. MCPとは何か（3行でつかむ）
Model Context Protocol（MCP）は、AIアプリケーションと外部のデータ・ツールをつなぐための公開プロトコルです。公式の仕様は、メッセージに JSON-RPC 2.0 を使い、ホスト（AIアプリ）、クライアント（ホストの中の接続部品）、サーバー（機能を提供する側）の3者で構成すると定めています事実［参考資料1］。
- 何をするものか：AIが使える「ツール」、AIに渡す「データ（リソース）」、人が選ぶ「プロンプトのひな形」を、サーバーが共通の形で公開し、クライアントが見つけて使えるようにする取り決めです事実［参考資料9］
- 誰が作ったか：Anthropic が2024年11月25日にオープンソースとして公開しました事実［参考資料20］。2025年12月9日に Linux Foundation が Agentic AI Foundation（AAIF）の設立を発表し、MCP は創設時の寄贈プロジェクトの1つ（ほかに Block の goose、OpenAI の AGENTS.md）になりました事実［参考資料21］
- どう管理されているか：仕様は「YYYY-MM-DD」形式の版で管理され、確認日時点の現行版は 2026-07-28 です事実［参考資料5］。プロジェクトは「Model Context Protocol a Series of LF Projects, LLC」として運営され、技術面の意思決定は個人（会社の席ではない）に基づく維持管理者（Maintainer）の階層で行うと、公式の運営方針に書かれています事実［参考資料18］
MCP は「通信の取り決め」であって、モデルでもエージェントでもなく、データの正しさや安全さを保証する仕組みでもありません。 何を公開するか、誰に何を許すか、結果をどう確認するかは、サーバーとホストを作る側の設計と運用で決まります。仕様自身も、プロトコルの水準では安全性の原則を強制できないと明記しています事実［参考資料1］。
2. なぜ共通の規約が要るのか
AIアプリがデータベースやファイル、業務システムを使うには、システムごとに「どんな操作ができ、どんな引数を取り、何が返るか」をAIに伝え、呼び出しを実行する接続部品が要ります。接続先とAIアプリがそれぞれ増えるほど、組み合わせごとに作る部品が増えます。Anthropic は公開時に、データ源ごとに個別の実装が必要になることが接続の拡大を妨げていると説明し、共通の規約で置き換えることを狙いとしました事実［参考資料20］。
図の数え方を式にすると、AIアプリがN個、外部システムがM個のとき、組み合わせごとに個別に接続すれば N×M 個、共通の規約を介せばアプリ側N個とサーバー側M個で N＋M 個です本稿の計算。たとえば5個のアプリと8個のシステムなら 40 個と 13 個、10個と20個なら 200 個と 30 個です。
これは接続部品の「個数」の数え方だけの単純な計算です。実際には、MCP を使ってもサーバーの設計（どの粒度のツールに切るか、権限をどう分けるか、データの単位や条件をどう伝えるか）の作業は各システムに残ります。すべての組み合わせが使われるとも限りません。工数の見積りや、特定の製品の比較に使える数字ではありません（本記事による解説）。
3. 構成：ホスト・クライアント・サーバー
元のSVG模式図・数値・出典注記を見る
公式仕様の構成は、次の役割分担です事実［参考資料6］。
| 役割 | 何をするか（公式仕様の記述） | 読むときの注意 |
|---|---|---|
| ホスト | AIアプリケーションの本体。クライアントを作り、接続の権限と寿命を管理し、セキュリティ方針と利用者の同意を実施し、AI／LLM との連携と、複数クライアントにまたがる文脈の集約を担う | 会話の全体を持つのはホスト。サーバーは「会話全体を読めない」ことが設計原則 |
| クライアント | ホストが作る接続部品で、1つのサーバーとだけ話す。2026-07-28 版では、要求のたびにプロトコルの版と能力を添付する | ホスト製品の中の部品であり、利用者が直接触る画面とは限らない |
| サーバー | リソース・ツール・プロンプトを公開する。ローカルのプロセスでも、リモートのサービスでもよい | サーバーが「安全」かは、プロトコルでは決まらない（第8章） |
すべて事実（アーキテクチャの章［参考資料6］）。
標準の通信路（トランスポート）は2つです。stdioはクライアントが起動した子プロセスの標準入出力で、改行区切りのメッセージをやり取りします。Streamable HTTPは、1つの MCP の窓口に対する HTTP の POST で、返答は JSON か、要求に紐づく SSE ストリームで返ります事実［参考資料7］。旧来の「HTTP＋SSE」方式は非推奨に分類されています事実［参考資料3］。 Streamable HTTP のサーバーは、DNS リバインディングを防ぐために Origin ヘッダーを検証しなければならず（MUST）、ローカルで動かすときは全インターフェース（0.0.0.0）ではなく localhost（127.0.0.1）にのみ待ち受けることが推奨（SHOULD）されています事実［参考資料16］。
2026-07-28 版の MCP はステートレス（状態を持たない）と明記されています。サーバーは、同じ接続の過去の要求から版・能力・クライアントの身元を推測してはならず、複数の要求にまたがる状態は、サーバーが発行して要求のたびに渡す明示的な識別子（ハンドル）で持つ、という規定です事実［参考資料7］。これが、サーバーを複数台に並べて運用しやすくする設計上の狙いです（本記事による解説。公式の説明は、共有の保存領域やステートフルな負荷分散を要さない、という趣旨）［参考資料8］。
4. サーバーの3つの基本機能と、クライアントの機能
公式仕様は、サーバーの3つの部品を「誰が使うタイミングを決めるか」で整理しています事実［参考資料9］。
| 部品 | 制御するのは | 中身 | 仕様が求める注意 |
|---|---|---|---|
| ツール | モデル | モデルが呼び出す関数。名前、説明、入力の JSON Schema（inputSchema）、任意で出力のスキーマ、注釈（annotations）を持つ［参考資料10］ | 人が拒否できる状態を常に保つことが推奨（SHOULD）。注釈は、信頼できるサーバーから得たもの以外は信頼してはならない（MUST） |
| リソース | アプリケーション | ファイル、データベースのスキーマなど文脈になるデータ。URI（RFC 3986）で識別する［参考資料11］ | 取り込み方はホストが決める。利用者の同意なしにリソースのデータを他へ送ってはならない（ホストの原則）［参考資料1］ |
| プロンプト | 利用者 | サーバーが公開する指示・手順のひな形。スラッシュコマンドのように利用者が選ぶ［参考資料32］ | 「利用者が選ぶ」は、使うタイミングの話であり、内容（サーバーが定義）を信頼してよいという意味ではない |
すべて事実（サーバー機能の章［参考資料9・10・11・32］）。右端の列の最後の一文は本記事の解説です。
ツールの定義で、仕様が決めていること
- 入力の書式：JSON Schema 2020-12 が既定の方言で、実装は少なくともこれに対応しなければなりません。2026-07-28 版では、inputSchema と outputSchema に任意の 2020-12 のキーワードを使えるよう緩和されました事実［参考資料2・7］
- 一覧は接続ごとに変わらない：tools/list が返す一覧は、接続ごと、または他の要求の副作用で変わってはなりません。ただし、要求に添えた認可（付与された scope など）によって変わるのは許されます事実［参考資料10］
- 順序とキャッシュ：サーバーは、集合が変わらない限り同じ順序でツールを返すことが推奨され、結果には鮮度の目安 ttlMs と、共有キャッシュの可否 cacheScope を付けます。仕様は、決まった順序がクライアントのキャッシュとLLMのプロンプトキャッシュの命中率の改善につながるとしています事実［参考資料2・10］
- サーバー側の安全要件（MUST）：入力の検証、アクセス制御、呼び出し回数の制限、出力の無害化。クライアント側（SHOULD）：機微な操作は利用者に確認する、入力を呼び出し前に利用者へ見せる（意図しない流出を避けるため）、結果をLLMに渡す前に検証する、タイムアウトを設ける、監査のために利用記録を残す事実［参考資料10］
クライアントの機能と、拡張
クライアント側の機能として残るのはエリシテーション（サーバーが利用者に追加の入力を求める）です。形式（フォーム）と URL の2つのモードがあり、パスワード・APIキー・アクセストークン・決済情報のような機密は、フォームで求めてはならず（MUST NOT）URL モードを使うと定められています事実［参考資料15］。 ルート、サンプリング、ログは2026-07-28 版で非推奨になりました（第5章）。
中核の外に、拡張（extensions）という任意の仕組みがあります。拡張は常にオプトインで、双方が対応を宣言して初めて使えます。公式仕様が代表例として挙げるのは、長時間の処理を扱う Tasks、エージェントの手順を発見・利用する Skills over MCP、会話の中に画面部品を出す MCP Apps です事実［参考資料1］。Tasks は、サーバーが結果の代わりに「作業の取っ手（task handle）」を返し、クライアントが tasks/get で状態（working、input_required、completed、failed、cancelled）を確かめて、再接続後でも結果を受け取れるようにします事実［参考資料19］。
5. 版の読み方 ― 2025-11-25 から 2026-07-28 で何が変わったか
版の名前は「YYYY-MM-DD」で、後方互換のない変更を最後に加えた日付を表します。互換を保つ変更では版は上がりません。版には Draft（草案）、Current（現行）、Final（確定済み）の状態があります事実［参考資料5］。公式サイトには、2024-11-05、2025-03-26、2025-06-18、2025-11-25、2026-07-28 の各版の仕様ページがあります事実［公式サイトの索引、参考資料1］。
2026-07-28 版の変更一覧のうち、実装に最も影響する「主要な変更」は次のとおりです事実［参考資料2］。
| 変更 | 内容 | 実装・運用への含意（本記事の解説） |
|---|---|---|
| セッションとハンドシェイクの廃止 | プロトコル上のセッションと Mcp-Session-Id が取り除かれ、initialize／initialized の手順も廃止。各要求が版（protocolVersion）と能力（clientCapabilities）を _meta に持つ。版が合わなければ UnsupportedProtocolVersionError | サーバーを複数台並べやすい。一方、旧版のクライアントは新しいサーバーにつながらない（双方の版を話せる実装が必要） |
| server/discover の追加 | サーバーは対応する版・能力・身元を返す server/discover を実装しなければならない（MUST）。クライアントが先に呼ぶのは任意 | 接続前の機能確認や、stdio での旧新判定に使う |
| 購読の方式変更 | HTTP の GET と resources/subscribe を、長く開く1本の応答ストリーム subscriptions/listen に置き換え。ping と logging/setLevel も削除 | 変更通知の受け方の実装が変わる |
| MRTR の導入 | サーバーが利用者入力などを必要とするとき、input_required を返し、クライアントが inputResponses を付けて元の要求を再送する | サーバーから要求を出す方式が使えなくなる（破壊的変更） |
| Tasks を拡張へ | 実験的だった tasks をコアから外し、拡張（io.modelcontextprotocol/tasks）に。tasks/result のかわりに tasks/get で状態を確かめる方式 | 長時間処理は拡張に対応した実装でのみ |
| 結果の resultType | すべての結果に resultType（complete／input_required）が必須。欠けている旧版の結果は complete とみなす | 旧サーバーの結果も読めるように作る |
| SSE の再開機能の廃止 | Last-Event-ID による再開と再送を削除。ストリームが切れると進行中の要求は失われ、クライアントは新しい要求として再送する | 再送しても副作用が二重にならない設計（冪等性）が要る。推測：再送時の重複実行を防ぐ工夫はサーバー側の設計課題になる |
「内容」列は事実（変更一覧［参考資料2］、MRTR［参考資料8］）。右の列は本記事の解説です。
非推奨になった機能と、廃止までの目安
公式サイトは、機能の状態を Active（有効）、Deprecated（非推奨）、Removed（廃止）で管理する方針を採り、非推奨の機能は少なくとも12か月は仕様に残る（緊急の例外は90日以上）としています事実［参考資料5］。2026-07-28 版で非推奨に分類されているのは次のものです事実［参考資料3］。
| 機能 | 移行先（公式の記載） | 廃止の対象になりうる最も早い時期 |
|---|---|---|
| ルート（Roots） | ツールの引数、リソースURI、サーバー設定でディレクトリやファイルを渡す | 2027-07-28 以降に公開される最初の版 |
| サンプリング（Sampling） | LLMプロバイダーのAPIを直接使う | 同上 |
| ログ（Logging） | stdio では stderr、観測には OpenTelemetry | 同上 |
| 動的クライアント登録（DCR、RFC 7591） | Client ID Metadata Documents（CIMD） | 同上 |
| HTTP＋SSE のトランスポート | Streamable HTTP | SEP-2596 が Final になってから3か月後 |
すべて事実（非推奨機能の一覧［参考資料3］）。「最も早い時期」は、廃止の資格ができる時期であり、実際の廃止は後になりうると公式が明記しています。
公式の互換性表では、旧版しか話さないクライアントは、新版しか話さないサーバーにつながらず、その逆も失敗します。双方の版を話せる実装（dual-era）だけが両方とつながります事実［参考資料4］。 導入前に、使うクライアント製品とサーバーがどの版に対応しているかを、各製品の公式資料で確認する必要があります。本記事は個別の製品の対応状況を確認していません（第10章）。
6. 他のプロトコルとの関係 ― A2A、AGENTS.md
Agent2Agent（A2A）プロトコルは、独立したエージェントどうしが能力を見つけ合い、課題（タスク）を委ね、情報を交換するための公開プロトコルです。A2A の公式ページは、MCP を「エージェントとツール・リソース」、A2A を「エージェントとエージェント」の接続と位置づけ、両者は競合でなく補い合うと説明します事実［参考資料22・23］。
| 観点 | MCP | A2A |
|---|---|---|
| つなぐ相手 | エージェント（のホスト）と、ツール・データ・プロンプトを出すサーバー | 互いに内部を見せない独立したエージェントどうし |
| 発見の仕組み | server/discover と、tools/list などの一覧 | エージェントカード（能力・接続先・認証要件を書いたJSON） |
| 長時間処理 | 拡張の Tasks | タスクとストリーミング、プッシュ通知が仕様の中核 |
| 版と状態 | 2026-07-28 が現行（確認日）。ステートレス | 公式の仕様ページは「最新の公開版 1.0.0」と表示。GitHub のリリースに v1.0.1（2026-05-26）がある。要求に A2A-Version を付ける |
| 運営 | LF Projects の一つ。2025-12-09に AAIF へ寄贈が発表された | Google が開発し Linux Foundation に寄贈。2026年8月27日に、AAIF の Growth Stage プロジェクトとして受け入れられたと A2A のブログが述べる |
すべて事実（MCP：参考資料1・5・18・21、A2A：参考資料22〜25）。A2A の採用規模（「150以上の組織が支援」など）は A2A 側のブログの記述で、本記事は独立に検証していません。
補足として、AGENTS.md は別の性格のものです。OpenAI が2025年8月に公開した、コーディングエージェント向けにプロジェクト固有の指示を置くための Markdown の約束事で、MCP や A2A のような通信規約ではありません。MCP、goose とともに AAIF の創設時の寄贈プロジェクトです事実［参考資料21］。 各モデル提供企業が自社のAPIに持つ関数呼び出し（function calling）の仕組みは、本記事では扱いません。MCP のツールの定義は、それらと同様に「名前・説明・入力の型」で表されるため、クライアントがモデル側の形式に変換して渡す、という役割分担になります（本記事による解説）。
MCP も A2A も、公式の文書は「オープンな規格」と書きますが、ISO／IEC や IEEE のような国際標準化団体の規格ではありません。オープンソースの仕様として、LF Projects などの下で運営されています。「業界標準」という言葉は、開発元や関連団体の主張である場合があります。たとえば Anthropic の幹部は LF の発表で、MCP を「業界の標準になった」と述べています［参考資料21］が、これは開発元の言葉です。 ISO／IEC や IEEE の規格として MCP や A2A が制定されているかは、本記事の調査では確認できませんでした。
7. 認可と権限
MCP の認可は任意（OPTIONAL）です。HTTP 系のトランスポートで認可を使う実装は仕様に従うことが推奨（SHOULD）され、stdio の実装は仕様に従わず、環境から資格情報を受け取ることが推奨されています（従うべきでない：SHOULD NOT）事実［参考資料12］。 仕組みは OAuth 2.1 を土台にします。MCP サーバーが OAuth 2.1 のリソースサーバー、MCP クライアントが OAuth 2.1 のクライアント、トークンを発行するのが認可サーバーで、認可サーバーはサーバーと同居していても別の事業者でもかまいません事実［参考資料12］。
| 要件 | 内容（公式仕様の記述の要約） | 仕様上の水準 |
|---|---|---|
| 認可サーバーの発見 | MCP サーバーは OAuth 2.0 保護リソースメタデータ（RFC 9728）を実装し、クライアントはそれで認可サーバーを見つける。認可サーバーは RFC 8414 か OpenID Connect Discovery のどちらかで自身の情報を公開する | MUST（サーバー・クライアントとも） |
| クライアントの登録 | Client ID Metadata Documents（CIMD）を推奨。事前登録も可。動的クライアント登録（RFC 7591）は非推奨で、CIMD に未対応の認可サーバーのための互換 | CIMD は SHOULD、DCR は MAY（非推奨） |
| PKCE | 認可コードの横取りを防ぐため、S256 方式で実装し、認可サーバーのメタデータに対応の記載がなければ処理を進めない | MUST |
| resource パラメータ | RFC 8707 に従い、認可要求とトークン要求の両方に、使い先の MCP サーバーの正規 URI を含める。認可サーバーが対応していなくても送る | MUST |
| 宛先（audience）の検証 | MCP サーバーは、自分宛てに発行されたトークンだけを受け入れ、他のトークンを受け入れも中継もしない | MUST／MUST NOT |
| トークンの送り方 | Authorization: Bearer ヘッダーに入れ、すべての HTTP 要求に付ける。URL のクエリ文字列には入れない | MUST／MUST NOT |
| 発行元（iss）の検証 | 認可サーバーは認可応答に iss を含めることが推奨。クライアントは iss があれば記録した発行元と照合してからコードを使う（RFC 9207） | サーバーは SHOULD、クライアントは MUST |
| scope（権限の範囲） | サーバーは必要な scope を WWW-Authenticate に入れて示すことが推奨。クライアントは最小権限で要求し、足りなければ追加の同意（段階的な昇格）を求める | SHOULD |
| トークンの寿命 | 認可サーバーは短命のアクセストークンを発行することが推奨。公開クライアントには更新トークンの回転が必須 | SHOULD／MUST |
| リダイレクトURI | localhost か HTTPS のみ。認可サーバーは登録済みの値と完全に一致するかを検証する | MUST |
すべて事実（認可の章と認可のセキュリティの章［参考資料12・13］）。表は要約で、仕様の全文ではありません。OAuth 2.1 は、MCP 仕様が参照する版（draft-ietf-oauth-v2-1-13）より新しいドラフトが IETF にあり（確認日時点で改訂16）、まだ RFC ではありません［参考資料33］。
仕様の「権限」の考え方を3つに分けると、次のようになります（本記事による整理）。
- 通信路の権限（誰がサーバーにつなげるか）：OAuth の認可と scope。stdio では OS の権限と環境変数で決まる
- ツールごとの権限（何を実行できるか）：サーバーが tools/list の内容を、付与された scope に応じて変えてよい事実［参考資料10］。権限の細かさは、サーバーの設計で決まる
- 人の関与（誰が最後に承認するか）：仕様は、ツールの呼び出しに人が介在し拒否できることを推奨し、ホストには利用者の明示的な同意を求めています事実［参考資料1・10］。ただし同意の取り方（画面）は仕様では定められておらず、実装ごとに異なります
上の表の MUST／SHOULD は、仕様が実装に求める水準です。実際のクライアントやサーバーが守っているかは、製品ごとに確認する必要があります。仕様自身も、プロトコルでは安全性の原則を強制できず、実装者が同意・認可の流れを作り込むべきだと書いています事実［参考資料1］。
8. 運用上のリスクの考え方
公式の「セキュリティのベストプラクティス」は、MCP の実装で起こりやすい問題を名前をつけて整理しています［参考資料14］。ここでは攻撃の手順には立ち入らず、問題の名前と、公式が示す対策の方向だけを表にします。
| 問題の名前 | 何が問題か（要約） | 公式が示す対策の方向 |
|---|---|---|
| 混乱した代理人（confused deputy） | MCP のプロキシサーバーが第三者のAPIにつなぐとき、利用者の同意を飛ばして認可が進んでしまう構成がありうる | クライアントごとの同意の取得、リダイレクトURIの厳密な検証など |
| トークンのパススルー | 自分宛てでないトークンを受け入れ、そのまま下流のAPIに渡す。監査の追跡や、下流の制御の回避が難しくなる | 自分宛てでないトークンは受け入れない（MUST NOT） |
| SSRF（サーバー側リクエスト偽造） | 認可の発見の過程でクライアントが取りに行く URL が、悪意のあるサーバーの指定で内部ネットワークなど意図しない宛先を指す | HTTPS の強制、宛先の制限など、ネットワーク環境に応じた対策を実装する（MUST consider） |
| 状態ハンドルの乗っ取り | 2026-07-28 版は複数の要求にまたがる状態を、サーバーが発行する識別子（ハンドル）で持つ。その識別子が推測・入手されると他人の状態を操作できる | ハンドルの所持を認証とみなさない（MUST NOT）。推測されにくい値にし、認証された利用者に紐づけて検証する |
| ローカルMCPサーバーの乗っ取り | 利用者の端末で動くサーバーは、端末のファイルや権限に近い。設定に悪意のある起動コマンドが紛れ込む危険がある | ワンクリック導入では、実行するコマンドを省略せず表示して明示の同意を取る（MUST）。サンドボックスで最小権限で動かす |
| scope の過大要求 | 広い権限をまとめて要求すると、トークン漏えい時の被害が大きく、同意の画面も読まれなくなる | 最小の初期 scope から、必要になった時点で昇格させる |
すべて事実（セキュリティのベストプラクティス［参考資料14］、認可のセキュリティ［参考資料13］）。表現は本記事による要約です。
ここまでの問題は、主に通信と認可の側のものです。もう一つ、MCP に固有でない、しかし MCP のサーバーを通じて現れやすい問題があります。ツールの説明文や、ツールが返す文章はAIの入力になるため、そこに紛れ込んだ指示にAIが従ってしまうことがありえます（プロンプトインジェクション）。仕様は、ツールの注釈（annotations）を、信頼できるサーバーから得たもの以外は信頼してはならない（MUST）と定めています事実［参考資料10］。 OWASP の「エージェント向けアプリケーション Top 10（2026年版）」は、MCP のツール記述子やスキーマが改ざんされる場合を、ツールの誤用と悪用（ASI02）の例として挙げています［参考資料26］。評価と安全の考え方は、本シリーズ『エージェントの評価と安全』編で詳しく扱います。
9. 素材技術者の視点：装置・データ・コスト
MCP のサーバーは、実験装置のデータ、電子実験ノート（ELN）、製造の履歴データなどをAIに見せる出入口にもなります。素材の研究開発や工場では、次の点を先に決めておくと、後の手戻りを減らせます（以下は本記事による解説で、MCP の仕様が要求する事項ではありません）。
- まず読み取り専用から：測定値や記録の参照と、装置の条件を変える書き込みは、サーバーも scope も分けます。仕様が許す「付与された scope に応じて tools/list の内容を変える」仕組み［参考資料10］は、この分離に使えます
- 数値だけを返さない：AIに渡す結果には、単位、測定条件、試料ID、時刻、装置の校正状態を添えます。数値だけでは、後から条件を取り違えても気づけません。素材の評価で「条件を書かない数字は比べられない」のと同じ理由です
- ツールの説明文も入力として管理する：説明文はAIが読む文章なので、第三者のサーバーのものは、仕様どおり信頼せずに扱います［参考資料10］。社内で作るサーバーは、説明文の変更もレビューの対象にします
- 再現性の記録：どの版のプロトコル、どのサーバーとツールの版で、どの引数を渡したかを記録に残します。仕様はクライアントに利用記録（監査用）を残すことを推奨しています［参考資料10］
- 物理的な操作は別格に：加熱・投入・ガス・圧力など、安全に直結する操作は、AIが直接呼ぶツールにせず、既存の制御系の安全機構と人の承認の後ろに置く、というのが無難な設計です。特定の安全規格への適合は、本記事では確認していません
MCP では、使えるツールの名前・説明・入力の型がモデルに渡されます。公式のクライアント向けの指針は、ホストが何十ものサーバーと数百のツールにつながると、ツール定義だけで文脈の大半を占めうると述べ、必要なときだけ定義を読み込む「段階的なツール発見」を勧めています。目安として、ツール定義が文脈ウィンドウの1〜5％程度を超えたら切り替える、という例を示しています事実［参考資料17］。
また仕様は、ツールを決まった順序で返し、結果に鮮度の目安（ttlMs）を付けることで、クライアント側のキャッシュとLLMのプロンプトキャッシュの命中率を上げられるとしています［参考資料2・10］。 文脈が長いほど、推論時の計算とメモリ（KVキャッシュ）が増えることは、本シリーズ『検索拡張生成とコンテキストウィンドウ』編と『推論の最適化とサービング』編で扱います。つまり、ツールをいくつ・どんな説明でつなぐかは、AIデータセンターの計算と電力にも間接的に響く設計項目です（本記事による解説。具体的なトークン数や費用は、モデルとクライアントの実装で変わるため、本記事では示しません）。
10. 限界と、確認できなかったこと
(1) 個別の製品の対応状況
特定のクライアント製品やサーバー（SDK を含む）が、どの版に対応し、仕様の要件をどこまで守っているかは確認していません。製品の優劣も論じません。
(2) 仕様の全文
本記事は、主要な要件を選んで要約しています。仕様の全文（スキーマ、エラー処理、ページ分割、キャンセル、進捗など）は扱っていません。MUST／SHOULD の水準は、取り上げた箇所について公式の文面から転記しました。
(3) 国際標準としての位置づけ
MCP や A2A が ISO／IEC や IEEE の規格として制定されているかは、確認できませんでした。両者は、LF Projects／Linux Foundation の下で運営されるオープンな仕様です。
(4) 採用の規模
MCP や A2A の「利用組織数」「サーバー数」などの数字は、開発元や関連団体の発表に現れますが、独立した一次情報で検証できなかったため、本記事では扱いません。
(5) 版の新しさ
確認日（2026年10月15日）以降に新しい版が出ている可能性があります。また本記事が参照した認可関係の文書のうち、OAuth 2.1 と CIMD は IETF のドラフトで、仕様が参照する改訂番号より新しい改訂が出ています［参考資料33・37］。
(6) セキュリティ
実際の脆弱性や攻撃の事例、個別のツール・サーバーの安全性評価は扱っていません。攻撃の手順も書いていません。
- MCP は、AIアプリと外部のツール・データをつなぐ公開の通信規約です。ホスト・クライアント・サーバーの構成で、サーバーはツール・リソース・プロンプトを出します事実
- 版を必ず確認します。確認日時点の現行は 2026-07-28 で、ハンドシェイクとセッションを廃止し、要求ごとに自己完結する方式に変わりました。ルート・サンプリング・ログは非推奨です事実
- A2A とは役割が違います。MCP はエージェントとツール、A2A はエージェントどうしです。どちらも国際標準化団体の規格ではありません事実
- 認可は任意ですが、使うなら OAuth 2.1 を土台に、PKCE・resource・宛先の検証・最小権限が求められます。仕様の要件と、実装が守っているかは別です事実
- ツールの説明文も、AIの入力です。信頼できるサーバーのもの以外は信頼しない、人が拒否できる状態を保つ、記録を残す、が基本です事実
11. 評価・標準の読み方
MCP の「性能」と「安全性」は、3つの層に分けて評価されます。①プロトコルとして仕様どおりに動くか（適合性）、②AIがツールを正しく使えるか（ツール利用の能力）、③ツールの説明や結果に紛れ込んだ指示に、AIが従わないか（耐性）です。①は仕様と検査ツール、②と③は学術論文のベンチマークが中心です。 どの層も、確認日（2026年10月15日）時点で、国際標準化団体（ISO／IEC、IEEE）が MCP そのものを対象に定めた規格は確認できませんでした。代わりに、認可は IETF の RFC、安全性の整理は OWASP と NIST の指針、組織の管理は ISO／IEC の AI 規格が関わります。
| 評価項目 | 代表的なベンチマーク・評価手法（名称・出典） | 標準・指針（ISO／IEC・IEEE・NIST・IETF・OWASP など） | 読み方の注意 |
|---|---|---|---|
| プロトコルへの適合 事実 | MCP Inspector（公式の開発・デバッグ用ツール。Web・CLI・TUI の3つのクライアント）［参考資料44］。公式リポジトリ modelcontextprotocol/conformance（「MCP の適合性テスト」）が存在する［参考資料43］。テストの内容と、どの版・どの機能に対応しているかは確認できなかった | MCP 仕様 2026-07-28（LF Projects の下のオープン仕様）［参考資料1］。ISO／IEC・IEEE の規格は確認できなかった | 「検査を通る」ことは「安全である」ことと別。検査がどの版・どの機能を対象にしているかを確認する |
| ツール利用の能力 事実 | MCP-Atlas（arXiv 2602.00933）：専門家が作った1,000課題、実在の36サーバー・220ツール、主張単位の採点、公開500・非公開500に分割［参考資料39］。MCPMark（arXiv 2509.24002）：127課題、作成・読取・更新・削除の操作を含む、pass@1 と pass^4［参考資料40］。MCP-Universe（arXiv 2508.14704）：6領域・11サーバー、実行に基づく採点［参考資料49］ | 該当する ISO／IEC・IEEE・NIST の標準は確認できなかった | 結果は論文の発表時のモデルと設定のもの。実施主体は論文の著者で、第三者とは限らない。サーバーの版が変わると再現しない。順位は断定せず、数値は載せない |
| ツール説明・結果への耐性 事実 | MCPTox（arXiv 2508.14925）：45の実サーバー・353ツール・1,348の試験ケース［参考資料41］。AgentDojo（arXiv 2406.13352）：97課題・629の安全試験ケース［参考資料42］。NIST AI 100-2e2025 の第3.6節が、AgentDojo など評価資料の例を挙げる［参考資料50］ | OWASP Top 10 for Agentic Applications for 2026（ASI01〜ASI10、2025年12月）［参考資料26］。OWASP Top 10 for LLM Applications 2026（2026年8月公表、LLM01:2026「Prompt Injection」、LLM03:2026「Excessive Agency」）［参考資料27］。2025年版では Excessive Agency は LLM06:2025 でした［参考資料28］。NIST AI 100-2e2025「Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations」（2025年3月）［参考資料50］ | OWASP と NIST の文書は指針で、法的拘束力はない。攻撃の成功率は、攻撃の作り方・防御の有無・モデルで変わり、設定の違う数字を並べて優劣をつけてはならない |
| 認可・認証 事実未確定／将来 | MCP 固有の認可の認証制度や公式ベンチマークは確認できなかった | RFC 9728（2025年4月）、RFC 8707（2020年2月）、RFC 7636（2015年9月）、RFC 8414（2018年6月）、RFC 9207（2022年3月）［参考資料34〜36・38・51］。OAuth 2.1（IETF ドラフト、改訂16）と CIMD（IETF ドラフト、改訂02）は策定中［参考資料33・37］。NIST の NCCoE 概念文書「Accelerating the Adoption of Software and AI Agent Identity and Authorization」（DRAFT、2026年2月、意見募集 2026-02-05〜04-02）［参考資料31］ | RFC の何を必須にするかは MCP 仕様が決める。ドラフトと概念文書は変わりうるので、版と日付を確認する |
| 組織としての管理・リスク管理 事実未確定／将来 | MCP 固有の評価手法は確認できなかった | ISO/IEC 42001:2023「Information technology — Artificial intelligence — Management system」（第1版、2023-12）［参考資料45］。ISO/IEC 23894:2023「Guidance on risk management」（第1版、2023-02）［参考資料46］。NIST AI RMF 1.0（NIST AI 100-1、2023年1月）［参考資料47］。NIST AI 600-1「生成AIプロファイル」（2024年7月）［参考資料48］。NIST の AI Agent Standards Initiative（ページ作成 2026-02-17、更新 2026-08-14）と CAISI の情報募集（Federal Register 2026-01-08、回答期限 2026-03-09）は進行中の取り組み［参考資料29・30］。なお NIST のサイトは、確認日時点でこの評価部署を「Center for Advancing Innovation and Standards for Super Intelligence（CAISSI）」と表記しており、これらの文書が書かれた当時の名称は CAISI（Center for AI Standards and Innovation）でした［参考資料52］。背景には、行政府の非法令文書で「AI」の代わりに「Super Intelligence」を使うよう定めた大統領令14434（2026年9月29日署名）があります［参考資料53］。文書の題名は原題のままです | ISO／IEC 42001 は組織の管理体制の要求事項、23894 は手引き。いずれも本文は有料で、題名と適用範囲のみ確認。法令（拘束力）とは別。NIST の取り組みは標準の策定途中 |
表の整理は本稿の計算（本記事による編集）。規格の本文は未確認のため、要求事項の中身は書いていません。
読み方の注意
- ベンチマークの数値は、設定と実施主体で変わります。同じ名前のベンチマークでも、使うエージェントの枠組み、ツールの版、サーバーの状態、思考の長さが違えば結果は変わります。論文の著者と開発元が実施した数字は、独立した第三者の数字ではありません。本記事は優劣をつけず、具体的な点数を載せていません
- 飽和と汚染に注意します。公開された課題は、学習データに混入して「覚えられる」ことがあります。MCP-Atlas が評価の一部を非公開にしているのは、順位表の信頼性を保つための工夫と説明されています事実［参考資料39］。外部のサーバーや日付に依存する課題は、時間が経つと正解が変わることもあります
- 「仕様の水準」と「法的な拘束力」は別です。MCP 仕様の MUST／SHOULD は、MCP プロジェクトが実装に求める水準です。OWASP と NIST の指針は推奨で、ISO／IEC 42001 は組織が認証を受けうる要求事項、RFC は IETF の技術標準です。どれも、それ自体が法律ではありません（規制は本シリーズ『EU AI法』編などで扱います）
- 宣言値と実測値の違いに注意します。仕様が「できる」と書くことと、実装が「できている」ことは別で、後者は適合検査と運用の記録で確かめます
12. 用語集
- MCP（Model Context Protocol）
- AIアプリと外部のツール・データをつなぐ公開プロトコル。JSON-RPC 2.0 を使う。
- ホスト／クライアント／サーバー
- AIアプリ本体／ホストの中の接続部品（1サーバーと対応）／機能を公開する側。
- ツール／リソース／プロンプト
- サーバーが出す3つの部品。モデル主導／アプリ主導／利用者主導。
- stdio／Streamable HTTP
- 標準の2つの通信路。子プロセスの標準入出力／HTTPの1つの窓口。
- エリシテーション
- サーバーが利用者に追加の入力を求める機能。機密はURLモードで。
- MRTR
- 複数往復の要求。追加入力が要るとき input_required を返し、入力を付けて再送する。
- server/discover
- サーバーの対応する版・能力・身元を返す必須の呼び出し。
- 拡張（extensions）
- 中核の外にある任意の機能。Tasks、MCP Apps など。双方が宣言して使う。
- A2A
- Agent2Agent プロトコル。独立したエージェントどうしの連携の公開プロトコル。
- AAIF
- Agentic AI Foundation。Linux Foundation の下の財団で、MCPなどを受け入れた。
- OAuth 2.1
- 権限の委譲の枠組み。IETF のドラフトで、MCP の認可の土台。
- PKCE
- 認可コードの横取りを防ぐための仕組み（RFC 7636）。
- CIMD／DCR
- クライアントIDを得る方式。メタデータ文書方式／動的登録（非推奨）。
- scope／audience
- トークンで許す権限の範囲／トークンの宛先。
- プロンプトインジェクション
- 入力に紛れた指示にAIが従ってしまう問題。
- SEP
- MCP の仕様変更の提案文書（Specification Enhancement Proposal）。
13. 参考資料（一次情報）
- MCP プロジェクト "Specification (Version 2026-07-28)" — modelcontextprotocol.io/specification/2026-07-28
- MCP プロジェクト "Key Changes"（2026-07-28 版の変更一覧） — modelcontextprotocol.io/specification/2026-07-28/changelog
- MCP プロジェクト "Deprecated Features" — modelcontextprotocol.io/specification/2026-07-28/deprecated
- MCP プロジェクト "Versioning and Compatibility"（仕様） — modelcontextprotocol.io/specification/2026-07-28/basic/versioning
- MCP プロジェクト "Versioning"（ドキュメント） — modelcontextprotocol.io/docs/2026-07-28/learn/versioning
- MCP プロジェクト "Architecture" — modelcontextprotocol.io/specification/2026-07-28/architecture
- MCP プロジェクト "Base Protocol Overview" — modelcontextprotocol.io/specification/2026-07-28/basic
- MCP プロジェクト "Multi Round-Trip Requests" — modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr
- MCP プロジェクト "Server Features Overview" — modelcontextprotocol.io/specification/2026-07-28/server
- MCP プロジェクト "Tools" — modelcontextprotocol.io/specification/2026-07-28/server/tools
- MCP プロジェクト "Resources" — modelcontextprotocol.io/specification/2026-07-28/server/resources
- MCP プロジェクト "Authorization" — modelcontextprotocol.io/specification/2026-07-28/basic/authorization
- MCP プロジェクト "Authorization Security Considerations" — modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations
- MCP プロジェクト "Security Best Practices" — modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices
- MCP プロジェクト "Elicitation" — modelcontextprotocol.io/specification/2026-07-28/client/elicitation
- MCP プロジェクト "Streamable HTTP" — modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
- MCP プロジェクト "Client Best Practices" — modelcontextprotocol.io/docs/2026-07-28/develop/clients/client-best-practices
- MCP プロジェクト "Governance and Stewardship" — modelcontextprotocol.io/community/governance
- MCP プロジェクト "Tasks"（拡張） — modelcontextprotocol.io/extensions/tasks/overview
- Anthropic "Introducing the Model Context Protocol"（2024年11月25日） — anthropic.com/news/model-context-protocol
- Linux Foundation "Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF)"（2025年12月9日） — linuxfoundation.org/press
- A2A プロジェクト "Agent2Agent (A2A) Protocol Specification" — a2a-protocol.org/latest/specification/
- A2A プロジェクト "A2A and MCP: Detailed Comparison" — a2a-protocol.org/latest/topics/a2a-and-mcp/
- A2A プロジェクト "A New Chapter for A2A: Joining the Agentic AI Foundation"（2026年8月27日） — a2a-protocol.org/latest/blog/2026/08/27/…
- A2A プロジェクト GitHub "Release v1.0.1"（2026-05-26） — github.com/a2aproject/A2A/releases/tag/v1.0.1
- OWASP GenAI Security Project "OWASP Top 10 for Agentic Applications for 2026"（2025年12月9日） — genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
- OWASP GenAI Security Project "OWASP Top 10 for LLM Applications 2026"（リソースページ 2026年8月3日、文書は Version 2026） — genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
- OWASP GenAI Security Project "LLM06:2025 Excessive Agency"（2025年版） — genai.owasp.org/llmrisk/llm062025-excessive-agency/
- NIST "AI Agent Standards Initiative" — nist.gov/artificial-intelligence/ai-agent-standards-initiative
- NIST CAISI "Request for Information Regarding Security Considerations for Artificial Intelligence Agents", Federal Register 91(5), 2026年1月8日 — govinfo.gov/content/pkg/FR-2026-01-08/html/2026-00206.htm
- NIST NCCoE "Accelerating the Adoption of Software and AI Agent Identity and Authorization"（概念文書、DRAFT、2026年2月） — nccoe.nist.gov/…/concept-paper.pdf
- MCP プロジェクト "Prompts" — modelcontextprotocol.io/specification/2026-07-28/server/prompts
- IETF "The OAuth 2.1 Authorization Framework"（Internet-Draft draft-ietf-oauth-v2-1） — datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
- IETF RFC 9728 "OAuth 2.0 Protected Resource Metadata"（2025年4月） — rfc-editor.org/rfc/rfc9728
- IETF RFC 8707 "Resource Indicators for OAuth 2.0"（2020年2月） — rfc-editor.org/rfc/rfc8707
- IETF RFC 7636 "Proof Key for Code Exchange by OAuth Public Clients"（2015年9月） — rfc-editor.org/rfc/rfc7636
- IETF "OAuth Client ID Metadata Document"（Internet-Draft draft-ietf-oauth-client-id-metadata-document） — datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/
- IETF RFC 9207 "OAuth 2.0 Authorization Server Issuer Identification"（2022年3月） — rfc-editor.org/rfc/rfc9207
- Bandi C. ほか "MCP-Atlas: A Large-Scale Benchmark for Tool-Use Competency with Real MCP Servers", arXiv:2602.00933 — arxiv.org/abs/2602.00933
- Wu Z. ほか "MCPMark: A Benchmark for Stress-Testing Realistic and Comprehensive MCP Use", arXiv:2509.24002 — arxiv.org/abs/2509.24002
- Wang Z. ほか "MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers", arXiv:2508.14925 — arxiv.org/abs/2508.14925
- Debenedetti E. ほか "AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents", arXiv:2406.13352 — arxiv.org/abs/2406.13352
- MCP プロジェクト GitHub "modelcontextprotocol/conformance"（Conformance Tests for MCP） — github.com/modelcontextprotocol/conformance
- MCP プロジェクト "MCP Inspector" — modelcontextprotocol.io/docs/2026-07-28/tools/inspector
- ISO／IEC "ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system"（ISO の標準ページ） — iso.org/standard/42001
- ISO／IEC "ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management"（ISO の標準ページ） — iso.org/standard/77304.html
- NIST "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", NIST AI 100-1（2023年1月） — doi.org/10.6028/NIST.AI.100-1
- NIST "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile", NIST AI 600-1（2024年7月） — doi.org/10.6028/NIST.AI.600-1
- Luo Z. ほか "MCP-Universe: Benchmarking Large Language Models with Real-World Model Context Protocol Servers", arXiv:2508.14704 — arxiv.org/abs/2508.14704
- NIST "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations", NIST AI 100-2e2025（2025年3月） — doi.org/10.6028/NIST.AI.100-2e2025
- IETF RFC 8414 "OAuth 2.0 Authorization Server Metadata"（2018年6月） — rfc-editor.org/rfc/rfc8414
- NIST "Center for Advancing Innovation and Standards for Super Intelligence (CAISSI)"（NIST のページ、確認日 2026年10月15日） — nist.gov/caissi
- 米国大統領府 Executive Order 14434 "Inaugurating the Era of Super Intelligence", Federal Register 91(190)（2026年9月29日署名、10月2日掲載） — federalregister.gov/documents/2026/10/02/2026-20321/…
14. 主張と出典の対応表（監査）
最終更新：2026年10月15日／出典は一次情報（MCP と A2A の公式仕様、Linux Foundation・Anthropic の発表、OWASP・NIST・IETF・ISO の公式ページ、arXiv の論文）に限定しています。規格（ISO／IEC）の本文は有料のため確認できていません。 この分野は変化が速く、版や状態は確認日（2026年10月15日）のものです。 MCP・A2A の国際標準としての位置づけ、個別製品の対応版、適合性テストの内容、採用規模の数字については、確認できなかったため記載していません。 図2〜図7はベクター作図、図1と図8はAI生成イメージであり、いずれも実在の施設・製品・測定結果を示すものではありません。