エージェントが使う道具が増えると、次の問題は性能ではない。どこに何があるのか、どうやって見つけるのか、そして誰を信じるのかだ。

直近のRadarに入っている「AI Tool Discovery at Scale: All You Need is DNS」というプレプリントは、そこに一つの答えを出している。香港大学のEnhao ChenとYulin Shaoが提案するToolDNSの核心は、実は検索の話ではない。サービス発見はインフラ設計の視点で見れば、純粋な意味マッチングの問題ではなく、大部分を命名の問題に還元できる——そう論文本文に書いている。意味検索のO(N)を、名前解決のO(log N)に変えるという提案だ。

機能と信頼の属性を階層的な名前空間に埋め込めば、適切な道具を見つける行為は、ドメイン名を解決する行為と等価になる。エージェントが「英語を中国語に訳せる道具はどれか」と尋ねるとき、それは制約条件を満たすサービスの名前を尋ねている。DNSは、階層的な名前空間、再帰的な解決、分散キャッシュ、DNSSECのような暗号拡張、そして委任を最初から持っている。だから使う、という筋だ。

ここで引っかかってほしい。意味から名前へ還元するということは、名前を持たないものは意味的に適切でも見つからない、ということだ。登録できない小さな提供者、信頼属性を用意できない組織、命名規則の外にある道具は、ランキングで負けるのではなく、解決されない。

著者たちは、むしろ逆を狙っている。partially unfolded names、EDNS0 intent payloads、logical subdomainsという三つの拡張を導入する目的は、非中央集権的な統治と意味的な枝刈りを可能にすることだと要旨に明記されている。だがDNSは、委任とルートゾーンという統治機構そのものでもある。

DNSの類推を採ると、その統治構造も一緒に付いてくる。委任は誰が誰に与えるのか。ルートに相当する層を誰が持つのか。可視性の争点が、検索アルゴリズムからレジストリへ移る。SEOではなく、レジストラの話になる。

この論点はまだ決着していない。DNSを推す提案は他にもある。Verisignの研究者らは119,757件の実サービスエンドポイントを使い、必要なデータ量が単一のDNS UDPトランザクションに収まり、その遅延がミリ秒級になりうると報告している。一方、「Beyond DNS」と題した別のプレプリントは、DNS中心の識別・発見にかかる負荷を問題にし、NANDA Indexと検証可能な属性情報であるVerified AgentFactsを提案する。いずれもプレプリント段階の主張だ。実験と性能比較は、そのつもりで読む。

実務担当が今やることは、巨大な発見基盤を待つことではない。社内のエージェント用ツールに、所有者、用途、必要権限、入力データ、障害時の止め方を一枚で結びつけることだ。そして、その一枚の命名規則を誰が決めているかを確認する。名前はラベルではなく、運用責任の入口になる。

棚の住所と鍵の持ち主が曖昧なまま道具を増やすと、後で探せないし、止められない。そして誰が住所を配るのかは、たぶんもう決まりはじめている。

出典リスト