Playwright MCPで複数セッションを同時実行する方法｜--isolated設定と並列ブラウザ自動化の完全ガイド

Playwright MCPの複数セッション問題とは何か

Playwright MCPをClaude Codeや他のAIエージェントフレームワークに組み込んで複数セッションを並行稼働させる際に発生する「Browser is already in use」エラーの原因と、--isolatedフラグを中心とした解決策を解説します。Playwright MCPはModel Context Protocol（MCP）を介してAIエージェントにブラウザ操作機能を提供するサーバーであり、Claude Codeをはじめとする多くのAI開発ツールで採用されています。

Claude Codeで複数のブラウザ自動化タスクを同時に走らせようとしたとき、「Browser is already in use」というエラーに遭遇した経験はないでしょうか。1つ目のセッションでWebサイトのスクレイピングを実行中に、2つ目のセッションでフォーム入力を試みると、ブラウザが排他制御に引っかかって動かなくなる。Playwright MCPを業務に組み込むほど、この問題は避けて通れなくなります。

デフォルト設定で発生する「Browser is already in use」エラー

Playwright MCP Serverは、デフォルトではPersistentモード（永続プロファイルモード）で起動します。このモードでは、OSごとに固定されたユーザーデータディレクトリを使用します。

OS	デフォルトのプロファイルパス
Windows	`%USERPROFILE%\AppData\Local\ms-playwright\mcp-chrome-profile`
macOS	`~/Library/Caches/ms-playwright/mcp-chrome-profile`
Linux	`~/.cache/ms-playwright/mcp-chrome-profile`

このパスはPlaywright MCPのインスタンス間で共有されるため、1つ目のセッションがプロファイルディレクトリをロックしている最中に2つ目のセッションが同じディレクトリを開こうとすると、「Browser is already in use for ...mcp-chrome-profile, use --isolated to run multiple instances」というエラーが発生します。GitHub Issue #1294でも報告されている通り、CI/CDパイプラインや複数のClaude Codeセッションを並行稼働させる環境では、この制約が自動化のボトルネックになります。

BrowserContextとプロファイルロックの仕組み

この問題の根本は、Chromiumベースのブラウザが採用しているプロファイルロックの仕組みにあります。Chromiumはユーザーデータディレクトリ内にSingletonLock（Linuxの場合）やlockfileを作成し、同時に複数のプロセスが同じプロファイルにアクセスすることを防ぎます。これはブラウザのデータ整合性を守るための設計ですが、Playwright MCPのデフォルト設定ではすべてのインスタンスが同一のプロファイルパスを参照するため、プロファイルロックの競合が原因でセッションの排他制御が発生します。

BrowserContextはPlaywrightにおける「分離されたブラウザセッション」の単位です（Playwright公式: BrowserContext API）。Cookie、ローカルストレージ、キャッシュなどのブラウザ状態はBrowserContextごとに独立しています。Persistentモードでは1つのBrowserContextが1つのユーザーデータディレクトリに紐づくため、ディレクトリが占有されていれば新しいBrowserContextは作成できません。

なぜ並列実行が求められるのか

ブラウザ自動化のユースケースが高度になるほど、並列実行の必要性は高まります。たとえば、複数のECサイトの在庫情報を同時に監視するタスク、異なるアカウントでのログイン状態を維持しながらのテスト実行、サブエージェントを使った分散スクレイピングなどです。Claude Codeのサブエージェント機能やAgent Teams機能を活用すれば、複数のAIエージェントが並列でブラウザ操作を行う構成が自然に生まれます。Claude Codeの権限設定の最適化と組み合わせれば、ブラウザ自動化タスクをより安全に並列実行できます。GitHub Issue #893では、複数のClaude Codeエージェントが「同じタブを奪い合う」現象が報告されており、並列実行を前提としたセッション設計が不可欠であることがわかります。

Playwright MCPのセッションモード3種（Persistent / Isolated / Extension）の使い分け

Playwright MCP Serverは3つの動作モードを提供しており、ユースケースに応じて選択します。それぞれのモードはブラウザプロファイルの扱い方が根本的に異なるため、選択を誤ると認証情報の消失やセッション競合といった問題を引き起こします。ここでは各モードの特性と適切な使い分けを解説します。

Persistentモード — 単一セッション・認証永続化向け

Persistentモードはデフォルトの動作モードです。ブラウザのユーザーデータディレクトリがディスク上に永続化されるため、セッション終了後もCookie、ローカルストレージ、ブラウザ拡張機能の状態が保持されます。一度ログインしたWebサービスには、次回セッション開始時にも認証済みの状態でアクセスできます。

このモードが適しているのは、単一のClaude Codeセッションで1つのブラウザを使い続ける場合です。認証が必要なサービスを繰り返し操作する定型業務や、ブラウザの状態を開発セッション間で引き継ぎたい場合に向いています。ただし前述の通り、複数インスタンスの同時起動はプロファイルロックによってブロックされます。

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

明示的なフラグは不要です。何も指定しなければPersistentモードで起動します。

Isolatedモード — 複数セッション・並列実行向け

Isolatedモードは--isolatedフラグを指定して起動するモードです。セッションごとにメモリ上の一時プロファイルが生成され、ディスクには一切書き込まれません。ブラウザを閉じるとCookie、ローカルストレージ、キャッシュを含むすべての状態が破棄されます。

各セッションが独立した一時プロファイルを使用するため、プロファイルロックの競合が発生しません。複数のPlaywright MCPインスタンスを同時に起動しても、それぞれが独自の空間で動作します。複数のClaude Codeセッションやサブエージェントからブラウザを並列操作する場合は、このモードが基本的な選択肢になります。

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--isolated"]
    }
  }
}

デメリットは、セッション終了時に認証状態が消失する点です。毎回ログインし直す必要がある場合は、後述する--storage-stateとの併用で解決できます。

Extensionモード — ブラウザ拡張連携向け

Extensionモードは--extensionフラグで起動し、既存のブラウザインスタンスに接続するモードです。Playwright MCP Bridge拡張機能をChrome/Edgeにインストールした状態で使用します。新たにブラウザを起動するのではなく、ユーザーが普段使っているブラウザのタブやログイン状態をそのまま活用できます。

ブラウザ拡張機能が必要な操作（パスワードマネージャー連携、広告ブロッカーの動作確認など）に適していますが、既存ブラウザへの接続であるため並列実行には向きません。

判断フローチャート — どのモードを選ぶべきか

モード選択の基本方針は「並列実行が必要かどうか」を起点に考えることです。並列実行が不要で認証永続化が必要ならPersistent、並列実行が必要ならIsolated、既存ブラウザの拡張機能を使いたいならExtensionを選択します。Isolatedモードで認証が必要な場合は--storage-stateを併用します。

--isolatedフラグで複数セッションを同時実行する方法

ここからは、--isolatedフラグを使って複数のPlaywright MCPセッションを並列実行する具体的な手順を解説します。

.claude.jsonでの--isolated設定手順

Claude Codeで--isolatedフラグを有効にするには、.claude.json（プロジェクトルート）または~/.claude.json（ユーザーグローバル）のmcpServers設定を変更します。

.claude.jsonを開き、mcpServersセクションのPlaywright設定を確認する
args配列に"--isolated"を追加する
Claude Codeを再起動して設定を反映させる

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--isolated"]
    }
  }
}

args配列に"--isolated"を1行追加するだけで、プロファイルロック問題は解消されます。この設定により、Playwright MCPは起動のたびにメモリ上の一時プロファイルを使用するため、複数インスタンスが同一ディレクトリを取り合う事態が発生しなくなります。

headlessモードとの併用も可能です。--headlessフラグを追加すれば、ブラウザウィンドウを表示せずにバックグラウンドで実行できます。

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--isolated", "--headless"]
    }
  }
}

独立プロファイルが生成される仕組み（user-data-dir）

--isolatedフラグを指定すると、Playwright MCPは--user-data-dirにディスク上のパスを設定する代わりに、ブラウザの一時プロファイル機能を利用します。Chromiumの場合、一時プロファイルはメモリ上（またはOSの一時ディレクトリ）に作成され、ブラウザプロセスの終了とともに自動削除されます。

Persistentモードでは固定パス（{AppData}/Local/ms-playwright/mcp-chrome-profileなど）が使われるため、同じパスへの同時アクセスがロックで弾かれていました。Isolatedモードではセッションごとに異なる一時パスが割り当てられるため、ロックの競合自体が原理的に発生しません。

なお、--user-data-dirフラグを使って手動で一時ディレクトリを指定する方法もあります。

TMPDIR=$(mktemp -d)
npx @playwright/mcp@latest --user-data-dir "$TMPDIR"

この方法はシェルスクリプトやCI/CDパイプラインで柔軟にディレクトリを制御したい場合に便利です。ただし、.claude.jsonで--isolatedを設定している場合はそちらが優先されるため、両方を同時に指定すると整合性の問題が生じる可能性があります。

動作確認 — 複数Claude Codeセッションからの同時起動テスト

設定が正しく反映されているかを確認するために、以下の手順で動作テストを行います。

ターミナルを2つ開き、同じプロジェクトディレクトリでClaude Codeを起動する
1つ目のセッションでPlaywright MCPのbrowser_navigateを呼び出し、任意のWebページを開く
1つ目のセッションのブラウザが開いたまま、2つ目のセッションで別のWebページにbrowser_navigateする
両方のセッションがそれぞれ独立したブラウザウィンドウで動作していることを確認する

--isolatedが正しく設定されていれば、2つのブラウザウィンドウが同時に開き、互いに干渉することなく操作できます。「Browser is already in use」エラーが表示される場合は、.claude.jsonの設定が正しく保存されているか、Claude Codeの再起動が完了しているかを確認してください。

認証状態を保持したまま並列実行する（--storage-state + --isolated）

Isolatedモードの最大の欠点は、セッション終了時にすべてのブラウザ状態が消えることです。認証が必要なWebサービスを操作するたびに毎回ログインし直すのは非効率です。この問題を解決するのが--storage-stateフラグとの併用です。

--storage-stateでCookie・ローカルストレージを引き継ぐ

--storage-stateフラグにJSONファイルのパスを指定すると、Isolatedモードのセッション開始時にそのファイルからCookieとローカルストレージの状態を読み込みます。--storage-stateと--isolatedを組み合わせることで、認証状態を失わずにセッション分離と並列実行を両立できます。

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--isolated",
        "--storage-state", "./auth/session-state.json"
      ]
    }
  }
}

session-state.jsonにはCookieとlocalStorageの情報がJSON形式で保存されています。このファイルを複数のIsolatedセッションで共有すれば、すべてのセッションが認証済みの状態で起動します。

認証済みセッションのエクスポートと再利用手順

storage-stateファイルを作成するには、まずPersistentモードで対象のWebサービスにログインし、その状態をエクスポートします。

Persistentモード（--isolatedなし）でPlaywright MCPを起動する
browser_navigateで対象のWebサービスにアクセスし、通常の手順でログインする
ログイン完了後、Playwrightのbrowser_run_codeツールで以下のコードを実行し、状態をファイルに保存する

const context = page.context();
await context.storageState({ path: './auth/session-state.json' });

保存されたJSONファイルの内容を確認し、想定するCookieやlocalStorageが含まれていることを検証する
.claude.jsonを--isolatedと--storage-stateの併用設定に切り替える

エクスポートされたJSONファイルには認証トークンやセッションIDが含まれるため、.gitignoreに追加してバージョン管理から除外してください。また、トークンの有効期限が切れた場合は同じ手順で再エクスポートが必要です。

セッション分離と認証共有の両立パターン

実務では、複数のセッションが同じ認証情報を共有しつつ、ブラウザの操作状態（開いているタブ、フォームの入力内容など）は完全に分離したいケースが多くあります。--isolatedと--storage-stateの組み合わせはまさにこのパターンを実現します。

認証状態（Cookie・トークン）はJSONファイルから読み込まれて全セッションで共有される一方、各セッションのDOM操作やナビゲーション履歴はメモリ上の一時プロファイルに閉じるため、セッション間で干渉しません。ただし、セッションAがログアウト操作を実行してサーバーサイドのセッションを無効化した場合、同じCookieを使っているセッションBの認証も失効する点には注意が必要です。サーバーサイドのセッション管理は--storage-stateの守備範囲外です。

複数セッション実現方法の比較 — --isolated / playwright-parallel-mcp / Docker

Playwright MCPで複数セッションを実現するアプローチは--isolatedフラグだけではありません。サードパーティのplaywright-parallel-mcpパッケージやDockerによるコンテナ分離も選択肢に入ります。それぞれの特性を整理し、プロジェクトの要件に応じた選択を可能にします。

公式--isolatedフラグ（軽量・推奨）

microsoft/playwright-mcpの公式機能である--isolatedフラグは、追加パッケージなしで使える最も軽量なアプローチです。.claude.jsonに1行追加するだけで有効になり、セッションごとにメモリ上の一時プロファイルが作成されます。公式の--isolatedフラグは追加依存なし・設定1行で済むため、複数セッションの実現手段として最も軽量かつ推奨されるアプローチです。

プロセスレベルの分離ではなくBrowserContextレベルの分離であるため、すべてのセッションが同一のNode.jsプロセス内で動作します。極端に多数のセッションを同時実行する場合はメモリ消費に注意が必要ですが、5〜10セッション程度であれば問題なく動作します。

playwright-parallel-mcpパッケージ（複数ポート起動方式）

playwright-parallel-mcpは、プロセスレベルの分離を提供するサードパーティパッケージです。セッションごとに独立した子プロセスを起動し、各プロセスが自身のPlaywright MCPバックエンドを持ちます。

{
  "mcpServers": {
    "playwright-parallel": {
      "command": "npx",
      "args": ["playwright-parallel-mcp"],
      "env": {
        "MAX_SESSIONS": "10",
        "SESSION_TIMEOUT_MS": "3600000"
      }
    }
  }
}

create_session、close_session、list_sessionsの3つの管理ツールが追加され、セッションのライフサイクルを明示的に制御できます。バックエンドツール（browser_navigate、browser_clickなど）は各セッションにsessionIdパラメータが自動注入され、どのブラウザインスタンスに対する操作かを一意に指定できます。

公式の--isolatedとの違いは、プロセスレベルで完全に分離される点です。あるセッションでクラッシュが発生しても他のセッションには影響しません。一方で、セッション管理のオーバーヘッドが追加されるため、単純な並列実行には過剰な場合もあります。

Dockerコンテナ分離方式（完全隔離）

最も強力な分離レベルを提供するのがDockerコンテナによるアプローチです。各セッションを独立したコンテナ内で実行し、ファイルシステム、ネットワーク、プロセス空間をすべて分離します。Microsoftが提供する公式Playwrightコンテナイメージを使用するのが推奨です。


services:
  playwright-session-1:
    image: mcr.microsoft.com/playwright:v1.52.0-noble
    command: npx @playwright/mcp@latest --headless --port 3001
    ports:
      - "3001:3001"
  playwright-session-2:
    image: mcr.microsoft.com/playwright:v1.52.0-noble
    command: npx @playwright/mcp@latest --headless --port 3002
    ports:
      - "3002:3002"

セキュリティ要件が厳格な環境や、セッション間のリソース干渉（CPU・メモリ）を完全に排除したい場合に適しています。Cloudflare Browser Renderingのようなリモートブラウザサービスと組み合わせれば、ローカルリソースを消費せずにスケーラブルな並列実行も実現できます。ただし、Docker環境の構築と管理のコストが加わるため、小規模なプロジェクトには過剰です。

比較表

比較項目	--isolated（公式）	playwright-parallel-mcp	Docker分離
分離レベル	BrowserContext	プロセス	コンテナ
セットアップ	`.claude.json`に1行	npmパッケージ追加	Docker環境構築
追加依存	なし	playwright-parallel-mcp	Docker / Docker Compose
セッション管理	自動（暗黙的）	明示的（create/close）	コンテナ単位
クラッシュ耐性	他セッションに影響あり	他セッションに影響なし	完全隔離
メモリ効率	高い	中程度	低い（コンテナごとのオーバーヘッド）
推奨ケース	一般的な並列実行	大規模・高信頼性が必要	セキュリティ要件が厳格

Claude Codeで複数ブラウザタスクを同時処理するワークフロー

--isolatedの設定方法を理解したところで、実際にClaude Codeから複数のブラウザタスクを同時に処理するワークフローを設計します。

サブエージェント×Playwright MCPの並列アーキテクチャ

Claude Codeのサブエージェント（Agentツール）は、親エージェントから独立したコンテキストで動作します。hook機構によるAI間権限管理と組み合わせると、各エージェントが適切な権限でブラウザ操作を実行する構成が可能です。各サブエージェントがPlaywright MCPのbrowser_navigateやbrowser_clickを呼び出すとき、--isolatedモードが有効であれば、それぞれのサブエージェントに対して独立したブラウザインスタンスが割り当てられます。

この仕組みを活用すると、親エージェントが「調査タスクA」と「調査タスクB」を2つのサブエージェントに委任し、それぞれが独自のブラウザで並列にWebサイトを操作するアーキテクチャが成立します。親エージェントはサブエージェントの完了を待ってから結果を集約し、次のステップに進みます。

実践例 — 複数サイトの同時スクレイピングとフォーム入力

具体的なワークフローの例として、3つの競合サイトの価格情報を同時に収集するケースを考えます。

親エージェントのプロンプトで以下のように指示します。

以下の3サイトから商品Xの価格情報を取得してください。
サブエージェントを3つ起動し、並列で処理してください。

1. https://example-store-a.com/product-x
2. https://example-store-b.com/product-x
3. https://example-store-c.com/product-x

各サイトで商品名、価格、在庫状況を取得し、比較表を作成してください。

各サブエージェントはbrowser_navigateで担当サイトにアクセスし、browser_snapshotでページ内容を取得します。--isolatedモードにより、3つのブラウザインスタンスが互いに干渉することなく同時に動作します。

フォーム入力を伴うタスクでも同様です。たとえば複数のテスト環境に対して同じ入力パターンを同時に投入するE2Eテストでは、各サブエージェントがbrowser_fill_formとbrowser_clickを使って独立した環境でフォーム操作を行います。

エラーハンドリングとセッションのクリーンアップ

並列実行では、一部のセッションだけがエラーになるケースに備える必要があります。ネットワークエラーやタイムアウトが発生した場合、そのサブエージェントのブラウザセッションだけが影響を受け、他のサブエージェントは正常に動作を続けます。これは--isolatedモードの利点の1つです。

セッションのクリーンアップについては、--isolatedモードではブラウザ終了時に一時プロファイルが自動削除されるため、明示的なクリーンアップ処理は基本的に不要です。ただし、ブラウザプロセスが異常終了した場合にゾンビプロセスが残る可能性があるため、長時間稼働する自動化パイプラインでは定期的にプロセスの確認を行うことを推奨します。


tasklist | findstr chromium


ps aux | grep chromium

トラブルシューティング — プロファイルロックとセッション競合の解決

--isolatedモードを設定しても、運用中にセッション関連の問題が発生することがあります。ここでは頻出するトラブルとその解決策を整理します。

プロファイルロックエラーの原因と強制解除手順

「Browser is already in use」エラーが--isolated設定済みにもかかわらず発生する場合、以下の原因が考えられます。

1つ目は、設定の反映漏れです。.claude.jsonを編集した後にClaude Codeを再起動していない場合、旧設定（Persistentモード）のまま動作します。Claude Codeのセッションを完全に終了してから再度起動してください。

2つ目は、前回セッションのブラウザプロセスが残存しているケースです。異常終了などでブラウザプロセスが正しく終了しなかった場合、プロファイルディレクトリのロックファイルが残ります。以下の手順で強制解除できます。

残存するブラウザプロセスをすべて終了する
デフォルトのプロファイルディレクトリ内のロックファイルを削除する


taskkill /F /IM chrome.exe 2>/dev/null
rm -f "$LOCALAPPDATA/ms-playwright/mcp-chrome-profile/SingletonLock"


pkill -f chromium 2>/dev/null
rm -f ~/.cache/ms-playwright/mcp-chrome-profile/SingletonLock

Claude Codeを再起動し、ブラウザが正常に起動することを確認する

セッションリークの検出と対策

セッションリークとは、使い終わったブラウザプロセスが解放されずにメモリやCPUを消費し続ける状態です。--isolatedモードでは一時プロファイルの自動削除機構があるものの、ブラウザプロセス自体の終了は保証されません。

長時間稼働する環境では、プロセス監視スクリプトを定期実行することでリークを検出できます。


ps -eo pid,etimes,comm | awk '$2 > 3600 && $3 ~ /chromium/ {print $1}'

playwright-parallel-mcpを使っている場合は、SESSION_TIMEOUT_MS環境変数でセッションの自動タイムアウトを設定できます。デフォルトは3,600,000ミリ秒（1時間）で、この時間を超えて無操作のセッションは自動的に終了されます。

browser_closeの代わりにnavigateでセッションを維持する方法

Claude Code環境では、browser_closeツールの呼び出しに注意が必要です。browser_closeはブラウザプロセスを完全に終了させるため、同一プロセス内で管理されている他のセッションのCookieやブラウザ状態が破壊されるリスクがあります。

安全なセッション切り替え方法は、browser_closeの代わりにbrowser_navigateで次の作業先URLに遷移することです。ブラウザプロセスを閉じずにページ遷移するだけなので、Cookie状態やlocalStorageは維持されます。


browser_navigate → https://next-task-site.com


browser_close → browser_navigate → https://next-task-site.com

タスクの完全終了時にブラウザを閉じたい場合でも、--isolatedモードであればセッション終了時に一時プロファイルが自動削除されるため、明示的なbrowser_closeは不要です。Claude Codeのセッション自体を終了すれば、関連するブラウザプロセスも併せて終了されます。

よくある質問（FAQ）

--isolatedと--headlessは併用できますか？

併用できます。.claude.jsonのargs配列に"--isolated"と"--headless"の両方を指定することで、ブラウザウィンドウを表示せずに複数セッションを並列実行できます。CI/CDパイプラインやサーバー環境でのバッチ処理に適した組み合わせです。"--isolated"が複数セッションの分離を担い、"--headless"がGUI非表示を担うため、機能的に干渉しません。

並列セッション数の上限はありますか？

Playwright MCP側に明示的なセッション数の上限は設定されていません。実際の上限はマシンのメモリ容量とCPUリソースに依存します。Chromiumベースのブラウザは1インスタンスあたり200〜500MB程度のメモリを消費するため、16GBのメモリを搭載したマシンであればOS・他プロセスの使用分を差し引いて10〜20セッション程度が実用的な範囲です。--headlessモードを併用すると、GPUレンダリングが不要になる分メモリ消費が軽減され、同一マシンでより多くのセッションを維持できます。playwright-parallel-mcpを使う場合はMAX_SESSIONS環境変数で明示的に上限を設定できます（デフォルトは10）。

--isolatedモードでブラウザ拡張機能は使えますか？

--isolatedモードでは一時プロファイルが使用されるため、Persistentモードでインストールしていたブラウザ拡張機能は利用できません。拡張機能が必要な場合は、Extensionモード（--extensionフラグ）を使って既存のブラウザインスタンスに接続するか、--user-data-dirで拡張機能がインストール済みのプロファイルディレクトリを明示的に指定する方法があります。ただし--user-data-dirを指定すると同一ディレクトリへのロック競合が再発するため、並列実行との両立にはセッションごとに異なるディレクトリを用意する必要があります。

Persistent→Isolatedに切り替えたとき認証状態はどうなりますか？

Persistentモードで蓄積されたCookie、ローカルストレージ、ログイン状態は、Isolatedモードに切り替えた時点で引き継がれなくなります。Isolatedモードは毎回空の一時プロファイルで起動するため、切り替え直後からすべてのWebサービスで未認証の状態になります。認証を維持したい場合は、切り替え前にPersistentモードの状態でstorage-stateをエクスポートし、--storage-stateフラグで読み込む設定に変更してください。エクスポート手順は本記事の「認証済みセッションのエクスポートと再利用手順」を参照してください。

まとめ — Playwright MCP複数セッション管理のベストプラクティス

Playwright MCPの複数セッション問題は、--isolatedフラグの追加という1つの設定変更で解決できます。Persistentモードのプロファイルロック競合を回避し、セッションごとに独立した一時プロファイルで動作させることで、複数のClaude Codeセッションやサブエージェントからの並列ブラウザ操作が可能になります。

認証状態の維持が必要な場合は--storage-stateとの併用で対応し、より強力なプロセスレベルの分離が必要な場合はplaywright-parallel-mcpを検討してください。セキュリティ要件が厳格な環境では、Dockerコンテナによる完全隔離も選択肢に入ります。

運用上の注意点として、browser_closeはCookie破壊のリスクがあるためbrowser_navigateでの遷移を優先すること、長時間稼働環境ではゾンビプロセスの監視を組み込むこと、そしてstorage-stateファイルには認証情報が含まれるためバージョン管理から除外することを覚えておいてください。

まずは.claude.jsonに"--isolated"を追加するところから始めてください。それだけで、Playwright MCPの並列実行における最大の障壁であるプロファイルロック問題は過去のものになります。Playwright MCPの最新リリースやオプションの変更については公式リポジトリのREADMEを定期的に確認することをお勧めします。

Playwright MCPの複数セッション問題とは何か

デフォルト設定で発生する「Browser is already in use」エラー

BrowserContextとプロファイルロックの仕組み

なぜ並列実行が求められるのか

Playwright MCPのセッションモード3種（Persistent / Isolated / Extension）の使い分け

Persistentモード — 単一セッション・認証永続化向け

Isolatedモード — 複数セッション・並列実行向け

Extensionモード — ブラウザ拡張連携向け

判断フローチャート — どのモードを選ぶべきか

--isolatedフラグで複数セッションを同時実行する方法

.claude.jsonでの--isolated設定手順

独立プロファイルが生成される仕組み（user-data-dir）

動作確認 — 複数Claude Codeセッションからの同時起動テスト

認証状態を保持したまま並列実行する（--storage-state + --isolated）

--storage-stateでCookie・ローカルストレージを引き継ぐ

認証済みセッションのエクスポートと再利用手順

セッション分離と認証共有の両立パターン

複数セッション実現方法の比較 — --isolated / playwright-parallel-mcp / Docker

公式--isolatedフラグ（軽量・推奨）

playwright-parallel-mcpパッケージ（複数ポート起動方式）

Dockerコンテナ分離方式（完全隔離）

比較表

Claude Codeで複数ブラウザタスクを同時処理するワークフロー

サブエージェント×Playwright MCPの並列アーキテクチャ

実践例 — 複数サイトの同時スクレイピングとフォーム入力

エラーハンドリングとセッションのクリーンアップ

トラブルシューティング — プロファイルロックとセッション競合の解決

プロファイルロックエラーの原因と強制解除手順

セッションリークの検出と対策

browser_closeの代わりにnavigateでセッションを維持する方法

よくある質問（FAQ）

--isolatedと--headlessは併用できますか？

並列セッション数の上限はありますか？

--isolatedモードでブラウザ拡張機能は使えますか？

Persistent→Isolatedに切り替えたとき認証状態はどうなりますか？

まとめ — Playwright MCP複数セッション管理のベストプラクティス

関連記事

関連する専門ポータル

Playwright MCPで複数セッションを同時実行する方法｜--isolated設定と並列ブラウザ自動化の完全ガイド

Playwright MCPの複数セッション問題とは何か

デフォルト設定で発生する「Browser is already in use」エラー

BrowserContextとプロファイルロックの仕組み

なぜ並列実行が求められるのか

Playwright MCPのセッションモード3種（Persistent / Isolated / Extension）の使い分け

Persistentモード — 単一セッション・認証永続化向け

Isolatedモード — 複数セッション・並列実行向け

Extensionモード — ブラウザ拡張連携向け

判断フローチャート — どのモードを選ぶべきか

--isolatedフラグで複数セッションを同時実行する方法

.claude.jsonでの--isolated設定手順

独立プロファイルが生成される仕組み（user-data-dir）

動作確認 — 複数Claude Codeセッションからの同時起動テスト

認証状態を保持したまま並列実行する（--storage-state + --isolated）

--storage-stateでCookie・ローカルストレージを引き継ぐ

認証済みセッションのエクスポートと再利用手順

セッション分離と認証共有の両立パターン

複数セッション実現方法の比較 — --isolated / playwright-parallel-mcp / Docker

公式--isolatedフラグ（軽量・推奨）

playwright-parallel-mcpパッケージ（複数ポート起動方式）

Dockerコンテナ分離方式（完全隔離）

比較表

Claude Codeで複数ブラウザタスクを同時処理するワークフロー

サブエージェント×Playwright MCPの並列アーキテクチャ

実践例 — 複数サイトの同時スクレイピングとフォーム入力

エラーハンドリングとセッションのクリーンアップ

トラブルシューティング — プロファイルロックとセッション競合の解決

プロファイルロックエラーの原因と強制解除手順

セッションリークの検出と対策

browser_closeの代わりにnavigateでセッションを維持する方法

よくある質問（FAQ）

--isolatedと--headlessは併用できますか？

並列セッション数の上限はありますか？

--isolatedモードでブラウザ拡張機能は使えますか？

Persistent→Isolatedに切り替えたとき認証状態はどうなりますか？

まとめ — Playwright MCP複数セッション管理のベストプラクティス

関連記事

GitとGitHubの使い方入門｜チーム開発の第一歩

関連する専門ポータル