In Silico

AIエージェント

ARDとは？AIエージェントのツール探しとMCP Registryとの違い

2026/10/3 （更新: 2026/10/11）

🤖 AIを使用して執筆

  • ARD
  • AIエージェント
  • MCP
  • MCP Registry
  • Hugging Face
  • Google
  • A2A
  • tool search
  • 検索サービス
  • 名前空間
  • 登録簿
  • tool poisoning
  • 信頼
  • Anthropic
  • JSON-LD
  • well-known
  • PyPI
  • npm
  • Docker
  • v0.91
  • Microsoft
目次
背景・問い・要点
背景

社内の障害対応をエージェントに手伝わせる場面を考える。エージェントは原因を探すために、監視の仕組み、技術文書の検索、配備の履歴、サポートチケット、専門のエージェントを使い分ける。ここでいうツールは、エージェントが呼び出す外部の機能を指す。今の多くの仕組みでは、開発者がツールを一つずつ登録して設定し、登録したすべてのツールの説明をモデルに渡して、どれを使うかをモデルに選ばせる。

ツールの数が増えると、この仕組みはうまく働かなくなる。使えるツールの数がある程度を超えると、モデルが正しいツールを選ぶ精度が落ちることを、モデルの提供元自身が文書に書いている。コンテキスト（モデルが応答を返すときに読む入力の全体）には量の上限があり、ツールの説明がその多くを使うと、本来の仕事に回せる分が減る。

そこで、ツールを自動で見つけて繋ぐ仕組みが検討される。ところが、知らない提供元のツールを自動で繋ぐと、そのツールが名乗るとおりの提供元のものか、説明文に悪意のある指示が含まれていないかを、誰が確かめるのかが決まっていない。開発者は、手で登録する仕組みの限界と、自動で繋ぐ仕組みの不安のあいだで、次の設計を決めかねている。

本稿は、ARD 仕様の v0.91（2026年8月26日版）と MCP Registry を例に取る。本稿がこの二つを選んだのは、ARD が一覧を提供元のドメインに分散して置き、MCP Registry が公式の一覧を一つ置くという点で設計が分かれ、どちらも作り手が理由と限界を一次資料に書いているからである。

問い

エージェントがツールを探す仕組みはどこへ動き始めていて、見つけたツールを信じてよいかの判断は誰が担うのか。

要点

エージェントのツール探しは、全部の説明をモデルに渡す形から、提供元が公開したツールをモデルの外の検索が絞る形へ向かい始めたが、見つけたツールを信じてよいかは検索が判定せず、登録簿の検証と利用側の確かめに任される。

モデル・例示

ツールを40個つないだ障害対応のエージェント

※ この節の数値は説明のための仮定で、測定値ではありません。

社内の障害対応をエージェントに手伝わせる場面は、ARD の発表記事で Google が挙げた例である。その記事は、問題を解くためにエージェントが、監視の仕組みへの問い合わせ、技術文書の検索、配備の履歴の確認、サポートチケットの起票を行い、専門の障害対応エージェントにも相談するかもしれないと書く1。同じ記事は、正しいツールがどこにあるか、どれを使うべきか、繋いで安全かをどう確かめるか、という三つの問いに組織をまたいで答える標準の方法が今は無いと書く1。

このエージェントに、監視、技術文書の検索、配備の履歴、サポートチケットなど40個のツールをつないだとする。ツールの説明は1個あたり1,000トークンとする。全部の説明をモデルに渡す形では、エージェントは作業を始める前に4万トークンをツールの説明に使い、モデルは40個の中から1つを選ぶ。モデルの外の検索が候補を5個に絞る形では、説明に使うのは5千トークンで、モデルが選ぶのは5個の中からになる。その代わり、検索が返した5個の中に正しいツールが入っているかは検索の側で決まり、その5個の提供元を信じてよいかは、検索とは別にモデルの外で確かめることになる。

全部を渡す形は、ツールが増えるとコンテキストの量で行き詰まり、選ぶ精度も落ちる

ARD の仕様は、今の一般的な形では、利用者や開発者が各エージェントを使う前に明示的にインストールするか、コードに直接書き込む（ハードコードする）必要があると書く2。同じ仕様は、多くのモデルがすべての説明をコンテキストに入れてツールを選んでおり、この方法はスケールしないと書く2。同じ文は、エージェントの説明は一般的な書き方になりがちだとも書く2。

Hugging Face の発表記事も同じ点を挙げる。記事は、手で入れる形はエージェントが毎日使う少数のツールには効くが、数千のその場限りのツールにはスケールしないと書く3。記事によれば、その代わりに使われるのが利用できるすべての説明をコンテキストに入れてモデルに選ばせる方法で、この方法はコンテキストの予算に制限される3。記事は、検索に基づく方法もあるが、説明が薄すぎてうまく見分けられないことが多いとも書く3。

モデルの提供元も、ツールの数と選ぶ精度の関係を文書に書いている。Anthropic は、自社の API の機能として提供する tool search（ツールの定義を検索させる機能）の文書で、同社のモデルが正しいツールを選ぶ能力は、使えるツールの数が30〜50を上回った時点で下がると書く4。同じ文書は、tool search を使うとモデルがすべてのツールの定義を最初に読む代わりにツールの一覧を検索し、必要なツールだけを読み込むと説明する4。同じ文書は、GitHub、Slack など5つのサーバーをつなぐ典型的な構成で、ツールの定義だけで作業を始める前に約5万5千トークンを使いうるとも書く4。文書によれば、tool search はこの量を通常85%以上減らし、1回の依頼に要る3〜5個のツールだけを読み込む4。三者の文書はいずれも、全部を渡す形の限界としてコンテキストの量を挙げ、選ぶ精度が落ちる点は Anthropic の文書が数で示している。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

出典9件

  1. Google Developers Blog「Announcing the Agentic Resource Discovery specification」2026-06-17. https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/ — 障害対応の例と、ツールの場所・選び方・安全の確認に組織をまたぐ標準が無いという問題提起。 ↩ ↩2 ↩3

  2. Bu ほか「Agentic Resource Discovery Specification」v0.91, 2026-08-26（2026-10-01 取得）. https://github.com/ards-project/ard-spec/blob/main/spec/ard.md — 提供元のドメインの一覧と登録簿の検索の二層、全説明をコンテキストに入れる形はスケールしないという問題設定、名前空間の乗っ取りへの防御。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17

  3. Burtenshaw ほか「Agentic Resource Discovery: Let agents search」Hugging Face Blog, 2026-06-17. https://huggingface.co/blog/agentic-resource-discovery-launch — 手で入れる形は数千のツールにはスケールしないこと、複数社の寄稿者による草案であること、Discover Tool が参照実装であること。 ↩ ↩2 ↩3 ↩4 ↩5

  4. Anthropic「Tool search tool」（2026-10-01 取得）. https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool — ツールが30〜50を超えると選ぶ精度が落ちること、必要なツールだけを読み込む検索、定義だけで約5万5千トークンという例。 ↩ ↩2 ↩3 ↩4

  5. MCP Registry「Ecosystem Vision」（2026-10-01 取得）. https://github.com/modelcontextprotocol/registry/blob/main/docs/design/ecosystem-vision.md — 一度の公開で全利用者が同じ正本を参照し、メタデータだけを持つ設計と、運営の体制、下流の登録簿が選別と評価を加えること。プレビュー公開と API v0.1 凍結の時期は README（https://github.com/modelcontextprotocol/registry/blob/main/README.md ）による。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  6. MCP Registry「The MCP Registry Moderation Policy」（2026-10-01 取得）. https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/moderation-policy.mdx — 審査は最小限で保証せず、深い審査を上流と下流の登録簿に任せること、プレビュー段階であること。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  7. MCP Registry「How to Authenticate When Publishing to the Official MCP Registry」（2026-10-01 取得）. https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/authentication.mdx — 選んだ認証の方法がサーバーの名前の名前空間を決めること。 ↩ ↩2 ↩3

  8. Bu ほか「Agentic Resource Discovery Specification」§3.3・§4.5・§4.5.2・§5.1（2026-10-01 取得）. https://github.com/ards-project/ard-spec/blob/main/spec/ard.md#452-verification — 関連度の値は信頼の判断ではないこと、署名の手順を定めないこと、旧パスとメディアタイプの登録が未確定であること。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  9. Beurer-Kellner ほか「MCP Security Notification: Tool Poisoning Attacks」Invariant Labs, 2025-04-01. https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks — 悪意のある MCP サーバーがデータを持ち出し他のサーバーの指示を上書きできた実験と、版の固定などの緩和策。 ↩ ↩2 ↩3

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。