AIエージェント向けプロトコルが次々と登場し、名前だけ並ぶと競合のように見えます。実際には多くが別のレイヤーを担っており、設計の勘所は「どの層を今採用するか」と「まだ空いているtransport層をどう扱うか」にあります。
この記事では、各プロトコルの役割分担と、HTTPでは解けないtransport問題、実務での設計判断の指針を整理します。
この記事でわかること
- MCP・A2A・ANPがそれぞれ解く問題の違い
- ACPがA2Aに統合された経緯と現在地
- transport層が未解決である理由
- アーキテクチャを組むときの層分離の考え方
プロトコル乱立は「層の違い」で整理できる
過去18か月で、MCP（Anthropic、2024年後半）、ACP（IBM Research、2025年3月）、A2A（Google、2025年4月）、ANP（コミュニティ主導）の4つが相次いで公開されました。W3CのAI Agent Protocolコミュニティグループが標準化トラックを開き、IETFにもエージェント向けtransportのInternet-Draftが提出されています。
混乱の多くは、各プロトコルが「AIエージェント通信の標準」と紹介される一方で、どの通信面を指すのかが曖昧なことに起因します。分散コンピューティングの歴史では、CORBAやSOAPが乱立したあとRESTがHTTPネイティブさで収束したように、エージェント領域もまず層ごとに整理する必要があります。
MCPはツール呼び出し層を担う
MCP（Model Context Protocol）は、AIアプリケーションと外部システムをつなぐオープン標準です。モデルがサーバーが公開する機能を発見し、呼び出し、結果を解釈するまでの型付きRPC契約を定義します。公式ドキュメントでは「AIアプリケーション向けのUSB-C」に例えられています。
Linux Foundationの調査では、2026年4月時点で公開MCPサーバーが1万以上、Python SDKの月間ダウンロードが1億6400万回に達したと報じられています（参考）。Anthropicは2025年12月にMCPをAgentic AI Foundation（AAIF）へ寄贈し、Claude、ChatGPT、VS Code、Cursorなど主要プラットフォームが採用しています。ツール接続の標準化は実質的に収束段階に入っています。
A2Aはエージェント間のタスク調整を担う
A2A（Agent2Agent）は、異なるフレームワークやベンダーで作られたエージェント同士が協調するためのプロトコルです。GitHub上の公式READMEによると、JSON-RPC 2.0 over HTTP(S)をベースに、Agent Cardによる能力公開、同期・ストリーミング（SSE）・非同期プッシュの3モードを備えます。
MCPが「エージェントとツール」の接続を担うのに対し、A2Aは「エージェントとエージェント」のタスク委譲とライフサイクル管理を担います。Googleは2025年6月にA2AをLinux Foundationへ寄贈し、2026年3月にはv1.0がリリースされました。エンタープライズ向けのマルチエージェント連携では、ここが主戦場になっています。
ACPはA2Aへ統合された
ACP（Agent Communication Protocol）は、IBM Researchが2025年3月にBeeAI向けに公開した、軽量なエージェント間メッセージ形式でした。RESTベースでシンプルなメッセージ交換に特化し、A2Aのフルなタスク調整が不要な場面向けに設計されていました。
2025年8月、Linux FoundationはACPをA2Aへ正式統合すると発表しました（参考）。ACPチームは単独開発を終え、技術と知見をA2Aへ移管しています。新規プロジェクトはA2Aを採用し、既存のACP実装は移行ガイドに沿ってA2Aへ移すのが現実的な選択です。
ANPは発見とアイデンティティを担う
ANP（Agent Network Protocol）は、W3Cの分散識別子（DID）を基盤にした発見・認証プロトコルです。did:wba（Web-Based Agent）方式でエージェントの身元を検証し、JSON-LDグラフで能力を記述します。中央レジストリに依存しない、分散型エージェントマーケットプレイスを想定した設計です。
W3C AI Agent Protocolコミュニティグループの白書でもANPが参照実装として位置づけられており、エージェント同士が初対面で身元を確認する場面に向いています。エンタープライズ内の閉じた連携より、オープンなエージェントネットワークを見据えた層です。
4層で見ると競合ではなく補完関係になる
整理すると、次のようなスタックが形になりつつあります。
- ツール呼び出し：MCP
- タスク調整：A2A（ACPの機能を統合）
- 発見・アイデンティティ：ANPまたは簡易レジストリ
いずれもHTTP上で動く設計が主流です。研究チームやAPIプロバイダー、エンタープライズソフトウェア企業がHTTPを前提に開発してきた結果であり、デモや社内導入では十分機能します。課題は、アプリケーション層の意味論が固まりつつある一方で、エージェント同士がどう接続するかは別問題だという点です。
transport層が残す課題
HTTPは「到達可能なサーバー」が存在することを前提にします。ネットワーク機器の88%がNAT（ネットワークアドレス変換）の内側にあり、NATの背後には外部から直接到達できるサーバーがありません（参考）。クラウド、家庭内ネットワーク、エッジにまたがるエージェント群がピア間でタスクを直接ルーティングしたい場合、すべての通信をリレー経由にする必要が生じます。レイテンシ、コスト、単一障害点が増えます。
MCP、A2A、ACP、ANPのいずれも、このセッション層（OSIモデルの第5層）相当の問題には手を入れていません。アプリケーション層のプロトコルは「何を言うか」を定義し、「どう接続するか」は定義しません。
transportを埋める技術候補
解決のための技術要素自体はすでに存在します。STUN（Session Traversal Utilities for NAT）を使ったUDPホールパンチは、おおよそ70%のネットワーク構成でNAT越えを実現します。X25519 Diffie-HellmanとAES-256-GCMでトンネル暗号化を行い、QUIC（RFC 9000）やカスタムUDPプロトコルでTCPのヘッドオブラインブロッキングを避ける構成も、WireGuardやWebRTCと同系統の手法です。
エージェント文脈で新たな要件となるのは、能力ベースのルーティングです。ホスト名ではなく「リアルタイムの為替データを持つピアはどこか」と問い合わせ、応答する仕組みが必要になります。DNSに近いが、サービスレジストリに近い設計が求められます。
Pilot Protocol
Pilot Protocolは、IETFにInternet-Draft（draft-teodor-pilot-protocol-01、2026年4月）として公開されたオーバーレイネットワークです。自律AIエージェントに仮想アドレス、ポート多重化、信頼性のあるストリーム、NAT越え、暗号化トンネルを提供し、A2AやMCPの下位層として位置づけられています。仕様書は「TCP/IPがHTTPの下にあるのと同様に、Pilotがアプリケーション層プロトコルの下にある」と説明しています。
NAT越えは3段階で行います。beaconサーバーによるSTUN的なエンドポイント発見、制限付きコーンNAT向けのホールパンチ調整、対称NAT向けのリレーフォールバックです。直接接続に失敗してもアプリケーション層は同じインターフェースを使える設計になっています。
libp2p
libp2pは、ピア発見・NAT越え・暗号化通信の実績ある基盤ライブラリです。Pilot Protocolのドラフトでも既存プロトコルとの関係として言及されています。自前でtransport層を組む場合の選択肢の一つになります。
収束の見通しと設計判断
HTTPベースのMCPとA2Aは安定版に向かっています。今後12か月は、セキュリティ強化、ステートレスMCPサーバーによる水平スケール、A2Aのフェデレーション改善といった実運用の硬化が中心になる見込みです。一方、transport層はアプリケーション層より18〜24か月遅れており、IETFとW3Cの正式標準は2027〜2028年頃が想定されます（参考）。
実務での指針は層分離です。MCPによるツール接続は低リスクで採用できます。マルチエージェント連携にはA2Aを選び、プロトコル進化は見込んでおきます。transport層は、早期実装を評価するか、カスタム実装を入れるなら将来の置き換えを前提にします。マイクロサービス時代に観測性やサーキットブレーカーを後付けした苦労と同様、アプリケーション意味論（MCP・A2A）とtransportを最初から分けておくコストは小さく、後から分離するコストは大きいです。
エージェント通信の標準化は、ツール呼び出しとタスク調整で大きく前進しました。次の焦点は、NATの壁を越えてエージェント同士を直接つなぐtransport層に移っています。