DNS-AID に対応してみた｜実装の記録と落とし穴
目次
「サイトの AI エージェント対応」を解説する記事を書くなら、まず自分のドメインで試してみる。本記事は、ドメイン番人のサイト（domain-bannin.jp）で DNS for AI Discovery（DNS-AID） に実際に対応した作業記録です。手順だけでなく、ドラフト段階の標準ならではの落とし穴も、隠さず書きます。
DNS-AID そのものの概念はDNS-AID とは？DNS で AI 入口を告知にまとめているので、本記事は「実際にやるとどうなるか」に絞ります。
この記事でわかること
- DNS-AID にリファレンス実装（
dns-aidCLI）で対応する具体手順 - Cloudflare で SVCB レコードを公開するときに起きる「想定外」
- 実装して初めて分かった 3 つの落とし穴
- 測定スコアの結果と、DNSSEC を見送った判断
なぜ対応したのか（現状の実用価値は正直ほぼゼロ）
先に正直なところを書きます。DNS-AID は IETF のインターネットドラフト段階で、確定標準ではありません。対応しているサイトもまだごくわずかで、「今すぐ集客や売上に効く」類の施策ではありません。
それでも対応した理由は 2 つです。第一に、評価項目がほぼ DNS まわりで、ドメインやメール認証を本業にする立場として相性がよいこと。第二に、解説する側が自分のドメインで実装していないのは説得力に欠けるためです。新しい仕様を早めに触っておくと、顧客に説明するときの解像度が上がります。投資としては「先行者としての知見の蓄積」が主目的、という位置づけです。
実装手順（dns-aid CLI + Cloudflare）
DNS-AID のレコードは手書きすると書式を誤りやすいため、リファレンス実装の dns-aid CLI で生成・公開しました。DNS は Cloudflare で管理しているので、CLI の Cloudflare バックエンドを使います。
大まかな流れは次のとおりです。
dns-aidCLI をインストール- Mock バックエンドでプレビューして、生成されるレコードの形を目視確認（DNS には触れない）
- Cloudflare の API トークン（DNS 編集権限・対象ゾーン限定）を用意
- 本番のバックエンドを Cloudflare にして publish
digと CLI の検証コマンドで反映を確認
公開対象は、当サイトが既に持つ MCP サーバーの情報です。/.well-known/mcp/server-card.json という入口情報を、DNS からも発見できるように告知する形になります。MCP サーバーの入口情報についてはMCP サーバーカードとはで解説しています。
実際に作られたのは、エージェントの索引（_index._agents）と、診断エージェント本体（_diagnose._mcp._agents）の SVCB / TXT レコードです。いずれも新規追加で、既存の MX・SPF・A レコードには一切触れていません。だからメール配送やサイト表示への影響はなく、不要になれば追加したレコードを消すだけで元に戻せます。低リスクな作業です。
実装で当たった 3 つの落とし穴
ここからが本題です。ドラフト段階の仕様を実装すると、ドキュメントどおりにいかない場面に必ず出会います。
落とし穴 1：CLI が起動時にエラーで落ちる
インストール直後、CLI を実行すると依存パッケージが見つからずに落ちました。配布物の依存定義に漏れがあり、追加パッケージを同じ環境に注入して解決しました。リリースされたばかりのツールにありがちな話で、エラー文をそのまま読めば原因にたどり着けます。
落とし穴 2：Cloudflare が独自パラメータを SVCB に入れてくれない
DNS-AID は SVCB レコードに、capability descriptor（エージェントの機能説明の在りか）を指す独自パラメータを載せます。ところが Cloudflare の DNS は、標準として登録済みのパラメータ（alpn や port など）しか受け付けません。
このとき CLI は賢く、独自パラメータを SVCB から外し、同じ名前の TXT レコードに退避してくれました。結果として SVCB には標準パラメータだけが残り、機能説明の在りかは TXT 側に入ります。検証ツールはこの TXT を「フォールバック」として正しく読むため、発見性そのものは保たれます。dig で SVCB を引いても独自パラメータが見えないのは正常で、その値は TXT 側にある、という挙動です。
落とし穴 3：実装どうしで「名前の付け方」が食い違う
公開後に第三者の採点ツールで測定したところ、索引（TXT）は認識されたのに、エージェント本体の SVCB が「見つからない」と判定されました。
調べると、CLI が付けたレコード名と、採点ツールが探しに行くレコード名が微妙に違っていました。片方は先頭にアンダースコアを付け、もう片方は付けない。どちらも同じドラフトを実装しているはずなのに、解釈が割れていたのです。確定していない標準では、実装ごとに細部が食い違うことがあるという、生々しい現実です。
測定結果と、DNSSEC を見送った判断
第三者ツールでの総合スコアは 71 点・最上位レベルの「Agent-Native」 でした。robots.txt、サイトマップ、Link ヘッダ、Markdown 配信、AI ボット制御、MCP サーバーカード、Agent Skills などが揃っている結果です。自社サイトの AI エージェント対応状況を点検する方法はサイトの AI 対応を確認する方法や、無料のサイトの AI エージェント対応チェックでも確認できます。
DNS-AID の項目は「索引は見つかったが、有効な SVCB 発見レコードは未検出」という途中段階の判定でした。満点に届かない要因は、前述の名前の食い違いに加えて、DNSSEC で署名されていないことです。
DNSSEC は今回あえて見送りました。DNSSEC は設定を誤ると、AI エージェント向けのレコードだけでなく、ドメイン全体の名前解決（サイトとメールの両方）が止まるおそれがある、影響範囲の大きい作業です。本業がドメインの安全である以上、ここは別の機会に、単独で慎重に進めるべきだと判断しました。低リスクな SVCB 公開と、高リスクな DNSSEC を切り分けたわけです。
まとめ
- DNS-AID はドラフト段階で、現状の実用メリットはほぼないが、先行して触る価値はある
- 公開は新規レコードの追加のみで、既存のメール・サイトには影響しない低リスク作業
- 独自パラメータの TXT 退避や、実装間の名前の食い違いなど、ドラフトならではの落とし穴がある
- DNSSEC は影響範囲が大きいため、SVCB 公開とは切り離して別途判断するのが安全
新しい標準への対応は、派手な成果よりも「自社ドメインで何が起きるかを把握しておく」ことに価値があります。まずは現状把握から、という考え方は通常のドメイン運用でも同じです。
自社ドメインの SPF・DKIM・DMARC や SSL の設定が今どうなっているかは、無料のドメイン診断でまとめて確認できます。AI エージェント対応の前に、足元のインフラを整えるところから始めてみてください。