CloudflareがセッションスコープのBot検知を昨日リリース
2026年7月13日、CloudflareはPrecursorをローンチしました。これは、訪問者がアクセスした瞬間だけでなく、セッション全体を監視する継続的な振る舞いベースのBot検知エンジンです。既存のTurnstileチャレンジは、ログイン、サインアップ、チェックアウト時に1日約30億回実行されています。Precursorは、その同じクライアントサイドの可視性を、アクセス間のすべてのページへと拡張します。
そのアプローチの違いが重要です。Turnstileはある一瞬において、この訪問者は人間か、という1つの問いを投げかけました。Precursorは同じ問いを、マウスの移動、キー入力、スクロール、フォーカス変更のすべてにわたって継続的に投げかけ、その結果をセッションに追従するリアルタイムのBotスコアへと反映します。
これは、プレスリリースの文面以上に大きな変化です。
セッションが新たなフィンガープリントになる
長年、Bot検知は短時間のスポットチェックで行われてきました。入口で1回チェックし、その後は一定期間訪問者を保証するCookieを付与する形式です。より新しいワイヤーレベルやヘッダーのチェックであっても、リクエスト単位のイベントでした。最初の検査を通過すれば、次の検査まではほぼ安全でした。
セッションスコープの振る舞い検知は、そのパターンを打破します。Cloudflareのローンチ記事によると、BotはJavaScriptを実行し、完全なブラウザ環境を使用し、疑いを持たれることなく個別のチャレンジを完了できます。依然として再現が困難なのは、時間をかけた一貫した人間の振る舞いです。
彼らは、自動化が直面する壁として人間の入力の物理特性を挙げています。人間のマウスの動きは、手首の旋回や前腕の回転によって制限される弧を描きます。チェックボックスを視認してからクリックするまでには、測定可能な遅延（認知的負荷）が存在します。また、安定した手であっても生理的な微小震戦の周波数で揺れます。Botは直線や数学的にきれいなベジェ曲線を生成します。そして、人間が決して到達できない精度でクリックします。
これらのシグナルは、単体では微弱なものです。しかし、5分間のセッション全体で積み重なると、その差異は顕著になります。
ページ更新がもはや通用しない理由
リクエスト単位の検知における従来の習慣は単純でした。セッションのスコアが悪化した場合、ページを更新し、IDをローテーションして、最初からやり直すという方法です。Precursorはその抜け道を塞ぎます。
Cloudflareは明確に述べています。「セッションスコープが重要なのは、Botがページを更新したり新しいチャレンジでやり直したりしても、振る舞いシグネチャをリセットできないことを意味するためです。」不審なセッションはコンテキストを蓄積します。Botスコアは訪問者を追跡し続けます。
しかし、その変化は特定の中間層のスクレイパーに最も大きな打撃を与えます。完全なheadlessでリクエストごとにローテーションするモデルは、すでに標準的なチェックに敗れていました。それは目新しいことではありません。実ユーザーの滞在時間にわたって1つのブラウザIDを維持する、真にセッションを意識したオペレーターは、概ね問題ありません。Precursorが影響を与えるのはその中間に位置する層です。妥当なデフォルト設定でPuppeteerやPlaywrightを実行し、各URLを独立したジョブとして扱い、クリーンに見せかけるためにクロール間でページを更新しているようなチームです。
そのようなスクレイピング手法は、使い捨てが可能であるため低コストでした。Precursorは、その使い捨てを高コストなものに変えます。
エージェント型スクレイパーにとっての意味
Precursorが捕捉対象として明確に想定しているもう1つのグループがあります。自律型AIスクレイパーです。Cloudflareはサブヘッドで「継続的なクライアント側シグナルによる自律型動作の検知」と明記しています。
自律型ブラウジングエージェント（タスクを計画し、ステップごとに実行するLLM駆動型）は、短く決定的なバーストで動く傾向があります。遷移、抽出、遷移、抽出の繰り返しです。個々のアクション自体は実際の訪問者が行う操作のように見えます。しかし、滞在時間の揺らぎ、読み進めるスクロールパターン、細かなカーソル修正、ターゲットの行き過ぎなどがありません。セッション全体で見ると、これらの欠落は不自然なマウスジッターと同じくらい露骨に現れます。
そのため、思考しながらスクレイピングするエージェントを構築している場合、物理的なコスト負担が現実のものになります。Cloudflareのブログでは、Precursorが「セッション全体のシミュレーションを要求することで、自動化運用のコストを引き上げる。これは構築難易度が大幅に高く、維持費がかさみ、大規模運用での信頼性が著しく低下する」と述べています。
それこそが設計の狙い全体です。自動化を不可能にすることではなく、採算が合わないものにすることです。
データチームにとっての意味
3つの変化が生じますが、そのどれも安価には済みません。
第一に、requestバジェットがsessionバジェットに置き換わります。Cloudflareで保護されたターゲットのキャパシティを計画する場合、1秒あたりのrequest数ではなく、1時間あたりのsession数で考える必要があります。自然に見える独立したユーザージャーニーをいくつ維持できるか、そして各ジャーニーの長さはどの程度かという点です。短いバースト動作は、まさにPrecursorが検知するように調整されているシグネチャです。5月に執筆したproxy設計の見直しはここでも当てはまります。プールサイズが上限を決めるのではなく、セッションの現実味が上限を決めます。
第二に、自作か購入か（build vs buy）の判断が購入側へさらに傾きます。request単位で防御するシステムに対するスクレイパーの維持は、一度の統合と時折のパッチで済みます。一方、sessionスコープで防御するシステムに対する維持には、ペーシングモデル、カーソル軌道、滞在時間分布、それらすべてのテストカバレッジ維持といった継続的な行動R&Dが必要です。Webデータ収集のアウトソースを迷っていたなら、自作する場合の採算性はさらに悪化します。
第三に、Precursorを大規模に最初に導入した事業者が、業界の新たな検知基準を打ち立てることになります。CloudflareはWebの約20%を保護しています。Eコマースや金融関連の顧客が次の四半期にPrecursorを積極的に有効化すれば、他のすべてのスクレイピングスタックも影響を受けます。防御側のエコシステムは効果的な手法を監視して迅速に模倣するため、Precursor自体を導入していないサイトでも同様の影響が生じます。
誰も言及していない時間軸のシフト
3か月前に振る舞い検知への移行について書きました。Precursorはそのトレンドを製品化したものであり、測定の基準枠を再定義しています。
ボット検知はかつて、1つのrequestの範囲内で行われていました。現在は数分間、場合によってはそれ以上に及ぶsession全体で行われます。この単一の変化は、検知の単位が単一の呼び出しだった時代に作られたあらゆるスクレイピング手法に影響を及ぼします。Proxy rotation、header fuzzing、秒単位のrequest pacing、そのすべてが、損失関数が5分間のインタラクションを通じた行動の一貫性である場合には妥当性を失います。
問題は、ボット検知が進化し続けるかどうかではありません。それは自明のことです。問題は、防御側がsession単位で思考しているときに、自社のデータ収集スタックがいまだrequest単位で思考しているかどうかです。