ブロックされずに大規模にウェブデータを収集する方法

はじめに

スクレイパーは数百ページ程度なら問題なく動作します。しかし、数十万ページを対象にすると、リクエストの半分が403エラー、CAPTCHA、あるいは空白のページとして返ってきます。パーサーが失敗したわけではありません。対象サイトが、あなたのトラフィックが人間のような振る舞いをしないことに気づき、防御を開始したのです。

大規模なスクレイピングは、主に「目立たないこと」が鍵となります。スクレイピングする価値のあるサイトは、何らかの形でボット検知を行っており、リクエストが1つ増えるごとに、フラグが立てられる可能性が高まります。 これを克服するには、基本をしっかりと押さえる必要があります。適切なウェブスクレイピング用プロキシ、適正なリクエスト間隔、実際のブラウザと見分けがつかないリクエスト、そしてサイトが対抗してきた場合の対応策です。本記事では、ブロックが実際にどのように発生するか、そしてあらゆるアラームを鳴らさずにデータを収集し続けるパイプラインを構築する方法を解説します。

サイトが自動収集をブロックする理由

サイトがスクレイパーをブロックするのは、単に厄介者扱いするためではありません。あなたのトラフィックがサイトにコストを発生させ、秘匿したいデータを流出させてしまうからです。攻撃的なスクレイパー1台が1分間に数千ものリクエストを送信すれば、サーバーに負荷をかけ、分析データを歪めてしまいます。価格、商品リスト、レビューはまさに競合他社が欲しがる情報であり、そうしたデータを保有するサイトはそれを最も厳重に守ります。ターゲットとなるサイトは、あなたのような存在に対してすでに対策を講じていると想定してください。

ブロックシステムの判断基準

ブロックは、単一のルールによることはめったにありません。ほとんどの防御システムは、訪問者ごとに累積スコアを記録しており、ある閾値を超えるとCAPTCHAが表示されたり、アクセスが遮断されたりします。そのスコアは、「あなたが誰か」「どのくらいの速さで動作するか」「近くで見るとどのような特徴があるか」という3つの質問に答えるものです。

「あなたが誰か」はIPレピュテーションです。既知のデータセンターのIP範囲や、過去に不正行為を行ったアドレスは、最初から不利な評価を受けます。「どのくらいの速さで動作するか」はリクエストレートです。「どのような姿か」はフィンガープリント、つまり送信するヘッダーとTLSハンドシェイクであり、これによって実際のブラウザか、単なるスクリプトかが見破られます。

CloudflareとAkamaiは、これら3つの要素をすべて統合し、リクエストごとにリアルタイムのスコアを算出しています。これが、同じコードを実行しているにもかかわらず、あるスクレイパーが小規模なサイトではスムーズに動作する一方で、保護されたサイトでは壁にぶつかってしまう理由です。

スケーラビリティのためのプロキシプールの構築

まずは自身の立場を把握することから始めましょう。1つのIPアドレスでは大規模な作業を処理できないからです。1つのアドレスから10万件のリクエストを送信すれば、すぐにレピュテーションチェックに引っかかってしまいます。プロキシプールを使えば、負荷を多数のIPアドレスに分散させ、特定のアドレスが際立つことを防げます。これは、あらゆる大規模データ収集環境の基盤となるものです。ここで選択するウェブスクレイピング用プロキシが、下流のすべての処理能力の上限を決定します。

保護が弱い、あるいは保護されていないサイトでは、データセンターIPが重責を担います。これらは安価で高速、かつ大量に入手可能です。大量処理を行う場合は、1日で使い切ってしまうような少数の共有アドレスではなく、大容量のデータ収集用に構築されたデータセンターIPを選ぶべきです。 ただし、これらのIPは検知されやすいという欠点があります。TorchProxies（2026）によると、データセンタープロキシは保護されていないターゲットに対しては60～90％の成功率を示しますが、CloudflareやAkamaiのボット対策が導入されているサイトでは、その成功率は20～40％に低下します。

必要なIP数の算出は単純な計算です。あるサイトがIPあたり1分間に約10リクエストまで許容し、6,000リクエストが必要な場合、最低でも600個のクリーンなIPが必要となり、さらにフラグが立てられたIPへの余裕分も加える必要があります。

リクエストのペース制御とローテーションロジック

次は、処理の速度です。ローテーションはどのIPが各リクエストを受け取るかを決定し、ペーシングはリクエスト間の間隔を決定します。

リクエストごとのローテーションでは、各呼び出しに新しいIPを割り当てます。これは、個別の商品ページのようなステートレスな処理に適しています。スティッキーセッションでは、関連するリクエストの処理中に1つのIPを維持します。これは、チェックアウトのようにサイトがセッションを追跡する場合に必要です。

ペーシングの調整次第で、スクレイピング時にブロックを回避できるか、あるいはブロックに直撃するかが決まります。 リクエスト間の遅延をランダム化してください。200msという一定の間隔は、それ自体がボットのシグナルとなるからです。IPごとのレートに上限を設け、指数関数的バックオフを追加することで、エラーが発生した際に無理に処理を続行するのではなく、速度を落とすようにします。上のグラフがその理由を示しています。ブロック率は、ターゲットの許容範囲を超えるまではゼロ付近で推移しますが、それを超えると急上昇します。RankTrackerのSEOツール向けウェブスクレイピングガイドでは、同じペーシング手法がランクトラッカーの精度を維持する仕組みが解説されています。

ヘッダーとフィンガープリント

最後は、リクエストが「どのように見えるか」です。クリーンなIPアドレスで適切なペース配分を行っても、リクエスト自体がスクリプトであることを露骨に示していれば、依然として検知されてしまいます。すべてのリクエストにはヘッダーとTLSフィンガープリントが含まれており、検知システムはこれら両方を実際のブラウザと比較します。

まずはUser-Agentから始めますが、それだけにとどまってはいけません。実際のブラウザは、Accept、Accept-Language、Accept-Encodingヘッダーを一致したセットで一貫した順序で送信します。これらを省略したり順序を乱したりするリクエストは目立ちます。その下にはTLSハンドシェイクがあり、これはJA3フィンガープリントに集約されます。 PythonクライアントとChromeは、目に見えるヘッダーが一致していてもハンドシェイクの仕方が異なるため、強力なボット対策システムはハンドシェイクを読み取り、表面だけを偽装したスクレイパーを検知します。各リクエストを、最初から最後までブラウザのように見せかけましょう。

CAPTCHAとソフトブロックの対処

すべてのブロックが明示的なフラグを掲げるわけではありません。ハードブロックは明白です。CAPTCHA画面や403エラーなどです。一方、ソフトブロックは隠れています。サイトは200を返しますが、ボディはスロットリングされたり、内容が薄められていたり、あるいは知らされずにデータセットを台無しにするための誤ったデータが混入されていたりします。

検知が最優先事項です。不審なほどデータ量が少ないレスポンスや、本来異なるはずのページ間で同一のレスポンスをフラグ付けし、ステータスが「成功」と表示されていても失敗として扱ってください。不正な入力データは、それに基づいて構築されたすべてを台無しにするため、データ品質のチェックはアクセスと同様に重要です。Ranktrackerの「正確な順位追跡ガイド」では、ノイズの多い入力データが報告する数値をいかに台無しにするかが説明されています。

CAPTCHAが表示された場合、それを解くサービスは存在しますが、より安価な解決策は上流工程にあります。リクエストレートを下げ、ローテーションを増やし、フィンガープリントをクリーンアップすれば、CAPTCHAの表示自体を防ぐことができます。

いつ住宅用IPに移行すべきか

場合によっては、IPティア自体が限界となることがあります。トラフィックのペース調整や偽装をどれだけ工夫しても、ボット管理システムによってデータセンターのIPプールがブロックされ続ける場合は、上位のティアへ移行すべきサインです。

住宅用IPは実際の家庭用デバイスから取得されるため、データセンターのIP範囲では決して得られない信頼性を備えています。手強いターゲットに対しては、ローテーション式の住宅用IPに切り替えることで、一般的な家庭ユーザーと見なされるトラフィックが得られ、データセンターのアドレスを即座に拒否するフィルタを回避できます。

その代償は速度とコストです。ProxyWingによると、データセンタープロキシの処理速度は3～10倍速く、データセンターが概ね200ms未満であるのに対し、住宅用は500msから2秒かかります。数百万件のリクエストではこの差が累積するため、階層化しましょう。デフォルトはデータセンターのままにし、ブロックされたリクエストのみを住宅用へルーティングします。

検索結果はその典型的な例です。RanktrackerのSERP Checkerのようなツールにデータを供給するためにSERPをスクレイピングする場合、最も処理が難しいページほど、住宅用プロキシにリダイレクトされてしまうことがよくあります。

スケールアップする前に、1つのターゲットでテストを行う

スクレイパーをターゲットリスト全体に向ける前に、保護されたサイトを1つ選んでテストを実行し、レスポンスコードを確認してください。まずは小規模なデータセンタープールから始め、控えめなペースで実行し、ブロックが発生するまでレートを引き上げ、その後、最後にブロックされなかったレベルまで戻します。その数値がIPごとの上限となり、ジョブ全体のプールサイズを決定する基準となります。1つのサイトでウェブスクレイピング用のプロキシとペース配分を適切に設定できれば、同じ設定を他のサイトにも拡張できます。

よくある質問

大規模なスクレイピングを行うには、何台のプロキシが必要ですか？

対象サイトの許容範囲と、あなたのスループットによって異なります。1つのIPがフラグを立てられる前に耐えられる1分あたりのリクエスト数を算出し、目標レートでそれを割り、さらにバッファを加算してください。IPあたり10リクエストまで許容するサイトに対して、1分あたり6,000リクエストが必要ですか？ それなら、600以上のクリーンなIPが必要であり、ほんの一握りのIPを酷使するわけではありません。

ウェブスクレイピングには、データセンタープロキシとレジデンシャルプロキシのどちらが適していますか？

どちらにも絶対的な優位性はありません。データセンター型は高速で安価であり、保護されていないサイトには問題なく対応できます。住宅用プロキシは速度が遅く高価ですが、厳格なボット対策にも耐えられます。ほとんどのパイプラインでは両方を併用し、デフォルトではデータセンター型を使用し、ブロックされた場合にのみ住宅用プロキシに切り替えます。

プロキシを使っているのに、なぜブロックされてしまうのですか？

通常は、IPアドレスそのものではなく、アクセスペースやフィンガープリントが原因です。大規模なプロキシプールをローテーションさせても、デフォルトのヘッダーでマシン並みの速度でリクエストを送信すれば、そのパターンは依然として検出されます。速度を落とし、ランダム化し、まずブラウザのように振る舞うようにしましょう。

公開データのスクレイピングは許可されていますか？

これは法的なグレーゾーンであり、管轄区域やサイトの利用規約によって状況が異なります。一般に公開されているデータに限定し、可能な限りrobots.txtを遵守し、個人データには手を付けず、大規模な商用目的のデータ取得を行う前には法的助言を求めてください。