ウェブ収集が制限される理由：指紋認証・IPブロック・CAPTCHA・複数アカウントログイン問題の解決

ウェブ収集で403、429、CAPTCH­A、ログイン失敗が繰り返し発生した場合、正しい対処はIPローテーション、指紋偽装、あるいは「人間を装う」ことではありません。これらの兆候は通常、リクエスト頻度、アクセス範囲、認証方法、自動化の挙動がサイトが許容する境界を超えたことを示しています。回避を続けると一時的な制限がエスカレートし、利用規約、契約、著作権、データ保護規則に違反する可能性もあります。

より安定した進め方は、まず認可と利用可能なAPIを確認し、続いてリクエストを減らし、キャッシュとバックオフを整え、JavaScriptレンダリングや人間によるログインが本当に必要なページにだけブラウザ自動化を使うことです。CAPTCHAは「突破すべき技術的障害」ではなく、「一時停止すべきシグナル」として扱ってください。

まず現象から原因を絞り込む

現象	よくある原因	コンプライアンスに沿った対処
429 Too Many Requests	リクエストが速すぎる、並列度が高い、重複取得	速度を下げる、Retry-After を読む、指数バックオフを使う
403 Forbidden	未認可のパス、ポリシーによるブロック、セッション不足	権限・規約・robots.txt・認証方式を確認
CAPTCHA が出現	サイトが人間確認を要求するか自動化を遮断	タスクを停止し、手動で処理するかAPIを依頼
ログインが繰り返し失敗	Cookie 切れ、複数人によるセッション上書き、認証失敗	公式 OAuth やサービスアカウントを利用し、セッション引き継ぎを整理
ページには内容があるがスクリプトが取得できない	JavaScript レンダリング、API の非同期読み込み	公式 API を使う。許可があればブラウザでレンダリングしてから DOM を取得
セレクタが突然効かない	DOM 変更、A/B テスト、言語変更	意味的ロケータ、構造テスト、アラートを利用し、ハードコードした階層を避ける
データの重複・欠落	ページング、カーソル、タイムゾーン、更新ウィンドウの誤り	一意キー、増分ウォーターマーク、再実行機構を整備

一度に変えるのは1つだけにし、ログを残してください。IP、User-Agent、アカウント、パーサーを同時に差し替えて偶然成功しても、原因の切り分けはできません。

ステップ1：そのデータを取得する権限があるか確認する

始める前に次の4つに答えてください。

1. データは公開か、ログイン後・有料後・特定ロール限定か？
2. サイトは API、エクスポート、フィード、Webhook、パートナー用データインターフェースを提供しているか？
3. 利用規約、robots.txt、契約、現地の法令は用途を認めているか？
4. データには個人情報、著作権で保護されたコンテンツ、その他機微な項目が含まれるか？

robots.txt はサイトが自動クライアントに対して許可・禁止パスを伝える標準的な仕組みです。RFC 9309 は Robots Exclusion Protocol の文法とマッチング規則を規定しており、robots.txt はアクセス許可ではないことを明確にしています。つまり robots.txt で許可されていても、データの複製・処理・商用利用の全権利を得たことにはなりません。禁止されたパスを別の入口から迂回するべきでもありません。

企業プロジェクトでは、データソース、アクセスの根拠、目的、項目、保存期間、削除机制を文書化しておくべきです。集計データで解決できるなら、識別可能な個人情報を収集しないでください。

ステップ2：安定したデータ入口を優先する

一般的な優先度は次の通りです。

1. 公式 API、Webhook、データエクスポート；
2. 公開フィード、サイトマップ、バッチファイル；
3. 許可された通常の HTTP ページ；
4. JavaScript をどうしてもレンダリングする必要がある場合のみブラウザ自動化；
5. 人間のアカウントと操作が必要なページは最後に。

API は項目定義、ページング、レート制限、エラーコードを備えていることが多く、UI を解析するより保守コストが低くなります。Webページは人間の目向けのインタフェースであり、いつでも変更され得るため、安定したデータベースとして扱うべきではありません。

適切なインターフェースがない場合は、まずデータの所有者に連絡して用途、頻度、項目、商用規模を説明してください。明確なデータ許諾は、長期間制限と戦い続けるより大抵は安価です。

ステップ3：429 と IP ブロックは「隠す」ではなく「負荷を減らす」

速度と同時実行数の上限を設定する

単一ワーカーと長めの間隔から始め、応答時間とエラー率を観察します。サーバーが Retry-After を返したらその時間だけ待ち、返さなければ指数バックオフとランダムジッターを使い、複数のタスクが同時にリトライしないようにします。

方針の例：

待機時間 = min(上限, 基準時間 × 2^試行回数) + ランダムジッター

最大試行回数に達したら停止してアラートを上げ、無限ループにしないでください。

キャッシュと増分更新を行う

同じ URL をキャッシュし、可能であれば ETag や Last-Modified を使った条件付きリクエストを送ります。最後の更新時刻やカーソルを記録し、新規と変更分だけを取得します。全量タスクと日次の増分タスクを分けると、リクエスト量を大きく減らせます。

クライアントを正直に識別する

コンプライアンスに準拠したクローラーは安定かつ本物の User-Agent を使い、目的を明記し、連絡先ページやメールを提示します。一般ブラウザになりすましたり、頻繁に身元を変えたりすると、サイトが善意のトラフィックとそうでないトラフィックを区別しにくくなり、結果としてブロックされやすくなります。

特定の IP が制限された場合、タスクを停止して原因を確認してください。プロキシをローテーションしながらアクセスを続けることは、アクセス制御の迂回と見なされやすく、解決にはなりません。

ステップ4：指紋認証と行動分析に対応する

ブラウザ指紋は User-Agent、OS、言語、タイムゾーン、画面の解像度、Canvas、WebGL などのシグナルを組み合わせて使います。サイトはさらにリクエストの間隔、ナビゲーションの経路、セッションの行動を分析する場合もあります。OWASP は Fingerprinting、Scraping、CAPTCHA Defeat、Credential Stuffing などを個別の自動化脅威カテゴリとして列挙しており、サイトが複数のシグナルを組み合わせて自動化リスクを判断する理由になっています。

認可された作業では、「人間らしい」ID を大量に作ることは目標ではありません。環境が安定していて説明可能であることが目標です。

• 同じ業務アカウントには固定環境と正規の認証を使う；
• ブラウザの各種パラメータは実際の地域と端末と一致させる；
• ブロック回避のために指紋をランダムに変更しない；
• 収集頻度、タスク ID、責任者をログに残す；
• アカウント数、同時実行数、データ範囲についてサイト側と合意する。

認可済みタスクが誤って判定された場合は、時刻、User-Agent、出口 IP、リクエストのサンプルを提示し、ホワイトリストや専用インターフェースへの登録を依頼してください。

ステップ5：CAPTCHA が出たら自動化するのをやめる

CAPTCHA は人間の確認のため、または不審な自動化の遮断のためにあります。OCR や CAPTCHA 解答サービス、CAPTCHA 破解プラグインなどでの自動突破は避けてください。

正しいフローは次の通りです。

1. 現在のアカウントとタスクキューを直ちに停止する；
2. トリガーとなる直前のリクエスト頻度、経路、エラーログを保存する；
3. 権限のある人間が公式ページで必要な確認を行う；
4. リクエストが速すぎたのか、セッションが切れたのか、許可されていないパスにアクセスしたのかを確認する；
5. 長期的に自動化したい場合は、サイトへ API・サービスアカウント・ホワイトリストを申請する。

人間が1回 CAPTCHA を解いたとしても、その後ずっと自動リクエストをしていいということにはなりません。まず発生原因を修正してください。

ステップ6：ログインと複数アカウントは正規の権限で運用する

ログイン後のデータは公開ページより機微です。OAuth、サービスアカウント、API トークン、またはプラットフォームの公式チームが認める権限を優先し、スクリプトに個人のメインハッシュワードを保存させないでください。

ブラウザセッションがどうしても必要な場合は：

• 正当な業務アカウント1つに対して安定した環境を1つ用意する；
• Cookie は暗号化して保存し、有効期限と失効手段を用意する；
• MFA を有効化し、二要素認証を自動化で迂回しない；
• 複数人が同時にパスワードリセットしたり Cookie をコピーしたりすることを禁止する；
• 誰がいつどのタスクを起動したか記録する；
• 退職、プロジェクト終了、権限変更時には速やかにアクセスを取り消す。

複数アカウントは、実際に所有しているか利用が許諾されているアカウントにのみ使えます。サイトが1主体1アカウントに制限している場合、環境隔離を使ってその制限を突破しないでください。

ステップ7：動的ページの解析を改版に強くする

意味的で安定した属性を使う

タイトル、見出し、アクセシビリティ属性、サイトが公開しているテスト用識別子を優先してください。div:nth-child(7) のような脆い階層は避けてください。ページ更新後は DOM を読み直し、過去のノードが残っている前提を持たないでください。

抽出と業務ロジックを分離する

収集層はページから構造化フィールドへの変換だけを担い、検証層が型、範囲、一意キー、必須項目をチェックします。改版時にはパーサだけ修正すれば済み、後段の解析は壊れません。

サンプルとアラートを整備する

少量のコンプライアンスに準拠した HTML もしくは構造スナップショットをテストサンプルとして保存します。完全なアカウントページや機微なデータは保存しないでください。項目の欠落率、レコード数、重複率、ページタイトルを監視し、異常が出たら本番データの書き込みを停止します。

認可収集における PurpleMark の適切な役割

チームが複数の認可アカウント、複数顧客、複数リージョンの環境を同時に管理する必要がある場合は、PurpleMark ウェブ版で業務アカウントごとに独立したブラウザ環境を作成し、対応する Cookie、ログイン後に開く既定ページ、通常のネットワーク設定をまとめて保存できます。再度その環境を開けば、ブラウザは前回のセッションと作業ページに戻るため、複数人が同じ Cookie を共有したり、毎回ログインし直したりする手間を避けられます。

アカウントを顧客、プラットフォーム、リージョンごとに分けたいときは、環境グループで業務アカウントを分類し、メンバー権限、共有、移転で誰がどの環境を開けるかを制御できます。操作ログはどの環境がいつ、誰によって開かれたか、あるいは変更されたかを記録するため、認可収集について問い合わせがあった際に、具体的なアカウントと責任者まで迅速に追跡できます。

PurpleMark は「アカウント、環境、セッション、責任」を1つのワークスペースに長期的に管理することを助けますが、IP ブロック、CAPTCH­A、アカウント数制限、サイトの自動化対策を回避するために使うものではありません。先に権限を取得し、その上で自動化を語ってください。

保守可能な収集アーキテクチャ

次の5層に分割することをお勧めします。

1. スケジューラ層：頻度、並列度、タスク優先度、一時停止を制御；
2. アクセス層：API、HTTP、許可されたブラウザセッション；
3. 解析層：レスポンスを構造化フィールドへ変換；
4. 品質層：重複排除、型チェック、欠落アラート、バージョン記録；
5. ガバナンス層：権限、ソース、用途、保存期間、削除。

各レコードにはソース URL、収集時刻、解析バージョンを残してください。問題発生時にサイト全体を取り直さず、対象レコードだけを特定して再実行できます。

よくある質問

プロキシをローテーションすれば IP ブロックは解決しますか？

出口アドレスは一時的に変わっても、頻度・権限・行動の問題は解決しません。アクセスを続けるためのプロキシローテーションは迂回と見なされ得ます。まずタスクを停止し、頻度を下げて、サイトに連絡してください。

CAPTCHA を自動で突破できますか？

すべきではありません。CAPTCHA は一時停止や人間確認を求めるシグナルです。継続的な自動化が必要なら、API、サービスアカウント、ホワイトリストを申請してください。

robots.txt で許可されていれば必ず収集できますか？

そうとは限りません。robots.txt はアクセス許可ではなく、規約、著作権、プライバシー、契約、データの用途も考慮する必要があります。

指紋ブラウザは収集を「見つからなくする」ことができますか？

保証はできませんし、検出回避が目的であってはなりません。指紋ブラウザは、正当なアカウントセッションとチームの権限を分け、Cookie の混同や操作ミスを減らすために使う方が向いています。

まとめ

ウェブ収集の制限は単なる「対クローラー技術」の問題ではありません。403、429、指紋認証、CAPTCH­A、複数アカウント制限は、すべて権限・負荷・アイデンティティ管理の問題に収斂します。

安定的な解は常に「API 優先、認可明確、抑制されたリクエスト、増分キャッシュ、テスト可能な解析、監査可能なアカウント」です。CAPTCHA やブロックに遭遇したら、自動化の出所を隠し続けるのではなく、プロセスを止めて修正してください。