AWS、ARDフェデレーション型ディスカバリー仕様を紹介：すべてのschemaをコンテキストに詰め込まず、エージェントが先にツールを検索

AWSは8月24日、Agentic Resource Discovery（ARD）を公開紹介し、エージェントシステムの拡大に伴う「能力をどのように見つけるか」という課題の解決を試みた。現在のツール選択では通常、多数のツール説明とschemaをモデルのコンテキストに投入する。数が数千件に増えると、tokenを消費するだけでなく、選択品質もpromptの長さに左右される。ARDは候補の絞り込みを独立した検索サービスへ移し、モデルには現在のタスクに関連する少数の結果だけを渡す。

この仕様では、`/.well-known/ai-catalog.json`を通じてリソース一覧を公開し、MCP server、A2A agent、Skill、API、データセット、ワークフローを記述できる。各レコードはドメインにアンカーされた`urn:air:`識別子を使用し、IANA media typeによってリソース形式を区別する。完全な記述は、`url`またはインラインの`data`のいずれか一方で提供する。必須の`POST /search`はタスククエリを受け付け、`POST /explore`と`GET /agents`はオプションとなる。`representativeQueries`はregistryによるセマンティックインデックスの構築に利用でき、`trustManifest`にはSPIFFE、DID、証明書、provenance chain、JWS署名を関連付けられる。

技術的にARDが扱うのは「ディスカバリー」のみであり、MCPやA2Aの呼び出しプロトコルを置き換えるものではない。また、リソースの検証、認可、実行も担わない。AWSによると、同社のAgent RegistryではIAMまたは企業向けJWTを使用して、レコード、承認、検索を管理できる。一方ARDは、クラウドや社内registryが共通形式で相互にインデックスを作成できるようにし、個別の二者間connectorを一つずつ実装する必要をなくす可能性がある。

エンジニアリングチームは、現時点でこれを確定済みの標準として扱うべきではない。公開文書では依然としてv0.9 Proposalとされ、一部のmedia typeは正式登録待ちであり、主要な信頼関連フィールドもオプションである。今後は、AWSが検証可能なネイティブARDインポート／エクスポート、registry間のページネーションと失効セマンティクスを提供するか、また検索ランキングと権限フィルタリングについて異なるベンダー間で相互運用できるかを注視する必要がある。