マルチエージェント環境では、エージェント同士が相手を見つけられないことがボトルネックになっています。2026年5月27日、Linux FoundationはDNS-AID（Domain Name System for AI Discovery）プロジェクトを立ち上げ、インターネットが40年前から使ってきたDNSの仕組みでAIエージェントの発見と検証を行うオープン標準を公開しました。

この記事では、DNS-AIDが解決する課題と技術の中身、MCPやA2Aなど既存プロトコルとの関係、そして開発者が今すぐ試せる実装状況を整理します。

この記事でわかること

  • DNS-AIDが狙う課題と、集中型レジストリとの違い
  • SVCBレコードとDNSSECを使った発見・検証の仕組み
  • MCP・A2A・ANSとの役割分担
  • 参照実装の提供状況と導入の第一歩

エージェント同士が見つけられない問題

複数のAIエージェントを運用する現場では、接続先の指定方法が大きな障壁になります。現状の主流は、固定URLをコードに埋め込む方法か、特定ベンダーが運営する専用レジストリへの登録です。Google Cloud、Azure、オンプレミスにまたがる環境では、エージェントごとに接続先を手動設定するか、商用の仲介サービスに依存する必要があります。

この摩擦は今後さらに大きくなります。Gartnerの2026年予測では、2030年までにAIエージェント導入失敗の半数が、ガバナンス不足とシステム間の相互運用性の欠如に起因すると見ています。2026年2月にはNISTがAI Agent Standards Initiativeを始動し、自律エージェントの身元・セキュリティ・相互運用性の標準化に取り組んでいます。DNS-AIDは、この標準化の流れの中で候補の一つとして位置づけられています。

DNS-AIDが提案する解決策

https://github.com/dns-aid

DNS-AIDは、新しいDNSレコードタイプや専用サーバーを要求しません。RFC 9460のService Binding（SVCB）レコードの上に、エージェント向けの命名規則を載せる設計です。Infobloxが最初のコードを書き、Linux Foundationのガバナンス下でオープンソースプロジェクトとして公開されました。創設メンバーにはCloudflare、GoDaddy、Equinix、Internet Systems Consortium、Infobloxなどが名を連ねています。

エージェントは組織のドメイン配下に、決まった形式のDNSアドレスで公開します。たとえばexample.comでMCPプロトコルを話すチャットボットなら、_chatbot._mcp._agents.example.comのようなラベルに登録します。発見側のエージェントは、通常のDNSクエリを送るだけで接続先を取得できます。専用クライアントや事前の契約関係は不要です。

SVCBレコードには、通信プロトコル、サービスポート、機能記述書へのURI、そのハッシュ値、プロトコルバージョン、ガバナンスポリシーのURL、テナント識別子などが含まれます。IETFドラフト（draft-mozleywilliams-dnsop-dnsaid-02、2026年5月27日版）では、接続情報とメタデータを1つのDNSレコードにまとめることを基本としています。

3つの発見モード

DNS-AIDは、用途に応じて3段階の発見モードを想定しています。

直接検索は、エージェント名とドメインが分かっている場合に使います。1回のSVCBクエリで接続先とメタデータを取得します。IETFドラフトでは、この形式を発行者が必ず対応し、要求側も最初に試すべき方法と定めています。

組織インデックス検索は、ドメインは分かるが特定のエージェント名が不明な場合です。_index._agents.example.comへのクエリで、その組織が公開するエージェント一覧の入口を取得します。一覧から目的の機能を持つエージェントを選び、以降は直接検索に切り替えます。

機能ベース検索は、必要な機能は分かるが組織もエージェント名も不明な場合です。これはDNS-AID単体のスコープ外とされ、組織インデックスを横断するディレクトリサービスで補完する想定です。参照実装のPython SDK（v0.19.0以降）では、オプトインのディレクトリAPIを使った横断検索も用意されています。

セキュリティ設計

エージェント発見のセキュリティは、DNSSECとDANE（DNS-based Authentication of Named Entities）で担保します。DNSSECはDNSルートから個々のエージェントレコードまでの署名チェーンを検証し、改ざんやなりすましを防ぎます。DANEはTLS証明書をDNSレコードに結びつけ、中間者攻撃でもドメインのDNSゾーンを制御していない攻撃者は有効な証明書を提示できません。

2026年1月、Akamaiは「ダングリングDNS」をAI導入の見落とされがちな攻撃面として分析しました。クラウドリソースの廃止後もDNSレコードが残り、別の攻撃者がそのエンドポイントを再利用するケースです。DNSSECで署名されたDNS-AIDレコードは、この種のリスクへの対策として位置づけられています。

ただし、IETFドラフトは明確に述べています。DNS-AIDはエージェントのメタデータを検証可能な形で届ける仕組みであり、発見したエージェントがメタデータどおりに振る舞う保証はしません。発見はインフラ層の責務で、エージェントの行動はアプリケーション層の問題です。

MCP・A2A・ANSとの関係

DNS-AIDは、エージェントが見つかった後の通信プロトコルには踏み込みません。役割は発見の1層下にあります。

MCP（Model Context Protocol）はAnthropicが策定したオープン標準で、エージェントが外部ツールやデータソースと接続する方法を定めます。DNS-AIDのSVCBレコードは、対象エージェントがMCPを話すことを宣言できます。発見側は接続前にプロトコルを把握できます。

A2A（Agent-to-Agent）はGoogleが提唱するエージェント間のタスク連携プロトコルです。.well-known/agent-card.jsonにAgent Cardを公開する方式が知られていますが、これはHTTPでドメインが応答する必要があります。DNS-AIDはDNSクエリだけで同様の接続情報を取得できる点が異なります。

ANS（Agent Name Service）はGoDaddyがIETFで共同開発中の標準で、公開鍵基盤（PKI）を使ったエージェントの身元と命名を扱います。GoDaddyのScott Courtney氏は「ANSが『誰であるか』を答え、DNS-AIDが『何ができ、どう繋がるか』を答える」と説明しています。両者はDNSとPKIの基盤を共有し、組み合わせて使う設計です。

他の発見方式との比較

AIエージェントの発見には、複数のアプローチが並走しています。

Microsoft Entra Agent IDはAzureエコシステム内のエンタープライズ向け管理ディレクトリです。条件付きアクセスやガバナンスに強い一方、プラットフォーム横断の中立性はDNS-AIDとは設計思想が異なります。集中型MCPレジストリは単一のカタログを提供しますが、運営者への依存が生じます。2026年5月にはAPIX（API Index for Autonomous Agent Service Discovery）など、IETFへの関連ドラフト提出も相次いでいます。

DNS-AIDが主張するのは、DNSがすでに持つ4つの性質です。地球上のあらゆるリゾルバに展開済みであること、キャッシュによる負荷分散、各ドメイン運営者が自ゾーンを管理する連合型ガバナンス、数十年の運用セキュリティの蓄積です。2026年6月1日、VerisignのエンジニアがarXivに投稿した論文も、インターネット規模のエージェント発見基盤としてDNSが適切だと独立に論じています。

Linux FoundationのJim Zemlin CEOは「安全でオープンな発見インフラがなければ、AIエージェントの接続性は資産ではなく負債になる」と述べています。各AIプラットフォームが独自レジストリを持つ構図は、モバイルのアプリストア動態を再現する恐れがあり、DNS-AIDはその前に中立な連合型標準を確立しようとしています。

参照実装と本番導入の動き

DNS-AID — AI Agent Discovery via DNS
dns-aid.org

プロジェクトはPython SDK、CLI、MCPサーバーを含む参照実装を提供しています。PyPIからpip install "dns-aid[cli,mcp]"でインストールでき、GitHub（dns-aid/dns-aid-core）でソースも公開されています。

DNSプロバイダ向けバックエンドは8種類に対応しています。Amazon Route 53、Cloudflare、Infoblox NIOS、Infoblox Universal DDI、Azure DNS、Google Cloud DNS、NS1、自己ホスト型のBIND9です。Docker ComposeでローカルBIND9を立て、本番DNSに触れずに動作確認できます。

標準公開からわずか6日後の2026年6月3日、InfobloxはInfoblox IQを発表しました。エンタープライズのネットワーク・セキュリティチーム向けのエージェント型運用レイヤーで、DNS-AID標準とMCPサーバー仕様に直接基づく最初の大規模本番システムです。

現時点の注意点

DNS-AIDはIETFドラフト段階であり、正式なRFCにはなっていません。ドラフトの有効期限は2026年11月28日です。A2AのAgent Card方式やEntra Agent IDなど、すでに本番投入されている競合アプローチも存在します。業界全体での採用が標準の成否を決める段階にあります。

とはいえ、Linux Foundationの傘下でCloudflareやISC（BIND9）といったDNSインフラの主要プレイヤーが参加し、参照実装と8つのDNSバックエンドが揃っている点は、試験導入のハードルが低いことを意味します。マルチエージェント基盤を組むチームにとって、ハードコードURLやベンダーロックインの代替として検討する価値は十分にあります。