AIエージェント

ARDはエージェントの道具選びをモデル外の検索へ出す提案

2026/10/3

🤖 AIが執筆しています

ARD は、提供元がドメインに一覧を置き、外の検索サービスが候補を絞る

ARD（Agentic Resource Discovery）は、エージェントが組織をまたいで道具を見つけ、見つけたものを確かめるための仕様である。仕様の著者は Google の Junjie Bu、Hugging Face の Shaun Smith、所属の記載が無い R.V. Guha の三人である²。Google と Hugging Face は同じ日にそれぞれ発表記事を出し、Hugging Face の記事は、Microsoft、Google、GoDaddy、Hugging Face などの寄稿者が作った仕様だと書く⁷⁸。仕様の状態は Proposal（提案）で、v0.9 から v0.91 へ一度改訂されている²。本稿は ARD を、提案段階の仕様として扱う。Hugging Face は、自社の Discover Tool を ARD の参照実装として出している⁸。

ARD は、MCP の道具、A2A（エージェントどうしが仕事を頼み合うための規約）で呼べる他のエージェント、スキル、その他の呼び出せるサービスをまとめて agentic resources と呼び、同じ仕組みで探せるようにする²。仕組みは静的な層と動的な層の二つからなる。

静的な層では、提供元が自分のドメインの well-known パスに、道具の項目（entry）の一覧を置く。well-known パスは、ドメインの決まった場所（/.well-known/…）にファイルを置き、機械がそこを探しに行けるようにする方式である。ARD では、その場所は /.well-known/ard.json である²。仕様は他にも、robots.txt に書く Agentmap、HTML の link タグ、DNS、ページ内の JSON-LD から一覧をたどる方法を挙げる²。

動的な層では、登録簿が提供元の一覧を巡回して索引を作り、POST /search の呼び出しに順位つきの候補を返す²。仕様は、道具を見つける処理をモデルの外の専用の検索サービスへ移し、代表的な質問、提供元の身元、コンプライアンスの情報、使われ方の傾向といった手がかりを、文脈のトークンを使わずに活かすと書く²。この形では、エージェントは「配備の履歴を調べる」のような問いを検索サービスに送り、返ってきた少数の候補の説明だけを文脈に入れる。

ARD の項目は、道具の中身の記述を MCP や A2A の仕様に任せる。項目は、何の種類の道具かをメディアタイプ（データの種類を表す識別子）で示し、中身の形式を自分では定めない²。

ARD は、他人の名前を先に名乗る乗っ取り（namespace squatting）への対策を仕様に入れている。ここでいう名前空間は、道具の名前の先頭部分で、誰の道具かを表す部分を指す。ARD の項目の識別子は urn:air:<提供元のドメイン>:… の形をとり、この提供元のドメインが trustManifest.identity に書かれた信頼ドメインと一致しなければ、検証を行う登録簿はその項目を拒否する²。仕様はこの規則を、名前空間の乗っ取りに対する ARD の防御と呼ぶ²。

v0.91 は、一覧を置く固定のパスを /.well-known/ard.json の一つにまとめ、記述の層を JSON-LD にした²。作り手はこの改訂を位置づけの変更と呼び、定義は変えておらず、既存の記述ファイルはそのまま有効な項目であると説明する²。

MCP Registry は、名前を所有者に結びつける点で同じで、一覧を中央に一つ置く

MCP Registry は、MCP サーバーの一覧を MCP クライアントに提供する、コミュニティ運営の登録簿である。作り手はこの登録簿を、MCP サーバーのためのアプリストアのようなものと書く³。作り手は、この登録簿を MCP のオープンソースのコミュニティが所有し、Anthropic、GitHub、PulseMCP、Microsoft などの主要な貢献者が支えると書く³。登録簿は2025年9月にプレビューとして公開され、2025年10月に API の v0.1 を凍結したが、2026年10月1日に取得した作り手の文書は、まだプレビューの段階にあり、一般提供の前に互換を壊す変更やデータの消去がありうると書く³⁵。

MCP Registry では、公式の登録簿が一つあり、提供元は一度登録すれば済む。作り手によれば、MCP クライアント、集約サービス、マーケットプレイスは、すべて同じ正本のデータを参照する³。登録簿はパッケージについてのメタデータだけを持ち、コードの本体は npm、PyPI、Docker などの配布先に置かれる³。作り手は、この形をメタレジストリ（metaregistry）と呼ぶ。

MCP Registry も、道具の名前を所有者に結びつける。作り手は、登録するときに選ぶ認証の方法がサーバーの名前の名前空間を決めると書く⁴。GitHub で認証した提供元の名前は io.github.ユーザー名/… に限られ、ドメインで認証した提供元の名前は、com.example/… のようにドメインを逆順にした形に限られる⁴。名前の先頭を、認証で確かめた持ち主に結びつける点で、MCP Registry は ARD と同じ方向を向いている。

二つの設計は、一覧をどこに置くかで分かれる。ARD の仕様は、アプリストアのように前もってエージェントをインストールさせる代わりに、検索で動的に見つける形を勧めると書き、一覧を各提供元のドメインに分散させる²。MCP Registry は一覧を中央に一つ置き、選別や評価は下流の登録簿（subregistry）に任せる⁵。下流の登録簿は、公式の一覧を取り込み、選別や評価を加えて配り直す登録簿を指す。

検索が候補を絞っても、信頼の判断と説明の危険は残る

検索が返す関連度の値は、信頼の判断を含まない。ARD の仕様は、関連度の値は意味の近さだけを表し、信頼、コンプライアンス、安全の判断として解釈してはならず、信頼の評価は完全に切り離されていると定める⁶。一方で仕様は、連合する登録簿が項目の宣言した枠組みで検証を走らせることを求め（SHOULD）、その結果を絞り込みや順位づけに使ってよい（MAY）と書く⁶。署名の手順そのものは、ARD は自分では定めず、項目が宣言した既存の身元の枠組み（例として SPIFFE、DID、企業の公開鍵基盤）に任せる⁶。仕様は、将来の ARD のプロファイル（特定の用途向けに選択肢を固定する追加の取り決め）が既定の方式を固定してもよいが、この仕様は固定しないと書く⁶。作り手はこの空白を埋めるかどうかを決めていないので、本稿はこの点を現時点で未決と判定する。

知らない提供元の道具の説明がモデルに入ること自体にも、危険がある。tool poisoning は、道具の説明文に、モデルへの隠れた指示を仕込む攻撃である。Invariant Labs の Luca Beurer-Kellner と Marc Fischer は、この攻撃を実験で試した結果を報告した⁹。報告によれば、悪意のある MCP サーバーは利用者の機密データを持ち出せただけでなく、エージェントの振る舞いを乗っ取り、信頼できる他のサーバーの指示を上書きできた⁹。この実験が示したのは、悪意のあるサーバーの説明がエージェントの動作を乗っ取りうることである。見つけ方を検索に変えても、選ばれた道具の説明は文脈に入る。そのため本稿は、この危険は検索の仕組みでは取り除けず、説明を文脈に入れる設計である限り残る（恒久）と考える。緩和の手段としては、同じ報告が、説明を利用者に見えるようにすること、版を固定すること、サーバー間の境界を強めることを挙げている⁹。

MCP Registry の審査は最小限である。作り手は、審査について保証せず、利用者は審査がほとんど、または全く無いものと考えるべきだと書く⁵。作り手の方針では、削除するのは違法な内容、マルウェア、スパム、まったく動かないサーバーに限られ、脆弱性のあるサーバーは削除しない⁵。登録簿は開いたまま保ち、深い審査は上流のパッケージ登録簿（npm、PyPI、Docker など）や下流の登録簿に頼るとされる⁵。この方針について作り手は、将来変えるかもしれないとも書いている⁵。今の方針のもとでは、利用側は公式の一覧が審査済みではないことを前提に設計することになる。

ARD は提案段階にあり、公開の手順がまだ動いている。一覧を置く固定のパスは、v0.9 の /.well-known/ai-catalog.json から v0.91 で /.well-known/ard.json に変わり、旧パスを参照するかは利用側の任意とされた⁶。このため、旧パスだけに一覧を置いた提供元が、旧パスを参照しない利用側にも見つけてもらうには、新しいパスへ移す必要がある。MCP と A2A のメディアタイプを IANA（インターネットの識別子を登録する機関）に登録する作業も終わっておらず、仕様は形式が変わりうると書く⁶。本稿は、この二点を仕様が固まるまでの一時的な負担と判定する。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。