AIスクレイパーを実際にブロックするrobots.txtの書き方

robots.txtについての気まずい真実

robots.txt ファイルは鍵ではありません。ドアに貼られた表示です。

チームが小さなテキストファイルひとつで「AIスクレイパーをブロック」できるかを尋ねるとき、この違いは重要です。Robots Exclusion Protocolに従う信頼できるクローラーであれば、答えは「はい」です。正しく書かれた robots.txt は、ページをクロールしないよう伝えることができます。未知のスクレイパー、なりすまし、ブラウザー自動化、そして単に気にしないボットに対しては、それだけでは何の効果もありません。

したがって実務上の目標は「スクレイピングを不可能にする」ことではありません。目標は次のとおりです。

• 準拠するAIクローラーに、自サイトを使わないよう伝える。
• 検索エンジンや有用なサービスを誤ってブロックしない。
• 悪用に対して、より強いサーバー側制御を追加する。
• クローラー名が変わっても、ポリシーを保守しやすく保つ。

これは退屈な説明です。しかし、実際に機能する説明でもあります。

robots.txtでできること、できないこと

robots.txt ファイルはサイトのルートに置かれます。

https://example.com/robots.txt

クローラーはクロール前にこれをリクエストします。ファイルにはルールのグループが含まれます。各グループは1つ以上の User-agent 行で始まり、その後に Allow または Disallow ディレクティブが続きます。

サイト全体をブロックする簡単な例は次のとおりです。

User-agent: GPTBot
Disallow: /

これは「あなたが GPTBot なら、このサイトのどこもクロールしないでください」という意味です。

ただしrobots.txtには明確な限界があります。

1. 任意の仕組みです。悪意ある行為者は無視できます。
2. 通常のブラウザーやスクリプトによるURLリクエストを防ぎません。
3. すでに他所で収集されたコンテンツを削除しません。
4. それ自体では著作権、ライセンス、学習利用の権利を定義しません。
5. 設定ミスにより、誤ったボットをブロックすることがあります。

本当のアクセス制御が必要なら、認証、認可、レート制限、IPベースの制御、ボット管理、法的な制御を使ってください。Robots.txtは今でも有用ですが、より広いコンテンツ保護戦略の一部として位置づけるべきものです。

これは他のWebガバナンス上の問題にも似ています。目に見える制御が、制御のすべてであることはめったにありません。組織内ですでに管理されていないAI利用があるなら、同じ原則が当てはまります。単一のポリシー文書で問題が解決すると考えるより、簡単な シャドーAI監査 のほうが有用なことがよくあります。

まずポリシー判断から始める

ファイルを編集する前に、実際に何をブロックしたいのかを決めてください。

「AIスクレイパー」と言うとき、人々が意味しているものは少なくとも4種類あります。

• 学習データ収集に使われるクローラー。
• AI検索または回答エンジンのクローラー。
• ユーザー起点の取得ツール。たとえば、誰かがAI製品にURLの要約を依頼した場合など。
• 通常のブラウザーを装う汎用スクレイパー。

これらすべてをブロックしたい場合もあるでしょう。あるいは、検索での発見性は維持しつつ、モデル学習からはオプトアウトしたい場合もあります。これらは同じポリシーではありません。

たとえばOpenAIは、GPTBot、ChatGPT-User、OAI-SearchBot など、目的別に異なるユーザーエージェントを文書化しています。Googleは一部のGeminiおよびVertex AIのユースケース向けの制御トークンとして Google-Extended を使用し、通常のGoogle Searchクロールは他のGooglebotユーザーエージェントによって処理されます。

この分離は重要です。広範なユーザーエージェントを不用意にブロックすると、AI学習をブロックしようとして、通常の検索での可視性を損なう可能性があります。

AIブロック用robots.txtの妥当なテンプレート

一般的な検索クローラーはそのままにしつつ、一般に文書化されている複数のAI関連クローラーをブロックするための保守的な出発点は次のとおりです。

# AI training and AI product crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# Default rule for other crawlers
User-agent: *
Allow: /

これは魔法のような万能リストではありません。保守しやすいパターンです。

いくつか注意点があります。

• Disallow: / は「どのパスもクロールしないでください」という意味です。
• User-agent: * は、より具体的なグループに一致しないクローラーに適用されます。
• Allow: / はデフォルトグループに厳密には必須ではありませんが、意図を明確にできます。
• コメントは短く保ってください。寛容なパーサーもありますが、robots.txtは退屈なままにしておくべきです。
• robots.txtに非公開URLを含めないでください。このファイルは公開されており、機密パスを列挙すると、それらを知らせることになります。

最後の点は繰り返す価値があります。Robots.txtは秘匿の仕組みではありません。/client-contracts/ を公開すべきでないなら、認証で保護してください。単にdisallowするだけでは不十分です。

Google-Extendedには注意する

Google-Extended は広く誤解されています。これはGoogle Searchをブロックすることと同じではありません。

Googleのドキュメントによると、Google-Extended は、サイトのコンテンツが特定のGeminiおよびVertex AI機能の改善に役立てられるかどうかをパブリッシャーが管理するための独立したプロダクトトークンです。これをブロックしても、それ自体でSearch用のGooglebotのクロールがブロックされるべきではありません。

とはいえ、本当にそうする意図がない限り、すべてのGoogleディレクティブを次のような広範なブロックに置き換えないでください。

User-agent: Googlebot
Disallow: /

これはGoogle Searchの主要クローラーに対して、サイトをクロールしないよう伝えることになります。ほとんどの公開Webサイトにとって、それは望ましいことではありません。

同じ区別は他の場所にも当てはまります。ベンダーによっては、学習用クローラーをユーザー起点のブラウジングやAI検索クローラーから分けています。分けていないベンダーもあります。重視するボットについてはドキュメントを読み、robots.txt を一度限りのチェックボックスではなく、生きたファイルとして扱う必要があります。

本番コードのようにファイルをテストする

Robots.txtは単純に見えます。だからこそ壊しやすいのです。

よくあるミスには次のようなものがあります。

• /robots.txt ではなく /assets/robots.txt など、間違った場所にアップロードする。
• ドキュメントエディターからコピーしたスマートクォートを使う。
• 誤って User-agent: * と Disallow: / で全クローラーをブロックする。
• あるドメインのファイルが別のサブドメインにも適用されると考える。
• 設定によっては、http://、https://、www、非wwwホストが別々に扱われる可能性を忘れる。

マルチドメインサイトでは、すべての正規ホストを確認してください。https://www.example.com/robots.txt にあるrobotsファイルが、https://app.example.com/robots.txt を自動的に管理するわけではありません。

デバッグするときは、CMSのプレビューに表示されるものだけでなく、実際のHTTPレスポンスを確認してください。望ましいのは、200 OK レスポンス、可能であれば text/plain のコンテンツタイプ、そして期待どおりの正確なファイルです。リダイレクト、キャッシュ、CDNルールが関係する場合は、生のヘッダー確認が役立ちます。本番環境でリダイレクトとHTTPヘッダーをデバッグする で説明したワークフローは、ここでもそのまま使えます。

ルールを無視するボットにはサーバー側制御を追加する

クローラーが準拠しているなら、robots.txtが最もきれいなシグナルです。クローラーが悪質なら、強制力が必要です。

実践的な制御には次のものがあります。

レート制限

異常なリクエストパターンにしきい値を設定します。1分あたりのページ数が多すぎる、深いページネーションをたどる、404を繰り返す、少数のIPから大量のリクエストが来る、といったパターンです。レート制限は、実際のユーザーを不当に罰しない程度に寛容でありつつ、大量抽出を高コストにする程度に厳しくあるべきです。

ユーザーエージェントのフィルタリング

文書化されたAIクローラーのユーザーエージェントは、Webサーバー、リバースプロキシ、CDN、またはアプリケーション層でブロックできます。これは実際の拒否レスポンスを返すため、robots.txtより強力です。

たとえばNginxではユーザーエージェントのパターンをブロックできます。ただし本番ルールは慎重にテストすべきです。

if ($http_user_agent ~* "GPTBot|CCBot|ClaudeBot|Bytespider") {
    return 403;
}

これは完全ではありません。ユーザーエージェント文字列は簡単に偽装できます。それでも、正直なトラフィックや怠惰なトラフィックを止め、負荷を減らせます。

IPとASNの制御

IPレンジを公開している運営者もいますが、多くのスクレイパーエコシステムは公開していません。IPベースのブロックは、特に通常のユーザートラフィックがないクラウドホスティング範囲からの明らかな悪用に対して有効なことがあります。ただし、誤検知も生みます。ルールより先にログを使ってください。

認証とペイウォール

コンテンツを大規模にコピーされたくないなら、完全なコンテンツを公開URLに置かないでください。Robots.txtは、機密資料、ライセンスされたデータベース、非公開コミュニティ、有料アーカイブには適していません。

コンテンツの最小化

最良の保護がアーキテクチャであることもあります。公開ページに小さなサブセットだけが必要なら、不要なAPI、大きなJSONペイロード、隠しメタデータ、ドラフト用エンドポイント、完全なアーカイブを公開しないでください。画像中心のサイトでは、公開しているメタデータについても考えるべきです。オンラインで写真を共有する前にEXIFメタデータを削除する で述べたプライバシーの考え方は、コンテンツ運用にも当てはまります。

ページ単位のルールにはrobots metaタグを使う

Robots.txtはクロールを制御します。Robots metaタグと X-Robots-Tag ヘッダーは、準拠する検索エンジンやクローラーに対して、インデックス登録やスニペットの挙動を制御します。

たとえば次のようにします。

<meta name="robots" content="noindex, noarchive">

またはHTTPヘッダーとして次のようにします。

X-Robots-Tag: noindex, noarchive

これらはAI専用の盾ではありません。ページにはアクセス可能にしたいがインデックスはさせたくない場合に有用です。ただし、robots.txtでクローラーがページ取得をブロックされている場合、そのクローラーはページ単位のmetaタグを見ない可能性があります。クロールを禁止しているURL上の noindex タグに依存しないでください。

大まかなルールは次のとおりです。

• robots.txtはクロールを減らす、または防ぐために使う。
• meta robotsまたは X-Robots-Tag はインデックス挙動を制御するために使う。
• サーバー側制御はアクセスを強制するために使う。

公開後にログを監視する

ファイルを公開することは第一歩にすぎません。その後、ログを確認してください。

見るべきものは次のとおりです。

• 指定したユーザーエージェントからの /robots.txt へのリクエスト。
• disallowルールが配信された後も続くクロール。
• 高いボリュームの不審なユーザーエージェント。
• 何千ページも連続してリクエストするブラウザー風のユーザーエージェント。
• フィード、サイトマップ、検索ページ、ページネーションへの繰り返しアクセス。

ボットが robots.txt をリクエストし、全面的なdisallowを見て停止したなら、robots.txtは役割を果たしています。続けるなら、そのボットを強制対象に移してください。レート制限、ブロック、または認証です。

サイトマップの露出も見直してください。サイトマップは検索エンジンにとって有用ですが、スクレイパーにとっても便利な地図です。だからといって通常のサイトから削除すべきという意味ではありません。公開システムに発見されたくないURLを含めるべきではない、という意味です。

ファイルを小さく保ち、レビューする

Robots.txtは劣化しがちです。マーケティングチームがキャンペーン用マイクロサイトを追加する。開発者がステージング用パスを追加する。ベンダーがクローラー名を変更する。2年後には、ルールの半分がなぜ存在するのか誰も分からなくなります。

設定として扱ってください。

• 可能であればバージョン管理に保存する。
• 各AIクローラーグループに短いコメントを追加する。
• 四半期ごとにレビューする。
• 広範なルールを追加する前に、ベンダーのドキュメントを確認する。
• CDN、CMS、ホスティングの変更後にテストする。

サイトがAI支援コンテンツを公開している場合は、クローラーポリシーと編集上の透明性も分けて考えてください。AIスクレイパーのブロックは、アクセスと再利用に関するものです。開示は読者の信頼に関するものです。倫理的には重なりますが、同じ制御ではありません。実践的な開示の考え方は、小規模Webサイトにおける誠実なAI開示のあり方 で扱っています。

<!-- tool-cta:start -->

💡 お試しください: AIクローラー向けのルールを追加したら、正当なボットまで誤ってブロックしないように、Robots.txt Testerで構文を確認してください。

<!-- tool-cta:end -->

結論

優れた robots.txt ファイルは、準拠するAIクローラーをブロックします。しかし、意図的なスクレイピング、コピーされたユーザーエージェント文字列、侵害されたブラウザー、または人が手動でコンテンツをAIシステムに貼り付ける行為は止められません。

だからといって無用ではありません。ひとつのレイヤーだということです。

文書化されたAIクローラーに対して明示的なルールを書いてください。検索での可視性を損なう広範なブロックは避けてください。下書きではなく、配信されているファイルをテストしてください。ログを確認してください。望ましくない挙動が悪用の領域に入った場所では、サーバー側制御で強制してください。

Webは常に、プロトコル、規範、強制力の組み合わせで動いてきました。Robots.txtは規範のレイヤーです。使ってください。ただし、壁だと誤解しないでください。