「ブラウザを自動操作するMCPサーバーをClaude Codeから呼んでいたら、急に『接続が切れました』と言われた」「複数のClaude Codeセッションを並行で動かしていたら、片方のブラウザ操作がもう片方の画面を書き換えていた」「スクリーンショットを撮ろうとしただけなのに、相手の作業中のタブが変わってしまった」――ブラウザ自動操作系のMCPサーバーを使っていると、こうした「接続が切れる」「操作が反映されない」「他の作業を壊す」詰まりに遭遇しやすい。原因の多くは共通していて、ブラウザを自動操作するMCPサーバーの実装が「同時に1接続しか受け付けない」設計になっていることにある。この記事では症状の見分け方、原因、そして安全な2つの回避策を解説する。
- ブラウザ操作系のMCPサーバー（Firefox・Chrome系）は同時に1接続しか受け付けない実装が多い
- 別のセッション・エージェントが先に繋いでいる状態で新規接続すると、エラーで切断されるか、相手の操作中の状態を横から書き換える
- 回避策は「ユーザーの普段使いブラウザで直接確認してもらう」か「確認用の別ブラウザへ一時的に切り替える」の二択
- ヘッドレスブラウザはソフトウェア描画になるため、実機GPUに依存する描画性能の確認には使えない
目次を開く
症状: どう出るか
MCP経由でブラウザ操作ツールを呼ぶと、次のような形で詰まりが出る。
| 症状 | 典型的な状況 |
|---|---|
| 新規接続が即座にエラーで切断される | 別のセッション・エージェントが既にそのMCPサーバーに接続中 |
| 操作は通るが、意図しないページやタブに反映される | 同時接続で片方の操作がもう片方に割り込んだ |
| スクリーンショットの内容が自分の操作結果と違う | 相手が開いていた画面を撮ってしまっている |
いずれも「エラーメッセージが分かりにくい」「毎回同じ形で再現しない」のが特徴で、ツール自体の不具合と誤認しやすい。
切り分け方
まず、同じMCPサーバーを使っている別のプロセス・セッションが無いかを確認する。
ps aux | grep -i -E "firefox|chrome" | grep -v grepブラウザのプロセスが複数走っている、または別のターミナル・セッションで同じ自動操作ツールを呼んでいる形跡があれば、競合が疑われる。
原因: なぜ起きるか
ブラウザを自動操作するMCPサーバーの多くは、ブラウザのデバッグ用プロトコルへの接続を1本しか張らない実装になっている。複数のクライアント（複数のClaude Codeセッション、複数のエージェント）が同時に同じMCPサーバー経由で繋ごうとすると、次のどちらかが起きる。
- 後から接続した側がエラーで拒否される
- 先に接続していた側の接続が奪われ、そのまま操作が横取りされる
これは「複数セッションを並行して立てて作業する」運用（例: 複数のブランチで同時に開発を進める）と相性が悪い。ブラウザ自動操作だけが「1本しか繋がらない」制約を持つ共有リソースになっているため、他の並行作業では問題が出ないのにブラウザ操作だけで事故が起きる。
対処1: ユーザーの普段使いブラウザに任せる
見た目の最終確認のように、自動でスクリーンショットを撮る必要が無い場面では、MCP経由の自動操作を使わず、普段使いのブラウザで新規タブを開いてもらい、結果を口頭や画像で共有してもらう方法がある。接続の競合が原理的に起きないため、最も安全な回避策になる。
対処2: 確認用の別ブラウザへ一時的に切り替える
自動でスクリーンショットを取得する必要がある場合は、普段使いのブラウザとは別に、確認専用のブラウザを一時的に立てて使う。
google-chrome --headless=new --screenshot=/tmp/check.png --window-size=1280,800 "https://example.com"この方法には注意点がある。ヘッドレスブラウザはソフトウェア描画になるため、実機のGPUに依存する描画性能やフレームレートの計測には使えない。見た目のレイアウト確認や文字・要素の有無のチェックには十分だが、「滑らかに動いているか」の確認には向かない。
どちらを選ぶかの判断表
| 確認したいこと | 選ぶ方法 |
|---|---|
| レイアウト・見た目の最終確認 | 普段使いブラウザ（ユーザーに確認してもらう） |
| 定時・自動でのスクリーンショット取得 | 確認用ブラウザへ一時切替 |
| 実機GPUに依存する描画性能・フレームレート | どちらも不可。実機で直接確認する |
恒久対策: 並行運用のルールを決めておく
複数のセッション・エージェントで同じブラウザ操作MCPサーバーを共有する運用を続けるなら、「使う前に他のセッションが使っていないか確認する」ルールを決めておくと事故を防げる。使用中かどうかを示すロックファイルを1つ用意し、使う前に存在を確認してから接続する運用でも十分機能する。
# 使用前に確認
test -f /tmp/browser-mcp.lock && echo "使用中" || touch /tmp/browser-mcp.lock
# 使用後に解放
rm -f /tmp/browser-mcp.lockまとめ
ブラウザを自動操作するMCPサーバーは、同時に1接続しか受け付けない実装が多い。複数のセッション・エージェントを並行で動かしていると、この制約が「接続が切れる」「操作が反映されない」「他の作業を壊す」という分かりにくい症状として現れる。対処は、自動操作が必須でなければユーザーの普段使いブラウザに任せ、自動でのスクリーンショットが必要なら確認用の別ブラウザへ一時的に切り替える。恒久的には、使用中かどうかを示す仕組みを用意して並行運用のルールを決めておくと事故を防げる。
よくある質問（FAQ）
Q. ブラウザのプロセスを複数立てれば解決しますか？
A. ブラウザ自体のプロセスを複数起動することは可能だが、プロファイルやポートの競合が別に発生しやすく、トラブルの原因が増える。シンプルな運用では「使う前に確認する」ルールの方が事故が少ない。
Q. エラーメッセージの何を見れば競合だと分かりますか？
A. 接続が明示的に閉じられたことを示す文字列（切断・クローズを示すエラー）が出ていて、かつ再実行すると直ることがある場合は、まず他セッションとの同時利用を疑うとよい。
Q. ヘッドレスブラウザでは何が確認できませんか？
A. ソフトウェア描画になるため、実機のGPUに依存する描画性能やフレームレートは確認できない。レイアウトや要素の有無の確認には使える。
Q. 普段使いブラウザとヘッドレスブラウザ、どちらを優先すべきですか？
A. 自動化の必要が無いなら普段使いブラウザを優先する。接続の競合が原理的に起きず、最も安全なため。
