先日、3つのテストサイトでは問題なく動いていた Python スクリプトの調整に40分ほど頭を抱えました。原因は4つ目のサイト。アクセスした途端、背後に Cloudflare が控えていると気づいたのです。スクレイパーは「Checking your browser…」の画面を延々と返すばかりで、手元に届くのはチャレンジ用の HTML だけ。覚えのある方も多いのではないでしょうか。
同じ壁にぶつかったなら、あなた一人ではありません。いまや2,400万を超えるアクティブサイトが Cloudflare を使っており、これはウェブ全体のおよそ22%にあたります。リード獲得、価格監視、不動産リサーチ、競合分析——目的が何であれ、Web データを取りに行く人にとって、Cloudflare はもっとも頻繁に出くわす関門です。
ところが多くの解説記事は回避手法を並べるだけで、肝心の「自分の状況なら、どれを最初に試すべきか」を教えてくれません。この記事では、優先順位をつけた判断ツリー、誇張のない成功率の目安、大半の記事が触れないノーコードの選択肢まで、まとめて整理します。
- 難易度: 初級〜中級（選ぶ方法によります）
- 所要時間: ノーコードなら10〜30分ほど。コードベースは内容しだいです
- 必要なもの: Chrome ブラウザ（ノーコードの場合）、必要に応じて Python 3.9 以上（コード方法の場合）、対象 URL
Cloudflare の保護とは何か、そしてなぜスクレイパーを止めるのか？
Cloudflare は、訪問者とサイトのオリジンサーバーのあいだに立つリバースプロキシです。すべてのリクエストはまず Cloudflare のエッジを通り、そこで「ページを返すか」「チャレンジを出すか」「遮断するか」が決まります。押さえておきたいのは、Cloudflare はあなたのスクレイパーを「悪意あるもの」だと断定する必要はない点です。自動化されている、または怪しいと判断できれば十分なのです。
Cloudflare のBot Managementは、一枚の関所ではなく、何層にも重なったゲートのように働きます。IP の評判、HTTP ヘッダー、TLS フィンガープリント、JavaScript の実行、ブラウザフィンガープリント、行動パターンまでをチェックします。Python の requests で保護下のページに GET をかけると、TLS ハンドシェイクが不自然、JavaScript を実行しない、Cookie がない、ブラウザらしい指紋もない——と複数の層に引っかかります。単純なヘッダー偽装がとうに通用しなくなったのは、こういう仕組みだからです。
ありがちな症状は、403 Forbidden、503 とともに出る「Checking your browser…」、1020 Access Denied、終わらないチャレンジループ、解けない Turnstile、本来 JSON が返る場所に HTML のチャレンジページ、といったものです。
パッシブ検知：ページが開く前に Cloudflare がチェックしていること
ページを目にする前の段階で、Cloudflare のパッシブ層はリクエストの採点を始めています。
- IP の評判: データセンター IP、クラウド事業者のレンジ、知られたプロキシ出口は警戒されます。住宅回線やモバイル回線の IP のほうがずっと信頼されやすいとされます。2026年のコミュニティ報告でも、自宅の住宅回線からは通るのに、Docker や VPS 環境だと弾かれる、という声が一貫して見られます。
- HTTP ヘッダーの分析: Cloudflare は User-Agent、Accept-Language、ヘッダーの並び順、HTTP バージョンを照らし合わせます。Chrome 136 を名乗りながら TLS ハンドシェイクが「いかにも Python」だと、たちまち怪しまれます。
- TLS フィンガープリント（JA3/JA4）: TLS ハンドシェイクの際、クライアントは対応暗号スイート、拡張、プロトコル優先順位といったパターンをさらけ出します。JA3/JA4 はそれを一つの識別子に凝縮します。本物の Chrome と Python の
requestsでは、この「形」がまるで違うのです。 - HTTP/2 フィンガープリント: ブラウザと HTTP ライブラリでは、HTTP/2 の SETTINGS フレーム、擬似ヘッダーの並び、優先度の扱い方が異なります。Cloudflare の JA4 Signals は、単発だけでなくリクエスト間のパターンまで追います。
- AI Labyrinth: Cloudflare の新手の罠です。怪しいクローラーをブロックする代わりに、もっともらしい AI 生成のハニーポットページへ誘い込み、リソースを浪費させます。スクレイパー側は、捕まったことにすら気づかないことがあります。
アクティブ検知：ブラウザ内で動くチャレンジ
パッシブなチェックで判断がつかないとき、Cloudflare はアクティブなチャレンジへ切り替えます。
- JavaScript チャレンジ: おなじみの「Checking your browser…」の中間ページです。Cloudflare の JavaScript Detections は、目に見えないスクリプトで自動化リクエストを見抜きます。
- Turnstile: Cloudflare による CAPTCHA の代替です。Turnstile のウィジェットモードには Managed、Non-Interactive、Invisible の3種類があります。目に見えるパズルを出さなくても、マウスの動き、ブラウザ環境、TLS フィンガープリントを解析します。
- Canvas と WebGL のフィンガープリント: ヘッドレスブラウザの描画が本物のブラウザと食い違うところを突くチェックです。
- 行動シグナル: リクエストの間隔、スクロールの仕方、クリックの順序。3秒で50ページを取得しながらマウスの動きがゼロのスクレイパーは、どう見ても人間には見えません。
実務的な結論はこうです。Cloudflare がアクティブチャレンジまで持ち出したら、requests、httpx、curl_cffi のような素の HTTP クライアントでは突破できません。本物のブラウザ環境を走らせられるものが必要です。
Cloudflare 保護の段階：同じスクリプトがあるサイトでは動いて別のサイトでは失敗する理由
ここは、多くの回避ガイドが見落とす論点です。Cloudflare の保護は横並びではありません。Free プランで「Security Level: Medium」のサイトと、Enterprise で Bot Management と Turnstile を効かせたサイトとでは、難易度がまるで別物です。片方を軽くすり抜けるスクリプトが、もう片方では歯が立たないのは当たり前なのです。
| Cloudflare の段階 | 一般的な防御 | 回避の難易度 | たいてい有効な方法 |
|---|---|---|---|
| Free プラン（低セキュリティ） | Bot Fight Mode、基本的な WAF ルール、IP の評判 | ⭐ 低 | 内部 API の発見、適切なヘッダー付きの curl_cffi、本物のブラウザセッション |
| Pro プラン（中程度） | Super Bot Fight Mode、Managed Challenge、JavaScript 検知 | ⭐⭐ 中 | 本物のブラウザセッション、ステルス系ブラウザ自動化、住宅プロキシ |
| Business | より強い WAF、Bot Analytics、重要パスでの厳しいチャレンジ | ⭐⭐⭐ 中〜高 | ブラウザセッション抽出、セッション維持、住宅/モバイルプロキシ、有料スクレイピング API |
| Enterprise / Bot Management | Bot スコア、JA3/JA4 フィールド、エンドポイントごとのルール、Turnstile、AI Labyrinth | ⭐⭐⭐⭐ 高 | 内部 API（使えるなら）、実ユーザーセッション系ツール、プロバイダ級のスクレイピング API |
Cloudflare の料金ページによると、Free は0ドル、Pro は月額20ドル、Business は月額200ドル、Enterprise は個別見積もりです。Bot Fight Mode は Free プラン向けのシンプルなスイッチ、Super Bot Fight Mode は Pro/Business 向けの追加制御で、Enterprise の Bot Management はさらに細かい Bot スコアとエンドポイント単位のルールを上乗せします。
段階を見分けるコツ: Cloudflare ロゴ入りのブロックでチャレンジスクリプトが出ない 403 なら、WAF かフィンガープリント拒否の線が濃厚です。cf-turnstile の div や challenges.cloudflare.com/turnstile/v0/api.js のスクリプトが見えれば Turnstile。「Checking your browser」の中間ページなら Managed Challenge です。ホームページは開けるのに特定のパスだけ失敗するなら、エンドポイント単位の WAF か Bot Management ルールの可能性が高いでしょう。
どの方法を採るにせよ、まずは保護レベルを見極めること。これだけでデバッグの時間が何時間も浮きます。
Cloudflare 回避でまず試すべきことを決めるフローチャート
当てずっぽうではなく、優先順位に沿って進めましょう。簡単で成功率の高いものから入り、必要になったら一段ずつ上げます。
| ステップ | まず試すこと | 理由 | 失敗したら → |
|---|---|---|---|
| 1 | 内部 / 非公開 API を探す | Cloudflare を完全に迂回でき、最速で最も安定 | ステップ 2 |
| 2 | ブラウザレンダリング内蔵のノーコードツールを使う（例: Thunderbit） | 設定不要、JS チャレンジを自動処理 | ステップ 3 |
| 3 | TLS フィンガープリントの偽装（curl_cffi） | 高速・軽量、ブラウザ不要 | ステップ 4 |
| 4 | ステルス系ブラウザ自動化（SeleniumBase UC / Puppeteer stealth） | JS チャレンジとフィンガープリントに対応 | ステップ 5 |
| 5 | FlareSolverr + Docker | オープンソースでサーバー向き | ステップ 6 |
| 6 | 有料スクレイピング API（ScrapingBee、ZenRows、Scrapfly など） | いたちごっこを丸ごと外部化できる | — |
考え方はシンプルで、無料で手間の少ない方法を先に回し、コードが重くて費用のかかるものは後ろへ下げる。自分の状況に近いステップから始めてください。
2026年3月のコミュニティベンチマークでは、curl_cffi がテスト対象20ドメインのうち16件（80%）を通過し、FlareSolverr はおよそ55〜70%、有料のプロキシ集約サービスは平均でおよそ97%の成功率に達したと報告されています。ただし同じスレッド内でも、Cloudflare の更新でこの数字はすぐ動くと釘を刺されています。成功率は目安で、保証ではありません。
ステップ1: 戦わずに抜ける — Cloudflare の裏にある内部 API を探す
私が見つけた4つのフォーラムスレッドは、いずれも Cloudflare と正面からぶつかるより、内部 API を探すほうを勧めていました。正直、これがいちばん賢い初手です。内部 API があれば Cloudflare をまるごと迂回でき、小細工もフィンガープリント偽装もステルスプラグインも要りません。
手順はこうです。
- Chrome DevTools を開く → Network タブへ → XHR/Fetch で絞り込む。
- ページを操作する: 検索、フィルタ、ページ送り、スクロールを行い、Network タブに JSON のレスポンスが現れないか見る。
- リクエスト URL とヘッダーを確認する。 API エンドポイントは、フロントエンドより Cloudflare の保護が弱い、もしくはかかっていないことが珍しくありません。
- リクエストを右クリック → Copy → Copy as cURL。 ターミナルや Postman に貼って試します。
- 同じヘッダー、Cookie、クエリパラメータで Python に置き換える（
requestsまたはcurl_cffiを使用）。
API が構造化された JSON を返すなら、従来型のスクレイパーそのものが不要になるかもしれません。2026年1月の Reddit スレッドがまさにこのケースで、curl_cffi でも Cloudflare に止められたユーザーが、唯一通せたのは API レスポンスを直接傍受する方法だった、という話です。
実用上のコツ: cURL のコピーで動いたら、不要なヘッダーを一つずつ削ります。sec-ch-ua、Cookie、CSRF トークン、referer は要ることがありますが、キャッシュ制御はたいてい外せます。cURL からコードへ移すときは、TLS フィンガープリントと User-Agent をそろえましょう。
制約: どのサイトにも API があるわけではありません。認証、CSRF トークン、署名付きパラメータ、セッション紐づきの Cookie が必要なこともあります。それでも動けば、保守ほぼゼロで成功率99%前後という強力な方法です。
ブラウザベースのスクレイピングで Thunderbit を試す
ステップ2: ノーコードの道 — ブラウザ拡張で Cloudflare を回避する（Thunderbit）
競合する解説の多くは、読者が Python か JavaScript を書く前提で進みます。ところがこのキーワードでたどり着くのは、リードリストを作る営業、競合価格を追う EC 担当、不動産データを集めるアナリストかもしれません。彼らは Docker コンテナを立ち上げたいわけではないのです。
ブラウザ拡張で Cloudflare を回避 Get Started Free
Thunderbit のような Chrome 拡張は、実際のブラウザセッションの中で動くため、Cloudflare の多くのチェックを自然にくぐり抜けます。Chrome 本物の TLS フィンガープリント、Cookie、ログイン状態、行動シグナルを引き継ぐので、Cloudflare からすると信頼しやすい相手です。ステルスプラグインも xvfb-run もターミナルコマンドも要りません。
手順
- Chrome ウェブストアから Thunderbit Chrome 拡張機能 をインストールします。
- Cloudflare 保護下のページを Chrome で開きます。チャレンジが出たら、ふつうのユーザーとして通過してください。Turnstile のチェックボックスを押し、「Checking your browser」のページが消えるのを待ちます。本物のブラウザを使う本物の人間なので、Cloudflare は通してくれます。
- Thunderbit のサイドバーで 「AI Suggest Fields」 をクリックします。AI がページを読み取り、「商品名」「価格」「評価」といった関連データの列を提案します。
- 提案された項目に目を通します。いらないものは外し、ほしい内容は自然な英語で書いてカスタム項目として足します。
- 「Scrape」 をクリックすると、Thunderbit が表示中のページからデータを抜き出します。
- Google Sheets、Excel、Airtable、Notion、CSV、JSON へエクスポートします。
ページネーションのあるサイトでも、Thunderbit はクリック型のページ送りと無限スクロールの両方に対応します。詳細ページがあるケース、たとえば商品リンクの一覧から各商品の仕様をまとめたい場合は、サブページスクレイピング が使え、各リンク先を巡って表を広げてくれます。
私の経験では、50〜100行ほどのデータセットなら、インストールからスプレッドシート出力まで5〜10分です。
ブラウザベースのスクレイピングが向いている場面／向いていない場面
制約も正直にお伝えします。ブラウザベースのスクレイピングは、自分のセッション速度に縛られます。数百から数千ページ規模の中くらいの作業には最適ですが、毎日スケジュールで何百万ページもクロールするなら、コードベースか API ベースのほうが向いています。
Thunderbit の Cloud Scraping オプションなら、公開サイトに一度に最大50ページまで取得でき、処理を速められます。開発者向けやより大きな規模では、Thunderbit のWeb Scraper API が JavaScript レンダリング、アンチボット対策、プロキシローテーションをまとめて引き受け、1リクエストあたり最大50〜100 URL をバッチ処理できます。
それでも、リード、価格データ、不動産物件などをほどほどの規模で集めるビジネスユーザーには、これで足りる場面が多いものです。コード不要、プロキシ不要、保守不要という身軽さが魅力です。
ステップ3: curl_cffi で TLS フィンガープリントを偽装する（軽量なコード手法）
Python に慣れていて、ノーコードがワークフローに合わないなら、curl_cffi がもっとも軽いコードの選択肢です。libcurl を Python から扱うバインディングで、本物のブラウザの TLS フィンガープリントを真似られます。requests や httpx と違い、TLS ハンドシェイクが Chrome や Safari 由来のように見えるのです。
2026年時点で、対応する偽装ターゲット には chrome136、safari184 のほか、過去の多くのプロファイルが含まれます。ライブラリは2026年4月にも PyPI へリリースされ、いまも活発にメンテナンスされています。
使う場面: Cloudflare の Free〜Pro レベルで、主にパッシブなフィンガープリントを見ているサイト。アクティブな JavaScript チャレンジや Turnstile が出ないケースです。
基本例:
from curl_cffi import requests
url = "https://example.com/products"
resp = requests.get(
url,
impersonate="chrome136",
headers={
"accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"accept-language": "en-US,en;q=0.9",
},
timeout=30,
)
print(resp.status_code)
print(resp.text[:500])
つまずきやすい点: User-Agent は偽装ターゲットとそろえてください。Chrome 136 を偽装するのに Chrome 120 の User-Agent を送ってはいけません。食い違いがシグナルになります。
制限: curl_cffi は JavaScript を実行しません。サイトが「Checking your browser」チャレンジや Turnstile を出してきたら失敗します。ブラウザチャレンジ経由で Cookie ベースのセッション状態を受け取るサイトにも不向きです。パッシブ保護だけを相手にする、速くて安い一手だと考えてください。
同系統の代替: tls-client や curl-impersonate も、似た TLS 偽装の機能を備えています。
ステップ4: ステルス系ブラウザ自動化（Puppeteer Stealth と SeleniumBase UC）
サイトが JavaScript の実行、アクティブチャレンジ、Turnstile を求めてくるなら、TLS 偽装だけでは追いつきません。必要になるのが本物のブラウザです。主な選択肢は2つあります。
- SeleniumBase UC Mode（Python）: ドキュメントでは UC Mode を、より人間らしく見せてアンチボットサービスをかわす手段として位置づけ、Cloudflare Turnstile への対応例も載っています。
puppeteer-extra-plugin-stealthを使った Puppeteer（Node.js）: いまも広く使われていますが、2026年に入って不安定さが目立つようになりました。コミュニティ報告では、CDP（Chrome DevTools Protocol）の検知フラグや、ブラウザプロファイルの食い違いが原因で失敗する例が見られます。
どちらも本物の Chromium を立ち上げつつ、navigator.webdriver、WebGL のメタデータ、プラグイン一覧といった見破られやすい自動化シグナルを書き換えます。
実際に効く設定のコツ:
- ヘッドレスではなくヘッドありモードを使う。SeleniumBase のドキュメントも、UC Mode はヘッドレスだと見破られやすいと述べています。Linux サーバーでは仮想ディスプレイを併用します。
- ビューポートのサイズと User-Agent をランダム化する。ただし互いに矛盾せず、プロキシの地理位置とも辻褄を合わせます。
- 操作の間に自然な間を入れる。読み込み間隔が200msでは、いかにも bot です。
- 初回のチャレンジを抜けたら Cookie とブラウザプロファイルを保持する。毎回解き直さずに済みます。
- 住宅プロキシと組み合わせると、IP の評判が上がります。
この方法の難点は保守です。Chrome の更新、Cloudflare の新シグナル、後手に回るステルスプラグイン、ターゲット側のパス単位 Turnstile 追加——こうした要因で、ブラウザ自動化のスタックは壊れます。ScrapeOps のベンチマーク では、タイムゾーン・言語・プロキシの地理情報が噛み合わない「フランケンフィンガープリント」が原因で、多くのステルスブラウザ構成が失敗したと報告されています。
強力なのは確かですが、運用コストは小さくなく、直し続ける時間を見込んでおいてください。
プロキシローテーション：IP がフィンガープリントと同じくらい重要な理由
ブラウザのステルス性が完璧でも、一つの IP から大量にアクセスすればレート制限に引っかかります。Cloudflare は、データセンター IP より住宅 IP とモバイル IP を圧倒的に信頼します。
- 住宅プロキシ: 2026年の入門帯では1GBあたりおよそ1.50〜8ドル超。信頼性は高い反面、価格も高めです。
- データセンタープロキシ: 安価ですが、本格的な Cloudflare 対象ではすぐ通用しなくなりがちです。
- ローテーション戦略: リクエストごとではなく、セッションごとに切り替えます。リクエスト単位で替えると、セッション紐づきの Cookie や
cf_clearanceが壊れます。1セッション内では IP、Cookie、フィンガープリントを一致させてください。
「最低これだけプロキシプールが要る」という魔法の数字はありません。少量のリード取得ならわずかな sticky 住宅セッションで足り、高頻度の価格監視なら、何百もの出口とリトライロジックが要ることもあります。
ステップ5: FlareSolverr — オープンソースの Cloudflare 回避サーバー
FlareSolverr は、Docker コンテナ内で Chromium と undetected-chromedriver を使い、Cloudflare チャレンジを解いて Cookie とヘッダーを再利用可能な形で返す、オープンソースのプロキシサーバーです。2026年5月に v3.5.0 がリリースされ、いまも活発に保守されています。
使う場面: 毎晩走る自動ジョブのように、チャレンジを解き続けるサービスをサーバーサイドのパイプラインに組み込みたいとき。たとえば cf_clearance Cookie を定期的に取り直すケースです。
仕組み: スクレイパーが FlareSolverr の API へ URL を送ると、FlareSolverr がブラウザでページを開き、チャレンジ解決を試み、HTML と Cookie を返します。返ってきた Cookie は、通常の HTTP クライアントで次のリクエストに使い回せます。
セットアップの概要: Docker Compose でコンテナを立ち上げ、ローカルの API エンドポイントへ POST します。ScrapeOps にわかりやすい手順があります。
正直に言うと、限界もあります:
- 対話式の Turnstile や Enterprise Bot Management を安定して解くことはできません。
- GitHub issues や Reddit スレッド では、チャレンジの検知漏れ、Turnstile のタイムアウト、ページのクラッシュなど、挙動の不安定さが報告されています。
- Docker のインフラと継続的なメンテナンスが欠かせません。
- リソース消費が大きく、解くたびにブラウザコンテキストを立ち上げます。
成功率の目安は、中程度の保護対象でおよそ60〜80%。Enterprise では下がり、単純なチャレンジページなら高めに出ます。FlareSolverr で手が届かないなら、有料 API の出番です。
ステップ6: Cloudflare 対応を丸ごと任せられる有料スクレイピング API
ときには、計算がはっきり物を言います。自前でステルス基盤を維持するほうが、エンジニアの工数で見ればサブスクリプションより割高になる、ということです。有料のスクレイピング API なら、フィンガープリント、プロキシ、チャレンジ解決、リトライといった面倒をプロバイダにそっくり預けられます。あなたは URL を送るだけです。
比較:
| プロバイダ | Cloudflare 対応 | JS レンダリング | 住宅プロキシ | 構造化出力 | 課金モデル |
|---|---|---|---|---|---|
| ScrapingBee | あり | あり | あり | HTML のみ | リクエスト単位のクレジット |
| ZenRows | あり（成功率99%超を主張） | あり | あり（上位プラン） | HTML、一部パース | 係数付き CPM |
| Scrapfly | あり（CF、Akamai、DataDome を明記） | あり | あり | HTML、一部パース | クレジット制 |
| Browserless | あり | あり（ヘッドレス Chrome） | あり（内蔵） | HTML、スクリーンショット | ユニット制 |
| Thunderbit API | あり | あり | あり | AI スキーマによる構造化 JSON/CSV | 無料枠 + 有料プラン |
向いているケース: 大量スクレイピング、エンタープライズ級の安定性が要る場合、自社で基盤を抱えたくない場合です。費用感は、小〜中規模でおおよそ月30〜500ドル超、エンタープライズ規模ならさらに上がります。
Thunderbit API は、生の HTML ではなく構造化データを返す点で取り上げる価値があります。Extract エンドポイント は1リクエストあたり最大50 URL をバッチ処理し、AI ベースのスキーマに沿って JSON/CSV を返します。自分で HTML を解析せず、すぐ分析に回せるきれいなデータがほしいなら便利です。
正直な信頼性スコアボード：実際に動くもの、壊れるもの
私は2025〜2026年を通して、コミュニティ報告、GitHub issues、ベンダーの主張を追ってきました。以下は率直な比較です。どれもラボの厳密なベンチマークではなく、目安だと受け取ってください。
| 手法 | 推定成功率 | 保守負担 | 壊れる条件 | コスト感 |
|---|---|---|---|---|
| 内部 API（存在する場合） | 約90〜99% | 低 | API 変更、認証追加、トークン署名化 | 無料 |
| ブラウザ拡張（Thunderbit） | 約85〜95%（実セッション） | 低（AI がレイアウト変化に適応） | 特殊な認証フロー、アクションごとの厳しい Turnstile | 無料枠あり |
curl_cffi / TLS 偽装 | 約70〜85% | 中（フィンガープリント更新） | Cloudflare が JA3 チェックを更新、アクティブ JS チャレンジが必要 | 無料 |
| Puppeteer + stealth plugin | 約70〜90% | 高（プラグイン更新が遅れがち） | CDP 検知、新しいフィンガープリントシグナル、ヘッドレス検知 | 無料 + プロキシ費用 |
| FlareSolverr | 約60〜80% | 高（Docker、依存関係のズレ） | Enterprise レベルの保護、Turnstile の対話 | 無料 + インフラ費用 |
| 有料スクレイピング API | 約85〜95% | 低（提供側が保守） | ベンダー未更新、予算超過 | 約 $30〜500+/月 |
ここでいちばん大切なのは成功率ではなく、**「壊れる条件」**の列です。どの方法にも固有の弱点があり、最善は、対象にいちばん手間の少ない有効な手段を選び、必ずフォールバックを用意しておくことです。
永遠に通用する方法はありません。Cloudflare は更新を止めません。いたちごっこは現実です。
どの方法を使っても Cloudflare の目を避けるコツ
どの方法を選ぶにせよ、いくつかの習慣を守るだけで、Cloudflare に見つかるまでの時間を延ばせます。
- レート制限を尊重する。 リクエストの間に自然な間を置きましょう。人間らしさを装うなら最低でも2〜5秒は空けたいところです。機械じみた速さで叩くのは、ブロックへの最短ルートです。
- フィンガープリントを一貫させる。 User-Agent、TLS フィンガープリント、ブラウザバージョン、タイムゾーン、ロケール、IP の地域は、同じ筋書きを語る必要があります。ドイツの IP から Chrome 136 を名乗り、
en-USロケールで Python くさい TLS ハンドシェイクを出すのは矛盾です。 - チャレンジを抜けたら Cookie とセッションを使い回す。 毎回やり直さないでください。
- セッション途中で IP を切り替えない。 Cloudflare はセッションのつながりを追っています。
- 用途と予算が見合うなら、住宅 IP かモバイル IP を使う。
- ソフトブロックに目を配る: JSON のはずがチャレンジ HTML、空っぽの表、ログインへのリダイレクト、AI Labyrinth のハニーポットに見えるページなど。
- アクセスが集中する時間帯を避ける。 運営者が WAF ルールを締めることがあります。
- フォールバック経路を組む: まず API、次にブラウザセッション、最後に有料プロバイダ。
とりわけ Thunderbit ユーザーは、ページレイアウトの変化に AI が自動で合わせるので、CSS セレクタの保守に時間を取られず、データを活かすことに時間を回せます。
法的・倫理的な注意点
本筋ではありませんが、素通りするには大事すぎる話です。
公開情報のスクレイピングには、文脈によっては米国の判例上、好意的な扱いがあります。hiQ v. LinkedIn における CFAA の解釈は最高裁の差戻し後も残りましたが、2022年に和解しており、全体像は込み入っています。新しいところでは、Reddit が Anthropic を提訴し、2025年にユーザーコメントのスクレイピングを巡る疑いを争いました。同年後半には、Reddit が Perplexity やデータスクレイピング企業も提訴しています。
EU では、個人データが関わる限り GDPR が適用され、EU AI Act には、AI 学習のための無差別なスクレイピングに関する具体的な義務があります。
実務上の目安はこうです。
- サイトの利用規約には必ず目を通す。
- Cloudflare の保護は、運営者が自動アクセスを管理したいというサインです。その意図を尊重する。
- 正当な根拠なく個人データを集めない。
- 商用や大量処理のワークフローでは、公式 API、ライセンス付きデータ、書面の許可があればそれを優先する。
- 迷ったら、自分の用途と法域について法律の専門家に相談する。
Thunderbit は、公開アクセス可能なデータを使ったリード獲得、価格監視、市場調査など、正当なビジネス用途に向けて設計されています。
まとめ：最初に試すこと、次に試すこと
この記事を通していちばんの時短ポイントは、特定のツールでもコード片でもなく、まず保護レベルを見極めることでした。これさえ押さえれば、成功しようのない方法のデバッグに何時間も溶かさずに済みます。
ここから始めましょう:
- 内部 API がないか確認する（無料・高速・見落とされがち）。
- コードを書かないビジネスユーザーなら、Thunderbit の Chrome 拡張機能 を試す。実際のブラウザセッションこそ、Cloudflare に対する最大の武器です。
- 開発者で、対象がパッシブなフィンガープリントだけを見ているなら、
curl_cffiを試す。 - もっと強い対策が要るときに限って、ステルスブラウザ、FlareSolverr、有料 API へ進む。
ひとつの方法が永遠に使えることはありません。それでも、自分の規模に合うツールとフォールバック計画を組み合わせれば、403 ページを眺める時間はぐっと減ります。
さらに掘り下げたい方は、Thunderbit ブログで コードなしの Web スクレイピング、AI Web Scraping、最高の AI Web スクレイパー も解説しています。動きを見たいなら、Thunderbit の YouTube チャンネル の解説動画をどうぞ。
Cloudflare 保護サイトで Thunderbit を試す
Thunderbit AI Web Scraper を試す Get Started Free
FAQ
1. Cloudflare の保護を完全に回避できますか？
100%の成功を約束する単一の方法はありません。とくに Turnstile、JA4 フィンガープリント、AI Labyrinth まで備えた Enterprise レベルの Bot Management では難しいでしょう。もっとも信頼できるのは、本物のブラウザフィンガープリントと良質な IP 評判の組み合わせです。内部 API が見つかれば Cloudflare をまるごと避けられ、「完全回避」に近い手ですが、どのサイトにもあるわけではありません。
2. Scraping 時に Cloudflare を回避するのは合法ですか？
法域、サイトの利用規約、集めるデータの中身によって変わります。公開データのスクレイピングは、米国では一部の文脈で有利な判例があります（hiQ v. LinkedIn）。ただし、技術的なアクセス制御の回避、利用規約違反、正当な根拠のない個人データ収集は法的リスクを招きます。商用では、可能なら公式 API やライセンス付きデータを優先し、迷ったら法律の専門家に相談してください。
3. コードを書かずに Cloudflare を回避する最も簡単な方法は？
Thunderbit のように、本物の Chrome セッションの中で動くブラウザ拡張です。Cloudflare チャレンジを自動でさばき、ふつうのユーザーのようにサイトを操作したあと、抽出とエクスポートを任せられます。Python も Docker もプロキシ設定も不要です。
4. なぜある Cloudflare サイトでは動くのに、別のサイトでは動かないのですか？
Cloudflare の保護レベルは、プラン（Free、Pro、Business、Enterprise）と設定で大きく違います。Free プランで単純な JS チャレンジを抜けられる方法でも、Enterprise サイトの Turnstile や完全な Bot Management には歯が立たないことがあります。回避手法を選ぶ前に、単純な JS チェックか、Managed Challenge か、Turnstile かを見極めて、保護の階層を判断してください。
5. Cloudflare の回避手法はどのくらいの頻度で壊れますか？
ステルスプラグインや TLS 偽装のようなコードベースの方法は、Cloudflare の検知更新により、難しい対象では数週間から数か月単位で劣化します。有料 API や実ブラウザセッション系のツールは、インフラ層やユーザーセッション層で適応するため比較的壊れにくい傾向があります。内部 API は、サイトがバックエンドを作り直したり認証方式を変えたりしない限り、めったに壊れません。長い目で見れば、ひとつの方法に頼らず複数のフォールバックを持つのがいちばん安全です。
さらに詳しく読む
