エージェントに『発見層』がやってきた——ARDが埋めるMCPの手前と、日本企業が置き直す統制の位置

つなぐ標準は揃った。次は「見つける」だ

homulaは、特定のベンダーやツールに縛られず、企業が自社にとって最適なAI構成を選び使い続けられるよう支援するAIインテグレーターです。その立場から2026年前半のエージェント標準化を見ていると、ある「欠けたピース」が急速に埋まりつつあります。

この2年で、エージェントがツールを呼ぶための MCP（Model Context Protocol） はほぼ業界標準になり、運営も一社の資産から中立団体へ移りました（MCPは『一社の資産』から『業界標準』へで既報）。エージェント同士をつなぐ A2A も、Linux Foundation傘下で150を超える組織が支持する段階にあります（Linux Foundation）。

ところが、企業が数十〜数百のMCPサーバーやエージェントを抱えるようになると、新しい問題が顔を出します。「そのタスクに使える道具は、そもそもどこにあるのか」——つなぐ規格が揃っても、エージェントが必要な能力を見つけられなければ意味がない。ここを埋めるために2026年6月に公開されたのが、本記事の主役 ARD（Agentic Resource Discovery） です。

何が起きたか——Google発、多社連合の「発見標準」ARD

ARDは、2026年6月17日にGoogleが公開した、AIの能力（ツール・エージェント・API）を横断的に公開・発見・検証するためのオープンな連合型（federated）仕様です（Google Developers Blog、Help Net Security）。ライセンスはApache 2.0、仕様は agenticresourcediscovery.org と GitHub（ards-project） で公開されています。

特徴的なのは、Google単独ではなく主要な企業ソフト／インフラのベンダーが名を連ねる点です。Microsoft、Salesforce、ServiceNow、Snowflake、Cisco、Databricks、GitHub、Hugging Face、NVIDIA などが策定に参加しています（InfoQ、Snowflake）。SnowflakeやServiceNowといった業務データ・業務プロセスの本丸が乗ってきたことで、7月に入り「エンタープライズの発見層」としての現実味が一段増しました。

ARDは「MCPの対抗」ではなく「MCPの手前」

ARDの核心は、発見（discovery）と実行（execution）を分けるという設計思想にあります。

• MCP は、エージェントがツールを呼び出すためのインターフェース（実行時の接続）。
• A2A は、エージェント同士が協調するためのプロトコル。
• ARD は、その手前で「どのMCPサーバーが／どのエージェントが目的に合うか」を探し当てるための層。

ARDのカタログ項目は、中身の規格を再定義しません。IANAメディアタイプ（application/mcp-server+json、application/a2a-agent-card+json など）でキー付けされた中立的なエンベロープとして能力を束ねるだけで、実体はあくまでMCPやA2Aのカードです（ARD仕様、Snowflake）。

動きはシンプルです。エージェントはHTTPで POST /search（意味検索）や POST /explore（ファセット集計）を発行し、連合レジストリから候補を得る。連合の振る舞いはクライアントが選べます——auto（レジストリが結果を統合）／referrals（クライアントが辿る）／none（単一レジストリのみ）。そして重要なのは、発見サービスは呼び出し経路には決して入らないこと。見つけた後、クライアントは選んだ相手にその相手固有のプロトコル（MCP／A2A／REST）で直接つなぎ、認証やデータのやり取りはクライアントと能力提供側の間だけで完結します（AgentPatterns）。

つまりARDは、エージェント版の「検索エンジン兼カタログ」です。事前にすべてのツールを組み込む（pre-install）のではなく、実行時に意味検索で能力を見つけ、native protocolで叩く——この「動的発見」が、規模が増えた企業で効いてきます。

なぜ今「発見層」なのか——MCPサーバーが増えすぎた

MCPが標準化した結果、皮肉なことにサーバーが増えすぎて管理不能になりつつあります。部門ごと・SaaSごと・業務ごとにMCPサーバーが立ち、エージェントに何を接続すべきか人間が手で決める運用は、数が三桁に乗ると破綻します。

ここで「全部を各エージェントに事前接続する」発想はスケールしません。接続先が増えるほどコンテキストは膨らみ、権限は散らばり、棚卸しは追いつかない。ARDが狙うのは、この**「静的な作り込み」を「動的な発見」に置き換える**ことです。カタログにドメイン起点の識別子と代表的な問い合わせ例を載せ、公開した瞬間に連合ネットワーク全体から検索可能になる——Snowflakeは、Snowsightでエージェントを公開すると組織の発見エンドポイントに自動登録し、MCPエンドポイントまで含めて発見可能にする構想を示しています（Snowflake）。

日本企業が置き直すべき論点

発見層の登場で、統制の重心が動きます。整理すると論点は三つです。

1. 発見 ≠ 認可。ARDは能力を見つけやすくしますが、認証・認可・監査は接続時（MCP／A2A側）に残ります。発見が速くなるほど、接続の関所の重要度は上がります。誰の・どのエージェントが・どのツールを・どの権限で呼んだか——ここを握れていないと、発見の高速化はそのままリスクの高速化になります。
2. 来歴（provenance）の検証。ARDは能力を暗号的に検証し、ドメイン起点の識別子で「誰が公開したか」を担保する設計です。社外レジストリまで連合させるなら、署名・発行元の検証を接続ポリシーに組み込む必要があります。
3. 自社カタログの主権。ARDは連合型で、単一企業がレジストリを独占しません。各社が自社カタログを持ち寄る前提だからこそ、**「自社の能力カタログを誰が持ち、どの範囲まで外部に晒すか」**が新しい設計判断になります。標準がどれか一つに収斂するのを待つより、まず内部カタログを整えておくのが現実的です。

homulaの観点——発見は開き、実行は締める

homulaの基本方針は、標準の勝ち負けに賭けるのではなく、どの標準が来ても崩れない統制の土台を先に作ることです。発見層の登場は、この方針をむしろ後押しします。

homulaの Agens は、MCPを活用したエンタープライズ向け統合プラットフォームとして、200以上のツールと構築ゼロで接続します。ARDのような発見層が普及しても、エージェントから見た接続点・権限付与を共通の枠組みで扱えるようにしておけば、「発見できる能力」が増えても接続の作り込みが増殖しません。発見はオープンに、しかし実行の入口は一本化する——ここが要点です。

そして「見つけた相手に無条件でつながない」を担保するのが Agens Control です。承認フロー・DLP・5年分の監査ログ・RBACをセットで提供し、発見が高速化した先で 「誰の・どのエージェントが・どのツールを・どの権限で呼んだか」 を横断的に追える状態をつくります。発見層はカタログを広げますが、関所は呼び出しの瞬間に置く——この分業が、便利さと統制を両立させます。MCPを軸にした接続設計は、MCP活用支援で扱う領域です。

導入の順序としては、(1) 社内のMCPサーバー・エージェントを棚卸しして自社カタログを作る → (2) Agens Controlで承認・監査・RBACの境界を設計する → (3) 読み取り系の低リスクな能力から発見・接続を解放し、書き込み系を段階的に開く、が現実的です。homulaの AIエージェント・ブートキャンプ では、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で行い、この最初の一歩を素早く形にします。

まとめ

ARDは、エージェントの相互運用スタックに欠けていた**「発見・検索の層」**を埋める標準です。Google主導ながらMicrosoft・Salesforce・ServiceNow・Snowflakeらが参画し、Apache 2.0のオープン仕様として2026年6月に公開されました。

要点は二つ。第一に、ARDはMCPの代替ではなく補完であること——発見（ARD）・接続（MCP）・協調（A2A）は役割が違い、発見サービスは実行経路に入りません。第二に、発見が速くなるほど、認可・監査・来歴検証といった「接続時のガバナンス」の価値が上がること。「見つけられる」を「呼んでよい」と取り違えない設計が、これからの分かれ目です。

---

エージェントが自分で能力を探し当てる時代は、企業にとって「何を発見可能にし、どこで接続を止めるか」という設計問題になります。標準の収斂を待つ前に、自社カタログの整備と接続時の統制から着手することが、安全な先行のカギです。

無料相談を予約する

Agens Controlで承認・監査・ガバナンス設計を見る

MCP活用支援の詳細を見る