ディスカバリーコールのおおむね2回に1回は、こう尋ねられます。「A2A と MCP、どちらに標準化すべきですか?」
質問の前提が間違っています。両者は競合ではありません。異なる層で異なる問題を解いており、健全なエージェントシステムは両方を使います。
MCP の目的
MCP（Model Context Protocol）は ツールサーフェス の標準です。これが答えるのは、LLM ベースのエージェントが学習に含まれないツールをどう発見・呼び出すか、という問いです。ドキュメント検索、データベースクエリ、カレンダー API、社内サービス。各ツールが MCP サーバを公開し、エージェントが接続し、機能を一覧し、呼び出します。
形は 1つのエージェント ↔ 多数のツール です。ツールは受動的で、いつ呼ぶかはエージェントが決めます。
MCP が提供するもの: スキーマ発見、型付きパラメータ、構造化された戻り値、認証境界、サンドボックス。本質的には、エージェント的クライアント向けにチューニングされた RPC 標準です。
A2A の目的
A2A（Agent-to-Agent プロトコル群。Google の A2A、AGNTCY、その他いくつかあります）は エージェント間協調 の標準です。これが答えるのは、複数の半自律エージェントがどう協調し、サブタスクを受け渡し、結果を集約するか、という問いです。
形は エージェント ↔ エージェント、状態あり です。両側がそれぞれの推論ループを持ちます。ハンドオフにはコンテキスト、中間結果、時にはサブタスクの所有権が含まれます。
A2A が提供するもの: エージェントカード（機能の広告）、タスクライフサイクル、メッセージパッシング、オプションのストリーミングと human-in-the-loop。RPC ではなく、型付きアクターシステムに近いものです。
なぜ混同されるのか
どちらも、構造化ペイロードを持つプロトコル越しに、エージェントが何かと話すという形をとります。どちらも JSON を生成します。どちらもクライアントとサーバの役割を持ちます。3万フィート上空から見れば同じものに見えます。
しかし、両側の自律性のレベルが本当の違いです。
- MCP サーバ: 受動的。呼び出しに応答する。自分の推論ループを持たない。
- A2A エージェント: 能動的。タスクを断る、代替案を提案する、別のエージェントにハンドオフする、明確化を要求する、ができる。
相手が「データベースからこの行を取ってくる」なら MCP です。相手が「この異常を調査して何が見つかったか教えてくれ」なら A2A です。
実際に機能するアーキテクチャ
我々が出荷したマルチエージェントシステムでは、すべて次のような構造になります。
- スタックの最上段: オーケストレータ（これ自体がエージェントであることも多い）がユーザーリクエストを専門エージェントにルーティングする。
- 専門エージェントは A2A で通信する。ハンドオフはコンテキストを保持し、スーパーバイザがタスク状態を追跡する。
- 専門エージェントは MCP でツールを使う。検索エージェントはベクター DB への MCP 接続と全文検索サービスへの MCP 接続を持つ。「ops エージェント」はチケットシステムへの MCP 接続を持つ。
A2A はエージェントが 協調する 方法です。MCP は各エージェントが 行動する 方法です。
実務的な結論
まず MCP を採用してください。最も差し迫った問題（ツールと話すこと）を解決し、今日時点でエコシステムが広く（ほとんどの LLM プロバイダが MCP をネイティブサポート）、「アドホックなツール呼び出し」から MCP への移行は素直です。
仕事を受け渡す必要のあるエージェントが 2つ以上 になったら A2A を採用してください。エージェント1つ + ツール多数のシステムでは A2A はやり過ぎです。誰とも協調していません。最初のエージェントと話す必要のある2つ目の専門エージェントを追加した瞬間、A2A は元を取り始めます。
選ばないでください。重ねるのです。