1月に発生した1,600万のrequestが証明した、IPブロックの終焉
2026年1月、大手ECプラットフォームが転売目的の買い占め（スキャルピング）攻撃を受けました。390万個のユニークなIPアドレスに分散された1,600万のrequest。IPごとのrate limitでは対処できませんでした。この攻撃が成功したのは、巧妙なコードによるものではありません。膨大なIP数によって、従来の検知手法が無効化されたためです（SecurityBoulevard, March 2026）。
このインシデントは、アンチボット業界が以前から指摘していたことを証明しました。すなわち、IPレピュテーションだけでは人間とボットを区別できないということです。防御側が次の段階へ進んだのであれば、スクレイパー側も進化しなければなりません。
IPブロックに代わる3つのレイヤー
現代のボット検知は3つのレイヤーで動作します。IPが関係するのは、そのうちの最初の1つだけです。
ネットワークフィンガープリント。 requestがサーバーに到達する前に、TLSの「Client Hello」パケットが、requestを送信しているHTTPライブラリを特定するシグネチャ（JA3またはJA4として知られています）を作成します。Pythonのrequestsライブラリ、Goのデフォルトクライアント、Node.jsのfetchは、それぞれ異なるフィンガープリントを生成します。アンチボットシステムは、1つのheaderを読み取る前にこれをチェックします。TLSシグネチャが実際のブラウザと一致しない場合、接続レベルでブロックされます（Reddit r/programming）。
ブラウザフィンガープリント。 現在、サイトはブラウザ環境から300以上のシグナルをチェックしています。Canvasレンダリング、WebGL出力、オーディオコンテキスト、インストールされているフォント、画面解像度、タイムゾーン、GPU情報などです。User-Agent文字列は、スタックの中で最も重要度の低いシグナルにすぎません。Cloudflare、Akamai、DataDomeは、ページが読み込まれる前に実行されるJavaScriptチャレンジを通じて、これらをパッシブに収集します（ScrapingBee, 2026）。
行動分析。 これは最新のレイヤーであり、偽装が最も困難な部分です。アンチボットシステムは現在、マウスの動き、スクロール速度、クリックパターン、タイピングの強弱、インタラクション間のタイミングを追跡しています。本物の人間は、マウスを完全に直線的には動かしません。一時停止したり、ボタンを行き過ぎたり、不規則にスクロールしたりします。ボットはこれらを一切行わないか、あるいはすべてを完璧に行いすぎます（r/webdev, 2026）。
ほとんどのスクレイピングチームは的外れな戦いをしている
不都合な真実があります。それは、ほとんどのスクレイピングチームが依然としてIPインフラへの投資を最優先しているということです。より大規模なproxyプール、レジデンシャルIP、ローテーティングゲートウェイなどです。それらにも役割はあります。IPレピュテーションは、数あるシグナルの1つとして依然として重要です。
しかし、TLSフィンガープリントが「Pythonスクリプト」であることを示していたり、headlessブラウザがnavigator.webdriverを通じて自動化フラグを漏洩させていたりすれば、10,000個のレジデンシャルIPを購入しても意味はありません。誤ったレイヤーにお金を費やしていることになります。
34個の本番環境用スクレイパーを構築した開発者が、この問題について書いています（Dev|Journal, March 2026）。チュートリアルレベルのスクレイピングと、本番環境で通用するスクレイピングの差は、DOMセレクターではなく、TLSフィンガープリントやマウスの動きを分析するアンチボットシステムによって定義されます。チュートリアルはHTMLのパースを教えますが、本番環境は検知を回避して生き残る方法を教えてくれます。
そして、状況は悪化しています。BrowserlessのState of Web Scraping 2026レポートによると、標準的なheadlessブラウザは、実際のブラウザよりも頻繁にフラグを立てられます。これは、アンチボットシステムがheadlessと通常のChromeの間の具体的なフィンガープリントの違いをカタログ化しているためです。その差は縮まっていません。
もしスクレイパーが壊れ続けており、あなたがproxyのローテーションだけを気にしているなら、まったく的外れな部分を修正しようとしている可能性があります。
Cloudflareという要因
Cloudflareはこの移行の両側に位置しているため、特筆に値します。
同社のBot Management製品は、すべてのrequestに対して行動分析を実行し、数多くのシグナルに基づいて訪問者を1〜99のスケールでスコアリングします。Turnstile（同社の目に見えないCAPTCHA代替機能）は、訪問者がどれだけ人間に見えるかに基づいて、チャレンジの難易度を動的に調整します（Cloudflare docs）。
同時に、Cloudflareは独自のAIクローリングインフラを立ち上げました。コミュニティはその皮肉に気づいています（Reddit r/cybersecurity）。
これが実質的に意味することは、Cloudflareで保護されたサイトは2026年において最もスクレイピングが困難であり、全ウェブサイトの約20%が同社のネットワークの背後にあるということです。スクレイピング戦略が行動検知を考慮していない場合、アクセス可能なウェブの5分の1を失うことになります。
2026年に実際に機能するもの
成功しているスクレイパーには、3つの共通する特徴があります。
第一に、実際のブラウザのTLSフィンガープリントと一致していることです。curl-impersonateのようなツールは、ChromeやFirefoxの正確なTLSシグネチャを複製し、検知が始まる前にそれを防ぎます。どれだけheaderを偽装しても、一致しないJA3ハッシュを修正することはできません。
第二に、本物の（あるいは極めて本物に近い）ブラウザ環境を実行していることです。デフォルト設定のheadless Chromeではありません。自身が主張するUser-Agentと一致する、一貫したフィンガープリントを持つ実際のブラウザインスタンスです。
第三に、保護されたサイトに対して、人間のような行動ノイズを追加していることです。ランダムな遅延だけでは不十分です。アクション間のタイミングは現実的な分布に従う必要があり、マウスの移動経路には自然に見える曲線やためらいが必要です。
つまり、アーキテクチャが移行したのです。重要なのはIPを増やすことではありません。各requestを、Chromeを閲覧している本物の人間と区別がつかないようにすることです。
加速する検知の軍拡競争
アンチボットベンダーは、顧客ベース全体で脅威インテリジェンスをリアルタイムに共有し始めています。あるサイトが新しいボットパターンを検出すると、ネットワーク内の他のすべてのサイトが数分以内にそれを学習します（SecurityBoulevard, March 2026）。これは、各サイトsの防御が独立して動作していた古いモデルからの根本的な変化です。
私たちは、これが自社構築のスクレイピングインフラのコストが上昇し続けることを意味すると考えています。新しい検知シグナルが登場するたびに対処するためのエンジニアリング時間が必要になり、そのサイクルは加速しています。インフラレベルで検知に対処するチーム（スマートproxyルーティング、ブラウザフィンガープリント、TLSマッチング）は、問題に対してIPを投入し続けるチームよりも優れた成果を上げるでしょう。
問いかけるべきは、さらに多くのproxyが必要かどうかではありません。あなたのrequestが、ターゲットサーバーに到達する前に人間のように見えるかどうかです。