「先月からログのクローラーアクセスが3倍になっていて、大半が ClaudeBot と Googlebot です。AIに読ませる方針にしたので許可していますが、これは正常な状態なんでしょうか」——サイトの運用を引き継いだ担当者から、こういう相談が来ることがあります。
2026年8月、この質問の答えが変わりました。AIクローラーの User-Agent を名乗りながら、実際には脆弱性スキャンを走らせているアクセスが大規模に観測されています。ClaudeBot や Googlebot を騙る手口が使われており、狙われているのは、AIコーディングツールや社内LLMを急いで立ち上げた環境に残った認証情報です。
User-Agent は誰でも名乗れる
前提を確認しておきます。User-Agent はリクエストを送る側が自由に書ける文字列で、身元の証明ではありません。curl のオプション1つで ClaudeBot/1.0 を名乗れます。これは仕様上そうなっているだけで、脆弱性ではありません。
問題は、この文字列を運用側が身元として扱ってしまう構造にあります。ここ2年ほどでAIクローラーへの対応方針を決めた組織は多く、その多くが次のどちらかの形をとりました。
- robots.txt でAIクローラーを明示的に許可（あるいは拒否）した
- WAF やCDNのボットルールで、User-Agent の一致を条件に通過させる例外を書いた
攻撃側から見ると、後者は「この文字列を名乗れば検査が緩くなる経路」です。しかも運用側のログ画面では、その通信は正常なクローラーアクセスとして集計されます。異常として目に入らないため、気づくまでの時間が長くなる。
robots.txt については、そもそも強制力のある仕組みではないことも押さえておく必要があります。Anthropic は robots.txt の指示に従う方針を明示していますが、それは正規のクローラーの話であって、名前を騙る側が従う理由はありません。
本物かどうかを確かめる方法
名乗りではなく、通信元そのものを見ます。方法は2つあり、事業者によってどちらが使えるかが違います。
1つは、公開されているIPレンジとの照合です。Google はクローラーのIPレンジを機械可読なJSONで公開しており、Googlebot を名乗るアクセスがそのレンジに含まれるかを機械的に判定できます。この方式が使える相手には、これが一番確実です。
もう1つは、逆引きDNSによる確認です。アクセス元のIPを逆引きしてホスト名を得て、そのホスト名を正引きして元のIPに戻ることを確かめます。この往復が一致することを確認する手順を forward-confirmed reverse DNS（FCrDNS）と呼びます。逆引きだけでは不十分で、正引きで戻ることまで確認しないと成立しません。ここを片道で済ませている実装をときどき見かけます。
# 逆引き（IP → ホスト名）
$ dig -x 203.0.113.10 +short
crawler-203-0-113-10.example-vendor.com.
# 正引きで戻るか（ホスト名 → IP）
$ dig +short crawler-203-0-113-10.example-vendor.com
203.0.113.10事業者がIPレンジを公開しているかどうかは変わることがあるため、実装時にはその時点の公式ドキュメントを確認してください。公開されていない相手については、逆引きの往復確認が現実的な拠り所になります。
さらに先の方向として、Cloudflare が提案している Web Bot Auth があります。HTTP Message Signatures を使い、エージェントがリクエストごとに署名で身元を証明する仕組みです。AIエージェントが増えてIPリストの維持が追いつかなくなっている、という問題意識から出てきたもので、中長期的にはここに寄っていく可能性が高い領域です。
運用側で今日確認できること
大掛かりな仕組みを入れる前に、既存の設定で穴になっている箇所を潰せます。
1. WAF・CDNのボット許可ルールが User-Agent 一致で書かれていないか。「ClaudeBot を含むなら通す」という条件が入っているなら、そこが素通り経路です。CDN 側に検証済みボットの判定機能があるなら、文字列一致からそちらに切り替えます。
2. アクセス解析のボット除外が壊れていないか。騙りのアクセスがクローラーとして除外されているなら、被害の観測ができていないだけでなく、除外の判定基準が同じ文字列に依存していることの証拠でもあります。逆に人間として集計されているなら、PVやセッション数が実態から乖離します。
3. 転送量とオリジンへの到達を見る。クローラー扱いで通したアクセスがオリジンまで届いているなら、CDNのキャッシュが効かない経路を通っている可能性があります。これは費用の話であると同時に、探索的なリクエストがそのままアプリケーションに届いていることを意味します。
4. 探索されている先を見る。騙りのスキャンは、.env、.git/config、管理画面のパス、公開されたままの設定ファイルを狙います。ログでこれらへの404が増えているなら、それは正規のクローラーの挙動ではありません。404が多いことを「無視してよいノイズ」として扱わないでください。何を探しに来たかは、404の中身にしか残っていません。
なお、これは通信元の身元確認の話であり、正規のAIエージェントを客として扱うかどうかの判断とは別の問題です。訪問者の行動から意図を見分ける観点はAIエージェントは客か、ボットかで、AIクローラーへのアクセス方針そのものはAIクローラーとコンテンツの主導権で扱っています。
次にやること
まず、自社サイトのWAFやCDNに User-Agent 文字列での許可ルールが入っていないかを見てください。入っているなら、それが今回の手口に対してどう振る舞うかを確認する。文字列一致で通しているなら、検証済みボットの判定に置き換えるか、少なくとも例外の適用範囲を静的ファイルに限定します。
そのうえで、直近1ヶ月のログでクローラーを名乗るアクセスの404を集計してください。存在しない設定ファイルや管理画面のパスが並ぶなら、それは調査ではなく探索を受けている状態です。
アクセスログの調査や、CDN・WAFのボット制御の設計を含めて相談したい場合は、グリームハブの開発・AI・自動化のご相談で承っています。構成や使っているサービスによって取れる手段は変わるため、個別にご相談ください。お問い合わせからどうぞ。
Sources
- Someone is running mass vulnerability scans, spoofing AI bots like ClaudeBot — Hacker News
- Anthropic clarifies what its three web crawlers do - and how to block them — PPC Land
- Verifying Googlebot and other Google crawlers — Google Search Central
- AI Bot Verification and Edge Enforcement: 2026 Playbook — Digital Applied
- The AI User-Agent Landscape in 2026: A Complete Reference — No Hacks
