複数アカウントでのデータ収集における関連リスクの要因と制御可能な変数

ECサイトのデータ収集は、大きく2種類に分けられます。ログイン不要の公開ページを収集する方法と、競合の管理画面データを確認したり、パーソナライズ後に表示される結果を取得したりするような、ログイン状態で行う収集です。

前者は、通常は頻度を適切に管理すれば十分です。後者で複数アカウントを使う場合、成否を左右するのはスクリプトの巧妙さではなく、各アカウントが互いに独立して存在できるかどうかです。この層が適切でないと、レート制限や停止がランダムに見え、スクリプトの変更、頻度の低下、selectorの変更を行っても改善しません。

リスクはどこから生じるのか

プラットフォームは、複数のアカウントが同じ主体によって操作されているかを複数の情報で照合します。ネットワークアドレス、ブラウザとデバイスの特性、Cookieとセッションデータ、利用パターンなどです。いずれかのカテゴリで重複が大きければ、同じ運用主体のアカウントとしてまとめられる可能性があります。

ここでは明確な線引きが必要です。検出ロジックは継続的に更新されるため、一時的な手法で対抗しても効果は短く、コストが高くなります。そのため、ここではリスク管理を回避する方法は扱いません。重要なのは別の問いです。リスクの発生源を整理したうえで、どの変数を自分たちで制御し、長期的に安定させられるのか。これらの変数が、複数の正当なアカウントが互いに影響し合うかどうかを決めます。

デバイスとブラウザの特性

問題が起きやすい構成の一つは、同じマシンで複数のウィンドウを開き、別々のアカウントにログインすることです。キャッシュを消去したりシークレットモードを使ったりしても、それらのウィンドウは同じシステム環境とブラウザデータを共有しています。特性の重複は残り、プラットフォームからは1台のデバイスが繰り返しIDを切り替えているように見えます。

制御可能な方法は、アカウントごとに専用環境を用意することです。1アカウントにつき1つの独立環境を割り当て、fingerprint、Cookies、ローカルストレージを分離します。重要なのは、その環境をアカウントに固定し、起動のたびにランダムな構成を生成しないことです。ランダムな組み合わせは内部で矛盾しやすく、タイムゾーン、言語、解像度、UAが整合しないと、安定した構成よりも不自然に見えます。

結局、安定性はランダムさではなく一貫性から生まれます。

ネットワーク出口

出口はアカウントに紐づける必要があります。1環境につき1出口とし、その地域をアカウント情報、タイムゾーン、言語と整合させます。複数アカウントの環境を分離していても同じ出口を共有すれば、それまでの分離の多くが意味を失います。

出口も比較的安定させる必要があります。地域を頻繁に変えると、アカウントの所在地というシグナルを説明しにくくなります。出口を選ぶ際、一般に住宅系のアドレスはデータセンター系のアドレスより通常のユーザーアクセスに近く見えます。また、大量に使われてきたアドレスは、それ自体がより強く監視されている可能性があるため避ける必要があります。

Cookiesとセッション

セッション状態そのものがIDの記録です。複数アカウントが同じCookiesやローカルストレージを共有すると、他の環境をどれだけきれいに分離しても、アカウント間に直接的なつながりができます。

新しい環境のセッションを、最初から高い強度で使うのも適切ではありません。まず通常のブラウジングによる履歴を一定期間蓄積し、その後で作業量を段階的に増やします。この考え方はデータ収集以外でも同様で、利用履歴があるかどうかは、アカウントが無理なく処理できる活動量に直接影響します。

リクエストのリズム

リクエスト密度は行動シグナルです。スクリプトには典型的な規則性があります。アクセス間隔が固定され、ページの順序も固定され、収集以外の行動が一切ないといった特徴です。この規則性は単に乱数を加えるだけでは解決しません。問題の中心は全体の量にあるからです。

制御可能な方向は、作業量を妥当な範囲に収めることです。アカウントごとに実行時間をずらし、全アカウントを同時に最大負荷で動かさず、ページ間に適切な間隔を設け、優先度の高い収集と低い収集を分けます。境界は明確です。自分たちの収集によって対象サービスに負荷をかけてはいけません。相手のサービスに影響を与える代わりに得る収集速度は、妥当な最適化とはいえません。

アカウントごとの固定環境がランダム切り替えより安定する理由

ランダム切り替えの目的は毎回違って見せることですが、関連判定では各次元のシグナルが安定しているか、互いに矛盾していないかが見られます。あるアカウントが今日はある場所から、明日は別の場所から接続し、特性の組み合わせも毎回変わるなら、その不整合自体が異常なシグナルになります。

固定環境は逆の考え方です。アカウントは登録時から一貫したIDを持ちます。固定された環境と出口、整合したタイムゾーンと言語、時間をかけて蓄積するセッション履歴です。この一貫性が長く続くほど、通常のユーザーの活動として見えやすくなります。環境レイヤーの価値はここにあります。派手な変化ではなく、長期的な安定性です。

これは、収集スクリプト自体がブラウザインスタンスを管理すべきでない理由も説明します。異なるアカウントに専用環境を割り当てるには、環境を独立してスケジュールできる必要があります。異常な環境や無効になったアカウントを見つけるには、環境の状態を照会できなければなりません。長期運用でzombie instanceを蓄積しないよう、環境を回収できることも必要です。また、収集タスクの再試行では別の環境に切り替えることが多く、これは環境を独立してスケジュールできる場合にのみ実現できます。この構成では、PurpleMarkが環境リソースのレイヤーを担います。スクリプトは収集ロジックだけを担当し、IDとリソースは環境レイヤーに任せます。

コンプライアンスの境界

以下の点は、これまでのどの最適化よりも重要です。

対象サイトの利用規約とrobotsルールを守ってください。多くのECプラットフォームは利用規約で自動アクセスを明確に制限しているため、開始前に予定している利用方法が許可されているか確認します。収集するのは公開されている商品、価格、在庫情報に限り、個人情報は収集しません。技術的な保護措置を回避しないでください。CAPTCHAや暗号化されたインターフェースなどの保護に遭遇した場合は、突破を試みるのではなく、収集戦略を変更するか許可を申請します。アカウント数に関係なくリクエスト頻度を管理し、対象サービスの通常運用に影響を与えないようにします。

この議論の前提は、複数の正当なアカウントを互いに独立させ、干渉しない状態で運用する方法であり、プラットフォームのルールを回避する方法ではありません。前者は運用上の衛生管理であり、後者は別の話です。