スクレイピングでブロックされない方法【2026年最新】レート制限からプロキシ活用まで

Webサイトをブロックされずにスクレイピングするには、robots.txtとサイトの利用規約を尊重し、リクエストを人間の閲覧としてあり得る速度に抑えて指数バックオフを実装し、完全でリアルなブラウザヘッダーを送信し、セッション内でCookieの一貫性を保ち、正当な大量トラフィックはローテーション型のレジデンシャル（住宅）IPに分散させたうえで、ステータスコードを監視してブロックの兆候を早期に捉えることが基本だと私は考えています。派手な回避テクニックより、この地道な設計の積み重ねが効きます。

ブロックされるのは運が悪いからではありません。それは、サイトのアンチボットスタックが「人間の閲覧に見えないトラフィック」、あるいは「サイトが明示的に拒否しているトラフィック」を正しく識別した結果です。本ガイドでは、価格監視、SEO順位トラッキング、広告検証、AI学習データ収集、市場調査といった正当なスクレイピングプロジェクトを安定稼働させるためのエンジニアリング手法を解説します。同時に、越えてはならない一線についても明確に示します。スクレイピング全体の仕組みを最初から押さえたい方は、Webスクレイピング完全ガイドからお読みください。

まずルールの確認から：robots.txtと利用規約

技術的な最適化に入る前に、そもそも対象サイトをスクレイピングしてよいのかを確認します。

1. robots.txtを取得してパースする。 サイトルートに置かれたこのファイルは、クローラーの立ち入りが禁止されているパスを宣言しており、Crawl-delayディレクティブが含まれていることも少なくありません。これを守ることは、プロジェクトが誠実に運用されている最も明確なシグナルであり、成熟したスクレイピングフレームワークの多くは自動的に遵守できます。
2. 利用規約を読む。 自動アクセスを全面的に禁止するサイトもあれば、特定の用途だけを制限するサイトもあります。利用規約の条項に法的拘束力があるかは法域や判例によって異なりますが（主要な判例はWebスクレイピングは合法かで解説しています）、サイトが何を定めているかを把握するのは任意ではなく最低限の義務です。
3. 公式チャネルを優先する。 サイトがAPI、データフィード、ライセンスプログラムを提供していて用途をカバーできるなら、それを使いましょう。スクレイピングより安定しており、ブロック問題自体が消滅します。
4. 収集範囲を絞る。 必要なフィールドだけを、公開ページからのみ取得し、個人を特定できる情報は除外します。GDPRをはじめとする各国の規制のもとでは、個人データには多くのスクレイピングプロジェクトが対応しきれない義務が伴います。

当サイトのコンプライアンス方針を明確に述べます。 ProxyFactsは、ペイウォールやログインウォールの回避、ソルバーファームによる大規模なCAPTCHA突破、個人データのスクレイピング、購入の自動化（スニーカーボット、チケット転売ボット、アカウント量産）に関するガイダンスは一切提供しません。本記事で扱うブロック回避のエンジニアリングは、正当なアクセスを安定させるためのものであって、許可されていないアクセスを手に入れるためのものではありません。

サイトがスクレイパーをブロックする理由を理解する

アンチボットシステムは、人間には生じ得ないパターンを探しています。検知レイヤーを知れば、何を直すべきかが分かります。

ここから2つの結論が導けます。第一に、IPローテーションだけでは1つのレイヤーしか解決しません。IPをローテーションしていてもUser-AgentがPythonのデフォルトのままなら、第二レイヤーで捕まります。第二に、各レイヤーは相互に影響します。ヘッダーは一貫しているのにセッションが支離滅裂という状態は、どちらか片方の欠陥よりも疑わしく見えます。効果的なブロック対策とは、すべてのレイヤーが同じ、そして真実のストーリー、つまり「まっとうなクライアントが常識的な回数のリクエストを送っている」と語るようにすることです。

レート制限とバックオフ：最も効果の高い対策

回線速度の限界までリクエストを送るのは、ブロックされる最短ルートです。対策のコストはほぼゼロです。ブロックの原因を切り分けるなら、私はプロキシを疑う前にまずこの層を確認します。

• 控えめなベースラインを設定する。 多くのサイトでは、ドメインあたり数秒に1リクエストが妥当な出発点です。robots.txtにCrawl-delayが宣言されていれば、それは目安ではなく下限として扱います。
• ジッターを加える。 リクエスト間の待機時間をランダム化します（例：基準となる待機時間に0.5〜1.5のランダム係数を掛ける）。完全に規則的な間隔は機械の署名そのものです。
• 指数バックオフを実装する。 HTTP 429や503を受け取ったら待機し、1秒、2秒、4秒、8秒と待機時間を倍々にしながらリトライします（上限は常識的な値で頭打ちに）。レスポンスにRetry-Afterヘッダーが含まれていれば、その値に正確に従います。
• 同時実行数はグローバルではなくドメイン単位で管理する。 20のワーカーを20サイトに分散させるのは問題ありませんが、1サイトに20ワーカーを向けるのは攻撃に見えるバーストです。
• ピーク時間帯を避けてスケジュールする。 ECサイトをトラフィックのピーク時にクロールすると、実際の顧客とサーバーリソースを奪い合うことになります。オフピークのクロールは礼儀にかなうだけでなく、負荷ベースの防御を作動させる可能性も下がります。

これらのルールを守るスクレイパーは、小〜中規模のジョブであれば追加のブロック対策がまったく不要な場合も少なくありません。以下の内容が重要になるのは、主に規模が大きくなってからです。

リアルで一貫性のあるヘッダーを送る

HTTPクライアントのデフォルトヘッダーは、あなたの正体をそのまま宣伝しています。分かりやすい痕跡から直しましょう。

1. 実在するブラウザのUser-Agentを設定する。 現行のChromeやFirefoxの文字列を使い、ライブラリのデフォルトや何年も前のブラウザバージョンは避けます。
2. そのブラウザが送るヘッダー一式をすべて送る。 Accept、Accept-Language、Accept-Encoding、さらに最近のChromeが含めるSec-CH-UA系のクライアントヒントヘッダーです。ChromeのUser-Agentなのにクライアントヒントがないのは、フィンガープリントシステムが見逃さない矛盾です。
3. ヘッダーの内部整合性を保つ。 Accept-LanguageはIPが主張する地域と一致させます。日本のレジデンシャルIPにen-USだけのAccept-Languageを組み合わせるのはミスマッチです。
4. Refererをもっともらしく設定する。 サイトの深い階層のページには通常どこかから辿り着くものであり、無から召喚されるものではありません。
5. User-Agentのローテーションは控えめに、正しく。 ローテーションする場合は、一貫したヘッダー一式を丸ごと入れ替えます。あるブラウザのUser-Agentに別のブラウザのクライアントヒントを混ぜるのは厳禁です。

対象サイトがJavaScriptでコンテンツをレンダリングし、非ブラウザクライアントにチャレンジを課す場合、ヘッダーの工夫だけでは足りません。本物のヘッドレスブラウザが必要になり、その段階ではスタックを自前で構築するよりマネージドのスクレイピングAPIのほうが合理的なことも多くなります。私が判断するなら、Chromeの更新のたびに検知対策との整合を取り直す保守コストまで含めて比較します。損益分岐点はスクレイピングAPIとプロキシの比較をご覧ください。

セッションとCookieを意図的に管理する

サイトはCookieで訪問者の連続性を追跡しています。スクレイパーが検知されるのは、その連続性が途切れたときです。

• 論理的なセッションの中ではCookieを受け入れて保持する。 セッションCookieを受け取っておきながら一度も送り返さないクライアントは、壊れているか敵対的に見えます。
• IPとCookieジャーをペアで管理する。 同じセッションCookieが10分間に3つの国から届くのは「あり得ない移動」です。IPをローテーションするなら、Cookieジャーも一緒にローテーションします。
• セッションタイプをジョブに合わせる。 数千の独立した商品ページを取得するようなステートレスなタスクには、永続CookieなしのリクエストごとのIPローテーションが適しています。検索結果のページネーションや複数ページにわたるリスティングの巡回といったステートフルなフローには、処理が終わるまでIPとCookieを固定するスティッキーセッションが必要です。
• セッションは人間らしく失効させる。 1つのサイトを72時間閲覧し続ける人はいません。もっともらしい寿命でセッションのアイデンティティを引退させ、新しく始めましょう。

主要なレジデンシャルプロキシプロバイダーがセッション制御を提供しているのは、まさにこのためです。各社の製品ページ（2026年7月取得）によると、Oxylabsはローテーションに加えて最大24時間のスティッキーセッション、Decodo（旧Smartproxy）はリクエストごとのローテーションと数分から数日までのスティッキーセッション、IPRoyalは最大7日のスティッキー間隔、Bright Dataはスティッキーとローテーションの両モードを提供しています。どの長さが必要かは、最も長いステートフルフローの所要時間だけで決まります。

正当な大量アクセスのためのローテーション型レジデンシャルIP

プロジェクトが正当に規模を必要とする場合、たとえば毎日100,000の商品ページを監視したり、20か国から検索順位をチェックしたりする場合、単一のIPでは常識的なIPあたりレートを超えずに負荷を賄うことはできません。リクエストをレジデンシャルIPのプールに分散すれば、IPあたりのリクエストレートを人間の閲覧としてあり得る水準に保ちながら、ジョブ全体を予定どおり完了できます。また、レジデンシャルIPは一般消費者としての通常のレピュテーションを持っており、多くのサイトが一括ブロックするデータセンターIPレンジとは扱いが異なります。基礎はレジデンシャルプロキシとはの解説をご覧ください。

当サイトが追跡している4社は、以下のブロック対策関連の仕様を公表しています（数値はすべて2026年7月に各社の製品・ポリシーページから取得。プール規模はベンダー公称値であり、独立検証はしていません。料金はいずれも米ドル建てです）。

最後の行に注目してください。信頼できるプロバイダーはいずれも顧客審査を行っています。彼らのビジネスは、不正利用をネットワークから締め出すことで成り立っているからです。Bright Dataはレジデンシャルネットワークへのアクセスを、人間がレビューするKYCプロセスを通過した認証済み企業に限定しています（KYC FAQより）。Oxylabsはサインアップ時に全顧客へKYCフォームの提出を求め、リスクに応じて審査を強化します（KYCおよび安全性ポリシーより）。Decodoは全登録に対して自動不正チェックとKYCを実施し、銀行やチケット販売などハイリスクなターゲットを積極的にブロックしています（セキュリティ・コンプライアンスページより）。IPRoyalは第三者プロバイダーのiDenfyを通じてKYCを実施しています（KYCポリシーより）。あなたのユースケースがベンダーのコンプライアンス審査を通過できないなら、問題はベンダーではなくユースケースの側にあります。

エンジニア視点（友田）: この表で私が最初に見る数字は、プール規模ではなく1GBあたりの単価です。レジデンシャルは帯域課金なので、画像やCSSまで律儀に取得すると請求は簡単に数倍へ膨らみます。私が価格監視のパイプラインを組むなら、まずHTMLだけを取得して圧縮を効かせ、1ページあたりの転送量を実測してから月間コストを逆算します。転送量を絞る工夫は、どのプロバイダーを選ぶかよりも先に効く最適化だと考えています。

正当な大量アクセスにおける実践的なローテーション指針は次のとおりです。

• プールの規模はレートに合わせる。見栄で選ばない。 重要なのは、具体的なターゲットに対して「IPあたり・時間あたりのリクエスト数」が人間の閲覧としてあり得る範囲に収まることであって、カタログ上のプール数ではありません。ProxywayのProxy Market Research 2026（データ収集は2026年3〜4月）によれば、公称レジデンシャルプールの中央値は5,400万IPであり、主要プロバイダーはどこも、正当なジョブが必要とする以上のアドレスを持っています。
• 地域ターゲティングは目的をもって使う。 日本の価格を監視するなら、日本のIPをリクエストし、日本向けに一貫したヘッダーを送ります。地域ターゲティングは現地の実ユーザーが見ているものを見るための機能であって、地域単位のバンを回避するためのものではありません。
• ローテーション戦略とセッション戦略を揃える。 前述のセッション管理セクションのとおりです。

ブロック対策以外の選定基準（料金体系、トライアル、サポートなど）は、おすすめレジデンシャルプロキシ比較をご覧ください。

無料プロキシがブロック対策を悪化させる理由

この誘惑的な近道は、エビデンスの前に崩れます。NDSS MADWeb 2024で発表された、11のプロバイダーから収集した64万600件を超える無料プロキシを30か月間追跡した縦断的学術研究では、稼働が一度でも確認できたのは全体のわずか34.5%で、プロキシのIP上に4,452件の脆弱性（うち1,755件はリモートコード実行を許すもの）が特定され、さらに通信の途中でコンテンツを改ざんしていたプロキシが16,923件検出されました。

ブロック対策という観点でも、無料プロキシは逆効果です。同じIPを、同じターゲットを叩く他のすべての無料ユーザーと共有するため、主要サイトのブロックリストに載った「使用済み」の状態で手元に届きます。自分のリスクに加えて、他人の悪評まで相続することになるのです。詳しい議論は無料プロキシと有料プロキシの比較をご覧ください。

ブロックの兆候を継続的に監視する

ブロックは一度に襲ってくることはまれで、段階的にエスカレートします。その兆候を早期に捉えられるよう、スクレイパーを計測可能にしておきましょう。

1. ドメインごとのステータスコード内訳。 403、429、503の割合の上昇は最初の警報です。単発の失敗ではなくトレンドでアラートを設定します。
2. CAPTCHA・チャレンジページの検知。 多くのサイトは、コンテンツの代わりにチャレンジページをHTTP 200で返します。チャレンジページの特徴（タイトルのパターン、既知のマークアップ）をフィンガープリント化して失敗としてカウントしないと、成功率の指標が嘘をつきます。私が監視ダッシュボードを設計するなら、生の成功率よりこのチャレンジ検知率を先に置きます。
3. レスポンスサイズとコンテンツの異常。 これまで80 KBだった商品ページが突然5 KBしか返さなくなったり、抽出フィールドがゼロ件でパースされたりする場合、それはブロックページかダミーデータの可能性が高いです。
4. レイテンシの変化。 レスポンスが300 msから5秒へと徐々に遅くなる段階的スロットリングは、ハードバンに先立つソフトブロックのシグナルです。
5. プロキシサブネット別・セッション別の成功率。 失敗が特定のIPレンジに集中するならそのレンジを引退させ、長寿命セッションに集中するならセッション寿命を短くします。

シグナルが発火したときの正しい対応は、速度を落として原因を調べることであって、攻勢を強めることではありません。リクエストレートを半分にし、ヘッダーが現行ブラウザと一致しているか確認し、サイトの構造や規約が変わっていないかを調べてから再開します。ブロックに対して力押しで応じるスクレイパーは、一時的なスロットリングを恒久的なバンに変えてしまいます。

当サイトが意図的に扱わないこと

ブロック対策に関する質問の中には、答えを公開しないと決めているものがあります。その技術がアクセス制御を破るためだけに存在するからです。

• ペイウォールやログインウォールの回避。 認証の内側にあるコンテンツは、設計上アクセスが制御されています。その制御を自動化で迂回することは、どんなツールを使おうと不正アクセスです。
• CAPTCHAソルバーファーム。 CAPTCHAは、サイトが自動化に対して「ノー」と言っている状態です。産業規模のCAPTCHA突破は、その拒否を踏みにじるために存在します。
• 個人データのスクレイピング。 氏名、メールアドレス、プロフィール、連絡先には法的義務（GDPR、CCPA）と現実の被害リスクが伴います。信頼できるプロバイダーが利用規約でこれらのユースケースを禁止しているのには、正当な理由があります。
• 購入の自動化。 スニーカーボット、チケット転売、アカウント量産は、プロキシの評判を悪化させた張本人であり、プロバイダーのKYCプログラムはまさにこれらを排除するために存在します。

これらのいずれかを必要とするプロジェクトが抱えているのは、ブロックの問題ではなく許可の問題です。そして、それをエンジニアリングで解決することはできません。

チェックリスト：倫理的なブロック回避対策

• robots.txtと利用規約を読み、データが公開かつ非個人情報であることを確認する
• 公式APIやデータフィードがあればそちらを優先する
• ドメイン単位でジッター付きのレート制限を行い、Retry-Afterに従い、指数バックオフを実装する
• 完全で内部整合性のある、現行ブラウザのヘッダー一式を送信する
• セッション内でCookieを保持し、CookieジャーとIPをペアで管理し、セッションをもっともらしく失効させる
• 本当に規模が必要な場合のみ、KYCを実施するプロバイダーのローテーション型レジデンシャルIPを使う
• スティッキーセッションの長さを、最も長いステートフルフローに合わせる
• ステータスコード、チャレンジページ、コンテンツ異常、レイテンシをドメイン単位で監視する
• ブロックの兆候には速度を落として原因を調べることで対応し、決してエスカレートしない

このように運用すれば、ブロック対策は軍拡競争ではなく、エンジニアリングで表現された基本的な礼儀になります。サイトがブロックするのは行儀の悪いトラフィックであり、恒久的な解決策は行儀の良いトラフィックであることです。ツール、法的側面、アーキテクチャを含む全体像は、Webスクレイピング完全ガイドでご確認ください。