「昨日まで通っていたrequestsのコードが、今日から403で弾かれる」——2026年7月以降、Cloudflareのアンチボット強化でこの相談が急増しています。JSチャレンジの検証が厳しくなり、Turnstileの判定も厳格化されたことで、requestsはもちろんPlaywrightのヘッドレス実行すら弾かれるケースが出ています。本記事ではCloudflare JSチャレンジの失敗原因を切り分ける具体的な手順と、規約違反にならない範囲でどこまで対策できるかを整理します。

2026年7月以降、Cloudflareの何が変わったのか

Cloudflareのボット判定は単純なCAPTCHA表示ではなく、複数の検出ベクトルを組み合わせた多層判定です。2026年上半期のCloudflareのデータでは、ネットワーク層の攻撃件数が前年比31.2%増、HTTPリクエスト量も32.4%増と報告されており、大規模ボットネット対策の強化がそのまま一般サイトの防御レベル引き上げにつながっています。

3つの検出ベクトル

検出手法

内容

requestsで再現できるか

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

TLSハンドシェイクの順序・拡張やHTTP/2フレームの特徴からクライアントの正体を推定

不可（標準ライブラリのTLSスタックはブラウザと異なる指紋を持つ）

JavaScript実行環境チェック

Cookieやトークンを生成する過程でブラウザのJS実行結果を検証

不可（JSエンジンがないため）

行動分析

マウスの動き・スクロール・入力タイミングの自然さを監視

不可（ヘッドレスブラウザでも機械的な動きは検出対象）

requestsはそもそもJavaScriptを実行できないため、JSチャレンジが有効なページには最初から到達できません。一方でPlaywrightやSeleniumのようなヘッドレスブラウザはJSを実行できても、navigator.webdriverの値やヘッドレス特有のプロパティ欠落、機械的すぎるマウス移動が検出材料になり、依然としてブロックされます。

JSチャレンジ突破に失敗する原因の切り分け方

「動かない」で止めず、まず失敗レイヤーを特定します。切り分けを誤ると、無関係な対策（プロキシ変更など）に時間を溶かすことになります。

requests・httpxの場合

まずレスポンスヘッダーとステータスコードを確認します。

import requests

resp = requests.get(url, headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"})
print(resp.status_code)
print(resp.headers.get("cf-mitigated"))   # "challenge" ならJS実行が必要なページ
print(resp.headers.get("server"))          # "cloudflare" かどうか

cf-mitigated: challengeが返っている時点で、requestsでの直接取得は原理的に不可能です。ここで足掻いてUser-Agentやヘッダーを変えても解決しません。

Playwright・Seleniumの場合

  • ヘッドレス検出：headless=Trueのままだとnavigator.webdriverがtrueのままになるケースがある。ヘッドフル実行やstealth系拡張での挙動差を比較する
  • TLS指紋の不一致：PlaywrightのバンドルChromiumはOSやネットワーク環境によってJA3/JA4指紋がブラウザ標準と微妙にズレることがある
  • 行動パターン：ページ到達直後に即クリック・即スクロールしていないか。人間の操作ログと比較して不自然な速度になっていないか
  • IPレピュテーション：データセンターIP（クラウドのVPS等）からのアクセスは、住宅用IPより厳しく判定されやすい

Playwrightは1アクションあたり約290ms、Seleniumは約536msというベンチマークがあり速度面では優位ですが、速さそのものはCloudflare突破率に直結しません。あくまで自動待機によるテスト安定性の向上が主な利点です。

規約違反にならない回避策はどこまでか

ここが最も判断を誤りやすい部分です。「技術的にできる」と「やってよい」は別物で、2026年はこの境界がむしろ厳しくなっています。

2026年7月30日施行のGoogle利用規約改定

Googleは数年ぶりに利用規約を大幅改定し、robots.txtの指示に違反する行為、機械可読な指示でスクレイピングが禁止されているコンテンツの収集、これらの制限に反する自動化システムの利用を明確に禁止事項として列挙しました。あわせて「コンテンツの不正なスクレイピング」がアカウント停止事由に追加されています。robots.txtが「クロール禁止」を示している時点で、技術的に突破可能かどうかに関わらず規約違反となる点は明確化されたと理解すべきです。

許容される範囲・グレーゾーン・アウトの目安

区分

具体例

判断

許容される

公式APIの利用、robots.txt許可範囲内の低頻度アクセス、公開データへの常識的な範囲でのアクセス

推奨

グレーゾーン

User-Agentを一般ブラウザ風に偽装、robots.txt上は許可されているがJSチャレンジ回避専用ツールを使う

サイト側の意図と乖離するため個別判断が必要

アウト

robots.txtやToSで明示的に禁止された領域への継続アクセス、Turnstile専用の突破サービス・CAPTCHAソルバーの業務利用

規約違反・不正アクセス禁止法抵触のリスク

日本国内では「スクレイピング自体を直接禁止する法律」は存在しません。ただし利用規約違反・サーバーへの過剰負荷・不正アクセス禁止法・著作権侵害・個人情報の無断収集は、いずれも別の法律・契約違反として問題になり得ます。JSチャレンジという「明示的な拒否の意思表示」を突破し続ける行為は、この中でも不正アクセス禁止法との関係で最もリスクが高い部類に入ります。

米国の判例動向（参考）

2026年7月、米カリフォルニア州北部地方裁判所はGoogleがSerpApiを訴えた著作権侵害訴訟で、検索結果自体（URL・スニペット・事実に基づく検索インデックス）は著作権法で保護される著作物ではないと判断しました。ただしこれは著作権侵害の主張が退けられただけで、利用規約違反やアクセス制御突破の適法性を認めたものではない点に注意が必要です。日本国内での実務判断にそのまま流用できる話ではありません。

自力での回避が割に合わない理由と代替手段

Cloudflare自身のBot Management機能は、エンタープライズプランのアドオンとして年間契約で月額5,000ドルから、ミッドマーケント向けで月額8,000〜25,000ドル、大規模契約では月額80,000ドル以上になることもあります。同様にDataDomeもEssentialsティアで月額3,830ドルからと、サイト側は相応のコストをかけて防御しています。個人・小規模チームが片手間でこれに継続対抗するのは、費用対効果として見合いません。

商用スクレイピングAPIの料金感（2026年8月時点）

  • ScrapingBee：月額49ドルで150,000クレジット。JS描画やステルスプロキシ使用時は1リクエストあたり最大75クレジット消費。無料枠は月1,000クレジット
  • Bright Data Web Scraper API：1,000レコードあたり1.50ドルの従量課金、または月額499ドルで510,000レコードのプラン
  • Oxylabs Web Scraper API：月額49ドルから

これらのサービスはアンチボット対策済みのインフラを前提料金に含んでいるため、自前でTLS指紋偽装や行動シミュレーションを継続メンテナンスするより、結果的に安上がりになるケースが多くあります。

まず検討すべきは公式API・許諾ベースのアクセス

日本では2026年8月20日から本人送信要求権の拡大施行が予定されていますが、個人情報保護委員会は2026年8月11日、これによってスクレイピング方式が一律・全面禁止になるわけではないと説明しています。金融機関などが使ってきたスクレイピング方式は、事前協議を経てAPIなどより安全な方式への転換が求められる段階的なアプローチで、6月25日からの試験運用では7月31日までに約700件の申請が受け付けられています。この流れが示す通り、恒久的な解決策は「JSチャレンジを突破し続ける」ことではなく「先方が用意した公式APIや許諾ベースの取得手段に移行する」ことです。エラーログや403の傾向を継続的に観測して切り分ける習慣は、この種の判断の土台になります。ログを地道に確認して異常パターンを見極める考え方自体は、SSH総当たり攻撃の形跡をログで確認【26年8月】で扱ったアクセスログの読み方とも共通しています。

まとめ

2026年7月以降のCloudflare強化により、requestsは原理的にJSチャレンジを突破できず、Playwright/Seleniumもヘッドレス検出やTLS指紋不一致で弾かれる場面が増えています。まずはcf-mitigatedヘッダー等で失敗レイヤーを切り分け、robots.txtや利用規約で明示的に禁止された領域は突破せず、公式APIや許諾ベースの手段、商用スクレイピングAPIへの切り替えを優先するのが2026年時点での現実的な結論です。Google規約改定や国内の本人送信要求権の議論が示す通り、境界線は年々明確になっており、グレーゾーンでの力技は長期的にリスクが高まっています。