アンチディテクトブラウザは機能一覧だけを見るとほとんど同じです。本当の違いは隔離をどう実装するかにあり、本記事では4方式を隔離強度、パラメータ制御、負荷、保守コストで比較し、それぞれに向く用途を整理します。
アンチディテクトブラウザを選ぶとき、各社の機能表はほとんど同じに見えます。複数環境、独立したフィンガープリント、プロキシ連携、自動化インターフェース、チーム協業などです。いくつも見比べると、機能一覧だけでは優劣を判断しにくくなります。
本当の違いは、隔離をどのように実現しているかです。これによって、環境がどれだけ見破られやすいか、そのツールにどの程度依存することになるか、長期運用でどれだけ保守の手間がかかるかが変わります。主流の方式は大きく4種類に分けられます。
Chromiumコアを直接変更する
Chromiumのソースコードを二次開発し、フィンガープリントの変更をC++層で行う方式です。ブラウザ起動時に、Canvas、WebGL、AudioContext、TLSなどがレンダリングやハンドシェイクの段階で設定どおりの値を出力するため、ページ側のスクリプトで返り値を上書きする必要がありません。
隔離強度は高く、各環境に独立したプロファイルディレクトリがあり、Cookie、ローカルストレージ、キャッシュが混在しません。パラメータの制御性も高く、UAのような表面的な項目だけでなく、より低いレイヤーの値に触れられます。その代わり、ローカルで完全なブラウザプロセスを動かすため、メモリ使用量は実ブラウザを複数同時に起動する場合と近くなります。
この方式の分かれ目は保守です。ブラウザコアは常に更新されるため、追随速度とバージョン切り替えのしやすさが、2〜3年後にも実用的かどうかを直接左右します。自動化の接続は通常それほど難しくなく、ローカルAPIやデバッグポートが用意され、オートメーションフレームワークから直接制御できることが一般的です。
アカウント数が多く、隔離の安定性を重視し、長期運用を行うチームに向いています。
拡張機能でパラメータを上書きする
ブラウザ拡張機能がページにスクリプトを注入し、navigatorの値やCanvasの出力などを上書きします。導入が早く、変更も少なく、アイデアを短時間で検証できます。
ただし、スクリプト注入の痕跡自体が検出ポイントになります。ページ側はプロパティが上書きされたかを確認できるため、隔離強度は低〜中程度です。制御できる範囲もスクリプトが触れられる項目に限られ、ハードウェア関連の情報はほとんど動かせません。負荷は小さく、通常のブラウザに拡張機能を1つ加える程度です。保守はブラウザのバージョンに左右され、アップデートのたびに拡張機能の書き直しが必要になることがあり、自動化スクリプトと拡張機能が干渉する場合もあります。
一時的なテスト、アカウント数がごく少ないケース、長期安定性を重視しない用途に向いています。
仮想マシンとコンテナ
アカウントごとに独立したシステムまたはコンテナを割り当てます。完全な仮想マシン、軽量コンテナ、サンドボックスなどが考えられます。
4方式の中では隔離強度が最も高く、OSレイヤーで環境とストレージを分離するため、標準状態で共有されません。一方、パラメータ制御は平均的です。GPUの型番やハードウェア情報は偽装しにくく、同じイメージから作った環境では同じハードウェア情報が繰り返されることがあります。リソース消費は最大で、システムごとにコストがかかります。コンテナは軽量ですが、ブラウザに必要な部品は多く、ディスク使用量も増えやすくなります。
保守は自分たちで担います。イメージ更新、スナップショット管理、バックアップ方針を管理する担当が必要です。自動化は柔軟で、イメージ内にフレームワークを入れて実行できますが、タスクのスケジューリングと配布は別途構築しなければなりません。
アカウント数は多くないものの要件が非常に厳しいチームや、業務上もともと完全に独立したOS環境が必要なケースに向いています。
リモートセッション（クラウド環境）
ブラウザをクラウドホスト上で動かし、ローカル端末は画面を受け取り、操作指示だけを送ります。
環境がローカル端末に存在しないため、隔離強度は自然に高くなります。統一設定したイメージを使えば、多数の環境の一貫性も保ちやすくなります。ローカル側の負荷はほぼ無視できますが、コストはクラウドの計算資源と帯域に移り、ネットワーク遅延の影響を受けやすくなります。アップデートと保守はサービス提供側が一括で行うため手間は減りますが、相手の更新ペースにも左右されます。
API化の度合いは通常この方式が最も高く、大量のスケジューリングに向いています。一方で、セッション時間や同時接続数などの制限を管理する必要があります。メンバーが各地に分散するチーム、オンデマンドで拡張したい組織、ローカル端末の管理に人手をかけたくない場合に適しています。
自分たちの条件に照らして選ぶ
- アカウント数が少なく、環境を完全に管理したいなら、コア改変かローカル仮想マシンが適しています。
- 多人数が同時に利用し、メンバーが各地に分散しているなら、リモートセッションの方が運用を簡単にできます。
- 自動化スクリプトのアイデアを試すだけなら拡張機能でも足りますが、長期運用の前提にはしない方がよいでしょう。
長期的には、3つの問いを繰り返し確認する価値があります。コアの更新にどれだけ早く追随するか、変更したパラメータが本当に反映されるか、ネットワークの出口をツール側が管理するのか自分たちが管理するのか、です。最後の点は特に見落とされがちです。環境隔離が解決するのは端末側だけであり、出口は別途設定する必要があります。
アカウント数が増えると、環境、ネットワーク出口、メンバー権限をまとめて管理する必要があります。PurpleMarkのようなツールは、複数アカウント環境の隔離とチーム協業を1か所にまとめ、日々の繰り返し切り替えや引き継ぎにかかる時間を減らします。
まとめ
どの方式もすべての面で優れているわけではありません。コア改変は保守コストと引き換えに隔離強度と制御性を高め、仮想マシンとコンテナはリソースと人手と引き換えに最も強い隔離を得ます。拡張機能は軽さと引き換えに安全余裕が小さくなり、リモートセッションはローカルの手軽さと引き換えにネットワークやサービス提供側の運用ペースへの依存が増えます。何を最も妥協できないかが明確になれば、選択は難しくありません。
