Agent2Agent 入門 (5) - Agent Discovery
「Agent2Agent」の「Agent Discovery」についてまとめました。
前回
1. A2Aにおけるエージェント検出
AIエージェントが「Agent2Agent」(A2A) プロトコルを用いて連携するには、まず互いのエージェントを検出し、それぞれのエージェントが提供する機能を理解する必要があります。「A2A」は、「Agent Card」を通じてエージェントの自己記述の形式を標準化しています。ただし、これらの「Agent Card」を検出する方法は、環境や要件によって異なります。
2. Agent Card の役割
「Agent Card」は、A2Aサーバ (リモートエージェント) のデジタル「名刺」として機能するJSONドキュメントです。「Agent Card」は、検出とインタラクションの開始に不可欠です。「Agent Card」に通常含まれる主な情報は次のとおりです。
・ID
名前、説明、プロバイダー情報。
・サービスエンドポイント
A2Aサービスにアクセスできる URL。
・A2A 機能
ストリーミングやプッシュ通知などのサポートされているプロトコル機能。
・認証
エージェントとのやり取りに必要な認証スキーム。
(例: 「Bearer」、「OAuth2」)
・スキル
エージェントが実行できる特定のタスクまたは機能 (AgentSkill) のリスト。ID、名前、説明、入力モード、出力モード、例が含まれます。
クライアントエージェントは「Agent Card」を解析して、リモートエージェントが特定のタスクに適しているかどうか、そのスキルの要求をどのように構成するか、および安全に通信する方法を判断します。
3. 検出戦略
クライアントエージェントがリモートエージェントの「Agent Card」を検出する一般的な戦略を以下に示します。
3-1. Well-Known URI
パブリックエージェント、または特定のドメイン内での広範な検出を目的としたエージェントに推奨されるアプローチです。
・メカニズム
A2Aサーバは、ドメイン内の標準化された「既知の」パスに「Agent Card」をホストします。
・標準パス
https://{agent-server-domain}/.well-known/agent.json
(既知のURIに関するRFC 8615の原則に準拠)。
・プロセス
・クライアントエージェントは、潜在的なA2Aサーバのドメイン (例：smart-thermostat.example.com) を認識しているか、プログラムによって検出します。
・クライアントは、https://smart-thermostat.example.com/.well-known/agent.jsonに対してHTTP GETリクエストを実行します。
・「Agent Card」が存在しアクセス可能な場合、サーバはJSONレスポンスとしてそれを返します。
・利点
シンプルで標準化されており、ドメインを解決できるクローラーやシステムによる自動検出が可能です。「エージェントのドメインを見つける」という検出の問題を効果的に軽減します。
・考慮事項
オープンな検出、またはドメインを管理する組織内での検出を目的としたエージェントに最適です。「Agent Card」を提供するエンドポイントでは、カードに機密情報が含まれている場合、それ自体に認証が必要になることがあります。
3-2. キュレーションされたレジストリ (カタログベースの検出)
エンタープライズ環境、マーケットプレイス、または特殊なエコシステムでは、「Agent Card」を中央レジストリまたはカタログに公開し、それを介して検出することができます。
・メカニズム
仲介サービス (レジストリ) が「Agent Card」のコレクションを管理します。クライアントは、このレジストリにクエリを実行し、様々な基準 (提供スキル、タグ、プロバイダー名、必要な機能など) に基づいてエージェントを検索します。
・プロセス
・A2Aサーバ (またはその管理者)は、「Agent Card」をレジストリサービスに登録します。この登録メカニズムは、A2Aプロトコル自体の範囲外です。
・クライアントエージェントは、レジストリのAPIにクエリを実行します。（例：「ストリーミングをサポートする「画像生成」スキルを持つエージェントを検索する」）
・レジストリは、一致する「Agent Card」のリストまたはそれらへの参照を返します。
・メリット
・利用可能なエージェントの一元管理、キュレーション、ガバナンス。
・ドメイン名だけでなく、機能に基づいた検出を容易にします。
・レジストリレベルでアクセス制御、ポリシー、信頼メカニズムを実装できます。
・企業固有またはチーム固有のエージェントカタログや、A2A準拠エージェントのパブリックマーケットプレイスなどのシナリオを可能にします。
・考慮事項
追加のレジストリサービスが必要です。A2Aプロトコルでは、現在、このようなレジストリ用の標準APIは定義されていませんが、これは将来的な調査とコミュニティによる標準化の対象となる可能性があります。
3-3. 直接設定 / プライベート検出
多くのシナリオ、特に密結合システム内、プライベートエージェント、または開発およびテスト中は、クライアントはエージェントカード情報またはそれを取得するためのURLを使用して直接設定されることがあります。
・メカニズム
クライアントアプリケーションは、「Agent Card」の詳細情報をハードコードしており、ローカル構成ファイルから読み取るか、環境変数を介して受け取るか、クライアントが認識しているプライベートな独自APIエンドポイントから取得します。
・プロセス
これは、アプリケーションのデプロイメントおよび構成戦略に大きく依存します。
・利点
エージェント間の既知の静的な関係がある場合、または動的な検出が不要な場合には、シンプルかつ効果的です。
・考慮事項
新規または更新されたエージェントを動的に検出する場合の柔軟性は低くなります。「Agent Card」を変更すると、クライアントの再設定が必要になる場合があります。独自APIベースの検出は、A2Aによって標準化されていません。
4. Agent Card のセキュリティ保護
「Agent Card」自体に、保護すべき情報が含まれる場合があります。
例えば、次のような情報です。
・社内専用またはアクセス制限のあるエージェントのURL。
・スキーム固有の非機密情報 (OAuthトークンURLなど) に使用される場合のauthentication.credentialsフィールドの詳細。「Agent Card」にプレーンテキストの機密情報をそのまま保存することは強く推奨されません。
・機密性の高いスキルや社内スキルの説明。
4-1. 保護メカニズム
・エンドポイントのアクセス制御
「Agent Card」を提供する HTTP エンドポイント (/.well-known/agent.json パス、レジストリ API、カスタム URL のいずれであっても) は、カードがパブリックの認証されていないアクセスを想定していない場合は、標準的な Web プラクティスを使用してセキュリティ保護する必要があります。
・mTLS
信頼モデルに適切な場合は、クライアント認証に相互 TLS を要求します。
・ネットワーク制限
特定の IP 範囲、VPC、またはプライベートネットワークへのアクセスを制限します。
・認証
「Agent Card」自体へのアクセスには、標準の HTTP認証 (例：OAuth 2.0 ベアラートークン、API キー) を要求します。
・レジストリによる選択的な開示
エージェントレジストリは、認証されたクライアントのIDと権限に基づいて、異なる「Agent Card」や様々な詳細レベルを返すロジックを実装できます。例えば、パブリッククエリでは限定的なカードが返される一方、認証されたパートナークエリではより詳細な情報を含むカードが返されるといった具合です。
「Agent Card」に機密データ (繰り返しますが、シークレットには推奨されません) が含まれている場合、カード自体を強力な認証と認可なしに利用できないようにすることが重要です。A2Aプロトコルでは、「Agent Card」に埋め込まれた静的なシークレットに頼るのではなく、クライアントが帯域外で動的な認証情報を取得する認証スキームが推奨されています。
