この記事をシェア
「AIエージェントのプロトコル」と聞いてMCPを思い浮かべる方は多いでしょう。しかし2026年の今、マルチエージェント構成の設計現場でMCPと並んで必ず名前が挙がるのがA2A（Agent2Agent）です。両者は競合する規格ではなく、担当するレイヤーがまったく違うプロトコルです。MCPが「エージェントと道具をつなぐUSBポート」なら、A2Aは「エージェント同士の電話回線」。本記事では、この2つのプロトコルの役割の違いを図解で整理し、実務でどう組み合わせるべきか、そして変化の速い標準化競争にどう備えるべきかを解説します。
1. 混乱の原因：「プロトコル」という言葉の広さ
A2AとMCPが混同されやすい最大の理由は、どちらも「AIエージェントのためのオープンなプロトコル」と紹介されるからです。しかし、両者が標準化しようとしている通信の相手が違います。
- MCP（Model Context Protocol）：エージェント ↔ ツール／データソース間の接続を標準化する
- A2A（Agent2Agent Protocol）：エージェント ↔ エージェント間の対話を標準化する
つまりMCPは「1体のエージェントが外部の道具や情報をどう使うか」という縦方向の接続を、A2Aは「独立したエージェント同士がどう仕事を依頼し合うか」という横方向の接続を担当します。これを1枚の図にすると次のようになります。
図：MCP＝縦の接続（エージェント↔道具）、A2A＝横の接続（エージェント↔エージェント）
この図さえ頭に入れば、「A2AとMCPのどちらを使うべきか？」という問いが、そもそも比較として成立していないことが分かります。用途が重ならないので、置き換え関係にはなりません。迷ったときは「通信の相手は道具か、それとも別のエージェントか」を考えれば十分です。
2. MCPのおさらい — エージェントと道具をつなぐUSB
MCPはAnthropicが2024年11月に公開したオープンプロトコルで、LLMアプリケーションに外部の機能・情報を提供する側（MCPサーバー）と、それを利用する側（MCPクライアント＝エージェントやチャットアプリ）の間の規約を定めます。提供できるものは大きく3要素です。
- ツール（Tools）：エージェントが実行できる操作。「請求書を作成する」「DBを検索する」など
- リソース（Resources）：エージェントが読み取れるデータ。ファイル、DBレコードなど
- プロンプト（Prompts）：再利用可能な指示テンプレート
「USBポート」の比喩どおり、MCPサーバーを1つ作れば、Claude、各種IDE、自作エージェントなどどのMCP対応クライアントからでも同じ道具が使えるのが最大の価値です。MCPの実装方法や社内ツールをMCP化する際の設計指針は、過去記事「社内業務ツールをMCP化する — Hello Worldの次の一歩」で詳しく解説しているので、本記事ではこれ以上の深掘りは譲ります。
3. A2Aの仕組み — Agent Cardとタスクのライフサイクル
A2A（Agent2Agent Protocol）は、Googleが2025年4月に発表し、同年6月にLinux Foundationへ移管されたオープンプロトコルです。2026年にはバージョン1.0に到達し、150を超える組織が支持を表明、Google・Microsoft・AWSの各プラットフォームにも統合が進んでいます。ベンダー中立の標準として、エージェント間連携の本命と見られる存在になりました。
3-1. Agent Card：エージェントの「名刺」
A2Aの出発点はAgent Cardです。各エージェントは「自分は何ができるか」「どのエンドポイントで話せるか」「どんな認証が必要か」を記したJSONを公開します。他のエージェントはこれを読んで、仕事を依頼できる相手かどうかを判断します。
{
"name": "accounting-agent",
"description": "請求書の作成・送付・入金確認を行う経理エージェント",
"url": "https://agents.example.com/accounting",
"skills": [
{
"id": "create-invoice",
"name": "請求書作成",
"description": "取引先情報と明細から請求書を作成して送付する"
}
],
"capabilities": { "streaming": true, "pushNotifications": true },
"securitySchemes": { "bearer": { "type": "http", "scheme": "bearer" } }
}
人間社会の名刺交換と同じで、相手の内部実装（どのLLMを使っているか、どんなフレームワークか）を知らなくても連携できるのがポイントです。A2Aではエージェントは互いに「不透明（opaque）」な存在として扱われ、公開された能力だけを頼りに協調します。
3-2. タスクのライフサイクル：長時間・非同期が前提
MCPのツール呼び出しが「関数を呼んで結果をもらう」という同期的な発想であるのに対し、A2Aの中心概念であるタスク（Task）は、人間の仕事の依頼に近い設計です。タスクは次のような状態を遷移します。
submitted：依頼を受け付けたworking：処理中（進捗を逐次通知できる）input-required：依頼元に追加情報を求めて一時停止completed/failed/canceled：完了・失敗・キャンセル
注目すべきはinput-requiredの存在です。「請求書を作りたいが支払期日が未指定なので教えてほしい」といった対話の往復がプロトコルレベルで定義されています。また、数分〜数時間かかる仕事を前提に、SSE（Server-Sent Events）によるストリーミング通知や、依頼元がオフラインでも結果を受け取れるプッシュ通知の仕組みが最初から組み込まれています。この「長時間・非同期・対話あり」という性質こそ、単発のツール呼び出しであるMCPとの決定的な設計思想の違いです。
3-3. 比較表：MCPとA2Aの設計思想
| 観点 | MCP | A2A |
|---|---|---|
| 接続の相手 | ツール・データソース | 別のエージェント |
| 比喩 | USBポート（道具の規格化） | 電話回線（対話の規格化） |
| やりとりの単位 | ツール呼び出し（同期中心） | タスク（非同期・長時間前提） |
| 相手の発見 | クライアント設定に登録 | Agent Cardによる能力公開 |
| 途中の対話 | 基本なし（結果を返すのみ） | input-requiredで追加質問が可能 |
| 主導した組織 | Anthropic（2024年11月〜） | Google → Linux Foundation（2025年6月〜） |
4. 使い分けの実例シナリオ
4-1. 営業エージェントと経理エージェントの連携
冒頭の図に登場した2体のエージェントで、具体的な業務フローを追ってみましょう。
- 営業支援エージェントが商談成立を検知し、CRMから取引先情報と契約金額を取得する（MCP：縦の接続）
- 営業支援エージェントが経理エージェントのAgent Cardを確認し、「この取引の請求書を作成・送付してほしい」とタスクを依頼する（A2A：横の接続）
- 経理エージェントは支払サイトが未指定だったため
input-requiredで確認を返し、回答を受けて処理を再開する（A2A） - 経理エージェントが会計SaaSのAPIを操作して請求書を発行する（MCP）
- 完了通知が営業支援エージェントに届き、タスクが
completedになる（A2A）
このように、組織の中で「依頼」が流れる部分はA2A、各エージェントが「道具」を使う部分はMCPという役割分担が自然に決まります。部署間の依頼は電話で、手元の作業は自分の道具で、という人間の働き方とまったく同じ構図です。
4-2. 現実的な線引き：1つのアプリで完結するならA2Aは過剰
ここで実務上の重要な注意点があります。自分が管理する1つのシステム内でエージェントを複数動かすだけなら、A2Aはたいてい過剰です。同一プロセスや同一チーム管理下のマルチエージェント構成であれば、フレームワーク内蔵のオーケストレーション（サブエージェント呼び出しやワークフロー機能）の方がシンプルで高速です。実際、私が「7つのAIエージェントを並列稼働させた話」や「Claude Multi Orchestrator」で紹介した構成も、プロトコルなしのプロセス内連携で十分に機能しています。
A2Aが本領を発揮するのは、管理主体・技術スタック・組織の境界をまたぐときです。
- 別部署・別会社が運用するエージェントに仕事を依頼したい
- LangGraph製・ADK製・自社フレームワーク製など、実装がバラバラのエージェントを連携させたい
- SaaSベンダーが提供するエージェントと自社エージェントを対話させたい
逆に言えば、こうした「境界」が登場するまでは、A2A導入を急ぐ必要はありません。マイクロサービスと同じで、分散させること自体が目的化すると運用コストだけが増えます。
5. 標準化競争の行方と今から備えること
エージェント連携のプロトコルはA2Aだけではありません。IBM系のACP（Agent Communication Protocol）や研究コミュニティ発のANPなど複数の規格が提案され、統合や淘汰が続いています。A2AはLinux Foundation移管とバージョン1.0到達で最有力候補になりましたが、仕様は今も速いペースで拡張されており（2026年5月の1.0.1では拡張メカニズムが追加されました）、数年後の勢力図を断言できる段階ではありません。
では、いま何に投資すべきか。私は次の3点をおすすめします。
5-1. ツール層はMCPで固めてよい
エージェント↔ツールの縦の接続は、MCPが事実上の標準として定着しました。社内APIやデータソースのMCP化は、どのエージェントフレームワークを採用しても無駄になりにくい投資です。
5-2. エージェント間連携は「境界」ができてから、疎結合に
エージェント同士の横の接続は、必要になった時点でA2Aを第一候補として検討しつつ、特定プロトコルへの依存を1か所に閉じ込める設計にしておきましょう。具体的には、エージェント本体のロジックと通信アダプタを分離しておけば、将来プロトコルが変わってもアダプタの差し替えで済みます。
5-3. 「能力の記述」を資産化する
Agent Cardのような「このエージェントは何ができて、何を入力に取り、何を返すか」という能力記述は、どのプロトコルが勝っても必要になる情報です。エージェントを作る際に能力・入出力・制約をドキュメントとして整備しておけば、将来どの規格へも低コストで対応できます。
まとめ
- MCPは縦の接続：エージェントとツール／データをつなぐ。単発・同期中心の「道具の規格」
- A2Aは横の接続：エージェント同士をつなぐ。Agent Cardで能力を公開し、長時間・非同期のタスクを依頼し合う「対話の規格」
- 両者は競合せず、組み合わせて使うもの。依頼はA2A、作業はMCP
- 1システム内で完結するならA2Aは不要。管理主体や組織の境界をまたぐときが導入の合図
- 標準化競争はまだ動く。ツール層はMCPで固め、エージェント間連携は疎結合に保って備える
マルチエージェントの世界は「1体の万能エージェント」から「得意分野を持つエージェントたちの分業」へと確実に進んでいます。そのとき土台になるのが、今回整理した2つのプロトコルです。まずは足元のツールのMCP化から始めつつ、横の接続が必要になる日に備えておきましょう。
