良いボットと悪いボット：遮断前に分類する

1つのIPが10分間に600ページをリクエストします。価格スクレイパーなら止めたいでしょう。新しいサイトマップを発見したGooglebotなら、遮断によって数千商品の処理が遅れる可能性があります。同じように「速い」行動に見えても、運用判断は正反対です。

良いボットと悪いボットは、ユーザーエージェント、速度、JavaScriptの実行有無だけでは区別できません。誰なのか、何をしているのか、システムにどのような影響を与えるのか、という3つの問いに答える必要があります。

良いボット、悪いボット、正体不明のボットとは？

良いボット

良いボットは、サイトが認めている目的や、サイトに利益をもたらす目的で動作します。

• 検索エンジンのクローラー。
• 自社で設定したリンク、稼働状況、セキュリティの確認ボット。
• SNSで共有する際のプレビュー生成ツール。
• 許可されたアクセシビリティやアーカイブのサービス。
• 合意に基づいて利用する提携先のAPIクライアント。

良いボットだからといって、無制限に許可するわけではありません。Googlebotは自動クロール時にrobotsのルールに従います。自社の監視にも、エンドポイントと頻度の制限を設けるべきです。

悪いボット

悪いボットは、損害を与えたり、意図に反するアクセスを行ったりします。

• 広告をクリックして予算を浪費させます。
• 価格、コンテンツ、顧客データを収集します。
• パスワードの推測やクレデンシャルスタッフィングを行います。
• アカウント作成、フォームスパム、在庫の取り置きを行います。
• 脆弱性をスキャンします。
• 偽のトラフィックで分析をゆがめます。

正体不明のボット

最も大きい分類です。SEOツール、モバイルアプリ、ヘッドレスブラウザ、テスト用プロキシ、新しいAIサービスなどによる自動化が含まれます。即座に遮断すれば連携が壊れる可能性があり、無条件で許可すればリスクが高まります。

この分類には、白黒を即断するより、レート制限を適用してさらに観察する方が適している場合が多いです。

ユーザーエージェントは身分証明書ではありません

リクエストに次のように記載されていても、

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Googleから来たことの証明にはなりません。どのようなスクリプトでも、この文字列をコピーできます。

Googleは、次の2つの検証方法を推奨しています。

1. 逆引きDNSがGoogle所有の有効なホスト名を返し、正引きDNSが同じIPに戻ることを確認します。
2. 送信元IPをGoogleが公開するクローラーの範囲と照合します。

ユーザーエージェントだけで許可リストを作ると、なりすましボットを通してしまいます。ユーザーエージェントだけで遮断しても、ブラウザの名前に変えたボットを見逃す可能性があります。

ボットを分類するためのシグナル表

完璧な単一のシグナルはありません。複数の層を組み合わせてください。

良いクローラーは高速でも、身元を検証でき、robotsを読み、公開コンテンツを中心に巡回します。スクレイパーはChromeを装っても、アセットを無視し、IPを頻繁に変え、商品ページだけを取得することがあります。

不審な行動の6つのパターン

1. 頻度が高く、ユーザーらしいリズムがない

200msの等間隔で数百回クリックするのは、人間ではまれです。ただし、正当なクローラーも高頻度で動作するため、IPと対象URLを併せて判断する必要があります。

2. 事業上の価値が高いエンドポイントだけを呼び出す

?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

3. フィンガープリントとユーザーエージェントが矛盾する

ユーザーエージェントはiPhoneのSafariを名乗っているのに、TLS、ヘッダーの順序、ビューポートがデスクトップのヘッドレスChromiumに似ている場合です。ユーザーエージェントの文字列そのものより、この矛盾の方が注目すべき点です。

4. IPは変わるが、端末の痕跡が変わらない

住宅回線プロキシを使えば、ボットはIPを切り替えられます。Cookie、フィンガープリント、行動、対象が繰り返されるなら、IPを1つずつ遮断しても終わりのない追いかけ合いになります。

5. 付随リソースを読み込まない

通常、人間のブラウザは必要なCSS、JavaScript、フォント、画像を読み込みます。単純なスクレイパーはHTMLやAPIだけを取得します。ただし、キャッシュやプライバシーツールでパターンが変わるため、絶対的な証拠ではありません。

6. 失敗後、リストに沿って再試行する

ユーザー名、クーポン、カード番号、管理用パスが順番に大量試行されるのは、自動化の兆候です。ボットが分散している場合、IP単位のレート制限だけでは不十分で、アカウント、フィンガープリント、操作単位での制御が必要です。

単純すぎるルールで良いボットを遮断しない

データセンターをすべて遮断する

多くの悪いボットはデータセンターで動きますが、監視、Webhook、検索クローラー、企業向けサービスも同様です。このルールはクーポン利用などの機密性が高い操作に向いており、そのままサイト全体へ適用すべきではありません。

高速なリクエストをすべて遮断する

検索クローラーや稼働監視ツールは、正当なリクエストを短時間にまとめて送ることがあります。レート制限には、エンドポイントの機密性と検証済みの身元を反映するべきです。

すべてのクローラーにJavaScriptチャレンジを課す

検索ボットには一定のレンダリング能力がありますが、ボット対策チャレンジ、CAPTCHA、必須Cookieはクロールを妨げる可能性があります。重要な公開コンテンツには、検証済みクローラーが支障なくアクセスできる経路が必要です。

古い許可リストを永遠に信頼する

IP範囲、サービス、事業上の必要性は変わります。許可リストには、情報源、所有者、見直し日、利用ログが必要です。

リスク段階に応じた対処方針

レベル1：許可してログを記録する

検証済みクローラー、自社の監視、既知の提携先が対象です。非公開領域には引き続き認証が必要です。「良いボット」であることは、認可を意味しません。

レベル2：緩やかなレート制限

公開コンテンツを読む正体不明のボットが対象です。しきい値を超えたら、429とRetry-Afterを返します。一時的な増加だけで永久遮断しないでください。

レベル3：チャレンジまたは機能制限

検索が速すぎる、大量のカートを作る、フォーム送信を繰り返すなど、中程度のリスク行動に適用します。JavaScriptの実行を求めたり、しきい値を超えたらCAPTCHAを出したり、返すデータを制限したりできます。

レベル4：遮断

クレデンシャルスタッフィング、脆弱性の悪用、確実なスパム、十分な証拠のあるクリック詐欺、または質の高い拒否リストに含まれるIPや痕跡が対象です。

レベル5：調査して証拠を保存する

広告詐欺や継続的な攻撃では、リクエストID、タイムスタンプ、IPハッシュ、ユーザーエージェント、フィンガープリント、キャンペーン、操作を保存します。必要以上の個人データを保持しないでください。目的は、遮断判断を再現できるようにすることです。

接点ごとの保護方法

コンテンツページとSEO

検証済みクローラーを許可し、キャッシュを十分に活用し、正体不明のボットをレート制限し、スクレイピングを監視します。インデックス登録が必要な記事やカテゴリの前にCAPTCHAを置かないでください。

ログインとパスワードリセット

アカウントとIPの両方でレート制限し、ユーザー名のリストを検出し、MFAを使い、失敗が増えたら警告します。住宅回線IPのボットも、操作パターンで検出できます。

リード獲得フォーム

ハニーポット、最低入力時間、サーバー側の検証、レート制限はスパムを減らします。人間が支援するファームに対して、CAPTCHAだけでは不十分です。

購入手続きとクーポン

アカウント、端末、カード、クーポンにまたがって頻度を追跡します。データセンターの遮断は役立つ場合がありますが、法人顧客には例外が必要かもしれません。

広告のランディングページ

キャンペーン、クリックID、タイムスタンプ、品質スコアを記録します。広告ネットワークのクリックを、セッション、ログ、コンバージョンと比較します。財務上の除外には、1件の不審なリクエストよりも強い証拠が必要です。

IPまたはフィンガープリントを調査する手順

1. IP Checkerでアドレスを分類します。
2. 大手クローラーを名乗る場合は、逆引きDNSを検証します。
3. 5–30分の時間枠にわたる操作の連続を取得します。
4. ユーザーエージェント、ヘッダー、フィンガープリント、アセットのリクエストを比較します。
5. キャンペーン、ランディングページ、操作の価値を確認します。
6. 絶対的な正誤ラベルではなく信頼度を割り当てます。
7. 許可、制限、チャレンジ、遮断を選択します。
8. 一時的なルールに有効期限を設定します。

0–100のスコアなら、曖昧な領域を残せます。

• 80–100：人間らしさを示すシグナルが多い状態です。
• 50–79：監視や軽い制限が必要です。
• 50未満：自動化やリスクの兆候が多い状態です。

しきい値は、サイトに合わせて調整する必要があります。ブログ、銀行、ゲームでは、許容できる水準が異なります。

誤検知をプロダクトの指標として測定する

ボットの99%を遮断しても、実際の顧客の5%を失うシステムは、遮断率の低いシステムより悪いかもしれません。次の項目を追跡してください。

• チャレンジ成功数。
• 遮断された後にサポートへ連絡したユーザー。
• ルール適用前後のコンバージョン。
• 新しいIPで戻ってくるボットの割合。
• 誤検知の多いエンドポイント。

各ルールには、理由、所有者、ロールバック方法が必要です。「このIPは怪しい気がする」は運用方針にはなりません。

ボット対策ルールを本番コードと同じように管理する

ボット対策は蓄積しがちです。攻撃中に追加した緊急IP遮断が、そのアドレスの所有者が変わった後も何年も残ることがあります。ルールを、バージョン管理する本番のロジックとして扱ってください。

各ルールには、次の情報を記録するべきです。

• ルールの根拠となった行動やインシデント。
• 使用するシグナルと信頼度。
• 影響するエンドポイントとユーザー群。
• 所有者と承認日。
• 有効期限または見直し日。
• ロールバック手順。
• 監視する誤検知の指標。

リスクが許す限り、新しい対策はレポートのみのモードでテストしてください。制限や遮断の対象になるはずだったリクエストを記録し、ログイン成功、購入、検証済みクローラー、サポートへの苦情と比較します。この試行期間により、広すぎる正規表現やネットワークルールを、顧客へ影響する前に発見できます。

全体へ一括適用するのではなく、接点ごとに展開してください。厳しいルールがクーポン利用には適切でも、ドキュメントページでは有害な場合があります。エンドポイント別の方針なら、変化が起きた際の指標も分かりやすくなります。

検証済みの運用作業向けに緊急バイパスを用意し、すぐにロールバックできるようにしてください。誤検知の発生時にアプリケーション全体のデプロイを待つことは、ルールが防ごうとしていた自動化よりも大きな損失につながりかねません。

最後に、拒否リストと同じくらい慎重に許可リストを見直してください。侵害された提携先トークンや古いクローラー例外が、恒久的な穴になる可能性があります。信頼には範囲を設け、観測できるようにし、定期的に再検証するべきです。

Robots.txtはボット防御ツールですか？

Robots.txtは協力的なクローラー向けの取り決めであり、悪質な自動化は無視できます。Googlebotや正当なクローラーには引き続き不可欠ですが、WAF、認証、レート制限、行動分析の代わりにはなりません。

Robots.txt Checkerを使い、スクレイピング対策の変更で検索クローラーを誤って遮断していないか確認してください。

全体像を把握しましょう： トラフィックのQuality Scoreの仕組みを読み、無料SEO監査を実施してから、サイト全体へ遮断ルールを適用してください。

まとめ

提供元の公式な方法でクローラーの身元を検証し、その操作を確認します。セキュリティヘッダーだけでは身元や WAF によるアクセス許可は確認できません。

参考資料：Google Search Central – Googlebot、Googleクローラーの概要。