ボットをブロックするサイトのスクレイピング：Cloudflare、DataDome、PerimeterX

ウェブの大部分では、スクレイピングはすでに解決済みの問題です。URL を取得し、HTML をパースすれば完了します。ところが、価格・リスティング・レビュー・在庫といった、集める価値のある本当に面白いサイトは、まさにそれをさせてくれないサイトなのです。これらは Cloudflare、DataDome、PerimeterX（現 HUMAN）、Akamai、Kasada の裏側に隠れていて、スクリプトがページを要求した瞬間に CAPTCHA や「ブラウザを確認しています」というインタースティシャル、あるいは素っ気ない 403 が返ってきます。現代のスクレイピングの難所は、ページをパースすることではありません。ページを取得することなのです。

本ガイドでは、この壁が実際にどう機能するのか——これらのシステムがチェックするシグナルと、なぜ通常の HTTP クライアントがそのすべてに引っかかってしまうのか——を説明し、その上で、問題を実際より単純だと装うことなく、スクレイパーがどう確実に突破するのかを解説します。

ボット検知の四つの層

アンチボットのベンダーは単一のチェックに頼りません。彼らはすべてのリクエストをいくつかの独立した層にわたってスコアリングし、リクエストはそのすべてで人間らしく見える必要があります。この層構造を理解することがすべてです。なぜなら、それぞれの層が異なる種類の素朴なスクレイパーを排除するからです。

「現実的な User-Agent を設定するだけ」が何年も前に通用しなくなった理由は、User-Agent が最も重要でない層にある単なる一つの文字列だからです。いくらでも Chrome 140 を名乗ればよいのですが、TLS ハンドシェイクが Python だと告げ、IP が AWS だと告げていれば、ページが読み込まれる前にすでに二つのチェックで失敗しているのです。

ベンダーが実際にやっていること

主要な三社は互いに十分に異なる挙動をするので、いま自分がどの壁と向き合っているのかを知っておく価値があります。

• Cloudflare はマネージドチャレンジを発行し、通過に成功すると、あなたの IP と User-Agent に紐づいた cf_clearance Cookie を付与します。チャレンジを通過すればその Cookie が一定期間のアクセスを買ってくれますが、IP を変えれば無効になります。
• DataDome はリクエストをリアルタイムでスコアリングし、datadome Cookie をセットします。データセンター IP や、あまりに多くのリクエストにわたるフィンガープリントの使い回しに対して攻撃的です。
• PerimeterX / HUMAN はシグナルのペイロードを POST する JavaScript センサーを実行し、_px3 系のクリアランス Cookie を付与します。強く IP に紐づいており、ある IP で発行された Cookie を別の IP から提示すると、盗用とみなされ、Cookie がない場合よりも強くブロックされます。

共通点は、クリアランス——「このクライアントは通過した」と告げる Cookie——は本物のブラウザでチャレンジを実行したときにだけ獲得でき、しかもそれを獲得した IP に紐づいている、ということです。この一点が戦略全体を決定づけます。

どの壁に、どの対処法

各ベンダーはそれぞれ独自のフィンガープリント——見分けのつく Cookie やブロックメッセージ——を残し、それぞれ異なるレバーに屈します。おおまかなフィールドガイドは次のとおりです。

パターンは繰り返されます。どのベンダーも究極的には、信頼する IP から、人間のように振る舞う本物のブラウザを見たいのです。壁が違うのは主に、この三つのチェックそれぞれをどれだけ厳格にするかという点です。

どうやって確実に突破するか

ほとんどのスクレイパーが犯す間違いは、すべてのリクエストに対して一つのこと——ステルスブラウザ、または residential プロキシ——だけをやることです。それは簡単なページでは遅く高コストで、それでいて手強いページでは脆いままです。確実なパターンはエスカレーションです。安いところから始め、特定のサイトが強いてくるところまでだけ登っていくのです。

1. Chrome 偽装 HTTP。 ただのリクエストですが、TLS と HTTP/2 のフィンガープリントを本物の Chrome に一致させます。これだけでフィンガープリントの層を通過でき、驚くほど多くの「保護された」サイトにはこれで十分です——しかもブラウザのほんの一部のコストで。
2. 本物のステルスブラウザ。 ページが JavaScript の実行を必要とするとき——Cloudflare や PerimeterX のチャレンジ——には、自動化の痕跡をパッチした本物のフィンガープリントを持つ、堅牢なブラウザエンジンのフリートに渡します。エンジンが違えば打ち破るベンダーも違うので、一つに賭けるより、フリート全体で競わせたりローテーションしたりすることのほうが重要です。
3. 新しい IP。 アンチボットは IP レピュテーション優先なので、現在の出口がフラグ付けされたら、最も効果の高い一手は単に別のアドレスを使うことです。ローテーションプールを通して複数のリクエストを一度に発射し、本物のページを最初に返してきたものを採用する——これがコインの表裏をほぼ確実な成功に変えます。なぜなら、他がブロックされていても、たいてい一つは新鮮な IP が通過するからです。

とはいえ、すべてのアドレスが同等というわけではなく、ここでコストが関わってきます。IP はレピュテーションの階層に分かれ、信頼される階層ほど高価になります。

• データセンター IP は安価で豊富ですが、最もフラグ付けされやすいものです——レンジ全体がクラウドやホスティング事業者のものだと知られているので、ベンダーはデフォルトで警戒します。
• residential IP は、プロキシネットワーク経由で調達された本物の家庭用ブロードバンドのアドレスです。ごく普通の訪問者のように見え、はるかに高い信頼を持ちますが、相応に高価です。
• mobile IP はキャリアの NAT を通した 4G/5G のアドレスで、すべての中で最も信頼されます。何千もの本物のスマートフォンが一つのアドレスを共有するため、それをブロックすると本物の顧客をブロックしてしまうリスクがあるからです。最も高価でもあり、通常はアドレスごとではなくトラフィックのギガバイト単位で課金されます。

手強い壁に対する反射的な反応は、まっすぐ最も高価な IP に手を伸ばすことです。より安上がりな手は、このセクション全体が扱っているもの、すなわちスタックに頼ることです——本物のブラウザにエスカレートし、複数のデータセンター IP を一度に競わせ、獲得したクリアランスを再利用する——こうすれば、できる限り多くの場合に低コストなアドレスで突破でき、本当に必要とする対象に対してだけ residential や mobile にフォールバックします。ページが強いてきたちょうどそのときにレピュテーションの代金を払い、それより一リクエストも早く払うことはありません。

二つの工夫が、これを確実であると同時に高速にします。

• クリアランスを再利用する。 ブラウザが cf_clearance や DataDome の Cookie を獲得したら、その短い寿命の間ドメインごとにキャッシュし、同じ IP からの後続のリクエストに付与します。そうすれば、安価なエンジンが、高価なエンジンが支払ったクリアランスに乗ることができます——成功率は高く、コストは低く。
• 本物のページだけを成功と数える。 チャレンジページも、「ブラウザを確認しています」の外殻も、403 も、すべてボディにバイト列を含む 200 を返します。それらを成功として扱うスクレイパーは、ゴミを渡してきて何も学びません。その違いを検知すること——そして外殻を返す代わりにエスカレートすること——が、見栄えのよい数字と、使えるデータとを分けるのです。

具体例：PerimeterX で保護されたページ

これらの部品が、実際の手強い対象——データセンターの出口 IP が十分に使われ、壁がすでにそれをフラグ付けしていた PerimeterX の裏側にあるニュースサイト——でどう組み合わさるかを見てみましょう。

• 一つのエンジン、一つのフラグ付き IP： 単一のステルスブラウザに、その焼けた IP からページを取得するよう求めても、成功したのは約 6 回に 1 回 だけでした。エンジンには能力がありましたが、IP がボトルネックだったのです。
• 新しい IP を競わせる： 同じページに対して四つのリクエストを、それぞれ異なる出口 IP を通して同時に発射し、本物の記事を返してきた最初のものを採用したところ、成功率は 6 回に 5 回 に跳ね上がりました——しかもより速くなりました。勝者はたいてい数秒で返ってくる一方、ブロックされた試行は打ち切られたからです。
• クリアランスを再利用する： ひとたび一つのブラウザが PerimeterX のクリアランス Cookie を獲得すると、単体では決して壁を打ち破れない軽量なエンジンでさえ、そのキャッシュされた Cookie に乗ってまっすぐフルページにたどり着きました。高価なリクエストがクリアランスの代金を払い、安価なリクエストがそれを換金したのです。

これらのどれ一つとして特効薬ではありません。結果は、それらを積み重ねること——ブラウザにエスカレートし、新しい IP を競わせ、うまくいくものを再利用すること——から、そしてチャレンジページを勝利と数えることを拒むことから生まれます。最後の点は間違えやすいものです。素朴な版は、何も入っていない 200 を返しておきながら、素晴らしい成功率を報告するのです。

自分で作るか、それとも買うか

これらすべてを自分で組み立てることはできますし、単一の対象になら週末プロジェクトとして妥当です。ステルスパッチを当てたブラウザ、プロキシ、Cookie キャッシュ。コストは後から、ランニングマシンとして現れます。

自分で作るということは、パッチを当てたブラウザエンジンのフリート（パッチは Chrome のリリースごとに古びます）、residential や mobile のプロキシ予算（あなたの天井を実際に決める費目）、サイトごとに最も安い手法を選ぶエスカレーションロジック、チャレンジページに騙されない成功検知、そしてベンダーが検知アップデートを出すたびにそのすべてを再修正し続ける常設のコミットメントを、抱え込むことを意味します——それは彼らの本業であり、あなたにとっては、本来のクエストを絶えず邪魔してくるサイドクエストなのです。

買うということ——マネージドなスクレイピング API——は、そのランニングマシンをリクエスト単位の価格と引き換えにします。正直な比較は「API クレジット対タダのコード」ではありません。「API クレジット対、プロキシ代 プラス、製品を出荷する代わりに検知バイパスの保守に費やすことになるエンジニアリングの数週間」です。簡単なサイトが一つか二つなら、DIY が勝ちます。確実に保ち続ける必要のある、動き続ける保護済み対象のリストに対しては、保守こそが製品です——そしてそれこそが、外注する価値のある部分なのです。

Crawlora はどこに当てはまるか

これはまさに、Crawlora の Web Scraping API が作られているモデルです。単一の /web/scrape 呼び出しがそれ自身でエスカレートし——Chrome 偽装 HTTP、次にステルスブラウザエンジンのフリート、そして同時に競わせる新しい IP——ドメインごとにクリアランス Cookie を取得して再利用し、チャレンジではなく本物のコンテンツだと確認できたときにだけページを返します。きれいな Markdown（あるいは HTML、リンク、メタデータ）が返ってきて、課金されるのは成功した分だけです。

一つのリクエストは一つの呼び出しです——欲しいフォーマットを指定して、エスカレートさせましょう。

curl -X POST "https://api.crawlora.net/api/v1/web/scrape" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/product/123",
    "formats": ["markdown", "links", "metadata"],
    "render": "auto"
  }'

render: "auto" はエスカレーションのスイッチです。Chrome 偽装 HTTP から始まり、ページが要求したときにだけステルスブラウザのフリート（そして新しい IP）まで登るので、ブラウザを必要としないページにブラウザの料金を払うことはありません。同じ呼び出しを Python から。

import requests

resp = requests.post(
    "https://api.crawlora.net/api/v1/web/scrape",
    headers={"x-api-key": "YOUR_API_KEY"},
    json={
        "url": "https://example.com/product/123",
        "formats": ["markdown", "links", "metadata"],
        "render": "auto",  # escalate HTTP -> stealth browser -> fresh IP as needed
    },
    timeout=60,
)
data = resp.json()["data"]
print(data["markdown"])            # clean article text, not raw HTML
print(data["metadata"]["title"])   # parsed page metadata

コードを一行も書く前に、何を相手にしているのかだけ知りたいなら、無料の can-I-scrape-this-site チェッカー に URL を通してみてください。サイトがどの保護を使っているか、そして収集がどれだけ難しくなるかを教えてくれます。

スコープについて最後に一言。ここに書いたことはすべて公開ページに関するものです。ボット検知はログインではなく、それを突破することは非公開データに侵入することとは同じではありません——しかし、責任ある一線はやはり公開データのみであり、各サイトの利用規約と robots ディレクティブを尊重し、個人情報や著作権のあるコンテンツには手を出さないことです。法的な状況については 2026 年にウェブスクレイピングは合法か を、関連する、ゲート付き記事の問題については ペイウォールは実際どう機能するのか をご覧ください。

ほかの誰もがブロックされるサイトをスクレイピングする

一つの API 呼び出し——自動エスカレートするステルスブラウザ、ローテーションする IP、クリアランスの再利用——が、きれいな Markdown を返し、成功した分だけ課金します。毎月 2,000 クレジット無料、カード不要。

Web Scraping API を見るサイトを無料でチェックする