メインコンテンツまでスキップ

A2A：エージェント間プロトコル

上級

2026年半ばまでに、ほとんどの非自明なエージェント作業は、協調する複数のエージェントによって行われます — 調査エージェントが執筆者に引き渡し、請求エージェントが別のベンダーのサポートエージェントと話し、オーケストレーターが別の組織のクラウド内の専門家に委任します。A2A（エージェント間） は、それらのエージェントがお互いを見つけ、できることを記述し、タスクを行き来させることを可能にするオープンプロトコルです — 異なるチームによって異なるフレームワーク上で構築されていても。MCP がエージェントをそのツールとデータに接続する一方、A2A はエージェントを別のエージェントに接続します。それらは構成されるものであり、競合しません。

What you'll learn
  • A2Aが何のためのものかを正確に述べる — そしてMCPとの境界がどこにあるかを述べる
  • Agent Cardを読み、受信側のエージェントがそれで何をするかを知る
  • 8つのライフサイクル状態すべて（終端ではなく中断される2つを含む）を通してタスクを歩く
  • 長時間実行タスクに対してSSEストリーミングとWebhookプッシュを選択する
  • 非自明な機能を認識する：署名付きカード、マルチテナントエンドポイント、構造化データパーツ

なぜA2Aが存在するのか​

すべてのエージェントフレームワーク — LangGraph、CrewAI、Claude Agent SDK、OpenAI Agents SDK、MicrosoftのAgent Framework、カスタムの社内ループ — は、モデルのネイティブなツール呼び出しに寄りかかることでツール使用を解決し、ますます、ユニバーサルなツール&データコネクターとしてのMCPに寄りかかっています。それは私たちにエージェント↔ツールを与えました。

それらのどれもが単独で解決しなかったのは、エージェント↔エージェントの境界を越えたものです。2つの問題が繰り返し現れました：

  • 発見。 エージェントAは、エージェントBが存在し、何ができ、どうやって認証するか、ストリーミングをサポートするかどうかを、どうやって知るのか？手書きのREADMEはプロトコルではありません。
  • タスクの引き渡し。 AがBに何かをしてほしいとき、彼らは仕事（モデルのチャットではなく）をどのようにやり取りするのか？ — ファイル、構造化データ、進捗更新、そしてBが一時停止してAに入力を求める必要があるかもしれないという事実を含めて。

フレームワーク固有の回答（LangGraphサブグラフ、CrewAIクルー、1つのランタイム内のサブエージェント）は1つのプロセス内では素晴らしく機能します。それらは組織の境界で止まります。A2Aは、あなたの製品内のエージェントが、別の人の製品内のエージェントに、どちらの側も内部を漏らすことなく作業を委任できるようにするピースです — GoogleのTodd Segalは「個人、チーム、ドメイン固有のエージェントが、あらゆるプラットフォームを越えてシームレスに一緒に働くための安全な基盤」と呼んでいます。ガバナンスはLinux Foundationにあり、2026年4月までに、プロジェクトはAWS、Microsoft、Salesforce、SAP、ServiceNow、IBMを含む150以上のサポート組織を報告しました。

MCP対A2A — メンタルモデル​

両方ともオープンプロトコルです。両方ともHTTP上でJSONを使用します。それらは異なる問題を解決し、構成するように設計されています：

  • MCP = エージェントからツールへ。MCPサーバーは、ツール（search、read_file、run_query）とリソース（ドキュメント、プロンプト）をモデル駆動のクライアントに公開します。クライアントはエージェントで、サーバーは受動的な機能プロバイダーです。ClaudeがどのようにそれをMCPを使うかについては、MCPとツールへの接続を参照してください。
  • A2A = エージェントからエージェントへ。A2Aエンドポイントは、エージェント — 委任されたタスクをどのように解決するかを決める独自の推論ループを持つエンティティ — を公開します。両方の側がエージェントで、どちらも他方を呼び出せます。

具体的な違いはワイヤーフォーマットに現れます。MCPのtools/callは結果を返して閉じます。A2AのSendMessageはタスク — 更新をストリームし、明確化を求め、または何時間もバックグラウンドで実行できる、独自のライフサイクルを持つステートフルなもの — を開きます。あなたのエンドポイントの回答が常に「1つの関数の結果はこちら」であるなら、それはツールです — MCP経由で公開してください。「それについて考えて、あなたに戻ります、そしてフォローアップの質問が必要かもしれません」であるなら、それはエージェントです — A2A経由で公開してください。

ほとんどの本格的なシステムは両方を実行します：内部でMCPを使ってツールに到達するエージェントで、その外部ではピアが作業を引き渡せるようにA2Aを話すもの。

Agent Card — 仕様で最も重要な部分​

Agent Cardは、Well-Known URLで提供されるJSONドキュメントで、潜在的な呼び出し元があなたのエージェントと話すのに必要なすべてを伝えます。エージェントのためのOpenAPI + robots.txtと考えてください。すべてのA2Aインタラクションは、1つを取得することから始まります。

カードには以下が含まれます：

  • アイデンティティ — id、name、description、provider（組織の詳細）。
  • エンドポイント — サービスURLと、どのプロトコルバインディング（JSON-RPC、gRPC、REST）が利用可能か。
  • 機能 — 機能フラグ：streaming、pushNotifications、extendedAgentCard。
  • スキル — 入力/出力スキーマ付きの宣言されたエージェント機能（これはBができると言うものです）。
  • セキュリティスキーム — APIKey、HTTPAuth（Basic/Bearer）、OAuth2（Authorization Code、Client Credentials、Device Code）、OpenIdConnect、MutualTLSのうちの1つまたは複数。呼び出し元は、最初の呼び出しの前にどの認証情報を持ってくるかを知るためにこれを読みます。
  • 署名 — カードに対するオプションの暗号署名。

その最後のフィールドは、立ち止まる価値のあるものです。署名付きAgent Cardは、受信側のエージェントが、カードが実際にドメイン所有者によって発行されたことを検証できるようにします — 「はい、これは本当にagents.acme.comであり、攻撃者が植えたものではありません」というDNS/PKIの同等物です。mTLS認証と組み合わせると、なりすましホストから提供される不正なAgent Cardの扉を閉じます、そうでなければ発見レイヤーでのプロンプトインジェクションを得ることになります：攻撃者のAgent Cardが、公開するツールと欲しがるデータについて嘘をつくというものです。

8つのタスクライフサイクル状態​

A2AエージェントにSendMessageすると、作業はタスク — ポーリング、購読、キャンセル、リストできるIDを持つファーストクラスのオブジェクト — になります。タスクは8つの状態を通じて移動し、5つだけが終端であることに注目する価値があります：

  • SUBMITTED — サーバーがタスクを承認しました。
  • WORKING — アクティブに処理中。
  • INPUT_REQUIRED — 中断： エージェントは呼び出し元からより多くの情報を必要としています。エラーではなく、実際のワークフローで予想されるものです。
  • AUTH_REQUIRED — 中断： エージェントは続行する前に呼び出し元に認証（または再認証）を必要とします。
  • COMPLETED — 成功。終端。
  • FAILED — エラー。終端。
  • CANCELED — 呼び出し元によるキャンセル。終端。
  • REJECTED — エージェントがタスクを拒否しました（ポリシー、機能、クォータ）。終端。

中断される状態が要点です。レガシーRPCは1回の呼び出し→1つの結果を前提としています。実際のエージェント作業は次のように見えます：「分析を開始し、1時間後に戻ってきて、明確な質問を尋ねる必要があることに気づき、答えを待ち、再開し、終わらせる。」 A2Aはそれをネイティブにモデル化します。あなたの呼び出しコードは、同期的なawaitではなく、小さなステートマシンでなければなりません。

ストリーミング対プッシュ通知​

長時間実行タスクには、更新を配信する方法が必要です。A2Aは2つの非同期モデルを提供します — エージェントごとではなくタスクごとに選択：

  • ストリーミング（SendStreamingMessage / SubscribeToTask）。 オープンなHTTP接続上のServer-Sent Events。クライアントは接続を維持し、TaskStatusUpdateEventとTaskArtifactUpdateEventを順序どおりに受信します。インタラクティブUIと短〜中程度のタスクに最適。クライアントが接続を維持できない場合（モバイル、サーバーレス、スリープするブラウザタブ）は失敗します。
  • プッシュ通知（Webhook設定）。 クライアントはCreateTaskPushNotificationConfig経由でWebhookを登録します。サーバーはそのURLに更新が発生するたびにPOSTします。クライアントはその間完全にオフラインでいることができます。これは、HTTP接続よりも長生きするタスクのモードです — 「一晩実行する」または「バッチジョブが終了したら私に電話をかけ直す」のようなものを考えてください。

両方とも、エージェントがそのAgent Cardでサポートを宣伝することを要求します（capabilities.streaming: trueおよび/またはcapabilities.pushNotifications: true）。準拠する呼び出し元は最初にチェックし、きれいにダウングレードします。

メッセージパーツ — 単なるチャットではない​

A2A メッセージは、1つ以上のパーツで構成されます。各パーツは次のいずれかです：

  • text — 文字列コンテンツ（チャット的な部分）。
  • raw — バイナリファイル、JSONでbase64エンコード。
  • url — 外部ファイルへの参照（巨大なブロブのインライン化を避ける）。
  • data — オプションのmetadataマップ付きの、構造化JSONオブジェクトまたは配列。

dataパーツは、A2Aをマシン間作業に有用にするものです。2つのエージェントは、自然言語会話をしているふりをすることなく、型付きペイロード — 注文、購入仕様、JSON差分 — を交換できます。これはまた、**Agent Payments（AP2）**のようなプロトコルがA2Aの上にきれいに層をなす理由でもあります：支払い意図は既知のスキーマを持つdataパーツに乗ります。

マルチテナントエンドポイント — 1つのURL、多くのエージェント​

これは見逃しやすいものです。単一のA2Aエンドポイントは多くのエージェントをホストでき、認証後にGetExtendedAgentCardメソッドを通じて提供されます。SaaSベンダーは、1つのURLを提供し、呼び出し元が提示するAPIキーまたはOAuthスコープに応じて、テナント固有の異なるAgent Cardを返すことができます。呼び出し元側からは、エージェントごとに1つのエンドポイントに見えます；ベンダー側からは、1つのデプロイメントです。エージェント提供インフラを構築している場合、これはテナントごとに1つのホスト名なしでスケールできるパターンです。

最小限のエンドツーエンドインタラクション​

完全なプロトコルは表面積が広いですが、ハッピーパスのフローは短いです：

Guided walkthrough1 of 5
  1. Well-Known URLからAgent Cardを取得する。署名がある場合は検証する。`capabilities`、`skills`、`securitySchemes`を読んで、このエージェントが必要なことをできるか、どの認証を持ってくるかを決める。

Agent Cardを取得する（概念）​

発見は単なるHTTP GETです。これは、クライアントが候補エージェントに作業を送る前にそれを検査するためにするリクエストの形です：

Agent Cardを取得して検査する

GET https://agents.example.com/.well-known/agent.json
Accept: application/json

# Response (abbreviated):
# {
#   "id": "acme/support-router",
#   "name": "Acme Support Router",
#   "provider": {"organization": "Acme, Inc."},
#   "endpoints": [
#     {"url": "https://agents.example.com/a2a", "protocol": "jsonrpc"}
#   ],
#   "capabilities": {
#     "streaming": true,
#     "pushNotifications": true,
#     "extendedAgentCard": true
#   },
#   "skills": [
#     {"id": "route_ticket", "inputSchema": {...}, "outputSchema": {...}}
#   ],
#   "securitySchemes": {
#     "primary": {"type": "oauth2", "flows": {...}}
#   },
#   "signature": {"alg": "EdDSA", "value": "..."}
# }

カードにないものに注目してください：エージェントの背後のモデル、そのプロンプト、そのツール、そのプライベート状態については何もありません。その不透明性は意図的です — A2Aはピアエージェントを、作業を委任するブラックボックスとして扱い、内省するシステムとしては扱いません。

よくある落とし穴​

  • INPUT_REQUIREDをエラーとして扱う。 それは違います；それは、あなたのコードに応答するよう頼むプロトコルです。呼び出し元のコードが「成功したか失敗したか」だけで分岐するなら、すべてのインタラクティブワークフローを壊すでしょう。
  • Agent Cardのcapabilitiesを無視する。 streaming: trueを宣伝しなかったエージェントにストリーミングリクエストを送ると、UnsupportedOperationErrorが返されます。カードを読み、きれいにダウングレードしてください。
  • ストリーミング接続が永続的であると仮定する。 モバイルクライアント、サーバーレスランタイム、ブラウザタブ — それらはすべてSSE接続を落とします。「チャットターン」より長いものについては、プッシュ通知を優先してください。
  • オプションだからといって署名検証をスキップする。 組織外からAgent Cardを消費しているなら、署名を検証してください — そうでなければ、発見レイヤーのプロンプトインジェクションベクトルを作成したことになります。
  • A2AとMCPを混同する。 ステートレスな単発関数のためにA2Aエンドポイントを公開するのは過剰です；それはツールで、MCPが正しいプロトコルです。数分かかり明確化の質問を必要とするもののためにMCPツールを公開するのはアンダーエンジニアリングです；それはエージェントで、A2Aが正しいプロトコルです。

Check yourself

0/4
  1. 以下のどれがA2Aの仕事 — MCPが設計されて*いない*もの — ですか？
  2. A2Aは8つのタスク状態を定義します。どの2つが終端ではなく*中断*ですか？
  3. 1時間かかるA2Aタスクを実行する必要があります。クライアントは、オープンHTTP接続を維持できないサーバーレス関数です。正しい配信モデルは何ですか？
  4. *署名付き* Agent Cardは何から保護しますか？

A2Aがスタックのどこに座るか​

エージェントの全体像の残りと一緒にまとめると：

  • エージェントの中では、MCPがツールとデータに到達する方法です — 書いていないリモートMCPサーバーを含めて。
  • 1つのフレームワーク内のエージェント間では、フレームワークが提供するものを何でも使います — Claude Codeのサブエージェント、LangGraphサブグラフ、CrewAIクルーなど。これは最も速いですが、1つのランタイムに縛られます。
  • フレームワーク、チーム、またはベンダー間のエージェント間では、A2Aが手を伸ばすものです。ランタイム側についてはオープンソースAIエージェントフレームワークを読んでください；A2Aはそれらのランタイム間のワイヤーです。

経験則：境界がプロセス境界なら、フレームワークネイティブの引き渡しで十分です。組織、クラウド、または信頼境界なら、A2Aを使ってください。

ソースとさらなる読み物​