## この記事でわかること

- 「AIエージェント版DNS」と呼ばれる標準が、なぜ同時にいくつも登場しているのか
- ANS・DNS-AID・Web Bot Auth・A2Aエージェントカードを「発見」と「本人証明」の2軸で整理
- それぞれの成熟度（本番／稼働／草案／立ち上げ意向）の違い
- 中小企業サイトが今やるべきこと／様子見でよいことの切り分け

## なぜ標準が「乱立」しているのか

AIエージェントが自律的に動き、別のエージェントやサービスとやり取りする時代に向けて、大きく2つの問いに答える標準づくりが同時多発しています。

1. **発見**：「この相手（サービス）のエージェントの入口はどこにあるか？」
2. **本人証明**：「見つけた相手は本物か？誰のものか？改ざんされていないか？」

この2つは別問題です。「見つける」仕組みと「確かめる」仕組みが、それぞれ複数の提案として立ち上がっているため、一見すると乱立して見えます。まずはこの2軸で地図を描くと、全体像がすっきりします。

![「発見」と「本人証明」の2軸で整理](/blog/ai-agent-dns-standards-map/two-axes-map.svg)

## 主要な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 とは](/blog/web-bot-auth-toha) を参照してください。

### DNS-AID（発見）

[DNS-AID（DNS for AI Discovery）](/blog/dns-aid-toha) は、DNS の SVCB レコードを使って「エージェントの入口はここにあります」を告知する提案です。中央レジストリに頼らず、各サイトが自分の DNS に入口を書いておく発想です。IETF のインターネットドラフト段階で、まだ確定した標準ではありません。

### ANS（本人証明）

[ANS（Agent Name Service）](/blog/ans-toha) は、DNS を拡張してエージェントに「検証可能な本人証明」を与える提案です。ACME でドメイン所有権を検証し、証明書と改ざん検知ログで担保します。2026 年 6 月に Linux Foundation が「立ち上げの意向」を発表したばかりで、4つの中では最も初期段階です。

## 成熟度で「今やる／様子見」を分ける

同じ「AIエージェント版DNS」でも、成熟度はまったく違います。ここを混同すると、まだ固まっていない仕様を焦って設定してしまいます。

![成熟度で「今やる／様子見」を分ける](/blog/ai-agent-dns-standards-map/maturity-signal.svg)

- **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](/blog/dnssec-basics) といった **足元のドメインの信頼が整っていること**が、どの標準に乗るにも共通の前提になります。逆に土台が崩れていれば、その上に何を載せても揺らぎます。

**まずは足元のドメインの信頼を固めることが、どの標準が主流になっても無駄にならない、一番堅実な備え**です。自社ドメインが今どの程度対応できているかは、[ドメインの AI エージェント対応チェック](/tools/agent-ready-check) で公開エンドポイントの有無を無料で確認できます。全体像は [AI エージェント対応とは](/blog/agent-readiness-toha) に整理しています。

## よくある質問

### 結局、どれから対応すればいいですか？

「自社がエージェントや 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](/blog/dnssec-basics) やメール認証など土台を固めるのが堅実。自社の対応状況は [ドメインの AI エージェント対応チェック](/tools/agent-ready-check) で確認できます
- 各標準の詳細：[ANS とは](/blog/ans-toha)／[DNS-AID とは](/blog/dns-aid-toha)／[Web Bot Auth とは](/blog/web-bot-auth-toha)