AIエージェントが社内外のツールを使うには、まず「どこに何のツールがあるか」を見つけ、次に呼び出し方を合わせ、最後に返ってきたデータの意味を正しく読む必要があります。2026年6月17日にGoogleが発表したAgentic Resource Discovery（ARD）は、このうち「見つける」段階を標準化するオープン仕様で、Salesforceも創設パートナーとしてOpen Discoveryの考え方を説明しています。
AIエージェントのツールディスカバリとは、エージェントが使えるツールやデータの置き場所を実行時に見つけ、どれを使うか選ぶ仕組みです。ARDは「見つける・提供元を確かめる」、MCPは「見つけたツールを呼び出す」、社内の意味辞書は「返ってきたデータを正しく読む」を担当し、3つは互いの代わりになりません。見つけられることと安全に実行できることも別なので、権限・承認・監査ログは別に設計します。
要点
- ツールディスカバリは、AIエージェントが使えるツールの置き場所を実行時に見つけて選ぶ仕組みで、見つけられることと安全に実行できることは別です。
- ARDは発見と提供元の確認、MCPは呼び出し、社内の意味辞書は返り値の解釈を担当し、互いの代わりにはなりません。
- 導入前に、許可するツールの一覧、環境の分離、返り値の定義、操作ごとの承認、ログ項目を社内で決めておきます。
発見・接続・意味解釈の役割の違い
ツールディスカバリをめぐる用語は、担当する段階で分けると混同しにくくなります。
| 段階 | 担う仕組み | 答える問い | これだけでは足りないこと |
|---|---|---|---|
| 発見 | ARD（カタログとレジストリ） | この作業に使えるツールはどこにあり、どれが候補か。提供元は本物か | 呼び出し方、社内での使用可否 |
| 接続 | MCP（サーバーとクライアントの通信仕様） | 見つけたツールをどう呼び出し、結果をどう受け取るか | どのサーバーが存在するかの探索、データの意味 |
| 意味解釈 | 社内の意味辞書（セマンティックレイヤー） | 返ってきた「ステージ」「金額」が業務上何を意味するか | ツールの発見や呼び出し |
| 実行制御 | 権限・承認・監査ログ | この操作をこの利用者の代わりに実行してよいか | 上の3つのどれでも代わりにならない |
この4つを同じものとして見ると、導入判断が曖昧になります。どこに製品の機能があり、どこに自社側の設計が必要かを段階ごとに確かめてください。意味辞書の作り方はセマンティックレイヤーの記事、実行権限の切り方は権限設計の記事で扱います。
ARDでツールはどう見つかるか
ARDでは、ツールを提供する組織が、自社ドメインの決まった場所に「どんなエージェント、MCPサーバー、APIを公開しているか」を書いたカタログを置きます。Salesforceの説明では、カタログを自社の環境の中だけで非公開にする使い方もあります。レジストリと呼ばれる索引サービスがカタログを集めて検索できるようにし、エージェントは「この作業に使えるツールは何か」を自然文で問い合わせて候補を受け取ります。取引先など相手が決まっている場合は、検索を通さずに相手のカタログを直接読みにいくこともできます。
Googleの発表によると、カタログに載せられるのは、MCPサーバー、A2A（エージェント同士が連携するための仕様）に対応したエージェント、OpenAPIで記述したAPI、さらに別のカタログです。仕様はApache 2.0ライセンスで公開され、Linux FoundationのAI Catalog Working Groupが進めるAI Catalogのデータモデルを土台にしています。Salesforceの説明では、レジストリ同士が互いを参照できるため、中央の管理者がいなくても検索できる範囲が広がる設計です。
Googleの発表では、ドメインの所有が身元と信頼の土台になり、エージェントは接続前に提供元を確かめられます。Salesforceは、すべてのツール説明をAIの入力に読み込むのではなく、検索の段階で候補を絞るため、エージェントが扱う情報量を抑えられると説明しています。
MCP側の変化
MCPは2026年7月28日版の仕様で、接続ごとの初期化手順をなくし、サーバーが対応する版や機能、名前を返す server/discover を必須にしました。ただし、これは「つないだ相手が何者か」を確かめる仕組みで、「どこにサーバーがあるか」を探す仕組みではありません。サーバーの所在を見つける段階は、ARDのような発見の仕組みと組み合わせて考えます。
同じ版では、サーバーがツール一覧を毎回同じ順序で返すことが推奨され、ツール一覧などの結果にはキャッシュしてよい期間を示す項目が必須になりました。クライアントは一度取得した一覧を一定期間使い回せるため、ツールが多い環境でも一覧の取り直しを減らせます。発見の段階で候補を絞るARDと、接続後の一覧を効率よく扱うMCPの変更は、どちらもエージェントが扱うツールの数が増えることを前提にしています。
導入前に社内で準備すること
- 使ってよいツールの一覧を作る：レジストリで見つかる候補をそのまま使わず、社内で許可した提供元とツールだけを候補にする。
- 接続先の環境を分ける：テスト用と本番用のサーバーやAPIを別の名前・別の認証情報で登録する。
- 返り値の意味をそろえる：ツールが返す項目と社内の業務定義を対応させ、意味辞書に書く。
- 操作ごとに承認を決める：外部送信、価格提示、契約条件、個人情報の更新は人の承認を必須にする。
- ログに残す項目を決める：どのツールを、誰の権限で、どの入力で呼び、何が返ったかを記録する。
許可済みツールの一覧には、提供元のドメイン、用途、接続に使う認証情報、承認が必要な操作、担当者を並べておくと、レジストリで新しい候補が見つかったときに追加してよいかを同じ基準で判断できます。使わなくなったツールを一覧から外す担当も決めておきます。ツール接続は管理者権限ではなく、用途別の最小権限で分けます。製品ごとの機能名で比べるのではなく、自社の業務フローのどの段階に当てはまるかに置き換えて評価すると、足りない部分が見えやすくなります。
よくある質問
AIエージェントのツールディスカバリとは何ですか？
AIエージェントが利用できる外部ツール、API、MCPサーバー、データソースを見つけるための仕組みです。業務利用では、発見できることに加えて、権限、承認、監査ログをセットで設計する必要があります。
ARDとMCPは何が違いますか？
ARDはツールの置き場所を見つけ、提供元を確かめるための仕様です。MCPは見つけたツールを呼び出すための通信仕様です。2026年7月28日版のMCPにはサーバーの情報を返す仕組みがありますが、サーバーの所在を探す役割はARDのような発見の仕組みが担います。
レジストリで見つかったツールはそのまま使ってよいですか？
そのまま使うのは避けます。提供元を確かめられても、社内で許可した用途・権限・データ範囲に合うかは別の判断です。許可済みのツールだけを候補にする一覧を社内で持ちます。
ARDのカタログには何を載せられますか？
Googleの発表では、MCPサーバー、A2Aに対応したエージェント、OpenAPIで記述したAPI、別のカタログを載せられます。社外に公開するだけでなく、自社の環境の中だけで非公開のカタログを持つ使い方もSalesforceが説明しています。
最初に確認すべき設定は何ですか？
権限、接続先、承認条件、監査ログ、例外時の停止・差し戻し手順を先に確認します。特に更新、送信、契約条件、個人情報に関わる操作は、人間承認を前提に設計する方が安全です。
