Agent2Agentプロトコル:アーキテクチャ、セキュリティ、MCP比較
Agent2Agent(A2A)は、2025年4月にGoogle Cloudによって立ち上げられ、Linux Foundationに寄贈されたオープンプロトコルです。異なるフレームワークやベンダーで構築されたAIエージェントが、標準化されたHTTP/JSONインターフェースを通じて通信し、タスクを委任し、結果を交換することを可能にします。MCPがツールアクセス問題(LLMが外部APIを呼び出す)を解決するのに対し、A2Aは調整問題を解決します:あるエージェントが独自の推論ループ、メモリ、ツールを持つ専門ピアエージェントにサブタスク全体を委任します。a2aproject/A2A GitHubリポジトリには、Salesforce、Atlassian、SAPを含む50以上の組織からの貢献があります。
Agent2Agent(A2A)は、AIエージェントの相互運用性のためのオープンなHTTP/JSONプロトコルであり、Linux Foundationが管理しています。異なるフレームワークやベンダー間で、自律エージェントが能力を広告し、タスクを委任し、結果を交換する方法を標準化します。
Agent2Agent(A2A)プロトコルとは何か
A2Aは、AIエージェントエコシステムの具体的なギャップから生まれました:モデルからツールへの通信には標準(MCP、2024年11月に立ち上げ)がありましたが、エージェントからエージェントへの通信にはありませんでした。オーケストレーターエージェントがサブタスクを専門のピアに引き渡す必要がある場合、そのデリゲーションのための標準化されたワイヤーフォーマットが存在しませんでした。
Google Cloudは2025年4月9日にA2Aを発表し、仕様に貢献する50以上のテクノロジーパートナーの初期グループも発表しました。多くのベンダー主導の標準とは異なり、A2Aは中立的なガバナンスのためにLinux Foundationに寄贈されました。
プロトコルのコアはHTTP/JSONです。A2A準拠エージェントは少数のエンドポイントを公開します:エージェントカード(能力マニフェスト)、タスク送信エンドポイント、ステータスポーリングエンドポイント、および長時間タスク用のSSEストリーミングエンドポイント。
A2Aが対処するマルチエージェント調整問題の背景については、マルチエージェントシステムアーキテクチャとAIエージェントオーケストレーションパターンを参照してください。
A2Aプロトコルアーキテクチャ
A2Aは3つのコアコンセプトを定義しています:エージェントカード(能力発見)、タスクライフサイクル(状態付きデリゲーション追跡)、デリバリーモード(SSEストリーミングとWebhookプッシュ)。
エージェントカード:能力広告と列挙リスク
エージェントカードは、既知のURL(/.well-known/agent.json)で提供されるJSONドキュメントで、エージェントができることを説明します。最小限のエージェントカードには以下が含まれます:
{
"name": "web-research-agent",
"description": "ウェブ検索でトピックを調査し、構造化されたサマリーを返す",
"version": "1.0.0",
"url": "https://agents.example.com/web-research",
"skills": [
{
"id": "research_topic",
"name": "トピック調査",
"description": "トピックについてウェブを検索し、構造化されたサマリーを返す",
"inputModes": ["text"],
"outputModes": ["text", "data"]
}
],
"authentication": {
"schemes": ["bearer"]
}
}
エージェントカードは動的な能力発見を可能にしますが、セキュリティリスクを伴います:A2Aベースプロファイルでは、エージェントカードはデフォルトで認証なしで提供され、スキルの全表面が認証なしで列挙にさらされます。
本番環境では、認証後にのみエージェントカードを提供するか、内部ネットワークセグメントに制限すべきです。AIエージェントセキュリティの脅威モデルでは、能力列挙を偵察攻撃ベクターとして扱っています。
タスクライフサイクル:送信から完了まで5つの状態
A2Aは5状態のタスクライフサイクルを定義しています:
- submitted - リモートエージェントがタスクを受信済み;まだ処理に取り込まれていない
- working - リモートエージェントがタスクを積極的に処理中(SSE経由でプログレスをストリーミングできる)
- input-required - リモートエージェントが処理前に説明を必要とする(ヒューマン・イン・ザ・ループゲート)
- completed - タスク完了;結果アーティファクトが取得可能
- failed - タスク失敗;タスクステータスオブジェクトにエラー詳細
input-required状態は、長い自律パイプラインにおけるヒューマン・イン・ザ・ループチェックポイントのためのA2Aのメカニズムです。
プッシュ対プル型タスクデリバリー:SSEとWebhook
A2Aはタスク結果のデリバリーに2つのモードをサポートしています:
SSE(Server-Sent Events): 委任エージェントが受信エージェントのストリーミングエンドポイントへの永続的な接続を開きます。SSEは増分プログレスが必要な長時間タスクの主要メカニズムです。
Webhookプッシュ: 委任エージェントが送信時にコールバックURLを提供します。サーバーレス環境など永続的なSSE接続を維持できない場合に推奨されます。
A2A対MCP:異なる層、異なる問題
A2AとMCPは競合するものではなく、補完的なものです。エージェントスタックの異なる層で動作し、異なる調整問題を解決します。
| 次元 | MCP | A2A |
|---|---|---|
| 目的 | ツールアクセス - LLMが外部APIを呼び出す | エージェント調整 - エージェントが別のエージェントに委任する |
| 通信 | 1つの推論ターン内での同期ツール呼び出し | 非同期タスク委任;受信エージェントは独自ループを持つ |
| Auth(デフォルト) | 必須 - MCPサーバーはクライアントを認証 | ベースプロファイルではオプション - 匿名許可 |
| 発見 | MCPサーバーマニフェスト(ツールリスト) | エージェントカード(JSON:スキル+Auth要件) |
| 状態 | ツール呼び出しごとにステートレス | ステートフル、5状態ライフサイクル |
| ストリーミング | コア仕様には含まれない | リアルタイム用SSE;非同期用Webhookプッシュ |
| 主な脅威 | ツールポイズニング(OWASP LLM07:2025) | タスクペイロードインジェクション、エージェントカード列挙 |
エージェントがツールを必要とする場合(MCP)
MCPは、単一エージェントが1つの推論ターン内で外部能力を呼び出す必要がある場合の正しい選択肢です。ツールは独自の推論ループを持ちません;関数を実行して値を返します。
エージェントが別のエージェントを必要とする場合(A2A)
A2Aは、タスクがピアエージェントの完全な推論能力を必要とする場合の正しい選択肢です。受信エージェントは独自のモデル、メモリ、ツールアクセス、マルチステップ推論ループを持ちます。
同じシステムでMCPとA2Aを一緒に使用する
本番のマルチエージェントシステムは通常、両方を使用します。オーケストレーターエージェントはA2Aを使用して専門エージェントに委任します。各専門エージェントはMCPを使用してツール呼び出しを行います。
A2A認証とセキュリティモデル
A2Aのセキュリティモデルには重大なギャップがあります:ベースプロファイルは認証をオプションにしています。A2Aタスクペイロードを通じたプロンプトインジェクションは、信頼できない呼び出し元からタスクを受け入れるA2Aデプロイメントに対するドキュメント化された攻撃クラスです。
A2Aシステムの攻撃対象:
1. タスクペイロードインジェクション: A2Aタスク送信のタスク説明と入力データはユーザー制御下にあります。
2. エージェントカード列挙: 非認証エージェントカードはスキルの全表面を公開します。
3. エージェント間信頼の前提: 出力検証なしにピアエージェントの結果を信頼する委任エージェントは、リレーインジェクションに対して脆弱です。
4. 匿名委任: 必須認証なしでは、ネットワーク上の任意の呼び出し元がA2Aエージェントにタスクを送信できます。
OpenLegionの見解:A2Aはワイヤーフォーマットであり、セキュリティモデルではない
A2Aはワイヤーフォーマットとして優れた設計です。セキュリティモデルは本番要件に達していません。
OpenLegionのエージェント間通信アプローチは、A2Aのベースプロファイルがオプションとしているものを強制します:
-
すべてのエージェント間呼び出しはクレデンシャルボルトを経由します。 匿名委任モードはありません。
-
56のネットワークチョークポイントでタスクペイロードをサニタイズ。 ユーザー制御コンテンツは、LLMコンテキストに到達する前にUnicode攻撃(双方向オーバーライドU+202A~U+202E、タグ文字U+E0000~U+E007F、ゼロ幅文字)についてサニタイズされます。
-
オーケストレーターが検証する型付きハンドオフコントラクト。 不正なペイロードはハンドオフ境界でブロックされます。
-
エージェント能力マニフェストにアクセスするには認証が必要。 スキル表面は匿名呼び出し元に公開されません。
A2Aの実装:技術的なウォークスルー
エージェントカードスキーマ
本番エージェントカードは、デフォルトに依存せず、明示的に認証要件を含めるべきです:
{
"name": "data-analysis-agent",
"description": "構造化データセットを分析し、可視化付き統計サマリーを返す",
"version": "1.2.0",
"url": "https://agents.internal.example.com/data-analysis",
"skills": [
{
"id": "analyze_dataset",
"name": "データセット分析",
"description": "提供されたデータセットに対して統計分析を実行する",
"inputModes": ["data"],
"outputModes": ["text", "data", "file"]
}
],
"authentication": {
"schemes": ["bearer"],
"required": true
}
}
タスク送信とステータスポーリング
タスク送信は/tasks/sendへのPOSTです。ステータスポーリングはGET /tasks/{task_id}を使用します。指数バックオフ(1s、2s、4s、8s、最大30s)でポーリングします。長時間タスク(>60s)はSSEに切り替えるべきです。
SSEによる長時間タスクのストリーミング
30秒以上の予想タスクには、POST /tasks/sendSubscribe経由のSSEを使用します。"final": trueフラグはタスク完了を示します。接続切断後に再開するため、Last-Event-IDヘッダーを使用してSSE再接続を実装します。
よくある質問
Agent2Agent(A2A)プロトコルとは何ですか?
Agent2Agent(A2A)は、AIエージェントの相互運用性のためのオープンなHTTP/JSONプロトコルで、2025年4月にGoogle Cloudによって立ち上げられ、Linux Foundationに寄贈されました。異なるフレームワーク上に構築された自律エージェントが能力を広告し、タスクを委任し、結果を交換する方法を標準化します。Salesforce、Atlassian、SAPを含む50以上の組織が2025年4月の立ち上げ以来プロトコルに貢献しています。
A2AとMCPの違いは何ですか?
MCPはツールアクセスを解決します:単一エージェントが1つの推論ターン内で外部APIを呼び出す(ステートレスな関数呼び出し)。A2Aはエージェント調整を解決します:あるエージェントが独自の推論ループ、メモリ、ツールを持つピアエージェントにサブタスク全体を委任する(ステートフルな非同期委任)。MCPはデフォルトで認証を必要とします;A2Aのベースプロファイルはそれをオプションにします。2つのプロトコルは補完的です。
A2Aエージェントカードとは何ですか?
エージェントカードは/.well-known/agent.jsonで提供されるJSONドキュメントで、エージェントの能力、受け入れ入出力モード、認証要件を説明します。A2Aベースプロファイルでは、デフォルトで認証なしで提供されます(スキルの全表面がエンドポイントに到達できる任意の呼び出し元に見える)。本番デプロイメントは、エージェントカードへのアクセスに認証を要求するべきです。
A2Aプロトコルは安全ですか?
A2Aのベースプロファイルには重大なセキュリティギャップがあります。認証はデフォルトでオプションです。A2Aタスクペイロードによるプロンプトインジェクションはリアルな本番リスクです。本番A2Aデプロイメントは、拡張認証プロファイルを明示的に実装し、LLMに到達する前にすべてのタスクペイロードコンテンツをサニタイズし、すべてのハンドオフ境界で出力を検証する必要があります。
A2Aタスクライフサイクルとは何ですか?
A2Aは5つのタスク状態を定義しています:submitted(受信済み、まだ処理されていない)、working(アクティブ処理中、SSEプログレスをストリーミングできる)、input-required(リモートエージェントが処理前に説明を必要とする - ヒューマン・イン・ザ・ループゲート)、completed(結果が取得可能)、failed(エラー詳細付きでタスク失敗)。input-required状態は、自律パイプラインのヒューマン・イン・ザ・ループチェックポイントを表面化するためのA2Aのメカニズムです。
どの企業がA2Aをサポートしていますか?
A2Aは2025年4月にSalesforce、Atlassian、SAPを含む50以上の貢献組織と共に立ち上げられました。Google Cloudが初期仕様をリードし、ガバナンスをLinux Foundationに移管しました。プロトコルは、異なるフレームワーク(LangGraph、CrewAI、AutoGen、カスタム実装)上に構築されたエージェントがベンダーロックインなしに相互運用する必要があるエンタープライズAIプラットフォームをターゲットにしています。
OpenLegionはエージェント間通信をどのように実装していますか?
OpenLegionのメッシュアーキテクチャは、すべての呼び出しに必須認証を持つエージェント間調整を実装しています - 匿名委任モードはありません。すべてのエージェント間ハンドオフはクレデンシャルボルトを経由し、呼び出し元IDを検証し、タスクが受信エージェントに到達する前にエージェントごとのACLゲートを強制します。タスクペイロードコンテンツは56のネットワークチョークポイントでUnicode攻撃についてサニタイズされます。これらのコントロールはエージェントのコードの外側、インフラストラクチャ層で実行されます。
すべての呼び出しで認証を持つマルチエージェントシステムを構築する
A2Aはフレームワークとベンダー間のエージェント相互運用性のためのワイヤーフォーマットを提供します。セキュリティモデル(認証、ペイロードサニタイズ、出力検証)は、上に構築するかインフラストラクチャ層によって強制される必要があります。
エージェント間呼び出しが実際のクレデンシャルを運び、機密データにアクセスし、または不可逆なアクションをトリガーするシステムでは、インフラストラクチャ層の強制が唯一の信頼できる保証です。完全な脅威分類についてはAIエージェントセキュリティと脅威モデルを、調整パターンについてはマルチエージェントシステムアーキテクチャを参照してください。
すべてのエージェント間呼び出しがデフォルトで認証、ログ記録、クレデンシャル分離されたマルチエージェントシステムを実行する - OpenLegionで始める