# A2A と MCP は何が違う？エージェント間通信プロトコルの設計思想を整理してみた

> MCPだけではエージェント間通信に足りない理由を、対等性・Agent Cardによる能力発見・非同期タスク管理から整理し、両プロトコルがHTTPを選んだ理由まで解説します。

- Source: https://oharu121.com/ja/blog/a2a-mcp-complementary-agent-protocol-design/
- Published: 2026-07-13T12:00:00+09:00
- Tags: MCP, AIエージェント, 生成AI

---
## はじめに

「エージェント同士を連携させたいけど、MCP でつなげばいいのでは？」

AIエージェントの開発が進む中、こんな疑問を持ったことはないでしょうか。MCP（Model Context Protocol）がツール連携の標準として広がる一方で、Google が提唱する A2A（Agent-to-Agent）プロトコルという別の規格も登場しています。

先に結論を書くと、両者は守備範囲が違います。MCP はエージェントの「手と目」であり、A2A はその「口」です。ツール用のプロトコルがエージェント用の代わりにならないのは、ツールは依頼を断れないのに対し、エージェントは断れるからです。

なぜ2つのプロトコルが必要なのか、MCP だけでは何が足りないのか、そしてなぜどちらも HTTP を基盤に選んだのか。この記事では、これらの疑問を順に掘り下げていきます。

## A2A と MCP — それぞれの守備範囲

まず、両者の役割を整理します。

| | MCP | A2A |
|---|---|---|
| **正式名称** | Model Context Protocol | Agent-to-Agent Protocol |
| **担当領域** | エージェント ↔ ツール/データソース | エージェント ↔ エージェント |
| **関係性** | クライアント-サーバー（主従） | 対等・双方向 |
| **典型的な操作** | `tools/call`, `resources/read` | `tasks/send`, `tasks/get` |
| **提唱元** | Anthropic | Google |

一言でまとめると、**MCP はエージェントの「手と目」**（ツールを使う・データを読む）であり、**A2A はエージェントの「口」**（他のエージェントと会話・交渉する）です。

### 物流 × 在庫管理の具体例

組織をまたいだエージェント連携の例で見てみましょう。

*Figure — Architecture: 企業の境界を越えるのは A2A のリンクだけで、どちらのエージェントも相手のツールには触れません。*

1. **在庫エージェント**が MCP で在庫 DB を照会 →「商品 X が残り10個、補充必要」と判断
2. 在庫エージェントが **A2A で配送エージェントに依頼** →「商品 X 500個、倉庫 A へ明日配送可能？」
3. **配送エージェント**が MCP で GPS API やルート最適化ツールを呼び出し、空き枠を確認
4. 配送エージェントが **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 で連携させるか」を分けて考えることが重要です。