Agent2Agent (A2A)とは？AIエージェント通信のためのオープンプロトコル

今日のほとんどのAIシステムはシングルエージェントです。1つのモデル、1つのプロンプトループ、1組のツール。これは、1つのエージェントでは処理しきれないほどタスクが大きくなるか、あるいは自分のエージェントでは対応できないステップを別のチームが構築したエージェントに処理してもらう必要が生じるまでは機能します。しかし、そこで壁にぶつかります。2つの独立したエージェントが互いを見つけ、作業を交換し、結果を報告するための標準的な方法が存在しないのです。Agent2Agent (A2A) は、その壁を取り除くために構築されたプロトコルです。

このガイドでは、A2Aとは何か、それが解決する問題、その内部動作、そしてMCPとの違いについて説明します。これを読んだ後にA2Aエージェントをテストしたい場合は、Apidog A2Aデバッガーガイドがこの記事の続きを詳しく解説しています。

Agent2Agent (A2A) とは？

Agent2Agent (A2A) は、AIエージェント間の通信のためのオープンプロトコルです。これは、あるエージェントがその能力をどのように宣伝するか、別のエージェントがそれにどのように接続するか、2つのエージェントがどのようにメッセージとファイルを交換するか、そしてタスクの状態が呼び出し元にどのように戻るかを定義します。

キーワードは「間」です。A2Aは、単一のエージェントに多くのツールを与えることではありません。それは、異なるチームによって異なるフレームワークで構築された別々のエージェントが、互いの内部を知ることなく連携できるようにすることです。

エージェントトラフィックのためのHTTPだと考えてください。HTTPは、ブラウザがサーバーがどの言語で動作しているかを気にすることなく、あらゆるウェブサーバーと通信できるようにします。A2Aは、LangGraphエージェントがCrewAIエージェントと、そのエージェントがどのように構築されたかを気にすることなく通信できるようにします。両者は「封筒」に合意し、どちらの側もその実装を漏洩することはありません。

Googleは2025年にA2Aを導入し、その後、ベンダーニュートラルなプロジェクトとしてLinux Foundationに移管しました。仕様はA2A GitHubリポジトリで公開されており、リファレンス実装はA2Aプロジェクトサイトで公開されています。

A2Aが解決する問題

A2A以前は、2つのエージェントを接続するには、接着コードを書く必要がありました。すべてのペアリングはカスタムでした。もし自分のエージェントがパートナーチームのリサーチエージェントを呼び出す必要があった場合、誰かが特注のクライアントを作成し、ペイロードの形状を選択し、認証スキームを考案し、そのすべてを手作業で保守していました。次のペアリングもまたゼロから始まることになりました。

このアプローチはすぐに破綻します。

• ディスカバリがない。 作業を送信する前に、エージェントが「何ができるのか？」と尋ねる標準的な方法はありませんでした。
• 共通のタスクモデルがない。 あるエージェントはプレーンな文字列を返し、別のエージェントはカスタムJSONブロブを返し、3番目のエージェントはトークンをストリーミングしました。呼び出し元はそれぞれを特別扱いする必要がありました。
• 共通の認証がない。 すべての統合で認証情報とヘッダーが再発明されました。
• 相互運用性がない。 AutoGenで構築されたエージェントは、LangGraphで構築されたエージェントと同じ仕事をしても、その代替としてそのまま組み込むことはできませんでした。

A2Aは、OpenAPIがREST統合を修正したのと同じ方法でこれを解決します。すなわち、合意された1つの契約によって、どの準拠エージェントも他の準拠エージェントと通信できるようにします。

A2Aの仕組み

A2Aには4つの核となる概念があります。これらを理解すれば、プロトコル全体を把握できます。

エージェントカード

エージェントカードは、エージェントが自身を記述するために公開するJSONドキュメントです。これはディスカバリのエントリーポイントとなります。エージェントの名前、説明、機能、宣言されたスキル、サポートされる入力および出力タイプ、認証要件、およびプロトコルバージョンをリストします。

慣例により、カードはよく知られたパス（例: https://your-agent.example.com/.well-known/agent.json）に配置されます。呼び出し元のエージェントは最初にそのURLを取得し、カードを読み込み、1つのメッセージを送信する前に何が要求できるかを正確に知ることができます。

タスク

タスクはA2Aにおける作業の単位です。あるエージェントが別のエージェントに何かをするように依頼すると、そのリクエストは独自のIDと、submitted（提出済み）、working（作業中）、input-required（入力要求）、completed（完了）のような状態を遷移するステータスを持つタスクになります。呼び出し元はタスクをポーリングしたり、更新を購読したりできます。この共通のタスクモデルこそが、A2Aエージェントを交換可能にするものであり、誰が作業を行っているかに関わらず、呼び出し元は同じ方法でステータスを処理します。

メッセージとアーティファクト

メッセージは、エージェント間で実際のコンテンツを運びます。メッセージは、テキスト部分、ファイル部分、構造化データ、またはその混合物などの「パーツ」で構成されます。受信側のエージェントは、そのスキルが必要とするパーツを読み取ります。

エージェントが完了すると、アーティファクト（タスクの構造化された出力）を返します。アーティファクトは、生成されたドキュメント、データテーブル、要約、またはファイル参照である可能性があります。アーティファクトもパーツから構築されるため、フォーマットは両方向で一貫しています。

ストリーミングと更新

時間のかかるタスクはブロックする必要がありません。A2Aはサーバー送信イベントをサポートしているため、エージェントは作業の進行に合わせて部分的な結果やステータスの変更をストリーミングできます。リサーチエージェントは最終報告書を発行する前に「3つのソースを見つけました」と出力できます。呼び出し元はスピナーを凝視するのではなく、進捗状況を表示します。

これらをまとめると、典型的なA2Aのやり取りは次のようになります。

1. エージェントAはエージェントBのエージェントカードを取得し、そのスキルを読み取ります。
2. エージェントAはタスクを作成するメッセージを送信します。
3. エージェントBはタスクを処理し、ステータスの更新をストリーミングします。
4. タスクがcompleted状態に達すると、エージェントBはアーティファクトを返します。
5. エージェントAはアーティファクトを利用し、次のステップに進みます。

会話全体はHTTP上のJSONです。特別なものはありません。

A2A vs MCP

A2Aとモデルコンテキストプロトコル（MCP）は、どちらもエージェントに関わり、オープンプロトコルであるため、常に混同されがちです。しかし、これらは異なる問題を解決します。

MCPはエージェントが外部システムに「到達する」方法です。A2Aはエージェントが別のエージェントに「到達する」方法です。実際のプロダクションシステムでは、両方を使用することがよくあります。エージェントはMCPを使用してデータベースをクエリし、A2Aを使用して専門エージェントにサブタスクを渡します。MCPサーバーとA2Aの詳細な比較では、この決定について深く掘り下げており、ApidogのMCPクライアントデバッガーはMCP側を実際に示しています。

現実世界でのマルチエージェント連携

A2Aはエージェントを連携させるための一つの方法ですが、唯一の方法ではありません。一部のシステムでは、代わりに直接オーケストレーションを使用し、一つのエージェントが作業を計画し、明示的に別のエージェントに委譲します。

明確なオープンソースの例としては、OpenAI CodexとClaude Code間のリアルタイムワークフローを調整するスキル、Codex-Claude-Collabがあります。Codexはタスクを計画し、実装をClaude Codeに委譲し、その後、差分を確認して結果を検証してからユーザーに回答します。これは、2つの異なるコーディングエージェント間の緊密なプランナーとビルダーのループです。

このパターンはハードワイヤードなオーケストレーションであり、一方が他方を正確に知っています。A2Aは同じ考え方を一般化します。Codexが具体的にClaude Codeを呼び出していると知る代わりに、A2Aの呼び出し元はエージェントカードを読み込み、応答する準拠エージェントであればどれとでも連携します。オーケストレーションは、両端を制御できる場合に非常に有効です。A2Aは、エージェントが独立している場合、異なるチームが所有している場合、または交換可能である必要がある場合に望ましいものです。ほとんどの成熟したシステムは、最終的に両方を持つことになります。つまり、チーム内でのオーケストレーションと、チーム境界を越えるA2Aです。

A2Aエージェントのテスト方法

A2Aエージェントを構築または利用する際、トラフィックを可視化する必要があります。コンソールログでは構造化されたフィールドが隠され、特注のテストスクリプトは陳腐化します。ここで視覚的なA2Aデバッガーが真価を発揮します。

Apidogは、標準クライアントにA2Aデバッガーを搭載しています。エージェントカードのURLを貼り付け、「接続」をクリックすると、Apidogがカードを読み込み、エージェントの名前、機能、スキルを表示します。テストメッセージを送信し、ファイルを添付し、メタデータを追加し、返信を読みやすいプレビュー、生コンテンツ、完全なJSON-RPCペイロードの3つのビューで確認できます。Bearer Token、Basic Auth、APIキーヘッダーをcurlなしで処理します。

重要なのは分離です。エージェントが異常な動作をした場合、トランスポートが間違っているのか、エージェントのロジックが間違っているのかを知りたいものです。正確なワイヤペイロードを見ることで、その疑問に数秒で答えることができます。Apidog A2Aデバッガーガイドは、接続-送信-読み取りの一連の流れを詳しく説明しており、APIを呼び出すAIエージェントのテストというより広範な原則にも、まずワイヤを確認するという同じ規律が適用されます。

A2Aを始めるには

A2Aエージェントを構築または接続したい場合、簡単な手順は以下の通りです。

1. A2A仕様を読み、必要なエージェントカードフィールドとタスクライフサイクルを理解してください。
2. リファレンスサンプルエージェントのいずれかをローカルで実行します。ほとんどは数分で起動し、動作するエージェントカードを公開します。
3. サンプルのエージェントカードURLにA2Aデバッガーを向け、「hello」メッセージを送信します。ラウンドトリップが確認できることを確かめます。
4. 独自のエージェントを構築し、有効なエージェントカードを公開し、ワークフローに組み込む前に同じ方法でテストします。
5. プレーンテキストのパスが機能したら、認証、ファイル添付、ストリーミングを順次追加します。

A2Aはまだ新しいですが、ベンダーニュートラルな財団と、増え続けるフレームワーク統合に支えられています。今、エージェントトラフィックをファーストクラスのプロトコルとして扱うことで、後でカスタムの接着コードを書き直す手間を省くことができます。AIエージェントは新しいAPIコンシューマーという記事では、より長期的なケースについて説明しており、AIエージェント向けAPIの設計では、コンシューマーが人間ではなくエージェントである場合に何が変わるかを解説しています。

よくある質問

A2AはGoogle製ですか？

Googleは2025年にA2Aを導入し、その後、ベンダーニュートラルなオープンプロジェクトとしてLinux Foundationに寄贈しました。仕様はオープンな環境で開発されており、どのベンダーもこれを実装できます。

エージェントが1つしかない場合でもA2Aが必要ですか？

いいえ、必要ありません。A2Aはエージェント間の通信を解決します。ツールセットを持つ単一のエージェントにはA2AではなくMCPが必要です。2つ目のエージェントが登場したときにA2Aを利用します。

どのフレームワークがA2Aをサポートしていますか？

A2Aは設計上フレームワーク非依存です。有効なエージェントカードを公開し、プロトコルを話す任意のエージェントが参加できるため、LangGraph、CrewAI、AutoGen、およびカスタムエージェントのすべてが動作します。エージェントの内部フレームワークは、呼び出し元からは見えません。

A2AはMCPと同じですか？

いいえ、違います。MCPは1つのエージェントをツールやデータソースに接続します。A2Aはエージェント同士を接続します。これらは補完的なものであり、多くのシステムでは両方を同時に実行します。

A2A統合をデバッグするにはどうすればよいですか？

Apidog A2AデバッガーのようなビジュアルA2Aデバッガーを使用してください。エージェントカードのURLを貼り付け、テストメッセージを送信し、生の要求と応答を検査することで、トランスポートのバグとエージェントロジックのバグを区別できます。

A2Aは長時間実行されるタスクをサポートしていますか？

はい、サポートしています。タスクモデルには明示的なステータス状態があり、プロトコルは部分的な結果と進捗状況の更新をストリーミングするためのサーバー送信イベントをサポートしているため、長時間かかるジョブが呼び出し元をブロックすることはありません。