Cloudflareが昨日セッションスコープのボット検知機能をリリース
2026年7月13日、CloudflareはPrecursorをリリースした。これは訪問者がアクセスした瞬間だけでなく、セッション全体を監視する継続的な振る舞いボット検知エンジンである。既存のTurnstileチャレンジは、ログイン、サインアップ、チェックアウト時に1日約30億回実行されている。Precursorは、そのクライアントサイドの可視性を中間のすべてのページに拡張する。
この枠組みは重要である。Turnstileは特定の瞬間に「この訪問者は人間か」という一つの問いを発していた。Precursorは、マウスの移動、キー入力、スクロール、フォーカスの変更のたびに同じ問いを継続的に発し、その結果をセッションに紐づくボットスコアに反映させる。
これはプレスリリースから受ける印象よりも大きな変化である。
セッションは新しいフィンガープリントである
長年、ボット検知は短時間の処理として行われてきた。チャレンジを解決し、cookieを取得し、リクエストを実行する。新しいワイヤーレベルやヘッダーのチェックであっても、リクエスト単位のイベントであった。最初の検査を通過すれば、次の検査まではほぼ問題なかった。
セッションスコープの振る舞い検知はこのパターンを破壊する。Cloudflareのリリース記事によると、ボットはJavaScriptを実行し、完全なブラウザ環境を使用し、疑われることなく個別のCAPTCHAを通過できる。依然として再現が困難なのは、時間を経過した際の一貫した人間の振る舞いである。
彼らは、自動化が直面する壁として人間の入力の物理的特性を挙げている。人間のマウスの動きは、手首の軸と前腕の回転によって制限される弧を描く。チェックボックスを見てからクリックするまでには測定可能な遅延(認知的負荷)がある。そして、安定した手であっても生理的な振戦周波数で揺れる。ボットは直線や数学的に綺麗なベジェ曲線を生成する。人間が決して出せない精度でクリックする。
これらのシグナルは一つ一つは微弱なものである。5分間のセッションを通してそれらを合算すると、その差異は顕著になる。
リロードがもはや解決策にならない理由
リクエスト単位の検知における回避策は明確であった。ボットスコアが上がれば、ページをリロードし、アイデンティティをローテーションしてやり直せばよい。Precursorはその手段を封じる。
Cloudflareは明言している。「セッションスコープが重要なのは、ボットがページのリロードや新しいチャレンジの開始によって振る舞いのシグネチャをリセットできないことを意味するからだ。」疑わしいセッションはコンテキストを蓄積する。ボットスコアは訪問者に追従する。
しかし、この変更は特定の中間層のスクレイパーに最も大きな打撃を与える。完全なheadlessでリクエストごとにローテーションするモデルは、すでに標準的なチェックに敗北していた。そこに新しさはない。真にセッションを意識し、実際のユーザーの訪問期間を通して一つのブラウザアイデンティティを実行する運用者は、概ね問題ない。Precursorが罰するのはその中間に位置するものだ。つまり、PuppeteerやPlaywrightを妥当なデフォルト設定で実行し、各URLを独立したジョブとして扱い、クリーンに見せるためにクロール間でリロードするチームである。
このスタイルのスクレイピングは使い捨てであるため安価である。Precursorは使い捨てをコストのかかるものにする。
これがエージェント型スクレイパーに意味するもの
Precursorが明確に標的としている2つ目のグループがある。自律型AIスクレイパーだ。Cloudflareは小見出しで明言している。継続的なクライアント側のシグナルによる自律的な挙動の検出である。
自律型ブラウジングエージェント(タスクを計画し段階的に実行するLLM駆動型)は、短く決定的なバーストで動く傾向がある。ナビゲート、抽出、ナビゲート、抽出の繰り返しだ。個々の動作は実際の訪問者と同じように見える。しかし、滞在時間、スクロールして読むパターン、小さな修正、ターゲットの行き過ぎなどが存在しない。セッション全体で見ると、これらの欠落は偽のマウスのジッターと同じくらい明白である。
したがって、思考しながらスクレイピングするエージェントを構築する場合、物理的な負担が現実のものとなる。Cloudflareのブログは、Precursorが「完全なセッションのシミュレートを要求することで、自動化の運用コストを引き上げる。これは構築が著しく困難であり、保守コストが高く、大規模な運用でははるかに信頼性が低くなる」と指摘している。
これが全体の設計目標である。自動化を不可能にするのではなく、非経済的にすることだ。
データチームにとっての意味
3つの変化が生じる。どれも安価ではない。
第1に、requestの予算がsessionの予算に置き換わる。Cloudflareで保護されたターゲットのキャパシティを計画する場合、秒間のrequest数で考えるのをやめ、時間あたりのsession数で考える必要がある。独立して継続的に見えるユーザージャーニーをいくつ維持できるか。そしてそれぞれの長さはどのくらいか。短いバーストは、Precursorが捕捉するように調整された正確なシグネチャである。私たちが5月に書いたproxyの計算の再考もここに適用される。プールサイズは上限ではない。セッションのリアリズムが上限である。
第2に、自社構築か購入かの計算が購入にさらに傾く。requestごとの防御機能に対してスクレイパーを維持することは、一度の統合と時折のパッチで済む。セッション単位の防御機能に対する維持は、継続的な挙動のR&Dを意味する。ペースモデル、カーソル経路、滞在時間の分布、そしてそれらすべてに対するテストカバレッジを維持する方法などである。Webデータ収集のアウトソーシングを迷っていたなら、これは自社構築の採算を悪化させる。
第3に、Precursorを大規模に最初に出荷した者が、業界の新しい検出ベースラインを設定する。CloudflareはWebの約20%を保護している。Eコマースや金融の顧客が次の四半期にPrecursorを積極的に有効にした場合、Precursorをインストールしないサイトを含め、他のすべてのスクレイピングスタックがその影響を感じることになる。防御側のエコシステムは何が機能するかを監視し、迅速にコピーするからである。
誰も言及していないタイムスケールの変化
私たちは3ヶ月前に行動検知への移行について書いた。Precursorはその傾向を製品化したものであり、測定ウィンドウを再設定する。
ボット検知はかつて1つのrequest内で完了していた。現在では、数分、場合によってはそれ以上続くセッション全体で行われる。この変化は、検知の単位が単一のコールであった時代に書かれたすべてのスクレイピング手法に波及する。proxyのローテーション、headerのファジング、秒単位のrequestペーシングは、損失関数が5分間のインタラクションにおける行動の一貫性である場合、すべて意味を失う。
問題は、ボット検知が進化し続けるかどうかではない。それは当然のことである。防御側がセッション単位で設計しているときに、自社のデータ収集スタックがまだrequest単位で機能しているかどうかが問われているのだ。