Agent2Agent 入門 (3) - キーコンセプト

「Agent2Agent」のキーコンセプトをまとめました。

前回

1. はじめに

「Agent2Agent」(A2A)は、エージェント間の相互作用を定義する一連のコアコンセプトに基づいて構築されています。

2. コアアクター

2-1. ユーザー

リクエストを開始するエンドユーザー (人間または自動サービス) です。

2-2. A2Aクライアント (クライアントエージェント)

ユーザーに代わってリモートエージェントにアクションまたは情報を要求するAIエージェントです。クライアントはA2Aを使用して通信を開始します。

2-3. A2Aサーバ (リモートエージェント)

A2Aを実装したHTTPエンドポイントを公開するAIエージェントです。クライアントからのリクエストを受け取り、タスクを処理し、結果またはステータスの更新を返します。リモートエージェントはクライアントの観点からはブラックボックスとして動作します。つまり、クライアントはリモートエージェントの内部動作、メモリ、ツールについて知る必要はありません。

3. 基本的なコミュニケーション要素

3-1. Agent Card

「Agent Card」は、A2Aサーバの情報を記述するJSONです。通常は既知のURL (例 : /.well-known/agent.json) で検出します。

エージェントID (名前、説明)、サービスエンドポイントURL、バージョン、サポートされているA2A機能、提供されるスキル、デフォルトの入出力方式、認証要件などが記述されています。

クライアントは「Agent Card」でエージェントを検出し、やり取りする方法を理解します。

3-2. Task

クライアントがエージェントにメッセージを送信すると、エージェントはリクエストを処理するにはステートフルな「Task」 (例 : 「レポートの作成」、「航空券の予約」、「質問への回答」) を完了する必要があると判断する場合があります。

各タスクにはエージェントによって定義された一意のIDが付与され、定義されたライフサイクル (例 : submitted, working, input-required, completed, failed) に従って処理が進められます。

タスクはステートフルであり、クライアントとサーバ間で複数のメッセージ交換が行われる場合があります。

3-3. Message

「Message」は、クライアントとエージェント間の通信の1ターンを表します。

「Message」には「role」 (クライアントは「user」、サーバは「agent」) があり、実際のコンテンツを運ぶ1つ以上の「Part」が含まれます。MessageのmessageIdは、Messageの送信者が設定した各メッセージの一意の識別子です。

必ずしも正式な「Artifact」ではない指示、コンテキスト、質問、回答、またはステータス更新を伝えるために使用されます。

3-4. Part

「Part」は、「Message」または「Artifact」内のコンテンツの基本単位です。各Partには特定のタイプがあり、異なる種類のデータを運ぶことができます。

3-5. Artifact

「Artifact」は、タスク処理中にリモートエージェントによって生成される具体的な出力または結果を表します。

例としては、生成されたドキュメント、画像、スプレッドシート、構造化データの結果、またはタスクの直接的な結果として得られるその他の自己完結的な情報などが挙げられます。

「Artifacts」は1つ以上の「Part」で構成され、段階的にストリーミングできます。

4. 相互作用メカニズム

4-1. リクエスト/レスポンス (ポーリング)

・クライアントはリクエストを送信し (例：message/send RPCメソッドを使用)、サーバからのレスポンスを受け取ります。
・やり取りにステートフルな長時間実行タスクが必要な場合、サーバは最初に「working」ステータスで応答する可能性があります。その後、クライアントはタスクが終了状態 (例：completed, failed) に達するまで、定期的にtasks/getを呼び出して更新情報をポーリングします。

4-2. ストリーミング (Server-Sent Events - SSE)

・段階的に結果を生成したり、リアルタイムで進行状況を更新したりするタスク向けです。
・クライアントは、message/stream を使用してサーバとのやり取りを開始します。
・サーバは、開いたままの HTTP 接続で応答し、その接続を介して Server-Sent Events (SSE) のストリームを送信します。
・これらのイベントは、Task、Message、TaskStatusUpdateEvent (ステータス変更の場合)、または TaskArtifactUpdateEvent (新規または更新されたアーティファクト チャンクの場合) のいずれかです。
・この場合、サーバはAgent Cardでストリーミング機能をアドバタイズする必要があります。
・詳しくは Streaming & Asynchronous Operations を参照してください。

4-3. プッシュ通知

・非常に長時間実行されるタスクや、SSE などの永続的な接続を維持することが困難なシナリオ向けです。
・クライアントは、タスク開始時 (または tasks/pushNotificationConfig/set を呼び出す) に Webhook URL を提供できます。
タスクのステータスが大幅に変化した場合 (completes, fails, requires input など)、サーバはクライアントが提供したこの Webhook に非同期通知 (HTTP POST リクエスト) を送信できます。
・そのためには、サーバがAgent Cardで pushNotifications 機能をアドバタイズする必要があります。
・詳しくは Streaming & Asynchronous Operations を参照してください。

5. エージェントの応答：タスクまたはメッセージ

詳しくは Life of a Task を参照してください。

6. その他の重要な概念

・コンテキスト (contextId)
複数の関連する Task オブジェクトを論理的にグループ化し、一連のインタラクション全体にわたってコンテキストを提供するために使用できる、サーバによって生成される識別子です。

・トランスポートとフォーマット
A2A 通信は HTTP(S) 経由で行われます。すべてのリクエストとレスポンスのペイロード形式として、JSON-RPC 2.0 が使用されます。

・認証と承認
A2A は標準的な Web セキュリティ手法に基づいています。認証要件はエージェントカードで宣言され、資格情報 (OAuth トークン、API キーなど) は通常、A2A プロトコルメッセージ自体とは別に、HTTP ヘッダーを介して渡されます。
詳しくは Enterprise-Ready Features を参照してください。

・エージェント検出
クライアントがAgent Cardを検索し、利用可能な A2A サーバとその機能を確認するプロセスです。
詳しくは Agent Discovery を参照してください。

・拡張機能
 A2A を使用すると、エージェントは AgentCard の一部としてカスタムプロトコル拡張機能を宣言できます。
その他のドキュメントは近日公開予定です。

これらのコア コンポーネントとメカニズムを理解することで、開発者は A2A を効果的に設計、実装、活用し、相互運用性と協調性に優れた AI エージェント システムを構築できます。

次回