Playwright MCPの「プロファイル」を理解する：persistent(既定)/isolated/extensionの3モードでログイン状態は毎回消えるのか残るのか

Playwright MCPにログインを含む操作を任せたら、次のセッションでもちゃんとログイン状態が残っていた。前に触ったサイトなのに、AIが「あれ、ログインが必要ですね」と初めましての顔でログイン画面から始めた。どちらも実際に見た人がいるはずです。私も最初は「なんで今回は覚えてるんだ」「なんで今回は忘れてるんだ」と挙動が気まぐれに見えて戸惑いました。

結論から言うと、これは気まぐれではなく仕様です。Playwright MCPには「プロファイル」という設定があり、どのモードで起動しているかでログイン状態の扱いがまるっきり変わります。今回はこの仕組みを整理します。Playwright MCP入門の続きとして読んでもらえる内容です。

デフォルトはpersistentモード
isolatedモードとの違い
3つ目、extensionモード
今どのモードで動いているか確認する
名前付きセッション管理は、まだ正式機能ではない
実務での使い分け

デフォルトはpersistentモード

Playwright MCPは何もオプションを付けずに起動すると、persistentプロファイルというモードで動きます。これが既定値です。

persistentモードでは、Cookie・localStorage・認証トークンといったブラウザの状態が、OS上のディレクトリにファイルとして保存されます。セッションを終えてMCPサーバーを再起動しても、次に開いた時にこの保存先を読み込むので、ログイン状態が残っているわけです。普段使っているChromeが再起動しても前回のログインを覚えているのと同じ理屈ですね。

面白いのが、このプロファイルの保存先がms-playwright/mcp-{channel}-{workspace-hash}という名前になっていて、workspace-hash、つまり作業しているプロジェクト（ワークスペース）ごとに自動で別のプロファイルになるという点です。プロジェクトAで使っていたログイン状態が、プロジェクトBに勝手に持ち込まれることはありません。意識していなくても、プロジェクト単位でちゃんと分離してくれているということです。

保存先を自分で指定したい場合は--user-data-dirで上書きできます。共有マシンでプロファイルの置き場所を明示したい時などに使う場面がありそうです。今どこにプロファイルができているか気になったら、一度該当のディレクトリを覗いてみましょう。Cookieやトークンがそのままファイルとして保存されているのが確認できるはずです。

ここで一つ、正直に注記しておきます。私も最初は「workspace-hashって具体的に何を元にしているんだろう」と気になって調べたのですが、公式ドキュメントでは作業ディレクトリ由来のハッシュ値でプロジェクトごとに一意になる、という説明にとどまっていて、ハッシュの生成アルゴリズムの詳細までは書かれていませんでした。中身を厳密に知らなくても「プロジェクトが変われば別プロファイルになる」という結果だけ覚えておけば実務上は困りません。

isolatedモードとの違い

一方で--isolatedフラグを付けて起動すると、まったく違う挙動になります。セッションを開くたびにまっさらな状態から始まる、ephemeral（一時的な）コンテキストになるのです。ブラウザを閉じた瞬間に、そのセッションで貯めたCookieもlocalStorageも全部消えます。

「じゃあisolatedモードだと毎回ログインからやり直すしかないのか」というと、そうでもありません。--storage-stateオプションで、あらかじめ用意しておいたJSONファイルから初期状態だけを注入できます。

npx @playwright/mcp@latest --isolated --storage-state=./auth-state.json

このstorage-stateファイルは、Playwrightのcontext.storageState()で保存できる普通のファイルです。storageStateでログイン状態を使い回す回で書いたテスト用の仕組みが、そのままMCPの認証済み起動にも使えるということですね。isolatedは「何も覚えていない」のではなく「セッションをまたいで勝手に覚え続けることはしない」だけで、最初の一回だけ意図的に状態を渡す分には問題ないわけです。

使い分けの軸はシンプルです。普段使いでちょっとしたブラウザ操作をAIに任せる、次回もログインしたままがいい、という場合はpersistentのままでいいでしょう。逆に、毎回同じクリーンな状態からテストを再現したい、他のセッションの状態が紛れ込むと困る、という場合はisolatedを選び、必要なら--storage-stateで認証済みの初期状態だけ渡す、という組み合わせが良さそうです。迷ったら、まず--isolatedを付けずに試してみましょう。デフォルトの挙動を体感してから、必要に応じてisolatedに切り替える方が理解しやすいと思います。

3つ目、extensionモード

persistentとisolatedはどちらもPlaywright MCPが自分でブラウザを起動するモードですが、extensionモードは違います。こちらは新しくブラウザを立ち上げるのではなく、すでに開いている自分のブラウザインスタンスに接続しにいきます。

使いどころとしては、今まさに手で操作している既存のタブの状態をそのままAIに触らせたい時です。「このタブに残っている状態」自体が今回欲しいものなら、persistent/isolatedのようにMCP側でプロファイルを用意するより、素直に今のブラウザに繋いでもらう方が早い、という場面に向いています。

私の場合、社内ツールに二段階認証でログインした直後の状態を使ってAIに続きの操作をしてもらいたい、という場面でこのモードのありがたみを実感しました。二段階認証はPlaywright MCPが自動で突破できるものではありませんから（できたらそれはそれで怖いですが）、人間がログインまで済ませた既存のタブにそのまま繋いでもらうのが一番手っ取り早いのです。persistentモードでプロファイルを保存しても、二段階認証のセッションが切れていれば結局手動ログインが要ります。extensionモードなら、その手間そのものを飛ばせます。

今どのモードで動いているか確認する

ここまで3つのモードを紹介しましたが、実際に自分のMCP設定がどれで動いているかは、起動コマンドを見ればわかります。Claude Codeなどのクライアント設定ファイルで、MCPサーバーの起動引数に--isolatedが入っているかどうかをまず確認しましょう。何も付いていなければpersistentです。

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

この設定ならpersistentモードです。ここに"--isolated"を足せばisolatedモード、さらに"--storage-state", "./auth-state.json"を足せば認証済み状態から始まるisolatedモード、という具合に引数を見ればどのモードかすぐ判別できます。

「前回の状態が残っているか自信がない」という時は、設定ファイルを直接見るのが一番確実です。ログの挙動だけで判断しようとすると、ネットワークの遅さなのかプロファイルの初期化なのか区別がつきにくいので（実際、私も最初はこの2つを混同していました）、まず設定ファイルを見る、が鉄則だと思います。

名前付きセッション管理は、まだ正式機能ではない

ここまで読むと「じゃあ複数のログイン状態を名前を付けて切り替えたい」と思う人もいるはずです。管理者アカウント用のセッションと一般ユーザー用のセッションを、コマンド一つで呼び分けられたら便利ですよね。

実際、microsoft/playwright-mcpのGitHub issueには、名前付きの永続コンテキストを作って保存・復元・複製できるようにしてほしい、という趣旨のfeature requestが上がっています(issue #1530)。複数のAIエージェントの間で認証済みコンテキストを引き継ぎたい、同じMCPコンテキストの中で管理者とメンバーの2つのロールを分けたい、といった要望が背景にあるようです。

ただし正直に書いておくと、これは執筆時点(2026年8月)ではあくまでfeature requestの段階で、正式に実装された機能ではありません。今できるのは、persistent(ワークスペース単位の自動分離)・isolated＋storage-state(明示的な初期状態の注入)・extension(既存ブラウザへの接続)の3つの組み合わせで工夫することです。将来的にsessionIdのようなパラメータで名前付き管理ができるようになるかもしれませんが、それを前提にした運用は今はまだ組めないと考えておいた方が安全です。

実務での使い分け

というわけで、3つのモードを実務目線で整理すると、こうなります。

普段の調査・作業でAIにブラウザを触らせる → persistent(既定のまま)。プロジェクトごとに自動で分離されるので、特に意識しなくてOKです。
毎回同じ条件でテストを再現したい → isolated。必要なら--storage-stateで認証済み状態だけ渡す。
今開いているタブの状態をそのまま使いたい → extension。
複数ロールを名前で切り替えたい → 現時点では正式機能なし。issue #1530の動向待ち。

私が最初にハマったのは、複数のプロジェクトでPlaywright MCPを使っていて、片方でログインしたはずなのにもう片方では毎回ログインを求められる、という状態でした。原因はworkspace-hashによる自動分離で、実は正しく動いていただけだったわけです。ログイン状態の「残る/消える」で悩んだら、まずは今どのモードで起動しているかを確認してみてください。

Playwright 1.62でMCPサーバーが本体同梱になった話やプロンプトインジェクションのリスク回もあわせて読んでもらうと、MCPでブラウザをAIに触らせる時の安全な設定が一通り揃うと思います。