AIクローラーをブロックするツールと方法の比較
AIクローラーをブロックする方法を、robots.txt、CDNやWAFの設定、サーバーのルール、WordPressのプラグインで比較します。ポリシーの確認と、名乗っている身元の確認の方法も解説します。
AIクローラーをブロックするツールは、どこでアクセスを制御できるかで選びます。無料で、従うかどうかを相手に任せる「お願い」を出すならrobots.txt、ネットワークの入り口で止めるならCDNやWAFのボット対策、サーバーを管理しているならnginxやApacheのルールです。 WordPressのプラグインは、仕組みによってポリシーを書くだけのものと、リクエストを拒否するものがあります。SearchSealの無料のrobots.txtのAIクローラーチェッカーとAIクローラーのユーザーエージェント判定は、結果を確認するための道具で、アクセスそのものはブロックしません。
実際にブロックできる方法はどれか
| 方法 | HTTPでアクセスを拒否できるか | 手間 | なりすましへの弱さ |
|---|---|---|---|
| robots.txt | できない。従うかどうかは相手次第のお願い | 配信するファイルを管理できれば少ない | 相手はポリシーを無視できる |
| CDNやWAFのボット対策 | できる。ルールに一致したリクエストが対象 | 設定と見直しに中程度の手間 | 認識されない、または誤って分類されたアクセスはルールをすり抜ける |
| nginxやApacheのユーザーエージェントのルール | できる。サーバーに届いた一致するリクエストが対象 | サーバーへのアクセス権と設定の見直しが必要 | 相手はユーザーエージェントを変えられる |
| WordPressのプラグイン | ポリシーを書くだけか、実際に拒否するかで変わる | 導入に加えて、キャッシュと互換性の確認が必要 | 名前（トークン）での判定はなりすましができる。キャッシュされた応答はアプリケーションの処理を通らないことがある |
| SearchSealのチェッカー | できない。確認のための道具 | 少ない。ドメインか、ログのユーザーエージェントがあれば使える | トークンを調べても、相手の身元の証明にはならない |
どれか1つが常に正解というわけではありません。制限したい動きと、自社で管理できる仕組みに合った方法を選びます。ボット全体に関わる設定を変える前に、目的が「方針を公開すること」なのか、「自動のアクセスを減らすこと」なのか、「非公開の情報を守ること」なのかを書き出しておきましょう。
robots.txtで十分なのはどんなときか
協力的なクローラーに自社の方針を伝えたいだけなら、robots.txtで十分です。robots.txtはお願いであり、強制力はありません。Robots Exclusion Protocolも、robots.txtはアクセスを許可する仕組みではないと明記しています。ファイルを無視するクライアントは、公開ページを取得できてしまいます。
書き方の例は次のとおりです。公開する前に、ExampleBotを運営者が公開している実際のクローラーのトークンに置き換えてください。
User-agent: ExampleBot
Disallow: /
ファイルは正しいホスト名から配信し、実際の応答を確認します。ドキュメント用のサブドメインなどは、メインのサイトと別の方針になっていることがあります。ワイルドカードの指定がすべてに優先すると思い込まず、すでにある名前つきのグループとパスのルールを先に確認しましょう。
指定したトークンとパスのルールは、robots.txtのAIクローラーチェッカーで確認できます。方針とアクセス制御の違いは、robots.txtの書き方のガイドで解説しています。機密の情報をrobots.txtで守ろうとしてはいけません。内容に合った認証や権限の管理を使いましょう。
CDNやWAFの設定を使うべきときはいつか
一致するリクエストを、アプリケーションに届く前に止めたい場合は、ネットワークの入り口（エッジ）での制御を使います。Cloudflareのドキュメントによると、AIのボットのポリシーは、Search（検索）、Agent（エージェント）、Training（学習）などの動きの種類を区別しています。使える設定と、その対象の範囲は、自社のゾーンで確認してください。
検索での発見、ユーザーの依頼による取得、学習への利用について、それぞれ意識して決めましょう。広い設定は、特に複数の目的を持つクローラーの場合、制限したかった以上の動きに影響することがあります。昔のトグルの名前が今の動きをそのまま表していると考えず、現在のポリシーの説明を読みましょう。
ルールを有効にしたら、セキュリティのイベントを確認します。一致した身元、パス、処理、応答を確かめ、通したい訪問者や、許可している自動のサービスが引き続き使えることも確認します。エッジでの制御が効くのは、そのエッジを通るアクセスだけです。オリジンのサーバーに別の経路で届く場合は、そちらのアクセスも別に見直す必要があります。
nginxやApacheのルールが向いているのはいつか
サーバーのルールは、Webサーバーを管理していて、決めた条件に一致するリクエストを拒否したいチームに向いています。nginxでは、ユーザーエージェントのパターンをブロックの判定に対応づけられます。Apacheにも、リクエストの条件によるアクセス制御の仕組みがあります。導入しているサーバーに合った書き方と設定の場所を使いましょう。
nginxのmapモジュールのドキュメントとApacheのアクセス制御のドキュメントが示すとおり、これらはリクエストの処理を設定するための道具です。コピーされたユーザーエージェントの文字列が、本当にその組織のものかを確かめる機能ではありません。
トークンのリストは必要な範囲にしぼり、再読み込みの前に設定を見直します。そのうえで、一致するリクエストと、ふつうのブラウザからのリクエストの両方で応答を確認しましょう。なりすましたトークンが拒否されても、分かるのはルールが一致することだけで、身元を隠すクライアントを防げる証明にはなりません。信頼できる身元の情報があれば使い、一致しない自動のアクセスは「不明」として分けておきます。
WordPressのプラグインで確認すること
プラグインが、robots.txtを書き換えるのか、サーバーの設定を追加するのか、アプリケーションのコードで一致するリクエストを拒否するのかを確認します。仕組みによって、対象になる範囲が違います。Disallowの行を書くだけのプラグインは、方針を公開するだけで、HTTPでのアクセスの拒否はしません。
キャッシュやホスティングの環境との互換性も確認します。WordPressが動く前にページが配信される場合、アプリケーションのルールはそのリクエストを見られません。同じように、実際に置かれたrobots.txtのファイルや、ホスティング会社が管理するrobots.txtが、アプリケーションの中で作られた方針より優先されることもあります。設定画面を信じるのではなく、実際に配信された結果を確認しましょう。
プラグインは更新を続け、権限とルールのリストも見直します。同じ方針を管理しようとする複数のプラグインを重ねて入れるのは避けましょう。更新のあとは、少数のリクエストを確認し直して、ルールや配信の経路の変化で、意図した動きが知らないうちに変わっていないかを確かめます。
SearchSealの無料のチェッカーで確認できること
robots.txtのAIクローラーチェッカーは、公開されているrobots.txtを読み、対応しているクローラーと制御トークンについて、選んだパスの結果を判定します。結果は許可・拒否・指定なしで表示し、可能な場合は一致したルールも示します。「指定なし」は、明示的に拒否するルールがあるという意味ではありません。
AIクローラーのユーザーエージェント判定は、ログから貼り付けたユーザーエージェントの文字列から、対応しているトークンを見つけ、身元の確認方法の案内を示します。そのクライアントが本当にその身元のものかを証明したり、非公開のログを調べたり、ファイアウォールがリクエストを拒否したかを確かめたりするものではありません。
この2つは、信頼できるリクエストの記録とあわせて使います。公開している指示を確認し、名乗っている相手を読み取り、実際の応答を確かめるという流れです。SearchSealのAI回答のトラッキングは、こうしたアクセスの診断とは別の機能です。クローラーのアクセスの結果はサーバーやエッジのログで、人の訪問はアクセス解析で確認しましょう。
ブロックの変更をどう確認するか
変更前のルール、変更した時刻、対象のホスト名、パス、対象にしたいクローラーの種類を記録します。変更のあとに、配信されているrobots.txtを開き直し、エッジやサーバーの応答を確認します。成功、拒否、チャレンジのリクエストは分けて数え、合計の数字だけで想定外の結果が見えなくならないようにしましょう。
ユーザーエージェントを指定して自分でリクエストを送れば、単純な文字列の一致は確認できます。ただし、別のネットワークから来る本物のクローラーの動きまでは確かめられません。可能であれば、そのあとに届いた本物のリクエストを確認します。設定は元に戻せる形で残し、クローラーの役割や自社の公開の方針が変わったら見直しましょう。
よくある質問
robots.txtでクローラーがページを開くのを止められますか？
協力的なクローラーに、一致するパスをクロールしないようお願いするものです。HTTPでアクセスを拒否する仕組みではなく、方針を無視する相手から機密の情報を守ることもできません。
ユーザーエージェントのルールで、すべてのAIクローラーをブロックできますか？
できません。設定した文字列に一致するリクエストは拒否できますが、相手はその名前を変えたり、名乗らなかったりできます。信頼できる身元の情報があれば確認し、不明な自動のアクセスは別に確認してください。
WordPressのブロック用プラグインは、アクセスを制御しますか？
仕組みによります。robots.txtを編集するだけのものは方針を公開するだけで、サーバーやアプリケーションのルールを使うものは一致するリクエストを拒否できる場合があります。実際にどの層がリクエストを処理するかは、キャッシュとホスティングの環境で決まります。
SearchSealのクローラーのチェッカーは、ボットをブロックしますか？
ブロックしません。無料のツールは、公開されているrobots.txtのルールを確認し、対応しているユーザーエージェントのトークンを見つけるものです。実際のブロックはエッジ、サーバー、アプリケーションで行い、リクエストの結果はログで確認する必要があります。