CrispLoginChrome のアカウント切り替え
日本語
Chrome に追加 Edge に追加

拡張機能レベルのコンテナプロキシ vs アンチディテクトブラウザ：マルチアカウント分離の 2 つのルート

約 4887 字 最終更新

マルチアカウント分離コンテナプロキシアンチディテクトブラウザ

マルチアカウント分離には 2 つのルートがあります。アンチディテクトブラウザはカーネル層で独立した環境を偽装し、拡張機能レベルのコンテナプロキシはセッション層で 1 つのブラウザを分割します。前者は分離の深さを、後者は並行性を買います。

マルチアカウント分離は何を分離するのか。まず 3 層に分ける

「分離」はスイッチではありません。互いに代替できない 3 つの能力であり、欠けている層がそのままリスク判定で露見します。

セッション分離
Cookie、localStorage、ログイン状態が互いに見えません。アカウント同士が混ざるかどうかを決めます。
ネットワーク分離
各アカウントが自分の出口 IP を通り、ワークスペースを切り替えても A の通信が B のセッションに混ざりません。プラットフォームから見て送信元が 1 つか複数かを決めます。
フィンガープリント分離
UA、タイムゾーン、言語、Canvas / WebGL / Audio、フォント列挙といった受動的に取得される面が、アカウントごとに安定しつつ互いに異なる状態です。1 つの送信元が何台の端末と判定されるかを決めます。

3 層の重みは対称ではありません。セッション層は下限、ネットワーク層は合格ライン、フィンガープリント層は分水嶺です。あるルートで足りるかは、どの層を自分の境界の内側で実装しているかに尽きます。

ルート 1：アンチディテクトブラウザは分離をブラウザのカーネルに埋め込む

アンチディテクトブラウザは独立したクライアントです。環境ごとに専用のプロファイル、専用の Cookie ストア、専用のプロキシ、そして書き換えられたフィンガープリントを持ちます。3 層すべてが自分の境界の内側にあるため、2 つのルートのうち分離が最も深いのはこちらです。

コストも同じ場所から来ます。各環境は実際に動くブラウザインスタンスなので、メモリは環境数に比例して増えます。ライセンスは同時起動環境数またはシート単位の課金が一般的で、環境が増えるとカーネル更新、プロキシプール、フィンガープリントテンプレートの一貫性維持が運用作業になります。自動化インターフェースを備えるのも通常で、数十アカウントの一括ログインや投稿は手作業では回りません。個々の製品がどこまで対応するかは実装次第なので、比較記事ではなく公式ドキュメントで確認してください。

ついでに切り分けておきます。Chrome 標準のマルチプロファイルはセッション分離を実現しますが、プロファイル単位で振り分けるプロキシの入口がなく、ログイン状態のスナップショットもありません。切り替えのコストは「ウィンドウを変える」ことです。詳しくは【内部リンク：Chrome のマルチプロファイルとの違い】。

ルート 2：拡張機能レベルのコンテナプロキシ。アンチディテクトブラウザなしでもマルチアカウント分離はできる

CrispLogin はこのルートです。独立したブラウザではなく、Chrome / Edge の拡張機能です。すでに使っているブラウザの中で動き、拡張機能が使える API で 1 つのブラウザを複数の分離ワークスペースに分割します。各ワークスペースは自分の Cookie とサイトストレージの見え方、自分の出口プロキシ、自分のログイン状態スナップショットを持ちます。

因果は明快です。コンテナは拡張機能自身が管理する「タブ → コンテナ」の帰属であり、Cookie とサイトストレージはコンテナ単位で書き込まれるため、A でログインしたサイトは B で開くと未ログインになり、両者の localStorage も互いに見えません。プロキシはブラウザ全体ではなくコンテナに紐づくため、ワークスペースを切り替えると出口 IP も変わり、A のネットワーク上の身元が B のセッションに入り込むことはありません。これが「1 つのブラウザ 複数アカウント 同時ログイン」をセッション層で実現できる範囲です。

コンテナプロキシは Chrome でどう実装されるのか

正確に言うと、Chrome のプロキシ設定のスコープはブラウザプロファイル単位で、タブ単位ではありません。PAC スクリプトに tabId は渡りません。したがってコンテナプロキシは、アクティブタブが変わったタイミングでこの設定を書き換え、前面タブの出口をそのタブが属するコンテナの出口に合わせる形で実装されます。保証されるのは「いま見ているワークスペースの出口が有効である」ことで、「10 のワークスペースが同時に別々のトンネルを張る」ことではありません。後者には独立したネットワークスタックが必要で、クライアントにしかできません。コンテナを離れると他のコンテナはルールで遮断され、2 つの出口が同じ瞬間に混ざることはありません。Service Worker の直接通信や WebRTC への網羅性は限定的で、実装次第です。設定とトラブルシュートは【内部リンク：コンテナプロキシの設定と切り分け】。

サイトスナップショット：アカウント切り替えを「再ログイン」から「1 つ選ぶ」へ

スナップショットが保存するのは 1 つのサイトのログイン状態（Cookie とそのサイトのストレージ）で、コンテナに属します。ログイン状態を単独のスナップショットとして保存できるため、アカウント切り替えのコストは 1 つ選ぶだけになり、ログアウトして再ログインする必要も、パスワードをメモに貼る必要もありません。中リスクの運用で拡張機能ルートが最も実用的なのはこの層で、「複数アカウント」を「複数ブラウザ」から「複数ワークスペース」に引き下げます。使い方は【内部リンク：サイトスナップショットの保存と復元】。

拡張機能がフィンガープリント層でできること、できないこと

Manifest V3 で拡張機能が変えられるのはリクエストヘッダーです。UA と sec-ch-ua 系の Client Hints はコンテナ単位で書き換えられます（declarativeNetRequest の modifyHeaders）。その下は無理です。Canvas、WebGL、AudioContext、フォント列挙はレンダラーとカーネルの内側で起きるため、拡張機能に API はなく、ページの JavaScript にパッチを当てるしかありません。それはカーネルレベルの書き換えではなく、検出可能で、ブラウザのバージョンに強く依存します。つまり拡張機能がフィンガープリント層で提供するのは「一貫性」（同じコンテナは毎回同じに見える）であって、「偽装」（別のコンテナを別の機械に見せる）ではありません。ここが 2 つのルートの分水嶺であり、曖昧にしてはいけません。

アンチディテクトブラウザ vs 拡張機能：8 項目の比較

ここまでの分析を 1 枚の表に圧縮します。各行は 1 つの問いにだけ答え、結論はセルに直接書きます。「状況による」は使いません。

拡張機能レベルのコンテナプロキシとアンチディテクトブラウザの能力境界（2026 年 11 月時点）
項目アンチディテクトブラウザ（クライアント）拡張機能レベルのコンテナプロキシ（CrispLogin など）
分離の層カーネル層：独立したブラウザインスタンス + 専用プロファイルセッション層：同一ブラウザ内のコンテナ化された Cookie とストレージ
フィンガープリントの制御高：UA、タイムゾーン、言語、Canvas / WebGL / Audio、フォントを一式で設定可能限定的：リクエストヘッダーと UA は変更可、カーネル層のフィンガープリントは不可
プロキシの粒度環境ごとに 1 本。複数の出口を同時に並行できるコンテナに紐づく。同時刻に前面ワークスペースの出口が 1 本
並行のしかた複数クライアント・複数ウィンドウ。環境同士は干渉しない1 ウィンドウに複数タブ。ワークスペースを即時に切り替え
リソース消費環境ごとにブラウザプロセス一式。メモリは環境数に比例ホストのブラウザを再利用。増分はほぼゼロ、タブが数枚増えるだけ
コスト同時環境数またはシート単位の購読。加えてプロキシプールと運用工数拡張機能の購読のみ。追加クライアントも環境運用も不要
向くリスク水準高：プラットフォームがフィンガープリントの一貫性を深く検証する中：リスク管理がセッション・行動・出口 IP 中心
典型例大規模な SNS マトリクス、越境の複数店舗、一括自動化少数アカウント、日々のワークスペース切り替え、広告とサポートの多重ログイン

判断の境界：拡張機能で足りる場合と、クライアントが必要な場合

判断基準は 3 つだけです。順に照らせば済みます。「要件次第」は答えではありません。

  1. アカウント数と同時実行数。10 前後で 1 日に数十回切り替えるなら拡張機能で足ります。30 以上を同時にオンラインにするならクライアントが必要です。拡張機能の並行は「切り替え」であって「同時」ではなく、前面の出口は同時に 1 本しかありません。
  2. プラットフォームが何を罰しているか。停止理由に端末フィンガープリントの重複や Canvas 異常といった語が出るなら、一貫性を検証されています。拡張機能のセッションと出口の 2 層では届きません。停止理由が IP、ログイン頻度、操作行動に紐づくなら、拡張機能で既に覆えています。
  3. 無人運用が必要か。一括ログイン、一括投稿、定時処理にはクライアントが必要です。安定した自動化インターフェースが要るからです。拡張機能にそれはなく、仮に製品が対応をうたっていても対話層までです。

逆方向も同じくらい重要です。アカウントが 3 つ、1 日に 5 回切り替え、店舗の管理画面と広告管理画面を 1 ウィンドウで分けたいだけなら、環境課金のクライアントを買うのは、使わない分離の深さと引き換えに運用コストを払うことになります。【内部リンク：軽量ルートが通用する範囲】

よくある 3 つの誤解

誤解 1：分離とは IP を変えること

IP はネットワーク層にすぎません。セッションが分離されていなければ、2 つのアカウントは同じブラウザで Cookie を共有し、出口をいくら回しても混ざります。まずセッション、次に IP を確認してください。

誤解 2：拡張機能はアンチディテクトブラウザを完全に置き換える

置き換えません。拡張機能はカーネル層のフィンガープリントに届かず、独立したネットワークスタックも提供しません。この 2 点が上限を決めます。置き換わるのは「ログインを分けるためにクライアントを買う」という動機であって、クライアントそのものではありません。

誤解 3：アンチディテクトブラウザなら必ず安全

得られるのは強い環境分離であって、強い運用安全性ではありません。環境が増え、設定が不揃いになるほど綻びが増えます。フィンガープリントテンプレートとプロキシの地理位置が食い違う、タイムゾーンと IP の帰属が矛盾する、といった状態のほうが、均一であるより目立つシグナルになります。

よくある質問

拡張機能はアンチディテクトブラウザを完全に代替できますか？

できません。Cookie とサイトストレージの分離、コンテナ単位の出口切り替え、ログイン状態の復元は可能ですが、Canvas や WebGL のようなカーネル層のフィンガープリントは変更できず、複数ワークスペースを同時に別トンネルへ流すこともできません。プラットフォームが一貫性を深く検証するならクライアントが必要です。逆にセッションと IP の分離だけで足りる場面では、クライアントは過剰装備です。

コンテナプロキシとグローバルプロキシはそんなに違いますか？

違いは「何が何に従うか」です。グローバルプロキシはブラウザ全体で 1 つの出口を全タブが共有するため、アカウントを切り替えても出口は変わりません。コンテナプロキシは出口をワークスペースに紐づけるので、ワークスペースを切り替えれば出口も変わります。前者は手軽ですが複数アカウントが同じ IP を共有します。後者だけがワークスペースごとに別の送信元を作れます。

1 つのブラウザで複数アカウントに同時ログインすると、互いに押し出されますか？

セッションが本当に分離されているか次第です。Cookie とサイトストレージがコンテナ単位で分かれ、コンテナ間でログイン状態を共有していなければ、同一ドメインの複数アカウントは共存できます。2 つのワークスペースが同じコンテナに入っていれば同一セッションなので、後からログインしたほうが先のものを押し出します。両者の Cookie が独立しているかで判断できます。

アンチディテクトブラウザを使わない場合、リスクはどこにありますか？

フィンガープリント層に集中します。同じ端末と同じブラウザでは、IP を分けても受動的に取得される面（Canvas、フォント、タイムゾーン）は一致したままで、そこを判定に使うプラットフォームではアカウント同士が関連づけられます。したがって拡張機能ルートは、リスク管理がセッションと IP 中心のプラットフォームに向き、フィンガープリントの一貫性を必須要件とするプラットフォームには向きません。

出典と最終更新

API の挙動に触れた箇所は公式ドキュメントを優先します。拡張機能の能力境界はブラウザのバージョンで動くため、導入前にその時点のドキュメントで確認してください。

最終更新：2026 年 11 月 8 日。個々の製品能力の記述はその時点のバージョンに基づきます。「実装次第」と書いた箇所は、選定時に実測で確認してください。