multi-account-isolation について
multi-account-isolationは、ブラウザープロファイルの分離を検証するためのスキルガイドです。自分が所有する、または運用を許可されたIDを管理する開発・QA担当者向けに、プロキシ、指紋、保存データ、プロファイル間の整合性を確認する原則とチェック項目をまとめています。
主な機能
- 01IDとプロファイルの一対一対応
- 02出口IPとタイムゾーンの照合
- 03WebRTCとCanvasの安定性検証
- 04プロファイル間の指紋比較
- 05Cookie保存領域の分離確認
活用シーン
- 01QAテスト用ID間の分離検証
- 02CIでのブラウザープロファイル整合性確認
- 03プロファイル間でのIPやID共有の調査
- 04ブラウザーセッションデータの保存先監査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ antibrow/ anti-detect-browser-skills --skill multi-account-isolationインストール後、Claude Code で/multi-account-isolationを入力して読み込まれたか確認します。
詳細
プロファイルの分離 — 想定せず、検証する
分離されているように見えるプロファイルは、通常、実際には分離されていません。問題はありふれた機械的なものです。出口 IP と一致しないタイムゾーン、実際のアドレスを含む WebRTC の候補、読み取るたびに変わるキャンバスハッシュ、同じペルソナになってしまった 2 つのプロファイル。このスキルは、こうした問題が影響する前に見つけるためのチェックリストです。
許可された用途に限ります。 これは、ご自身が所有する、または運用を許可されている ID のためのものです。ご自身のアカウント、ご自身のテスト用フィクスチャ、ご自身の QA フリート、ご自身の不正対策スタックが該当します。許可なくシステムにアクセスすること、ご自身が所有していないアカウントを使うこと、偽のアカウントやエンゲージメントを作成することを目的としたものではありません。自動化するサイトの利用規約および適用法を遵守してください。詳しくは 利用上の注意 をご覧ください。
このスキルが保証しないこと。 以下のすべてのチェックに合格すれば、ブラウザー層の内部整合性が保たれているということです。特定のサイトが 2 つのプロファイルを無関係なものとして扱うことを意味するわけではありません。共有の支払い手段、共有の連絡先情報、同一のアクティビティパターンなど、ブラウザーの外部にある要素は、どのブラウザー設定でも制御できません。問題のない結果は「技術層に問題はない」という意味であり、保証ではないと考えてください。
これらのプロファイルを作成して起動する SDK については、anti-detect-browser スキルをご覧ください。
構成上の不変条件
1 つの ID に対して、すべてを 1 つずつ割り当てます。2 つの ID 間で共有されているセルはすべて、見つけるべき不具合です。
identity → profile → persona → proxy → timezone
1 : 1 : 1 : 1 : 1
antibrow のすべてのプランでプロファイルは無制限に無料で使えるため、再利用する理由はありません。1 つのプロファイル内で「ログアウトして、もう一方の ID で再度ログイン」すると、セットアップ全体が台無しになります。Cookie jar と localStorage が要点です。
テスト対象のセットアップ
import { AntiDetectBrowser } from 'anti-detect-browser'
const ab = new AntiDetectBrowser({ key: process.env.ANTI_DETECT_BROWSER_KEY })
const identities = [
{ profile: 'fixture-us-01', proxy: process.env.PROXY_US_1, tags: ['Windows 10', 'Chrome'] },
{ profile: 'fixture-us-02', proxy: process.env.PROXY_US_2, tags: ['Apple Mac', 'Safari'] },
{ profile: 'fixture-de-01', proxy: process.env.PROXY_DE_1, tags: ['Windows 10', 'Edge'] },
]
for (const id of identities) {
const { browser, page } = await ab.launch({
profile: id.profile, // isolated cookies, storage, login state
proxy: id.proxy, // from the environment, one per identity
fingerprint: { tags: id.tags }, // drawn once, frozen, replayed after
label: id.profile, // address-bar tag drawn by the kernel, unreadable from the page
})
// ... run the checks below, then ...
await browser.close()
}
Python でも、ディスク上のプロファイル形式は同じです。
import os
from antibrow import launch
with launch(
profile="fixture-us-01",
proxy=os.environ["PROXY_US_1"], # from the environment, never a literal
geoip=True, # timezone + WebRTC follow the proxy exit
label="fixture-us-01",
) as browser:
page = browser.new_page()
print(browser.timezone, browser.public_ip)
チェック項目
各プロファイルをそれぞれ専用のプロキシ経由で実行し、目視ではなくアサーションで検証します。
| # | チェック項目 | 方法 | 失敗する条件 |
|---|---|---|---|
| 1 | タイムゾーンが出口 IP と一致する | browser.timezone と browser.public_ip の国を比較します | geoip が無効になっている、または timezone が IP と矛盾する値に強制されている場合です。これが最もよくある不具合です。 |
| 2 | WebRTC がプロキシのみを公開する | browserleaks.com/webrtc | ICE 候補にローカルアドレスまたは実際のパブリックアドレスが含まれている場合です |
| 3 | Canvas ハッシュが起動間で安定している | 値を読み取り、閉じてから、同じプロファイルを再起動してもう一度読み取ります | 2 回の読み取り結果が異なる場合です。読み取るたびに値が変わること自体が異常であり、ペルソナが固定されていないことを意味します |
| 4 | Worker とメインスレッドの値が一致する | CreepJS | Web Worker 内で再読み込みしたときに、UA、languages、hardwareConcurrency、タイムゾーン、または GPU が異なる場合です |
| 5 | 3 つのインターフェースで同じ GPU が使われている | CreepJS、または WebGL/WebGL2/WebGPU を直接読み取ります | adapter.info.vendor が、マスク解除された WebGL レンダラーの系列と一致しない場合です |
| 6 | 2 つのプロファイルで同じペルソナを共有していない | フリート全体で browser.persona を比較します | 2 つのプロファイルが同じ UA、画面ジオメトリ、シードを報告する場合です |
| 7 | 2 つのプロファイルで同じアドレスを共有していない | フリート全体の browser.public_ip を収集します | 2 つのアイデンティティが同じ出口、または同じ /24 から出ている場合です |
| 8 | Cookie ジャーが分離されている | フリート全体で browser.profile_dir を比較し、それぞれの user-data/ を調べます | 2 つのアイデンティティが同じディレクトリを参照している、または 1 つのディレクトリに別のアイデンティティの状態が保存されている場合です |
| 9 | 1 つのアイデンティティに 1 つのプロファイルツリー | 同じ名前で起動するたびに、同じ temporary 値が渡されることを確認します | 管理対象の gmail と一時的な gmail は、別々のペルソナと Cookie ジャーを持つ 2 つの異なるプロファイルです。スクリプト内で temporary の値が一致していない場合、1 つの名前で 2 つのアイデンティティを実行することになり、不具合ではなくログアウト状態のように見えます |
| 10 | スタック全体の整合性 | whoer.net、pixelscan.net | IP、タイムゾーン、ロケールの不一致がひと目で分かる場合です |
| 11 | CI での整合性ルール | npx liarjs(liarjs.dev) | 約 40 個のオープンソースのレイヤー間ルールのいずれかが失敗する場合です。これは無人で実行されるチェックです |
CI に組み込む価値があるのはチェック 1、3、7 です。低コストで決定論的に実行でき、実際に繰り返し発生する不具合を検出できます。
失敗時の確認手順
まずは最も手軽な項目から、次の順番で確認してください。フィンガープリントが本当の原因であることは、ほとんどありません。
- プロファイル名を再利用していませんか?
list_profilesを使うか、アイデンティティごとにbrowser.profile_dirを比較します。2 つのアイデンティティが 1 つのディレクトリを使っていれば、ほかの問題もすべて説明できます。ディレクトリ名はプロファイル名ではなく ID に基づいているため、フォルダー名ではなく、その中のprofile.jsonを確認して照合してください。 - 同じアドレスが 2 回使われていませんか? それぞれの
public_ipが異なることを確認します。 - 時刻とアドレスが一致していませんか?
browser.timezoneとbrowser.public_ipを一緒に出力します。 - ペルソナが再生成されていませんか? 起動間で Canvas ハッシュが変わっている場合、プロファイルは固定されていません。
profile_dirまたはキャッシュディレクトリが変わっていないか確認します。 - これらを確認してから、上記のテストスイートを使ってフィンガープリント自体を検証してください。推測だけで判断してはいけません。
ランタイムがアクセスするデータと、その確認方法
ログイン済みセッションを操作するツールは、Cookie とプロキシの認証情報を受け取ります。その情報がどのように扱われるのかを確認するのは当然です。antibrow の場合:
| アーティファクト | 保存場所 | 閲覧者 |
|---|---|---|
Cookie、localStorage、ログイン状態 | ローカルディスク上の ~/.anti-detect-browser/profiles/<id>/user-data/、または一時プロファイルの場合は profiles-temp/<id>/ | ローカルです。クラウド同期はプロファイルごとにオプトインします。起動しただけでクラウドプロファイルが作成されることはなく、sync: true を指定するとクラウドに保存されます。マシン上に留まると決めつける前に、どのプロファイルが同期されるかを確認してください |
ペルソナ(persona.json) | 同じプロファイルディレクトリに一度だけ書き込まれ、固定されます | ローカルです |
プロファイルの識別情報(profile.json) | 同じプロファイルディレクトリにあります。ファイル内の ID がディレクトリ名になります | ローカルです。名前を変更してもペルソナが失われないのはそのためであり、フォルダー名がプロファイル名ではない理由でもあります |
| プロキシ URL とその認証情報 | 起動時にカーネルへ渡され、ネットワークスタックで処理されます(HTTP 407 / SOCKS5 RFC 1929)。そのため、認証情報を保持する拡張機能はありません | カーネルプロセスとプロキシプロバイダー |
| API キー | 環境、または ~/.antibrow/license.key | antibrow.com と交換され、短期間有効なライセンストークンになります。およそ 1 日に 1 回です |
カーネルはクローズドソースの Chromium ビルドです。これは、スプーフィングを注入可能なスクリプトではなく C++ 内で行うためのトレードオフです。そのため、うのみにせず、動作を確認してください:
python -m antibrow info # kernels, profiles, license state, cache dir
browser.plan.redacted_args() # exact kernel command line, secrets masked - safe to paste in a bug report
ログを確認できるプロキシ、またはローカルの MITM プロキシを指定し、起動時にマシンから送信される情報を監視してください。SDK のバージョンを固定し、公開されているハッシュ(npm view [email protected] dist.integrity)を確認して、監査したコードが実際に実行されるコードであることを確かめてください。デプロイ環境から一切の外部通信を許可できない場合、このツールは適していません。ライセンス認証はカーネルにコンパイルされており、オフラインモードはありません。
分離で対応できないこと
確認項目に問題がないと、誤った結論を招きやすいため、はっきり述べておきます:
- ブラウザーの外にあるあらゆるもの。 支払い手段、連絡先情報、出金先の共有などは、ブラウザーの設定では対応できません。これらは最も強力な相関要因です。
- 行動パターン。 タイミング、コンテンツ、操作対象が同一であること。これは技術的な属性ではありません。
- 本人確認。 書類確認はフィンガープリントの問題ではありません。
- プラットフォーム独自の判断。 ここでの機能によって、アカウントに対するサイトの扱い方が変わることはありません。
すべての確認に合格しても問題が見つかる場合、その原因はブラウザーレイヤーではなく、このリストにあります。
許容される使用方法
想定される使用方法: 自分が所有する複数の ID 間の分離を確認すること。アカウント所有者の許可を得てクライアントのアカウントを運用すること。異なるデバイスをエミュレートする QA 用フィクスチャを作成すること。独自の不正対策や相関ロジックをテストすること。ブラウザーランタイムが認証情報をどのように扱うかを監査すること。
対象外であり、サポートされない使用方法: 許可なくシステムにアクセスすること。自分が所有していないアカウントにログインすること。クレデンシャルスタッフィングやアカウント乗っ取り。偽のアカウント、レビュー、エンゲージメントの作成。認証、支払い、認可の制御を回避すること。適用される法律に違反して個人データをスクレイピングすること。プラットフォームによる措置を回避すること。
利用するプラットフォームの規約と適用される法律を遵守する責任は、運用者にあります。不正使用やセキュリティ上の問題は、https://antibrow.com の連絡先から報告してください。
関連スキル
- anti-detect-browser - ここで確認する環境を構築する SDK、プロファイル、ペルソナ、プロキシ、REST API
- browser-mcp-agent - AI エージェントが単一のプロファイルを自ら操作できる MCP サーバーモード