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

- ANS（Agent Name Service）とは何か、なぜ「DNS の拡張」なのか
- ACME・証明書・改ざん検知ログを組み合わせた本人証明の仕組み
- 「発見」の DNS-AID と「本人証明」の ANS の違い
- まだ「立ち上げの意向」段階の提案であること、中小企業サイトでの現実的な向き合い方

## ANS（Agent Name Service）とは

**ANS（Agent Name Service）** は、AI エージェントに「検証可能な本人証明」を与えるためのオープンソースの提案です。具体的には、「そのエージェントを誰が運用しているのか」「どんな権限を持つのか」「登録や運用の履歴が改ざんされていないか」を、後から確かめられるようにすることを狙っています。

核心は、まったく新しい名前解決の仕組みを作るのではなく、**既存の DNS（ドメイン名の仕組み）を拡張して**エージェントの身元をドメインに紐づける点にあります。エージェントの名前は `ans://v1.0.0.my-agent.example.com` のように「バージョン付きの DNS 風の名前」で表され、ドメイン側は `_ans` という TXT レコードでその存在を告知します。分散アイデンティティ（DID）や法人識別子（LEI）とも連携でき、既存の組織 ID の基盤と接続できる設計です。

2026 年 6 月 23 日に **Linux Foundation** が ANS の「立ち上げの意向（intent to launch）」を発表し、GoDaddy・Cloudflare・Cisco・Salesforce・Infoblox・OWASP などが支持を表明しています。

![ANS の本人証明のしくみ（DNS＋証明書＋改ざん検知ログ）](/blog/ans-toha/trust-flow.svg)

## なぜ「本人証明」が必要なのか

これまで Web の世界では、「このドメインは本物か」を確かめる仕組みが積み重ねられてきました。通信を暗号化する SSL/TLS 証明書、なりすましメールを防ぐ SPF・DKIM・DMARC、DNS 応答の改ざんを防ぐ DNSSEC などです。

AI エージェントが自律的に動き、やがて予約や取引といった「お金や権限が絡む行動」まで担うようになると、同じ問いがエージェントにも向きます。**「このエージェントは本物か」「誰のエージェントか」「途中で乗っ取られていないか」** を確かめられないと、安心して任せられません。ANS は、この問いに DNS を土台にして答えようという提案です。

## 仕組み：DNS ＋ ACME ＋ 改ざん検知ログ

ANS の本人証明は、大きく次の 3 つの要素を組み合わせています。

1. **ドメイン所有権の検証（ACME）**：登録局（Registration Authority）が、SSL 証明書の自動発行で使われる ACME という手順でドメインの所有権を確認し、証明書を発行します。「そのドメインを本当に管理している人が登録した」ことを担保する部分です。
2. **改ざん検知ログ（透明性ログ）**：登録・更新・失効といったイベントを、後からの書き換えが検知できる「追記専用の台帳」に記録します。これは SSL 証明書の世界で使われている Certificate Transparency（証明書の透明性）と同じ考え方を、エージェントに応用したものです。
3. **オフラインで検証できるレシート**：記録には電子署名付きの「レシート」が発行され、専用の検証ツール（`ans-verify`）を使えば、中央のレジストリに接続しなくても暗号的に本物かどうかを確かめられます。

つまり ANS は「DNS の TXT レコードを 1 つ置くだけ」の仕組みではなく、**DNS と証明書と改ざん検知ログを束ねた信頼の層**だと理解すると正確です。仕組みの詳細は IETF のインターネットドラフト（`draft-narajala-ans` および `draft-narajala-courtney-ansv2`）として公開され、GoDaddy 発の参照実装（Go 言語・MIT ライセンス）も GitHub にあります。

## 「発見」の DNS-AID と「本人証明」の ANS は別の層

紛らわしいのですが、ANS は [DNS-AID（DNS for AI Discovery）](/blog/dns-aid-toha)とは**別のプロジェクト**です。両者は競合ではなく、役割が違います。

- **DNS-AID は「発見」の層**：「このドメインの AI エージェントの入口はここにあります」を DNS で告知し、エージェントが相手の入口を見つけられるようにします。
- **ANS は「本人証明」の層**：見つけた相手が「本物か」「誰のものか」「改ざんされていないか」を確かめられるようにします。

同じドメインで、DNS-AID による発見と ANS による本人証明を並行して公開できる設計になっています。「見つける」と「確かめる」は別問題、という整理です。

![「発見」と「本人証明」は別の層（DNS-AID と ANS）](/blog/ans-toha/discovery-vs-identity.svg)

## 成熟度と中小企業の向き合い方

ここで最も大切なのは、ANS が **まだ「立ち上げの意向」段階の提案**だという点です。

- 2026 年 6 月 23 日の発表は「これから立ち上げる」という意向表明で、正式なローンチや一般提供ではありません。
- 仕様は IETF の**個人提出ドラフト**として議論されている初期段階で、作業部会で採択された標準でも、RFC 番号が割り当てられた仕様でもありません。今後変わり得ます。
- 参照実装は存在するものの、名の通った本番運用の利用者はまだ表に見えていません。エージェントを大量に生み出す主要な AI の提供元が採用するかどうかが、普及の分かれ目になります。

したがって、中小企業のサイトで **今すぐ ANS 用の設定を行う必要はありません**。まずは「エージェントに本人証明を与える標準づくりが始まった」という動向を押さえておけば十分です。

そして見落とされがちですが、ANS のような新しい層は、**既存のドメインの信頼運用の"真上"に積み上がります**。SSL 証明書、SPF・DKIM・DMARC、[DNSSEC](/blog/dnssec-basics) といった土台がきちんと整っていれば、どの提案が標準になっても無駄になりません。逆に土台が崩れていると、その上に何を載せても揺らぎます。**まずは足元のドメインの信頼を固めることが、エージェント時代への一番堅実な備え**です。

自社ドメインが今どの程度「AI エージェント時代」に対応できているかは、[ドメインの AI エージェント対応チェック](/tools/agent-ready-check)で、公開エンドポイントの有無を無料で確認できます。全体像は [AI エージェント対応とは](/blog/agent-readiness-toha) で整理しています。

## よくある質問

### ANS と DNS-AID は何が違いますか？

DNS-AID は「エージェントの入口を DNS で発見できるようにする（見つける）」仕組み、ANS は「そのエージェントが本物かを検証できるようにする（確かめる）」仕組みです。別のプロジェクトで、同じドメインで併用できます。

### 今すぐ自社サイトに ANS を設定すべきですか？

いいえ。2026 年 7 月時点では「立ち上げの意向」段階で、仕様も提供時期も確定していません。実在しない手順を急いで設定するより、SSL・SPF・DKIM・DMARC・DNSSEC といった土台の信頼を整えるほうが確実で、無駄になりません。

### ANS は既存の DNS を置き換えますか？

置き換えません。ANS は新しい名前解決ネットワークを作るのではなく、既存の DNS に本人証明の層を重ねる設計です。ドメインは `_ans` の TXT レコードで告知し、検証は証明書と改ざん検知ログで行います。

### DID や LEI とはどう関係しますか？

ANS は、分散アイデンティティ（DID）や法人識別子（LEI）と連携できる設計です。「このエージェントはどの法人のものか」を、既存の組織 ID の基盤とつなげて確かめられるようにする狙いがあります。

## まとめ

- ANS（Agent Name Service）は、AI エージェントに「検証可能な本人証明」を与えるために、DNS を拡張する提案
- 仕組みは DNS ＋ ACME ＋ 改ざん検知ログの組み合わせで、単なる TXT レコード 1 つではない
- 「発見」の [DNS-AID](/blog/dns-aid-toha) とは別の「本人証明」の層で、併用できる
- まだ「立ち上げの意向」段階。中小企業は今すぐ設定する必要はなく、まず SSL・メール認証・[DNSSEC](/blog/dnssec-basics) など足元のドメイン信頼を固めるのが堅実
- 自社の対応状況は [ドメインの AI エージェント対応チェック](/tools/agent-ready-check) で確認できます