.png)
Agent Name Serviceとは？
Agent Name Serviceは、AIエージェントに組織が管理できる名前を付け、その名前と公開鍵、機能情報を検証可能な形で結び付ける標準です。Linux Foundationは2026年11月10日、ANSをオープンなプロジェクトとして受け入れたと発表しました。公開仕様は7文書で構成され、11組織が初期参加しています。[1]
短く言えば、Webサイトにドメイン名とTLS証明書があるように、エージェントにも検証できる名前を持たせる試みです。ただしANS公式サイトは、公開中の仕様を「active development」のdraftと説明しています。完成済みの認証基盤ではなく、相互運用を始めるための標準案として見る必要があります。[2]
| 確認したいこと | ANSが扱う範囲 | 別に必要な仕組み |
|---|---|---|
| 誰がその名前を管理しているか | DNSによる名前の所有確認 | 組織内の登録・廃止手続き |
| 通信相手が同じ主体か | 証明書と公開鍵による検証 | セッション管理、秘密鍵保護 |
| どんな機能を持つか | 検証可能なメタデータ | 実行前の内容審査 |
| 何を実行してよいか | 対象外 | 認可、ポリシー、承認フロー |
| 信頼できるか | 対象外 | 評判、監査、取引履歴 |
名前を検証する仕組み
ANSの名前は、公式リポジトリの例では ans://v1.0.0.my-agent.example.com のように表します。バージョン、エージェント名、組織が管理するドメインを一つの識別子に含める設計です。検証側はDNSで公開情報をたどり、証明書が名前と公開鍵を正しく結び付けているかを確かめます。[3]
この構造の利点は、新しい中央名簿を一社が独占しなくても、既存のドメイン管理と公開鍵基盤を利用できる点にあります。企業は自社ドメインの配下でエージェント名を管理でき、相手側は別の事業者が運営するエージェントでも同じ手順で検証できます。
さらにANSは、証明書の発行記録を透明性ログで検査できる設計と、ネットワーク接続が限られる環境でも検証情報を持ち運ぶオフライン検証器を示しています。名前が衝突しないこと、証明書が不正に差し替えられていないこと、失効情報が反映されていることを、それぞれ別の層で確かめる考え方です。
2026年10月にはGoDaddy、Infoblox、Google、Cloudflareが、異なる基盤をまたぐエージェント取引のデモを公表しました。DNSと証明書を共通の基盤にできる可能性を示した例ですが、これは限定された実演です。多数の企業が日常業務で利用している実績とは区別する必要があります。[4]
認証できても、実行を許可してよいとは限らない
ANSが答えるのは「名乗っている相手と、その名前を管理する主体を検証できるか」です。「このエージェントに送金を許してよいか」「顧客データを渡してよいか」までは決めません。本人確認と権限付与を混同すると、正規のエージェントが誤った命令を実行する事故を防げません。
実装では、少なくとも次の三層に分ける必要があります。
- 識別・認証：ANSなどで名前、ドメイン、公開鍵を検証する
- 認可：操作できるAPI、金額、データ範囲、有効期限を制限する
- 監査：誰が何を依頼し、何を実行し、どの結果になったかを残す
この分離は、AIエージェントの暴走や資格情報の悪用を考えるうえでも重要です。TechCreateが扱ったAIエージェントの認証情報悪用でも、接続できることと、操作を許してよいことは別の問題でした。
研究面では、ANSを使った50エージェントの検証実験で10ミリ秒未満の処理が報告されています。[5] ただし、論文の試作環境における結果であり、世界規模の商用ネットワークや障害時の性能を保証する値ではありません。公式発表の「相互運用できる」という主張と、独立した本番実績を分けて読むべきです。
企業はどの場面で検討するべきか
ANSが特に意味を持つのは、自社の閉じたシステムを越えてエージェントを連携させる場面です。社内だけで動く一つのエージェントなら、既存のID管理やサービスアカウントで足りる場合があります。一方、取引先の調達エージェント、外部の旅行予約エージェント、複数クラウドの運用エージェントが連携すると、名前の発行主体を共通手順で確認する必要が生じます。
導入判断は、次の順序で進めると整理しやすくなります。
- 組織外のエージェントと自動通信する予定があるか
- 相手のドメインと公開鍵を検証できないことがリスクになっているか
- 名前の発行、更新、失効を担当する部署を決められるか
- 認証後の権限を最小化するポリシーがあるか
- 仕様変更に追随できる検証環境を用意できるか
現時点では、ANS自体の利用料金は示されていません。公開仕様と参照実装は利用できますが、証明書管理、DNS運用、監査、障害対応には別途コストがかかります。TechTargetも、検証可能なアイデンティティをエージェント間取引の基礎と位置付ける一方、信頼を成立させるには運用とガバナンスが必要だと報じています。[6]
まずは本番の決済や顧客データを扱わず、検証用ドメインで名前の発行、証明書の更新、失効、監査ログまでを試すのが現実的です。採用可否を決める指標は、名前が引けるかだけではありません。失効が伝わる時間、鍵のローテーションに失敗したときの停止方法、認可システムとの接続まで確認する必要があります。
まとめ
- Agent Name Serviceは、DNSと証明書を使ってAIエージェントの名前と管理主体を検証する公開仕様で、実行権限や評判は扱いません。
- 異なる企業や基盤をまたぐエージェント連携では共通の本人確認層になり得ますが、公開仕様はまだdraftで、本番規模の実績は確認途上です。
- 企業は認証、認可、監査を分け、まず検証環境で発行・更新・失効まで試してから採用を判断するべきです。
出典・参考
- Linux Foundation「Linux Foundation Welcomes Agent Name Service...」2026年11月10日（https://www.linuxfoundation.org/press/linux-foundation-welcomes-agent-name-service-to-bring-verifiable-identity-and-discovery-to-ai-agents）
- Agent Name Service 公式サイト（https://ansinfo.ai/）
- Agent Name Service GitHub repository（https://github.com/agentnameservice/ans）
- GoDaddy「GoDaddy, Infoblox, Google and Cloudflare Demonstrate Secure AI Agent Transactions Across Platforms」2026年10月（https://aboutus.godaddy.net/newsroom/news-releases/press-release-details/2026/GoDaddy-Infoblox-Google-and-Cloudflare-Demonstrate-Secure-AI-Agent-Transactions-Across-Platforms/default.aspx）
- arXiv「Agent Name Service: Verifiable Identity and Discovery for the Agentic Web」2026年（https://arxiv.org/abs/2604.26997）
- TechTarget「Why verifiable identity will anchor the agentic web」2026年11月10日（https://www.techtarget.com/news/why-verifiable-identity-will-anchor-the-agentic-web/874299/）
読者のコメント (0)
コメントを残す