Agentic Resource Discoveryとは：ai-catalog.json、検証、スマホ操作の認可を分けて考える

Agentic Resource Discoveryが解く問題

Agentic Resource Discovery、略してARDは、AIエージェントが利用できるツール、スキル、エージェントをWeb上で見つけるための仕様です。2026年6月17日のGoogle Developers BlogによるARD発表では、組織が自社ドメインにカタログを公開し、レジストリがそれをクロールして索引化し、クライアントが意図に合う能力を探せる形が説明されています。

この仕様が必要になる背景は単純です。エージェントが増えるほど、使えるAPI、MCPサーバー、A2Aエージェント、OpenAPIツール、社内スキル、外部サービスの場所がばらけます。人間ならドキュメントを読み比べられますが、エージェントには「どこに何があり、誰が公開し、どう接続するのか」を機械的に扱える入口が必要です。ARDは、その入口をドメイン上のカタログと探索可能なレジストリとして整える試みです。

ここで最初に分けたいのは、発見と実行です。ai-catalog.jsonに能力が載っていることは、「その能力を見つけられる」という意味です。スマホエージェントにとっては、そこからさらに、端末側で使える契約か、Android権限が必要か、ユーザーが承認するべき操作か、結果をどう確認するかを判断します。ARDは信頼できるエージェントツール一覧へ近づくための基盤ですが、スマホ操作の許可証ではありません。

カタログとレジストリで能力を公開し、見つける仕組み

ARDの流れは、公開、探索、検証、接続に分けると理解しやすくなります。公開者は自社ドメインにai-catalog.jsonのようなカタログを置き、そこに提供するリソース、説明、インターフェース、検証情報、場合によっては別カタログへの参照を記述します。ARDの公開仕様とリポジトリでは、仕様、スキーマ、信頼アーキテクチャ、参照実装に関する作業が公開されています。

レジストリは、そのカタログを集めて検索しやすくする役割を持ちます。クライアントは「請求書を作成できるツール」「顧客レコードを更新できるエージェント」「スマホで次の予定を扱うための能力」のように意図で検索し、候補の説明や公開者情報を受け取ります。すでに相手先ドメインが分かっている場合は、レジストリ検索を経由せず、既知のパートナーが公開するカタログを直接取得する使い方もあります。

カタログとレジストリは同じものではありません。カタログは公開者が自分の能力を説明する場所です。レジストリは複数のカタログを見つけやすくする索引です。どちらも実行代理ではなく、ツールを勝手に起動する存在でもありません。スマホエージェントの文脈では、レジストリで候補を見つけ、カタログで詳細を読み、ネイティブな接続方式を確認し、その後に端末側の実行判断へ進む、という段階的な扱いが必要です。

公開者検証で分かること、分からないこと

信頼できるエージェントツール一覧を作るうえで、公開者検証は大きな前進です。ARDの発表では、本番環境での探索において、直接のネイティブプロトコル接続に進む前に、暗号学的に検証可能な公開者メタデータを含められると説明されています。これは「その能力が本当にそのドメインや組織から示されているのか」を確認する材料になります。

ただし、公開者が正しいことと、すべての操作が安全であることは別です。正規のドメインが公開したツールでも、要求するスコープが広すぎる、説明と実際の副作用が合わない、古いエンドポイントが残っている、スマホ側の操作対象がユーザーの意図とずれる、といった問題は起こり得ます。検証は接続前の信頼を高めますが、ユーザーの権限や実行承認を代替しません。

スマホでは、この違いが特に重要です。公開者検証は「誰の能力か」を見る仕組みです。Android権限は「端末上のどのデータや機能へアクセスするか」を扱います。行動承認は「この相手に送る、この設定を変える、この場所情報を使う」といった具体的な結果をユーザーが許すかどうかです。AIエージェントのリソース探索では、この三つを混ぜないほど運用しやすくなります。

ARDはMCP、A2A、OpenAPI、アプリ契約へ受け渡す

ARDは、MCP、A2A、OpenAPIをひとつにまとめる仕様ではありません。カタログは、MCPサーバー、A2Aエージェント、OpenAPIツール、入れ子になった別カタログなどを広告できます。ARDが担当するのは、リソースを見つけ、説明を読み、検証材料を確認し、どのネイティブな接続方式へ進むかを決めるところです。

その後は、それぞれの契約が重要になります。MCPならサーバーが公開するツールと呼び出し形式、A2Aならエージェント間のタスク受け渡し、OpenAPIならエンドポイント、認証、入力スキーマ、レスポンス、エラー処理を確認します。スマホアプリに近い領域では、アプリが機械から呼び出せる機能を持っているかも別の論点です。発見後のアプリ呼び出し契約を詳しく見る場合は、App Intentsと機械呼び出し可能なアプリ: AIエージェントがスマホ操作を実行する仕組みが、探索後に何を検証するべきかを補います。

つまり、ARDは地図に近い役割です。地図に入口が載っていても、その建物に入る権限、部屋ごとの許可、作業を完了してよいかの判断は別に必要です。AIエージェントのリソース探索をスマホ操作へつなぐなら、カタログ解決の後に、プロトコル検証、端末側のツール有効化、Android権限、ユーザー承認を順番に置く設計が現実的です。

スマホでは探索と認可を分ける必要がある

ai-catalog.json ツールカタログに目的の能力が見つかったとしても、それだけでスマホ操作を始めるべきではありません。スマホには連絡先、位置情報、写真、通知、メール、メッセージ、決済に近い画面、仕事用アカウントが集まります。発見したリソースが正規の公開者から来ていても、「この端末で、このユーザーの権限で、この対象に、この操作をしてよいか」は改めて判断します。

Androidのランタイム権限ガイドでは、機能が必要になった文脈で権限をリクエストし、拒否された場合の扱いもアプリ側の責任として説明されています。これはARDとは別の層です。ARDは公開者や能力の発見を助けますが、Androidの連絡先権限や位置情報権限を付与しません。また、Android権限があることも、取引先へメールを送る、予定を変更する、外部サービスへデータを渡すといった業務上の結果を自動承認するものではありません。

スキル単位の権限確認を深く扱う場合は、AIエージェントのスキル安全性：スマホ権限は実行時に確認すべき理由が隣接する整理になります。さらに、誰が何を実行し、どの権限で、どの履歴を残すかは、AIエージェントのID・権限・監査ログ：スマホエージェントに必要な安全基盤で扱う領域です。このページでは、ARDの発見機能を出発点に、スマホ上の認可へ分けて進むことに焦点を置きます。

発見したリソースを接続・実行する前の確認リスト

発見したリソースをスマホエージェントで扱うなら、接続前と実行前を分けて確認します。接続前は「相手を信頼できるか」と「技術的につながるか」を見る段階です。実行前は「この端末、このユーザー、この対象、このタイミングで実行してよいか」を見る段階です。両方を一つの許可ボタンに押し込むと、トラブル時にどこで判断を誤ったのか分かりにくくなります。

1. 公開者を確認する。ドメイン、組織名、検証メタデータ、カタログ取得元が期待どおりかを見る。
2. カタログの鮮度を見る。更新日、バージョン、参照先、入れ子カタログの範囲を確認する。
3. ネイティブな接続方式を検証する。MCP、A2A、OpenAPI、アプリ契約のどれで呼び出すのかを明確にする。
4. 要求スコープを読む。読み取りだけか、外部へ送るのか、端末設定や通信に触れるのかを分ける。
5. 端末側でツールを有効化する。既定で有効にするのではなく、用途に合う範囲から始める。
6. 低リスクの読み取りテストから始める。成功だけでなく、権限拒否、接続失敗、対象違いの挙動を見る。
7. 実行対象を確認する。送信先、ファイル、予定、場所、アプリ名などがユーザーの意図と一致しているかを確認する。
8. 承認と結果表示を分ける。実行前の確認、実行中の状態、実行後の結果を見える形にする。
9. 停止と取り消しを用意する。ツールの無効化、権限の取り消し、接続解除、履歴確認、失敗時のフォールバックを確認する。

この順番は、信頼できるエージェントツール一覧を作るための一般的な表ではなく、スマホで実行するための実務手順です。検索で見つかった候補をすぐ使うのではなく、接続前に相手を見て、実行前に端末とユーザーの意図を見る。これが、リソース探索を便利にしながらAndroid操作の重さを扱うための基本です。

FoneClawはカタログの可視性とスマホ操作の権限を分ける

FoneClawでは、モデルが計画し、FoneClawが対応済みのAndroidツールを呼び出す形でスマホ操作を扱います。ここで重要なのは、カタログに見えることと、端末で実行できることを分ける設計です。現在のFoneClawはARD実装をうたうものではありません。私たちがこの文脈で示したいのは、発見された能力をそのまま権限として扱わず、ランタイム側でツール範囲、リスク、承認、権限回復を管理する考え方です。

FoneClawの公開リリース情報では、0.1.0でツール管理、承認、権限回復、より安全なツール契約、信頼されたプラグイン継続に関する改善が含まれます。また、FoneClawの公開ツールカタログの2026年8月1日時点のスナップショットには、11カテゴリに118個の組み込みツールが含まれ、リスクや承認ラベルが付いています。長く使う説明では、私たちは100+ built-in toolsという表現を使い、固定数を永続的な約束として扱いません。

FoneClawの製品範囲は、探索結果を黙ってインストールしたり、外部リソースを自動で信頼したりすることではありません。対応済みツールは可視化され、必要な場面で権限が案内され、影響のある操作はツールポリシーとユーザー確認に沿って扱われます。署名されたプラグイン経路も、見える提案から始まり、サイレントな発見や導入として扱いません。Androidの意図から行動までの全体像を確認したい場合は、スマホ AI エージェント制御とは何か：Androidを任せる前に見るべき仕組みと安全性が、FoneClawのスマホ実行モデルを広く整理しています。

エージェント用レジストリを採用する前に検証すること

チームがARDやai-catalog.json ツールカタログを検討するときは、「標準があるか」だけでなく「運用で観測できるか」を見ます。発見の品質、検証の強さ、接続方式の明確さ、端末側ポリシーとの接続、失敗時の復旧までを別々に測ると、採用判断が現実的になります。

採用の目安は、発見と権限をそれぞれ観測できることです。レジストリが優れていても、端末側で何が有効になったのか分からないなら、スマホ操作には早すぎます。逆に、端末側の承認が堅実でも、カタログの公開者や鮮度を見ないなら、接続先の信頼判断が弱くなります。Agentic Resource Discoveryは、エージェントが能力を見つけるための重要な前進です。その価値をスマホで活かすには、最後の一歩を認可として別に扱うことが必要です。