エージェントが自分の道具を見つけられない — ランタイム道具探索レイヤー

どんな問題か

今AIエージェントが道具を得る方式は「インストール優先、利用は後」だ。開発者がMCPサーバーのURLを設定ファイルに手で書き込んで初めて、エージェントはその道具を使える。この方式は規模が大きくなると崩れる。エージェントが作業の途中で初めて見る道具を動的に発見する術がないからだ。よくある回避策 — 全道具の説明をLLMのコンテキスト窓に流し込む — も限界がはっきりしている。トークン予算が阻み、道具が数十個を超えるとモデルはどれを選ぶべきか混乱する。結局エージェントの能力は、開発者が前もって想像し書き込んだ道具の集合に閉じ込められる。ユーザーが「このPDFを会計システムに入れて」と頼んでも、その会計コネクタが事前にインストールされていなければエージェントは存在自体を知らない。人間なら検索して見つけることを、エージェントはできない。道具自体は爆発的に増えている — MCPサーバー、AIスキル、MLアプリケーションが数千個 — のに、肝心のエージェントがその中から適したものをランタイムに見つけて選ぶレイヤーが空いている。

なぜ今か

タイミングを作ったのは標準の登場だ。Hugging FaceがMicrosoft・Google・GoDaddyらとともにARD(エージェント資源探索)の草案仕様を公開した。モデルは単純だ。ドメインのよく知られたパスにai-catalog.jsonを置けば、レジストリが索引し、エージェントが自然言語の意図で検索し、発行者を検証してMCP・A2A・通常のAPIで接続する。エージェントのためのDNSと電話帳というわけだ。仕様は静的マニフェスト(ai-catalog.json)と動的レジストリAPI(自然言語のPOST /search)の二つを定義する。標準が着地したということは、その上で競う土俵が開いたということだ。ドメイン名システムが標準化されてDNS事業者やレジストラが生まれたのと同じだ。今は標準がまさに草案段階で、索引品質・ランキング・発行者検証といった「実際に使えるレジストリ」はまだ空いている。標準自体は誰が検索を上手くやるかを決めない。同じ意図にどの道具を1番に上げるか — そのランキング品質こそ製品の競争力であり、その席はまだ主がいない。

どう作るか

ARD仕様に従う道具探索レジストリを作る。核心は三つだ。第一に、クロールと索引 — ドメインごとに散らばるai-catalog.jsonを集め、道具の説明・代表クエリ・タグを埋め込みで索引する。第二に、意図ランキング — エージェントが自然言語で「Xをしたい」と検索すると、適した道具を信頼度順に返す。単なるキーワード一致ではなく、発行者の身元・準拠証明・実際の利用信号を重みに入れて精度を上げる。第三に、検証ゲート — どんな道具でも露出させず、発行者を検証し悪意ある・なりすましの道具をふるい落として、エージェントが安全に接続できるようにする。収益は道具発行者側(露出・優先索引のB2B課金)とエージェント開発者側(検索API呼び出し課金)の両面で立てる。最初から全道具を扱おうとせず、一つの垂直領域 — 例えばフィンテックのコネクタやデータパイプラインの道具 — の索引品質を圧倒的に引き上げ、そこで標準レジストリとして地位を築くのが現実的だ。Hugging FaceのDiscover Toolのようなリファレンス実装は既にあるので、差別化は「どれだけ正確に、どれだけ安全に」適した道具を見つけるかだ。