代理工具
AWS、ARDフェデレーション型ディスカバリー仕様を紹介:すべてのschemaをコンテキストに詰め込まず、エージェントが先にツールを検索
ARDは、統一されたREST検索インターフェースと`ai-catalog.json`を通じて、エージェント、MCP server、Skills、API、ワークフローを記述する。AWSはこれをAgent Registryのクロスクラウド相互運用レイヤーと位置付けている。ただし、仕様は現在もv0.9 Proposalであり、アイデンティティ、ランキング、実際の認可はディスカバリーレイヤーでは統一的に処理されない。

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間のページネーションと失効セマンティクスを提供するか、また検索ランキングと権限フィルタリングについて異なるベンダー間で相互運用できるかを注視する必要がある。