Agent2Agent (A2A) とは何か？ AI エージェントの通信と協働方法

Agent2Agent (A2A) は、AI エージェントが相互に発見し、メッセージを交換し、タスクを委任し、進捗を報告し、システム境界を越えて結果を返すことを可能にするオープンプロトコルです。 これは、一方のエージェントがもう一方のエージェントから支援を必要とするが、いずれの側も内部の推論、メモリ、実装を公開する必要がない状況向けに設計されています。

組織が専門化されたエージェントを導入するにつれて、通信はインフラストラクチャの問題になります。調達エージェントはコンプライアンスエージェントから情報が必要になることがあり、カスタマーサービスエージェントは物流エージェントに出荷の調査を依頼することがあります。A2A は、エージェントが異なるフレームワーク、ベンダー、またはモデルを使用していても、作業を調整する共通の方法を提供します。

エージェントが通信標準を必要とする理由

従来の API は機能とデータを公開しますが、エージェント間のやり取りはよりオープンエンドになる可能性があります。受信側エージェントは目標を解釈し、解決方法を決定し、フォローアップ質問を行い、数分または数時間作業し、更新をストリームし、複数の成果物を返す必要があるかもしれません。

共有プロトコルがなければ、各プラットフォームは ID、機能発見、タスク、メッセージ、ステータス、エラー用に独自のフォーマットを定義することになります。その断片化により、クロスプラットフォームの委任が困難になり、有用なエージェントが個別製品にロックされてしまいます。

A2A は通信レイヤーを標準化しつつ、各エージェントをブラックボックスのままにします。現在のA2A 仕様は、プロトコルのコアオブジェクトと相互作用を定義しています。

A2A の主要な役割

この分離が、A2A を単純な関数呼び出しと異なるものにしています。リモート参加者は長時間実行されるタスクを管理し、追加情報を求め、サポートされるコンテンツタイプを交渉し、1 つまたは複数の成果物を返すことができます。クライアントエージェントは、そのタスクを追跡しながら、タスクを開始したユーザーまたはアプリケーションの ID と権限を保持します。

A2A のやり取りは通常、2 つの論理的な役割を含みます。

• クライアントエージェント： 作業を要求するエージェントまたはアプリケーションです。
• リモートエージェント： 要求を受け取り、作業を実行または調整するエージェントです。

「クライアント」と「リモート」という語は現在のやり取りを表すものであり、永続的な階層構造を示すものではありません。同じエージェントがあるコンテキストでは作業を要求し、別のコンテキストでは別のエージェントにサービスを提供することができます。

エージェントカード：機能の発見

タスクを委任する前に、クライアントはリモートエージェントが何をできるか、そしてどのように通信すればよいかを知る必要があります。A2A はエージェントカードを使用して、記述的かつ操作的なメタデータを公開します。

エージェントカードは、エージェントの名前、エンドポイント、サポートされるプロトコル機能、認証要件、スキル、受け入れ可能なコンテンツタイプを記述できます。スキルとは、文書の翻訳、契約のチェック、市場調査など、宣言された能力領域のことです。

発見は品質や信頼性を証明するものではありません。エージェントカードは能力に関する主張であり、独立した認証ではありません。本番システムでは依然として ID、認可、ポリシー検査、評価、評判が必要です。

メッセージ、タスク、成果物

A2A はコラボレーションをいくつかのコアオブジェクトで表現します。

メッセージ

メッセージはエージェント間の通信を運びます。テキストやその他の構造化された部分を含むことができ、エージェントが指示、明確化、またはコンテキスト情報を交換できるようにします。

タスク

タスクは、時間とともに状態が変化し得る作業単位を表します。リモートエージェントは作業を受け入れ、処理を続行し、追加入力を要求し、完了させ、失敗させ、またはキャンセルすることができます。永続的なタスク ID は、長時間実行される操作に有用であり、クライアントは更新間で同じジョブを参照できます。

成果物

成果物は、レポート、データセット、画像、コードパッチ、構造化された提案など、作業によって生成される出力です。成果物を会話メッセージから分離することで、クライアントは最終的な納品物を識別しやすく、利用しやすくなります。

A2A のやり取りの仕組み

旅行計画エージェントが入国要件を確認する専門家を必要とすると仮定します。

1. クライアントはリモートエージェントを発見し、そのエージェントカードを読み取ります。
2. エージェントが関連する機能と互換性のあるインタラクション手法を提供しているか確認します。
3. クライアントは認証し、タスク、旅行者、日程、必要な出力を記述したメッセージを送信します。
4. リモートエージェントはタスクを作成または更新し、作業を開始します。
5. リモートエージェントは進捗をストリームしたり、欠落した詳細を要求したりすることがあります。
6. クライアントはタスクコンテキストを保持したまま、明確化情報を提供します。
7. リモートエージェントはタスクを完了し、結果を含む構造化された成果物を返します。
8. クライアントはその結果を評価し、旅行全体の計画に使用します。

リモートエージェントは割り当てをどのように実行するかを決定します。自分のツールを呼び出したり、プライベートデータを参照したり、他のエージェントと調整したりすることができます。A2Aはこれら内部ステップの公開を要求しません。

A2A と MCP の比較

プロトコルは同一アーキテクチャの異なる層に配置できます。旅行計画エージェントは、A2A を介して専門的なビザ調査タスクを委任することがあります。その専門エージェントは、MCP 接続を利用して承認済みデータベースを検索し、ポリシー文書を取得できます。A2A はエージェント間の責任を調整し、MCP は AI ホストと機能間のアクセスを標準化します。

A2A と Model Context Protocol は、異なる統合課題を解決します。

• MCP は AI アプリケーションをツールとコンテキストに接続します。 クライアントは MCP サーバーから関数、リソース、プロンプトなどの機能を検出します。
• A2A はエージェント同士を接続します。 クライアントは目標指向タスクをリモートエージェントに委任し、エージェントは自らのプロセスを管理し、成果を返します。

違いは、ツールを使用することと専門家を雇うことに似ています。電卓は操作を公開しますが、アナリストは目的を受け取り、必要な操作を決定します。実際のシステムでは、リモート A2A エージェントが内部で MCP を利用して自分のツールやデータにアクセスすることがあります。

A2A と従来の API の比較

従来の API は、呼び出し側が正確な操作と入力形式を把握している場合に最適です：レコードの取得、見積もりの計算、フィールドの更新など。A2A は、リクエストが会話的、状態保持的、非同期的、または成果指向である場合に有用です。

A2A がすべての API を置き換えるわけではありません。リモートエージェントはしばしば従来の API を呼び出して作業を実行し、エージェントの裁量が価値を生まない場合は組織が決定論的サービスを直接提供することがあります。

相互運用性が重要な理由

エージェントエコシステムは多様化します。異なるチームが異なるドメイン、モデル、セキュリティ境界、デプロイ環境に最適化するでしょう。共通プロトコルは、組織が専門性を維持しつつ協調を可能にします。

相互運用性は統合の結合度を低減させることもできます。クライアントは、リモートエージェントのフレームワークをインポートしたり内部ロジックを複製したりする代わりに、宣言されたスキルとプロトコルの動作に依存できます。A2Aプロジェクトの概要は、この目標を異なるスタック上で構築されたエージェントがピアとして通信できるようにすることと説明しています。2026年のプロジェクト更新でAgentic AI Foundationに参加することが示すように、中立的で産業横断的なガバナンスへの推進が反映されています。

セキュリティと信頼の課題

委任は責任の連鎖を作り出します。クライアントはリモートエージェントの身元と公表された能力を検証し、共有するコンテキストを最小限に抑え、開始ユーザーの認可を保持しなければなりません。リモートエージェントは、別のエージェントがタスクを要求したからというだけで広範な権限を継承すべきではありません。各ホップでは認証、スコープされたクレデンシャル、監査可能性、そして要件が衝突したり信頼度が低い場合に何が起こるかという明確なルールが必要です。

エージェント間の委任は権限の連鎖を作ります。クライアントは誤って機密コンテキストを共有したり、リモートエージェントに意図以上の裁量を与えたり、信頼できない成果物に基づいて行動したりする可能性があります。リモートエージェントは、信頼できないクライアントから悪意のある指示やファイルを受け取ることもあります。

堅牢なデプロイには複数の層での制御が必要です：

• 身元と認証： どのエージェントと組織が参加しているかを検証します。
• 認可： 各呼び出し元が利用できるスキル、データ、アクション、タスク範囲を制限します。
• データ最小化： リモートエージェントが必要とするコンテキストのみを共有します。
• 出所： 作業を要求した人物、生成したエージェント、そしてそれを支えるソースを記録します。
• 出力検証： リモートアーティファクトは、関連するチェックを通過するまで信頼できないものとして扱います。
• 委任制限： リモートエージェントが追加のエージェントやサービスを関与させるかどうかを制御します。
• 人的承認： 財務、法務、外部、破壊的、またはその他重要な影響を及ぼす行動の前に一時停止します。

プロトコルの互換性は組織の信頼を意味しません。エージェントがA2Aを正しく使用できても、特定のタスクには不適切である可能性があります。

チームはいつA2Aを使用すべきか

A2Aは、独立したエージェントが製品、ベンダー、または組織の境界を越えて協働する必要がある場合、作業が長期にわたる場合、または受信システムが結果の生成方法に自由度を保つべき場合に最も魅力的です。

単純な機能や固定された内部ワークフロー、あるいは単一アプリケーション内で緊密に結合されたコンポーネントに対しては、A2Aは不要かもしれません。そのような場合、通常のAPI、イベントバス、または直接ツール呼び出しの方が運用や評価が容易です。

Agent2Agent（A2A）について覚えておくべきこと

A2Aは、エージェントが内部の仕組みを共有せずに機能を発見し、目標指向の作業を調整するための共通言語を提供します。その核心的価値は、複数のエージェントが自動的に単一より優れているということではなく、独立して構築された専門家が安定した境界を通じて協働できる点にあります。

その境界はメッセージ以上の情報を運ぶ必要があります。身元、タスク状態、アーティファクト、権限、出所、そして失敗処理が必要です。A2Aはプロトコルの基盤を提供しますが、組織は依然として信頼モデルを提供しなければなりません。