Web Bot Authとは—AIクローラーの『なりすまし』を暗号で解決する新技術

「GPTBotがサイトに来ている」とサーバーログで確認できても、本当にOpenAIのクローラーなのか、確かめる方法が今はありません。User-Agentは自己申告なので、誰でも好きな名前を名乗れます。

Web Bot Authは、AIクローラーが「自分は本物だ」と暗号署名で証明できるようにする新しい仕組みです。IETFという国際標準化団体が2025年末にワーキンググループを立ち上げ、2026年4月に最初の仕様書を提出するタイミングを迎えています。

AI観測ラボでは、サーバーログでクローラーのUser-Agentを観測してきた中で「本当にこのボットは名乗り通りのものなのか」という疑問が常にありました。Web Bot Authはその疑問に、技術の側から答えを出そうとする動きです。

今回の記事では、IETFやCDN、AWS WAFといった技術用語が登場します。それぞれ以下の意味で使っています。

用語	意味
IETF	インターネットの技術標準を決める国際団体。HTTPやメールの仕組みもここで決まった
CDN	世界中にサーバーを置いてWebサイトを高速配信する仕組み。CloudflareやAkamaiが有名
AWS WAF	Amazonが提供するWebサイトへの不正アクセスを防ぐセキュリティサービス
RFC	IETFが発行するインターネット技術の正式な仕様書。RFCに載ると「国際標準」扱いになる

この記事でわかること｜📖：約6分

• AIクローラーのなりすまし問題とrobots.txtの限界
• Web Bot Authの仕組みと暗号署名でできること
• IETFの標準化タイムライン（2026年〜2027年）
• サイト運営者が今すべきこと・しなくていいこと

AIクローラーはUser-Agentを自己申告している

サーバーログにGPTBotという文字列が残っていても、そのリクエストが本当にOpenAIから来たものかどうかは、現在の仕組みでは確認できません。User-Agentはリクエストを送る側が自由に設定できる文字列なので、誰でも「GPTBot」と名乗ってアクセスできます。

AI観測ラボのサーバーログ解析を続けてきた中で気づいたのは、UAとIPアドレスの両方を公開して正直に名乗っているクローラーは、むしろ少数派だという現実です。

ByteSpiderやxAIのGrokクローラーは公式ドキュメント自体が存在せず、ChatGPT Agent modeは一般的なMac ChromeのUser-Agentを使うためサーバーログからは人間と区別できません。

「きちんと名乗っているクローラーだけを相手にしていればいい」という前提自体が、実態とずれているのが現状です。

robots.txtは「お願い」でしかなかった

現在のAIクローラー対策の中心にあるrobots.txtは、1994年に生まれた仕組みです。クローラーに対して「このページは読まないでください」とお願いする文書であり、強制力はありません。

robots.txtでAIクローラーを制御するでも解説したように、robots.txtはあくまでクローラーが「自主的に守る」前提で成立しています。守るかどうかはクローラー側の判断に委ねられており、実際にPerplexityBotはrobots.txtを尊重すると公表しながら、Cloudflareの調査では迂回が確認されています。

robots.txtの根本的な問題は2つあります。1つ目は「名乗っている相手が本物かどうか確認できない」点、2つ目は「名乗り通りだったとしても守る義務がない」点です。仮にGPTBotへの拒否設定を書いても、なりすましたボットにはまったく意味がありません。

Web Bot Authはこの2つの問題を、暗号技術で解決しようとする動きです。

Web Bot Authとは何か

Web Bot Auth（WBA）は、AIクローラーがWebサイトにアクセスする際に「自分は本物だ」と暗号署名で証明できるようにする仕組みです。Cloudflareが主導し、IETFという国際的なインターネット標準化団体でワーキンググループが立ち上がっています。

仕組みをざっくり説明すると、以下の3ステップになります。

1. クローラー運営者（OpenAIやAnthropicなど）が秘密鍵と公開鍵のペアを生成する
2. クローラーがサイトにアクセスする際、秘密鍵でリクエストに署名をつける
3. サイト側が公開鍵で署名を検証し、本物のクローラーかどうか確認できる

これはWebサイトのHTTPS通信（SSL/TLS）で使われている暗号の仕組みと同じ考え方です。「鍵を持っている本人しか署名できない」という性質を使って、なりすましを防ぎます。

公開鍵は`/.well-known/http-message-signatures-directory`というURLに置かれ、誰でも確認できる状態にします。サイト側はそのURLを参照して署名を検証するため、クローラーの正体をリアルタイムで確かめられます。

標準化のタイムライン—今どこまで進んでいるか

Web Bot AuthはIETFのwebbotauthワーキンググループで標準化が進んでいます。2025年末に立ち上がったばかりの新しい動きですが、AWS・Cloudflare・Vercel・Akamaといった大手インフラ企業がすでに実装済みで、普及のスピードは想定より速い印象です。

時期	出来事	状況
2025年末	IETFワーキンググループ（webbotauth）発足	✅ 完了
2026年4月（今月）	標準仕様をIESGに提出	🔄 進行中
2026年8月	運用ガイドライン（ベストプラクティス）提出	⏳ 予定
2027年頃	RFC正式公開	⏳ 予定

注目すべきは、標準化完了を待たずに主要インフラが動き始めている点です。AWS WAFはすでにWeb Bot Authで検証済みのクローラーを自動的に許可する実装を完了しています。Cloudflareも同様で、対応済みのクローラーとそうでないクローラーを区別して扱えるようになっています。

一方でRFC正式公開は早くても2027年の見込みで、現時点ではまだドラフト段階です。サイト運営者が直接対応しなければならない段階には至っていません。

AI観測ラボで見えていた「正体不明クローラー」問題

AI観測ラボでは2026年1月からサーバーログを継続的に解析してきました。その中で一貫して感じていたのが「User-Agentを信用していいのか」という疑問です。

たとえばAIクローラーはIPで判定するな—User-Agentを使うべき理由で解説したように、クローラーの識別にはUser-Agentを使うのが現状のベストプラクティスです。ただしUser-Agentはあくまで自己申告なので、完全な証明にはなりません。

実際にサーバーログを見ていると、以下のような状況が観測されています。

クローラー	UA公開	IP公開	公式ドキュメント
GPTBot	✅	✅	✅
ClaudeBot	✅	✅	✅
Bingbot	✅	✅	✅
Applebot	✅	✅	✅
ByteSpider	✅	❌	❌
Grok（xAI）	✅	❌	❌
ChatGPT Agent mode	❌（Chrome UAを使用）	❌	❌

きちんと名乗り、IPも公開し、公式ドキュメントまで整備しているクローラーは一部にとどまります。Web Bot Authが普及すれば、暗号署名で本物かどうかを確認できるようになるため、こうした「自己申告頼み」の状況が根本から変わります。

ただし署名できるのは「署名しようとするクローラー」だけです。ChatGPT Agent modeのようにそもそも正体を隠して動くクローラーへの効果は限定的で、完全な解決策にはならない点は押さえておく必要があります。

サイト運営者は今何をすべきか

結論から言うと、2026年4月時点でサイト運営者が直接Web Bot Authに対応する必要はありません。まだドラフト段階であり、RFC正式公開は2027年以降の見込みです。WordPressやXserverを使っている一般的なサイト運営者が設定を変える場面は、当面訪れません。

ただし、以下の2点は頭に入れておく価値があります。

観点	内容
robots.txtの限界を知る	robots.txtは「お願い」ベースの仕組みで、なりすましには無力。過信しないことが重要
サーバーログで実態を把握する	Web Bot Auth普及前の今は、サーバーログでクローラーの挙動を継続的に観測するのが現実的な対策

Web Bot Authが普及した世界では、「署名済みクローラー＝信頼できる」「署名なしクローラー＝素性不明」という区別がインフラレベルで自動的に行われるようになります。AWS WAFやCloudflareはすでにその方向で動いており、CDNを使っているサイトは気づかないうちに恩恵を受ける形になっていくはずです。

サーバーログでクローラーを観測する方法については、GA4だけではAI流入は計測できない—サーバーログで補完する方法を参考にしてください。また現時点でどのクローラーが来ているかを把握したい場合は、AI観測ラボの診断ツールも活用できます。