【2026年版】”AIエージェントの本人確認”実装ガイド——Web Bot Auth（RFC 9421 HTTPメッセージ署名）でサイト・API・MCPに来る自律エージェントが”正規か偽装か”を暗号的に検証する｜なりすましボット遮断・署名付きエージェント許可リスト・エージェント別レート制御による多層防御

はじめに——守る対象が「自社が使うエージェント」から「自社に来るエージェント」へ
なぜ今か——User-Agent偽装・IP許可リストの限界が露呈した
前提——Web Bot Authの仕組み（RFC 9421 HTTPメッセージ署名）
第1の防御層：署名検証——入口で「正規か偽装か」を暗号的に判定する
1. 検証で確定できること・できないこと
2. 3分類と段階的レスポンス
第2の防御層：署名付きエージェント許可リスト——「正体」に「権限」を紐づける
1. ドメイン単位・用途タグ単位で許可を設計する
2. 「既定拒否」ではなく「既定は従来扱い」から
第3の防御層：エージェント別レート制御——「誰が」に応じて速度を変える
1. 署名者ごとの「予算」を持つ
サイト・API・MCP——適用面ごとの勘所
標準・エコシステムの位置づけ——なぜ「様子見」ではなく「今」なのか
導入ステップ——最小構成から始める
多層防御チェックリスト
よくある質問（Q&A）
まとめ——「名乗り」を信じる時代から「署名」を検証する時代へ
参考リンク

はじめに——守る対象が「自社が使うエージェント」から「自社に来るエージェント」へ

これまでのAIセキュリティ記事では、ツールポイズニング、Confused Deputy、モデル抽出・蒸留窃取といった「自社が使うエージェントやモデルをどう守るか」を中心に扱ってきました。しかし2026年、その裏返しの問題が急速に現実味を帯びています。それは、外から自社のサイト・API・MCPサーバーに来る自律エージェントが、正規なのか偽装なのかを入口でどう見分けるかという問題です。

直前のエージェンティック・コマース対応ガイドでは、AIが「比較」だけでなく「決済まで」完了させる時代に、自社の商品・在庫・決済をどう機械可読にしてエージェントを迎え入れるかを扱いました。本記事はその防御面の対です。エージェントを迎え入れるということは、これまで人間かボットかを見分けていた入口に、「正規のエージェント」と「それを騙る偽装ボット」が同居することを意味します。決済まで任せる相手を、どうやって暗号的に本人確認するのか——ここを設計しないまま門戸を開くのは、鍵をかけずに店を開けるのと同じです。

筆者はネットワークのTAC（テクニカルアシスタンスセンター）とアドバンスドサービスで、長年トラフィックの真贋判定と異常検知に携わってきました。本記事の核心は、その発想が「送信元をどう信頼するか」という認証設計にそのまま接続するという点にあります。IPアドレスの許可リストやUser-Agent文字列——長らくボットの識別に使われてきたこれらの手段が、なぜ2026年に限界を迎えたのか。そして、その代わりに標準化されつつあるWeb Bot Auth（RFC 9421 HTTPメッセージ署名）による暗号的な本人確認を、実装の視点で整理します。

想定読者は、AIエージェント経由のアクセスを受け入れ始めたSaaS事業者・ECサイト運営者、APIやMCPサーバーを外部提供する企業、そしてボット対策とアクセス制御を預かる情シス・CISOの方々です。

なぜ今か——User-Agent偽装・IP許可リストの限界が露呈した

「正規のボットだけ通す」という運用自体は新しくありません。GooglebotやBingbotを通し、それ以外の自動アクセスを絞る——多くのサイトが以前からやってきたことです。問題は、その見分け方が2026年の現実に耐えられなくなったことです。

User-Agent文字列は「自己申告」にすぎない

User-Agentヘッダは、リクエストを送る側が自由に書ける文字列です。「私はGooglebotです」「私はChatGPTのエージェントです」と名乗ること自体には、何の証明もありません。悪意ある側が正規エージェントのUser-Agentをそのままコピーすれば、文字列だけでは本物と偽物が完全に一致します。名乗りを信じる認証は、なりすましの前で無力です。

IP許可リストは運用が破綻しつつある

「正規ボットのIPレンジを許可リストに登録する」方式は、長らく次善の策でした。しかし自律エージェントの時代に入り、この前提が崩れています。エージェントはクラウド上の可変IP、住宅用プロキシ、ユーザー端末などあらゆる場所から発信されます。事業者ごとにIPレンジを追い続け、変更のたびに許可リストを更新する運用は、対象が数十社に増えた時点で現実的に破綻します。IPは「どこから来たか」を示すだけで、「誰が送ったか」を証明しません。

だから「送信元の自己申告」から「暗号的な証明」へ

ここで登場したのがWeb Bot Authです。発想は明快で、ネットワークの世界がとうに通った道でもあります。「名乗り（User-Agent）」でも「経路（IP）」でもなく、公開鍵暗号による署名で送信元を証明する。TLSサーバー証明書がサイトの正体を証明するのと同じ論理を、リクエストを送るエージェントの側に適用したものだと考えると分かりやすいはずです。

Web Bot Authは、Cloudflareが主導し、Amazon・Akamai・OpenAI・Googleらが参画して、2026年にIETFで正式なワーキンググループ（webbotauth）が発足した標準化の動きです。アーキテクチャ仕様（draft-meunier-web-bot-auth-architecture）はCloudflareのThibault MeunierとGoogleのSandor Majorが起草し、2026年3月時点で版を重ねています。AWS WAF・Vercel・Shopify・Akamaiが対応を実装し、CloudflareはVerified Bots Program（正規ボット認定）にメッセージ署名を取り込みました。さらに、後述するVisa・Mastercard・American Expressのエージェント決済の本人確認基盤にも採用されつつあります。「署名付きエージェントだけ通す」が、新しい標準になろうとしています。

前提——Web Bot Authの仕組み（RFC 9421 HTTPメッセージ署名）

Web Bot Authは、まったく新しい暗号技術を発明したわけではありません。既存の標準であるRFC 9421「HTTP Message Signatures」を、ボット・エージェントの本人確認という用途に当てはめたものです。仕組みを分解すると、登場人物は「署名する側（エージェント）」「鍵を公開する場所（ディレクトリ）」「検証する側（サイト・API・MCP）」の3つです。

1. エージェントは「鍵ペア」を持つ

エージェントの提供者（OpenAIやAmazonなど）は、自社ボット用にEd25519の署名鍵ペアを生成します。秘密鍵はエージェント側が厳重に保持し、公開鍵は誰でも取得できる場所に公開します。秘密鍵で署名し、公開鍵で検証する——公開鍵暗号の基本形です。

2. 公開鍵は「.well-known ディレクトリ」で公開する

公開鍵は、署名者のドメイン配下の決まった場所——/.well-known/http-message-signatures-directory——にJWKS（JSON Web Key Set）形式で公開します。検証する側は、リクエストが名乗るドメインのこのURLを見に行けば、正しい公開鍵を取得できます。TLS証明書における認証局の役割を、公開された鍵ディレクトリが担うイメージです。

3. リクエストごとに3つのヘッダで署名を運ぶ

エージェントがHTTPリクエストを送るとき、秘密鍵でヘッダ群に署名し、次の3要素を付与します。ここが検証の核心です。

ヘッダ	役割
`Signature-Agent`	署名者の公開鍵が公開されているドメインを示す（例：`https://example-agent.com`）。検証側はここを起点に鍵を取得する。
`Signature-Input`	署名の有効期間（開始・失効）、鍵ID（JWKのサムプリント）、用途を示すタグなど、署名の対象と条件を記述する。
`Signature`	実際のEd25519暗号署名そのもの。上記の内容を秘密鍵で署名した値。

検証側は、Signature-Agentが示すドメインから公開鍵を取得し、Signatureを検証します。署名が正しければ、そのリクエストは「その秘密鍵を持つ主体が、たった今、この内容で送った」ことが暗号的に確定します。User-Agentのような自己申告と違い、偽装は秘密鍵を盗まない限り不可能です。しかも有効期間が短く区切られているため、署名を1つ盗んで使い回す「リプレイ攻撃」も成立しにくくなっています。

第1の防御層：署名検証——入口で「正規か偽装か」を暗号的に判定する

多層防御の一段目は、リクエストが入ってきた瞬間に署名を検証し、正規エージェント・偽装ボット・署名なしトラフィックの3つに仕分けることです。ここがWeb Bot Authの中核であり、User-Agent／IP時代には得られなかった確実性が手に入ります。

検証で確定できること・できないこと

署名検証が確定するのは「誰が送ったか（署名者の正体）」と「途中で改ざんされていないか」です。逆に、署名は「その送信元が善良か」までは保証しません。正規に署名されたエージェントであっても、過剰なクロールや目的外利用をする可能性は残ります。だからこそ署名検証は「本人確認」であって「振る舞いの許可」ではないと位置づけ、後述の許可リストとレート制御を重ねる必要があります。

3分類と段階的レスポンス

ネットワークのアクセス制御と同じく、いきなり全遮断ではなく段階的に扱うのが実務の鉄則です。

分類	状態	推奨レスポンス
署名あり・検証成功	正体が暗号的に確定した正規エージェント	許可リストに照合のうえ通す。エージェント別のレート枠を適用。
署名あり・検証失敗	署名不正・鍵不一致・有効期限切れ・改ざんの疑い	ブロックまたはチャレンジ。監査ログに保全し、偽装試行として記録。
署名なし	従来型ボット・人間・未対応エージェント	既存のボット対策（WAF・レート制限・チャレンジ）で従来通り扱う。

重要なのは、署名なしトラフィックを一律に排除しないことです。Web Bot Authはまだ普及途上であり、正規の人間ユーザーも署名を持ちません。移行期は「署名があれば確実に信頼できる」というホワイトリスト的な使い方から始め、署名なしは従来の防御で扱う——この二段構えが現実的です。

第2の防御層：署名付きエージェント許可リスト——「正体」に「権限」を紐づける

署名検証で正体が確定したら、次は「その正体に何を許すか」を決めます。ここがIP許可リストとの決定的な違いです。IPは変わり続けますが、署名者のドメインと鍵はエージェント提供者の恒久的なアイデンティティなので、許可リストが安定します。

ドメイン単位・用途タグ単位で許可を設計する

許可リストは、単に「通す／通さない」の二値ではなく、署名者ドメインごとに用途と範囲を割り当てる形にします。Signature-Inputの用途タグを使えば、「検索インデックス用のクロール」と「ユーザー代理の購入エージェント」を区別して権限を変えることも可能です。

設計軸	従来（IP許可リスト）	Web Bot Auth（署名付き許可リスト）
識別の単位	IPアドレス／レンジ	署名者ドメイン＋鍵ID
安定性	頻繁に変わり追従が困難	提供者の恒久ID。変更は鍵ローテーション時のみ
なりすまし耐性	IP偽装・プロキシで回避可能	秘密鍵がなければ不可能
粒度	送信元アドレスのみ	用途タグ・エージェント種別まで区別可能
失効	レンジ単位で粗い	ディレクトリの鍵更新で即時反映

「既定拒否」ではなく「既定は従来扱い」から

許可リスト運用の落とし穴は、真面目にやるほど正規のトラフィックまで締め出すことです。移行期の推奨は、「許可リストにある署名者＝優遇（高レート・認証済み扱い）」「それ以外＝従来のボット対策で判定」という設計です。信頼を段階的に積み上げ、対応エージェントが増えるにつれて許可リストの比重を上げていきます。

第3の防御層：エージェント別レート制御——「誰が」に応じて速度を変える

署名によって「誰が」が確定すると、レート制限の設計思想そのものが変わります。従来のレート制限はIPやセッション単位で、分散されると容易に回避されました。しかし署名付きなら、複数IP・複数リージョンから来ても同一署名者として名寄せでき、エージェント単位で公平な速度枠を割り当てられます。

署名者ごとの「予算」を持つ

正体が確定するからこそ、エージェントごとに異なる方針を適用できます。信頼度の高い提携済みエージェントには広い枠を、素性は確かだが未提携のエージェントには保守的な枠を、といった差別化されたレート・ポリシーです。分散による回避が効かないため、上限が実効的に機能します。

署名者の区分	レート方針	目的
提携済み・検証成功	広い枠。バースト許容。	正規の業務エージェントを妨げない
未提携・検証成功	保守的な枠。累積量を監視。	正体は確かだが乱用を抑止
検証失敗・署名なし	厳格な枠＋チャレンジ	偽装・従来型ボットのコストを上げる

ネットワークでいうQoS（トラフィックの優先制御）に近い発想です。帯域を「誰のトラフィックか」で重み付けするのと同じく、リクエスト速度を「どの署名者か」で重み付けします。正体が分かって初めて、公平な配分が設計できます。

サイト・API・MCP——適用面ごとの勘所

Web Bot Authの適用先は、Webサイトのクロール制御だけではありません。エージェントがアクセスするあらゆる入口が対象です。

Webサイト： クローラーやユーザー代理エージェントの真贋判定。「正規のAI検索クローラーには読ませ、偽装クローラーは弾く」を暗号的に実現。従来のrobots.txtやUser-Agent判定を、署名検証で裏打ちする。
API： エージェント経由のAPI呼び出しに署名を要求すれば、APIキーの漏洩・共有だけに依存しない多要素的な送信元確認になる。キー＋署名で「正しいキーを、正規のエージェントが使っている」まで確認できる。
MCPサーバー： 外部のAIエージェントが自社のMCPサーバーに接続してツールを呼ぶとき、接続元エージェントの正体を署名で確認する。MCPは強力な操作をエージェントに委ねるため、接続元の本人確認は特に重要。ツールポイズニングなどMCP内部の脅威対策とあわせ、入口での送信元検証を一段目に置く。

いずれの面でも、Web Bot Authは認可（何を許すか）そのものではなく、認可の前提となる認証（誰か）を提供します。既存のAPIキー・OAuth・アクセス制御を置き換えるのではなく、その手前に「送信元の暗号的な本人確認」を一枚足すものだと理解すると、既存設計への組み込み方が見えてきます。

標準・エコシステムの位置づけ——なぜ「様子見」ではなく「今」なのか

新しい標準に投資すべきかは、それがどれだけ本気で普及に向かっているかで決まります。Web Bot Authは、2026年時点で「一社の実験」の段階をすでに越えています。

IETFでの標準化： 2026年にワーキンググループ（webbotauth）が正式発足。土台のRFC 9421はすでに標準化済みで、その上に用途特化の仕様を積む構図。特定ベンダー独自仕様ではなく、オープンな標準として進んでいる。
プラットフォームの実装： Cloudflareがエッジで検証を提供し、Verified Bots Program（正規ボット認定）にメッセージ署名を統合。AWS WAF・Vercel・Shopify・Akamaiが対応。主要なCDN・WAF・ホスティング層に検証機能が下りてきている。
決済ネットワークの採用： Cloudflareは2025年10月、Visa・Mastercard・American Expressとエージェント決済のセキュア化で提携。VisaはWeb Bot AuthをTrusted Agent Protocol（TAP）としてVisa Intelligent Commerceに、MastercardはMastercard Agent Payに統合する方向。エージェントが「決済まで」行う世界の本人確認基盤として据えられつつある。

つまりWeb Bot Authは、クロール制御という狭い話にとどまらず、エージェンティック・コマース全体の信頼の土台になろうとしています。決済まで任せる相手を暗号的に確認する仕組みが標準化されるなら、その入口を持つ事業者は遅かれ早かれ対応を迫られます。「様子見」のコストは、対応エージェントの流入が増えるほど上がっていきます。

導入ステップ——最小構成から始める

いきなり全面適用する必要はありません。リスクの低いところから段階的に導入するのが定石です。

観測から始める： まず署名付きリクエストがどれだけ来ているかを計測する。Cloudflare等の検証機能を「ログのみ」モードで有効化し、正規エージェントの流入実態を把握する。
ホワイトリスト優遇： 検証成功した既知の署名者を優遇扱い（高レート・チャレンジ免除）にする。この段階では署名なしトラフィックの扱いは変えず、正規エージェントの体験だけを良くする。
用途別ポリシー： 署名者ドメイン・用途タグごとに許可範囲とレート枠を設計。MCPやAPIなど機微な面から署名要求を段階的に厳格化する。
失効・鍵ローテーション対応： 公開鍵ディレクトリの定期取得・キャッシュ・失効反映を運用に組み込む。鍵更新時に検証が壊れないよう、キャッシュTTLと再取得を設計する。
監査との接続： 検証成功・失敗・偽装試行を改ざん不能なログに残し、既存のSOC／インシデント対応につなぐ。

多層防御チェックリスト

層	対策	主に効く脅威
入口	RFC 9421署名の検証（正規／偽装／署名なしの3分類）	User-Agent偽装・なりすましボット
入口	署名者ドメイン＋鍵IDによる許可リスト	不正エージェントの権限取得
入口	公開鍵ディレクトリの取得・キャッシュ・失効反映	失効鍵の悪用・鍵ローテーション時の事故
速度	署名者単位のレート制御（分散を名寄せ）	分散による回避・過剰クロール
適用面	サイト・API・MCPそれぞれで送信元検証を前段配置	APIキー流用・MCP接続元のなりすまし
移行	署名なしは従来のボット対策で扱う二段構え	誤遮断（正規の人間・未対応エージェント）
運用	検証結果・偽装試行を改ざん不能ログに保全	事後の立証・監査対応

よくある質問（Q&A）

Q1. User-Agentのフィルタリングを続けていれば十分ではないですか？

不十分です。User-Agentは送信側が自由に書ける自己申告の文字列で、正規エージェントの名乗りをコピーすれば本物と区別がつきません。Web Bot Authは公開鍵署名で送信元を暗号的に証明するため、秘密鍵を盗まない限りなりすましは不可能です。「名乗り」を「証明」に置き換えるのが本質です。

Q2. IP許可リストはもう使えないのですか？

補助的には残りますが、主役ではなくなります。自律エージェントは可変IP・プロキシ・ユーザー端末など多様な場所から発信するため、事業者ごとにIPレンジを追う運用は破綻しがちです。署名者ドメインと鍵という恒久的なアイデンティティで識別するほうが安定し、なりすまし耐性も高くなります。

Q3. 署名がないトラフィックは全部ブロックすべきですか？

いいえ。Web Bot Authは普及途上で、正規の人間ユーザーも署名を持ちません。移行期は「署名があれば確実に信頼する」というホワイトリスト的な使い方から始め、署名なしは従来のボット対策（WAF・レート制限・チャレンジ）で扱う二段構えが現実的です。一律ブロックは誤遮断を招きます。

Q4. 署名を検証すれば、そのエージェントは安全だと言えますか？

言えません。署名が保証するのは「誰が送ったか」と「改ざんの有無」であって、「その送信元が善良か」ではありません。正規に署名されたエージェントでも過剰なクロールや目的外利用はあり得ます。だから署名検証（本人確認）に、許可リスト（権限）とレート制御（速度）を重ねる多層防御が必要です。

Q5. 自社はエージェントを受ける側ですが、何から手をつけるべきですか？

まず「観測」からです。CloudflareなどのWAF／CDN層で署名検証をログのみモードで有効化し、署名付きエージェントの流入実態を把握します。次に検証成功した既知署名者を優遇扱いにし、MCPやAPIなど機微な面から段階的に署名要求を厳格化します。いきなり全面遮断に踏み込まず、優遇から始めるのが安全です。

まとめ——「名乗り」を信じる時代から「署名」を検証する時代へ

AIエージェントが自社のサイト・API・MCPに来て、比較し、操作し、やがて決済まで行う——2026年、その入口には「正規のエージェント」と「それを騙る偽装ボット」が同居します。要点は3つです。

1. 自己申告は証明ではない。 User-Agentは書き換え自由、IPは経路を示すだけ。なりすましの前でどちらも無力です。必要なのは、公開鍵署名（RFC 9421）による送信元の暗号的な本人確認です。

2. 「本人確認」に「権限」と「速度」を重ねる。 署名検証で正体を確定し（第1層）、署名者ドメイン単位の許可リストで権限を与え（第2層）、署名者単位のレート制御で速度を配分する（第3層）。正体が分かって初めて、公平で実効的な制御が設計できます。

3. 「様子見」のコストは上がり続ける。 IETFでの標準化、主要WAF／CDNの実装、そしてVisa・Mastercardら決済網の採用——Web Bot Authはエージェンティック・コマースの信頼基盤になりつつあります。エージェントを迎え入れる入口を持つなら、対応は早いほど有利です。

「エージェントを迎え入れる」ことと「エージェントを見分ける」ことは、表裏一体です。門戸を開く前に、来る相手を暗号的に本人確認する——これが、エージェント時代の入口を守るための基本姿勢です。

参考リンク

免責事項： 本記事は2026年7月時点の公開情報および標準ドラフトに基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。Web Bot AuthおよびRFC 9421関連の仕様は策定・更新の途上にあり、実装状況や各社の対応は変化します。実際の導入は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家にご相談のうえ、最新情報は各公式ソースでご確認ください。