Cloudflare Web Bot Auth — AIエージェント認証の新標準

Cloudflare Web Bot Authが解決する「ボット認証」の構造的課題

Cloudflare CEOのMatthew Prince氏は2026年3月、ボットトラフィックが2027年までに人間のトラフィックを超えると予測しました。すでにCloudflareのネットワーク上では、AIボットからのリクエストが週100億件を超えています。

この膨大なトラフィックの中に、正規のショッピングエージェント、悪意あるスクレイパー、そしてAIモデルの訓練用クローラーが混在しています。問題は、従来のWeb標準ではこれらを区別する手段がほとんどないことです。

robots.txtは1994年に生まれた「お願い」の仕組みに過ぎません。Duke大学の2025年の調査では、AI関連クローラーの中にrobots.txtファイル自体を取得しないものが複数カテゴリ存在することが判明しています。さらに2026年、OpenAIはChatGPT-Userクローラーがrobots.txtに従うという記述を削除しました。ユーザー主導のアクション、つまりAIエージェントが人間の指示で行動する場合は、robots.txtの制約を受けないという立場です。

この変化が意味するのは明確です。「自己申告に基づく信頼」はもう機能しません。エージェンティックコマースが拡大する中で、サイトにアクセスしてきたボットが「誰なのか」を暗号学的に検証する仕組みが不可欠になっています。2025年5月にCloudflareが提案したWeb Bot Authは、この構造的な問題に正面から取り組むプロトコルです。

robots.txtの時代が終わる理由

なぜrobots.txtでは不十分なのか。3つの構造的な限界があります。

第一に、強制力の不在です。robots.txtはあくまで「お願い」であり、技術的にアクセスを阻止する仕組みではありません。善意のクローラーは従いますが、悪意あるボットは無視します。そしてAIエージェントの文脈では、「善意」と「悪意」の境界線自体が曖昧になっています。

第二に、識別の粗さです。robots.txtが識別できるのはUser-Agent文字列だけであり、これは容易に偽装できます。「Googlebot」を名乗るリクエストが本当にGoogleからのものかどうかを、robots.txtの仕組みだけでは判断できません。

第三に、権限の表現力不足です。robots.txtは「許可か拒否か」の二択しか表現できません。しかしエージェンティックコマースのセキュリティを考えるとき、求められるのはより精密な制御です。「閲覧は許可するが購入行為は認証済みエージェントのみ」といった段階的な権限設定が必要になります。

IPアドレスによる検証も代替手段としては限界があります。クラウド環境やブラウザ代行サービスではIPが頻繁に変動し、リストの維持管理が現実的ではなくなっています。Cloudflareが「IPを忘れよう」と呼びかけたのは、この背景からです。

Web Bot Authの技術アーキテクチャ

Web Bot Authは、既に標準化されたRFC 9421（HTTP Message Signatures）の上に構築されています。エージェントがHTTPリクエストに暗号署名を付与し、Webサイト側がその署名を公開鍵で検証する。この単純な仕組みが、ボット認証の根本的な転換を可能にしています。

具体的な動作を見てみます。AIエージェントがWebサイトにリクエストを送る際、HTTPヘッダに3つの要素を追加します。Signature-Agentヘッダは、エージェントの公開鍵が公開されているドメイン（例：operator.openai.com）を指します。Signature-Inputヘッダには、署名の有効期間、鍵のID（JSON Web Key Thumbprint）、署名の目的を示すタグが含まれます。そしてSignatureヘッダに、Ed25519アルゴリズムによる暗号署名そのものが格納されます。

Signature-Agent: operator.openai.com
Signature-Input: sig=("@authority" "signature-agent");created=1700000000;expires=1700011111;keyid="ba3e64==";tag="web-bot-auth"
Signature: sig=abc==

Webサイト側の検証は3ステップです。まずSignature-Agentヘッダのドメインにある/.well-known/http-message-signatures-directoryから公開鍵を取得します。次にその公開鍵で署名を検証し、最後にタイムスタンプの有効期限を確認します。署名はリクエスト先のドメイン（@authority）に紐づいているため、別のサイトへの転用はできません。

この設計の巧みさは、既存のHTTPインフラの上で動作する点にあります。新たなプロトコルスタックやTLS拡張を必要とせず、Webサーバーにミドルウェアを追加するだけで実装可能です。Cloudflareの技術ブログでは、TypeScript、Go（Caddyプラグイン）、npmパッケージによる実装例が公開されています。

公開鍵ディレクトリとレジストリ

2026年2月、CloudflareはAmazon Bedrock AgentCoreとの協業で、オープンなレジストリフォーマットを発表しました。これはエージェントの公開鍵の「発見」を標準化する仕組みです。

レジストリはシンプルなテキストファイルで、各エージェントの鍵ディレクトリのURLを列挙します。Webサイト運営者はこのレジストリをGitHubやCloudflare R2上でホストし、IPブロックリストやrobots.txtと同様に管理できます。レジストリの各エントリはSignature Agent Cardと呼ばれるJSON形式のメタデータで、エージェント名、運営者情報、期待されるリクエストレート、暗号鍵などを含みます。

この分散型の鍵発見メカニズムにより、中央集権的な認証局なしにエージェントの身元を検証できる構造が実現しています。

IETFでの標準化 ── Web Bot Auth Working Group

Web Bot Authは単なるCloudflareの独自提案にとどまりません。IETF（Internet Engineering Task Force）にWebBotAuth Working Groupが正式に設立され、インターネット標準としての策定が進んでいます。

共同議長はDavid SchinaziとRifaat Shekh-Yusef。IETF 123で開催されたBoF（Birds of a Feather）セッションを経てワーキンググループが認可されました。標準化のスコープは、検索エンジンのクローラー、Webアーカイバー、リンクチェッカーなどの従来型ボットから、AI訓練用クローラー、そしてユーザーの代理でコンテンツを取得・操作するAIエージェントまで幅広くカバーしています。

マイルストーンは2つ設定されています。2026年4月までに認証技術とボット情報伝達メカニズムの標準トラック仕様をIESG（Internet Engineering Steering Group）に提出。2026年8月までに鍵管理やデプロイメントに関するBCP（Best Current Practice）文書を提出。標準化が順調に進めば、2027年にはRFC化される可能性があります。

注目すべきは、このワーキンググループが「ボットのレピュテーション追跡」や「エンドユーザー認証」を明示的にスコープ外としている点です。Web Bot Authは「このリクエストは誰が送ったのか」を検証することに特化しており、そのエージェントが「信頼できるか」の判断は別のレイヤー、たとえばKYA（Know Your Agent）フレームワークに委ねる設計思想です。

エージェンティックコマースへの応用 ── Visa TAP・Mastercard Agent Pay

Web Bot Authの最も具体的な応用が、エージェンティックコマースの認証基盤です。2025年10月、CloudflareはVisa・Mastercard・American Expressとの協業を発表し、Web Bot Authを決済ネットワークのエージェント認証に統合する取り組みを開始しました。

Visa TAP（Trusted Agent Protocol）は、Web Bot Authの署名メカニズムを拡張し、ショッピングエージェント向けの認証レイヤーを追加しています。具体的には、Signature-Inputヘッダのtagフィールドに2種類の値を導入しました。agent-browser-authはエージェントが商品を閲覧していることを示し、agent-payer-authは決済を実行しようとしていることを示します。加えて、リプレイ攻撃を防ぐnonceフィールドが署名に含まれます。

Cloudflare側の検証プロセスは7段階です。署名ヘッダの存在確認、公開鍵ディレクトリからの鍵取得、タイムスタンプの有効性検証、nonceの一意性チェック、タグ種別の確認、Ed25519暗号署名の検証、そしてエージェントの登録ステータスの確認。この一連の検証をCloudflareのエッジで自動的に実行することで、加盟店側のインフラ変更は最小限に抑えられます。

Mastercardも同様のアプローチを採用しています。Mastercard Agent PayはWeb Bot Authを組み込み、エージェンティックトークンによってAIエージェントと個別ユーザーを紐づける仕組みを構築しました。Visaが「身元証明」を、MastercardのVerifiable Intentが「意思証明」を担い、その両方の土台としてWeb Bot Authの暗号署名が機能するという構造です。

では、加盟店にとって何が変わるのか。従来は「全ボットをブロックするか、全て通すか」の二択でした。Web Bot Authとこれらの決済プロトコルの統合により、「Visaが承認したショッピングエージェントは通すが、未認証のスクレイパーはブロックする」という精密な制御が可能になります。Cloudflareは今後、Visa・Mastercardのプロトコル対応をAgent SDKに統合し、マネージドルールセットとして提供する計画を示しています。

Webプラットフォームへの普及

Web Bot Authの影響力を測るうえで重要なのは、Cloudflare以外のプラットフォームへの浸透速度です。

AWS WAFは2025年11月にWeb Bot Auth対応を発表しました。Bot Controlルールにおいて、署名が検証されたリクエストにはweb_bot_auth:verifiedラベルが自動付与され、検証失敗にはweb_bot_auth:invalid、鍵期限切れにはweb_bot_auth:expiredのラベルが付きます。Amazon Bedrock AgentCoreのブラウザサービスもWeb Bot Authに対応し、AIエージェントがCAPTCHAに遭遇する頻度を削減する取り組みを進めています。

エージェント開発者側の動きも加速しています。OpenAIはOperatorの全リクエストにHTTP Message Signaturesを付与し始めました。公開鍵はoperator.openai.comの/.well-known/http-message-signatures-directoryに公開されています。Cloudflareの署名済みエージェントプログラムには、ChatGPTエージェント、Block社のGoose、Browserbase、Anchor Browserが初期メンバーとして参加しています。

この広がりが示すのは、Web Bot Authが特定のベンダーロックインではなく、インターネット全体のインフラストラクチャになりつつあるという事実です。

robots.txtからWeb Bot Authへの移行パス

従来の仕組みとWeb Bot Authは、どのような関係にあるのか。

重要なのは、Web Bot Authがrobots.txtを「置き換える」のではなく、「補完する」位置づけにあることです。robots.txtはクロールの頻度やアクセス範囲を宣言する「ポリシー」レイヤーとして引き続き機能します。Web Bot Authはその上に「認証」レイヤーを追加し、ポリシーに従うべきエージェントが本当にそのエージェントであるかを暗号的に検証します。

Cloudflareはさらに、コンテンツの利用条件を表現するContent Signalsという仕組みも提案しています。HTTPレスポンスにContent-Signal: ai-train=yes, search=yes, ai-input=yesのようなヘッダを付与し、パブリッシャーがAI訓練・検索インデックス・エージェント利用への許諾を明示するものです。Markdown for Agentsと組み合わせることで、AIエージェントが効率よく構造化データを取得しながら、パブリッシャーの意思も尊重する枠組みが形成されつつあります。

つまり、Cloudflareが描くWebの新秩序は3層構造です。Content Signalsがコンテンツの利用ルールを定義し、robots.txtがアクセスポリシーを宣言し、Web Bot Authがアクセス主体の身元を検証する。この3層が連動することで、エージェンティックコマースの信頼レイヤーが形成されていきます。

EC事業者への影響

EC事業者にとって、Web Bot Authへの対応は2つのルートがあります。

第一に、プラットフォーム経由の自動対応です。Cloudflare、AWS、Vercel、Shopifyをすでに利用している場合、プラットフォーム側のアップデートでWeb Bot Authの検証機能が順次提供されます。Cloudflareのユーザーであれば、Bot ManagementやAI Audit機能の一環として、署名済みエージェントの識別とトラフィック制御がダッシュボードから操作可能になります。

第二に、決済プロバイダー経由の間接対応です。Visa TAPやMastercard Agent Payに対応する決済プロセッサー（Stripe、Adyen、Nuvei、Worldpayなど）を利用していれば、エージェント認証の検証ロジックはプロセッサー側で処理されます。

いずれのルートでも、EC事業者に求められるのは「全遮断から選別管理へ」の方針転換です。AIエージェントによるトラフィックは今後増え続けます。正規のエージェントをブロックすることは、売上機会の喪失に直結します。Web Bot Authが提供する暗号的な識別基盤を活用し、信頼できるエージェントには門を開き、そうでないものには閉じる。この精密な制御こそが、エージェント時代のEC運営に求められる基本姿勢です。

まとめ

robots.txtが「お願い」だったのに対し、Web Bot Authは「証明」です。IETFでの標準化、主要CDN・WAFへの実装、そしてVisa・Mastercardの決済プロトコルへの組み込み。この三方向からの普及は、Web Bot Authがインターネットの新たなインフラ層になることを示唆しています。2026年後半のIETF標準トラック仕様の提出が、その未来の輪郭をさらに鮮明にするでしょう。