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

アクセスログに ClaudeBot というUser-Agentが出ていても、それが本物のAnthropic製クローラーである保証はありません。2026年7月末以降、ClaudeBotやGooglebot、GPTBotなどのUser-Agentを詐称して .env や .claude/settings.json といった認証情報ファイルを探し回る大規模な脆弱性スキャンが観測されており、この種のアクセスはrobots.txtでは1件も減りません。

本物のClaudeBotを判定できる公式手段は、送信元IPをAnthropicが公開しているIPリスト https://claude.com/crawling/bots.json と突き合わせることだけです。Webサイトやサービスを運用しているインフラ・情報システム担当者、そしてClaude CodeやCodex、AiderなどのAIコーディング支援ツールを社内導入している開発チームに向けて、観測されている事実とその確度、攻撃者が探しているファイルパス、事業者ごとに異なる検証方法、そして今日から着手できる対策までをまとめます。

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

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

出典: Anthropic 公式サイト

論点ごとに整理すると、状況は次のようになります。

つまり、「AIクローラーを許可するか拒否するか」というSEO/GEO上の判断と、「なりすましを検知して止める」というセキュリティ上の対処は別のレイヤーの話です。前者は選択、後者は必須という整理をしてください。

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

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

2026年8月12日ごろ、Hacker Newsに「Someone is running mass vulnerability scans, spoofing AI bots like ClaudeBot」という投稿が上がり、大きな議論になりました。内容は、ClaudeBot・Googlebot・GPTBot・ChatGPT-User・PerplexityBotなどのUser-Agentを詐称した、数千サイト規模の脆弱性スキャンキャンペーンの観測報告です。

現時点で確認できている観測内容は次の通りです。

ここでいう「なりすまし」の定義は、既知エージェントの名前を名乗っているが、そのエージェントの公式検証手段（公開IPリストの照合や署名検証）に失格した訪問です。比率としては1%未満に見えますが、正規のAIボットトラフィック（ClaudeBotは全ボットの約3.2%、Googlebotは約7.9%と計測されている）に紛れて到達する分、検知されにくいという性質があります。

なお、この一連の観測値はセキュリティベンダーの査読済みレポートではなく、一次観測者およびコミュニティによる報告です。攻撃主体が誰かも特定されていません。数字は目安として扱い、自サイトのログで実際に何が起きているかを確認するのが確実です。2026年8月15日時点で、Anthropicがこの事案について公式声明を出したという確認は取れていません。

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

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

今回のスキャンで最も特徴的なのは、AIコーディングツールが生成する設定ファイル・認証情報ファイルを狙い撃ちしている点です。従来の「WordPress管理画面を探す」タイプのスキャンとは目的が変わってきています。

報告されている探索対象パスは以下の通りです。

AIツール系の設定・認証情報

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

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

• /.aws/credentials
• /service-account.json
• /firebase-service-account.json
• /terraform.tfstate
• /rclone.conf

汎用的な環境変数ファイル

• /.env
• /.env.production
• /.env.local
• /.env.backup

これらのファイルは、APIキー・モデルのエンドポイント・そのツールに渡したトークンを保持していることが多く、1件当たれば横展開できる価値が高い、と指摘されています。加えて従来型のWordPress管理画面パスや各種 .php エンドポイントも並行して探索されています。

なぜ今このリストなのかは明確です。AIコーディングツールの導入が急速に進み、ハードニングが済んでいない環境が短期間に大量生産されたからです。ローカル開発用に作った設定ファイルが、そのままデプロイ物に混ざってWebルート配下に置かれてしまうケースは珍しくありません。攻撃者から見れば「新しく、雑に立っていて、鍵が置いてある」ターゲットが増えたことになります。

AIコーディングツール利用時の設定ファイル管理については「AIコーディングのセキュリティリスクと対策」と「Claude Codeのセキュリティと安全な使い方」でも整理しています。

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

理由は4つあり、いずれも運用側の善意の設定を逆手に取るという構造です。

1. 多くのサイトがAIクローラーを許可・ホワイトリスト化している

SEO/GEO（生成AI検索での露出最適化）の観点から、GooglebotやAI検索クローラーをWAFの例外リストに入れている運用は珍しくありません。攻撃者はその例外枠に潜り込もうとします。

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

「ClaudeBotが来ている」というログ行は、それ自体は正常に見えます。異常な単発プローブが通常のクロールに紛れることで、アラートの閾値に引っかかりにくくなります。

3. レート制限やBot対策が緩和されやすい

検索・AI経由の流入を失いたくないため、正規クローラー名に対しては甘い設定になりがちです。名前を借りるだけでレート制限を回避できるなら、攻撃者にとって費用対効果が高い手口になります。

4. 発信元がクラウドIPで、正規クローラーと帯域が重なる

公式IPリストの実データを見るとわかりますが、Anthropicの正規クローラーもGoogle CloudやAzureのIPを利用しています。攻撃者も同じクラウドを使っているため、「34.x だから本物」といった雑な判定は成立しません。

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

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

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

robots.txtは「このパスはクロールしないでください」というお願いであり、遵守はクローラー側の善意に依存します。サーバー側がアクセスを拒否する仕組みではありません。Known Agentsの計測では、ボット全体の約98.5%はrobots.txtを遵守しているとされますが、これは「行儀の良いボットが大多数」という話であって、悪意ある少数には無関係です。

理由2. なりすましは、そもそも遵守する動機がない

Anthropicの正規ボットはrobots.txtを尊重し、非標準拡張の Crawl-delay にも対応し、CAPTCHA等のアンチボット技術を回避しないと公式に明言しています。一方、ClaudeBotを名乗っているだけの攻撃者にはこの制約が一切かかりません。robots.txtに書かれた Disallow を守るのは本物だけで、偽物は無視します。

理由3. robots.txtが「隠したい場所の一覧」を公開してしまう

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

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

整理すると、robots.txtは「正規ボットの行儀を制御する道具」であって、「なりすましを止める道具」ではありません。 レイヤーが違うため、どれだけ丁寧に書いても対策になりません。なりすまし対策はWebサーバ・WAF・CDNのレイヤーで行う必要があります。

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

出典: Claude 公式サイト

現時点でClaudeBotの真偽を判定する公式手段は、送信元IPをAnthropicが公開しているIPプレフィックスリストと突き合わせることです。

判定は3ステップ

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

Anthropicの正規クローラーのUser-Agent文字列は、公式ヘルプセンターで次のように示されています（バージョン部は変動します）。

ただし、この文字列に一致していること自体は本物である証拠になりません。UA文字列はcurlのオプション1つで誰でも名乗れます。Known Agentsも「一致するログ行だけでは証拠にならない。どんなボットもClaudeBotを名乗れる」と明記しています。

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

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

{
  "creationTime": "2026-08-13T20:38:01Z",
  "prefixes": [
    { "ipv4Prefix": "216.73.216.0/22" },
    { "ipv4Prefix": "34.162.230.222/32" },
    { "ipv4Prefix": "34.150.241.79/32" },
    { "ipv4Prefix": "40.124.101.48/28" },
    { "ipv4Prefix": "20.102.46.224/28" }
  ]
}

2026年8月15日に取得した時点では、creationTime は 2026-08-13T20:38:01Z、プレフィックスは合計23件（/22 が1件、/32 が19件、/28 が3件）でした。中身はGoogle Cloud系（34.x / 35.x）とMicrosoft Azure系（20.x / 40.x）、および 216.73.216.0/22 の混在です。取得時点でIPv6プレフィックスは含まれていませんでした。

ここから読み取るべき実務上のポイントは3つです。

• クラウド帯という理由で本物と判定してはいけない。 攻撃者も同じGCP/Azureのレンジを使っているため、/32 単位・プレフィックス単位で厳密に一致させる必要があります
• creationTime は更新される。 手書きの許可リストにコピペして固定運用すると、いずれ正規クローラーを誤ってブロックします。定期取得して自動生成する仕組みにしてください
• 記事や他サイトに載っているIPを転記しない。 ここに載せた値も執筆時点のスナップショットです。運用に使うなら必ず自分で最新を取得してください

かつてAnthropicは「サービスプロバイダの公開IPを使っているため、IPレンジは公開していない」と記載していましたが、現在はIPリストを公開する方針に変わっています。「Anthropicはクローラー用IPを公開していない」と書いている解説記事はすでに古い情報なので注意してください。

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

Anthropicの開発者向けドキュメントには、別系統のIPアドレスが記載されています。これはClaude API / Console向けであり、クローラーの真偽判定には使えません。

クローラー検証は bots.json、APIやMCP経由のアクセス制御は 160.79.104.0/21 と用途を切り分けてください。ここを混同したまま許可リストを作ると、検証が機能しなくなります。なお開発者ドキュメントには廃止済みのIP（34.162.46.92/32 など）も明記されており、古い許可リストからは削除しておくべきです。

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

日本語の解説記事では「クローラーの真偽は逆引きDNS（rDNS）で確認する」と一律に書かれていることがありますが、これはGooglebotの手順であって、ClaudeBotには適用できません。2026年8月15日時点で、Anthropicがホスト名による検証手段を公式に提供しているという記載は確認できませんでした。

host コマンドでClaudeBotのIPを逆引きしてもホスト名が引けない、あるいはクラウド事業者の汎用ホスト名しか返らないのは、この理由によるものです。ClaudeBotの検証は bots.json 照合が正攻法です。

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

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

事業者ごとに公式の検証手段が異なります。「全部rDNSで確認する」「全部IPリストで確認する」といった統一運用はできません。

各JSONは2026年8月15日時点で到達を確認しています。特にOpenAIの chatgpt-user.json は creationTime が前日付（2026-08-14）になっており、IPリストは頻繁に更新されることがわかります。キャッシュしたまま放置する運用は、正規クローラーの誤ブロックを招きます。

実装上の目安としては、リスト取得を1日1回程度のcronで回し、取得失敗時は直前の内容を維持（フェイルオープン）する設計が無難です。取得できなかったからといって全ブロックにすると、AI検索経由の流入を丸ごと失う事故につながります。

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

対策は「露出を潰す」→「検証をルール化する」→「仕組みとして回す」の順に進めます。

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

• 自ドメインで認証情報ファイルの露出チェックを実行する。 200 が返るパスがあれば即座に非公開化する
• Webルート配下のドットファイル（.env .git .claude .aws .codex など）を物理的に外へ出す。 デプロイ物に含めない構成に変える
• 露出していた場合は、該当するAPIキー・トークン・クラウド認証情報をすべてローテーションする。 一度でも公開状態だったなら「漏洩したもの」として扱うのが原則です

優先度2：今週中

• ドットファイル・設定ファイルへのアクセスをWebサーバ層で一律に遮断する
  • Nginx: location ~ /\.(env|git|aws|claude|codex|ssh) { deny all; return 404; }
  • Apache: .htaccess の <FilesMatch> または RedirectMatch 404 /\..*$
• User-Agent名だけを条件にしたWAF例外・許可リストを廃止する。 「UA名 かつ 公式IPリストに一致」というAND条件に置き換える
• fail2ban や Nginx の limit_req で、認証情報系パスへのアクセスを即時BAN対象にする

優先度3：継続運用

• bots.json 系のIPリストをcronで定期取得し、許可リストを自動生成する。 手書きの許可リストは必ず陳腐化します
• CDN/Bot管理を使う場合は「検証済みは許可、未検証のAIボット名乗りはチャレンジまたはブロック」というポリシーにする
• ASNベースの制御を検討する。 ただしISP扱いのASNを巻き込むと一般ユーザーを遮断する副作用があるため、データセンター/VPS系ASNに限定して慎重に適用します
• 静的化できる部分は静的ホスティングに寄せ、攻撃面そのものを減らす

補足として、Anthropic公式はIPベースのブロックのみに依存することを推奨していません（robots.txtを正しく読み込めなくなる副作用があるため）。IPは「検証」に使い、「ブロック」の主手段にはしないという整理が実務上の落としどころです。

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

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"]]
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. Googlebotの場合（逆引き→正引きの二段確認）

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

逆引きで得たホスト名を正引きし直して元のIPに戻ることまで確認するのが必須です。逆引き結果だけを信じると偽装されます。

3. 狙われているパスが自サイトで露出していないかを確認する

for p in /.env /.env.production /.env.backup /.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 が返るものがあれば即対応

example.com の部分を自分のドメインに置き換えて実行してください。自分が管理していないドメインに対しては実行しないこと（第三者への無断スキャンになります）。

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

出典: Cloudflare 公式ブログ

IPリスト照合は現時点の現実解ですが、根本解決ではありません。IPは事業者の都合で増減し、クラウドIPは再利用されるため、照合方式には運用コストがつきまといます。

この問題の本命とされているのが、Web Bot Auth（RFC 9421のHTTP Message Signaturesをベースにした署名検証）です。エージェントがリクエストに Signature / Signature-Input / Signature-Agent の3ヘッダを付与し、受け側が公開鍵ディレクトリで検証する方式で、Ed25519鍵がサポートされています。IPに依存しないため、クラウドIPの変動や共用IPの問題を回避できます。

普及状況として、CloudflareはWeb Bot AuthをVerified Botsプログラムに統合しており、AWS WAFも2025年11月に対応を発表しています。

一方で、2026年8月時点で、AnthropicがClaudeBotのWeb Bot Auth対応を公式に文書化したという確認は取れていません。複数の調査系ソースが、Anthropic・Perplexity・Mistralは対応を文書化していないと指摘しています。したがって現時点のClaudeBot検証手段は公開IPリストの照合が主であり、署名検証は「今後の本命」という位置づけで捉えるのが妥当です。

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

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

また、Cloudflareの2026年5月のレポートでは、GPTBotを名乗るトラフィックの31%が実際には無関係なスクレイピング基盤によるUA詐称だったと推計された、とも報じられています（この数値は二次情報経由のため、参考値として扱ってください）。

いずれにせよ、User-Agentという文字列そのものを信頼のベースにする運用は、すでに成立していないという点が共通の教訓です。AIエージェント全般のアクセス制御の考え方は「AIエージェントのセキュリティ対策」で整理しています。

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

今すぐ確認すべき方

• Claude Code・Codex・Aiderなどを社内導入している開発チーム。 .claude/settings.json や .codex/config.toml が明示的に探索対象になっているため、リポジトリとデプロイ物の両方を確認してください
• VPSやクラウド上で自前運用しているWebサーバがある方。 ドットファイルの遮断がデフォルトで効いていないケースが多くあります
• SEO/GEO目的でAIクローラーをWAF例外に入れている方。 UA名だけの例外条件になっていないかを最優先で点検してください
• .env をWebルート配下に置いた経験がある、または過去に置いていたか記憶が曖昧な方。 露出＝漏洩とみなして鍵をローテーションするのが安全側の判断です
• WordPressや各種CMSを運用している方。 従来型の管理画面探索も並行して行われています

慌てなくてよい方

• 完全な静的サイト（GitHub Pages・Netlify等でビルド済みHTMLのみ配信）を運用している方。 そもそも認証情報ファイルがサーバ上に存在せず、ビルド時のシークレットもホスティング側の環境変数管理下にあるなら、直接的なリスクは限定的です
• Cloudflareなどでボット検証を有効化済みで、未検証のAIボット名乗りをチャレンジ対象にしている方
• Claudeやその他の生成AIを「使うだけ」で、自分でWebサーバを運用していない方。 今回の事案はサイト運営側の話であり、Claudeの利用そのものにリスクが生じるものではありません

ただし静的サイトでも、ビルド成果物に .env や .map ファイルが混入していないかの確認は一度やっておく価値があります。

よくある質問（FAQ）

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

本物なら止まりますが、なりすましなら止まりません。 まず送信元IPを bots.json と照合し、本物か偽物かを切り分けてください。本物のクロール量が多くて負荷になっている場合は、robots.txtの Crawl-delay が有効です（Anthropicの正規ボットは非標準拡張の Crawl-delay に対応すると公式に明言しています）。偽物であればWebサーバ層かWAF層での遮断が必要です。

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

ボットごとに役割が違うため、一律ブロックする必要はありません。学習用データ収集の ClaudeBot だけを拒否し、ユーザーがURLを渡したときに取得する Claude-User や検索インデックス用の Claude-SearchBot は許可する、といった粒度の指定が可能です。学習利用は避けたいが引用や検索露出は残したい、という場合はこの分け方が現実的です。

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

「安心」にはなりません。許可リストは検証のための参照データであり、それ自体が防御ではありません。加えて creationTime が更新されるため、コピペで固定した許可リストは時間とともに正規クローラーの誤ブロックを引き起こします。定期取得して自動反映する仕組みにしてください。

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

入れ替えるべきです。 スキャンは自動化されており、公開されていた時間が短くても取得されている可能性は排除できません。「アクセスログに取得された形跡がない」ことは、取得されていない証明にはなりません（別経路のキャッシュやアーカイブに残る場合もあります）。露出＝漏洩として、APIキー・クラウド認証情報・データベース接続情報をすべてローテーションしてください。

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

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

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

WordPress固有の対応としては、wp-config.php のWebルート外配置、XML-RPCの無効化（使っていない場合）、readme.html や license.txt などバージョンが推測できるファイルの削除、管理画面へのIP制限またはBasic認証が効果的です。加えて、テーマやプラグインのディレクトリに開発時の .env やバックアップファイルが残っていないかを確認してください。

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

基本的な対応は可能です。無料プランでもファイアウォールルール（WAFカスタムルール）で、特定のパスパターンへのアクセスをブロックしたり、Known Botsの検証結果を条件に使ったりできます。ただし詳細なBot管理機能は上位プランの機能になるため、無料プランでは「認証情報系パスへのアクセスを一律ブロック」というシンプルなルールを軸に組むのが現実的です。

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

日本国内で本事案に関する公的な注意喚起（IPA・JPCERT等）は2026年8月15日時点で確認できていません。実害（不正アクセス成功や情報漏洩）が確認された場合は、所轄警察・JPCERT/CCへの相談、および個人情報が関わる場合は個人情報保護委員会への報告義務の確認が必要です。単なるスキャン検知の段階であれば、ログを保全したうえで自社の防御を固めることを優先してください。

まとめ

• ログの ClaudeBot は、User-Agentが一致しているだけでは本物の証拠にならない
• 2026年7月末以降、AIクローラーを詐称して .env や .claude/settings.json などの認証情報ファイルを探すスキャンが観測されている（コミュニティ報告ベース）
• robots.txtでは防げない。 強制力がなく、なりすましには無関係で、むしろ隠したい場所を晒す副作用がある
• 判定手段は https://claude.com/crawling/bots.json との送信元IP照合。ClaudeBotは逆引きDNSでは検証できない
• クローラー用IP（bots.json）とAPI用IP（160.79.104.0/21）は別物。混同しない
• IPリストは更新されるため、定期取得して自動反映する。手書き固定は誤ブロックの原因になる
• 最優先は自サイトの露出チェックと、露出していた場合の鍵ローテーション

「AIクローラーを許可するか拒否するか」はSEO/GEO上の選択ですが、「なりすましを検知できる状態にしておくこと」はすべてのサイト運営者にとって必須の備えです。まずは自ドメインへの露出チェックを実行してください。

関連記事

• AIコーディングツール利用時の設定ファイル・認証情報の扱いは「AIコーディングのセキュリティリスクと対策」
• Claude Codeを安全に運用する設定は「Claude Codeのセキュリティと安全な使い方」
• AIエージェント全般のアクセス制御・権限設計は「AIエージェントのセキュリティ対策」
• 生成AI利用全体のリスクを俯瞰したい方は「生成AIのセキュリティリスクと対策」
• 公開インスタンスがスキャンで狙われた同型の事案は「Flowise RCE脆弱性（CVE-2025-59528）まとめ」
• Codex利用環境のセキュリティ設定は「Codex Securityとは」
• Anthropicのセキュリティ機能全般は「Claude Securityとは」
• AI検索エンジンとクローラーの関係を知りたい方は「AI検索エンジン比較」