agent-interop

エージェント間相互運用 — エージェントが自身のプロセス外で使用するプロトコル

agent-orchestrator はループを構築します。agent-evals はその動作を検証します。このスキルでは、ループが到達するプロセス外のすべてを扱います。ツールサーバー、ピアエージェント、レジストリ、そしてそれらの間をつなぐゲートウェイです。

---

トリガー

「MCP クライアント」、「エージェント相互運用」、「server.json」、「agentgateway」、「ツールフェデレーション」、「интероперабельность агентов」、「реестр MCP」、「委任トークン」、「токен делегирования」。

0.31.3 の説明にあった「карточка агента」からこちらに移動しました。

ルール 0 — 日付のないプロトコルに関する主張は推測です

これらの仕様はすべて、以下の各参照を確認した日付である 2026-08-13 までの 12 か月間に変更されており、その変更によって、以前のリビジョンを前提に書かれたコードが気づかないうちに壊れる可能性があります。具体的には、各項目について、その日付に記憶ではなく最新の仕様を基準に確認したところ、次のとおりでした。

• MCP は initialize ハンドシェイクを server/discover に置き換え、プロトコルをステートレスにしました。initialize で接続を開始するクライアントは、廃止に向かいつつあるリビジョンを使用しています。
• MCP は sampling、roots、logging の 3 つを非推奨にしました。1 年にわたりクライアント側の目玉だったため、古いモデルがまず使おうとする機能です。
• A2A は v0.x から v1.0 への間にワイヤーインターフェースの名称を変更しましたが、2026-08-13 時点でも SDK やブログ記事には v0.3 の説明が残っていました。
• agentgateway は binds を非推奨にし、gateways を推奨するようになりました。一方、2026-08-13 時点でも、agentgateway 自身の概要ページでは binds が主要な概念として紹介されていました。

そのため、このスキル内のすべての参照は **Spec pinned:** の行で始まります。このパックのリポジトリ検証ツールは、その行がないとビルドを失敗させます。これは目標ではなく機械的なチェックです。ページにそれ以外の記載がないため、文章が最新情報に見えてしまうという種類の誤りを防ぎます。

ワイヤーレベルのコードを書く前に、仕様を取得してください。 これらの参照は、確認すべき点や変更内容を示しますが、仕様書の代わりにはなりません。指定されたリビジョンを読み、より新しいものがないか確認してください。以下のリンクマップにある各項目は取得できます。

どのプロトコルがどの質問に答えるか

実際に抱えている疑問	答え	場所
稼働中のシステムに対する機能をモデルに提供したい	MCP サーバー	references/mcp.md
サーバーを書いたのに、クライアントが接続できない	マウントとトランスポート	references/mcp-ship.md
自分のアプリケーションから他の人のツールサーバーを利用したい	MCP クライアント	references/mcp.md、続いて references/mcp-scale.md
コンテキストウィンドウに収まらないほど多くのサーバーがある	クライアントのスケーリングパターン	references/mcp-scale.md
別のチームの自律型エージェントに、自分の代わりに成果を達成してもらいたい	A2A	references/a2a.md
自分のエージェントを、他のエージェントが発見して呼び出せるようにしたい	A2A エージェントカード	references/a2a.md
自分の MCP サーバーを見つけてインストールしてもらいたい	MCP レジストリ	references/registry.md
多数のサーバー、多数のクライアント、そしてセキュリティチームがある	ゲートウェイ	references/gateway.md

2つの大きなプロトコルを区別する一行ルール。 MCP は、形を自分で決められる機能にモデルを接続します。A2A は、内部を意図的に見られないピアに接続します。公式の説明は正確で、覚えておく価値があります。"A2A はエージェント同士がタスクで協力するためのものであり、MCP はエージェントが機能を利用するためのものです。" 実際のシステムでは両方を使います。内部で MCP を話す A2A サーバーを構成するのが、妥協ではなく推奨されるアーキテクチャです。

振り分けの基準は、相手が何であるかであって、実行時間の長さではありません。 MCP ＝ 形を自分で決められる機能／ツール、A2A ＝ 成果を委任し、内部を見ることができない自律的なピアです。実行時間の長さは第2の問いであり、プロトコルではなく Tasks 機能に関するものです。 自分が管理する、10分かかるエクスポートやバッチ変換のような長時間実行の固定ジョブは、Tasks 拡張機能を使う MCP です（永続的なハンドルを使い、ポーリングや実行中の入力提供、後からの結果取得ができます。references/mcp.md を参照）。A2A ではありません。したがって、振り分け先の種類で判断し、長時間実行という言葉だけで決めないでください。

• 長時間実行の固定エクスポート → クライアント／SDK がその拡張機能をネゴシエートする場合は MCP Tasks。
• 自律型の交渉を外部に委任 → A2A（手順ではなく、成果を委任します）。
• 接続先のクライアント／SDK が Tasks をサポートしていない → 明示的なフォールバックを使います（ジョブを分割する、呼び出し元が通常の tools/call でポーリングするジョブ ID を使う、または webhook を使う）。Tasks がないからといって A2A に手を伸ばすのは、拡張機能の欠落を回避するためにプロトコルを選んでいるにすぎません。

Tasks を基盤に構築する前に、クライアントが実際にネゴシエートした拡張機能を確認してください。Tasks が利用可能なのに tools/call の上に独自のタスクライフサイクルを作るのは、拡張機能を再実装することになります。また、Tasks が単にサポートされていないだけなのに A2A に手を伸ばすのも、この監査で解消する誤った振り分けです。JSON スキーマを使った1回の HTTP 呼び出しにすぎないもののためにエージェントカードを公開するのも、依然として MCP の領域です。

---

参考資料

各ファイルの冒頭には、それぞれ「この内容を読むタイミング」と改訂スタンプがあります。この表は索引です。参照するタイミングは各ファイルに記載されているため、両者が食い違うことはありません。

ファイル	参照するタイミング
references/mcp.md	MCP サーバーを構築または呼び出すとき — レイヤー、リクエストごとの _meta、server/discover、3 つのサーバープリミティブと唯一残るクライアントプリミティブ、通知、キャッシュ、トランスポート、非推奨項目の全一覧
references/mcp-ship.md	サーバーは実装済みなのに、接続できないとき — 既存のウェブアプリへのマウント、トランスポートレベルの認証、クライアント設定、実際には二重パスが原因の 404
references/mcp-scale.md	ホストのサーバーやツールがコンテキストに収まらないとき — 段階的なディスカバリー、プログラムによるツール呼び出し、キャッシュとの相互作用、それぞれがもたらすセキュリティ上の影響範囲
references/a2a.md	相手がツールではなく、別のエージェントであるとき — エージェントカードとディスカバリー、タスクのライフサイクルと終了状態、3 つのプロトコルバインディング、ストリーミングとプッシュ
references/registry.md	サーバーを公開するとき、またはレジストリを利用するものを構築するとき — server.json、逆 DNS 名前空間と所有権の証明方法、公開フロー、レジストリが拒否する 3 つのケース
references/gateway.md	エージェントのトラフィックに一元管理された接続点が必要なとき — API ゲートウェイにはなくゲートウェイに必要な機能、フェデレーションと名前の衝突、認可を実際に行う場所、そして委任 — どのエージェントが誰の代理として動くか、また呼び出しにトークンが必要かを示すトークン（マシンによる信頼：T0/T1/T2）

---

対象範囲 — このスキルが扱わないこと

make-skillとの境界。 make-skillが扱うのは、スキル作成者の視点です。つまり、タスクにスキルとサーバーのどちらが必要か、compatibilityでサーバー依存関係を宣言する方法、そしてツール名がホストによって異なること（Claude Codeではmcp__<server>__<tool>、プラグイン独自のサーバーではmcp__plugin_<plugin>_<server>__<tool>）です。このスキルが扱うのはワイヤープロトコルです。「プロトコルの仕様はどうなっているか」という質問の答えはこちらにあり、「自分のスキルで必要なサーバーをどう宣言するか」という質問の答えはあちらにあります。プロトコルの説明があるのはこの 2 つのうち一方だけで、それがこのスキルです。

Fabric アダプターおよび Observatory スキルとの境界。 エージェントやサービスが Fabric 環境に参加する方法は、それらが扱います。手順については、fabric-agent-adapter:creating-fabric-agents、fabric-agent-adapter:adapting-projects-to-fabric、fabric-agent-adapter:building-fabric-services（ディスクリプター、ハブ、fabric-service/0.1）を参照してください。エージェントが使う認証情報については、observatory-log:handling-secrets（名前付きのボルトスロットを使い、値そのものは渡しません）を参照してください。このスキルが扱うのは、それらが使用するプロトコル — MCP、A2A、ゲートウェイ、委任 — であり、内容を重ねて説明するのではなく、それらを参照します。

agent-orchestratorとの境界。 そのスキルはモデルプロバイダー間のルーティングと、ループ自体のコンテキスト管理を行います。このスキルがルーティングするのはプロセス間です。両者が関わるのは、次の 2 つの場合に限られます。多数の MCP サーバーをフェデレーションするオーケストレーターにはreferences/mcp-scale.mdが適用され、プロキシを介してそれらの前段に立つオーケストレーターにはreferences/gateway.mdが適用されます。

agent-orchestrator/references/governance.mdとの境界。 そのファイルは、境界を越えてよいか、また統制が適用されたことを証明するために監査レコードに何を記録する必要があるかを判断します。このスキルが説明するのは、境界を越える際にどのようなプロトコルで通信するかです。許可はあちら、プロトコルはこちらです。

一切扱わないもの： 1 つのサーバーで使用するツールセットの設計（どのツールを用意し、どのスキーマや説明を使うか。これは設計上の問題であり、Anthropic のmcp-server-devプラグインがそのためにあります）。プロンプトの文面。スクリプト内の単一の LLM 呼び出し。

周辺領域 — それぞれの結論

エージェントが推測せずに済むよう名前を付け、結論を暗示するのではなく明示します。 2026-08-13 時点の結論。このスキルの参照資料を固定した日付です。状況は変化するため、要注視と記されたものを基盤にする前に、必ず再確認してください。

項目	実際の内容	結論
Agent Skills（agentskills.io）	このファイル自体の記述に使われている、オープンなSKILL.md形式です。もともとはAnthropicのものでしたが、現在は幅広いクライアントに採用されているオープンスタンダードです	採用しますが、ここでは扱いません。 このファミリーではmake-skillで扱います。相互運用性に関係する点が1つあります。MCPにはSkills over MCP拡張があり、サーバーからスキルを提供できます。references/mcp.mdを参照してください
ACP（IBMのAgent Communication Protocol）	かつてのA2A競合プロトコルです	選択肢としては終了です。 2025-08-29にLF AI & Dataの下でA2Aに統合され、開発チームは開発を停止しました。ドキュメントでACPを見かけたら、現在の答えはA2Aです
AGNTCY（Cisco/Outshift → Linux Foundation、2025年7月）	A2Aの競合ではありません。マルチエージェントシステム向けのインフラストラクチャスタックで、OASFによる検出、エージェントID、SLIMメッセージング、オブザーバビリティを扱います。独自の競合プロトコルはアーカイブされました	別の領域です。 多数のエージェントを運用する場合は、IDとオブザーバビリティのために評価してください。A2AやMCPに取って代わるものではありません
AP2（Agent Payments Protocol）	A2A向けのGoogleの決済拡張で、FIDO Allianceのワーキンググループを通じて標準化が進められています。意図を検証可能なデジタル認証情報として署名します。Checkout MandatesとPayment Mandatesがあり、それぞれにOpen段階とClosed段階があります	まだ基盤にせず、動向を注視してください。 明確に開発中であり、本番環境に対応できる段階ではありません。このユーザーがこの購入を承認したことを証明するという課題に適した設計なので、エージェントが将来決済を行う可能性があるなら動向を追ってください
「ChatGPT apps」／OpenAIのプラグイン機能	確認した結果、独立したプロトコルではありません。MCP サーバーに、ワークフロー用のAgent Skillsと、オプションのUIを組み合わせたものです	新たに学ぶことはありません。 MCP サーバーを構築し、ホスト側のパッケージングはホストに任せてください
MCP拡張 — Tasks、MCP Apps、Skills over MCP	コアプロトコルへのオプトイン式の追加機能で、接続ごとにネゴシエーションされます	独自に作る前に確認してください。 長時間実行される作業には、永続的なハンドルによる解決策がすでにあります。references/mcp.mdを参照してください

---

リンクマップ — 読むべきドキュメント

ここにある内容は、実装に使えるほど十分に要約されていません。以下がドキュメントです。

読むもの	内容	URL
MCP 仕様（現行版）	規範的な要件。参照しているリビジョンを必ず確認してください	https://modelcontextprotocol.io/specification/latest
MCP アーキテクチャ	2 つのレイヤー、ステートレス性、実際の JSON を使った探索のやり取り	https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture
MCP サーバーの概念	ツール、リソース、リソーステンプレート、プロンプト — それぞれを誰が制御するか	https://modelcontextprotocol.io/docs/2026-07-28/learn/server-concepts
MCP クライアントの概念	elicitation の 2 つのモードと MRTR パターン、非推奨となったクライアント機能	https://modelcontextprotocol.io/docs/2026-07-28/learn/client-concepts
MCP 非推奨機能一覧	廃止予定の機能と、最も早い削除時期を示す正式な一覧	https://modelcontextprotocol.io/specification/2026-07-28/deprecated
MCP クライアントのベストプラクティス	数値を含む段階的な探索とコードモード	https://modelcontextprotocol.io/docs/2026-07-28/develop/clients/client-best-practices
サーバーの構築／クライアントの構築	SDK レベルの手順	https://modelcontextprotocol.io/docs/2026-07-28/develop/build-server、…/build-client
MCP と Agent Skills	スキルとサーバーの組み合わせ方、および mcp-server-dev プラグイン	https://modelcontextprotocol.io/docs/2026-07-28/develop/build-with-agent-skills
MCP レジストリ — 概要、クイックスタート	MCP レジストリとは何か、および正確な公開手順	https://modelcontextprotocol.io/registry/about、https://modelcontextprotocol.io/registry/quickstart
機械向け MCP ドキュメントのインデックス	エージェントとして調査する場合は、まずこれを取得してください	https://modelcontextprotocol.io/llms.txt
A2A ホームと仕様	v1.0、3 つのバインディング、規範的な仕様の範囲	https://a2a-protocol.org/latest/、https://a2a-protocol.org/latest/specification/
A2A の主要概念／タスクのライフサイクル／探索	オブジェクトモデル、ライフサイクル、well-known URI	https://a2a-protocol.org/latest/topics/key-concepts/、…/life-of-a-task/、…/agent-discovery/
A2A と MCP	両者の役割分担に関する公式見解	https://a2a-protocol.org/latest/topics/a2a-and-mcp/
agentgateway — スタンドアロン、Kubernetes	設定モデルと Gateway API の概要	https://agentgateway.dev/docs/standalone/latest/、https://agentgateway.dev/docs/kubernetes/latest/
ソースリポジトリ	ドキュメントがコードより遅れている場合はこちら	https://github.com/a2aproject/A2A、https://github.com/modelcontextprotocol/modelcontextprotocol、https://github.com/modelcontextprotocol/registry、https://github.com/agentgateway/agentgateway

エージェントの場合は、まず llms.txt を取得してください。 modelcontextprotocol.io と agentgateway.dev はどちらも llms.txt を公開しており、どちらもドキュメントのリリースごとにバージョン管理されています。これを使えば、記憶にあるページではなく、実際に存在するページを見つけられます。

---

チェックリスト — これらのプロトコルを話すものを出荷する際の確認事項

• 対象とするリビジョンを、compatibility、定数、または README の記述に明記している
• クライアント機能を使う前に、非推奨機能一覧を確認した
• バージョン不一致に対処する処理があり、クラッシュしない
• 自分のサーバーからの出力も含め、ツールの出力を信頼できない入力として扱っている
• elicitation フォームで秘密情報を要求していない — それは URL モードの役割です
• 長時間実行される処理では、接続を維持するのではなく、永続的なハンドルを使用している
• フェデレーションを行う場合：名前の衝突を、読み込み順ではなく意図的な方法で解決している
• 公開する場合：自分が所有権を証明できる名前空間を使用している
• 認可を入口だけでなく、各ホップで適用している