朝、書いたはずの記事のURLを Claude Code に聞いて、ついでに「DevToolsで開いて中身を確認したい」と頼んだ。ログイン済みプロファイルで開いてほしかったので、temp profile + 9222 の従来方式は使わずに chrome://inspect/#remote-debugging の許可フローで行く、と決めた。3月に自分でそう書いていたからだ。

何度許可ボタンを押しても、Claude Code 側は「9222は空っぽ」「mcp__chrome-devtools__* の list_pages を呼んでもユーザー拒否で止まる」のループから抜けない。1時間半ほど噛み合わないまま空回りした。原因を腰を据えて掘ったら、過去の自分の記事を読み返すところで決定打が出た。

今日の状態（観測）

数字で先に並べる。これが「今日詰まった現場の固有値」だ。

• Chrome: 149.0.7827.158（Stable、ログイン済みデフォルトプロファイル）
• chrome-devtools-mcp: v1.4.0（npx 経由、--autoConnect 単体）
• MCPサーバー: 2インスタンス常駐（chrome-devtools-mcp@latest のNodeプロセスが2本）
• localhost:9222 / 9223 / 9224 / 9225 / 9229: 全て connection refused（curl exit code 7）
• --remote-debugging-port フラグ付きの chrome.exe プロセス: 0個
• Chrome の Local State: "remote_debugging":{"user-enabled":true} ✅ 入っている
• 通常のchrome.exe プロセス: 20個以上（ログイン済みの普段使い窓が稼働中）

ユーザー側の見え方は「許可ボタンらしきものを何度も押している」。私の側の見え方は「9222は永久に空、MCPは autoConnect で起動済みだが繋ぎ先がない」。

噛み合っていない確信は、curl -s --max-time 5 http://localhost:9222/json/version の応答が常に空（接続不可）なまま動かなかったことで取れた。許可ボタンが本当に MCP のためのものなら、9222 か別ポートにエンドポイントが立ってもよさそうなのに、立たない。

chrome-devtools-mcp v1.4.0 が公式に言っていること

ここで初めて、入ってる版の --help を叩いた。

--autoConnect
  If specified, automatically connects to a browser (Chrome 144+)
  running locally from the user data directory identified by the
  channel param (default channel is stable).
  Requires the remote debugging server to be started in the Chrome
  instance via chrome://inspect/#remote-debugging.

宣言上は今日の構成と合っている。Chrome 149 は 144+ で、Local State の remote_debugging.user-enabled も true で、chrome://inspect の仕組みを呼ぶ前提だ。スペック上は噛み合うはずだ。実際は噛み合っていない。

--help には書かれていない実装の前提があるのだろう、ということだけ確定した。

過去の自分の記事と並べてみる

ここで詰まりが解けた。3本並べて初めて、自分の認識が更新されていなかったとわかった。

3月の記事は「これで動く」というトーンで書いていた。しかし、その記事には実際に動いたエビデンス（スクショ・コンソール出力・新規タブが開いた記録）が載っていない。

5月の復旧記録は対照的だ。taskkill //IM chrome.exe //F → temp profile + 9222 で起動 → curl /json/version で webSocketDebuggerUrl 入りJSONを確認 → /mcp reconnect → スクショ取得まで全部実証している。

つまり、過去に実際に動かせた経路は「temp profile + 9222」だけだった。3月の「ログイン済みプロファイル + chrome://inspect だけで autoConnect が刺さる」は、自分の理解として書いただけで、その経路で実際にスクショまで撮ったことは一度もなかった。今日「これで動くはず」と踏み込んだ前提は、自分で書いた誤情報だった。

「許可ボタンを押している」が何を指していたか

噛み合わない時間中、ユーザーは「許可ボタンを何度も押している」と言っていた。こちら側は「9222は空、MCPは autoConnect で起動済み」のままだった。

何が起きていたか、こちら側からは確定できない。仮説のレベルでメモを残す。

• chrome://inspect/#remote-debugging の中に「Open dedicated DevTools for incoming connections」のような能動ステップがあり、それを「許可ボタン」と呼んでいた可能性
• 何か別のダイアログ（拡張機能・サイト権限・自動更新の通知）を MCP の認可ダイアログだと取り違えていた可能性
• v1.4.0 の autoConnect の discovery 経路（localhost:9222 HTTP ではない別チャネル）が、Chrome 149 と噛み合う設定をユーザー側がそもそも通せていなかった可能性

どれが正解かは今日中には特定できなかった。確定したのは「chrome://inspect 経路は、こちら側に何の観測信号も出さないまま空回りした」という事実だけだ。3月の記事の「初回接続時に許可ダイアログが出る」は、私が確認した chrome-devtools-mcp v1.4.0 ＋ Chrome 149 では再現できなかった。

何が「今回」違っていたか

過去の固着事象と並べたとき、症状の表層は似ているが、詰まりのレイヤーが違う。

5月のときは「9222は開いているが死んでいた」のがゾンビ問題だった。今日は「9222が一度も開いていない」状態だ。温度の違う詰まりが、表層では似た見た目で再発した。

ナレッジ化していた .claude/issues/2026-05-26-chrome-devtools-mcp-connect.md のクイックスタートは「壊れた9222を直す」前提で書かれていた。今日の事象は「9222が無い」ので、その手順に乗っても何も直らなかった。

残る選択肢の現実

ログイン済みプロファイルにこだわるなら、現時点で実証経路がない。今日の構成（Chrome 149 + chrome-devtools-mcp v1.4.0 + autoConnect）では、私の側に観測信号が一度も来なかった。

実用上の選択肢として残ったのは、

1. temp profile + 9222 に妥協する — 5月に動いた経路。記事URLが localhost なら login 不要なので内容確認は通る。普段の Chrome 窓とは別窓になる
2. --browserUrl / --wsEndpoint に切り替える — ユーザーが ws:// URL を取り出せれば固定接続できる。~/.claude.json 編集 + Claude Code 再起動が必要
3. chrome://inspect 経路の実装を読みに行く — chrome-devtools-mcp の autoConnect 内部実装を読んで discovery 経路の前提条件を特定する。今日の時間枠では着手しなかった

今日は1で妥協する判断もせず、3まで時間を割く決断もしなかった。だから1時間半空回りした。失敗の本体はこの判断保留だ。「過去の自分の記事を信じて踏み込んだ」ことよりも、「噛み合わないと分かった時点で別経路に切り替えなかった」ことの方が重い。

学びメモ

• 過去記事の『これで動く』を、本当に実証したかどうかでもう一度ふるいにかける。実証スクショや明確な成功ログが載っていない記事は、自分の理解の宣言にすぎない可能性がある。3月の自分の記事はそれだった
• 温度の違う詰まりが、表層では同じ症状に見える。「mcp__chrome-devtools__* が空振りする」は、ゾンビポート問題でも・ポート不在問題でも・autoConnect discovery 不全問題でも、同じ顔で出る。issue ナレッジの「これだけ読めば直る」は、表層症状だけで適用してはいけない
• 観測信号が出ない経路で粘らない。9222 が空のまま動かないのを30分以上見たら、別経路（temp profile / --browserUrl）に切り替える判断をその場でする。「過去の記事に書いてあった経路だから」は、こちらが実証していない限り根拠にならない
• chrome-devtools-mcp は --help を毎回見る。v1.4.0 の --autoConnect の説明文に「Chrome 144+」「chrome://inspect/#remote-debugging」と明記してある。手元の版で何が前提なのかは、自分の記憶ではなく --help の出力で確定させる

関連記事

→ Chrome DevTools MCP の autoConnect で、自分のブラウザセッションをそのままAIに渡せるようになった (2026-03-31)

→ Chrome DevTools MCP が "still connecting" で固まる真因は『残骸9222リスナーの居座り』だった (2026-05-27)

→ ログイン済みChromeにCDPで繋ぐ手法をドキュメント化し、別系統のAIにレビューさせた (2026-05-31)