AIエージェント版DNSとは？ANS・DNS-AID・Web Bot Auth・A2Aカードを地図で整理
目次
この記事でわかること
- 「AIエージェント版DNS」と呼ばれる標準が、なぜ同時にいくつも登場しているのか
- ANS・DNS-AID・Web Bot Auth・A2Aエージェントカードを「発見」と「本人証明」の2軸で整理
- それぞれの成熟度（本番／稼働／草案／立ち上げ意向）の違い
- 中小企業サイトが今やるべきこと／様子見でよいことの切り分け
なぜ標準が「乱立」しているのか
AIエージェントが自律的に動き、別のエージェントやサービスとやり取りする時代に向けて、大きく2つの問いに答える標準づくりが同時多発しています。
- 発見：「この相手（サービス）のエージェントの入口はどこにあるか？」
- 本人証明：「見つけた相手は本物か？誰のものか？改ざんされていないか？」
この2つは別問題です。「見つける」仕組みと「確かめる」仕組みが、それぞれ複数の提案として立ち上がっているため、一見すると乱立して見えます。まずはこの2軸で地図を描くと、全体像がすっきりします。
主要な4つを地図で整理
| 標準 | 主な役割 | 成熟度 | 検証／告知の置き場所 |
|---|---|---|---|
| A2A エージェントカード | 発見＋本人証明 | 本番寄り（実運用が進む） | /.well-known に置く署名付きのカード |
| Web Bot Auth | bot の本人証明 | 稼働（土台は確立済み） | /.well-known/http-message-signatures-directory |
| DNS-AID | 発見 | 草案（IETF ドラフト） | DNS の SVCB レコード |
| ANS | 本人証明 | 立ち上げ意向（発表直後） | DNS ＋ 証明書 ＋ 改ざん検知ログ |
A2A エージェントカード（発見＋本人証明）
エージェント同士の連携で使われる「エージェントカード（Agent Card）」は、そのエージェントが何をできるか・どこに接続すればよいかを記した名刺のようなものです。カードをドメインに紐づけて署名することで、「発見」と「本人証明」の両方を兼ねられます。この方式は比較的実運用が進んでおり、4つの中では最も成熟しています。
Web Bot Auth（bot の本人証明）
Web Bot Auth は、サイトを巡回する bot が「正規の bot である」ことを電子署名で示す仕組みです。土台となる HTTP メッセージ署名の技術は標準（RFC 9421）として確立しており、Cloudflare の「Verified Bots」にも取り込まれています。サイト側は /.well-known/http-message-signatures-directory で鍵情報を公開します。詳しくは Web Bot Auth とは を参照してください。
DNS-AID（発見）
DNS-AID（DNS for AI Discovery） は、DNS の SVCB レコードを使って「エージェントの入口はここにあります」を告知する提案です。中央レジストリに頼らず、各サイトが自分の DNS に入口を書いておく発想です。IETF のインターネットドラフト段階で、まだ確定した標準ではありません。
ANS（本人証明）
ANS（Agent Name Service） は、DNS を拡張してエージェントに「検証可能な本人証明」を与える提案です。ACME でドメイン所有権を検証し、証明書と改ざん検知ログで担保します。2026 年 6 月に Linux Foundation が「立ち上げの意向」を発表したばかりで、4つの中では最も初期段階です。
成熟度で「今やる／様子見」を分ける
同じ「AIエージェント版DNS」でも、成熟度はまったく違います。ここを混同すると、まだ固まっていない仕様を焦って設定してしまいます。
- A2A カード（本番寄り）／Web Bot Auth（稼働）：自社が エージェントや bot を公開する側 なら、検討する価値があります。逆に公開する予定がないサイトは、まだ急ぐ必要はありません。
- DNS-AID（草案）／ANS（立ち上げ意向）：仕様が変わり得る段階です。今すぐ設定するより、動向を押さえておくのが現実的です。
判断の軸はシンプルです。「自社がエージェントを公開する側かどうか」 と 「その標準が本番で使える成熟度か」 の2つで、今やるか様子見かが決まります。
すべてに共通する土台＝ドメインの信頼
ここで見落とされがちな、しかし最も大切な点があります。上記の4つはいずれも 「ドメインを起点」 にしており、既存のドメインの信頼運用の"真上"に積み上がります。
- Web Bot Auth も A2A カードも、鍵やカードを 自社ドメインの
/.well-knownや DNS に置きます。 - DNS-AID も ANS も、告知や検証の起点は DNS とドメインの正当性 です。
つまり、SSL 証明書・SPF・DKIM・DMARC・DNSSEC といった 足元のドメインの信頼が整っていることが、どの標準に乗るにも共通の前提になります。逆に土台が崩れていれば、その上に何を載せても揺らぎます。
まずは足元のドメインの信頼を固めることが、どの標準が主流になっても無駄にならない、一番堅実な備えです。自社ドメインが今どの程度対応できているかは、ドメインの AI エージェント対応チェック で公開エンドポイントの有無を無料で確認できます。全体像は AI エージェント対応とは に整理しています。
よくある質問
結局、どれから対応すればいいですか？
「自社がエージェントや bot を公開する側か」で変わります。公開する側なら、成熟している A2A カードや Web Bot Auth から。公開しないサイトは、まず SSL・メール認証・DNSSEC といった土台を固め、DNS-AID や ANS は動向把握で十分です。
これらは互いに競合しますか？
多くは競合ではなく役割分担です。DNS-AID は「発見」、ANS は「本人証明」と層が違い、同じドメインで併用できます。A2A カードのように両方を兼ねる方式もあります。
中小企業のサイトも今すぐ何か設定すべきですか？
いいえ。エージェントを公開しないサイトは急ぐ必要はありません。まずは既存のドメイン信頼（SSL・SPF・DKIM・DMARC・DNSSEC）を整えるのが確実で、どの標準が主流になっても無駄になりません。
まとめ
- AIエージェント向けの標準は「発見」と「本人証明」の2軸で整理すると分かりやすい
- 成熟度は A2A カード（本番寄り）＞ Web Bot Auth（稼働）＞ DNS-AID（草案）＞ ANS（立ち上げ意向）の順
- どれも「ドメイン起点」で、足元のドメイン信頼の上に積み上がる
- 中小サイトはまず DNSSEC やメール認証など土台を固めるのが堅実。自社の対応状況は ドメインの AI エージェント対応チェック で確認できます
- 各標準の詳細：ANS とは／DNS-AID とは／Web Bot Auth とは