Cloudflare Turnstileが表示されて先に進めない、Playwrightでヘッドレスブラウザを使っているのに検出されてブロックされる——そんな悩みを抱える人は多いはずです。この記事では、2026年7月31日リリースのPlaywright 1.62.0時点でのブラウザコンテキスト設定（いわゆるstealth系オプション）を使って、Cloudflare Turnstileに対してどこまで検出回避が通用するのか、そして2026年7月13日にCloudflareが投入した新しいボット検知エンジン「Precursor」がその前提をどう変えたのかを、実装レベルで整理します。

Playwrightに「公式stealthモード」は存在しない

まず誤解を解いておく必要があります。Playwright自体（Microsoft開発、npmダウンロード数は2025年に週間3200万件を突破しSeleniumを置き換える勢いで普及）には、ワンフラグで検出を回避できる公式の「stealthモード」は存在しません。あるのはbrowser.new_context()に渡せるフィンガープリント関連のオプション群と、それらを補うサードパーティライブラリです。

コンテキストレベルで制御できる項目

  • user_agent — UA文字列の偽装
  • viewport / screen — 画面サイズの一致
  • locale / timezone_id — 言語・タイムゾーンの整合性
  • extra_http_headers — Accept-Language等の追加ヘッダー
  • permissions / geolocation — 権限周りの挙動

これらはPlaywrightのバージョンが上がるたびに細かく拡充されてきましたが、あくまで「見た目の設定」であり、Cloudflare側が見ている検出シグナルの一部にしか効きません。

navigator.webdriverを消すだけでは通らない

ヘッドレスブラウザはnavigator.webdriver = trueや、CDP（Chrome DevTools Protocol）経由での操作特有のプロパティ欠落によって機械的に弾かれます。これを打ち消すために使われるのがplaywright-stealthのようなコミュニティ製パッチや、CDPの痕跡を消すことに特化したPatchrightのようなフォーク版です。ただし、こうしたパッチは「既知の検出項目に後追いで対処する」性質のものなので、Cloudflare側が検出項目を追加・変更すれば効果が切れます。実際、Cloudflare JSチャレンジ失敗の原因【26年8月】で扱ったように、JSチャレンジの実行結果が既知パターンと少しでもズレるだけで詰まるケースが日常的に起きています。

Cloudflare Turnstileが見ている3つの検出ベクトル

2026年8月時点でCloudflareが公言している検出の柱は次の3つです。

検出ベクトル

何を見ているか

Playwright側での対策難易度

TLS/HTTPフィンガープリンティング

TLSハンドシェイクの順序やHTTPリクエストのシグネチャがChrome/Firefox正規版と一致するか

高（requestsやhttpxは即座に不一致で弾かれる。実ブラウザエンジンを使うPlaywrightは有利）

JavaScript実行環境の検証

ブラウザの環境変数・API群が本物のブラウザと矛盾しないか

中（stealthパッチである程度緩和可能）

行動分析（Precursor）

マウス移動・スクロール・入力タイミングをセッション全体で継続監視

非常に高い（スクリプトで機械的に再現しづらい）

厄介なのは3つ目です。2026年7月13日に一般提供が始まった次世代エンジン「Precursor」は、ページ読み込み時の一発判定ではなく、セッション全体を通じてリアルタイムに継続的なインタラクションを分析する方式に変わりました。つまり「初回アクセスだけ人間らしく見せる」小細工では通用せず、その後の操作パターンまで一貫して自然である必要があります。

実装：stealth設定を盛り込んだPlaywrightコード

実測に使った基本構成は以下の通りです。UA・ロケール・タイムゾーンをOSの実環境と一致させ、CDP経由のフラグを潰すパッチを併用しています。

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=True,
        args=[
            "--disable-blink-features=AutomationControlled",
        ],
    )
    context = browser.new_context(
        user_agent=(
            "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
            "AppleWebKit/537.36 (KHTML, like Gecko) "
            "Chrome/128.0.0.0 Safari/537.36"
        ),
        viewport={"width": 1280, "height": 800},
        locale="ja-JP",
        timezone_id="Asia/Tokyo",
        extra_http_headers={"Accept-Language": "ja-JP,ja;q=0.9"},
    )
    # navigator.webdriver を書き換えて検出を遅らせる
    context.add_init_script(
        "Object.defineProperty(navigator, 'webdriver', {get: () => undefined})"
    )
    page = context.new_page()
    page.goto("https://example.com/turnstile-protected")

    # 人間らしいカーソル移動を模してから待機
    page.mouse.move(200, 300, steps=25)
    page.wait_for_timeout(1500)
    page.mouse.move(450, 520, steps=18)

    page.wait_for_selector("iframe[src*='turnstile']", timeout=15000)
    browser.close()

TLSフィンガープリントとJS実行環境の検証までは、この構成で通過することがあります。しかしTurnstileのチャレンジ自体がPrecursorの行動分析と連携している場合、page.mouse.move()で作った軌跡は等速・直線的になりやすく、実際のマウス操作特有の揺らぎ（加速・減速・微振動）を欠くため、継続監視のどこかで弾かれるケースが残ります。

実測で見えた限界と代替策

通るケースと通らないケース

  • 通りやすい：TLS/HTTPフィンガープリント単体での判定、初回ページロード時の静的JSチェック
  • 通りにくい：セッション継続中の行動分析、Turnstileのインタラクティブチャレンジ（クリック確認が求められるモード）

結論として、Playwright 1.62時点のコンテキストオプションやコミュニティ製stealthパッチは「静的な検出」には有効でも、Precursorのような「継続的な行動監視」には根本的な対抗策になっていません。マウス軌跡の乱数化やタイミングのランダム化を精緻にすればするほど、実装・保守コストは跳ね上がる一方で、Cloudflare側の検知モデルはAI駆動で継続的に更新されているため、いたちごっこが終わりません。

現実的な代替策

  • 対象サイトが公式APIを提供していないか先に確認する（規約遵守かつ保守コストが圧倒的に低い）
  • Turnstile回避を自前実装せず、必要なデータの範囲を絞ってアクセス頻度を人間の閲覧並みに抑える
  • 継続的な運用が必要な場合は、検出ロジックの変化を追い続ける前提でコストを見積もる（1回作って終わりにはならない）

特に3点目は見落とされがちです。Cloudflareのアンチボット機構は数ヶ月単位でアップデートされるため、今日通ったコードが来月も通る保証はありません。ここが個人でスクレイピング基盤を自作する場合の一番の負担になります。

規約・法令面で必ず確認すべきこと

技術的に回避できるかどうかと、それをやってよいかどうかは別問題です。2026年8月時点の日本では、スクレイピング行為そのものを一律に禁止する法律はなく、総務省が消費者物価指数（CPI）調査にWebスクレイピングを活用している事例もあります。一方で、次の点は個別に確認が必要です。

  • 利用規約：対象サイトの規約でスクレイピングが明示的に禁止されていないか。禁止されている場合、アカウント停止や損害賠償請求のリスクがある
  • 著作権法30条の4：情報解析目的であれば原則利用可能だが、取得データをそのまま転載する行為は対象外。統計データ等への加工が必要
  • 個人情報保護法：取得データに個人情報が含まれる場合、目的外利用や第三者提供に本人同意が必要になりうる
  • 不正競争防止法：非公開の営業秘密を不正取得した場合に問われる可能性
  • 刑法（偽計業務妨害・電子計算機損壊等業務妨害）：高頻度アクセスでサーバーに過度な負荷をかけた場合のリスク。過去にはアクセス集中で障害が発生し逮捕に至った事例もある

Turnstileのような強力なアンチボット機構をわざわざ突破しようとしている時点で、そのサイトは「自動アクセスを歓迎していない」意思表示をしていると考えるのが妥当です。技術的な回避を試みる前に、規約とアクセス頻度の両方を見直すことをおすすめします。

まとめ

Playwright 1.62時点のコンテキストオプションやstealthパッチは、TLSフィンガープリントやJS実行環境の静的チェックには一定の効果がありますが、2026年7月にCloudflareが投入した継続的行動分析エンジン「Precursor」の前では限界があります。マウス軌跡やタイミングを人間らしく作り込むほど保守コストは膨らみ、検出モデルの更新にも追随し続ける必要があります。回避を追求する前に、公式APIの有無・利用規約・アクセス頻度を見直すほうが、結果的に持続可能な選択になることが多いです。