ローカルでは動くスクレイピングスクリプトでも、オンラインでしばらく実行するとブロックされることがあります。主な原因は、リクエスト頻度、リクエスト特性、レンダリング環境など複数のシグナルが重なることです。安定運用には、robotsのルールを守り、頻度を抑え、公開データだけを取得する方針が重要です。
ローカルでは問題なく動いていたスクレイピングスクリプトが、オンラインでしばらく実行すると止まることがあります。403が返る、検証ページへリダイレクトされる、あるいは空のHTMLしか取得できない。こうした現象の背景には、たいてい同じ判断があります。サイト側の防御機構が、そのアクセスを通常のユーザーらしくないと判定したのです。
なぜスクリプトは次々に通用しなくなるのか
アンチボット対策は単一の技術ではなく、複数の判定レイヤーを重ねたものです。最初に問題になりやすいのは頻度です。同じIPから短時間に同じパスへ大量のリクエストが送られ、しかも間隔がきれいに一定なら、非常に検出しやすいパターンです。検出されると、まず速度制限がかかり、深刻な場合はIP自体がブロックされます。
次のレイヤーはアイデンティティです。スクリプトライブラリのデフォルトUser-Agentを使っている、通常のブラウザが送るヘッダーが欠けている、Chromeを名乗っているのに対応するJavaScript実行環境やレンダリング結果がない、といった不整合は判定材料になります。CDNの背後にあるサイトではJavaScriptチャレンジが追加されることもあります。まずコードが返され、それを実行して初めて内容が得られる仕組みです。単純なHTTPリクエストライブラリでは実行結果を生成できないため、そこで止まります。
行動面のシグナルも目立ちます。実際のユーザーは画像やCSSを読み込み、スクロールし、途中で停止します。スクリプトはHTMLだけ取得して終わることが少なくありません。サイトはこうしたシグナルをまとめてスコア化し、しきい値を下回るとCAPTCHAを表示します。
この仕組みは今も進化しています。防御側が判定ロジックを変えるたびに、固定パラメータや固定テンポに依存するスクリプトは書き直しが必要です。パラメータを足すほどスクリプトは肥大化し、かえって自然な挙動を維持しにくくなります。1本のスクリプトであらゆるサイトに対応できるという前提自体が現実的ではありません。
なぜ防御の回避は選択肢にならないのか
防御を回避する方法を説明する記事は多くありますが、これは単なる技術選択ではありません。サイトの規約違反になり得ます。利用規約では、セキュリティ対策やアクセス制限の回避を禁止していることが一般的です。技術的に可能だからといって、契約上・法的に妥当とは限りません。
代償も具体的です。アカウントやIPの停止は最も直接的な結果です。多くの法域では、技術的な保護措置を回避してデータを取得する行為が違法となる可能性もあります。通常でない手段で得たデータは出所や完全性を追跡しにくく、後続の意思決定に使うほどリスクが高まります。技術上の問題をコンプライアンス上の問題へ置き換えるのは得策ではありません。
コンプライアンスを守る収集の基本線
まずrobotsのルールと利用規約を確認します。robots.txtには、どのパスをクロールしてよいかが示されています。単なる参考情報ではなく、サイト運営者が示した意思です。利用規約には、データ利用に関するさらに細かな制限が定められていることがあります。
公式APIがあるなら優先して使います。データ構造が明確で、ドキュメントとクォータがあり、フロントエンドの改修で一斉に壊れることもありません。クォータが足りない場合は収集量を下げるか、ビジネス窓口から上限引き上げを申請します。制限を回避するより安定した方法です。
頻度も制御します。クロールが許可されているからといって、帯域を使い切ってよいわけではありません。間隔を空け、単位時間あたりのリクエスト数を制限し、ピーク時間帯を避ける。これだけで多くの摩擦を防げます。
収集するのは公開データに限り、個人情報には触れません。ログインが必要な内容や、サイトが明確に取得禁止としているデータは収集しません。個人情報は法律で厳格に保護されており、収集には明確な法的根拠と、必要に応じてユーザーの同意が必要です。これは技術の問題ではありません。
レンダリング後の内容が必要な場合はどうするか
JavaScriptを実行しないと内容が表示されないページもあり、単純なリクエストライブラリだけでは取得できません。その場合はブラウザ自動化でページを開き、レンダリング済みDOMを読み取る方法があります。ただし、通常のペースでアクセスする、同じサイトに数十個のインスタンスを同時投入しない、サイトが自動アクセスを明確に禁止している場合は自動化を使わない、といった線を守る必要があります。
ここには混同されやすい境界があります。複数環境を扱うツールの正当な用途は、複数の合法なアカウントをそれぞれ分離して管理することです。たとえば、チームが複数顧客の管理画面へ同時にログインしてデータを確認する場合です。一方、大量の別ユーザーを装って同じサイトを収集するために使うものではありません。前者はアカウント管理、後者はアクセス制限の回避です。
よくある質問
IPを変えても、判定要素の一つが変わるだけです。ヘッダー、頻度、フィンガープリント特性が同じなら、すぐに同じ壁に当たります。IPを高頻度で切り替えること自体が異常シグナルになる場合もあります。
APIのクォータが小さい場合は、クォータに合わせて収集量を下げるか、ビジネス窓口から上限引き上げを申請します。制限回避と比べても必ずしも大幅に遅いわけではなく、データの出所をクリーンかつ追跡可能に保てます。
公開されていることと、自由に利用できることは別です。サイトの規約、データの著作権状態、その後の利用目的も確認する必要があります。個人情報が含まれる場合は特に慎重な扱いが必要です。
まとめ
スクレイピングがブロックされたということは、サイト側がすでに通常のユーザーらしくないアクセスだと判断しています。現実的な方向は二つです。アクセス挙動を通常の範囲に戻すか、公式インターフェースへ切り替えるかです。防御回避は近道に見えても、実際にはリスクを技術層からコンプライアンス層へ移しているだけです。
