AIエージェントやMCPサーバーが増えるほど、そもそも何が使えるのかを人が把握しきれなくなります。この探す側の困りごとだけに絞った共通仕様が、Agentic Resource Discovery、略してARDです。Apache License 2.0のオープン仕様として公開され、Google、Microsoft、GitHub、NVIDIAなど11社の技術者が設計とレビューに参加しています。Amazon Web Servicesも策定に意見を寄せ、自社のAWS Agent Registryとどう組み合わせるかを8月24日に公表しました[1]。
足りないのは道具ではなく道具の索引です
いまAIクライアントが呼び出せるものは、モデルが記憶している知識だけではありません。ツール、Skill、MCPサーバー、API、ワークフロー、他のエージェント。ARDの文書では、これらをまとめてエージェンティックリソースと呼んでいます。
問題は、その数が増える速さに人の手が追いついていないことです。誰かが見つけ、使えるかどうかを判断し、クライアントにつなぎ、そのつなぎ方を保守し続ける。有名なツールが数個しかない時代なら回りますが、社内チームもベンダーも個人も公開する時代になると、この作業が一気に重くなります。しかも、あるクライアント向けに設定したからといって、別のクライアントからも使えるようにはなりません。
つまり詰まっているのは呼び出しの部分ではなく、その手前の発見です。クライアントは存在を知らない機能を使えませんし、社員全員に社内ツールと承認済みサービスの一覧を暗記させるわけにもいきません。
ARDが決めているのは検索の入口だけです
ARDの担当範囲は、意外なほど狭く切られています。クライアントが投げる質問は1つで、この作業に使えるリソースは何か、というものです。返ってくるのは、それが何をするか、誰が提供しているか、どこにあるか、どうやって到達するか、という情報の集まりです。
そこから先、実際に呼び出す部分はARDの管轄外です。MCPでもAPIでもエージェントフレームワークでも、選んだリソース自身の方式に任せます。ARDは呼び出しの手前に座る層だと考えると分かりやすいはずです。
検索インターフェースは3つのエンドポイントで定義されています。
| エンドポイント | 役割 | 扱い |
|---|---|---|
| POST /search | 作業内容からリソースを探す | 必須 |
| POST /explore | 一覧を絞り込んで眺める | 任意 |
| GET /agents | 収録項目を取り出す | 任意 |
リソースそのものの記述には、ARDエントリと呼ばれる記述単位を使います。仕様v0.91ではJSON-LDのノードとして定義され、何をするか、誰が出しているか、どこにあるか、どう到達するかを、種類の違うリソースでも同じ書き方で表現できるようになっています[2]。公開する側は自分のドメインの/.well-known/ard.jsonにエントリを置きます。前身の仕様が使っていた/.well-known/ai-catalog.jsonは互換のために参照してもよい旧名という位置づけで、現行版ではard.jsonへの移行が推奨されています[2]。
収録範囲の決め方や並び順、ホスティング、課金モデルはARDが指定しません。ウェブ上のものを何でも拾う広い集合でも、承認済みだけを載せた厳選集合でも構いません。仕様側も、企業が実際に使うのは後者だろうと見込んでいます。
実装する側と、つなぐ側
このインターフェースを備えた集合体を、ARDの仕様ではAgent Registryと呼びます。実際には「エージェントファインダー」の名前で表に出ることが多く、GitHubのAgent Finder、Hugging FaceのDiscover Tool、CiscoのAI Catalog、Ora Directory、そして自分のサーバーに置けるANS Finderが公式の実装例として挙がっています[3]。
利用する側は、Claude、ChatGPT、GitHub Copilot、Microsoft Copilot、Geminiといったクライアントから、Skillかリモート MCP コネクター経由でエージェントファインダーに接続します。作業に使える機能を探すよう頼めば、候補が並び、何を入れるかは利用者が決める流れです。
AWSは社内カタログの側から寄せてきました
AWSが同じタイミングで押し出しているのが、AWS Agent Registryです。こちらは組織内のカタログで、レジストリとレジストリレコードという2階層で組み立てられています。
運用の流れは4段階です。管理者がレジストリを作り、承認設定とIAMまたは社内IDプロバイダー発行のJWTによる認可を設定する。公開者が自分のMCPサーバーやエージェントをレコードとして登録し、承認に出す。キュレーターが審査して承認や却下を行い、使われなくなったものを非推奨にする。そして利用者、これは人でもエージェントでもよいのですが、必要なリソースを検索する。
検索は意味の理解とキーワード一致を組み合わせたハイブリッド型で、自然文の問い合わせでも正確な名前引きでも通ります。レジストリ自体がリモートMCPエンドポイントとして提供されるため、MCP対応クライアントからそのまま叩ける点も特徴です。クロスアカウント共有を使えば、1つのレジストリでAWS Organization全体をまかなえます。
例えとして持ち出されたのはDNSです
ただし、レジストリが社内に閉じている限り、環境をまたいだ検索は解けません。複数のクラウド、オンプレミス、SaaS、業務アプリがそれぞれ独自の書式と命名規則でカタログを持っていると、つなぎたい組み合わせの数だけ専用コネクターが必要になります。
AWSがARDに期待しているのは、まさにこの部分です。同社の説明では、ネットワーク越しの名前解決をDNSが引き受けているのと同じ関係を、レジストリ同士の連合に持ち込むイメージだとされています。各環境のカタログが共通のプロトコルで窓口を出していれば、二者間の取り決めを積み上げなくても横断検索が成立します。
移さずに連合する、発見は広く制御は手元に残す、そして自社ドメインでカタログを公開すれば組織の外からも見つけてもらえる。AWSが挙げている3つの狙いは、いずれも既存の権限管理を動かさないことを前提にしています。
まとめ
ARDは製品ではなく、発見の部分だけを切り出したオープンな取り決めです。範囲を検索の入口に限ったぶん、既存のMCPやAPIとぶつからずに載せられる設計になっています。11社の名前が並んだ時点で、エージェントの数が増え続けることは前提として共有されたと見てよさそうです。あとは、実際に自社のカタログをこの形式で出す会社がどれだけ現れるかにかかっています。仕様の良し悪しより、載る中身の量で決まる類の標準だと思います。
出典:https://agenticresourcediscovery.org/spec/
出典:https://agenticresourcediscovery.org/ref_implementations/
