Web Bot Auth完全解説 — CloudflareとIETFが進めるAIエージェント認証の新標準【2026年版】

User-Agent偽装の時代を終わらせる暗号学的な署名

AIエージェントがWebで商品を探し、価格を比較し、カートに追加する時代になって、Webサイト運営者には新しい悩みが生まれました。そのエージェントは正規のClaudeやChatGPTなのか、それを装った無関係のスクレーパーなのか。従来の識別手段では区別がつきません。Web Bot Authは、この問題をIETF標準の署名方式で解こうとしています。

本記事では、Web Bot Authの仕組み、Cloudflareの実装状況、そしてEC事業者にとっての実務インパクトを整理します。信頼レイヤー全体の位置付けはプロトコル完全比較を参照してください。

Web Bot Authとは何か

Web Bot Authは、Cloudflareが2025年後半にIETFに提案した、HTTPリクエストを送るボットやAIエージェントの正当性を検証するための仕組みです。仕様はIETFのhttpbis作業部会のドラフトとして公開されており、RFC 9421（HTTP Message Signatures）をベースにしています。

中核の発想はシンプルです。AIエージェント提供者（Anthropic、OpenAI、Googleなど）は、自分のボット用の署名鍵ペアを作成し、公開鍵を決まった場所（例: https://anthropic.com/.well-known/http-message-signatures-directory）に置きます。ボットがHTTPリクエストを送るとき、秘密鍵でリクエストヘッダに署名を付けます。受信側のWebサイトは公開鍵で署名を検証し、「このリクエストは確かにAnthropicのClaudeから送られた」と確認できます。

従来のUser-Agentヘッダは文字列を書き換えるだけで偽装できました。robots.txtは「やってはいけないこと」を宣言するだけで強制力がありません。IP範囲リストは維持が大変で、動的にIPが変わると機能しません。Web Bot Authは暗号学的な証明によってこれらすべての弱点を一度に解決します。

Cloudflareの実装と2026年4月時点の状況

Cloudflareは2026年3月、自社エッジでWeb Bot Authの本実装を有効化したと発表しました。Cloudflareのネットワークを経由するWebサイトは、追加設定をするだけで「Web Bot Auth対応ボット以外は商品詳細ページを見せない」「Web Bot Auth済みのエージェントには料金表を公開する」といった制御ができます。

現時点で主要な対応エージェントは、Anthropic Claude、OpenAI ChatGPT、Perplexity、Common Crawl、そしていくつかのGoogle関連ボットです。Googleは独自に「Googlebot」を長年運用してきた経緯があり、Web Bot Authへの全面移行は2026年後半とされています。

IETFの標準化は2026年4月時点でまだドラフト段階ですが、CloudflareとAnthropic、OpenAIが足並みを揃えて本番展開に入っていることから、実質的な業界標準の位置にほぼ到達しています。

EC事業者にとっての意味

Web Bot AuthがEC事業者に与える影響は、大きく2方向あります。

1つはスクレイピング対策です。2025年以降、価格比較サイトや競合分析ツールを装った無認可のスクレイパーが急増し、商品情報や価格データが大量に吸い上げられていました。Web Bot Authを使えば、「認証されたAIエージェントだけを通す」というポリシーが設定でき、正規のChatGPTには情報を提供しつつ、無断スクレイパーは弾くという制御が実現します。

もう1つはAIショッピング体験への参加です。逆説的ですが、Web Bot Authに対応することは、AIエージェント経由の集客を歓迎するシグナルでもあります。Claudeが商品ページを訪問して情報を集めるとき、Web Bot Authで認証されたトラフィックを通してくれるサイトは、そうでないサイトよりも「AIに見つけてもらいやすい」状態になります。

具体的な設定例を示すと、Cloudflareダッシュボードから「Allow verified bots only」を選び、許可リストにClaude、GPT、Perplexityなどを加えるだけで対応が完了します。独自のルールを書く必要はほとんどありません。

Visa TAP / Mastercard Agent Pay / AP2との関係

Web Bot Authは、Visa TAPやMastercard Agent Payと似たレイヤー（信頼レイヤー）に位置しますが、解く問題が少し違います。Visa TAPは決済時にエージェントの正当性を検証します。Web Bot AuthはそもそもWebアクセスの時点でエージェントを識別します。

決済までたどり着く前の段階、つまり商品発見やカート構築の段階で「このエージェントは誰か」を知りたいとき、Web Bot Authのほうが自然な解になります。逆に、決済実行時の信頼はVisa/Mastercardが担います。両者は補完関係で、同時に使うことが前提です。

AP2との関係はもう少し緩いです。AP2はエージェント間のメッセージ形式を定めるプロトコルで、Web Bot AuthはWebサイト宛てのHTTPリクエストを扱います。直接の相互作用は少ないですが、同じエージェントIDで両方を使う運用は自然です。

まとめ — 「誰が訪問しているか」を解く最初の標準

Web Bot Authは地味な規格ですが、AIエージェントがWebを歩き回る時代のサイト運営には欠かせないインフラになりつつあります。2026年後半から2027年にかけて、主要CDN（Cloudflare、Akamai、Fastly）すべてが対応することで、実質的な業界デフォルトになる見込みです。

EC事業者としての最小限の動きは、Cloudflareまたはそれに相当するCDNを使っているなら、ダッシュボードで「verified bots」を許可する設定を一度確認することです。それだけで、AIエージェント経由のトラフィックを選別的に受け入れる準備が整います。

信頼レイヤーの全体像と、Web Bot Authが他のプロトコル（Visa TAP、Mastercard Agent Pay、AP2）とどう組み合わさるかはプロトコル完全比較にまとめてあります。