Playwright のマルチセッション分離 — 「ブラウザインスタンス」と「ログイン状態」は別の軸 Playwright のマルチセッション分離 — 「ブラウザインスタンス」と「ログイン状態」は別の軸
TL;DR Playwright を複数並行で使うときの「分離」には、混同しやすい 2 つの軸があります ① ブラウザインスタンスの分離: 複数のセッションが、それぞれ別プロセス・別プロファイルのブラウザを操作する ② アカウント / ログ
Playwright で複数のテストやセッションを並行実行する際、「分離」をうまく設計できないとログイン状態が混ざったり、テスト同士が干渉したりする。混乱の原因の多くは、本来別物である2つの軸を一括りに捉えてしまうことにある。それが「ブラウザインスタンスの分離」と「ログイン状態の分離」だ。
第1の軸は、ブラウザインスタンスの分離だ。複数のセッションがそれぞれ別プロセス・別プロファイルのブラウザを操作するという、ハードウェアやプロセス寄りの分離である。Playwright では browser.newContext() で生成する BrowserContext がここで重要な役割を果たす。コンテキストはシークレットウィンドウのように、Cookie やローカルストレージを独立して持つため、1つのブラウザプロセス内でも複数の独立した環境を比較的軽量に用意できる。完全にプロセスを分けたい場合は、複数の browser を起動する選択肢もある。
第2の軸は、アカウントやログイン状態の分離だ。これは「どのユーザーとしてログインしているか」という認証情報のレイヤーであり、ブラウザインスタンスをいくつ立てるかとは独立して考えられる。Playwright には storageState という仕組みがあり、Cookie やトークンを JSON として保存・再利用できる。これにより、各テストで毎回ログインし直す必要がなく、別アカウントの状態を別ファイルとして使い分けることも可能になる。
混同しやすいのは、両者が重なるケースが多いからだ。1コンテキスト=1アカウントとして使えば一見シンプルだが、同じブラウザインスタンスで別アカウントを切り替えたい、あるいは同じアカウントを複数コンテキストで使いたい場面では、軸を分けて考えないと設計が破綻する。並列実行を前提にすると、テスト間でログイン状態を共有すべきか分離すべきかという判断は、性能と信頼性のトレードオフに直結する。
近年は、こうした自動操作をエージェント経由で行う MCP(Model Context Protocol)サーバーとしての Playwright 利用も注目されている。AIエージェントが複数の作業を並行で進める場合、セッションごとにブラウザインスタンスと認証状態をどう割り当てるかが安定動作の鍵になると見られる。同種のツールである Puppeteer や Selenium でも基本的な考え方は共通しており、2軸を意識した設計はフレームワークを問わず有効だろう。テストの規模が大きくなるほど、この区別を最初に押さえておく価値は高い。
When running Playwright across multiple parallel sessions, the concept of "isolation" is frequently misunderstood, and conflating two distinct axes can lead to flaky tests, accidental data leakage between sessions, or wasted system resources. The key insight is that browser instance isolation and login state isolation are separate concerns. Treating them as one thing tends to produce setups that are either heavier than necessary or quietly share authentication where they should not. This distinction has become more relevant as Playwright is increasingly embedded inside MCP servers and agent workflows, where many sessions may operate concurrently.
The first axis is browser instance isolation. This describes whether sessions run as separate processes with separate user-data profiles, or whether they share a single browser process. In Playwright, launching a browser with one method creates a full process, while contexts created inside that browser behave like independent, sandboxed profiles. Each browser context has its own cookies, local storage, cache, and permissions, so two contexts in the same process cannot see each other's data. This is the default mechanism Playwright recommends for parallelism, because spinning up a fresh context is fast and cheap compared with launching a new browser. Multiple processes are only strictly necessary when you need different browser binaries, separate command-line flags, or hard OS-level separation.
The second axis is account or login state. This is about which credentials and session tokens a given page operates with, and it is governed largely by storage rather than by process boundaries. Playwright exposes this through storageState, a serialized snapshot of cookies and origin storage that can be saved after a login and reused to spawn new authenticated contexts without repeating the sign-in flow. Two contexts can share the same login state, or each can carry a distinct one, and that choice is independent of whether they run in the same process. You could, for example, have a single browser instance hosting two contexts logged in as two different users, or two separate browser processes that both restore the same admin session.
Conflating the axes causes practical problems. If you assume separate processes guarantee separate accounts, you may inadvertently reuse the same storageState and corrupt shared server-side state. Conversely, if you assume one process means one login, you might over-provision browsers when contexts would have sufficed. The cleaner model is to choose process-level separation only when you need it for stability or distinct configurations, and to manage login independently by assigning each context its own storage. This keeps memory use low while still letting you test multi-tenant or multi-role scenarios concurrently.
For the MCP context this article sits in, the distinction is especially important. Playwright-based MCP servers let language models drive a browser, and a single agent run may need several logical sessions. Designers must decide whether each session gets a fresh context, a persistent context, or a dedicated process. A persistent context, created by pointing Playwright at a user-data directory, retains login across runs and is convenient for tools that should "stay signed in," but it ties identity to disk and complicates parallelism. Ephemeral contexts with injected storageState are usually safer for scaling, because identity is data you pass in rather than a side effect of the filesystem.
Background concepts make this easier to reason about. Browser profiles map roughly to contexts; tabs map to pages; and authentication ultimately reduces to cookies and tokens that live in storage. Related tooling reflects the same split: Selenium has long separated driver processes from session capabilities, and Puppeteer offers incognito-style contexts that mirror Playwright's. Trace viewer, request interception, and global setup scripts that pre-generate login states are common companions that reinforce keeping authentication out of the process layer. CI pipelines benefit too, since they can cache a storageState artifact and fan it out across many shards.
In short, ask two independent questions for any parallel Playwright setup: how separate do the browsers need to be, and which identity does each session carry. The answers do not have to match. Keeping browser instance isolation and login state isolation on different axes appears to give the most flexible and resource-efficient designs, particularly as automated browser sessions multiply inside MCP and agent-driven systems.
本ページの本文・要約は AI による自動生成です。正確性は元記事 (zenn.dev) をご確認ください。
