ARD（Agentic Resource Discovery）とは、AIエージェントがWeb上のツールやAPI・他のエージェントを実行時に自動で発見・検証するための、Google・Microsoftら11社が2026年に公開したオープン規格です。各社が自ドメインに置く「ai-catalog.json」と、それを索引する「レジストリ」の2要素で成り立ち、MCPやA2Aの手前で発見と信頼確認を担います。本記事では、この新しい規格を日本の中小企業（SME）の視点から噛み砕き、「今すぐ動くべきか、まだ待つべきか」を判断軸とともに整理します。
この記事でわかること
- ARDの正体： AIエージェントがツールやAPIを実行時に発見・検証する新しい共通規格で、MCPやA2Aを置き換えるものではありません。
- SMEが今やること： 大半の中小企業に自前のai-catalog.json公開は不要で、まず構造化データ（Schema.org）で機械可読化の土台を固めるのが先決です。
- 判断の分かれ目： エージェント対応を後回しにする強い理由は乏しい一方、ECだけはカートシステムの対応を待つ判断も合理的です。
結論：ほとんどのSMEは「今すぐai-catalog.json」より先にやることがある
AIエージェント対応という言葉が広がり始め、「自社サイトも今すぐ何か対応すべきではないか」と不安を感じる中小企業の担当者が増えています。しかし結論から言えば、大半の中小企業（SME）にとって、いま最優先で取り組むべきは「ai-catalog.jsonの自前公開」ではありません。
ARDが主たる対象としているのは、ツール・API・エージェントといった「呼び出せる能力（callable capability）」を外部に提供する事業者です。一般的な店舗サイトやコンテンツ中心のサイトには、現時点で明確な打ち手はほとんどありません。実際、海外の専門メディアも「典型的なコンテンツサイトに今日とるべき明確なアクションはない」と整理しています。
（アイダイム分析）とはいえ、エージェント対応そのものを「まだ早い」と完全に放置するのも得策ではありません。当社の見立てでは、エージェント対応を意図的に後回しにする強い理由は乏しく、基本は「やってみないと分からない」段階に入っています。一方で、唯一はっきりと「待ち」が合理的だと考えているのがEC（ネット通販）です。エージェント経由の購買はマストだと語られがちですが、決済やカート周りは、利用しているカートシステム側の対応を待ってから動いても遅くないケースが多いと見ています。
ではSMEが今やるべきことは何か。それは、自前で新しいファイルを作ることではなく、既存の構造化データ（Schema.org）を網羅的に実装し、サイトを機械可読な状態に整えておくことです。これがエージェント時代の土台になります。AI検索全体で何が本当に必要かは、別記事「【図解】AI検索 対策とは？公式が示す本当に必要な施策」でも整理しています。
こうした「今すぐやるべきか」という疑問は、多くの担当者が最初に抱くものです。
Q. 中小企業も今すぐai-catalog.jsonを公開すべきですか？
A. 多くの中小企業には不要です。ARDの主な対象はツールやAPIを提供する事業者で、一般的なサイトはまず構造化データ（Schema.org）で機械可読化の土台を固めるのが先です。
では、その判断の前提となるARDそのものの仕組みを、次に具体的に見ていきます。
ARD（Agentic Resource Discovery）とは？11社が決めた“エージェント向け検索の共通規格”
ARDは、2026年6月17日に公開された、AIエージェント向けの発見規格です。Google・Microsoft・Hugging Faceが共同で執筆し、Cisco・Databricks・GitHub・GoDaddy・NVIDIA・Salesforce・ServiceNow・Snowflakeを加えた合計11社が参加しています。現在のステータスはv0.9のドラフト（草案）で、ライセンスはApache 2.0、Linux Foundation配下のワーキンググループが管理する「AI Catalog」データモデルを土台にしています。
仕組みはシンプルで、「カタログ」と「レジストリ」という2つの要素で成り立っています。
- カタログ： 事業者が自社ドメインの
/.well-known/ai-catalog.jsonに、提供するMCPサーバー・A2Aエージェント・API・スキルなどを機械可読な形式で記載したファイル。 - レジストリ： それらカタログをクロールして索引し、エージェントの自然言語による問い合わせに候補を返す、いわば「エージェントのための検索エンジン」。
実際の流れは、①事業者がカタログを公開し、②レジストリがそれを収集・索引し、③エージェントが自然言語で検索し、④発行元を検証してから、⑤ネイティブのプロトコルで直接接続する、という順序をたどります。
なぜ今この仕組みが必要とされるのか。背景には、利用可能なツールが数十万規模に膨れ上がり、エージェントに使うツールをすべて事前に登録しておく方式が限界を迎えつつあることがあります。必要なときに必要なものだけを見つけて接続する——この設計により、事前ロードによるコンテキストの肥大を抑えることが狙いとされています。なお、一部で語られる「コンテキスト最大約90%削減」といった具体的な数値は、公式仕様や関係各社の一次情報では確認できなかったため、本記事では数値としては扱いません。
参照実装として、GitHubが同日に「Agent Finder for Copilot」を、Hugging Faceが「Discover Tool」を公開しています。GoogleのAgent Registry（Gemini Enterprise Agent Platform内）がネイティブ対応するのは数カ月後の見込みで、規格としてもまだ草案段階です。
日本国内に目を向けると、執筆時点（2026年6月下旬）で、国内のSaaSベンダーや企業によるARD／ai-catalog.json対応の公式発表はまだ確認できていません。裏を返せば、日本語圏ではこのテーマがほぼ手つかずの先行領域だということです。
ここで、よく聞かれる2つの疑問に答えておきます。
Q. ARDとは何ですか？
A. AIエージェントがツールやAPIを実行時に発見・検証するためのオープン規格です。自ドメインに置く「ai-catalog.json」と、それを索引する「レジストリ」の2要素で構成され、MCPやA2Aの手前で発見と信頼確認を担います。
Q. ai-catalog.jsonはどこに置きますか？
A. 自社ドメインの /.well-known/ai-catalog.json に設置します。提供するMCPサーバー・API・エージェントなどを機械可読で記載し、ドメインを所有していること自体が発行元の証明になります。
仕組みが分かると、次に気になるのが「MCPやJSON-LDなど、似た用語との違い」です。
MCP・A2A・llms.txt・JSON-LDとの関係｜ARDはどこに位置するのか
ARDをめぐっては、MCP・A2A・llms.txt・JSON-LDといった用語が入り乱れ、混乱しがちです。これらは競合する規格ではなく、役割が異なります。5つの用語を「何を担うか」「対象」「設置場所」で並べると、重なっていないことが分かります。
| 規格 | 主な役割 | 対象 | 設置場所・形式 |
|---|---|---|---|
| ARD | 発見・検証（どこにあり信頼できるか） | ツール・API・エージェント | ai-catalog.json（/.well-known/）＋レジストリ |
| MCP | ツールの呼び出し（実行） | ツール・データ源 | MCPサーバーとして提供 |
| A2A | エージェント間の通信 | エージェント同士 | エージェント間プロトコル |
| llms.txt | AI向けの案内（効果に異論あり） | サイトのコンテンツ | サイトルートのテキストファイル |
| JSON-LD | ページ内容の構造化（人向けページ） | Webページ | HTML内の構造化データ |
表のとおり、ARDは「発見と検証」、MCPは「呼び出し」、A2Aは「エージェント同士の通信」、JSON-LDは「人が見るページの構造化」を担い、互いを置き換えません。
（アイダイム分析）ここで一つ、英語圏で論点になっている非対称性に触れておきます。GoogleのJohn Mueller氏は、通常のWebコンテンツについて「LLMはllms.txtのようなファイルでサイトを見分けられない」と否定的な見解を示しています。その一方で、エージェント発見ではwell-knownファイル（ai-catalog.json）を推進している——この食い違いをどう読むかは、まだ定まっていません。当社の解釈では、「人向けコンテンツの自己申告」と「機械向け能力の構造化された目録」は性質が別物であり、SMEがまず固めるべきは後者につながる構造化データだと考えています。
構造化データそのものの基礎は「構造化データとは？SEOへの影響と具体的な記述例」、JSON-LDの具体的なメリットは「JSON-LDとは｜SEO効果やメリット」で解説しています。
違いをもう一段かみ砕いた質問にも答えておきます。
Q. ARDはMCPやA2A、JSON-LDと何が違いますか？
A. 役割が異なり、置き換える関係ではありません。ARDは「発見・検証」、MCPは「ツールの呼び出し」、A2Aは「エージェント間の通信」、JSON-LDは「人が見るページの構造化」を担います。
用語の整理ができたところで、なぜ「今」これがビジネスの話になりつつあるのかを見ていきます。
なぜ今“エージェント対応”が流通チャネルになるのか
ARDは草案段階ですが、その周辺ではすでに「エージェント対応」を流通チャネルとして捉える動きが具体化しています。
たとえばCloudflareは2026年4月にエージェント専用のローンチ週間を設け、サイトの対応度を測る「Agent Readiness Score」を isitagentready.com で公開しました。Shopifyは、AIエージェントが在庫確認から決済までを完了できる「Agent Toolkit」を提供しています。Stripeも、エージェントがアカウント作成やインフラ調達を行える仕組みを整えており、直近半年でCloudflare・Shopify・Stripe・Supabase・Netlify・Googleといった基盤事業者が、それぞれ独立にエージェント対応へ投資してきました。
これらをSMEの言葉に翻訳すると、こうなります。これまで「人間がブラウザで見て操作する」ことを前提にしてきたサイトやサービスが、「エージェントが読んで・選んで・使う」対象へと広がりつつある、ということです。海外では「人間にしか機能しないサイトは、自分ではまだ気づいていない流通問題を抱えた製品だ」とまで指摘されています。
ただし、ここで煽る必要はありません。決済プロトコル（ACPやUCPなど）の多くは米国中心で、日本のSMEがすぐに対応すべきものではありません。重要なのは、「エージェントという新しい来訪者が、自社の情報を機械可読に読めるかどうか」という一点です。ローカルSMEにとって、エージェントとの最初の接点になりやすいのは自社サイトよりむしろGoogleビジネスプロフィールです。その整備は「Googleビジネスプロフィールの基本」で解説しています。
規格化と校正の視点｜ai-catalog.jsonは「機械可読な検査項目表」、verifyは「本人確認」
ここからは、当社が臨床検査の現場で培った「精度管理（QC）」の視点で、ARDを読み解きます。
臨床検査では、各施設の測定機器を共通の規格で「校正（キャリブレーション）」して初めて、施設をまたいだデータ比較が成立します。校正されていない機器の数値は、どれだけ精密に見えても比較の対象になりません。ARDが果たそうとしているのは、これとよく似た役割です。つまりARDは、各サイト・サービスが持つ「能力」を、エージェントの世界で比較可能にするための“校正基準”だと捉えられます（アイダイム分析）。
この比喩を当てはめると、ai-catalog.jsonは「機械可読な検査項目表」に相当します。どの検体に何の検査を行うかを定義した項目表があるからこそ検査が標準化されるのと同じで、自社が何を提供できるかを構造化して記載するのがai-catalog.jsonです。そしてverify（発行元検証）は、「検体の取り違えを防ぐ本人確認」に当たります。ドメイン所有を手がかりに「このカタログは確かにこの事業者のものだ」と確認してから接続する仕組みは、検体ラベルと患者を突き合わせる本人確認のプロセスそのものです。
（実務知見）この校正の発想は、当社が日々の構造化マークアップ実務で実践していることと地続きです。当社では、構造化マークアップを行ううえで最も重要なのはCMS（コンテンツ管理システム）の構成だと考えています。近年はクライアントのシステム会社と連携する案件も増えており、その場合はまずシステム側の構成をチェックし、そのうえで人の目による目視確認を行い、設定後に公式ツール（リッチリザルトテスト等）でマークアップが正しく認識されるかを検証する——この流れで品質を担保しています。機械可読化とは、こうした「正しく校正された情報」を整えることに他なりません。
日本のSMEが“今やること／まだ待つこと”チェックリスト
ここまでを踏まえ、日本のSMEが「今やること」と「まだ待つこと」を切り分けます。判断は、自社がAPI・予約・EC・受託などの「呼び出せる能力」を持っているかで変わります。まずは大枠を整理します。
| 今やること | まだ待つこと |
|---|---|
| 構造化データ（Schema.org）の網羅的な実装 | ai-catalog.jsonの自社単独での独自実装・公開 |
| 利用中のEC・決済プラットフォームのエージェント対応機能の仕様確認 | エージェント専用の独自決済プロトコルの自社開発 |
| JSON-LDの記述内容と本文表示の整合チェック | （EC）カートシステムの対応を待ってからの本格対応 |
多くのSMEは左列（今やる）の「構造化データの網羅実装」と「利用中プラットフォームのエージェント機能の仕様確認」から着手すれば十分です。
（アイダイム分析）右列の中で判断が分かれやすいのがECです。エージェント経由の販売は「マスト」と語られがちですが、決済やカートは利用しているカートシステム側の対応を待ってから動く方が、自社開発のリスクを避けられる場合があります。先んじて独自の決済プロトコルに対応するより、プラットフォームの標準対応に乗るのが安全です。
（実務知見）また、左列の「構造化データの網羅実装」に着手する際、現場で最も多いつまずきが、JSON-LDの記述内容とページ本文の表示内容のズレです。構造化データはあくまでページに表示されている内容を機械可読に補足するもので、本文と食い違った情報をJSON-LDに書くと、無効と判断されたりリスクになったりします。当社の経験上、ここがズレると元も子もないため、本文との整合は必ず確認します。
なお、前述のとおり国内ではARD／ai-catalog.json対応の公表事例がまだ出揃っていません。だからこそ、今は焦って先端規格を追うより、確実に効く土台（構造化データ）を固めるのが合理的です。MEO領域での構造化マークアップの考え方は「MEO対策で構造化マークアップが重要な理由」も参考にしてください。
アイダイムの構造化マークアップ代行で“機械可読化”の土台を整える
土台となる機械可読化を、自社のリソースだけで整えるのは負担が大きい——そう感じる場合は、構造化マークアップの代行も選択肢になります。
（実務知見）当社の構造化マークアップ代行では、CMS構成の確認を起点に、システム会社との連携が必要な案件ではシステムチェックと目視確認を組み合わせ、設定後に公式ツールでマークアップの認識を検証するところまでを一貫して行います。料金体系・作業フロー・納期をあらかじめ明示し、JSON-LD実装から将来のai-catalog.json対応を見据えた設計まで対応します。対応エリアは栃木・宇都宮を拠点に、全国のB2Bマーケティングまでカバーしています。
📌 機械可読化＝エージェント時代の“校正済みデータ”整備。JSON-LD実装から将来のai-catalog.json対応まで一気通貫で支援します。
→ 構造化マークアップ代行サービス
ARD・AIエージェント対応のよくある質問
最後に、ARDやエージェント対応について検索されやすい疑問をまとめます。
Q. llms.txtとの違いは？両方必要ですか？
A. 用途が別で、現状どちらもSMEに必須ではありません。llms.txtは効果に否定的な見解もあり、ai-catalog.jsonはエージェント発見用です。まずは構造化データを優先しましょう。
Q. ARDに対応しないとAI検索で不利になりますか？
A. 現時点で一般的なコンテンツサイトへの即時影響は限定的です。ARDはv0.9の草案でレジストリ生態系も未成熟なため、過度に焦らず機械可読化の土台を固める段階です。
📌 まずは確実に効く土台から。構造化データの網羅実装をプロに任せて、エージェント時代の準備を整えませんか。
→ 構造化マークアップ代行サービス
参考情報
- Search Engine Journal「Google, Microsoft Back Draft AI Agent Discovery Spec」 https://www.searchenginejournal.com/google-microsoft-back-draft-ai-agent-discovery-spec/579894/
- Google Developers Blog「Announcing the Agentic Resource Discovery specification」 https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/
- Microsoft Command Line「Introducing the Agentic Resource Discovery specification」 https://commandline.microsoft.com/agentic-resource-discovery-specification-ard/
- Hugging Face Blog「Agentic Resource Discovery launch」 https://huggingface.co/blog/agentic-resource-discovery-launch
- Search Engine Journal「Make Something Agents Want」 https://www.searchenginejournal.com/make-something-agents-want/576188/
