AIエージェントを見つける仕様ARD。Microsoft・Googleらが策定、まだ草案

Agentic Resource Discovery(ARD)は、AIエージェントやMCPサーバがどこにあるかを探すための共通仕様です。Microsoft・Google・Hugging Face・GoDaddyらの作業部会が策定を進めており、AWSが2026年8月24日に解説を公開しました。

📖 この記事で分かること

• ARDはエージェントを探す層の共通仕様
• 掲示は/.well-known/ai-catalog.jsonなど4経路
• MCPやA2Aを置き換える仕様ではない
• 現状はv0.9草案で確定仕様ではない

💡 知っておきたい用語

• well-known URI:サイトの決まった場所に置く「案内板」。robots.txtと同じで、置き場所が決まっているから誰でも取りに行ける

最終更新日: 2026年8月25日

▶ 公式ページ

• Agentic Resource Discovery 公式サイト(agenticresourcediscovery.org)
• ARD 仕様書(agenticresourcediscovery.org)
• ards-project(GitHub)(GitHub)

ARD(Agentic Resource Discovery)とは

この記事のポイント

• Microsoft・Google・Hugging Face・GoDaddyらの作業部会がARDを策定中。AWSが2026年8月24日に解説を公開した。
• エージェントやMCPサーバを「呼ぶ前に見つける」ための仕様で、MCPやA2Aは置き換えない。
• 掲示側は/.well-known/ai-catalog.jsonを置くだけ。ただし仕様はv0.9草案(2026年8月時点)。

ARD(Agentic Resource Discovery)は、AIエージェントやMCPサーバがどこにあるかを探すための共通仕様です。ライセンスはApache-2.0で、特定企業の製品でも単一のレジストリでもありません。策定はMicrosoft・Google・Hugging Face・GoDaddyらが参加する作業部会が進めており、公式サイトにはCisco・Databricks・GitHub・Nvidia・Salesforce・ServiceNow・Snowflakeも名を連ねています。AWSは策定中にフィードバックを提供した立場で、AWSが定めた仕様ではありません。

背景にあるのは、エージェントやツールが複数のクラウド・オンプレミス・SaaS・業務アプリに分散し、レジストリも命名規則もメタデータの形式もばらばらだという状況です。公式の説明では、これらをつなぐには「レジストリの組み合わせごとに個別のコネクタ」が必要になるとされます。ARDはその総当たりを避けるための共通の作法を用意しようとしています。

掲示の4経路と、カタログに書く中身

掲示する側は、Webが既に使ってきた発見の作法をそのまま流用します。経路は4つです。

• well-known URI:/.well-known/ai-catalog.jsonを置く。関連して/.well-known/agent-card.json、信頼検証用に/.well-known/spiffe/jwksがある
• DNSのSVCBレコード(TXTへのフォールバック可)。例:_index._agents.example.com 3600 IN SVCB 1 agent-search.example.com
• robots.txtのAgentmapディレクティブ。例:Agentmap: https://example.com/catalog.json
• HTMLのlinkタグ

カタログ1件あたりの必須フィールドはidentifier(URN形式)、displayName、type(IANA Media Type)、そしてurlかdataのどちらか一方です。任意でdescription、tags、capabilities、representativeQueries、version、updatedAt、metadata、trustManifestを持てます。

記述できる対象はメディアタイプで区別され、A2Aエージェントはapplication/a2a-agent-card+json、MCPサーバはapplication/mcp-server-card+json、入れ子のカタログはapplication/ai-catalog+json、レジストリ自体はapplication/ai-registry+jsonが割り当てられています。IANA Media Type形式であれば独自の型も定義できます。

探す側の要件も決まっています。仕様は「An Agent Registry MUST expose a standard HTTP REST search interface」として、POST /searchの実装を必須としています。自然言語のテキストと任意のフィルタを受け取り、意味的な関連度スコア0〜100で並べ替えて返す形です。任意でGET /agentsによる決定的な一覧と、POST /exploreによるファセット集計を持てます。ページングはpageTokenで行います。横断検索の範囲はfederationパラメータで「auto」「referrals」「none」から選べます。

MCPやA2Aの置き換えではない

ARDは既存プロトコルの競合ではありません。仕様は「ARD is not MCP, A2A, Skills, AI Catalog, or an API runtime, and it does not replace them」と明記しています。ARDが働くのは呼び出しの前(entirely before invocation)だけで、見つけた後の呼び出しは各プロトコルのまま行います。DNSが名前解決だけを担い、通信そのものはHTTPやSMTPに任せる関係と同じ構図です。

実装面でもMCPと組み合わせる形が示されています。AWSはレジストリをリモートMCPエンドポイントとして提供しており、MCP対応クライアントであればそのまま検索して利用できます。公式ドキュメントにはClaude・ChatGPT・GitHub Copilot・Microsoft Copilot・Gemini向けの接続ガイドも用意されています。ただし本番採用企業は明示されておらず、公式サイトに並ぶ社名は策定への参加・関与を示すものです。

編集部の見方

編集部は、ARDで最も効くのは検索インターフェースの標準化より、掲示側のコストがほぼゼロに設計されている点だと見ています。

• 根拠1:掲示に必要なのは/.well-known/ai-catalog.jsonを1枚置くこと、あるいはrobots.txtにAgentmap:を1行足すことです。新しいサーバも新しい認証基盤も要りません。sitemap.xmlが普及したときと同じ低さで、既存のWeb運用の延長で対応できます。
• 根拠2:必須フィールドがidentifier・displayName・typeとurlまたはdataの4つに絞られています。仕様を全部読まなくても書ける分量で、様子見の運営者でも試しに置いてみる判断がしやすい設計です。
• 根拠3:MCPやA2Aを置き換えないと明言しているため、既存の実装を捨てる必要がありません。導入判断が「乗り換え」ではなく「追加」で済みます。

一方で、いま本番前提で組む段階ではありません。仕様はv0.9のDraftでステータスは「Proposal」、仕様ドキュメントの日付は2026年5月28日です(2026年8月時点)。GitHubのards-project/ard-specはstar 437・Apache-2.0で、直近のpushは2026年8月23日と更新は続いていますが、必須フィールド名やエンドポイントが今後変わる可能性は残ります。

この見方が変わる条件は、主要なエージェントクライアントのどれか1つがARDの探索を既定の挙動として組み込んだときです。探す側が実際に読みに来るようになれば、掲示の低コストさがそのまま先行者の利得に変わります。逆に探す側が動かないままなら、/.well-known/ai-catalog.jsonは置かれるだけで読まれないファイルに留まります。

よくある質問

Q: ARDはAWSが作った仕様ですか?

A: 違います。策定はMicrosoft・Google・Hugging Face・GoDaddyらが参加する作業部会が進めています。AWSは策定中にフィードバックを提供した立場で、2026年8月24日に解説記事を公開しました。

Q: MCPを使っている場合、ARDに乗り換える必要がありますか?

A: 必要ありません。仕様はARDがMCPやA2Aを置き換えないと明記しています。ARDが担うのは呼び出し前の発見だけで、見つけた後の呼び出しは従来どおりMCPなどで行います。

Q: いま自社のツールを掲示しておくべきですか?

A: 仕様はv0.9のDraft(2026年8月時点)で、フィールド名が変わる可能性があります。試すなら/.well-known/ai-catalog.jsonを置く程度の可逆な範囲に留め、本番の依存先には組み込まない判断が無難です。

まとめ

ARDは、エージェントやMCPサーバを呼び出す前に見つけるための共通仕様です。掲示はwell-known URI・DNSのSVCBレコード・robots.txtのAgentmapディレクティブ・HTMLのlinkタグの4経路で、探す側にはPOST /searchの実装が求められます。MCPやA2Aを置き換えるものではなく、既存実装に追加する形で使えます。ただし現時点ではv0.9のDraftであり、仕様の変更余地を織り込んだうえで触る段階です。

【用語解説】

• SVCB レコード: DNSに置く新しい種類の記録。名前から住所を引くだけでなく、「どの入口にどう繋げばよいか」までまとめて答えられる
• A2A: エージェント同士が直接やりとりするための取り決め。ARDは相手を探すところまでを担い、話し始めてからはA2Aの担当になる
• ファセット集計: 検索結果を種類や提供元ごとに数え上げて見せる仕組み。通販サイトの絞り込み欄と同じ考え方

引用元:

• [1] ARD 仕様書(agenticresourcediscovery.org)
• [2] Agentic Resource Discovery 公式サイト(agenticresourcediscovery.org)
• [3] ards-project(GitHub)(GitHub)
• [4] Agentic Resource Discovery (ARD): An open specification for agent discovery(AWS Machine Learning Blog)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。