AWSがAIエージェントの「どこに何があるか分からない」問題に挑む — 社内カタログからマルチクラウド横断へ、オープン仕様「ARD」とは

8月25日、AWSが「Agentic Resource Discovery (ARD): An open specification for agent discovery」と題した記事を公開した。この記事では、マルチエージェント環境における横断的なリソース発見を可能にするオープン仕様「ARD（Agentic Resource Discovery）」と、それを活用するAWS Agent Registryについて詳しく紹介されている。

「どこに何があるか分からない」問題

AIエージェントの活用が広がるにつれ、組織内にMCP（Model Context Protocol）サーバー、エージェント、専用ツールが乱立し始めている。問題はカタログが存在しないことだ。開発者はリソースを個別に探し、検証し、接続し、その接続を手動で維持しなければならない。あるAIクライアント向けに設定したエージェントが、別のクライアントからは見えない——という状況も当然のように発生する。

数個のツールを手動で繋ぎ合わせる時代なら許容できた。しかし公開レジストリと社内インフラに散らばるエージェント、MCPサーバー、スキル、APIの数が増え続ける今、そのやり方はスケールしない。

AWS Agent Registry：まず「社内」を整理する

AWSはAWS Agent Registry（現在プレビュー）を提供している。組織内のエージェント・MCPサーバー・ツール・カスタムリソースを一元管理する検索可能なカタログだ。

構成要素は2つ。

Registry（レジストリ）：AWSアカウント上に作成するカタログ。承認設定やアクセス制御を個別に持つ。クロスアカウント共有により、AWS Organization全体に提供できる。
Registry Record（レコード）：個々のリソースを表すエントリ。「何者で、何をして、どこにいるか」を記述したメタデータを格納する。

ワークフローはシンプルだ。

管理者がレジストリを作成し、承認フローと認証（IAMまたはJWT）を設定する
パブリッシャーがMCPサーバーやエージェントをレコードとして登録・申請する
キュレーターが申請を審査し、承認・却下・廃止を管理する
コンシューマー（人間またはAIエージェント）が承認済みリソースを検索・利用する

エンタープライズ向けの機能として、セマンティック検索とキーワード検索を組み合わせたハイブリッド検索、MCP互換エンドポイント経由でのアクセス、IAMおよびJWTによる柔軟な認証制御を備える。

本命はここ：クロス環境を解決するオープン仕様「ARD」

AWS Agent Registryが解決するのは、あくまでAWS環境内の発見問題だ。現実のエンタープライズはマルチクラウド、オンプレミス、SaaSプラットフォームにまたがって動いている。環境ごとに独自のレジストリ、命名規則、メタデータスキーマを持つ。

この状況で全環境を繋ごうとすると、レジストリの組み合わせ分だけ専用コネクタが必要になる。

AWSが推進するのが**ARD（Agentic Resource Discovery）**だ。Apache License 2.0のオープン仕様としてGitHubでも公開されており、AWSは仕様策定に主導的な立場で関与している。

ARDのコンセプトは、DNSがネットワーク間の名前解決を可能にしたように、レジストリ間の連携を可能にすることだ。インターネット上でドメイン名からIPアドレスを引けるのは、あらゆるDNSサーバーが共通プロトコルに従って問い合わせに応答するからであり、ARDもこれと同じ発想を取る。共通プロトコルを持つことで、個々のレジストリは二者間の個別合意や独自コネクタなしに相互参照できる——このモデルを「フェデレーション」と表現している。

ARDのスキーマと仕様の概要

ARDはリソース（エージェント、MCPサーバー、ツールなど）を共通フォーマットで記述するためのスキーマを定義している。レコードは典型的にJSON形式で表現され、リソースの識別子・種別・エンドポイントURL・capability（何ができるか）・認証方式といったフィールドを含む。概念的には以下のような構造を持つ。

{
  "id": "arn:aws:agent-registry:us-east-1:123456789012:record/my-agent",
  "type": "agent",
  "name": "my-data-analysis-agent",
  "endpoint": "https://example.com/mcp",
  "capabilities": ["data-analysis", "report-generation"],
  "auth": { "type": "iam" }
}

エンドポイントはMCP互換であり、ARD互換クライアントはこの仕様に沿ったレコードを取得・解釈することで、レジストリ実装の違いを意識せずにリソースへ接続できる。詳細なスキーマ定義はARD公式サイトおよびGitHubリポジトリで参照できる。

ARDが組織にもたらす3つの効果

ARDが組織にもたらす効果として記事では3点が挙げられている。

移行なしにフェデレーション：マルチクラウド・オンプレ・SaaSのリソースを同一フォーマットで公開し、横断的な発見を実現する
グローバルに発見、ローカルで制御：カタログの内容・公開範囲・アクセス取り消しは公開元の組織が管理する。AWS Agent Registryの既存アクセス制御がそのまま適用され、ARDは相互運用レイヤーとして機能する
組織をまたいだ公開発見：組織が自社ドメイン上にカタログを公開すれば、ARD互換クライアントからそのまま発見できる

まとめ

AIエージェントが組織内で増殖し始めた今、「どのエージェントが何をできるか」を管理する仕組みは後回しにされがちな領域だ。AWS Agent Registryは社内のカタログ管理を、ARDはそれをマルチ環境に拡張する相互運用レイヤーを担う。ARDがApache License 2.0のオープン仕様として策定されている点は、特定ベンダーへのロックインを避けたいエンジニアには評価できる設計方針だ。

詳細はAgentic Resource Discovery (ARD): An open specification for agent discoveryを参照していただきたい。