ClaudeBot偽装の大規模脆弱性スキャンが横行｜なりすましの見分け方・robots.txtで防げない理由と対策【2026年11月】

アクセスログに ClaudeBot というUser-Agentが出ていても、それが本物のAnthropic製クローラーだという保証はありません。2026年7月末から少なくとも10月下旬まで、ClaudeBotやGPTBot、Googlebotなどを名乗って .env やクラウドの認証情報ファイルを探すスキャンが続いており、この種のアクセスはrobots.txtを書き換えても1件も減りません。

本物かどうかを確かめる公式の方法は、送信元IPをAnthropicが公開しているリスト https://claude.com/crawling/bots.json と照らし合わせることです。GreyNoise・Fastly・Cequenceの3社が公表した調査の中身、攻撃者が探しているファイル、事業者ごとに違う検証方法、今日からできる対策までをまとめました。

対象は、Webサイトやサービスを運用しているインフラ・情報システムの担当者と、Claude CodeやCodexなどのAIコーディングツールを社内で使っている開発チームです。

なお、危険なのは「ClaudeBotを名乗る偽物」で、Anthropicの正規クローラーそのものではありません。正規のClaudeBotはrobots.txtに従うと公式に説明されています。まずこの区別を押さえてください。

UAは証拠にならない｜真偽の判定は「送信元IPの照合」でしかできない

出典: Anthropic 公式サイト

User-Agentの文字列だけでは、本物か偽物かは判断できません。調査各社によると、偽物のUser-AgentはAnthropicの文字列と完全に一致しており、連絡先のメールアドレスまでコピーされています。論点ごとの答えは次のとおりです。

「AIクローラーを許可するか拒否するか」はSEO/GEO（AI検索での露出）上の判断で、サイトごとに選べます。一方、「なりすましを見分けて止める」のはセキュリティ上の対処で、どのサイトにも必要です。この2つは分けて考えてください。学習利用を止めたい場合のrobots.txtの書き方は「AI学習のオプトアウトとrobots.txt」で扱っています。

何が起きているのか｜2026年7月末から急増し、10月も続くAIクローラー詐称スキャン

出典: OpenAI 公式ドキュメント

今回のスキャンは8月の一時的な騒ぎではなく、9月・10月にも規模を広げて続いています。8月12日ごろにHacker Newsへ「Someone is running mass vulnerability scans, spoofing AI bots like ClaudeBot」という投稿が上がったのが発端で、その後セキュリティ企業3社が自社の観測データをもとに調査結果を公表しました。

3社の調査で分かったこと

各社の数字は、それぞれのセンサーや顧客の範囲で観測したものです。合算や単純比較はできませんが、規模感はつかめます。

GreyNoiseとCequenceはどちらも、ファイルの要求は観測したが、実際にファイルが盗まれた被害までは確認していないと明記しています。Cequenceによると、ほぼすべての要求はブロックされるか失敗していました。新しいマルウェアではなく、昔からある「機密ファイル探し」のスキャナーがAIボットの名前を借りているというのが実態です。

攻撃者が誰かは特定されていません。2026年11月4日時点で、Anthropicがこの件について公式声明を出したことは確認できていません。

攻撃者が探しているファイル｜狙いはAIコーディングツールの認証情報

出典: Claude Code 公式ドキュメント

狙われているのは、Webページではなく認証情報や秘密鍵が入ったファイルです。Cequenceは、要求のほぼすべてが認証情報ファイルだけを狙っていたと報告しています。Fastlyの観測では機密ファイルが約3,000種類、パスの書き方の違いを含めると4万6,000通り以上あり、最も多かったのは /.env でした。

報告されている主な探索先は次のとおりです。

環境変数ファイル（GreyNoise・Fastlyの観測）

• /.env、/.env.local、/.env.production
• /app/.env、/api/.env、/backend/.env
• /.env.old、/.env.bak、/.env.swp（バックアップやエディタの一時ファイル）

クラウド・インフラ系の認証情報

• /.aws/credentials
• /.git/config
• /service-account.json、/firebase-service-account.json
• /terraform.tfstate、/rclone.conf
• SSHの秘密鍵、サーバの環境情報（Cequenceの観測）

AIツール系の設定・認証情報（8月の初報で報告されたもの）

• /.config/anthropic/credentials/default.json
• /.claude/settings.json
• /.codex/config.toml
• /.aider.conf.yml

これらのファイルにはAPIキーやトークン、データベースの接続情報が入っていることが多く、1件見つかれば別のシステムへ入り込む足がかりになります。

AIコーディングツールの設定ファイルが標的に加わった背景には、ツールの導入が短期間で一気に進んだことがあります。ローカルで作った設定ファイルが、そのままデプロイ物に混ざってWebルートに置かれてしまうケースは珍しくありません。設定ファイルや認証情報の扱いは「AIコーディングのセキュリティリスクと対策」と「Claude Codeのセキュリティと安全な使い方」でも整理しています。

開発サーバの公開にも注意（Vite CVE-2025-30208）

GreyNoiseは、ビルドツールViteの脆弱性 CVE-2025-30208 を狙う動きもあわせて観測しています。Viteの開発サーバでは本来読めないはずのファイルを、URLに特定のクエリを付けると読み出せてしまう問題です。

• 影響を受けるのは、--host や server.host で開発サーバをネットワークに公開している場合だけです。ローカルで使っているだけなら影響しません
• 深刻度はCVSS 3.1で5.3（中）。修正版は 6.2.3 / 6.1.2 / 6.0.12 / 5.4.15 / 4.5.10 で、攻撃コードは公開済みです（GitLab Advisory Database）

検証用やデモ用に開発サーバをそのままインターネットに出している場合は、Viteを更新したうえで公開をやめてください。公開状態のAIツールがスキャンで狙われた同じ型の事例としては「Flowise RCE脆弱性（CVE-2025-59528）まとめ」もあります。

なぜ攻撃者は「AIクローラーのフリ」をするのか

出典: GreyNoise 公式ブログ

理由は4つあり、どれも運用側が善意で入れた設定を逆手に取るものです。

1. 多くのサイトがAIクローラーを許可・例外扱いしている

AI検索での露出を保つために、GooglebotやAI検索クローラーをWAFの例外リストに入れている運用は珍しくありません。攻撃者はその例外枠に紛れ込もうとします。計測サービスKnown Agentsによると、追跡している上位サイトの23%がClaudeBot向けのrobots.txtルールを持っています（2026年11月2日更新のページ）。AIクローラーを意識した設定がそれだけ広がっているということです。

2. ログ監視をすり抜けやすい

「ClaudeBotが来ている」というログ行は、それ自体は正常に見えます。異常な要求が普段のクロールに紛れるので、アラートの条件にも引っかかりにくくなります。

3. レート制限やボット対策が緩められている

AI経由の流入を失いたくないため、正規クローラー名には緩い設定をしているサイトがあります。名前を借りるだけで制限をくぐれるなら、攻撃者にとって手間の割に得るものが大きい手口です。

4. 送信元がクラウドのIPで、正規クローラーと見た目が似ている

Anthropicの正規クローラーもGoogle Cloudなどのクラウド上のIPを使っています。Fastlyの観測では、偽物の通信もほぼ1つのパブリッククラウドから来ていました。そのため「34.x だから本物」のような大ざっぱな判定は成り立ちません。

robots.txtでは防げない3つの理由

出典: Fastly 公式ブログ

「robots.txtで ClaudeBot を Disallow すれば止まるのでは」という質問はよくありますが、この種のスキャンは1件も減りません。理由は3つあります。

理由1. robots.txtに技術的な強制力がない

robots.txtは「このパスはクロールしないでください」というお願いで、守るかどうかはクローラー側に任されています。サーバー側でアクセスを拒否する仕組みではありません。

理由2. なりすましは、そもそもrobots.txtを読んでいない

Anthropicは公式ヘルプで、正規ボットはrobots.txtに従い、非標準の Crawl-delay にも対応し、CAPTCHAなどのボット対策を回避しないと説明しています。一方、GreyNoiseの観測では、偽物は /robots.txt を一度も要求していませんでした。本物のAnthropicクローラーでは /robots.txt が最も多く要求されるパスで、通信の約12%を占めていたのと対照的です。読んでいないファイルに何を書いても、偽物の動きは変わりません。

理由3. robots.txtが「隠したい場所の一覧」になってしまう

robots.txtは誰でも読める公開ファイルです。管理画面やバックアップのディレクトリを Disallow に並べると、スキャナーにとっては探す場所のヒントになります。隠したい場所の存在をrobots.txtで知らせるのは逆効果です。

なお、llms.txt も現時点では強制力のない宣言ファイルで、なりすまし対策にはなりません。

robots.txtは「正規ボットの行動を調整する道具」で、「なりすましを止める道具」ではありません。 なりすまし対策はWebサーバ・WAF・CDNの層で行う必要があります。

本物のClaudeBotを見分ける方法｜公式IPリスト（bots.json）の照合手順

出典: Claude 公式サイト

ClaudeBotの真偽を確かめる公式の方法は、送信元IPをAnthropicが公開しているIPリストと照らし合わせることです。Anthropicの公式ヘルプ（2026年4月7日更新の英語版）は、送信元IPが bots.json に載っていればAnthropicからのアクセスだと案内しています。

判定は3ステップ

1. User-Agentを見る。ここでは何も確定しません。調べる対象を絞るだけです
2. 送信元IPを公式リストと照合する（Anthropicなら https://claude.com/crawling/bots.json）
3. 一致しなければ「なりすまし」として扱い、レート制限・チャレンジ・ブロック・ログの保存へ進む

Anthropicの正規クローラーは次の3種類です。役割とブロックしたときの影響は公式ヘルプの説明に基づいています。

識別子は2026年8月に確認した例で、バージョン部分は変わることがあります。現在の公式ヘルプはボット名だけを載せています。また、この文字列と一致していても本物の証拠にはなりません。GreyNoiseとCequenceはどちらも、偽物のUser-AgentがAnthropicの文字列と完全に一致していたと報告しています。

見分けるための4つの手がかり

IP照合が判定の中心ですが、調査3社の報告を並べると、偽物には共通する動きがあります。ログを調べるときの手がかりとして使えます。

Cequenceによると、偽物はまず意味のないランダムなパスを送り、「どんなURLにも200を返すサイト」かどうかを確かめてから本番の探索に入っていました。存在しないパスに200を返す設定になっているサイトは、見分けにくいうえに狙われやすいので、あわせて確認しておくと安心です。

GreyNoiseはHTTPリクエストの特徴（JA4Hと呼ばれるフィンガープリント）も本物と偽物で違っていたと報告しています。ただし、これはブロックではなく調査に使うよう勧めており、許可するときは「特徴」と「公開IP」の両方が一致することを条件にするよう求めています。

bots.json の実際の中身（2026年11月4日取得時点）

https://claude.com/crawling/bots.json を取得すると、次のような構造のJSONが返ります（抜粋）。

{
  "creationTime": "2026-10-20T00:00:00Z",
  "prefixes": [
    { "ipv4Prefix": "216.73.216.0/22" },
    { "ipv4Prefix": "34.162.230.222/32" },
    { "ipv4Prefix": "136.79.143.251/32" },
    { "ipv4Prefix": "34.152.124.140/32" }
  ]
}

2026年11月4日の取得時点では、creationTime は 2026-10-20T00:00:00Z、プレフィックスは合計14件（/22 が1件、/32 が13件）で、すべてIPv4でした。IPv6のプレフィックスは含まれていません。

ここで注目したいのは、2か月で中身が大きく入れ替わっていることです。

この変化から、運用上のポイントが3つ見えてきます。

• クラウドのIPだからという理由で本物と判定しない。プレフィックス単位、/32 単位で厳密に一致させる必要があります
• 手書きの許可リストは必ず古くなる。8月時点のリストを固定で使い続けていたら、今は正規クローラーの一部を誤ってブロックしているはずです。定期的に取得して自動で反映する仕組みにしてください
• 記事や他サイトに載っているIPを書き写さない。この記事の値も取得時点のものです。運用では必ず自分で最新版を取得してください

Anthropicはかつて「サービス事業者の公開IPを使っているため、IPレンジは公開していない」と説明していましたが、現在はIPリストを公開しています。一部の言語版のヘルプにはまだ古い記述が残っているので、「AnthropicはクローラーのIPを公開していない」と書かれた解説は古い情報だと考えてください。

混同注意：API用のIPアドレスはクローラー検証に使えない

Anthropicの開発者向けドキュメントには、クローラーとは別のIPアドレスが載っています。これはClaude APIやConsole、MCPコネクタなどのためのもので、クローラーの真偽判定には使えません。

2026年11月4日時点のClaude APIのIPアドレス一覧では、153.61.224.0/22（Inbound）と 153.61.208.0/20（Outbound）が加わっています。8月時点の許可リストのままだと、新しいレンジからの通信を通せません。廃止済みのIPとして 34.162.46.92/32、34.162.102.82/32、34.162.136.91/32、34.162.142.92/32、34.162.183.95/32 の5件も明記されているので、古い許可リストからは消しておきましょう。

クローラーの検証は bots.json、APIやMCP経由の通信の制御は開発者ドキュメントのレンジと、用途を分けて管理してください。混ぜたまま許可リストを作ると、どちらの検証もきちんと働きません。

Claude APIやMCPコネクタを自社の業務システムにつなぐ場合は、こうした通信の許可設計も含めて要件を詰めることになります。新しいモデルや機能を自社のシステムに組み込むときの進め方と費用の目安は「AI開発の費用相場」でまとめています。

ClaudeBotは逆引きDNSでは検証できない

「クローラーの真偽は逆引きDNS（rDNS）で確かめる」と一律に書いている解説がありますが、これはGoogleの手順で、ClaudeBotには使えません。2026年11月4日時点で、Anthropicがホスト名による検証方法を公式に案内している記載は見当たりません。

ClaudeBotのIPを host コマンドで逆引きしてもホスト名が返らない、またはクラウド事業者の汎用的なホスト名しか返らないのはこのためです。ClaudeBotは bots.json との照合で判定するのが正しいやり方です。

【比較】主要AIクローラーの検証方法一覧

出典: Google 検索セントラル 公式ドキュメント

公式の検証方法は事業者ごとに違います。「全部rDNSで確かめる」「全部IPリストで確かめる」といった1つのやり方ではまとめられません。2026年11月4日時点の各社の公式ドキュメントをもとに整理しました。

この表のとおり、「robots.txtに従うかどうか」と「本物かどうか」は別の問題です。ChatGPT-UserやPerplexity-Userのように、本物でもrobots.txtが適用されないボットがあります。また Google-Extended を名乗るアクセスは、GoogleがそのUser-Agentを送らない以上、すべて偽物と判断できます。

IPリストは各社とも更新されます。実装の目安としては、リストの取得を1日1回程度cronで回し、取得に失敗したときは前回の内容を使い続ける設計が無難です。取得に失敗したからといって全部ブロックすると、AI検索からの流入を丸ごと失うことにつながります。

今日やるべき対策｜優先度1〜3

対策は「公開されているファイルをなくす」→「判定の条件を見直す」→「仕組みとして回す」の順に進めます。

優先度1：今すぐ（15分）

• 自分のドメインで、認証情報ファイルが公開されていないか確認する。/.env や /.git/config に curl でアクセスし、200 が返るパスがあればすぐに非公開にする
• Webルートにあるドットファイル（.env .git .claude .aws .codex など）を外へ移す。デプロイ物に含めない構成に変える
• 公開されていた場合は、関係するAPIキー・トークン・クラウドの認証情報をすべて入れ替える。一度でも公開状態だったなら「漏れたもの」として扱うのが原則です。GreyNoiseも、Webから取得できる状態だったクラウドの鍵は入れ替えるよう勧めています
• 開発サーバをインターネットに出していないか確認する。Viteを使っているなら修正版へ更新する

優先度2：今週中

• ドットファイル・設定ファイルへのアクセスをWebサーバの設定でまとめて遮断する
  • Nginx: location ~ /\.(env|git|aws|claude|codex|ssh) { deny all; return 404; }（/.well-known/ は止めないよう、対象を列挙する書き方にしています）
  • Apache: RedirectMatch 404 /\.(env|git|aws|claude|codex|ssh) をバーチャルホスト設定か .htaccess に書く（Nginxと同じく対象を列挙し、/.well-known/ は止めない）
• User-Agent名だけを条件にしたWAFの例外・許可リストをやめる。「名乗っているボット名」と「公式IPリストとの一致」の両方を条件にする
• 「AIボットを名乗る」かつ「検証に通らない」かつ「機密ファイルを要求している」通信をブロックするルールを入れる。Fastlyが勧めている組み合わせで、User-Agentの完全一致ではなく名乗った名前と検証結果で判定するため、IPが入れ替わっても効きます
• 認証情報系のパスへの要求でアラートが出るようにする。fail2banやNginxの limit_req で、こうしたパスへのアクセスを即時ブロックの対象にする方法もあります
• User-Agentを理由に権限や制限の免除を与えている箇所を洗い出す

優先度3：継続運用

• bots.json などのIPリストを定期的に取得し、許可リストを自動で作る。リストごとに担当者と取得の頻度を決めておく
• CDNやボット管理サービスを使う場合は、「検証済みは許可、検証されていないAIボットの名乗りはチャレンジかブロック」という方針にする
• 数日単位の動きで判断する。robots.txtを一度も取りに来ないのにクローラーを名乗るアクセスは疑う
• IPのブロックリストだけに頼らない。Cequenceは偽装者のIPが入れ替わるためブロックリストは数日で古くなると指摘し、GreyNoiseも795のネットワークに分散している以上、ネットワーク単位のブロックは現実的でないとしています
• ステージング環境や管理用サイトをインターネットに公開しない。静的にできる部分は静的ホスティングに移し、攻撃される面そのものを減らす

Anthropicは公式ヘルプで、IPによるブロックを推奨していません。IPで止めるとrobots.txtを読めなくなり、オプトアウトが正しく効かなくなる可能性があるためです。正規クローラーを止めたいならUser-Agent単位のrobots.txtで、なりすましは検証とファイル遮断で対処する、という分け方が現実的です。IPは「検証」に使い、「ブロック」の主な手段にはしないと覚えておいてください。

環境別のやることの目安

CloudflareでAIクローラーの扱いを細かく決めたい場合は「Cloudflare Pay Per Use（旧Pay Per Crawl）とは」も参考になります。

コピペで使える自己点検コマンド

ここで紹介するコマンドは、自分が管理しているサーバ・ドメインにだけ実行してください。他人のドメインに対して実行すると、無断のスキャンになります。

1. ClaudeBotを名乗るIPのうち、公式リストに含まれないものを洗い出す

# 公式IPリストを取得
curl -s https://claude.com/crawling/bots.json -o /tmp/claude-bots.json

# アクセスログから ClaudeBot を名乗るIPを抽出（Nginx combined 形式を想定）
grep -i 'ClaudeBot' /var/log/nginx/access.log | awk '{print $1}' | sort -u > /tmp/claimed-ips.txt

# 公式リストに含まれないIP＝なりすまし候補
python3 - <<'PY'
import ipaddress, json
nets = [ipaddress.ip_network(p["ipv4Prefix"]) for p in json.load(open("/tmp/claude-bots.json"))["prefixes"] if "ipv4Prefix" in p]
for line in open("/tmp/claimed-ips.txt"):
    ip = line.strip()
    if not ip:
        continue
    try:
        a = ipaddress.ip_address(ip)
    except ValueError:
        continue
    if not any(a in n for n in nets):
        print("SPOOF?", ip)
PY

SPOOF? と出たIPは、ClaudeBotを名乗りながら公式リストに載っていない送信元です。そのIPが何を要求していたかをログで追い、認証情報系のパスを要求していればブロックの対象にしてください。

2. ClaudeBotを名乗るのに /robots.txt を一度も取りに来ていないIPを探す

LOG=/var/log/nginx/access.log

# ClaudeBot を名乗ったIP
grep -i 'ClaudeBot' "$LOG" | awk '{print $1}' | sort -u > /tmp/claimed.txt

# そのうち /robots.txt を取得したIP（combined 形式では7列目がパス）
grep -i 'ClaudeBot' "$LOG" | awk '$7=="/robots.txt"{print $1}' | sort -u > /tmp/fetched-robots.txt

# robots.txt を取りに来ていないIP＝疑わしい
comm -23 /tmp/claimed.txt /tmp/fetched-robots.txt

ログの保存期間が短いと本物でも引っかかることがあるので、IPリストとの照合と組み合わせて判断してください。数日分のログで見るのがおすすめです。

3. Googlebotの場合（逆引き→正引きの二段確認）

host 66.249.66.1                       # → crawl-66-249-66-1.googlebot.com が返る
host crawl-66-249-66-1.googlebot.com   # → 元のIPに戻れば本物

逆引きで得たホスト名を正引きして、元のIPに戻ることまで確かめるのが必須です。逆引きの結果だけを信じると、偽装を見抜けません。

4. 狙われているパスが自サイトで公開されていないか確認する

for p in /.env /.env.local /.env.production /.env.bak /app/.env /api/.env \
         /.git/config /.aws/credentials \
         /.claude/settings.json /.codex/config.toml /.aider.conf.yml \
         /service-account.json /firebase-service-account.json \
         /terraform.tfstate /rclone.conf; do
  printf "%s -> " "$p"
  curl -s -o /dev/null -w "%{http_code}\n" "https://example.com$p"
done
# 404 / 403 なら問題なし。200 が返るものがあればすぐ対応

# 存在しないパスに 200 を返していないかも確認
curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/$(openssl rand -hex 8)"
# 404 が正常

example.com を自分のドメインに置き換えて実行してください。ランダムなパスで 200 が返る場合は、存在しないURLにもページを返す設定になっています。その場合はファイルの確認で 200 が出ても中身が普通のHTMLページのことがあるので、実際の応答内容も確かめてください。

Web Bot Auth｜なりすまし問題の本命はどこへ向かうか

出典: Cloudflare 公式ブログ

IPリストとの照合は今できる現実的な方法ですが、根本的な解決ではありません。8月から10月の間に bots.json の中身が大きく変わったように、IPは事業者の都合で増減し、クラウドのIPは使い回されるため、照合には手間がかかり続けます。

そこで有力とされているのが、Web Bot Auth（RFC 9421のHTTP Message Signaturesを使った署名検証）です。Cloudflareのドキュメント（2026年10月8日更新）によると、ボットはリクエストに Signature-Agent（鍵の置き場所のURL）・Signature-Input・Signature の3つのヘッダを付け、受け手は /.well-known/http-message-signatures-directory で公開されたEd25519の鍵で検証します。IPに頼らないため、IPの変動やクラウドIPの使い回しに左右されません。CloudflareではWeb Bot Authの検証に通ると、検証済みボットとして扱われます。

ただし、2026年11月4日時点で、AnthropicがClaudeBotのWeb Bot Auth対応を公式に文書化した記載は見当たりません。公式ヘルプにも署名検証への言及はありません。したがってClaudeBotの検証は、今のところ公開IPリストとの照合が中心です。署名検証は「今後の本命」と位置づけ、対応が発表されたら切り替えを検討するのがよいでしょう。

前例：UA詐称はAI事業者側でも起きている

User-Agentの偽装は攻撃者だけの問題ではありません。2025年8月には、Cloudflareが「Perplexityが公式のUser-Agentでブロックされた後、Chrome on macOSを装った未申告のクローラーに切り替え、公式外のIPや複数のASNを使い分けてrobots.txtやWAFを回避していた」と指摘し、Verified Botsから外す対応を取りました。数万ドメイン、1日数百万リクエスト規模と報じられています。

攻撃者による偽装でも、事業者自身の未申告クロールでも、User-Agentという文字列を信頼の根拠にする運用はもう成り立たないという点は同じです。AIエージェント全般のアクセス制御の考え方は「AIエージェントのセキュリティ対策」で整理しています。

今すぐ確認すべき方 / 慌てなくてよい方

今すぐ確認すべき方

• Claude Code・Codex・Aiderなどを社内で使っている開発チーム。.claude/settings.json や .codex/config.toml が探索対象として報告されています。リポジトリとデプロイ物の両方を確認してください
• VPSやクラウドでWebサーバを自前で運用している方。ドットファイルの遮断が初期設定で効いていないことがよくあります
• AI検索対策でAIクローラーをWAFの例外に入れている方。例外の条件がUser-Agent名だけになっていないかを真っ先に点検してください
• .env をWebルートに置いたことがある方、置いたかどうか覚えていない方。公開されていたものとして鍵を入れ替えるのが安全です
• Viteなどの開発サーバを検証用に外部公開している方。更新したうえで公開を止めてください
• WordPressなどのCMSを運用している方。従来型の管理画面探しも並行して行われています

慌てなくてよい方

• ビルド済みのHTMLだけを配信する完全な静的サイト（GitHub Pages・Netlifyなど）を運用している方。サーバ上に認証情報ファイルがなく、ビルド時の秘密情報もホスティング側の環境変数で管理しているなら、直接のリスクは小さいです
• CDNでボット検証を有効にし、検証されていないAIボットの名乗りをチャレンジかブロックの対象にしている方
• Claudeなどの生成AIを「使うだけ」で、自分でWebサーバを運用していない方。今回の件はサイトを運営する側の話で、Claudeを使うこと自体に新しいリスクが生じるものではありません。Claudeそのものについては「Claudeとは」で解説しています

静的サイトでも、ビルド成果物に .env や .map ファイルが混ざっていないかは一度確認しておくと安心です。

よくある質問（FAQ）

Q1. ログにClaudeBotが大量に出ています。robots.txtで拒否すれば止まりますか？

本物なら止まりますが、なりすましなら止まりません。 まず送信元IPを bots.json と照らし合わせ、本物か偽物かを切り分けてください。本物のクロール量が多くて負荷になっているなら、robots.txtの Crawl-delay（例: User-agent: ClaudeBot の下に Crawl-delay: 1）が使えます。偽物ならWebサーバかWAFで遮断します。

Q2. ClaudeBotを全部ブロックしたら、Claudeの回答や検索結果に自社サイトが載らなくなりますか？

ボットごとに役割が違うので、まとめてブロックする必要はありません。学習用の ClaudeBot だけを拒否し、ユーザーの質問に応じて取得する Claude-User や検索用の Claude-SearchBot は許可する、という分け方ができます。公式ヘルプでも、Claude-UserやClaude-SearchBotを止めると検索での表示が減る可能性があると説明されています。

Q3. bots.jsonのIPを許可リストに入れておけば安心ですか？

安心とは言えません。許可リストは判定のための参照データで、それ自体が防御になるわけではありません。実際に2026年8月から10月の間に、bots.json は23件から14件へと中身が入れ替わりました。書き写して固定したリストは、いずれ正規クローラーの誤ブロックを起こします。定期的に取得して自動で反映してください。

Q4. .env が一度でも公開状態だった場合、鍵は入れ替えるべきですか？

入れ替えるべきです。 スキャンは自動化されていて、Cequenceの観測では1つのIPが約8秒で50〜190回の要求を送っていました。公開されていた時間が短くても、取得された可能性は消せません。ログに取得の記録がないことも、取られていない証明にはなりません。APIキー・クラウドの認証情報・データベースの接続情報をすべて入れ替えてください。

Q5. 逆引きDNSでClaudeBotを検証しようとしましたが、ホスト名が引けません。設定ミスでしょうか？

設定ミスではありません。Anthropicはホスト名による検証方法を公式に案内していないため（2026年11月4日時点）、逆引きしても意味のあるホスト名は返りません。rDNSでの検証はGoogle向けの手順です。ClaudeBotは bots.json との照合で判定してください。

Q6. WordPressを使っています。特別にやることはありますか？

WordPressなら、wp-config.php をWebルートの外に置く、使っていなければXML-RPCを無効にする、readme.html や license.txt などバージョンが分かるファイルを消す、管理画面にIP制限かBasic認証をかける、といった対策が効果的です。テーマやプラグインのフォルダに、開発時の .env やバックアップファイルが残っていないかも確認してください。

Q7. Cloudflareの無料プランでも対応できますか？

基本的な対応はできます。WAFのカスタムルールで、/.env や /.git/ など特定のパスへのアクセスをまとめてブロックするのが手軽です。より細かいボット管理や署名検証をどのプランで使えるかは、Cloudflareの最新のプラン表で確認してください。無料プランなら「認証情報系パスへのアクセスを一律ブロック」という単純なルールを軸にするのが現実的です。

Q8. スキャンを受けたこと自体は通報すべきですか？

2026年11月4日時点で、IPAやJPCERT/CCによる本件の注意喚起は確認できていません。不正アクセスの成功や情報漏えいなど実際の被害が分かった場合は、警察やJPCERT/CCへの相談を検討し、個人情報が関わるなら個人情報保護委員会への報告義務も確認してください。スキャンを検知しただけの段階なら、ログを保存したうえで自社の防御を固めることを優先します。

Q9. 正規のClaudeBotのクロールで困ったときは、どこに連絡すればよいですか？

Anthropicの公式ヘルプに連絡先が案内されており、問題のドメインを含むメールアドレスから送るよう求められています。ただし、これは正規クローラーの挙動についての窓口です。bots.json に載っていないIPからのなりすましは、Anthropicの管理外の通信なので、自社の防御で対処することになります。

まとめ

• ログの ClaudeBot は、User-Agentが一致しているだけでは本物の証拠にならない。偽物は本物と同じ文字列を使っている
• 2026年7月末から少なくとも10月下旬まで、AIクローラーを名乗って .env やクラウドの認証情報を探すスキャンが続いている。GreyNoise・Fastly・Cequenceの3社が観測を公表した
• robots.txtでは防げない。強制力がなく、偽物はrobots.txtを読んでもいない。隠したい場所を知らせてしまう副作用もある
• 判定の基本は https://claude.com/crawling/bots.json との送信元IPの照合。ClaudeBotは逆引きDNSでは検証できない。robots.txtを取りに来るか、何を要求しているかも手がかりになる
• bots.json は8月の23件から10月20日付の14件へ入れ替わった。手書きの許可リストではなく、定期取得で自動反映する
• クローラー用IP（bots.json）とAPI用IP（160.79.104.0/21・153.61.208.0/20 など）は別物
• 最優先は自サイトで認証情報ファイルが公開されていないかの確認と、公開されていた場合の鍵の入れ替え。開発サーバの外部公開もやめる

AIクローラーを許可するか拒否するかはサイトごとの選択ですが、なりすましを見分けられる状態にしておくことはどのサイトにも必要です。まずは自分のドメインで公開ファイルの確認から始めてください。

関連記事

• AIコーディングツールの設定ファイル・認証情報の扱いは「AIコーディングのセキュリティリスクと対策」
• Claude Codeを安全に使う設定は「Claude Codeのセキュリティと安全な使い方」
• robots.txtでAIの学習利用を止める方法は「AI学習のオプトアウトとrobots.txt」
• CloudflareでのAIクローラーの扱いは「Cloudflare Pay Per Use（旧Pay Per Crawl）とは」
• AIエージェント全般のアクセス制御・権限設計は「AIエージェントのセキュリティ対策」
• 生成AI利用全体のリスクを知りたい方は「生成AIのセキュリティリスクと対策」
• 公開状態のAIツールがスキャンで狙われた同じ型の事例は「Flowise RCE脆弱性（CVE-2025-59528）まとめ」
• Codexを使う環境のセキュリティは「Codex Securityとは」
• Anthropicのセキュリティ機能は「Claude Securityとは」
• AI検索エンジンとクローラーの関係は「AI検索エンジン比較」