最近、サイトのトラフィックが突然急増した。詳細に分析したところ、セッション滞在時間とインタラクション時間が著しく短くなり、リピーターの割合が急落していることが判明した。2週間にわたる観察の結果、これらの異常なトラフィックは生身の人間によるものではないと確信した。
そのため、Bot（ボット）遮断メカニズムの導入を決定した。
第一歩、ISR（Incremental Static Regeneration）の有効化。 設定はシンプルだが、主な目的は静的キャッシュを利用してオリジンサーバーとデータベースのパンクを防ぐことであり、後の攻防戦のためのリソースの余力を残すためである。redisも同じだ。
第二歩、クラウドサービスのBot管理機能をオンにし、robots.txtに強力な拒否コマンド（Disallow）を追加。 しかし、これは「お行儀の良い」Botにしか効かず、大半の悪意あるBotはこれらのルールを完全に無視する。したがって、別の手段を講じる必要があった。
第三歩、基礎的なハニーポットのデプロイ。 これはBot専用に用意した「罠」であり、一般ユーザーには見えない。隠しフォームやリンク、ボタンなどである。これらがトリガーされると、システムは異常リクエストを即座に特定し、レートリミットやBAN（ブロック）を行う（クラウドベンダーのプロキシIPフィルタリングと組み合わせるとさらに効果的だ）。
第四歩、カナリアトークン（Canary Token）と動的ハニーポット。 従来のハニーポットは識別されやすいため、動的な検証メカニズムを組み込む必要がある。例えば、特定のリンクにアクセスした際、ランダムな名前の署名付きCookie( grep-safe )を動的に発行する。APIのインターセプターが、その後のリクエストでこの不正なクレデンシャルを保持・再利用しているのを発見した場合、次回または一定時間後にレートリミットやBANを実行する。この手法は、リンク巡回やパラメータ再利用型のクローラーに対する特効薬となる。
第五歩、切り札（伝家の宝刀）。 通常手段が通用しない場合、直接CAPTCHAとWAF Interstitial（不審なアクセスに対するチャレンジ）を投入する。
最後に、玉砕覚悟の最終手段（Proof of Work：PoW）。 狂ったようなスクレイピングによりインフラ費用が暴騰する高頻度Botに対しては、逆消耗戦略を取ることができる。疑わしいクライアントに対し、リクエストを送信する前に複雑な暗号計算問題を解かせることで、相手のCPUリソースを大量に消費させ、結果としてこちらの帯域幅と計算リソースの占有を減らすのだ。
JA3/JA4フィンガープリントや、Canvas・画面解像度・ブラウザ情報などを組み合わせたブラウザフィンガープリンティングも有効な手法である。ただし、これらはユーザー識別技術に該当するため、プライバシーや法規制への配慮が必要となる。利用目的や実装方法によってはグレーゾーンと見なされる可能性もある。
しかし残念ながら、クローラーを100%根絶できる解決策は存在しない。すべての対策の本質は、相手の「データ取得コスト」を釣り上げることに尽きる。
さらに、PlaywrightとAIが結びついたこの自動化の時代においては、フロントエンドのページに暗黙の罠を仕掛け、大規模言語モデル（LLM）に対して「プロンプトインジェクション（Prompt Injection）」による毒入れ（Data Poisoning）を行うことも手配すべき時期に来ている。
そうそう、逆引きDNS（Reverse DNS）の検証と基本的なホワイトリストの仕組みも忘れてはならない。さもないと、SEOが雪崩のように崩壊してしまう。