2026年6月、GoogleとMicrosoftらが共同で仕様を策定し、GitHub、Cisco、Salesforce、NVIDIAら主要12社が連携して支持する新しい標準仕様が公開された。
名称は「ARD（Agentic Resource Discovery）」。直訳すれば「エージェントによるリソース発見」だ。
この標準が企業に問いかけているのは、経営の根幹に関わるシンプルな問いだ。
「あなたの会社のAI機能は、外の世界から発見できる状態になっているか？」
AIエージェントが「仕事を探す」時代が来た
これまでAIは、人間が使うツールだった。人間がAIに指示を出し、AIが答えを返す。
しかし2026年現在、ビジネスの最前線では構図が根本から変わりつつある。
例えば、こんな場面を想像してほしい。営業担当者が「この顧客の与信を確認して、見積書を送っておいて」とAIエージェントに指示する。
するとAIエージェントが自律的に動き出し、社内の与信管理システムにアクセスして審査結果を取得し、別の見積作成AIに依頼して書類を生成し、さらにメール送信AIに渡して顧客に届ける。人間はその間、別の仕事をしている。
これが「マルチエージェント」と呼ばれる仕組みだ。ひとつの目標に対して、専門性の異なる複数のAIエージェントが役割分担しながら連携し、業務を完結させる。
人間が各ステップを仲介する必要がない。製造業では受発注の照合、物流では配送ルートの最適化、金融では審査フローの自動化といった複合的な業務が、人手を介さずに処理される世界が現実に近づいている。
だが、ここで大きな問題が生じる。
先ほどの例では「見積作成AIに依頼する」と一言で書いたが、実際にはそのAIがどこにあり、何ができて、どう呼び出すかをエージェントが知っていなければ依頼できない。
現在、各社のAI機能はバラバラな形で提供されている。APIの仕様も認証方式も提供形態もバラバラで、どんな機能があるかを把握するには人間が介在しなければならない。
人間が手動で調べて設定するのならまだしも、AIエージェントが自律的に「相手を見つけて連携する」には、あまりにも環境が整っていない。
マルチエージェントの恩恵を受けるためには、まず「エージェントが他のエージェントやAI機能を自動で発見できる仕組み」が必要なのだ。
標準がなければ、存在しないも同然
ARDが解決しようとしているのは、まさにこの「発見」の問題だ。
現在、各社のAI機能はバラバラな形で提供されている。あるベンダーのAPIはドキュメントを読まなければ使えず、どんな機能があるかを把握するには人間が介在しなければならない。
エージェント時代においてこれは致命的だ。AIエージェントは、自分が探しているものが「どこにあるか」を自律的に判断する必要があるからだ。
ARDはこの問題を、2つの仕組みで解決する。
ひとつは、ai-catalog.json という標準フォーマットのファイルだ。
これは人間向けのサービス紹介ページではなく、AIエージェントが自動で読み取れる「仕様書」のようなものだと思ってほしい。
企業は自社のAI機能の内容をこのフォーマットに従って記述し、自社のウェブサイト上の決まった場所に置く。
例えば与信審査AIであれば、「会社名と売上高を入力すると、与信可否と限度額を返す。呼び出しにはこのURLを使う」といった情報に加え、この機能の提供元が本物であることを証明するメタデータも記述する。
これにより、与信審査AIを利用しようとするエージェントが、接続前にそれを検証したうえで、「この機能を使えばいい」と自律的に判断して接続できる仕組みだ。
もうひとつは、レジストリAPI だ。
世界中のai-catalog.jsonを自動で収集・インデックス化し、AIエージェントからの問い合わせに応じて該当する機能の一覧を返す、いわば「AIエージェント向けの検索エンジン」だ。
例えばあるエージェントが「与信審査ができるAIを探して」と問い合わせると、レジストリは登録済みのカタログを検索し、条件に合うAIサービスの一覧を返す。エージェントはその中から適切なものを選んで接続する。
つまり、人間がGoogle検索で必要な情報を探すのと同じ構造を、AIエージェント間でも実現する仕組みだ。
仕組みはシンプルだが、インパクトは大きい。ARDに対応していない企業のAI機能は、他社のエージェントから検索にかからない。デジタルの世界での「存在しないも同然」の状態になるわけだ。
この一連の流れを、Googleは以下のように整理している。
図が示すように、ARDの動きは5つのステップで完結する。
まず企業が自社ドメイン上にai-catalog.jsonを公開（PUBLISH）し、レジストリがそれを収集（CRAWL）する。
エージェントはレジストリや直接カタログに対して目的ベースで検索（SEARCH）し、接続先の信頼性を検証（VERIFY）したうえで、A2A・MCP・APIのいずれかを通じて接続（CONNECT）する。
カタログとレジストリはどちらか一方だけでも機能するため、規模や用途に応じた段階的な導入が可能だ。
なお、ARDのアーキテクチャはフェデレーテッド（分散型）設計を採用しており、中央に単一の管理者が存在するわけではない。
各組織が自前のレジストリを運営でき、レジストリ同士が相互参照する形で成り立つ。
特定の企業に依存しないオープンな仕組みであることが、主要企業が支持する大きな理由のひとつでもある。
Google・Microsoftが「なぜ今」動いたのか
現在、AIエージェント間の連携を巡っては複数の標準が競合している。
ツールを実行するための「MCP（Model Context Protocol）」、エージェント同士が通信するための「A2A（Agent-to-Agent）」、そしてエージェントが能力を発見するための「ARD」。それぞれ異なるレイヤーを担っており、互いに補完し合う関係にある。
ARDはApache 2.0ライセンスのオープン仕様であり、カタログやレジストリの運営は特定企業に依存しない分散型の設計だ。
しかし、「どの仕様が業界標準になるか」という主導権争いは別の話だ。
HTTPがWebを生み、TCP/IPがインターネットを生んだように、標準仕様を提唱した側が次世代のAI産業における影響力を握ると言っていい。
GoogleとMicrosoftが揃って動いた背景には、そうした長期的な思惑があると捉えることができる。
だからこそ、半導体・データ・エンタープライズSaaSなど、異なる領域の主要企業12社が一斉に支持したことは見逃せない。
この標準がエンタープライズの現場に実装されていく速度は、想定より速い可能性がある。
経営層が直視すべき3つのインパクト
ARDの登場は、単なる技術仕様の更新ではない。「AIエージェントに発見されること」が企業活動の前提条件になるという、ビジネス環境そのものの変化だ。
AI機能を提供するSaaS事業者には「発見されなければ選ばれない」リスクがあり、自社でAIを内製している企業には「社内外のエージェントと連携できるか」という問いが生じる。
AIを持っていない企業も、利用しているSaaSベンダーがARDに対応しているかを確認する必要がある。どの立場であれ、無関係ではない。
こうした変化を、3つの側面から考えてみる。
1. B2B取引の自動化において「発見されない企業」になるリスク
AIエージェントが調達・発注・契約の一部を担う未来において、在庫照会や配送見積もりなどのAI機能を提供するSaaS事業者や、自社でAIを内製している企業がARDに対応していなければ、発注側エージェントの候補リストにそもそも上がらない。
これは、検索エンジンが普及した時代に「自社サイトを持たない企業」が商機を失ったことと構造的に同じだ。
2. SaaSベンダー選定の基準が変わる
自社がAIエージェントを活用して業務を自動化しようとするとき、連携先のベンダーがARD対応しているかどうかが選定基準になりうる。
今後の調達では「ARD対応」を確認項目に加える必要がある可能性が高い。
3. 自社AIの「外部公開戦略」が必要になる
自社で開発・運用しているAI機能を、どこまで外部エージェントに開放するか。
これは技術の問題である前に、事業戦略の問題だ。何を公開し、何をクローズドに保つか。ARDへの対応方針は、経営レベルの意思決定事項となる。
今、何をすべきか
ARDはまだ普及の初期段階にある。仕様が公開されたばかりのため、各社の実装はこれからであり、標準仕様として定着するという確証もない。
ただ、GoogleとMicrosoftをはじめ主要12社が支持しているという事実は重い。標準として定着した場合、早めに動いた企業ほど対応コストを低く抑えられる。
具体的には次の3点を起点に検討を始めることを勧める。
① 現状把握：自社が提供・利用しているAI機能・APIを棚卸しする。ARDカタログに掲載できる資産がどれだけあるかを把握する。
② ベンダーへの確認：利用中のSaaS・AIプラットフォームベンダーがARD対応を予定しているかを確認する。対応ロードマップがない場合、将来的な移行コストとして考慮に入れる。
③ 社内方針の策定：自社のAI機能をどの範囲で外部公開するか、情報セキュリティ・競争優位の観点から方針を定める。
④ カタログファイルの管理体制を整える
ai-catalog.jsonは自社ドメイン上に公開するファイルであるため、攻撃者にとって新たな標的になりうる。
ファイルを改ざんされると、他社のエージェントが意図しないサービスに誘導されるリスクがある。
ARDを導入するならば、カタログファイルのアクセス権管理・更新フロー・改ざん検知をセキュリティ対策の一環として検討しておく必要がある。
なお、ARD自体は「どの機能を使うかを選ぶ」ところまでが役割であり、実際の接続はMCP・A2A・APIといった別のプロトコルが担う。
役割が分かれている分、カタログファイルの管理責任が情報システム部門・セキュリティ部門・事業部門のどこに帰属するかが曖昧になりやすい。
導入前に管理体制を明確にしておくことが重要だ。
まとめ
ARDは「AIエージェント向けの検索エンジン標準」だが、その本質は「AIエージェント経済圏における存在証明」だ。
GoogleとMicrosoftを筆頭に主要12社が一斉に支持したこの動きは、AIエージェント同士が自律的に連携する世界の到来が、もはや仮定の話ではないことを示している。
標準化の波は、乗り遅れてから対応しようとすると想定以上にコストがかかる。
今のうちから準備を進めておくことが、次の競争に備える最初の一手となるだろう。