マルチエージェント基盤：Chromiumスロット分離と権限リース設計で避けるべきDOM衝突とセッション管理の落とし穴

はじめに：プロファイル分離が解決しない「並列ブラウザ」の罠

AIエージェントのマルチタスク化が進行する中、複数のブラウザエージェントを並列実行するシステム設計において、多くの開発者が最初に想到するのが「Chromeプロファイルの分離」だ。各エージェントに独立したプロファイルディレクトリを割り当てれば、クッキーやローカルストレージの混入は防げるはず——そう考えている人は少なくない。

しかし実務では、この単純な分離では解決しない問題が次々と浮上する。Chromiumプロセス内部の共有メモリや内部キャッシュの分離が不完全であること、同じホスト上のブラウザがネットワークアクセスを共有するためIPベースのレートリミットやGeo-IP判定で「完全な分離」にならないこと、そしてDOM操作における非同期処理のタイミング依存による状態汚染——これらはプロファイルディレクトリの数だけでは対処できない。

こうした課題に挑むアプローチの一つとして、SessionDock が注目されている。SessionDockはChromiumのワークスペースを「スロット」として抽象化し、プロジェクトやテナントといったデータモデルと紐づけることで、エージェントごとの独立した実行環境を提供する。これは単なるブラウザインスタンスの複製ではなく、メタデータを伴うリソースとしての管理単位を定義している点に本質的な違いがある。

本記事では、プロファイル分離の限界を技術的に分解した上で、それを補完するアーキテクチャパターン——権限の排他制御（リースとエポック）、DOM状態の独立性、認証フローの制約——を実装レベルで掘り下げる。読者は、並列実行時の競合回避設計に必要な「制御の粒度」と「トレードオフ」の判断基準を得られる。

前提：なぜ既存のプロファイル分離では不十分なのか

プロファイル分離がカバーする範囲としない範囲

ブラウザプロファイルの分離は、クッキー、ローカルストレージ、インデックスDB、サービスワーカーのキャッシュといった「永続化データ」の隔離には有効である。しかし、Chromiumのプロセスモデルを考えると、この分離は完全ではない。Chromiumはマルチプロセスアーキテクチャを採用しており、レンダラプロセス、GPUプロセス、ブラウザプロセスが共有メモリを介して通信する。プロファイルディレクトリが異なっても、同じホスト上で動作するChromiumインスタンス間では、内部のDNSキャッシュや接続プールが共有される可能性がある。

特に問題となるのはネットワーク層の分離不足だ。SessionDockのスロットは同じホスト上に存在し、Chromiumがホストのネットワークアクセスを共有しているため、完全な分離ではない。具体的には、同一IPアドレスから複数のスロットが同時にリクエストを送信すると、ターゲット側のIPベースのレートリミットに到達しやすくなる。また、Geo-IPベースのアクセス制御では、スロット数がどれだけ増えようと同一の地理的判定をされる。これは「論理的な分離」ではあるが、「物理的な分離」ではないことを意味する。

DOM操作における状態汚染のメカニズム

エージェントがDOM操作を行う際、CSSセレクターやXPathによる要素の特定は、文脈（コンテキスト）に強く依存する。2つのエージェントが同一のURLを別々のスロットで開いた場合、DOMツリーは独立しているはずだが、以下のケースで状態汚染（State Pollution）が発生し得る。

非同期APIコールの応答タイミングがずれ、DOMの中間状態を別のエージェントの操作が参照してしまうケース
SPAのルーター状態がセッションスコープで共有され、スロット間でURL遷移が干渉するケース
ブラウザ拡張機能やサービスワーカーがスロット間で共有されるケース

これらを回避するには、論理的なテナント隔離だけでなく、物理的・論理的な実行コンテキストの厳格な区別——すなわち、各エージェントが操作する「画面」自体が独立したプロセス空間に存在すること——が必要となる。

観点	プロファイル分離	スロットベース分離
クッキー・ストレージ	分離可能	分離可能
ネットワーク（IP・Geo-IP）	共有（分離不可）	共有（分離不可）
GUIイベントループ・フォーカス	競合する	独立デスクトップで分離
権限の排他制御	未定義	リース＋エポックで管理
管理コスト	低い	中〜高（スロットライフサイクル管理）
セキュリティ粒度	データ層のみ	実行コンテキスト層まで

SessionDockのアプローチ：スロットとしてのChromiumワークスペース設計

スロットのデータモデル

SessionDockの設計において、Chromiumのワークスペースは「スロット」という一級オブジェクトとして定義される。各スロットは、単なるブラウザプロセスのインスタンスではなく、プロジェクトやテナントといったデータモデルと紐づいたリソースである。この抽象化により、スロットの生成・破棄・割り当てをアプリケーション層から制御可能になり、エージェントのライフサイクルとブラウザ環境のライフサイクルを明確に分離できる。

この設計の利点は、スロットを単なる「ブラウザの窓」ではなく、メタデータを伴う管理対象として扱える点にある。スロットの状態（アイドル、アクティブ、破棄済み）をトラッキングし、スケジューラがエージェントの割り当てを最適化できる。また、テナント単位でスロットの数を制限したり、プロジェクト完了後にスロットを自動破棄したりするポリシーを定義できる。

手動ログイン要件とセキュリティのトレードオフ

SessionDockは、既存のChromeインストールからのセッションインポートをサポートしていない。各スロットでは手動ログインを想定している。これは意図的な設計判断であり、以下の2つの理由がある。

第一に、既存ブラウザからクッキーをコピーすると、そのクッキーがどのコンテキストで発行されたのか（どのIP、どのTLSフィンガープリント、どのユーザーエージェント）が不明確になる。スロットのネットワーク環境がホストを共有している以上、コピーされたクッキーが元環境と異なるIPから使用される場合、ターゲットのセッション管理が不整合を起こす可能性がある。

第二に、手動ログインを強制することで、各スロットの認証状態が「そのスロットで明示的に確立されたもの」であることが保証される。これは、エージェントが操作するセッションの正当性を監査ログに残す上でも有効だ。ただし、この設計は初期設定コストの増加という代償を伴う。テナント数が100を超えると、手動ログインの回数が運用負荷として無視できなくなる点に注意が必要である。

リソース管理フロー

スロットの生成からエージェントへの割り当てまでのフローを整理すると、以下のようになる。スロットはテナントまたはプロジェクトの作成時に生成され、スケジューラがエージェントのタスク割り当て時にスロットをバインドする。タスク完了後、スロットはアイドル状態に戻り、一定時間が経過すると破棄される。

flowchart LR
    A["テナント/プロジェクト作成"] --> B["スロット生成"]
    B --> C["手動ログイン（初回）"]
    C --> D["スロット: アイドル"]
    D --> E["スケジューラ: エージェント割り当て"]
    E --> F["スロット: アクティブ"]
    F --> G["タスク完了"]
    G --> D
    D --> H{"破棄条件に合致"}
    H -->|Yes| I["スロット破棄"]
    H -->|No| D

このフローにおいて、スロットの生成コスト（Chromiumプロセスの起動、Westonデスクトップの割り当て、初回ログイン）は比較的高いため、頻繁な生成・破棄を避けるためのプーリング戦略が運用面での鍵となる。後続のセクションでは、このスロットにエージェントがアクセスする際の排他制御——リースとエポック——の詳細を解説する。

権限管理の核心：リースとエポックによる排他制御

複数のエージェントが同一スロットに同時にアクセスしようとした場合、DOM操作やネットワークリクエストが交錯し、状態の不整合が発生する。この競合を防ぐために、SessionDockではスロットのアクセス制御に2つの概念——リース（lease）とエポック（epoch）——を組み合わせている。

リース：時間制限付きの排他的アクセス権

リースは、エージェントが一定時間だけスロットを独占できる仕組みである。エージェントがスロットにアクセスする際、スケジューラはリースを付与し、その有効期限内には他のエージェントは同一スロットに書き込みできない。タイムアウトが到来するとリースは自動的に解放され、スロットは再競合可能になる。

この設計の利点は、分散システムでよく見られる複雑なデッドロック回避ロジック（待ち行列の優先度付け、ロックの粒度変更、タイムアウトの段階的延長など）を実装しなくて済む点にある。リースは「時間」で切れるため、エージェントがクラッシュしても最大でリース期間分だけスロットが占有されるだけで、永久ロックは発生しない。実務上、リース期間の値はエージェントのタスク特性（単純なページ遷移なら数秒、複雑なフォーム入力なら数十秒）に応じて設定し、固定値より適応的な制御が望ましい。

エポック：世代番号による制御権の無効化

エポックは単調増加する世代番号であり、制御権が変更されるたびにインクリメントされる。重要な性質として、制御が変更されると以前の世代は無効になるという点がある。すなわち、エージェントAがエポック5で取得した操作権は、スケジューラがエージェントBに制御を移してエポック6に切り替えた時点で、自動的に無効となる。

このメカニズムが解決する問題は、エージェントAがリースのタイムアウトを待たずにBに制御を奪われた場合、AがまだDOMに書き込みを続けるとBが構築した状態を破壊するというシナリオである。エポック番号を各操作に付与し、スロット側で「現在のエポックと一致する操作のみ受理する」という検証を行うことで、古い世代の操作は安全に破棄される。

sequenceDiagram
    participant A as エージェントA
    participant S as スロット
    participant B as エージェントB
    A->>S: リース取得 (epoch=5)
    S-->>A: 許可 (epoch=5)
    A->>S: DOM操作 (epoch=5)
    S-->>A: 適用
    Note over S: 制御権をBに移譲
    S->>S: epoch=6 に更新
    B->>S: リース取得 (epoch=6)
    S-->>B: 許可 (epoch=6)
    A->>S: DOM操作 (epoch=5)
    S-->>A: 拒否（世代不一致）
    B->>S: DOM操作 (epoch=6)
    S-->>B: 適用

このシーケンスが示すように、エポック検証はスロット側の一元的なゲートとして機能する。エージェント側が「自分がまだ有効か」を判断するのではなく、スロットが受け入れ時に世代を照合する。これにより、エージェントがクラッシュした後の遅延リクエストや、ネットワーク遅延による操作の到着順の乱れにも耐性を持てる。

DOM状態の独立性：エージェントが操作する「画面」の分離

ブラウザエージェントが並列実行される際、最も深刻な衝突はDOMツリーレベルで発生する。複数のエージェントが同一のページに異なる操作を発行すると、CSSセレクターの解決結果が変化し、意図しない要素を操作する事象が起きる可能性がある。SessionDockのような設計では、ChromiumをプライベートなWestonデスクトップ上で実行し、表示を別個のビューアによって行うことで、この問題を回避しようとするアプローチが存在する。

Westonデスクトップによる入力経路の分離

WestonはWaylandプロトコルに基づく合成ウィンドマネージャであり、各スロットに専用のデスクトップセッションを割り当てることで、GUIイベントループや入力フォーカスの競合を構造的に排除する。通常のX11環境では、キーボードやマウスのイベントは全局的にディスパッチされるため、複数のブラウザウィンドウが同一のフォーカスコンテキストを共有するリスクがある。Westonのセッション分離により、各スロットのChromiumは独立した入力ストリームを持ち、他スロットの操作がフォーカスを奪うことを防げる。

ただし、この分離が完全に安全を担保するわけではない。スロットの競合キーは、スケジューラがディスパッチする作業のみを保護対象とし、人間の直接操作は対象外となる。つまり、運用者がビューア経由でスロットのブラウザに直接マウス操作を加えた場合、エージェントの進行中のDOM操作と衝突する可能性は残る。この保護範囲の非対称性は、ハイブリッド運用（人間とエージェントの共存）において注意すべき設計上の盲点である。

エージェント側のDOM監視と抽象レイヤー

実装側では、DOMノードのMutationObserverによる監視、イベントのフィルタリング、あるいは仮想DOM的な抽象レイヤーの導入を検討する必要がある。特に、エージェントが「要素Xをクリックする」という意図を持つ場合、DOMが他の要因で再構築された際にセレクターが解決しなくなる問題への対策が不可欠である。具体的には、操作前にノードの存在確認とエポック検証を組み合わせ、不一致を検知したら操作を中断してスケジューラに報告する、という防御的パターンが有効である。

stateDiagram-v2
    [*] --> Idle
    Idle --> Leased : エージェントがリース取得
    Leased --> EpochBump : 制御権移譲
    EpochBump --> Leased : 新エージェントがリース取得
    Leased --> Idle : リースタイムアウト
    Leased --> Idle : タスク完了
    Idle --> [*] : スロット破棄

この状態遷移において、EpochBumpは一時的な過渡状態であり、旧エージェントの操作がまだキューに残っている場合がある。この窓（エポック切り替えから新エージェントの初回操作までの間）に旧世代の操作が到達すると、スロット側で拒否されるが、エージェント側はエラーを認識して適切にリトライまたは中断する必要がある。この過渡期間の長さを最小化する設計が、実運用の安定性に直結する。

セキュリティと認証：USBキーやパスキーのブロックという現実

自動化されたブラウザ操作において、高度な認証手段は構造的な障害となる。SessionDockの現在のプロトタイプでは、USBセキュリティキーやスマートフォンパスキーの使用が明示的にブロックされている。これは、エージェントが物理的なデバイスのタッチや、SMS/プッシュ通知へのリアルタイムな応答ができないためであり、FIDO2やWebAuthnフローとの相性が根本的に悪いことを意味する。

ブロックの技術的理由

WebAuthnの認証フローでは、ブラウザがnavigator.credentials.create()を呼び出し、OSレベルのセキュリティモジュール（TPM、Secure Enclave、USBトークン）と通信する。エージェントがCDP（Chrome DevTools Protocol）経由でこのフローを代行するには、OSのセキュリティ境界をまたぐ操作が必要になるが、Westonデスクトップ上のChromiumではこの経路が閉じられている。パスキーの場合、スマートフォンのNFCタップやBluetooth近接通信がトリガーになるため、エージェントが物理的に応答不能である。

この制約により、設計者はユーザーにパスワードベースの認証やAPIキーの使用を事実上強制することになり、セキュリティレベルの低下を招く可能性がある。特に、2FAをWebAuthnで構成しているサービスに対しては、スロット経由のアクセス自体が不可能になる。このため、認証方式の選択はスロット基盤の設計段階で決定されるべきであり、事後に「このサービスにアクセスしたい」と追加するのが困難である。

代替認証フローの設計

WebAuthnを代替する現実的な方案として、セッションクッキーの長期保持とOAuthリフレッシュトークンの自動回転が考えられる。セッションクッキーをスロットのストレージに永続化し、有効期限内であれば再ログイン不要とすることで、エージェントの操作頻度を下げて認証フローの再実行を回避する。OAuthの場合は、リフレッシュトークンの有効期限が到来する前にエージェントが自動でトークン交換を行うスケジューリングが必要になる。

認証方式	エージェント互換性	実装難易度	主な制約
パスワード	高い（DOM入力で完結）	低	Brute-forceリスク、2FA未対応
セッションクッキー永続化	高い（ログイン1回のみ）	中	トークン失効時の再ログイン要
OAuthリフレッシュトークン	中（API呼び出しで可）	中	リフレッシュ頻度の管理が必要
WebAuthn / パスキー	不可（明示的にブロック）	—	物理デバイス応答が必要
USBセキュリティキー	不可（明示的にブロック）	—	物理接続とOSモジュール要

表に示すように、エージェントが操作可能なのはDOM経由の入力とHTTPリクエストに限られる。この制約を前提に、サービス側の認証フローを「エージェントが完結できる形」に設計するか、あるいはエージェントが介入できない認証は人間が手動で完了してからスロットをエージェントに引き渡す、という2段階運用を組み合わせる必要がある。単に「エージェントで全部やる」を前提にすると、多くのSaaSサービスに対してスロット基盤が機能しないことになる。

実装の空白地帯：MCPサーバーとアクションエグゼキューターの欠如

SessionDockのプロトタイプ段階において、公式解説記事が明確に指摘するように、MCP（Model Context Protocol）サーバー、エージェントアダプタ、完全なアクションエグゼキューターが欠落している。この3つの欠落はそれぞれ異なるレイヤーの問題であり、実務でこの基盤を採用する場合には、各レイヤーを自前で補完する必要がある。

MCPサーバーの欠落が意味すること

MCPはLLMが外部ツールやデータソースにアクセスするための標準化されたプロトコルであり、エージェントが「何ができるか」を宣言し、呼び出し方を構造化して伝える役割を持つ。これが無い場合、LLMからスロットへの操作指示を渡すには、プロンプトに自然言語で操作手順を埋め込むか、独自JSONスキーマを定義してパースするしかない。前者は再現性が低く、後者はプロトコル仕様の設計とバージョン管理のコストが発生する。

具体的には、スロットに対する「URLを開く」「要素をクリック」「フォームに値を入力」といったアクションを、LLMが構造化された形式で出力できるようにするインターフェースを自前で作る必要がある。このとき考慮すべきは、アクションの粒度である。粒度が粗すぎるとLLMの判断ミスが増え、細すぎるとトークン消費とレイテンシが増大する。実務的には、高頻度で使われる操作（ナビゲーション、入力、スクリーンショット取得）を原語として定義し、それらを組み合わせる「マクロ」をエージェント側で展開する二段階構造がバランスが良い。

アクションエグゼキューターの欠落と実装判断

アクションエグゼキューターとは、LLMが出力した構造化アクションをブラウザのDOM操作に変換して実行するコンポーネントである。これが欠落しているということは、DOM操作の「実行層」をゼロから書く必要があることを意味する。ここで設計判断が分かれるのは、実行層の信頼性の担保方法である。

一つの方法は、DOM操作を「宣言的なスクリプト」として定義し、実行前にバリデーションを行うアプローチである。例えば、対象要素のセレクタが存在しない場合や、要素がhidden状態の場合に実行を拒否し、エラーをLLMにフィードバックする。もう一つの方法は、操作を個別に実行し、各操作後にDOMスナップショットを比較して期待通りの状態遷移を検証するアプローチである。後者は堅牢だが、実行時間が2〜3倍に増えるため、並列エージェント数が多い場合の全体スループットに響く。

この空白を埋めるコストは、スロット基盤自体の導入コストと比べると過小評価されがちだが、実際にはプロジェクト全体の6割以上を占める場合がある。一方で、自社要件に合わせた制御（特定DOM要素へのアクセス制限、カスタムイベントフック、操作の監査ログ整形）を自由に設計できるという利点もある。標準化プロトコルが成熟するまでの過渡期として、この投資を「技術的負債の先取り」として位置づける判断が現実的である。

トレードオフ分析：完全分離 vs 運用コスト

スロットベースの分離アーキテクチャを採用するかどうかの判断には、セキュリティ要件と運用リソースの両面からトレードオフを評価する必要がある。以下に、スロット分離の特徴と適用ケースを整理する。

観点	スロット分離（同一ホスト）	VM/コンテナ分離
ネットワーク分離	共有（完全分離でない）	可能（独立NIC/プロキシ）
メモリ消費（スロット1つあたり）	中（Chromiumプロセス1つ）	高（OSカーネル+Chromium）
初期セットアップ	手動ログイン必要	イメージビルド+ログイン
認証制約	WebAuthn/USBキー不可	同様（物理デバイス依存）
向いているケース	内部ツール・低機密データ	顧客データ・金融・機密処理

表の通り、スロット分離の最大の弱点はネットワーク層の分離が不十分な点にある。スロットは同じホスト上に存在し、Chromiumがホストのネットワークアクセスを共有するため、IPベースのレートリミットやGeo-IP判定に対しては「完全な分離」ではない。この制約は、同一ホスト上の複数のスロットが同じ外部サービスにアクセスした場合に、サービス側から同一クライアントと判定されるリスクを意味する。内部業務システムへのアクセスや、レートリミットが緩いAPIの呼び出しであれば実務上問題にならないが、顧客個人データを扱う外部サービスへの並列アクセスでは、この分離不足がコンプライアンス上のリスクとなり得る。

運用コストの面では、各スロットでの手動ログインが前提である点が大きな負担になる。スロット数が10を超えると、初期セットアップ時のログイン作業だけで数時間かかると想定すべきである。また、セッションの有効期限が切れた場合の再ログインも手動で対応する必要がある。これを自動化するには、セッションクッキーの永続化やOAuthリフレッシュトークンの管理を別途実装するが、それはスロット基盤の外側の問題であり、基盤自体が解決するものではない。

判断基準として、次の3つの問いに「はい」が2つ以上当てはまる場合はVM/コンテナ分離を検討すべきである。①処理するデータに個人識別情報（PII）が含まれるか。②外部サービスへの並列アクセスでIP単位のリート制限に抵触する可能性があるか。③スロット間のサイドチャネル（共有メモリやキャッシュ経由の情報漏洩）が許容できないか。これらが「いいえ」の場合は、スロット分離で運用コストを抑えつつ、必要に応じてネットワーク層にプロキシを挟む補完策で十分である。

運用における落とし穴：エポック管理とデッドロック回避

エポック更新タイミングの設計

エポックは単調増加する生成番号であり、制御権が変更されると以前の世代は無効になるという設計である。運用上の注意点として、エポック更新の「トリガー」と「反映のタイミング」を明確にしない場合に問題が生じることがある。例えば、エージェントAがスロットを操作中に管理者が手動でスロットを再割り当てした場合、エポックがインクリメントされる。しかし、エージェントAが既にDOMに送信済みの非同期リクエスト（fetchやWebSocketメッセージ）は、エポック更新後もネットワークレベルでは処理され続ける場合がある。つまり、エポックは「新しい操作の開始」を防ぐことはできても、「進行中操作の即時キャンセル」までは保証しない可能性がある。

このギャップを埋めるには、エージェント側でエポック番号をリクエストヘッダーに含め、スロット側で受信時にエポックの妥当性を検証する仕組みが必要となる。エポックが古ければリクエストを破棄し、エージェントにエラーを返すように設計するとよい。この検証をスキップすると、古い世代のエージェントが新しいコンテキストのDOM状態に影響を与える可能性がある。

リースタイムアウトの適応的制御

リース（時間制限付きの排他的アクセス権）のタイムアウト値は、固定値で設定すると運用上問題が生じやすい。短すぎると、LLMの応答待ち時間中にリースが失効し、再接続コストが頻発する可能性がある。長すぎると、エージェントがクラッシュした際にスロットが長時間ブロックされ、他のエージェントが待機状態に追いやられる。

実務的には、ベースタイムアウトに「活動検出による延長」を組み合わせる方式が有効であることが多い。エージェントがDOM操作やHTTPリクエストを発行するたびにリースを自動延長し、一定時間活動がなければ失効させる。この「活動の定義」をどこまで広げるかが設計の分岐点になる。DOMのMutationObserverによる変化検出まで含めると、LLMの思考中（DOM操作なし）でもリースが維持され、意図しない長時間占有を防げなくなる可能性がある。そのため、明示的なアクション発行のみを活動とみなす方が安全である場合が多い。

人間介入との競合

競合キーはスケジューラがディスパッチする作業のみを保護し、人間の直接操作は対象外となるという設計である。これは、人間がスロットを直接操作している最中にエージェントが操作を開始しても、競合検知されないことを意味する。結果として、人間のクリックとエージェントのクリックがDOM上で交錯し、予期しない状態遷移が発生し得る。

このリスクを低減するには、スロットの状態に「人間操作中」のフラグを設け、エージェントのスケジューラがそのフラグが立っている間はディスパッチを保留する仕組みを追加するとよい。このフラグの検出方法として、スロットにマウスカーソルの移動やキー入力のイベントが一定頻度で発生しているかを監視するのが実用的である場合がある。ただし、この監視自体がスロットのオーバーヘッドを増やすため、検出周期は短くしすぎないことが望ましい。

監視と検知の観点では、エポック番号の変化イベントとリースの取得/解放イベントを構造化ログとして出力し、時系列で相関分析できるようにしておくことが重要である。予期せぬ競合は、通常「リース取得→エポック変更→リース失効」の順序が破綻した形でログに現れるため、このパターンを検出するアラームルールを設けることで、事象の早期発見が可能になる場合がある。

まとめ：マルチエージェント基盤設計への示唆

ブラウザエージェントの並列実行を本番運用に持ち込むには、単なるプロファイル分離では不十分であり、スロット管理と権限リースの仕組みが不可欠である。この領域の設計には「完全な自動化」を前提にすると到達できない制約が多数存在する。WebAuthnやUSBキーのブロック、手動ログインの前提、ネットワーク分離の不完全性、人間操作の競合保護の欠如——これらは制約として「回避すべきもの」ではなく、設計の出発点として「組み込むべきもの」として捉える必要がある。

MCPサーバーやアクションエグゼキューターが欠落している現状は、自前実装のコストという負担であると同時に、自社要件に合わせた制御を実現できる機会でもある。標準化プロトコルが成熟すれば、この部分は置き換え可能になるため、初回は最小限のインターフェースで実装し、プロトコルの変化に合わせて差し替える設計（アダプタパターン）を採用することで、将来の移行コストを抑えられる可能性がある。

最終的に、読者が自社の環境で判断すべきは「分離の粒度」である。ネットワーク層まで完全に分離する必要があるのか、それともDOM状態と権限制御の分離だけで十分なのか。この判断は、処理するデータの機密性、外部サービスとの契約条件、運用チームの対応能力の3つから導かれる。スロット基盤は特定の要件（低機密・内部ツール・中規模並列）に対して、VM分離よりも低いコストで実用的な分離を提供する場合がある。この適用範囲を正確に理解した上で、要件が範囲を超える部分には別の隔離手段を組み合わせる、という階層的な設計が考えられる。

参考

本記事は海外の技術トレンド「Multiple Browser Agents Need More Than Separate Profiles」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。