私たちは Geonode であり、プロキシを販売しています。これは、このようなライブラリと併せて通常推奨される製品です。率直に申し上げて、バイパスガイドを作成する予定はなく、またこの特定のケースでは、そのツールはすでに時代遅れとなっています。 2026年9月にこのパッケージを確認したところ、PyPI上のバージョンは1.2.71で、2023年4月にアップロードされたものでした。ソースリポジトリの最終更新は2025年6月でしたが、そのコミットは機能的な変更ではなく管理上のものに限られていました。 一方、Cloudflareのボット検出は、数十億件のリクエストに基づく機械学習、JavaScriptベースのヘッドレス検出、およびヘッダー順序の分析へと移行しています。JavaScriptの課題を解決するrequestsベースのライブラリでは、これらのいずれにも対応できていません。この記事で役立つ部分は、最後の3つのセクションです。
Cloudscraperがどのような目的で開発されたのか
このライブラリの説明文にはその目的が明確に記されており、今改めて読むと参考になる。
Cloudscraperは、自身を「Requestsを用いて実装された、Cloudflareのアンチボットページ（『I'm Under Attack Mode』またはIUAMとしても知られる）をバイパスするためのシンプルなPythonモジュール」と説明しています。 また、「Cloudflareのボット対策ページは現在、クライアントがJavaScriptをサポートしているかどうかを確認するだけだが、将来的には追加の対策が導入される可能性がある」と記されている。
このライブラリが解決しようとしていた問題は、典型的なインタースティシャル（中間画面）です：
Checking your browser before accessing website.com.
This process is automatic. Your browser will redirect to your requested content shortly.
Please allow up to 5 seconds...
このライブラリのアプローチは、「JavaScriptエンジン／インタプリタを使用してJavaScriptの課題を解決する」というものでした。これにより、「CloudflareのJavaScriptを明示的に難読化解除したり解析したりすることなく、スクリプトが通常のWebブラウザを容易に装うことが可能」になります。 そのドキュメントには、スクリプトが「Cloudflareのボット対策が有効になっているサイトへの初回アクセス時には約5秒間スリープ状態になる」と記載されており、その後は遅延が生じないとしています。
当時存在していた問題に対しては、これは妥当な設計でした。課題はJavaScriptパズルであり、このライブラリはJavaScriptエンジンを実行してそれを解いたのです。
READMEには、プロジェクトの更新頻度を明確に示す次のような記述もあります。「Cloudflareは定期的に手法を変更するため、このリポジトリを頻繁に更新します。」
メンテナンス状況の確認
印象ではなく事実に基づき、2026年9月に確認済み。
PyPIの最新リリースは1.2.71で、2023年4月25日にアップロードされました。 これは、作者が「定期的に変更される」と説明していた目標に対して、3年以上の遅れが生じていることを意味します。
GitHubリポジトリへの最後のプッシュは2025年6月であり、最新のコミットは「Fix owner」、「re-add gitignore」、「Correct the owner details」といったタイトルが付けられています。これらは検出機能の更新というよりは、管理作業に過ぎません。
アーカイブ化はされておらず、未解決のイシューが約36件あります。
これらは、有用なツールを作成し、MITライセンスの下で無償提供した作者に対する批判ではありません。これは単にパッケージの現状であり、このパッケージに依存しようとしている人にとって最も重要な事実です。 その価値のすべてが「敵対者」に追いつくことにあるライブラリは、リリース日がまさに仕様そのものであるライブラリです。
記事でcloudscraperが推奨されているのを見つけたら、その記事の投稿日を確認してください。出回っているアドバイスの多くは、執筆当時は正確でしたが、その後見直されていないものです。
現在のCloudflareの検知状況
この手法がもはや機能しなくなった理由について、Cloudflare自身のドキュメントから。
Cloudflareのボットスコアは1から99までの範囲で、1は「Cloudflareがリクエストが自動化されたものであるとかなり確信している」ことを意味し、99は人間によるものである可能性が高いことを示します。これは、複数のエンジンが連携して算出されます。
機械学習が検出の大部分を占めています。Cloudflareは、毎日数十億件のリクエストを分析し、「ヘッダーやブラウザのシグナルなどのリクエストの特徴」を調査して、クライアントが人間である確率を予測する「教師あり機械学習手法」について説明しています。
ヒューリスティックは既知のシグネチャと照合し、信頼度の高い検出にはスコア1を割り当てます。
JavaScriptによる検出は、「軽量で目に見えないクライアントサイドのJavaScript注入」を通じてヘッドレスブラウザを特定します。Cloudflareは、この手法について「個人を特定できる情報は一切収集しない」と述べています。
検出IDは、予測可能な挙動を特定する静的なルールです。Cloudflareの例は示唆に富んでいます。彼らは、「クライアントが、申告したブラウザが使用する順序とは異なる順序でヘッダーを送信する」場合を特定できるとしています。
この最後の点が核心です。ヘッダーの順序は、requestsベースのライブラリが制御できるものではありませんし、JavaScriptの課題を解決しても変化することはありません。TLSハンドシェイクの署名も同様で、これは送信する内容ではなく、PythonのHTTPスタックの特性に過ぎません。
つまり、モデルが逆転したのです。 2019年には「このクライアントはJavaScriptを実行できるか」という問いがあり、JavaScriptエンジンを備えたライブラリは「はい」と答えていました。現在では「このクライアントに関するすべての情報が、その主張と一致しているか」という問いとなり、Chromeであると主張するPythonプロセスは、複数の独立したシグナルにおいて同時に失敗します。そのいずれも、チャレンジの解決者が関与するものではありません。
Cloudflareは、意図的に敵対的なレスポンスも追加しています。同社のAI「Labyrinth」は、クローラーをブロックするのではなく、一貫性のある生成コンテンツを無期限に提供します。つまり、スクレイパーは成功したように見えても、実際には価値のある情報を何も収集できていない可能性があります。このパターンについては、ハニーポットトラップで取り上げました。
プロキシではこの問題が解決できない理由
これは事実であるため、自社製品に対して批判的な見解を示す部分です。
上記の検出リストを見て、そこに何が含まれているかを確認してください：ヘッダーの構成と順序、ブラウザのシグナル、機械学習によるリクエストの特徴、JavaScriptの実行特性などです。Cloudflare自身がボットスコアの算出方法について説明している内容には、IPアドレスは一切登場しません。
アドレスのレピュテーションは確かにCloudflareの総合的な判断における要素の一つであり、評判の悪いアドレスでは不利になります。しかし、それは多くの要素の一つに過ぎず、Pythonクライアントを自動化されたものと特定する要素ではありません。requestsセッションの前に住宅用プロキシを配置すれば、クライアントにクリーンなアドレスが割り当てられ、そのクライアントは依然として本来の姿そのものとして認識されます。
率直にまとめると：もし、履歴の悪い共有データセンターのIP範囲にあなたのアドレスが含まれているためにフラグが立っているのなら、より良いアドレスを使用することで改善されます。しかし、リクエストが主張しているブラウザとは異なると見なされたためにフラグが立っている場合、アドレスを変更しても状況は変わりません。私たちは、そのために帯域幅を販売するよりも、率直にそうお伝えしたいと考えています。
代わりにすべきこと
本当に役立つセクションを、最も多くの問題を解決できる順に紹介します。
公式APIの有無を確認する。 Cloudflareを利用しているサイトの多くは、正当なユーザーが正規のルートを利用できるよう、APIを公開しています。しかし、ドキュメントを探すよりも迂回方法を探すのが常となっているため、この確認は本来あるべき頻度よりもはるかに少ないのが現状です。
データフィードやパートナープログラムの有無を確認する。 業界全体として、下流の利用者向けに大量のデータを公開しているケースは多い。問い合わせてみよう。
保護された経路以外で何が利用可能かを確認する。 サイトマップ、RSSフィード、ページに埋め込まれたJSON-LD、公開データセット、アーカイブなど。求めていた特定の情報が、保護されていない場所で公開されていることはよくある。
サイト運営者に問い合わせる。 自分が誰で、何を必要としており、どの程度の量が必要なのかを説明するメールを送れば、ネット上の議論が示唆するよりもはるかに高い確率で解決します。サイト運営者が反対するのは、通常、理由の説明がない負荷に対してであり、あなた個人に対してではありません。また、これは継続的にアクセスできる唯一の手段でもあります。
ライセンス供与されたデータプロバイダーを利用しましょう。 一般的なデータ（企業情報、製品カタログ、市場データなど）については、どこかが販売しており、その価格は、購入を回避するために費やす開発コストよりも安いことがよくあります。
必要なデータを減らすことを検討してください。 多くのデータ収集では、必要以上に大量のデータが収集されています。より小規模で具体的な要求であれば、正当な手段で満たすのが容易であり、依頼する際の正当性も説明しやすくなります。
また、正当な自動クライアントを運用している場合、新たな傾向として、偽装ではなく識別が重視されるようになっています。 業界は、暗号化によるエージェント認証、エージェントごとのアクセスポリシー、場合によっては自動化されたトラフィックに対する有料アクセスへと移行しつつあります。これは、DataDomeに関する記事で私たちが説明した方向性です。サイトが識別し、許可を選択できるエージェントであることは、時間の経過とともに信頼性が低下するのではなく、むしろ高まっていく唯一のアプローチです。
すでにこれを使用しているコードがある場合
多くの人が実際に直面している状況――CloudScraper上に構築された正常に動作していたパイプラインが、突然動作しなくなった――に対する実践的な指針です。
まず、実際に何が起きているのかを特定しましょう。 「動作しなくなった」という表現には、対応が異なるいくつかの異なる障害が含まれます。例外をキャッチするだけでなく、ステータスコードとボディの最初の部分を出力してください：
import cloudscraper
scraper = cloudscraper.create_scraper()
r = scraper.get(url)
print(r.status_code, r.headers.get("content-type"))
print(r.text[:300])
403 で Cloudflare のブロックページが表示される場合は、身元が特定されたことを意味します。200 でチャレンジページが表示される場合は、チャレンジが解決されなかったことを意味します。 200 のような、一見妥当だが無関係なコンテンツが表示される場合は、タピット（tarpit）に引っかかっている可能性があります。503 のような、Cloudflare のインタースティシャルが表示される場合は、旧式のチャレンジがまだ有効であり、設定の別の部分に問題があることを意味します。それぞれが異なる原因を示しています。
次に、サイト側が変わったのか、ライブラリ側が変わったのかを確認してください。 requests だけで同じ URL を取得し、実際のブラウザでも試してみてください。ブラウザで動作し、両方の Python パスで同じように失敗する場合は、サイト側の保護が強化されており、ライブラリの設定を調整しても解決しません。requests だけで動作する場合は、cloudscraper が問題を解決するどころか、かえって問題を引き起こしていることになります。これは実際に起こり得る現象であり、cloudscraper が必要だと決めつける前に確認する価値があります。
動作を回復させようと、古いバージョンを固定しないでください。 失敗の原因は接続の向こう側にあるのであって、パッケージ自体にあるわけではありません。そのパッケージが作成された後に導入された検知方法について認識しているような、以前のリリースは存在しません。
もはや何の役にも立たない場合は削除してください。 かつては課題を解決していたが、現在は発生していない問題に対する依存関係は、サプライチェーン内で何の利益ももたらさない、メンテナンスされていないパッケージに他なりません。サイトはCloudflareのより積極的なモードをオン／オフし続けており、その期間中に構築されたパイプラインは、現在ではそのライブラリなしでも問題なく動作する可能性があります。テストしてみてください。
また、その失敗を「修正すべきバグ」ではなく、プロジェクトに関する「情報」として捉えてください。 機能するためにメンテナンスされていないバイパスライブラリを必要とする収集パイプラインは、構造的な問題を抱えているものであり、その復旧に費やす時間は、APIやフィード、あるいは相談すべき人物を見つけるために使える時間を奪うことになります。 私たちの経験上、2回目の検索の方が1回目よりも成功する確率が高いのです。
プロキシが真に活躍すべき場面
完全を期すために、これは私たちの事業分野であり、実際の活用例もあるためです。
アドレス間でトラフィックを分散させる場合。レート制限を最適化したものの、単一のアドレスがボトルネックとなっている状況です。これはスループットの問題であり、プロキシが解決する課題です。
地域限定コンテンツにアクセスする場合。特定の地域にいるように見せることが、この操作の目的そのものです。
サイトをフィルタリングするネットワークを回避する。これはサイト側の問題ではなく、ユーザー側の問題です。
広告検証とブランドモニタリング。支払った地域からの自社広告費の支出を確認します。
これらはいずれも「迂回」ではありません。いずれもIPアドレスが真の変数となるケースであり、いずれの場合も合理的な出発点はデータセンターの帯域幅（当社では0.14ドル/GBから）であり、明らかに必要と認められる場合にのみ、0.79ドル/GBの住宅用帯域幅へと段階的に引き上げるべきです。 数値は当社の価格ページより、2026年9月時点で確認済みです。
当社が決して行わないのは、ヘッダーの順序を検証する機械学習モデルを無効化できるかのような暗示を伴ってプランを販売することです。IPアドレスにはそのような機能はありません。
よくある質問
Cloudscraperはまだ機能しますか？
最新のCloudflareの保護対策に対しては、一般的に機能しません。PyPIでの最後のリリースは2023年4月であり、このライブラリは、課題が主にJavaScriptのチェックであった時代に設計されたものです。現在の検知では、リクエストの特徴に対する機械学習、ヘッダー順序の分析、およびJavaScriptベースのヘッドレス検知が使用されていますが、課題解決ツールではこれらはいずれも対応していません。
cloudscraperは現在もメンテナンスされていますか？
リポジトリはアーカイブされていませんが、最後のリリースは2023年4月であり、最新のコミット（2025年6月）は機能的なものではなく管理上のものです。変化し続けるターゲットを追跡することにその価値が完全に依存しているライブラリにとって、リリース日は事実上、仕様そのものです。
なぜCloudscraperは403を返すのですか？
Cloudflareが、ライブラリでは制御できないシグナルを通じてクライアントを特定したためです。ヘッダーの順序、TLSハンドシェイクの特性、および機械学習によるリクエストの特徴は、JavaScriptの課題が解決されたかどうかに関わらず、すべてPythonのHTTPクライアントであることを示しています。
プロキシを使えば cloudscraper は動作しますか？
いいえ、アドレスレピュテーションがフラグの具体的な理由でない限りは動作しません。Cloudflare 自身のボットスコアに関する説明には、リクエストの特徴に関する機械学習、ヒューリスティック、JavaScript 検出、ヘッダー順序のルールなどが含まれていますが、これらはアドレスが変わっても変化しません。
Cloudscraperの代わりに何を使えばよいですか？
公式API、パートナーのデータフィード、または保護されていない形で他で公開されているデータを探してください。その後、サイトに直接問い合わせることを検討してください。これは多くの人が予想するよりも頻繁に解決され、継続して機能するアクセス権を得ることができます。ライセンス供与されたデータプロバイダーを利用することは、それらを回避するために費やすエンジニアリングの時間よりも、多くの場合、費用対効果が高いです。
Cloudflareの保護を回避することは合法ですか？
利用規約違反は、ほとんどの法域において刑事上の問題ではなく契約上の問題であり、現実的な結果としてはアクセスブロックとなります。 合法性は、管轄区域、対象となるデータ、およびその使用方法によって異なります。保護措置を導入しているサイトは、その立場を表明しており、法的分析とは別に、その立場を考慮に入れる価値があります。これは法的助言ではありません。
有用なコンテンツがないのに、なぜ200レスポンスが返ってくるのですか？
「ターピット（tarpit）」に遭遇した可能性があります。CloudflareのAI Labyrinthは、クローラーをブロックするのではなく、サイトとは全く無関係でありながら、一貫性があり、事実上妥当な生成コンテンツを提供します。すべてが正常に返されますが、何も収集できないのは、これが設計上の仕様だからです。
ヘッドレスブラウザを使用すると、より効果的ですか？
ヘッドレスブラウザは、requestsベースのライブラリよりも多くのシグナルを検出できます。これは、実際のブラウザが実際のTLSやヘッダーの特性を生成するためです。ただし、帯域幅や演算リソースの消費量がはるかに大きくなり、CloudflareのJavaScript検出機能は特にヘッドレスブラウザを標的としています。これは解決策というよりは別のトレードオフであり、根本的な問題には変わりありません。
まとめ
Cloudscraperは実際の問題をうまく解決しましたが、その問題が当初想定されていた形ではもはや存在しません。最後の機能リリースから、相手側では数世代にわたる変化が起きており、ライブラリ自身のREADMEには頻繁な更新が約束されていますが、実際には3年以上も更新されていません。
その理由を理解することは、代替品を見つけることよりも有益です。かつての課題は、クライアントが JavaScript を実行できるかどうかという点にあり、JavaScript エンジンを備えたライブラリはそれに答えられていました。 現在の問いは、クライアントに関するあらゆる要素（ヘッダーの順序、TLSの特性、ブラウザのシグナル、動作など）が、そのクライアントが主張する内容と一致しているかどうかです。Chromeであると主張するPythonのHTTPセッションは、たとえ何の問題を解決したとしても、これらの要素のいくつかを同時に満たせていません。
それこそが、私たちがプロキシを「解決策」として売り込まない理由でもあります。Cloudflare自身がボットスコアの算出方法について説明している内容には、クライアントのアドレスについては一切言及されていません。より良いアドレスは、アドレスに関する問題の解決には役立ちますが、それ以外には何の役にも立ちません。
実際に効果のある方法は、地味ですが確実です。APIを見つけ、フィードを見つけ、他の場所で公開されているデータを見つけ、あるいは直接問い合わせることです。特に最後の方法は、世間で言われているよりもはるかに高い成功率を誇り、検出アルゴリズムの更新がリリースされるたびに再検討する必要がない唯一の手段です。