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

MCPだけではエージェント間通信に足りない理由を、対等性と拒否・Agent Cardによる能力発見・タスク管理から整理し、A2A v1.0がgRPCを加えMCPがHTTPに留まる理由まで解説します。

更新

白いカードに青のAgent2AgentのA-2-A円形マークとロゴタイプ
目次

はじめに

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

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

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

なぜ2つのプロトコルが必要なのか、MCP だけでは何が足りないのか、そしてなぜ A2A だけが gRPC を加え、MCP は HTTP のままなのか。この記事では、A2A v1.0 と MCP の 2026-07-28 版仕様をもとに、これらの疑問を順に掘り下げていきます。

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

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

MCPA2A
正式名称Model Context ProtocolAgent-to-Agent Protocol
担当領域エージェント ↔ ツール/データソースエージェント ↔ エージェント
関係性クライアント-サーバー（主従）対等・双方向
典型的な操作tools/call, resources/readSendMessage, GetTask
提唱元AnthropicGoogle

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

物流 × 在庫管理の具体例

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

エージェント間は A2A、ツールへは MCP2 つの企業の枠が左右に並ぶ。それぞれの枠にエージェントが 1 つあり、MCP で自社の 3 つのツール群へ下向きに接続する。2 つのエージェントは A2A の双方向リンクで横に結ばれ、企業の境界を越えるのはこのリンクだけで、相手のツールには触れない。物流企業AI配送エージェント配送計画と経路最適化を自律的に判断MCPツール群配送 DBGPS API経路最適化エンジン取引先企業AI在庫エージェント在庫管理と発注判断を自律的に実行MCPツール群在庫 DB発注 API倉庫管理システムエージェント間通信A2A

企業の境界を越えるのは 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:  エージェント ←→ エージェント（対等）

エージェントは自律的に判断する存在です。ツールとして従属させると、「その条件では受けられない」と断る能力といった相手の自律性を無視することになります。

A2A は、この「断る」をプロトコルに組み込んでいます。TASK_STATE_REJECTED は、エージェントがタスクを実行しないと決めたことを表す終了状態で、タスクの作成時点でも、処理を進めた後に続けられない、あるいは続けないと判断した時点でも使えます。

MCP にはこれに相当するものがありません。2026-07-28 版の仕様は呼び出しの向きを明記しています。サーバーから JSON-RPC リクエストを始めることはなく、呼ばれる側は常に答えるだけです。

2. 能力発見の仕組みがない

MCP はツールのスキーマ（入力と出力の型定義）を公開する仕組みはありますが、エージェントの「できること」「ポリシー」「現在の状態」を表現するには不十分です。

A2A では Agent Card という仕組みで、各エージェントが自分の能力やポリシーを /.well-known/agent-card.json として公開します。相手が何をできるか、どういう条件で受け付けるかを事前に発見できます。

3. 非同期タスク管理

MCP のコアはリクエスト-レスポンスです。「配送手配中、3時間後に確定します」のような長時間の処理は、オプトインの Tasks 拡張で扱います。サーバーは結果の代わりにタスクのハンドルを返し、クライアントは tasks/get でポーリングするか、状態通知を購読します。

A2A では、タスクはプロトコルのコアの一部です。タスクは TASK_STATE_SUBMITTED から TASK_STATE_WORKING に進み、TASK_STATE_COMPLETED、TASK_STATE_FAILED、TASK_STATE_CANCELED、TASK_STATE_REJECTED のいずれかで終わります。途中で止まる状態も2つあり、TASK_STATE_INPUT_REQUIRED はエージェントが追加情報を求めている状態、TASK_STATE_AUTH_REQUIRED は認証を待っている状態です。進捗は SSE のストリーミング、Webhook によるプッシュ通知、ポーリングのいずれかで受け取れます。

A2A タスクのライフサイクルA2A タスクの状態遷移図。SUBMITTED から WORKING に進む。WORKING からは、エージェントが追加情報を求める INPUT_REQUIRED か、認証を待つ AUTH_REQUIRED で一時停止でき、どちらからも WORKING に戻る。タスクは COMPLETED、FAILED、CANCELED、REJECTED の4つの終了状態のいずれかで終わり、REJECTED はエージェントがタスクを断ったことを表す。進行中SUBMITTED送信済みWORKING処理中終了状態: タスクはここで終わるCOMPLETED完了FAILED失敗CANCELEDキャンセル済みREJECTEDエージェントがタスクを断った一時停止: WORKING に戻るINPUT_REQUIREDエージェントが追加情報を求めるAUTH_REQUIRED認証を待つ

状態名は TASK_STATE_ プレフィックスを省略しています。エージェント自身が仕事を断ったことを記録するのは REJECTED だけです。

4. 組織間の認証・信頼

組織の境界を越える場合、エージェント同士の身元確認や権限の交渉が必要です。MCP の認可は HTTP トランスポート向けのオプションの OAuth 2.1 フローで、クライアントがリソースオーナーに代わってサーバーを呼び出す形を前提にしています。

A2A は、この要件を Agent Card に載せます。securitySchemes フィールドで API キー、HTTP 認証、OAuth 2、OpenID Connect、相互 TLS のどれを求めるかを宣言します。呼び出す側のエージェントは、最初のリクエストを送る前に相手組織の要件を知ることができます。

まとめると

MCP:  「このツール実行して」→ 結果          （主従関係）
A2A:  「これお願いできる？」→ 交渉 → 合意 → 実行 → 報告  （対等関係）

トランスポートの選択 — gRPC をめぐって分かれた A2A と MCP

どちらのプロトコルも、HTTP 上の JSON-RPC 2.0 と、ストリーミング用の SSE から始まりました。A2A は v0.3 で gRPC をバインディングとして追加し、v1.0 では Protocol Buffers の定義を正規のデータモデルにしました。すべてのバインディングは、このデータモデルを表現できなければなりません。MCP は逆の方向を選び、2026 年のロードマップには「we are not adding more official transports this cycle」（今回のサイクルでは公式トランスポートを追加しない）とあります。

MCP（2026-07-28）A2A（v1.0）
メッセージ形式JSON-RPC 2.0Protocol Buffers のデータモデル。JSON-RPC 2.0、gRPC、HTTP+JSON で運ぶ
ローカル通信stdio—（組織間前提）
リモート通信Streamable HTTP。メッセージごとに HTTP POST を送り、応答は JSON か SSE ストリームで返るHTTP 上の JSON-RPC、HTTP+JSON（REST）、gRPC
gRPC公式トランスポートではない。SEP-1352 で提案中で、カスタムトランスポートとしてのみ使えるv0.3 からオプションのバインディング

MCP のロードマップは、トランスポートを少数に絞るのは設計原則に基づく意図的な判断だと説明しています。このサイクルで力を入れているのは、サーバーが状態を持たずに水平スケールできるようにすることです。

組織間通信で gRPC が標準にならない理由

A2A の主戦場は組織間通信です。社内 LAN のマイクロサービス間通信とは前提が異なります。

技術標準にならない理由
gRPCブラウザから直接呼べない。ファイアウォールやプロキシとの相性が HTTP ほど良くない
WebSocket企業プロキシで切断されがち。常時接続によるサーバーリソース消費。ロードバランサーでのルーティングが複雑。接続断からの再接続ハンドリングが必要

A2A v1.0 は正規の a2a.proto を1つ公開しているので、組織同士で Proto 定義をすり合わせる必要はなくなりました。ただし、ネットワーク面での gRPC の弱点は残ったままです。

A2A が HTTP を手放さずに gRPC を提供する仕組み

Agent Card は、エージェントが話せるバインディングをすべて supportedInterfaces に列挙します。各エントリには protocolBinding（JSONRPC、GRPC、HTTP+JSON）と URL が入っています。クライアントは双方が対応していれば gRPC を使い、それ以外では HTTP を使います。

HTTP のメリット説明
インフラ互換性企業のファイアウォール、プロキシ、ロードバランサーは HTTP 前提で構築済み
エコシステムOAuth 認証、レート制限、監査ログ、API Gateway など成熟したツール群がそのまま使える
発見性Agent Card を /.well-known/agent-card.json として HTTP GET で取得できる
スケーラビリティステートレスで各リクエストが自己完結。スケールアウトが容易
ストリーミングSSE でリアルタイム通知も可能。プロキシも通過できる

組織間の相互運用性を最大化することが設計の最優先事項であり、HTTP はその目的に最も摩擦が少ない選択です。その後の通信にどのバインディングを使う場合でも、Agent Card 自体は HTTP で取得します。

同一組織内でネットワークを双方が管理しているなら、エージェントは JSON-RPC と並べて gRPC も公開できます。対応しているクライアントは、そちらの速い経路を使えます。

まとめ

観点MCPA2A
役割エージェントがツール/データにアクセスエージェント同士が通信・交渉
関係主従（client → server）対等（双方向）。タスクを拒否できる
トランスポートStreamable HTTP / stdio。gRPC はカスタムトランスポートのみJSON-RPC、HTTP+JSON、gRPC。Agent Card に列挙
能力発見ツールスキーマ（入出力の型定義）Agent Card（/.well-known/agent-card.json）
メッセージ形式JSON-RPC 2.0Protocol Buffers のデータモデル。JSON-RPC バインディングでは JSON-RPC 2.0
長時間の処理オプトインの Tasks 拡張タスクのライフサイクルがコアに含まれる
  • MCP と A2A は競合ではなく相補的。MCP がエージェントの「手と目」なら、A2A は「口」
  • エージェントはツールではない。自律的に判断する存在だからこそ、ツール用プロトコル（MCP）とは別にエージェント用プロトコル（A2A）が必要
  • HTTP は互換性のための基盤で、A2A は速度のために gRPC を選択肢に加えた。MCP は gRPC を公式トランスポートの外に置いている

マルチエージェントシステムの設計では、「どのエージェントにどのツールを MCP で接続するか」と「どのエージェント間を A2A で連携させるか」を分けて考えることが重要です。

参考リンク

この記事をシェア

その他

その他