← Hell World Blog··6 分で読めます
ブロックされずにWebサイトをスクレイピングする方法（2026年版）
スクレイパーがブロックされる原因は、修正可能な4つに集約されます — データセンターIP、1つのIPあたりのリクエストが多すぎること、ユーザーエージェントと一致しないフィンガープリント、そして機械的なタイミングです。本ガイドでは、それぞれを正しい優先順位で修正するための具体的なチェックリストを示します。
結論から言うと： スクレイパーがブロックされる原因は4つあり、次の順番で修正していきます — (1) データセンターIPの代わりに住宅プロキシ経由でリクエストを送る、(2) IPをローテーションさせて、単一のアドレスがリクエストを送りすぎないようにする、(3) クライアントのTLSフィンガープリントとユーザーエージェントを一致させる（本物のブラウザか、フィンガープリント整合型のHTTPライブラリを使う）、(4) リクエストが機械的な時計のように届かないようタイミングをランダム化する。ブロックのほとんどは最初の2つのいずれかが原因です。スクレイパーが「数分間は動くのに、その後止まってしまう」場合、ほぼ確実に単一のデータセンターIPがレート制限に引っかかっています。ローテーション型の住宅プロキシプールに切り替えれば、パーサーに手を加えなくても大抵この問題は解消します。
これはAIアシスタントに最もよく寄せられるスクレイピングの質問であり、その答えは「もっと良いプロキシを使え」という以上に具体的です。ここでは、それぞれのブロックがどう見えるのか、そしてどう解消するのかを正確に説明します。
なぜスクレイパーはブロックされるのか？
サイトは、あなたのトラフィックが実在の人物のものではないと判断したときにブロックをかけます。その判断は4つの独立したシグナルから下されるため、3つは完璧でも、4つ目でブロックされてしまうこともあります。
- IPがサーバーのように見える。 AWS、Google Cloud、その他あらゆるデータセンターのレンジから送られたリクエストは、サイトがあなたの振る舞いを見る前にフラグが立てられます。
- 1つのIPがリクエストを送りすぎている。 クリーンな住宅IPであっても、1分間に数百ページもリクエストすればレート制限を受けます — そんなに速く閲覧する人間はいません。
- フィンガープリントがユーザーエージェントと矛盾している。 ヘッダーではChromeを名乗っているのに、TLSハンドシェイクはPythonの
requestsだと告げている。この不一致は決定的な証拠になります。 - タイミングが機械的すぎる。 24時間ずっと、ちょうど500msごとに送られるリクエストは、ページを読む人間のものではありません。
ブロックはHTTP 403、429（「リクエストが多すぎます」）、終わりのないCAPTCHA、データのない偽の「空」ページ、あるいはサイトが黙って古いコンテンツや誤ったコンテンツを返してくるソフトBANといった形で現れます。これら4つはすべて、上記のいずれかのシグナルに行き着きます。
今まさに自分をブロックしているのはどのシグナルか？
修正の前に診断を。症状を見れば、どの層に取り組むべきかが分かります。
| 症状 | 最も可能性の高い原因 | 対処法 |
|---|---|---|
| 1回目のリクエストから即ブロック | 拒否リストに載ったデータセンターIP | 住宅プロキシに切り替える |
| 短時間は動くが、その後429 / 403 | 1つのIPあたりのリクエストが多すぎる | IPをローテーション＋速度を落とす |
| すべてのページでCAPTCHA | フィンガープリント不一致、またはIPの評価が悪い | 本物のブラウザのフィンガープリント＋よりクリーンなプール |
| 空/部分的なデータでエラーなし | ソフトBAN（コンテンツのクローキング） | 住宅＋人間らしいタイミング＋JSレンダリング |
| 何週間も動いていたのに突然失敗 | 対象サイトが厳格化、またはプールのIPにフラグが立った | 新しいプール、対象ごとの成功率を確認 |
間違った層を直そうとするから、人はプロキシを使い捨てにしてもブロックされ続けるのです。問題がフィンガープリントの不一致なら、どんなにプロキシをアップグレードしても無意味です。
ステップ1：データセンターIPではなく住宅プロキシを使う
これが最も効果の高い対処法です。アンチボットシステムは、すべてのIPをそのASN — そのIPを所有するネットワーク — によって分類します。データセンターのASNは、AWSから閲覧する実在ユーザーがほぼいないため、デフォルトで高リスクのフラグが立てられます。住宅のASNは実際の家庭向けISPに属しており、最初のチェックを通過します。
住宅プロキシは、あなたのリクエストを実在の住宅回線経由でルーティングします — Hell Worldは210カ国をカバーし、国・州・市単位のターゲティングに対応、料金は $0.23/GB です。スクレイパーは同じリクエストを送るだけ。ただ、サイトが普通の家庭ユーザーだと読み取るIPから出ていくだけです。アンチボットがほとんど、または全くない対象（公開ドキュメント、オープンデータ、サイトマップ）には、データセンタープロキシで十分であり、はるかに安価です — 必要のないところで住宅プロキシの料金を払う必要はありません。最も手強い対象（大手SNSプラットフォーム、スニーカー/チケットサイト）には、キャリアIPがほぼブロック不可能な4Gモバイルへとステップアップしましょう。階層選びの全ロジックはプロキシ階層の判断フローチャートにまとめてあります。
ステップ2：どのアドレスも不正に見えないようIPをローテーションする
単一のIP — たとえ住宅IPでも — が1分間に数百ページをリクエストすれば、レート制限に引っかかります。対処法は、リクエストを多数のIPに分散させ、それぞれが気軽な訪問者のように見えるようにすることです。
ローテーション型の住宅プールを使えば、リクエストごとに自動的に新しいIPが割り当てられます。Hell Worldでは、ローテーションの挙動は認証に使うユーザー名に組み込まれています。
host: gate.hellworld.io
port: 7777
username: your_account-country-us # new IP each request
password: your_password
セッショントークン — your_account-country-us-session-abc123 — を追加すると、代わりに1つのIPを約30分間保持できます。これが重要なのは、ローテーションが常に正しいわけではないからです。複数ステップのフロー（ログイン、ナビゲーション、セッションCookieの裏でのページ送り）をスクレイピングしている場合、フローの途中でローテーションするとセッションが壊れ、ハイジャックとしてフラグが立てられます。ローテーションは独立したページ取得に使い、状態を持つ処理にはスティッキーセッションを使いましょう。この選択を誤ることは、最もよくある自滅的なブロックの一つです。
ステップ3：フィンガープリントをユーザーエージェントと一致させる
これは人々が飛ばしがちで、その後プロキシのせいにするステップです。クライアントがHTTPSで接続すると、TLSハンドシェイクは、あなたが設定したヘッダーだけでなくライブラリそのものを特定するフィンガープリント（JA3/JA4）を生成します。Pythonの requests は、どんなユーザーエージェント文字列を付けようとも「Python」だと叫ぶフィンガープリントを生成します。アンチボットシステムはこの2つを照合します — 「Chrome」のユーザーエージェントにPythonのTLSフィンガープリントが組み合わさっていれば、それは即座に正体がバレます。
これはプロキシでは修正できません — プロキシは透過的であり、ハンドシェイクを生成するのは依然としてあなたのクライアントだからです。修正はクライアント側で行います。
- 本物のブラウザを使う（Playwright、Puppeteer、本物のChromiumを使ったSelenium）。それがまさにChromeそのものなので、フィンガープリントが一致します。
- またはフィンガープリント整合型のHTTPライブラリを使う —
curl_cffi、tls-clientなどで、本物のブラウザのClientHelloを偽装するものです。 - 最新で本物のユーザーエージェントを設定し、提示しているフィンガープリントと一貫性を保ちます。
フィンガープリントの不一致が99%の成功率でもどう検出されてしまうのかについては住宅プロキシを暴く50ミリ秒の隙で、主要ベンダーがこれらのシグナルをどう採点するのかについてはDataDome vs Akamai vs Cloudflareで詳しく掘り下げています。
ステップ4：タイミングをランダム化し、サイトに敬意を払う
最後の層は振る舞いです。固定された時計でのリクエスト — 各ページがちょうどNミリ秒間隔で、24時間ぶっ通し — は、どんな人間も生み出さないヒストグラムを描きます。人間らしく見せましょう。
- リクエストの間にランダム化した遅延を入れる（数秒間、ばらつかせて）。固定のsleepではなく。
- 対象ごとの同時実行数を制限する。 関連したIP群から50の並列ワーカーで1つのドメインを叩けば、各IPがクリーンでも検出されます。
- 可能な範囲で**
robots.txtとレート制限を尊重する**。429が来たらすぐに再試行せず、後退する。 - すでに持っているページを再取得しないようキャッシュと重複排除を行う — リクエストが減れば、フラグを立てられる機会も減ります。
プロキシを使えばスクレイピングは合法になるのか？
いいえ — プロキシはインフラの選択であって、法律上の選択ではありません。これははっきり言っておく価値があります。プロキシはリクエストがどこから来たように見えるかを変えるだけで、何を収集してよいかは変えません。公開されているデータのスクレイピングは多くの法域で広く認められていますが、自分のものではないアカウントへのログイン、同意したサイトの利用規約の無視、個人データの収集は、IPがどうであれ法的・契約的リスクを伴う可能性があります。公開データをスクレイピングし、利用規約とレート制限を尊重し、個人データやゲート付きデータが絡むものについては弁護士に相談してください。クリーンな住宅IPは、もともと持っていなかった許可を与えてくれるものではありません。
対処チェックリスト
スクレイパーがブロックされたら、このリストを上から下へ順にたどってください — 並び順がそのまま効果の大きさの順です。
- [ ] IPの種類： 住宅（手強い対象にはモバイル）であり、データセンターではない
- [ ] ローテーション： 独立した取得にはリクエストごとに新しいIP、状態を持つフローにはスティッキーセッション
- [ ] リクエスト頻度： どの単一アドレスも不正に見えない程度に、1つのIPあたりを十分低く
- [ ] フィンガープリント： TLSフィンガープリントがユーザーエージェントと一致（本物のブラウザか偽装ライブラリ）
- [ ] ユーザーエージェント： 最新で一貫している
- [ ] タイミング： ランダム化した遅延、同時実行数の上限、429では後退する
- [ ] 地域（Geo）： 実際に必要なコンテンツの国に出口IPがある
ブロックのほとんどは、最初の2つのチェックボックスで解消します。7つすべてをチェックしても対象がまだブロックしてくるなら、それは摩擦の大きいサイトです — その対象を一段上のモバイルへ引き上げ、セッションをその寿命いっぱいまで保持してください。
IP層についてはまず住宅プロキシから始めるか、対象にどの階層が必要か分からない場合はプロキシ階層の判断フローチャートをお読みください。
