ブログに戻る

ブラウザ環境分離は一体何を分離しているのか?フィンガープリントから検証までの完全解説

ブラウザ環境分離は一体何を分離しているのか?フィンガープリントから検証までの完全解説

多くの方の「環境分離」の理解は、Cookie の削除どまりではないでしょうか。アカウントを切り替える前に閲覧履歴を消せば、もう無関係になると考えてしまう。しかし結果として、アカウントは次々と紐付けられてしまいます。Cookie は、プラットフォームがあなたを識別する数多くのシグナルの中で最も表層的なものにすぎないからです。ローカルストレージ、デバイスフィンガープリント、タイムゾーンと言語、ネットワーク出口——こうしたシグナルは、Cookie を消してもまったく消えません。

ブラウザ環境分離が分離するのは、まさにこれらのシグナルの発生源すべてです。本稿では、本当に分離された環境がどのレイヤーで構成されるのか、ゼロからどう構築するのか、そして最も飛ばされがちなステップ——分離が本当に機能しているかをどう検証するのか——を解き明かします。

環境分離の 4 つのレイヤー:1 つでも欠ければ隙間ができる

合格ラインに達する分離環境には、4 つのレイヤーが同時に独立している必要があります。

第 1 レイヤー:デバイスフィンガープリント。 ブラウザは Web サイトに対し、OS のバージョン、画面解像度、フォントリスト、Canvas/WebGL/Audio のレンダリング結果、ハードウェアの同時実行スレッド数など、数十項目のパラメータを「受動的に漏らしています」。2 つの環境が IP を変えていても、このパラメータ群が一致していれば、プラットフォームは同一デバイスと判定できます。環境分離の第一歩は、各環境が固有のフィンガープリントパラメータセットを生成することです。ここで注意すべき細部があります。フィンガープリントはランダムであればあるほど良いのではなく、パラメータ同士が相互に整合している必要があります。Windows のシステムに Mac 固有のフォントという矛盾した組み合わせは、それ自体が疑わしいシグナルです。だからこそ成熟したツールは「一般的なシステムとデバイスの妥当な組み合わせ」に沿って生成するのであり、純粋なランダム寄せ集めではありません。

第 2 レイヤー:タイムゾーンと言語。 このレイヤーの分離ロジックは最も誤解されやすいものです。タイムゾーンと言語は手動で選ぶものではなく、IP に自動追従させるべきです。プロキシの出口がどの国にあれば、環境はその国のタイムゾーンと言語を自動的に使います。アメリカの IP に UTC+8 の時刻と中国語インターフェースという組み合わせは、環境が操作されていることを一見でプラットフォームに示してしまいます。

第 3 レイヤー:ネットワーク出口。 各環境は固有のプロキシに紐付けます。このレイヤーが「どこからネットに接続しているか」を決めます。プロトコルの主流は HTTP と SOCKS5 で、後者は WebRTC のように実際の IP を漏洩させ得るトラフィックまでカバーできます。環境構築時に WebRTC を処理しておくのは標準的な操作であり、さもなければ最初の 2 レイヤーがどれほど完璧でも、実際の IP が一度漏れただけで全部が露呈します。

第 4 レイヤー:ローカルデータ。 Cookie、ログイン状態、LocalStorage、IndexedDB——これらはアカウントの活動痕跡です。分離環境のローカルストレージは物理的にパーティション分けされています。環境 A は環境 B のデータを一切見ることも触ることもできず、閉じて開き直しても、それぞれのログイン状態はそのまま保たれます。

この 4 レイヤーが揃って初めて、「まったく別の 2 人の人物が、別々の 2 台のコンピュータを使っている」という完全な物語になります。市場にはこのうち 1〜2 レイヤーしか実装していないソリューションも少なくなく、その隙間こそが紐付けの入口です。

ブラウザ環境分離の概念図:独立した 2 つの分離チャンバーがそれぞれ指紋・時計・言語・Cookie の 4 要素を持ち、回線はそれぞれ自分のサーバーに向かい互いに接触しない

ゼロから分離環境を構築する:5 ステップ

上記の原理を実操作に落とすと、環境構築の流れは実はかなり標準的です。主流のフィンガープリントブラウザに共通する手順を例に見てみましょう。

  1. 環境を新規作成し、システムプロファイルを選ぶ:環境に名前を付け(業務やプラットフォーム単位で命名すると後の管理が楽です)、OS プロファイル——Windows、Mac、Android のいずれか——を選びます。これがフィンガープリントの基礎枠組みを決めます。
  2. フィンガープリントを生成する:ワンクリックでフルセットのパラメータを生成できます。Canvas、WebGL、Audio といったレンダリング系はデフォルトのままで構いません。デフォルト値こそが妥当な組み合わせで設計されているため、明確な理由がない限り手動でいじるのはおすすめしません。
  3. プロキシを設定する:プロキシのアドレスを入力し、プロトコル(HTTP/SOCKS5)を選ぶと、ツールが先に接続テストを行い、通過した場合のみ保存を許可します。テスト結果に表示される出口国を確認し、アカウントのプロファイルと一致しているか必ず確かめてください。
  4. タイムゾーンと言語は自動追従:「タイムゾーンを IP に追従」「言語を IP に追従」を有効にし、この 2 項目が常に出口と揃うようにします。手動設定はしないでください。
  5. 必要に応じて Cookie をインポート:既存アカウントの移行時はログイン状態をインポートし、履歴を持ったまま環境に就役させます。新規アカウントはクリーンな状態から始めます。

一連の流れは通常 2 分以内に収まります。実際に時間を取るのは環境構築ではなく、その後の 2 つのタスクです。数十〜数百の環境を業務別にグルーピングすること、そしてプロキシのプールを一元的に管理すること——この 2 つは規模が上がると日常業務になります。チームで複数人が同時に環境を操作する場合は、権限管理のレイヤーも必要です。以前の記事「チーム協業管理」ではロール設定をかなり詳しく解説しています。

分離が成功したかどうかは、検証が決める

環境を作り終えても、分離が有効になったとは限りません。**検証はプロセス全体で最も飛ばされがちな、しかし決して飛ばしてはいけないステップです。**方法はとてもシンプルです。

2 つの環境を開き、それぞれ同じ IP チェックページにアクセスします。そして 4 つの点を照合します。2 つの環境が表示する IP が異なるか。それぞれのタイムゾーンが IP の所在地と一致しているか。言語と地域が適合しているか。そしてチェックページによる総合評価がクリーンか。1 つでも引っかかれば、どこかのレイヤーが分離できていないということです。原因を遡って調べてください。

このステップの価値は、「分離できたつもり」を「分離を確認した」に変えることにあります。新しい環境を投入する前に一度検証する。バッチ作業の前に抜き取り検査を一度行う。プロキシを変更したら必ず検証する——この 3 回の検証習慣が、初歩的な事故の大半を防いでくれます。このレイヤーにおいて MakoBrowser は、こうしたチェックを環境の起動フローに組み込んでいます。すべての Profile は起動時にタイムゾーンと言語を自動的に揃え、プロキシの接続テストは保存操作の前に組み込まれています。検証は「覚えておいて実行するもの」から「考える必要すらないもの」に変わります。

男性オペレーターが MakoBrowser で 2 つの環境ウィンドウを並べて開き、それぞれの地図位置情報チェックページが異なる地域のピンを表示し、中央の緑のチェックマークが分離検証の合格を示している

分離検証に合格するのは、あくまで「入場資格」を得ただけです。アカウントを回すには日常運用があります。繰り返しの多い大量操作はシンクロナイザーや自動化スクリプトに任せ、人間は機械的な作業から退きましょう。ただし、自動化の前提は常に環境そのものが堅牢であることです。フローがどれほど滑らかに回っても、環境に隙間があれば無駄になります。環境分離とプロキシ選定の関係については、以前の記事「静的プロキシとローテーティングプロキシ」が業務シーン別に解説しています。環境にプロキシを設定する際の参考にしてください。

よくある質問

普通のブラウザのシークレットモードは環境分離と呼べますか? 呼べません。シークレットモードはローカルに記録を残さないだけです。デバイスフィンガープリント、実際の IP、タイムゾーンと言語はそのまま露出しており、しかもシークレットウィンドウ同士でこれらのシグナルを共有します。解決しているのは「私の PC に痕跡を残さない」であって、「プラットフォームに同一デバイスと認識させない」ではありません。

環境を作った後、フィンガープリントを定期的に変えるべきですか? 頻繁に変える必要はありません。フィンガープリントの価値は安定性にあります。1 つのアカウントが妥当なパラメータセットを長く使い続けるのは、人が毎日顔を変えないのと同じことです。プラットフォームのフィンガープリントルールが更新されたとき、あるいは長年使った環境に異常シグナルが出たときにだけ、パラメータを微調整すればよく、作り直す必要はありません。

1 台の PC で複数の分離環境を開くと、パフォーマンスは持ちますか? 現代のフィンガープリントブラウザは必要に応じてリソースを配分するため、待機中の環境はほとんどリソースを消しません。同時アクティブ 10 環境以内であれば、一般的なオフィス PC でも問題なく動きます。環境数が多く同時アクティブをさらに増やしたい場合は、使用頻度の低い環境をオンデマンド起動に設定することを検討してください。

検証で IP 漏洩が見つかったらどうすればいいですか? まず WebRTC を確認します。最も多い漏洩源です。環境内で WebRTC が無効化されているか、プロキシモードで動いているかを確かめてください。次に、プロキシ自体が該当プロトコルをサポートしているか、環境設定にシステムレベルのプロキシ設定の残骸が残っていないかを確認します。レイヤーごとに潰していき、クリーンになるまで再テストします。


ブラウザ環境分離とは、突き詰めれば「完全性」の技術です。フィンガープリント、タイムゾーンと言語、プロキシ、ローカルデータ——4 レイヤーがすべて独立してこそ分離と呼べます。1 つでも欠ければ、プラットフォームにはあなたのアカウントを繋ぎ合わせる手段が残ります。そして検証こそが、「分離できているように見える」を「分離を確認できた」に変える唯一の方法です。

もしアカウントの身替わりが今も Cookie 削除なら、今日からまともな分離環境に切り替えることをおすすめします。まず環境を 2 つ作り、プロキシを 2 本紐付け、デュアルウィンドウ検証を 1 回走らせる——10 分で分離の正体を自分の手で確認できます。MakoBrowser をダウンロードして、すべてのアカウントを本当に独立した部屋に置いてください。