MCPサーバーを使うには、まず接続情報を設定ファイルに手で書く。1個や2個ならいい。だが社内に数十のMCPサーバーやエージェントが立ち、外部にも無数のツールがある世界では、この「使う前に全部つないでおく」やり方が破綻する。エージェントは自分が知らないツールを、必要になった瞬間に見つけることができない。

Model Context Protocol(MCP)やA2Aが解いたのは「どうやってツールを呼ぶか」だった。呼び方の規格はできた。けれど「どこに目的のツールがあるか」「どれを使うべきか」「つないで安全か」という、呼ぶ手前の問いは誰も標準化していなかった。ここを埋めにきたのが、6月17日にGoogleが旗振り役となって11社で公開した Agentic Resource Discovery(ARD) だ。

仕組みは「公開する側」と「探す側」の2つだけ

ARDの構造は驚くほど素朴で、登場人物は2種類しかいない。

ひとつはカタログ。組織は自分のドメイン直下の決まった場所、https://{ドメイン}/.well-known/ai-catalog.json に、提供するエージェントやMCPサーバーやAPIの一覧をJSONで置く。robots.txt や security.txt のように「機械が見にくる住所が固定されている」と考えるとわかりやすい。住所が自分のドメイン配下にあること自体が、後述する身元証明の土台になる。

もうひとつはレジストリ。これは公開されたカタログをクロールして索引を作り、検索を受け付ける。仕様書はこれを「エージェンティックWebのための検索エンジン」と表現している。エージェントは個々のカタログを総当たりするのではなく、レジストリに自然言語で問い合わせるだけでいい。

カタログ本体はこういう形をしている(仕様書 4.1 節の例)。

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Acme Enterprise AI",
    "identifier": "did:web:acme.com"
  },
  "entries": [
    {
      "identifier": "urn:air:acme.com:server:weather",
      "displayName": "Weather Data Node",
      "type": "application/mcp-server-card+json",
      "url": "https://api.acme.com/mcp/weather.json",
      "capabilities": ["WeatherTool", "ForecastTool"],
      "description": "Enterprise weather MCP server for live telemetry.",
      "representativeQueries": [
        "what is the current wind speed in Chicago",
        "get the 5-day forecast for Seattle"
      ]
    }
  ]
}

注目したいのは representativeQueries だ。エントリーごとに「このツールはこういう質問に答えられる」という例文を2〜5個添えておく。レジストリ側はこの例文をベクトル化して索引し、利用者の自然言語クエリと意味的にマッチさせる。「タグを正確に指定して検索」ではなく「やりたいことを書けば近いものが返る」設計になっている。

探す側はLLMの外でツールを絞り込む

レジストリのAPIは3本のRESTエンドポイントで定義されている。中心は POST /search で、自然言語の query.text を投げると関連度順の候補が返る。

{
  "query": {
    "text": "find me a flight booking agent",
    "filter": { "type": ["application/a2a-agent-card+json"] }
  },
  "pageSize": 5
}

返ってくる各候補には0〜100の score(意味的な関連度)が付く。

{
  "results": [
    {
      "identifier": "urn:air:acme.com:agent:assistant",
      "displayName": "Corporate Assistant (A2A)",
      "type": "application/a2a-agent-card+json",
      "url": "https://api.acme.com/agents/assistant.json",
      "score": 95,
      "source": "https://registry.acme.com/api/v1/"
    }
  ]
}

残りの2本は、結果をファセット集計する POST /explore と、決定論的に一覧を辿る GET /agents だ。

ここでの設計思想がいちばん面白いところで、Hugging Faceは公開記事で「選択をLLMの外に出す」と言い切っている。従来は使えるツールの説明を全部コンテキストに流し込んでLLMに選ばせるしかなく、これはトークン予算に縛られる。ARDではレジストリの検索が候補を絞ってから、必要な分だけをエージェントに渡す。コンテキストウィンドウを索引で肩代わりさせる発想だ。

そしてARDは呼び出しそのものには一切関与しない。見つけたあとは、そのリソース固有のプロトコル(MCP、A2A、OpenAPIなど)で呼ぶ。仕様は明確に「MCPやA2A、Skillsの置き換えではない」と位置づけている。呼ぶ手前だけを担当する薄い層、と捉えるのが正しい。

「見つかる」と「信用できる」は別問題

検索エンジンが厄介なのは、知らない相手が上位に出てくることだ。エージェントが見つけたツールに認証情報や操作権限を渡すなら、相手が名乗り通りの存在かを機械的に確かめられないと話にならない。Hugging Faceの記事の表現が的を射ている。

検証なき発見は、見知らぬ相手を信用する作業を産業化するだけだ

ARDはこの検証をドメイン所有権に紐づけて解く。各エントリーの識別子は urn:air:<publisher>:<namespace>:<name> 形式で、先頭にドメインが入る。さらに trustManifest に暗号的な身元(SPIFFE ID、DID、HTTPSのFQDNなど)を持たせる。レジストリやオーケストレーターはURNからドメインを取り出し、trustManifest の暗号的な主張と突き合わせる。そのドメインが発行した有効な証明を提示できなければ、その能力は拒否される。要するに、身元の根をDNSとドメイン管理という既存の信頼基盤に下ろしている。SOC2やHIPAAといった準拠表明を attestations に載せる枠も用意されている。

もう動いているもの、まだ固まっていないもの

仕様だけの話ではなく、公開と同時に実装が出ている。

実装	提供元	何をするか
Agent Finder	GitHub	CopilotがMCPサーバー・Skill・エージェント等を実行時に発見し、必要なときだけ読み込む。導入は明示承認が必要で自動インストールはしない
Agent Registry	Google Cloud	Gemini Enterprise上でエージェントやMCPサーバーを検索・ホストするフルマネージドのレジストリ
`hf discover`	Hugging Face	Hubの意味検索をARDのレスポンス形式で返すアダプタ。CLIから `hf discover search "..."` で叩ける

GitHubのAgent Finderは「全部を事前に配線せず、索引から関連だけを取り出す」というARDの狙いをそのまま製品化したもので、コンテキストの肥大に悩んでいる人には一番ピンとくる入口だろう。

冷静に見ておきたい点もある。リポジトリ(ards-project/ard-spec、Apache-2.0)上の仕様はv0.9のドラフト段階で、実際に細部はまだ揺れている。たとえばMCPサーバーを指すメディアタイプは、仕様本文の例では application/mcp-server-card+json だが、Hugging Faceの実装例では application/mcp-server+json を使っており一致していない。type がIANAメディアタイプで分類を表す以上、ここがバラつくと検索フィルタの相互運用が崩れる。発見規格としての価値は、結局レジストリのランキング品質と、誰がどれだけ真面目にカタログを公開するかにかかっている。索引が薄ければ「検索エンジン」は空振りする。

それでも、A2A・MCP・Skillと役割が重ならない「呼ぶ手前の層」をきれいに切り出し、信頼の根をドメインに置いた設計判断は筋がいい。プロトコルの乱立ではなく、既存プロトコルの上に検索とID検証を一枚足す方向だからだ。社内に複数のMCPサーバーやエージェントを抱え始めた組織なら、まず自分たちの /.well-known/ai-catalog.json に何を載せるかを棚卸しするところから、この規格との距離を測れる。