1月に発生した1,600万件のリクエストが証明したIPブロッキングの終焉
2026年1月、大手Eコマースプラットフォームがスキャルピング攻撃を受けました。390万件のユニークIPアドレスに分散された1,600万件のリクエスト。IP単位のrate limitはまったく機能しませんでした。攻撃が成功したのは、コードが巧妙だったからではありません。圧倒的なIP数により、従来の検知が無意味になったためです (SecurityBoulevard、2026年3月)。
このインシデントは、ボット検知業界が以前から指摘していた事実を証明しました。IPレピュテーション単体では人間とボットを判別できません。防御側が次の段階へ移行した以上、スクレイピング側も進化する必要があります。
IPブロッキングを置き換えた3つのレイヤー
最新のボット検知は3つのレイヤーで動作します。IPが関係するのは最初のレイヤーだけです。
接続フィンガープリンティング。 requestがサーバーに到達する前、接続の最初のパケットにはリクエストを送信しているHTTPライブラリを特定する固有のパターンが含まれています。Pythonのrequestsライブラリ、Goのデフォルトクライアント、Node.jsのfetchなど、それぞれが固有のフィンガープリントを生成します。ボット検知システムは、headerを1つ読み取る前にこれを検証します。シグネチャが実際のブラウザと一致しない場合、接続レベルでブロックされます (Reddit r/programming)。
ブラウザフィンガープリンティング。 現在のWebサイトは、ブラウザ環境から300以上のシグナルをチェックします。Canvasレンダリング、WebGL出力、オーディオコンテキスト、インストール済みフォント、画面解像度、タイムゾーン、GPU情報などです。User-Agent文字列は、スタック内で最も重要度の低いシグナルにすぎません。Cloudflare、Akamai、DataDomeは、ページが読み込まれる前に実行されるJavaScriptチャレンジを通じて、これらをパッシブに収集します。
行動分析。 これは最も新しいレイヤーであり、偽装が最も困難な部分です。ボット検知システムは現在、マウスの動き、スクロール速度、クリックパターン、タイピングの間隔、インタラクション間のタイミングを追跡します。実際の人間はマウスを完全に直線的には動かしません。一時停止し、ボタンを行き過ぎ、不規則にスクロールします。ボットはこれらの動作を行わないか、すべてを完璧に行いすぎます (r/webdev、2026年)。
多くのスクレイピングチームが戦う場所を誤っている
不都合な真実があります。多くのスクレイピングチームは、いまだにIPインフラへの投資を主軸にしています。より大規模なproxyプール、レジデンシャルIP、ローテーションゲートウェイなどです。それらの役割は確かに存在し、IPレピュテーションも多数のシグナルの1つとして依然重要です。
しかし、接続レベルのフィンガープリントが「Pythonスクリプト」であることを露呈していたり、headlessブラウザがnavigator.webdriver経由で自動化フラグをリークしていたりする場合、10,000個のレジデンシャルIPを購入しても意味がありません。投資するレイヤーが間違っています。
本番環境向けに34個のスクレイパーを構築した開発者が、この問題について言及しています（Dev|Journal, 2026年3月）。チュートリアルレベルのスクレイピングと本番環境で通用する技術とのギャップは、DOMセレクターではなく、接続フィンガープリントやマウスの動きを解析するボット検知システムによって生じています。チュートリアルが教えるのはHTMLのパースですが、本番環境で求められるのは検知の回避です。
そして状況はさらに難しくなっています。BrowserlessのState of Web Scraping 2026レポートによると、ボット検知システムがheadlessブラウザとheadedブラウザのインスタンス間にある固有のフィンガープリント差分をカタログ化しているため、標準のheadlessブラウザは実際のブラウザよりも検知される頻度が高くなっています。この差は縮まっていません。
もしスクレイパーが停止し続けており、proxyのローテーションしか確認していないのであれば、修正すべき箇所を根本的に見誤っている可能性があります。
Cloudflareという要素
この変化の両側に関わっているため、Cloudflareには特筆すべき点があります。
CloudflareのBot Managementはすべてのリクエストに対して行動分析を実行し、多数のシグナルに基づいて訪問者を1から99のスケールでスコアリングします。Turnstile（同社の不可視チャレンジ）は、訪問者がどれだけ人間に見えるかに応じてチャレンジの難易度を動的に調整します（Cloudflare docs）。
同時に、Cloudflareは独自のAIクローリングインフラを立ち上げました。コミュニティはこの皮肉に注目しています（Reddit r/cybersecurity）。
実用上の意味合いとして、Cloudflareで保護されたサイトは2026年現在最もスクレイピングが困難であり、全Webサイトの約20%が同社のネットワーク背後に存在します。スクレイピング戦略で行動検知を考慮していない場合、アクセス可能なWebの5分の1を失うことになります。
2026年に実際に機能するもの
成功しているスクレイパーには、3つの共通点があります。
第一に、最新ブラウザのワイヤレベルのシグネチャと一致していることです。接続の実際のバイトレベルの形式は、最新のChromeやFirefoxセッションが出力するものと一致していなければなりません。接続フィンガープリントの不一致は、どれだけheaderを偽装しても修正できません。
第二に、実際の（または極めて精巧な）ブラウザ環境を実行していることです。デフォルト設定のheadlessインスタンスではなく、宣言しているUser-Agentと一致する一貫したフィンガープリントを持つ、実際のブラウザインスタンスです。
第三に、保護されたサイトに対して人間らしい行動ノイズを追加していることです。ランダムな待機時間だけでは不十分です。アクション間のタイミングは現実的な分布に従う必要があり、マウスの移動経路には有機的に見える曲線やためらいが必要です。
そのため、アーキテクチャは変化しました。重要なのはIPの数を増やすことではありません。各リクエストを、実際のブラウザを操作する実際の人間と区別がつかない状態にすることです。
検知の軍拡競争が加速
Bot検知ベンダーは、顧客ベース全体でリアルタイムに脅威インテリジェンスの共有を開始しました。あるサイトが新しいBotパターンを検出すると、ネットワーク内の他のすべてのサイトが数分以内にそれを学習します（SecurityBoulevard、2026年3月）。これは、各サイトの防御が独立して機能していた従来のモデルからの根本的な変化です。
これは、スクレイピングインフラの内製コストが上昇し続けることを意味すると考えています。新たな検知シグナルに対処するたびにエンジニアリング工数が発生し、そのサイクルは加速しています。インフラストラクチャ層で検知に対処するチーム（スマートプロキシルーティング、ブラウザフィンガープリント、接続レベルのマッチング）は、単にIPを追加し続けるチームよりも優れた成果を上げます。
問題は、より多くのプロキシが必要かどうかではありません。リクエストがターゲットサーバーに到達する前に、人間によるアクセスに見えているかどうかです。