A2A vs MCP：エージェント通信のための正しいプロトコルの選択

ほとんどの本番エージェントシステムは 1 つではなく 2 つのプロトコルを必要とします。Model Context Protocol (MCP) はエージェントにツールやデータソースへのアクセスを提供します — NetSuite レコード、HubSpot 連絡先、サプライヤーカタログ、Redshift クエリ。Agent2Agent Protocol (A2A) はエージェントが他のエージェントに作業を委譲する方法を提供します — 引き合いエージェントがカタログエージェントに代替部品を依頼する、調達エージェントがコンプライアンスエージェントに GMP 認証の検証を依頼する。この 2 つを混同すると脆弱なアーキテクチャにつながります：データベースを呼ぶために A2A を使ったり、2 つの独立したエージェントを調整するために MCP を使ったりすると、プロトコル自身の設計と競合するシステムが生まれます。

2026 年 8 月 1 日、OpenAI は Astra を確認しました — 長時間実行されるマルチエージェントタスクのために明示的に設計された、次の主要なモデルファミリーです。内部バージョンは数学と理論計算機科学における10の未解決問題を解決し、総トークンコストは約 $2,000 でした。Astra は拡張期間にわたって複数のエージェントを調整します。これは A2A（エージェント間委譲）と MCP（エージェントからツールへのアクセス）が連携する必要があるまさにそのパターンです。モデルレイヤーは今や 2 プロトコルパターンのために構築されています。

この記事は、A2A と MCP のどちらかを選ぶ、あるいはより一般的にはマルチエージェントシステムでそれぞれをどこに配置するかを決めるチーム向けの意思決定フレームワークです。各プロトコルの基礎を理解していることを前提とします。統合のウォークスルーが必要な場合は、A2A Hermes Agent ブリッジ と MCP + A2A プロトコルスタックの概要 が実装側をカバーしています。

1 行での区別

MCP はエージェントをツールに接続します。A2A はエージェントをエージェントに接続します。 MCP はツール呼び出しプロトコルです — エージェントがリソースを要求するか関数を呼び出すと、サーバーが構造化データで応答します。A2A はタスク委譲プロトコルです — エージェントが別のエージェントに作業単位を送信し、ストリーミング出力を受け取り、状態マシンを通じてタスクを追跡します。150 以上の A2A 組織と 10,000 以上の MCP サーバーで確認された本番パターンは：エージェント間は A2A、エージェントとツール間は MCP です。

各プロトコルが適合する場所

次元	MCP	A2A
接続対象	エージェント → ツール、データソース、API	エージェント → エージェント
作業単位	ツール呼び出し（リクエスト/レスポンス）	タスク（ステートフルライフサイクル）
プロトコル主体	Anthropic（オープン仕様、2026-07-28 最終版）	Google（オープン仕様、Linux Foundation、150 以上の組織）
トランスポート	STDIO、Streamable HTTP（SSE 廃止予定、12 か月 Sunset）	JSON-RPC 2.0 over HTTP、SSE ストリーミング
ディスカバリー	サーバーがツールを登録、クライアントが発見	/.well-known/agent-card.json の Agent Card
状態	ステートレス（2026-07-28 仕様）、状態はクライアントに存在	ステートフルタスクマシン：submitted → working → input-required → completed/failed/canceled
ストリーミング	ツール結果は単一レスポンス	message/stream によるリアルタイムトークンとアーティファクト配信
ヒューマンインザループ	第一級概念ではない	INPUT_REQUIRED は第一級タスク状態
認証	サーバーごと、仕様では OAuth 2.1、実践ではベアラートークン	エージェントごと、Agent Card が認証スキームを宣言、ゲートウェイが適用を処理
採用	10,000 以上のサーバー、4 つの Tier 1 SDK（TypeScript、Python、Go、C#）	150 以上の組織、Linux Foundation ガバナンス

この表はほとんどのチームが最初に尋ねる質問に答えます：あなたの統合が「エージェントが顧客レコードのために NetSuite を照会する必要がある」場合、それは MCP です。あなたの統合が「調達エージェントが価格エージェントに 3 つのサプライヤー見積もりを評価して推奨を返すよう依頼する」場合、それは A2A です。区別は、相手側に独自の推論があるか、それとも構造化クエリに応答するデータソースであるかです。

分担を決定する 5 つの質問

1. 相手側は推論するか、応答するか？

NetSuite MCP サーバーは推論しません。ツール呼び出し（get_customer、search_items）を受け取り、API を照会し、構造化 JSON を返します。呼び出したエージェントが推論を行います。A2A 価格エージェントは推論します — タスク（「これらの 3 つの見積もりを過去の価格設定とサプライヤーの信頼性に対して評価する」）を受け取り、独自のモデル推論を実行し、独自の MCP ツールを呼び出す可能性があり、推論を添えた推奨を返します。

相手側がデータソースや API の場合、MCP を使用します。相手側が独自のモデル、独自のツール、独自の意思決定を持つ自律エージェントの場合、A2A を使用します。実用的なテスト：呼び出す対象に独自のプロンプトがありますか？あるなら A2A。ないなら MCP。

2. ストリーミング出力が必要ですか？

MCP ツール呼び出しはリクエスト/レスポンスです。サーバーはリクエストを処理し、単一の結果を返します。中間状態、トークンごとのストリーミング、部分的なアーティファクトはありません。データベースの照会やレコードの取得にはこれで問題ありません — 断片のストリームではなく完全な結果が必要です。

A2A は message/stream をサポートし、トークンデルタとアーティファクトが生成されるにつれて配信します。3 つの見積もりを評価するのに 30 秒かかる価格エージェントは、作業中に推論をストリーミングできるため、呼び出し元のエージェント（および監視している人間）は進捗を見て、エラーを早期に検出し、推論が外れた場合にキャンセルできます。ワークフローが時間とともに出力を生成し、部分結果に基づいて行動する必要がある場合、A2A がネイティブにサポートするプロトコルです。

3. ヒューマン承認ゲートがありますか？

MCP にはヒューマンインザループの第一級概念がありません。MCP ツールを呼び出すエージェントに承認ロジックを組み込むことはできます — エージェントが一時停止し、人間に尋ねてから続行 — しかし、プロトコル自体はこれをエンコードしません。承認状態はプロトコルではなく、アプリケーションコードに存在します。

A2A は INPUT_REQUIRED を第一級タスク状態として定義します。エージェントが人間の承認を必要とする決定に達したとき — 購買承認、見積もり承認、データアクセス決定 — タスクを INPUT_REQUIRED に遷移させます。呼び出し元のエージェント（またはその背後の人間オペレーター）は、フレームワーク固有の詳細ではなく、標準プロトコル状態を見ます。人間が応答すると、タスクが再開します。ワークフローにエージェント境界をまたぐ承認ゲートが含まれる場合、A2A はそれらのゲートを透過的に運びます。Hermes Agent A2A ブリッジは Hermes のネイティブ承認リクエストを A2A の INPUT_REQUIRED 状態にマッピングするため、各エージェントがどのフレームワークで実行されているかに関係なく、エージェント委譲チェーンに人間のチェックポイントを含めることができます。

4. 作業にどのくらい時間がかかりますか？

MCP ツール呼び出しは短く同期な操作のために設計されています — API の照会、レコードの取得、計算の実行。2026-07-28 仕様は MCP を明示的にステートレスにしました。つまり、サーバーは呼び出し間の会話コンテキストを維持しません。状態はサーバーではなくクライアント（エージェント）に存在します。これはツールにとって正しい設計です：NetSuite サーバーは 5 分前に顧客を照会したことを記憶すべきではありません。

A2A タスクは明示的なライフサイクル管理を伴う長時間実行作業のために設計されています。タスクは submitted → working → completed（または failed、canceled、input-required）を経由します。状態マシンはプロトコルの一部です。2 分かかる価格評価、1 時間かかるコンプライアンスチェック、1 日かかるマルチエージェント研究タスク — これらは A2A のタスクモデルに適合します。OpenAI の Astra は 8 月 1 日に確認され、数時間または数日かかるタスクのために構築されています。Astra のマルチエージェント調整パターンは MCP のステートレスなツール呼び出しモデルではなく、A2A のタスクライフサイクルに直接マッピングされます。

5. 1 つのシステムを呼び出していますか、それとも複数のエージェントを調整していますか？

エージェントが NetSuite、HubSpot、BigCommerce と通信する必要がある場合、それは 3 つの MCP サーバーです。各サーバーがツールを公開し、エージェントが必要に応じて呼び出します。エージェントが調整を行います — どのツールを、いつ、どの順序で呼び出すかを決定します。MCP サーバーは互いについて知りません。

カタログエージェント、価格エージェント、コンプライアンスエージェントに委譲する必要がある調達エージェントがある場合 — それぞれが独自のモデルとツールを持つ — それは 3 つの A2A エンドポイントです。調達エージェントがタスクを送信し、ストリーミング結果を受け取り、委譲チェーンを調整します。カタログ、価格、コンプライアンスエージェントはそれぞれ MCP を使用して独自のデータソースにアクセスする可能性があります。2 つのプロトコルは異なるレイヤーで動作します：A2A はエージェント間委譲を処理し、MCP は各エージェント内のエージェントとツール間アクセスを処理します。

両方を使用する場合：本番パターン

tyk.io エンタープライズガイドで確認され、150 以上の A2A 組織で見られる本番パターンは、2 層アーキテクチャです：

各専門エージェントは A2A エンドポイントです（Agent Card を公開し、タスクを受け入れ、結果をストリーミング）。各専門エージェントは MCP を使用して独自のデータソースに接続します。オーケストレーターエージェントは NetSuite に直接通信することはありません — 価格エージェントに委譲し、価格エージェントが MCP を使用して NetSuite を照会します。この分離により各エージェントのツールサーフェスはガバナンスされ監査可能でありながら、A2A レイヤーがエージェント間調整を処理します。

Hermes Agent A2A ブリッジのリファレンス実装はこのパターンを示しています：ゲートウェイが A2A プロトコルサーフェス（Agent Card、JSON-RPC ディスパッチ、SSE ストリーミング、タスク状態マシン）を処理し、プラグ可能なハンドラーが A2A タスクセマンティクスを各フレームワークのネイティブ API に変換します。新しいエージェントフレームワークの追加は 1 つのハンドラークラスの記述を意味します — プロトコル、ゲートウェイ、状態マシンは共有インフラストラクチャです。同じゲートウェイは A2A クライアントサーフェスを変更することなく、Hermes Agent、OpenClaw、または将来のハンドラーにルーティングできます。

単一エージェントで十分な場合

すべてのシステムが A2A を必要とするわけではありません。Princeton NLP の研究では、単一エージェントが 64% のベンチマークタスクでマルチエージェントシステムに匹敵するかそれを上回ることが判明しました — マルチエージェント構成は 2 倍のコストでした。ワークフローが NetSuite を照会し、見積もりを起草して承認のために提出する単一エージェントである場合、MCP（NetSuite 接続用）とアプリケーションレベルの承認ゲートが必要です。A2A は必要ありません。

異なるモデル、異なるツールサーフェス、または調整が必要な異なる所有権境界を持つエージェントがある場合、A2A は必要になります。調達チームのソーシングエージェントと財務チームのコンプライアンスエージェントは異なるグループが所有し、異なるインフラストラクチャで実行され、異なるモデル選択を持つ可能性があります。A2A はコードベースやデプロイメントを共有せずに作業を委譲して追跡するためのプロトコルを提供します。すべてのエージェントが同じ所有者で同じインフラストラクチャ上の同じモデルである場合、MCP ツールを備えた単一エージェントの方がシンプルで安価です。

MCP 2026-07-28 仕様最終版：この決定における変更点

MCP 仕様は 2026 年 7 月 28 日に最終版として公開されました。4 つの Tier 1 SDK（TypeScript、Python、Go、C#）はすべて 2026-07-28 に対応しています。仕様は MCP を明示的にステートレスにしました — サーバーは呼び出し間のセッション状態を維持しません。12 か月の SSE 廃止ポリシーがアクティブです：Streamable HTTP トランスポートが SSE に代わり、既存の SSE デプロイメントは 2027 年 7 月までに移行する必要があります。

A2A と MCP の決定に関して、仕様最終版は階層化を確認します：MCP はステートレスなツールプロトコルです。MCP セッションを使用してエージェントの会話状態を維持していた場合、仕様はそれを止めるよう指示します — 状態はサーバーではなくエージェント（MCP クライアント）に属します。これにより A2A レイヤーはより明確に必要になります：エージェント間の長時間実行されるステートフルな調整は、MCP が設計されたものではありません。A2A のタスク状態マシンがそのギャップを埋めます。

トランスポートの重複に関する注記

両プロトコルは HTTP と SSE を使用するため、競合するかどうかの混乱が生じる可能性があります。競合しません — トランスポートの重複は表面的です。MCP はツール呼び出し（リクエスト → レスポンス）に HTTP を使用し、サーバー起動の通知のために SSE から Streamable HTTP に移行しています。A2A はタスクディスパッチに JSON-RPC 2.0 over HTTP を使用し、ストリーミングタスク出力に SSE を使用します。トランスポートは配管であり、プロトコルセマンティクスは異なります。MCP はツール呼び出しを運びます。A2A はタスクライフサイクルを運びます。両方を同じゲートウェイで実行できます — リファレンス実装はまさにこれを行い、ゲートウェイが両プロトコルの HTTP と SSE を処理しながら、ブリッジレイヤーが各フレームワークのネイティブ API に変換します。

あなたのアーキテクチャにとっての意味

B2B エージェントシステムを構築している場合 — RFQ 自動化、調達ワークフロー、ナレッジグラフを備えたカスタマーサポート、データパイプラインオーケストレーション — プロトコルの決定はワークフローの形状に従います：

• 1 つのエージェント、複数のデータソース → MCP のみ。エージェントは MCP モジュールを使用して NetSuite、HubSpot、BigCommerce、サプライヤーカタログに接続します。A2A は不要です。
• 複数のエージェント、同じ所有者、同じインフラストラクチャ → ツールに MCP、エージェント間作業にアプリケーションレベルの調整。調整ロジックがプロトコルレベルの状態マシンで簡素化されるほど複雑になった場合は A2A を検討。
• 複数のエージェント、異なる所有者または異なるインフラストラクチャ → エージェント間委譲に A2A、各エージェントのツールアクセスに MCP。これが分散エージェントシステムの本番パターンです。
• ヒューマン承認ゲートを伴う長時間実行タスク → タスクライフサイクルと INPUT_REQUIRED 状態に A2A、各タスク内のツール呼び出しに MCP。承認ゲートはカスタムアプリケーションコードとしてではなく、A2A 状態遷移としてエージェント境界を越えます。

8 月 1 日の OpenAI の Astra 確認により、長時間実行されるマルチエージェントパターンはフロンティアモデルの設計方向になりました。Astra は数時間または数日かかるタスクのために構築され、拡張期間にわたって複数のエージェントを調整します。このパターンをサポートするプロトコルスタックは、調整に A2A、ツールアクセスに MCP です — この記事が説明する 2 プロトコルアーキテクチャです。

---

中堅のディストリビューターは、カタログエージェントと通信する引き合いエージェントと、コンプライアンスエージェントと通信するカタログエージェントを必要とします — それぞれ異なるモデルで支えられ、それぞれ異なるチームが所有し、それぞれ MCP モジュールを通じて異なるシステムに接続します。A2A はこれらのエージェントに委譲とストリーミングのための共有プロトコルを提供します。MCP は各エージェントにデータソースへのガバナンスされたアクセスを提供します。ブリッジパターンにより、Hermes Agent、OpenClaw、その他のフレームワークが内部を書き直すことなく A2A ネットワークに参加できます。

スコープ定義済みの構築をリクエスト

1 週間のディスカバリー。システムインベントリ、ワークフローマップ、固定スコープを取得できます — 私たちと構築するかどうかにかかわらず。