【重複購入のご注意】この記事は「AI開発者の手帖」がnoteで販売している同名記事（2人目のエージェントがブラウザを開けない——プロファイル競合の切り分けと、4つの起動オプションの選び方）と同じ内容です。すでにnoteで購入・閲覧できる方は重複購入にご注意ください。
ブラウザを操作できるエージェントを、クライアントごとに Chrome DevTools MCP のサーバーを立てる構成で、既定の設定のまま2つ同時に動かすと、後から起動したほうが最初のツール呼び出しで止まります。筆者の手元（chrome-devtools-mcp 1.10.1）で、1つ目が動いている横に2つ目のサーバーを立ててツールを1回呼ぶと、返ってきたのはこの2行でした（ホームディレクトリは ~ に畳んでいます）。
The browser is already running for ~/.cache/chrome-devtools-mcp/chrome-profile. Use --isolated to run multiple browser instances.
Cause: The browser is already running for ~/.cache/chrome-devtools-mcp/chrome-profile. Use a different `userDataDir` or stop the running browser first.対処法まで添えてあるので親切に見えますが、この2行では決められないことが4つ残ります。いま掴んでいるのは動いているブラウザなのか、落ちたプロセスが置いていった錠なのか。掴んでいる相手に後から相乗りできるのか。提案されている isolated のフラグや別の userDataDir は、自分の用途で使えるのか。そして同じことを明日も繰り返さないために、どこを恒久的に変えるのか。
この記事は、ブラウザ操作のできるエージェントを、対話的に使うセッションと定期実行のジョブの両方で動かしている人に向けて書いています。エージェントを1つしか動かさない場合や、複数のクライアントが1つのサーバーを共有している場合、この競合は起きません。対象は macOS と Linux です。Windows は筆者が確認していないため含みません。Android の実機デバッグと、仮想マシンとホストの間のポート転送も範囲外です。
原因そのものは Chrome DevTools MCP 公式ドキュメントに書かれています。
The user data directory is not cleared between runs and is reused for subsequent
runs with the same channel. Only one browser can use it at a time.出典は公式リポジトリの advanced-usage.md です。原文はここにあります。
https://raw.githubusercontent.com/ChromeDevTools/chrome-devtools-mcp/main/docs/advanced-usage.md
2026-09-22 に取得しました。最後の一文が効きます。既定のユーザーデータディレクトリを同時に使えるブラウザは1つだけ。2つ目のセッションは、この設計そのものに阻まれて起動に失敗します。
置き場所も同じページにあります。macOS と Linux は ホームディレクトリ配下の .cache/chrome-devtools-mcp/chrome-profile、Windows は USERPROFILE 配下の同じ並びです。安定版以外のチャンネルを使うと、chrome-profile-canary のようにチャンネル名が後ろに付きます。
「使用中」で止まったときに、何を見れば次の一手が決まるかの流れです。筆者が公式の記述と手元の実測から整理したものです。「相乗りできる」は外から繋ぐ口が開いているという意味で、実際にどの方法で繋げるかは起動のしかたで変わります。
錠は、持ち主の名前を書いている
「使用中」で止まったとき、まず知りたいのは相手が生きているかどうかです。生きたブラウザが使っているなら待つか別の道を選ぶしかありませんが、落ちたプロセスが残しただけの錠なら、そのまま起動し直せば済みます。
筆者の実測です。手元の macOS でプロファイルのディレクトリを覗くと、SingletonLock という名前のシンボリックリンクがありました。中身はファイルではなく、向き先の文字列そのものが情報になっています。形はこうです。
SingletonLock -> ホスト名-プロセス番号つまり錠は、自分を掛けたプロセスの番号を書き残しています。錠そのものが無ければ、プロファイルは空いています。錠があれば、番号から持ち主の生死を確かめられます。持ち主がもういなければ、その錠は落ちたプロセスの残骸です。持ち主が生きているなら、次に見るのは起動のしかたです。ここで道が分かれます。デバッグ接続を TCP ポートで待ち受けているブラウザには、外から相乗りする口が開いています。pipe で起動したブラウザは親プロセスとの間でしか話せないので、外から入る口がありません。
この判定だけをする小さなスクリプトを書いて、実際に競合している状態へ当てました。出力はこうなりました。
プロファイル: ~/.cache/chrome-devtools-mcp/chrome-profile
判定: 使用中（pipe 接続。親プロセスとの間でしか話せない）
対処: 後から接続する手段は無い。別の --user-data-dir を用意する
exit=1掴んでいたのは生きたブラウザで、しかも pipe 起動でした。この場合、待つ以外にできることは「相手と別のプロファイルを使う」しかありません。エラー文が勧めてくるフラグは確かに別のプロファイルを作りますが、これが正解かどうかは用途によって変わります。
分かれ道は3つの質問でできている
競合を避ける起動オプションを、筆者は4つに分けて考えています。その場限りのプロファイルを作る（--isolated）、人が立ち上げた Chrome に自動で繋ぐ（--autoConnect）、デバッグポート越しに繋ぐ（--browser-url。WebSocket で繋ぐ --wsEndpoint も同じ仲間に入れました）、専用のユーザーデータディレクトリを指定する（--user-data-dir）。既定のディレクトリを共有したままにするのは、選択肢ではなく競合の原因の側です。各オプションの定義は configuration.md にあります。
https://raw.githubusercontent.com/ChromeDevTools/chrome-devtools-mcp/main/docs/configuration.md
公式は、起動済みの Chrome に繋ぐ2つの方式に、向く場面を一言ずつ添えています。自動接続は手動の確認とエージェントの操作で状態を共有したいとき、ポート接続はサンドボックスの中で動かすとき、という目安です。ただ、ログインが要るか、人がいるかの組み合わせで4つのどれが残るかという順序にはまとめていません。この順序は筆者の整理です。
決め手になるのは3つの質問です。ログイン済みの状態が要るか。人がその場で Chrome を立ち上げ、接続を許可できるか。そして、MCP サーバーに起動させたブラウザで困ることがないか。ログインが要って人もいない定期ジョブでは、最初の2問で4つのうち2つが落ちます。
関連する記事
エージェントを並列に動かすときに仕事をどう分けるかは、別の記事で扱いました。同じ資源を2つのセッションが取り合う本記事の問題の、一段上にあたります。
公式が条件を1枚にまとめていない設定を、自分の環境が対象かどうかへ落とす判定の型は、こちらでも同じ形で扱っています。
参考になったら、記事下部のライクとXの共有ボタンから応援してもらえるとうれしいです。
続きで読めるのは、錠を読んで持ち主の生死と起動方式を判定し、終了コードで返すスクリプトの全文、3つの質問から4つの起動オプションを選ぶ判断の順序、ログイン状態が必要で人がその場にいないという最も厳しい条件での設定例（MCP サーバーに起動させる形と、デバッグポート越しに繋ぐ形の両方）、そして環境によって答えが変わる箇所についての確認方法と合格条件です。では、自分の条件だと4つのうちどれが残るのか。ログインが要って人もいない定期ジョブなら、最初の2問で2つが落ちたあと、残る2つのどちらを選べばよいのか。続きは、その答えから始めます。
この記事のライター
