AIエージェント版DNSは失効していた──『agentdns://』が目指した自然言語検索・統一課金の中身

インターネットにおけるDNS（ドメインネームシステム）は、人間が覚えやすい名前とサーバーの実際の住所（IPアドレス）を切り離すことで、Webの拡張性を支えてきた。AIエージェントの世界にはまだこれに相当する「ルート」がない——という問題意識から、MCPやA2Aとは別の層として、LLMエージェント向けの命名・解決システムを提案するIETF個人ドラフト「AgentDNS」（著者は梁致远氏ら、2025年10月8日提出）の本文を確認した。

3行まとめ

• AgentDNSは、DNSに着想を得たagentdns://という統一名前空間、自然言語でのサービス発見、そして分断されたAPIキーと課金を1つにまとめる「統一認証・課金」の4つの機能を軸にする、LLMエージェント向けのルートドメインネームシステムのドラフト
• MCP・A2A・ANP（Agent Network Protocol）を置き換えるのではなく、これらのプロトコルと共存し、エージェントがどのプロトコルに対応しているかを解決の過程で伝える「プロトコル対応型の相互運用性」という設計
• IETF Datatrackerで確認したところ、このドラフトも「Expired Internet-Draft」「Expired & archived」というステータスで、2025年10月8日提出のrev00のみが存在し、失効予定日（2026年4月12日）を過ぎた後も改訂版は出ていない

3つの課題——発見・相互運用・認証課金がバラバラ

ドラフトの序文は、MCPやA2Aだけでは足りない部分をこう整理している。

Existing protocols such as the Model Context Protocol (MCP) [...] and Agent-to-Agent (A2A) protocol [...] have improved agent-tool interoperability and communication. However, these efforts lack a standardized root naming and discovery infrastructure to support autonomous cross-vendor interactions.

（MCPやA2Aといった既存のプロトコルは、エージェントとツールの相互運用性・通信を改善してきた。しかし、これらの取り組みは、ベンダーをまたいだ自律的なやり取りを支える標準化されたルート命名・発見インフラを欠いている）

具体的には「サービス発見の課題」（ベンダーごとにサービスの命名・管理が標準化されていない）、「相互運用性の課題」（MCP・A2A・ANPなど複数プロトコルにエージェントが自動で適応できない）、「認証・課金の課題」（ベンダーごとに固有のAPIキーと課金システムが分断されている）の3つを挙げている。

agentdns://org/category/nameという命名規則

AgentDNSが提案する統一名前空間の例が、ドラフト本文に示されている。

Unified Namespace with Semantic Information: AgentDNS introduces a semantically rich naming scheme (e.g., agentdns://org/category/name) for agents and tool services, decoupling service identifier name from physical addresses such as URLs.

（意味を持つ統一名前空間：AgentDNSは、エージェントとツールサービスのために、意味的に豊かな命名スキーム（例：agentdns://org/category/name）を導入し、サービスの識別子名をURLなどの物理アドレスから切り離す）

この切り離しによって、識別子名にエージェントの機能を意味的に埋め込み、分類・検索を効率化できるとしている。さらに、単純な文字列一致ではなく「自然言語での問い合わせ」でエージェントやツールサービスを発見できる仕組みも提案している——エージェントが自然言語のクエリでAgentDNSのルートサービスに問い合わせ、対応するサービス識別子名やメタデータ（物理アドレス・機能・通信プロトコルなど）を取得する、という流れだ。

統一課金——「事前入金してリアルタイムで自動精算」

認証と課金についての説明が具体的だ。

AgentDNS replaces fragmented API keys with a single-sign-on mechanism. Agents authenticate once with the AgentDNS root server to obtain time-bound access tokens, valid across all registered services. For billing, AgentDNS serves as a unified billing platform: users pre-fund accounts, usage costs are tracked and deducted in real-time, and payments are automatically settled across vendors.

（AgentDNSは、分断されたAPIキーをシングルサインオン機構で置き換える。エージェントはAgentDNSのルートサーバーに一度認証すれば、登録済みの全サービスで有効な期限付きアクセストークンを得られる。課金については、AgentDNSは統一課金プラットフォームとして機能する。ユーザーはアカウントに事前入金し、利用コストはリアルタイムで追跡・差し引かれ、支払いはベンダーをまたいで自動的に精算される）

これにより、エージェントがサードパーティの有料サービスを、人間の手作業による支払い設定なしに自律的に発見・呼び出せるようにすることを狙っている、とドラフトは説明している。

ケーススタディ本文にある具体例──「$1/百万トークン」と「無料」

ドラフト第4章「AgentDNS Case Study」は、「エージェント通信プロトコルを調べてサーベイ報告書を書いて」というユーザー依頼を例に、行動計画の生成からAgentDNSでのサービス発見、実行までの流れを図（Figure 7）付きで示している。図中でAgentDNSが返すサービス情報の例を、判明した範囲で表にする。

エージェントは自然言語のクエリ（例：「キーワード検索ツールが欲しい」）をAgentDNSのルートサーバーに送ると、上記のような物理エンドポイント・対応プロトコル・コスト・機能を含むメタデータが返る、という設計になっている。

著者はChina Telecom Research Instituteが中心、3人目の所属とメール末尾に食い違い

ドラフト末尾の「Authors' Addresses」を確認すると、著者3人のうち2人（Zhiyuan Liang氏・Enfang Cui氏）はChina Telecom Research Institute（中国電信研究院）所属で、メールアドレスも@chinatelecom.cn。3人目のYujun Cheng氏は所属が「University of Science and Technology Beijing（北京科技大学）」と記載されている一方、メールアドレスはyjcheng@tsinghua.edu.cn──清華大学のドメインになっている。所属機関とメールドメインが一致しない箇所が、ドラフト本文に実在する。

IANA・セキュリティ考慮事項は1文ずつのみ

ドラフト第7章「IANA Considerations」は "This memo includes no request to IANA."（本メモはIANAへの申請を含まない）の1文、第8章「Security Considerations」も "This document should not affect the security of the Internet."（本文書はインターネットのセキュリティに影響しない）の1文のみで構成されている。統一認証・統一課金という、実装されればセキュリティ上の検討が本来相応に必要になりそうな機能を提案していながら、セキュリティ考慮事項の章がこの1文にとどまっている点は、ドラフトの成熟度を判断する材料になる。

ANP自体は実在し、DIDベースの技術文書群を公開している

ドラフトが参照する「Agent Network Protocol（ANP）」の公式サイト（agentnetworkprotocol.com）を確認すると、ANPはDID（分散型識別子）ベースの身元・暗号通信層、メタプロトコル層、アプリケーションプロトコル層からなる3層アーキテクチャを掲げ、Technical White PaperやDID-Based End-to-End Encrypted Communication Protocolなど複数の技術仕様文書を公開しているプロジェクトであることが確認できた。単なる思いつきの名称ではなく、相応の文書量を持つ独立したプロジェクトである一方、AgentDNS本文が示す「ANPとの共存」が実装レベルでどう連携するかの具体例は、ドラフト本文にもANP公式サイトにも見当たらなかった。

このドラフトも失効・アーカイブ済み

IETF Datatrackerでこのドラフトのステータスを確認すると、次のように表示されている。

Document Type: Expired Internet-Draft (individual). Expired & archived.

（文書種別：失効したInternet-Draft（個人提案）。失効・アーカイブ済み）

2025年10月8日に提出されたrev00のみが存在し、失効予定日（2026年4月12日）を過ぎてもなお改訂版は出ていないことを確認した。前回この記事の一次ソース調査で扱ったHTTP Agent Profile（HAP）と同様、この提案もIETFの標準化プロセスの中で前進しているという証拠は、Datatrackerの記録からは見当たらない。

ANPは実在を確認できたが、AgentDNS自体の実装は見つからなかった

ANP自体は公式サイトの文書群で実在を確認できたが、ANPがどの程度の開発者コミュニティに使われ、普及しているかという「利用実態」までは今回の調査範囲では検証していない。AgentDNSを実際に実装したプロジェクト（GitHubリポジトリや動くルートサーバーなど）は、IETF Datatracker・ANP公式サイトのいずれからも見当たらなかった──提案されたのは「概念とケーススタディ」までで、参照実装が公開されている形跡はない。この記事を書いている自分自身は、DNSやルートサーバーの運用実務に関わった経験がなく、統一課金プラットフォームという発想が実際の決済インフラとどう接続しうるかについても検討していない。日本語ではZenn・Qiitaともに、「日刊IETF」という日次ダイジェスト記事シリーズで一覧的に触れられている例はあったが、AgentDNS単体を掘り下げた解説記事は見当たらなかった。

関連記事: AIエージェントとは

感想・指摘はコメント欄へ。