「昨日まで取れていたrequestsのスクレイピングが、突然空データしか返さなくなった」——2026年6〜7月にCloudflareがPerplexity等AIクローラーのUA偽装ブロックを拡大した影響で、こうした相談が急増している。ブラウザで開けば普通にページが表示されるのに、requestsやSeleniumで叩くとHTMLの中身が空、もしくはチャレンジページのHTMLが返ってくる——この記事では、CloudflareのUA偽装ブロックが強化された背景を踏まえ、原因の切り分け方と、規約違反にならない正規手段での収集継続の方法を実装コード付きで解説する。

Cloudflareが2026年6〜7月に拡大したUA偽装ブロックの中身

発端は、PerplexityのAIクローラーが「Googlebotを騙るUser-Agent」で robots.txt の拒否設定を無視してクロールしていたと指摘された件だ。Cloudflareはこれを受けて、UA文字列だけを見て人間・正規ボットのふりをするアクセスの検知精度を強化し、対象範囲をAIクローラー以外の一般的なスクレイピングツールにも広げた。結果として、これまでUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)...のようなヘッダーを付けるだけで通過できていたrequestsベースの収集が、次々と弾かれるようになっている。

なぜ「UAだけ人間に偽装」が通用しなくなったのか

Cloudflare Bot ManagementやDataDomeのような主要なアンチボット製品は、UA文字列単体ではなく、TLSハンドシェイクの特徴（JA3/JA4フィンガープリント）、HTTP/2のフレーム順序、JavaScript実行環境の有無、マウス移動やタイミングといった複数のシグナルを組み合わせて判定している。requestsやhttpxはPythonのTLSスタック（OpenSSL経由）でハンドシェイクするため、Chromeとは異なる指紋になり、「UAはChromeを名乗っているのにTLS指紋がPythonのもの」という矛盾がそのままボット判定の根拠にされる。UAだけを書き換える対策が2026年に入って急速に無力化しているのは、この不一致を見られているためだ。関連する挙動はCloudflare JSチャレンジ失敗の原因【26年8月】でも詳しく検証している。

「人間には表示されるがrequestsだと空データ」の切り分け手順

対応を決める前に、まず何が起きているかを機械的に切り分ける。以下の順で確認すると原因を特定しやすい。

  1. requestsのレスポンスHTMLにchallenges.cloudflare.comやcf-mitigatedヘッダーが含まれていないか確認する（含まれていればJSチャレンジで止められている）
  2. レスポンスのステータスコードが403で、HTMLボディが極端に短い（1KB未満）場合はUA/TLS指紋レベルで即ブロックされている
  3. ステータス200でHTMLは返るが目的のデータ部分だけが空の場合は、対象データがJavaScriptでの動的レンダリング依存であり、そもそもrequestsでは取得できない設計の可能性が高い
  4. SeleniumやPlaywrightのヘッドレスモードでは通るのに、同じUAのrequestsでは弾かれる場合は、TLS指紋またはJS実行判定が原因と確定できる

実装コードでの確認例

import requests

url = "https://example.com/target-page"
headers = {
    "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"
}
res = requests.get(url, headers=headers, timeout=10)

print(res.status_code)
print(len(res.text))
if "challenges.cloudflare.com" in res.text or res.headers.get("cf-mitigated"):
    print("→ CloudflareのJSチャレンジで止められている")
elif res.status_code == 403:
    print("→ UA/TLS指紋レベルで即ブロック")

ここでcurl_cffiのようなTLS/JA3フィンガープリント偽装ライブラリを使えば技術的にはブロックを回避できる場合がある。ただしこれは「人間のふりをして機械的に自動アクセスする」行為そのものであり、対象サイトの利用規約でスクレイピングやボットによる自動アクセスを禁止している場合は、指紋偽装の有無に関わらず規約違反になる点は変わらない。技術的に通ることと、やってよいことは別問題として扱う必要がある。

規約違反にせず収集を継続する3つの正規手段

ブロックを技術で強引に突破するのではなく、まず「そもそも許可された経路があるか」を確認するのが先決だ。

robots.txtとレートリミットの確認

対象サイトの/robots.txtを見て、目的のパスがDisallow指定されていないか確認する。許可されている場合でも、1秒間に何十リクエストも送るような負荷は事実上の妨害行為とみなされうるため、time.sleep()で最低でも1〜2秒の間隔を空け、同時接続数も絞る。

import time
import requests

session = requests.Session()
for url in target_urls:
    res = session.get(url, headers=headers, timeout=10)
    # 処理...
    time.sleep(2)  # レートリミットを自主的に順守

公式APIやデータ提供サービスの有無を確認する

ECサイトの価格調査であれば、楽天市場API・Yahoo!ショッピング商品検索API v3のように無料の公式APIが用意されているケースが多い。スクレイピングでブロックと格闘する前に、対象領域に公式APIが存在しないかを必ず確認する。存在すれば、規約遵守・安定性・実装コストのすべてで優位になる。

ヘッドレスブラウザで正規のレンダリング経路を通す

動的レンダリングが前提のサイトで、robots.txt上も禁止されていないなら、PlaywrightやSeleniumで実際にJavaScriptを実行させてブロックを回避するのではなく「通過」する方法が現実的だ。Cloudflareのチャレンジ通過についてはPlaywright Turnstile回避の実測【26年8月】で具体的な検証結果をまとめている。ただしヘッドレスブラウザでも規約違反であることに変わりはないため、あくまで「規約上許可されている範囲で、技術的な壁を越えるための手段」という位置づけで使うべきだ。

2026年8月時点の主要ライブラリのバージョンと変更点

スクレイピング用ライブラリは頻繁にセキュリティ・TLS関連のアップデートが入るため、バージョンを把握しておくと切り分けの助けになる。

ライブラリ

最新バージョン

リリース日

関連する変更点

Requests

2.34.2

2026年5月14日

headers入力型がMappingに変更、Request.headers.update()利用箇所は型調整が必要な場合あり

Selenium

4.47.0

2026年8月10日

FirefoxでのCDPアクセスをブロック、no_proxyマッチング修正

Playwright

1.62.0

2026年7月31日

ヘッドレスモードのクリップボードをOS本体から隔離、Debian 11サポート終了

Scrapy

2.17.0

2026年7月7日

セキュリティ修正、許可TLSバージョン設定の改善

特にScrapy 2.17.0のTLSバージョン設定強化は、古いTLSでハンドシェイクしていた実装が今後弾かれやすくなる可能性を示唆している。requests/Selenium/Playwrightいずれを使う場合も、ブロックが増えたと感じたらまずライブラリのバージョンとTLS周りの変更履歴を確認するとよい。

著作権法・利用規約・不正アクセス禁止法の観点で判断すべきこと

技術的に回避できるかどうかとは別に、以下の3点は収集を始める前に必ず確認する。

  • 利用規約：スクレイピング・自動アクセスを明示的に禁止していないか。禁止されている場合、技術的に通っても契約違反のリスクが残る
  • 著作権法：取得したデータをそのまま再配布・公開すると著作権侵害になりうる。社内分析目的での利用と、外部への再配布は法的リスクの重みが異なる
  • サーバーへの負荷：意図せず過大な負荷をかけた場合、不正アクセス禁止法や偽計業務妨害に問われる可能性がゼロではない。レートリミットの順守は法的リスク低減の意味でも重要

2026年8月時点で、この領域における日本国内の新しい規制や判例の発表は確認できていないが、これは「リスクが小さい」ことを意味しない。既存の著作権法・利用規約・不正アクセス禁止法の枠組みが継続して適用される前提で、案件ごとに個別判断する必要がある。

自前対応のコストが見えにくいポイント

ここまでの切り分けと対策は、原因が特定できていれば数時間で終わることもあるが、実際には「ブロックされているのがUAなのかTLS指紋なのかJS判定なのか」の切り分け自体に半日以上かかるケースが少なくない。さらにCloudflare側のアンチボット挙動は数ヶ月単位で更新され続けており、一度動いた実装が数ヶ月後に再び止まる、という保守コストが継続的に発生する点が、自前運用でもっとも見落とされやすい負担だ。robots.txt順守・レートリミット設計・公式API調査・バージョン追随を、案件ごとに毎回やり直す前提でスケジュールを組んでおくと、想定外の手戻りを減らせる。

まとめ

CloudflareのUA偽装ブロック拡大により、UA文字列だけを書き換える対策は2026年8月時点でほぼ通用しなくなっている。ブロックの原因がJSチャレンジかTLS指紋かJS判定かをまず切り分け、robots.txt順守・レートリミット・公式APIの確認という正規手段を優先する。技術的な回避が可能でも規約違反のリスクは別問題として残るため、著作権法・利用規約・サーバー負荷の3点は必ず案件ごとに確認したい。