ブラウザをローカル、アンチディテクト、クラウドスマホ／クラウドブラウザ、自動化専用の4種類に分け、それぞれの役割と向かない場面を整理します。まずID管理の方法を決め、その後に処理をどこで動かすかを決めます。
ブラウザ選びでは、最初の問いが間違っていることがあります。「どれが一番使いやすいか」ではなく、「このブラウザで何をするのか」と考えるほうが整理しやすくなります。役割で分けると、実用上は4種類です。自分のPCで使う一般的なブラウザ、アカウントのID管理を目的としたアンチディテクトブラウザ、クラウド上で動くクラウドスマホ／クラウドブラウザ、そしてスクリプトやAIから呼び出す自動化専用ブラウザです。
ローカルブラウザ：最も手軽で、最初に限界が来る
日常のWeb閲覧、情報収集、自分の数個のアカウントへのログインであれば、ローカルブラウザが最も簡単です。プライバシー拡張を入れ、不要な同期を切れば、追加コストはほとんどありません。
問題はアカウント数が増えたときです。複数プロファイルを使えばCookieの混在は防げますが、土台となるデバイス特性は同じままです。プロキシも通常は全体設定で、プロファイルごとに別の出口を割り当てにくい場合があります。プロファイルが増えると、グループやタグがないことも管理上の負担になります。さらに重要なのがIDの一貫性です。複数アカウントが1台のマシン、1つの環境に集中すると、プラットフォーム側からは同じ操作主体に見えやすくなります。
この種のツールは、ランダム性を増やし、フィンガープリントのエントロピーを下げることで追跡されにくくする設計です。複数アカウント運用が求めるのは正反対で、長期的な安定性と、互いに矛盾しないパラメータです。目的が逆なので、両者は代替関係にはなりません。
アンチディテクトブラウザ：1アカウントに1つの整合したID
アンチディテクトブラウザは、アカウントごとに独立した環境を作ります。IP、タイムゾーン、User-Agent、Canvas、WebGL、音声フィンガープリント、フォントフィンガープリント、メディアデバイスIDなどの情報を一式で生成し、固定します。Cookieとローカルストレージも相互に分離されます。作成後はパラメータが変わらないため、次回ログイン時も同じデバイスのように見えます。
プロキシは環境単位で紐づき、それぞれが独自の出口を使います。HTTP、HTTPS、SOCKS5などの主要プロトコルにも対応します。プロキシ設定後はタイムゾーンや言語も合わせることができ、米国IPなのに言語やタイムゾーンが別地域というような不整合を避けられます。プラットフォームが環境を実ユーザーらしいと判断する材料は、IPだけではありません。
管理機能も大きな価値です。グループ、タグ、メモ、一括インポート／エクスポート、設定の一括変更、一括起動／停止などが使えます。環境の作成や回収をAPI経由で行えば、スクリプトやAIから直接呼び出すこともできます。
制約も明確にしておく必要があります。日常の一般的な閲覧向けではなく、複雑さもコストも高くなります。また長期運用では、ブラウザのコアがプラットフォームのリスク管理更新に追随できるかも重要です。選定時には更新履歴を確認し、抽象的な説明ばかりか、何を変更したか具体的に書かれているかを見る価値があります。
クラウドスマホとクラウドブラウザ：デバイスをクラウドへ移す
この2種類の共通点は、実行場所をローカルPCからクラウドへ移すことです。クラウドスマホはクラウド上のモバイル端末を提供し、実機に近い環境やAppのインストールが必要なモバイル用途に向いています。クラウドブラウザはクラウド上のブラウザインスタンスを提供するため、ローカルPCのメモリや計算資源に負荷をかけません。
代償は分かりやすく、時間課金のため、長く動かすほど、同時に多く起動するほど費用がほぼ比例して増えます。ネットワーク往復による遅延は、細かな操作が必要なタスクには不利です。ローカルの素材も先にアップロードする必要があります。一方で、異なる端末や場所からアクセスしやすく、チーム内の複数人が同じクラウド端末に接続できます。
見落とされやすい点もあります。クラウドインスタンスは通常、あくまで実行場所です。アカウントIDが自動的にそこへ宿るわけではないため、ID管理と分離は別途設計する必要があります。
自動化専用ブラウザ：スクリプトとAIのための実行器
このタイプの目的は1つだけで、処理フローを正しく実行することです。プログラム制御に対応し、CDPプロトコルで外部フレームワークから接続できます。AIツールからインターフェース経由で呼び出し、ページ操作、スクリーンショット、内容読み取り、フォーム入力などを実行することもできます。
データ収集、回帰テスト、大量の反復処理に向いています。ただし、それ自体にアカウントIDはありません。複数アカウント環境では、既存の分離環境へ接続するのが一般的です。実行は実行レイヤー、IDはIDレイヤーで担当します。
弱点は業務判断を持たないことです。ページがリニューアルされたり要素が消えたりすると、スクリプトは失敗します。前段での判断や、後段での例外処理は人が担う必要があります。
タスクの特徴に沿って判断する
最初に、複数のアカウントIDを長期にわたって安定維持する必要があるかを確認します。必要ならアンチディテクトブラウザを検討します。不要なら次へ進みます。
次に、実機環境またはモバイルAppが必須かを確認します。必須ならクラウドスマホです。単に負荷をローカルPCから外したいだけなら、クラウドブラウザを検討します。
続いて、タスクがスクリプトやAIによって駆動され、同じフローを繰り返すかを確認します。該当するなら自動化専用ブラウザを使い、アカウントIDは環境レイヤーに任せて、実行器をそこへ接続します。
3つとも当てはまらなければ、プライバシー設定を施したローカルブラウザで十分です。重いツールを導入する必要はありません。
実際のプロジェクトでは、これらを重ねて使うこともよくあります。環境レイヤーではアンチディテクトブラウザがIDを管理し、実行レイヤーでは自動化ブラウザがフローを動かし、実機や遠隔アクセスが必要な部分はクラウドに置きます。大規模な複数アカウント運用では、PurpleMarkのような環境管理ツールが環境レイヤーを担当し、各アカウントのIDとセッションを分離することで、上位の実行器から操作できる状態を作ります。
一言で言えば、まずIDをどう管理するかを決め、次に処理をどこで動かすかを決めます。
