私たちの立場を明言します：私たちは Geonode であり、プロキシを販売しています。このテーマに関する記事のほとんどは、このプロキシを販売するために書かれているものです。正直に順位をつけると、プロキシは6位あたりで、その上位5つは無料のものです。 ペーシング、識別、キャッシュ、Retry-After の遵守、そして robots.txt の参照は、いかなるアドレスローテーションよりも多くのブロックを防ぐことができます。なぜなら、これらは症状ではなく、サイトがクローラーをブロックする真の原因——負荷と予測不可能性——に対処するからです。プロキシは、後述する特定の1つの問題に対してのみ真に役立ちます。もし最初にプロキシに頼れば、お金を費やしても結局ブロックされてしまうでしょう。
クローラーが実際にブロックされる理由
頻度の高い順に4つの原因を挙げます。
リクエスト頻度。 短時間にリクエストを多すぎたためです。これは圧倒的に最も一般的な原因であり、完全に自分のコントロール下にあるものです。 あるアドレスから1秒間に30回のリクエストがあることが問題だと判断する際、サイト側はあなたが誰であるかを知りませんし、気にも留めません。
予測不能性。 トラフィックの急増、エラーに対する再試行、同じページの繰り返しクロール、無限のURL空間への追跡など。サイト側が予測できない負荷は、予測可能な負荷よりも深刻です。
匿名性。 身元不明のクライアントによる原因不明のトラフィックは、阻止すべき問題です。身元が判明しているクライアントの場合は判断が必要ですが、多くの場合、許可されることになります。
身元を示すシグナル。 アドレスの種類、TLSフィンガープリント、ヘッダーの構成。 これらは現実的な問題ですが、このリストの最後に挙げられているのは、主にサイトがすでに「身元不明の自動化を望まない」と決定した後に重要になるためであり、また、これらを正直に変更するのが最も困難だからです。
4つのうち3つが動作に関するものであることに注目してください。業界が4つ目の要素に焦点を当てているのは、それが最も売り込みやすいからであり、最も多くのブロックを引き起こす要因だからではありません。
まずはクロールを必要としないところから始める
最も高いリターンが得られる対策であり、最も見過ごされがちな対策です。
APIの有無を確認しましょう。 多くのサイトがAPIを公開しており、それらは安定していて、構造化され、公式に承認されています。APIを提供しているサイトをクロールするのは、より多くの労力を費やして、より悪い結果に終わるだけです。
パートナーやアフィリエイトのフィードがあるか確認する。 求人、不動産、小売、旅行といった業界全体が、アグリゲーター向けに特別に大量のフィードを公開しています。なぜなら、アグリゲーターがトラフィックをもたらしてくれるからです。構築する前に確認してみましょう。驚くほど多くのサイトが「はい」と答えてくれます。
サイトマップの有無を確認する。 サイトマップがあれば、URLの一覧に加え、lastmodのタイムスタンプも得られるため、すべてを取得するのではなく、変更された部分のみを取得できます。
埋め込まれた構造化データがあるか確認する。 <script type="application/ld+json"> ブロック内の JSON-LD は、機械が読み取れるように設計されており、サイトのリデザイン後も残ります。しかも、取得しようとしていたページにすでに存在しています。
データが他の場所に存在しないか確認する。 公開データセット、アーカイブ、公式提出書類などです。
これらはいずれも、問題を単に緩和するのではなく、根本的な解決策となります。まずクローラーを作成しようとする反射的な行動は、この分野において最もコストのかかる習慣であり、だからこそ、技術的な内容よりも先にこのセクションを置いたのです。ソース階層全体については、ウェブサイトの全ページを見つける方法で解説しました。
まずはルールを確認してください
robots.txtは現在、RFC 9309として標準化されており、これを正しく遵守することは、コンプライアンスの観点からも、また自らの利益のためにも重要です。
運用上重要な点：ルールの一致は 順序ではなく特異性 によって決定されます — 最も長いルールが優先されます。5xx レスポンスは完全な拒否を意味し、「続行」を意味するものではありません。 404は制限なしを意味します；また、ファイルは起動時に一度取得するのではなく、少なくとも24時間ごとに更新されなければなりません。
メンテナンスされているパーサーを使用してください。特異性のルールとパーセントエンコーディングの正規化はどちらも誤りやすいものであり、ファイルを誤読するクローラーは、準拠していると信じ込んでいても実際には準拠していないことになります。詳細については、robots.txt ファイルの読み方で解説しました。
次に、利用規約をよく読んでください。robots.txtは許可を意味するものではありません（RFCにも明記されています）。ファイルで許可されている内容にかかわらず、サイト側が自動アクセスを禁止している場合があります。作業を始める前にこのことを知っておく方が、後で通知書で知らされるよりはるかに良いでしょう。
適切なペース配分
最も価値が高く、かつ最もコストのかからない技術的対策です。
ドメインごとに1～2秒に1回のリクエストが、妥当なデフォルト設定です。 小規模なサイトではこの頻度を下げ、ターゲット側が許容できるという証拠がない限り、この頻度を超えてはいけません。
Crawl-delay を遵守してください。ただし、robots.txt で値が設定されている場合はその値に従います。 これは標準の一部というよりは拡張機能ですが、これを順守するのにコストはかからず、誠意を示すことにもなります。
ジッター（変動）を加えましょう。 完全に等間隔のリクエストは、人間が生成するものではないという特徴があります。例えば1.0秒から2.5秒の間でランダム化すれば、コストをかけずにこの特徴を取り除くことができます。
同時接続数をグローバルではなく、ドメインごとに制限する。 8つのドメインに分散して8つの同時リクエストを行うのは礼儀正しい。1つのドメインに対して8つの同時リクエストを行うのはそうではない。
可能な限り、利用が集中しない時間帯にクロールを行う。 サイトが混雑しているときは許容度が低くなるが、夜間にジョブを実行しても追加コストはかからない。
そして、処理能力を増やす前に、実行期間を延長しましょう。 これは最も有用な視点の転換です。24時間にわたって5万ページを処理する場合、必要な同時接続数は約2つですが、同じ5万ページを2時間で処理する場合は20必要です。ジョブの迅速な完了に依存する要素が何もない場合（通常はそうである）、スケジュールの調整こそが最もコスト効率の良い手段です。 この計算については、プロキシはいくつ必要かで詳しく解説しています。
身元を明かす
直感に反するものの、常に効果的です。
User-Agent: AcmePriceBot/1.2 (+https://acme.example.com/bot)
名前、バージョン、そしてあなたが何者か、どのように連絡を取れるかを他者が確認できるURL。これには3つの、いずれも確かなメリットがあります：
**robots.txt
は、あなたを具体的に特定して対応できます。** ルールはプロダクトトークンに基づいて照合されるため、サイト運営者はあなたのクローラーに対して、他のユーザーには与えない特別な許可を与えることができます。匿名では、このようなことは不可能です。
サイト運営者は、あなたをブロックする代わりに連絡を取ることができます。 これは人々が想像するよりも頻繁に起こり、3週間後にブロックされていることに気づくよりも、はるかに良い結果となります。
アクセス許可の依頼が可能になります。 「私たちは AcmePriceBot と識別されるクローラーです。収集するデータとその理由は以下の通りです」という説明は、建設的な対話につながる可能性があります。
その対極にある方法――Chromeの文字列をコピーすること――は、偽装というよりは矛盾を生み出します。なぜなら、TLSフィンガープリントやヘッダーセットが明らかにブラウザのものではない接続上でブラウザのユーザーエージェントを装うことは、正直に実態を明かすよりもむしろ特定されやすくなるからです。この点については、curl を使ったカスタムユーザーエージェントの設定で解説しました。
キャッシュと条件付きリクエストの活用
カバレッジを低下させることなく負荷を軽減する手法。
変更されていない同じリソースを二度フェッチしてはいけません。 フェッチしたリソースを、ETagおよびLast-Modifiedの値とともに保存し、条件付きリクエストを送信します：
curl -sS -H 'If-None-Match: "abc123"' https://example.com/page
304 Not Modifiedのサイズは、ページ全体ではなく数百バイト程度です。ほとんどのページに変更がない再クロールでは、これにより帯域幅のコストと対象サイトの負荷を1桁分削減できます。
サイトマップのlastmodを活用して、そもそも何を取得すべきかを判断します。 5万ページあるサイトのうち、今日変更されたのが200ページの場合、クロール対象は5万ページではなく200ページとなります。
生のレスポンスを保存してください。 パーサーが動作しなくなった場合、再取得するのではなく、すでに取得済みのデータを再解析してください。これはコスト削減になると同時に、サイト運営者への配慮にもなります。
URLを適切に重複排除する。 末尾のスラッシュ、クエリパラメータの順序、ホスト名の大文字小文字を正規化し、トラッキングパラメータを削除する。正規化を行わないクローラーは同じページを何度も訪問し、実際よりもはるかに負荷の高いクライアントのように見えてしまう。
サーバーの指示通りにエラーを処理する
サーバーは、どうすべきかを教えてくれます。その指示に従うことが正しいだけでなく、正常な状態に戻るための最速の道でもあります。
429 Too Many Requests は、RFC 6585において、「ユーザーが所定の時間内に過剰なリクエストを送信した（『レート制限』）」ことを示すものとして定義されています。このレスポンスには、「新しいリクエストを行うまでの待機時間を示す Retry-After ヘッダーが含まれる場合がある」とされています。
503 Service Unavailable は、サーバーが「一時的な過負荷または定期メンテナンスのため、現在リクエストを処理できない」ことを意味し、サーバーは「クライアントが待機すべき適切な時間を示すために、Retry-Afterヘッダーフィールドを送信することがある」とされています。
Retry-After は、RFC 9110 に基づき、HTTP日付または秒数を指定します。Retry-After: 120は、2分間待機することを意味します。
429または503に対する正しい対応：
そのドメインへのリクエストを停止する。 速度を落とすのではなく、指定された間隔以上は完全に停止する。
Retry-Afterが指定されていない場合は、 余裕のある初期値から指数関数的にバックオフする。
その後、定常状態のレートを下げる。レートが高すぎたことが通知されたばかりだからだ。
決して即座に再試行してはならない。 レート制限中に再試行を行うと、一時的な制限が恒久的なブロックへと変わりかねず、これはクローリングにおいて最も一般的な自業自得の失敗である。
また、RFC 6585 には「ステータスコード 429 のレスポンスはキャッシュに保存してはならない」と明記されている点にも注意してください。つまり、キャッシュ層があっても、同じ過ちを繰り返すことを防ぐことはできません。
プロキシが真に役立つ場面
当社製品について、できる限り正確に説明します。
次のような場合に役立ちます： レート制限を最適化したにもかかわらず、単一のアドレスでは確保できないスループットが必要な場合； 特定の地域限定コンテンツを閲覧する必要があり、その目的が「特定の場所にいるように見せかける」ことである場合；分散型クローラーを運用しており、多数のスレッドを持つ単一のマシンではなく、個別のクライアントのように見せたい場合；あるいは、自身の過失ではないにもかかわらず、現在使用しているアドレスの評判が低い場合。
以下の場合には役に立ちません： アクセス速度が速すぎる場合 — より多くのアドレスから同じレートでアクセスしてもレートは変わらず、アドレス単体ではなくアドレスプール全体がフラグ付けされてしまいます。また、TLSフィンガープリントやヘッダー構成によってリクエストパターンが特定されている場合も同様です。これらはどのアドレスからアクセスしても付随するからです。 また、サイトが自動アクセスを禁止する利用規約を設けている場合も効果はありません。アドレスを増やしても、この状況は変わりません。
どのタイプを選ぶか： ほとんどのクローリングにはデータセンタープランが適しています。コストが大幅に安く、公開ページには通常これ以上の機能は必要ないからです。当社のデータセンタープランは 0.14 ドル/GB から利用可能です。 データセンターでのクロールが明らかに不可能な場合、または一般消費者向けネットワークのジオロケーションが必要な場合にのみ、住宅用（$0.79/GB～）に切り替えてください。数値は当社の価格ページより、2026年9月時点のものです。
意外にコストがかかるもの： ヘッドレスブラウザです。ブラウザは画像、フォント、スクリプトをすべて取得するため、帯域幅は生のHTTPに比べておよそ1桁ほど増加します。ページにJavaScriptが必要ない場合はレンダリングせず、必要な場合でも不要なリソースタイプはブロックしてください。
ハードブロックとソフトブロックの見分け方
失敗に見えないが、最もコストがかかる障害モード。
ハードブロックでは、403エラー、認証要求ページ、または接続拒否が返されます。目立ち、明白で、即座に対処が可能です。
ソフトブロックは、コンテンツが削減された状態で200を返します。アイテム数が少なかったり、フィールドが削除されていたり、データが古かったり、特定のページではなく汎用的なページが表示されたりします。成功率の指標は99％のままですが、データ品質は知らぬ間に低下していきます。洗練されたサイトでは、この種のレスポンスがより一般的です。なぜなら、何の警告もなしに予算を浪費してしまうからです。
これに対しては明確に防御策を講じましょう：
ステータスではなく、コンテンツを検証する。 ページ上で安定していることが分かっているマーカーを確認し、それが存在しない場合はエラーとして扱う。 件数を検証する。 カテゴリページにこれまで20件未満のアイテムが表示されたことがない場合、20件未満であれば失敗とみなす。 指標をターゲットごとに区分する。 12のターゲットが99％で、1つが40％の場合、平均値は健全に見える数値になります。 定期的にブラウザとの比較を行う。 1ページを手動で取得し、クローラーが取得した内容との差分を比較します。
これは、プロキシのテストが重要な理由で説明したのと同じ「サイレント・フェイル」のパターンであり、「3週間もブロックされていたのに気づかなかった」という事態が実際に発生する原因となっています。
いつやめるべきか
プロキシベンダーが最も書きたがらないセクション。
利用規約で禁止されている場合。 一部のサイトではこれを明示的に規定し、厳格に適用しています。明示された禁止事項を回避するための技術的対応は、技術的な側面を超えた影響を伴う決断となります。
停止を求められた場合。 サイト運営者からの直接的な要請があれば、議論の余地はありません。
労力が価値を上回る場合。 2週間ごとにアプローチを再構築しているようなら、そのデータのコストは価値を上回っています。これは技術的な敗北ではなく、ビジネス上の結論です。
正当な手段が存在する場合。 API、フィード、ライセンス付きデータセットなどです。正規のアクセスに対して料金を支払うことは、それを回避するために費やす開発時間よりも安上がりなことが多く、しかも不具合が発生することはありません。
サイト側がトラップを仕掛けている場合。 ターピットや生成された迷路は、サイト側のコストよりも利用者に大きな負担をかけるよう設計されています。サイト側はキャッシュされたコンテンツを提供している一方で、利用者はギガバイト単位や演算時間単位で料金を支払うことになります。この不均衡は意図的なものであり、努力を費やしても解決しません。
まずは問い合わせましょう。自分が誰で、何を必要としており、どの程度の量が必要なのかを説明するメールを送れば、議論で言われているよりもはるかに高い確率で問題が解決し、継続して利用できるアクセス権が得られます。
よくある質問
なぜクローラーがブロックされ続けるのですか？
通常はリクエストの頻度が原因です。1つのIPアドレスから短時間に過剰なリクエストが送信されることが、圧倒的に最も一般的な原因であり、これは完全にあなたの管理下にあります。その他には、予測不可能なリクエストパターン、エラー時の再試行、匿名でのアクセスなどが主な原因となっています。
ウェブサイトをどのくらいの速度でクロールできますか？
ドメインごとに1～2秒に1リクエストから始め、対象サイトがそれを許容しているという証拠がある場合にのみ速度を上げてください。robots.txtで制限が設定されている場合は、Crawl-delayを遵守してください。スループットをさらに上げる必要がある場合は、同時実行数を増やすよりも、時間間隔を広げる方がコストも低く、安全です。
プロキシを使えばブロックを回避できますか？
アドレス固有のブロックの場合に限ります。速度が速すぎると、より多くのアドレスから同じレートでリクエストを送っても、結局は同じレートとみなされ、プロキシプール全体がフラグ付けされてしまいます。TLSフィンガープリントやヘッダーによってリクエストのパターンが特定された場合、アドレスに関係なくその特徴は追跡されます。
ユーザーエージェントをローテーションすべきですか？
いいえ。セッション内でランダムにローテーションすると、訪問中にブラウザを変更しているように見えるクライアントとなり、これは偽装というよりは不整合です。連絡先URLを含む単一の正当なユーザーエージェントを使用する方が、どのようなローテーション方式よりもブロックされる頻度が低くなります。
429エラーが発生した場合はどうすればよいですか？
そのドメインへのアクセスを停止し、少なくともRetry-Afterで指定された時間だけ待ちます。そのヘッダーがない場合は、余裕のある開始点から指数関数的にアクセスを控え、その後、定常状態のレートを下げてください。レートが高すぎたことが通知されたのです。決してすぐに再試行してはいけません。
ソフトブロックされているかどうかはどうやって判断すればよいですか？
ステータスコードではなく、コンテンツに基づいて確認してください。各ページで安定していることが確認されているマーカーをチェックし、予想される項目数を検証し、成功指標を総計ではなくターゲットごとに分類し、定期的にクロールしたページとブラウザで取得したページを比較してください。
ウェブサイトのクロールは合法ですか？
管轄区域、サイトの利用規約、対象となるデータ、およびそのデータの用途によって異なります。robots.txtを遵守し、クローラーを識別し、クロールレートを適度に抑えることは一般的な慣行ですが、これらはいずれも利用規約や著作権に優先するものではありません。商業的に重要な事柄については、専門家の助言を求めてください。
最も効果的な対策は何ですか？
まずはペースを落とし、そもそもクロールが必要かどうかを確認してください。API、パートナーのフィード、またはlastmodのタイムスタンプ付きサイトマップを利用すれば、問題を軽減するのではなく根本的に解決できます。また、クロールが真に必要である場合でも、ペースを調整することで、他のあらゆる対策を合わせたよりも多くのブロックを防ぐことができます。
まとめ
この問題を扱いやすくする考え方は、ブロッキングとは「身元」に対する反応ではなく、「負荷」や「予測不可能性」に対する反応である、というものです。サイトは、読み込まれること自体には反対していません。反対しているのは、予測もできず、連絡も取れない何かから執拗にアクセスされることなのです。
この観点から考えると、効果的な対策の順序は、多くの記事が提示している順序とは逆になります。 そもそもクロールが必要かどうかを確認してください。APIやパートナーのフィードを利用すれば、この問題は完全に解消されるからです。『robots.txt』を読み、特定性マッチングや「5xxは停止を意味する」といった部分も含めて、正しく遵守してください。ペースを調整し、ジッターを加えましょう。名前と連絡先URLで自身を識別してください。積極的にキャッシュし、条件付きリクエストを使用して、変更されていないデータを再取得しないようにしてください。 Retry-After に記載されていることを実行してください。
これらはすべて無料で、インフラの購入よりも多くのブロックを防ぐことができます。プロキシは、単一のアドレスの上限を超えるスループットや、地域によって異なるコンテンツといった、真に限定された問題の解決には役立ちますが、このリストにあるその他の問題には何の役にも立ちません。
そして、最後のセクションを常に念頭に置いておいてください。利用規約を明記し、トラップを設置し、あるいは利用中止を求めてきたサイトは、何かを伝えているのです。それを技術的に回避する以外の方法は、通常はコストが安く、常に持続性が高いものです。