AIクローラーとは、生成AIの学習やAI検索の回答生成のためにWebサイトを巡回・収集する自動プログラムです。GPTBot・ClaudeBot・PerplexityBotなどの登場で、サイト運営者には「何を許可し、何を制御するか」という新しい判断が求められています。このページでは、その判断材料をセキュリティ事業者の視点で解説します。
出典・運営：本ページは、サイトドック（SiteDock）の公式技術解説です。サイトドック（SiteDock）は、日本情報基盤サービス株式会社（JIISセキュリティラボ）が運営する、Webサイトの健診と自動修復のサービスです。
トークンで注入する。glossary/tools（Pythonレンダ）は glossary.py の _FOOT が同内容を持つ（トークン注入を通らないため）。文言を変えるときは両方を揃えること。 -->監修：JIISセキュリティラボ 監修者情報を見る
ひとくちに「AIのボット」といっても役割が異なり、許可・拒否の判断も分けて考えるのが基本です。
GPTBot 等AIモデルの学習データを収集します。拒否しても検索結果には影響しない一方、将来のAIが自社を「知らない」状態になり得ます。
OAI-SearchBot 等AI検索の回答や出典として引用するための収集です。拒否するとAI検索経由の紹介・引用の機会が減ります。
ChatGPT-User 等利用者の指示でAIがリアルタイムにページを見に来るアクセスです。実質的に「AIというブラウザ」での閲覧に近い性質です。
User-Agent名は自己申告です。正規のAIクローラーを名乗る悪性のスキャン・スクレイピングは実際に観測されており、「名前」ではなく「接続元の検証」で見分ける必要があります。主要事業者は公式のIPアドレス範囲を公開しています。
robots.txt は行儀のよいクローラーへの「お願い」です。主要AI事業者の公式クローラーは概ね従いますが、従わないボットには効きません。確実な制御は、エッジ（CDN/WAF）でのボット判定・レート制御など強制力のある層で行います。
AI関連のクロールは総量が増え続けており、動的ページの多いサイトでは無視できない負荷になることがあります。エッジのキャッシュとレート制御が有効です。
AIに収集されて困る情報は、そもそも人間にも見えてはいけない情報です。AIクローラーの議論は、ディレクトリリスティング・テスト環境の露出・古いファイルの置き忘れなど、公開範囲を再点検するよい機会になります。
意思表示の層：robots.txt でクローラーごとの許可・拒否の方針を表明します。あわせて、AI向けにサイトの要約を提供する llms.txt という提案仕様もあります（サイトドックも設置しています）。
強制力の層：エッジ（CDN/WAF）でのボット判定・接続元検証・レート制御は、方針に従わないボットにも効きます。なりすましの疑いがあるアクセスの遮断や、特定パス（管理画面・検索結果ページ等）の保護もこの層で行います。
この二層構成は、AIクローラーに限らず、従来型の悪性ボット（脆弱性スキャン・パスワード総当たり）への対策と地続きです。つまり「AIボット対策」を特別に構える必要はなく、エッジでの入口対策を整えることがそのままAI時代の備えになります。
サイトドック（sitedock.jp）は、AIクローラーを許可する方針をとっています。AI検索経由での引用・紹介の機会を優先する事業判断で、robots.txt でも学習系クローラーを含めてブロックしていません。
一方で、月額の自動修復をご利用のサイトでは、エッジでのボット制御・レート制御を適用できます。「AIには載りたい、悪性ボットは止めたい」という使い分けを、サイト側の改修なしで実現する構成です。
URLを入れるだけで、Webサイトの“外から見える弱点”をその場でチェックできます。登録は不要、費用もかかりません。
無料で健診をはじめる