A2A と MCP は何が違う？エージェント間通信プロトコルの設計思想を整理してみた
はじめに
「エージェント同士を連携させたいけど、MCP でつなげばいいのでは？」
AIエージェントの開発が進む中、こんな疑問を持ったことはないでしょうか。MCP（Model Context Protocol）がツール連携の標準として広がる一方で、Google が提唱する A2A（Agent-to-Agent）プロトコルという別の規格も登場しています。
なぜ2つのプロトコルが必要なのか？MCP だけでは何が足りないのか？そしてなぜどちらも HTTP を基盤に選んだのか？——この記事では、これらの疑問を順に掘り下げていきます。
A2A と MCP — それぞれの守備範囲
まず、両者の役割を整理します。
| MCP | A2A | |
|---|---|---|
| 正式名称 | Model Context Protocol | Agent-to-Agent Protocol |
| 担当領域 | エージェント ↔ ツール/データソース | エージェント ↔ エージェント |
| 関係性 | クライアント-サーバー（主従） | 対等・双方向 |
| 典型的な操作 | tools/call, resources/read |
tasks/send, tasks/get |
| 提唱元 | Anthropic |
一言でまとめると、MCP はエージェントの「手と目」（ツールを使う・データを読む）であり、A2A はエージェントの「口」（他のエージェントと会話・交渉する）です。
物流 × 在庫管理の具体例
組織をまたいだエージェント連携の例で見てみましょう。
- 在庫エージェントが MCP で在庫 DB を照会 →「商品 X が残り10個、補充必要」と判断
- 在庫エージェントが A2A で配送エージェントに依頼 →「商品 X 500個、倉庫 A へ明日配送可能？」
- 配送エージェントが MCP で GPS API やルート最適化ツールを呼び出し、空き枠を確認
- 配送エージェントが A2A で回答 →「明日14時に配送可能。トラック B-12 割当済」
このように、ツール操作（MCP）とエージェント間の交渉（A2A）は明確に役割が分かれています。
なぜ MCP だけではエージェント間通信に不十分なのか
「相手のエージェントを MCP のツールとして登録すればいいのでは？」という発想は自然です。しかし、いくつかの根本的な問題があります。
1. 対等性の欠如
MCP はクライアント-サーバーモデルです。片方がクライアント（呼び出す側）、もう片方がサーバー（呼び出される側）になります。
MCP: エージェント(client) → 相手エージェント(server=ツール扱い)
A2A: エージェント ←→ エージェント（対等）
エージェントは自律的に判断する存在です。ツールとして従属させると、相手の自律性——たとえば「その条件では受けられない」と断る能力——を無視することになります。
2. 能力発見の仕組みがない
MCP はツールのスキーマ（入力と出力の型定義）を公開する仕組みはありますが、エージェントの「できること」「ポリシー」「現在の状態」を表現するには不十分です。
A2A では Agent Card という仕組みで、各エージェントが自分の能力やポリシーを /.well-known/agent.json として公開します。相手が何をできるか、どういう条件で受け付けるかを事前に発見できます。
3. 非同期タスク管理
MCP は基本的に同期的なリクエスト-レスポンスです。「配送手配中、3時間後に確定します」のような長時間タスクの状態管理には向いていません。
A2A はタスクの状態遷移（submitted → working → input-required → completed / failed）を追跡する仕組みが組み込まれており、SSE やプッシュ通知で進捗を受け取れます。input-required は、エージェントが処理を進めるために追加情報を要求している状態です。
4. 組織間の認証・信頼
組織の境界を越える場合、エージェント同士の身元確認や権限の交渉が必要です。MCP にはこうした組織間認証の仕組みが想定されていません。
まとめると
MCP: 「このツール実行して」→ 結果 （主従関係）
A2A: 「これお願いできる？」→ 交渉 → 合意 → 実行 → 報告 （対等関係）
トランスポート層の設計選択 — なぜ HTTP なのか
興味深いことに、MCP も A2A もトランスポート層の選択が似ています。
| MCP | A2A | |
|---|---|---|
| メッセージ形式 | JSON-RPC 2.0 | JSON-RPC 2.0 |
| ローカル通信 | stdio | —（組織間前提） |
| リモート通信 | Streamable HTTP（旧: HTTP + SSE） | HTTP + SSE |
| gRPC | 不使用 | 不使用 |
どちらも gRPC を採用していません。高速なバイナリ通信を提供する gRPC がありながら、なぜ HTTP + JSON を選んだのでしょうか。
gRPC / WebSocket を選ばなかった理由
A2A の主戦場は組織間通信です。社内 LAN のマイクロサービス間通信とは前提が異なります。
| 技術 | 不採用の理由 |
|---|---|
| gRPC | ブラウザから直接呼べない。Proto 定義の共有が組織間では煩雑。ファイアウォールやプロキシとの相性が HTTP ほど良くない |
| WebSocket | 企業プロキシで切断されがち。常時接続によるサーバーリソース消費。ロードバランサーでのルーティングが複雑。接続断からの再接続ハンドリングが必要 |
HTTP + SSE が選ばれた理由
| メリット | 説明 |
|---|---|
| インフラ互換性 | 企業のファイアウォール、プロキシ、ロードバランサーは HTTP 前提で構築済み |
| エコシステム | OAuth 認証、レート制限、監査ログ、API Gateway など成熟したツール群がそのまま使える |
| 発見性 | Agent Card を /.well-known/agent.json として HTTP GET で取得できる |
| スケーラビリティ | ステートレスで各リクエストが自己完結。スケールアウトが容易 |
| ストリーミング | SSE でリアルタイム通知も可能。プロキシも通過できる |
組織間の相互運用性を最大化することが設計の最優先事項であり、HTTP はその目的に最も摩擦が少ない選択です。
なお、同一組織内のリアルタイムなエージェント通信であれば、gRPC や WebSocket の方が適切な場面もあります。プロトコルの選択はユースケース次第です。
まとめ
| 観点 | MCP | A2A |
|---|---|---|
| 役割 | エージェントがツール/データにアクセス | エージェント同士が通信・交渉 |
| 関係 | 主従（client → server） | 対等（双方向） |
| トランスポート | Streamable HTTP / stdio | HTTP + SSE |
| 能力発見 | ツールスキーマ（入出力の型定義） | Agent Card（/.well-known/agent.json） |
| メッセージ形式 | JSON-RPC 2.0 | JSON-RPC 2.0 |
- MCP と A2A は競合ではなく相補的。MCP がエージェントの「手と目」なら、A2A は「口」
- エージェントはツールではない。自律的に判断する存在だからこそ、ツール用プロトコル（MCP）とは別にエージェント用プロトコル（A2A）が必要
- HTTP が選ばれたのは速度ではなく互換性。組織間通信というユースケースにおいて、既存インフラとの摩擦を最小化する設計判断
マルチエージェントシステムの設計では、「どのエージェントにどのツールを MCP で接続するか」と「どのエージェント間を A2A で連携させるか」を分けて考えることが重要です。
