Agentic Resource Discovery（ARD）とは？MCP・A2Aとの違いと企業ソフト連携の狙いを完全解説【2026年最新】

Agentic Resource Discovery（ARD／エージェント用リソース発見）とは、AIエージェントが「このタスクに使える能力（ツール・MCPサーバー・スキル・他エージェントなど）はどこにあり、信頼できるか」を、実際に呼び出す前に発見・検証するためのオープン仕様です。分かりやすく言えば、MCPが「AIと外部ツールをつなぐUSB-Cポート」だとすれば、ARDは「どのポートに挿すべきかを教えてくれる検索エンジン」にあたります。

2026年6月に、Google・Microsoft・Salesforce・GitHub・Hugging Face・NVIDIA・Snowflake など11社がLinux Foundation傘下のワーキンググループとして v0.9 ドラフトを公開し、AIエージェント業界で急速に注目を集めています。

この記事でわかること:

ARDの定義と、なぜ今この標準が必要とされているのか
カタログ（Catalogs）とレジストリ（Registries）という2つのコア構成と、発見から接続までの流れ
ARDとMCP・A2A・Skillsの役割の違い（比較表で整理）
Google・Microsoft・Salesforceら大手が組む「企業ソフト連携」の本当の狙い
GitHub・Hugging Face・Google Cloud の早期実装例
自社サイト・自社ツールをARD対応させる意味と、まだ様子見すべきポイント

対象読者は、AIエージェントの最新動向を追う開発者・技術リーダー、エンタープライズでのAI導入を検討する情報システム／DX担当者、そして「MCPやA2Aと何が違うのか」を一度で理解したい方です。専門用語は都度かみ砕いて説明します。

Agentic Resource Discovery（ARD）とは何か

GitHubで公開されているAgentic Resource Discovery（ARD）の仕様リポジトリ ards-project/ard-spec

出典：GitHub「ards-project/ard-spec」（Agentic Resource Discovery specification）

ARDは、AIエージェントが利用できる「エージェント用リソース」を、呼び出しの前段階（pre-invocation）で発見・検証するためのオープンな発見プロトコルです。公式サイト（AgenticResourceDiscovery.org）は「an open discovery protocol for agentic resources（エージェント用リソースのためのオープンな発見プロトコル）」と定義しています。AIクライアントが「What is available for this task?（このタスクに何が使えるか）」と問い合わせると、ディスカバリーサービスが該当リソースを返す、という仕組みです。

ここで言う「エージェント用リソース（agentic resources）」とは、AIが外部で利用できる能力全般を指します。具体的には次のようなものです。

AIエージェント（他社・他部門が公開するエージェント）
MCPサーバー（外部ツールやデータへの接続口）
Skills（スキル＝特定タスクをこなす能力単位）
API・プラグイン・キャンバス・ワークフロー

従来のWebにたとえると、ARDが担うのは「DNS＋検索エンジン」に相当する発見レイヤーです。無数のサイトがあっても検索エンジンがなければ辿り着けないのと同じで、無数のツールやエージェントが存在しても、発見手段がなければAIは使えません。ARDはこの「エージェントWeb（agentic web）」の入口を標準化しようとしています。

なお、AIエージェントそのものの基礎から押さえたい場合は、上位概念の解説であるAIエージェントとは、大分類としての生成AIとはもあわせて参照すると全体像がつかみやすくなります。

ARDは「エージェント版の検索エンジンの土台」

Microsoftはこの状況を「検索エンジンが登場する前のWeb」にたとえています。膨大なリソースが確かに存在するのに、それを見つける手段がない状態です。ARDはその発見レイヤーを作り、AIエージェントが自分で「使える能力」を探し出せるようにすることを目指しています。

ARDが解決しようとしている課題

現在のAIエージェントは、開発者が事前に手作業でつないだ（wireした）ツールしか使えません。 世の中に数十万規模のツール・MCPサーバー・エージェントが存在しても、事前に接続設定していなければ、その存在すら認識できず利用もできません。これがARDの出発点となる課題です。

Google公式の説明では、エージェントは能力を使う前に次の3つの問いに答える必要があるとされています。

Where does the right capability live? — 適切な能力はどこにあるのか
Which capability should I actually use? — 数ある候補のうち、どれを実際に使うべきか
How do I verify it's safe to connect to? — 接続して安全かどうかをどう検証するか

とりわけエンタープライズ用途では、「動けば何でもいい」では通用しません。Google CloudのDistinguished EngineerであるSrinivas Krishnan氏は、セキュリティ・ID・ガバナンスが「後付け（bolted on）」ではなく「最初から組み込み（built in）」であることが必須だ、という設計思想を示しています。ARDはこの3つの問いに答えるための、標準化された発見・検証の枠組みを提供しようとしているわけです。

ARDの仕組み：カタログとレジストリ

ARDは「カタログ（Catalogs）」と「レジストリ（Registries）」という2つのコア構成要素で成り立っています。 前者が「情報を公開する側」、後者が「情報を集めて検索可能にする側」です。

カタログ（Catalogs）：能力を公開する側

組織は、自ドメイン上の well-known パスに機械可読なファイル ai-catalog.json を公開します。

https://{ドメイン}/.well-known/ai-catalog.json

このファイルに、自社が提供する利用可能なツール・API・スキル・エージェントのエンドポイントを記述します。重要なのは、ドメインの所有権がIDと信頼の暗号学的な基盤になるという設計です。誰でも勝手に「自分は◯◯社だ」と名乗れないよう、公開元のドメインと発行者IDを結びつけます。

カタログを公開・発見してもらう手段は4つ用意されています。

Well-Known URI: https://{ドメイン}/.well-known/ai-catalog.json
Agentmap ディレクティブ: robots.txt に Agentmap: https://example.com/catalog.json を記載
HTML linkタグ: <link rel="ai-catalog" href="...">
DNS Service Binding: DNSレコードで静的マニフェストや動的レジストリのエンドポイントを指す

Webサイト運営者にとっては、robots.txt や sitemap.xml の「AIエージェント版」を用意するイメージに近いと言えます。

レジストリ（Registries）：発見を担う検索エンジン側

レジストリは、エージェントWebにおける「検索エンジン」です。各ドメインのカタログをクロール・インデックスし、エージェントからの自然言語クエリに対して、該当しそうなリソースを返します。

ARDが目指すのは、単一の中央集権的なカタログではありません。DNSがローカルと上流のサーバーに分かれているように、複数の分散したディスカバリーサービスが、それぞれ独自の信頼ポリシー・ランキング・アクセス制御で応答するモデルです。企業は社内向けのプライベートなレジストリ（社内イントラ検索のようなもの）を運用でき、公開レジストリも「品質・信頼を重視するもの」「網羅性を重視するもの」など複数併存すると想定されています。

発見から接続までの4フェーズ

ARDでの一連の流れは、次の4段階で整理できます。

フェーズ	内容
① 公開（Publish）	組織が `ai-catalog.json` を自ドメインに公開する
② 発見・解決（Discovery & resolution）	レジストリ経由、または直接ドメイン取得でリソースを見つける
③ 検証（Verification）	発行者IDを暗号学的に検証し、信頼できるか確かめる
④ 接続（Connect）	MCP・A2A・API・ワークフローなどネイティブなプロトコルで実際に接続する

ポイントは、ARDが担うのは①〜③までという点です。実際にツールを呼び出す④の実行は、MCPやA2Aといった既存のネイティブプロトコルに委ねられます。ARDは「見つけて、信頼できるか確かめる」までの標準であり、実行ランタイムではありません。

カタログエントリの主なフィールド

ai-catalog.json の各エントリには、次のような項目を記述します（v0.9ドラフト時点）。

必須: identifier（URN形式 urn:air:<publisher>:<namespace>:<agent-name>）、displayName、type（IANAメディアタイプ）
いずれか一方が必須: url（外部参照）または data（埋め込みJSON）
任意: description、tags、capabilities、representativeQueries（代表的な問い合わせ例）、version、updatedAt、metadata、trustManifest

type にはリソースの種類を示すメディアタイプが入り、A2Aエージェントは application/a2a-agent-card+json、MCPサーバーは application/mcp-server-card+json、入れ子のカタログは application/ai-catalog+json、動的レジストリは application/ai-registry+json などが使われます。OpenAPIツールやカスタム型もIANAメディアタイプ登録で拡張できます。

ARD・MCP・A2A・Skillsの違い

もっとも混同されやすいのが、ARDとMCP・A2A・Skillsとの関係です。これらは競合ではなく役割の異なるレイヤーであり、ARDは他を置き換えるのではなく補完します。 MCPが「how（どう呼ぶか）」を、ARDが「how to discover（どう見つけるか）」を担う相補関係だと、InfoQなど複数の技術メディアが整理しています。

項目	ARD	MCP	A2A	Skills
役割	リソースの発見・検証	ツール・データへの接続と呼び出し	エージェント間の通信・委譲	能力の単位（タスク遂行力）
答える問い	何が使えて信頼できるか	どう呼び出すか	どう他エージェントに任せるか	何ができるか
タイミング	呼び出し前（pre-invocation）	呼び出し時	呼び出し時	実行時に利用
構造	DNS的な分散・複数レジストリ	クライアント⇔サーバー	エージェント⇔エージェント	ツール/モデルに付随
提唱の起点	11社WG（2026年6月）	Anthropic発	Google発	各社

つまり、AIエージェントの動作を時系列で見ると、まずARDで「使える能力」を発見・検証し（呼び出し前）、次にMCPやA2Aでその能力に接続して実行する（呼び出し時）、という流れになります。ARDはMCPやA2Aの「上流」に位置づけられる、と考えると分かりやすいでしょう。

各プロトコルの詳細は、それぞれの解説記事もあわせてご覧ください。

ツール接続の標準について: MCP（Model Context Protocol）とは
エージェント間通信の標準について: A2Aプロトコルとは
複数エージェントの連携について: マルチエージェントとは

「OpenAI・Anthropicへの対抗」という報道の正しい読み方

一部メディアは「Google・Microsoft・SalesforceがOpenAI・Anthropicに対抗して新標準を立ち上げた」という業界政治的なフレーミングで報じています。ただしこの見方は正確ではありません。ARD公式は、MCP（Anthropic発）やA2A（Google発）を置き換えるものではなく補完すると明言しています。 ARDのカタログはMCPサーバーカードやA2Aエージェントカードをそのまま参照できる設計であり、むしろ既存標準の上に乗る「発見レイヤー」です。単純な対立構図ではなく、既存プロトコルを前提に不足していた層を埋める動き、と捉えるのが実態に近いと言えます。

ARDの信頼とセキュリティ

ARDの信頼モデルの基盤は「ドメイン所有権」です。中央の登録機関を介さず、ドメインの管理権限を根拠に発行者を暗号学的に検証する、ゼロトラスト志向の設計になっています。各カタログは発行者のドメイン上に置かれ、urn:air:<publisher>:... の <publisher> セグメントが、暗号学的ID内の authority ドメインルートと一致しなければならない（MUST）と規定されています。

信頼情報を運ぶのが trustManifest オブジェクトで、主に次の要素を持ちます。

identity: 暗号学的なワークロード識別子（SPIFFE ID、DID、HTTPS FQDN URI など）
identityType: did / spiffe / https などの種別
attestations: 検証可能なコンプライアンス主張（typeとURIの組）

一方で、ARD自体は認証・認可・アクセス制御そのものを提供しません。 それらはディスカバリーサービス側や接続先が担う前提で、ARDは「照合（マッチング）」と「信頼判断に必要な情報の受け渡し」に徹します。発見したリソースの安全性を堅牢化（harden）するわけではなく、あくまで判断材料を運ぶだけ、という割り切りです。

想定される脅威として、公式や技術メディアは次を挙げています。

サプライチェーンの完全性の毀損
ネームスペースなりすまし（namespace spoofing）
偽の能力公開（fake capability publishing）

エコシステムが拡大すればこれらのリスクは深刻化しうるため、「接続する前に発行者を検証する」ことが重要になります。エージェント全般のセキュリティ観点を深掘りしたい場合は、AIエージェントのセキュリティガイドも参考になります。

誰が提唱しているのか：11社とLinux Foundation

ARDは、Linux Foundation傘下の「AI Catalog Working Group」が策定を進めるオープン標準で、大手11社が名を連ねています。 参加企業は以下のとおりです。

Microsoft
Google
GitHub
Hugging Face
Cisco
Databricks
GoDaddy
NVIDIA
Salesforce
ServiceNow
Snowflake

基本情報を整理すると次のようになります。

項目	内容
名称	Agentic Resource Discovery（ARD）
公開時期	2026年6月（仕様ドキュメントの版日付は5月28日）
現行バージョン	v0.9（Draft／Proposal、策定途上）
ライセンス	Apache License 2.0
リポジトリ	GitHub `ards-project/ard-spec`
保守母体	Linux Foundation AI Catalog Working Group

クラウド／データ基盤（Google・Microsoft・Databricks・Snowflake）、エンタープライズSaaS（Salesforce・ServiceNow）、開発者プラットフォーム（GitHub・Hugging Face）、インフラ（Cisco・NVIDIA・GoDaddy）と、レイヤーの異なる企業が横断的に参加しているのが特徴です。特定ベンダーに閉じない「中立的な標準」を志向していることがうかがえます。

Google・Microsoft・Salesforceら大手が組む狙い：企業ソフト連携

出典：Google Cloud 公式サイト

大手11社がARDに集まる最大の狙いは、AIエージェントが企業内外に散らばる数十万規模のツールを「安全に、自動で」発見できる"エージェントWeb"の共通基盤を、早期に押さえることにあります。特にSalesforce・ServiceNow・Snowflake・Databricksといった企業ソフト（エンタープライズソフトウェア）勢が参加している点が重要です。

エンタープライズでは、CRM・ITSM・データウェアハウス・人事・会計など、部門ごとに膨大な業務システムが存在します。これらをAIエージェントが横断的に活用するには、次の条件が欠かせません。

発見可能であること: どの業務にどのツール・エージェントが使えるかを、その都度手作業でつながずに見つけられる
信頼できること: 接続先が正規のシステムであると検証でき、なりすましを防げる
ガバナンスが効くこと: どのエージェントが何にアクセスできるかを統制できる

裏を返せば、各社が個別に独自の発見方式を作ると、AIエージェントは企業ごと・製品ごとに設定をやり直すことになり、普及の足かせになります。共通の発見標準があれば、Salesforce上のエージェントがSnowflakeのデータやServiceNowの業務を、企業のガバナンスを保ったまま自動で見つけて連携できる——これがARDに大手が投資する実利です。

Googleにとっては Gemini Enterprise Agent Platform の Agent Registry、Microsoftにとっては Microsoft Agent 365 系のエージェント基盤と接続する「共通の入口」を確保する意味があります。関連して、Googleが進める企業向け接続基盤の考え方は Google UCP（Universal Commerce/Context Protocol）とはの解説も参考になります。

早期の実装例

ARDの早期実装「Agent Finder」を備えるGitHub Copilot

出典：GitHub Copilot 公式サイト

ARDはドラフト段階ながら、すでに複数の大手プラットフォームがリファレンス実装を公開・稼働させています。 代表的な3つを紹介します。

GitHub「Agent Finder」

GitHub Copilot が、公開カタログや私設レジストリからMCPサーバー・スキル・エージェントを、ランタイムで動的に発見・呼び出しできる機能です。開発者があらかじめ全ツールを手動接続しておかなくても、必要に応じて能力を見つけて使えるようになります。

Hugging Face「Discover Tool」

Hub の意味検索基盤を流用し、数千規模のSkills・MLアプリ・MCPサーバーを検索可能にする実装です。hf discover search "Fine tune a language model" のようなCLIに加え、REST APIやMCPエンドポイントも提供されます。Hugging Faceは「手動インストール前提の静的カタログから、意図（intent）ベースの検索へ」の転換を強調しています。

Google Cloud「Agent Registry」

Gemini Enterprise Agent Platform 上のホスト型ARDサポートです。namespaced URN、egress（外向き通信）ポリシー、trust manifestによるAgent Identity検証など、エンタープライズ向けのガバナンス機能を備えます。ネイティブ対応は2026年6月時点で「今後数か月で提供」とアナウンスされています。

自社サイト・自社ツールをARD対応させる意味

出典：Hugging Face 公式サイト

Webサイトやツールを提供する事業者にとって、ARDは「AIエージェントに見つけてもらうための新しい最適化（GEO/AEO）」という側面を持ちます。 自社ドメインに ai-catalog.json を公開しておけば、将来的にAIエージェント経由での被発見性（見つけてもらいやすさ）を高められる可能性があります。

想定される実務メリットは次のとおりです。

自社のAPI・エージェント・ツールを、AIエージェントが自動で発見・利用できる入口を用意できる
ドメイン所有権ベースの検証により、正規サービスとして信頼されやすくなる
検索エンジン最適化（SEO）が「人間の検索」向けだったのに対し、「エージェントの検索」向けの土台を先行して整備できる

ただし、現時点ではv0.9ドラフトであり、仕様やフィールドは変わりえます。今すぐ本番運用で全面採用するというより、まずは仕様を理解し、小さく試験公開して動向を追う段階というのが現実的な位置づけです。

こんな人・企業におすすめ

以下に当てはまる場合、ARDを今から追う価値が高いと言えます。

AIエージェント基盤の開発者・技術リーダー：MCPやA2Aの上流にあたる発見レイヤーを設計・実装したい
エンタープライズのDX／情シス担当：SalesforceやServiceNow、Snowflakeなど複数業務システムをエージェントで横断活用したい
AIエージェントを外部提供する事業者：自社ツール・エージェントをエージェントWeb上で見つけてもらいたい
クラウド・SaaSプラットフォーム提供者：Google・Microsoftの基盤との相互運用を見据えている

こんな場合はまだ様子見でよい

一方で、次のようなケースでは急いで採用する必要はありません。

単一ツール・小規模な用途：発見すべきリソースが少なく、手動接続で十分に足りている
本番安定性を最優先する運用：v0.9ドラフトのため仕様が変わりうるリスクを取りたくない
社内クローズド環境のみで完結：外部の多数リソースを動的発見する必要がない
標準の勝敗を見極めてから動きたい組織：普及可否がまだ未知数のため、実績を待ちたい

ARDは有望ですが、実運用での採用実績やスケール検証はこれからで、普及するかどうかは各メディアも「未知数」と留保しています。過度な先行投資よりも、MCPやA2Aといった実行レイヤーを固めつつ、ARDは情報収集・小規模検証で並走するのが堅実です。

ARDの料金

ARDはApache License 2.0で公開されたオープン仕様であり、仕様そのものに料金は発生しません。 誰でも無償で ai-catalog.json を公開し、仕様を実装できます。

ただし、次の点に注意が必要です。

ARD対応の商用サービス（例：Google Cloud の Agent Registry / Gemini Enterprise Agent Platform）を使う場合は、そのクラウドの課金体系に従います（各サービスの個別料金は現時点では未確認）。
レジストリ（ディスカバリーサービス）は公開・私設・ベンダー固有など複数形態が想定され、運用主体ごとに課金モデルが異なりえます。

つまり「標準を使うこと自体は無料、ただしそれを載せる商用プラットフォームの利用料は別」という整理になります。

よくある質問（FAQ）

Q. ARDはMCPやA2Aを置き換えるものですか？
いいえ。ARDは「呼び出し前の発見・検証」を担う別レイヤーで、MCP（ツール接続）やA2A（エージェント間通信）を置き換えず補完します。実際にツールを呼び出す実行はMCP・A2A・API等に委ねられます。

Q. ARDはもう本番で使えますか？
2026年6月時点で v0.9 のドラフト（Proposal）段階です。GitHub Agent FinderやHugging Face Discover Tool、Google Cloud Agent Registryなど早期実装は動いていますが、フィールド名やメディアタイプは今後変わりえます。本番全面採用より、理解と小規模検証が現実的です。

Q. ARDを使うのにお金はかかりますか？
仕様自体はApache 2.0で無償です。ARD対応の商用クラウドサービスを利用する場合のみ、そのサービスの料金が発生します。

Q. 自社サイトをARD対応させるには何をすればよいですか？
自ドメインの /.well-known/ai-catalog.json に、公開したいツール・API・エージェント情報を機械可読な形式で記述して公開します。robots.txt の Agentmap ディレクティブやHTML linkタグ、DNSレコードでも案内できます。ドメイン所有権が信頼の基盤になります。

Q. 「Google・MicrosoftがOpenAI・Anthropicに対抗」という記事を見ましたが本当ですか？
単純な対抗構図ではありません。ARDはAnthropic発のMCPやGoogle発のA2Aを補完する設計で、公式もそれらを置き換えないと明言しています。既存標準の上に乗る発見レイヤー、と理解するのが正確です。

まとめ

Agentic Resource Discovery（ARD）は、AIエージェントが「使える能力はどこにあり、信頼できるか」を呼び出し前に発見・検証するための、オープンな発見標準です。要点を振り返ります。

役割：MCP（接続）やA2A（エージェント間通信）の上流にある「発見レイヤー」。両者を置き換えず補完する
仕組み：ai-catalog.json を公開する「カタログ」と、それを検索可能にする分散型の「レジストリ」の2本柱
信頼：ドメイン所有権を基盤とした暗号学的なゼロトラスト検証。ただし認証・実行そのものは担わない
提唱：Google・Microsoft・Salesforceら11社＋Linux Foundation。Apache 2.0で無償公開
狙い：企業内外の膨大なツールを、ガバナンスを保ったままエージェントが自動発見できる"エージェントWeb"の共通基盤づくり
現状：v0.9ドラフト。有望だが普及可否は未知数で、本番全面採用より小規模検証が現実的

AIエージェントが「事前に配線したツール」から「自分で発見して使うツール」へと進化する流れの中で、ARDはその発見レイヤーを標準化する試みです。まずは上位概念のAIエージェントとは、接続標準のMCPとは、通信標準のA2Aプロトコルとはとあわせて理解を深め、自社の状況に応じて段階的に検証していくのがおすすめです。

※ARDはv0.9ドラフトとして策定途上のため、最新の仕様は公式サイトおよびGitHubリポジトリで確認してください。本記事は各社公式情報に基づいて作成しています。