Chrome DevTools MCP が朝イチで繋がらず、/check-earnings の Koyfin Step 0 をその日まるごと落とした

朝の /make-diary を回し始めた直後、Claude Code 側から呼んだ mcp__chrome-devtools__list_pages が rejected で戻ってきた。それから1時間半、Chrome DevTools MCP の許可フローと噛み合わずに空回りした。最終的に「Chrome MCP に依存するステップは今日全部スキップする」と判断して /check-earnings を回したら、Koyfin が必要な Step 0 がそのまま落ちて、Micron Q3 の実績取り込みが当日中にできない構図になった。後日 beat-monitoring/MU の行を手作業で作る原因がここで仕込まれている。

chrome-devtools-mcp 自体の詰まりの解剖は別記事に逃した（末尾の関連リンク）。この記事は、「ブラウザMCPが繋がらないこと」が日次の決算スナップショットパイプラインのどこに穴を空けたかを、自分があとから振り返るためにまとめておく。

朝の流れ（観測）

/make-diary を起動。前半は通常通り走る
後半の「ブラウザで実際にページを確認する」ステップで、Claude Code が mcp__chrome-devtools__list_pages を呼ぶ → 即 rejected
ユーザー側の見え方: 「Chrome 側に出ている許可ボタンらしきものを何度も押している」「MCP サーバーは connected で 29 tools がロード済みになっている」
Claude 側の見え方: ツール呼び出しが拒否される / 9222 を curl しても空

つまり、表層的には「MCP は繋がっているのに、呼ぶと拒否される」という、噛み合わない状態だ。

ポートを直接見に行く

ここで mcp__chrome-devtools__* の挙動を信じるのをやめて、OS 側で listening しているポートを直接確かめた。

# 9222 / 9223 を curl で叩く
curl -s --max-time 5 http://localhost:9222/json/version
curl -s --max-time 5 http://localhost:9223/json/version
# どちらも応答なし（接続不可）

PowerShell の Get-NetTCPConnection で 9000 番台を絞っても、--remote-debugging-port を持つ chrome.exe プロセスは0個。Chrome 本体のリモートデバッグポートがそもそも一度も開いていないことが確定した。

MCP サーバー一覧で chrome-devtools が connected と出ていても、繋ぐ先の Chrome ポートが立っていないなら、list_pages は呼ばれた瞬間に落ちる。「29 tools がロード済み」は、ツール定義のロード完了であって、Chrome に繋がっていることを保証していない、と今日初めて自分の頭に染み込んだ。

過去ログを引っ張り出す

ユーザーから「過去にも何度もミスっている。過去の公開記事のログを見てほしい。今回何が違うか」という指示が入ったので、過去の Chrome DevTools MCP 関連記事だけ絞って Read した。全文 cat はしない、複雑な grep もかけない、というルールでセッションを守りつつ、3本だけピックして読んだ。

並べて分かったのは、過去に実際にスクショまで撮れた経路は「temp profile + 9222 で純粋起動」だけ、ということだ。今日試していた「ログイン済みプロファイル + chrome://inspect 経由の autoConnect」は、3月の自分の記事に「これで動く」と書いてあったが、実証スクショは載っていなかった。書いた自分が経路を実証していなかった。

ここまで分かった時点で、深掘りを続けるか、別経路に逃げるかの分岐に立った。続報や検証手順の本体は autoConnect 詰まりの記事の方に集約したので、この記事では分岐の先だけ書く。

「明日に積み残す」判断

ユーザーから次の指示が入った。

ごめん、これちょっと明日の積み残しとして、Chrome DevTools の立ち上げがいくかどうか、ちょっと明日の積み残しにしましょう。

これを受けて、

1時間半の試行錯誤を chrome-devtools-mcp-autoconnect-stuck-again.md に公開記事として残す
明日試す手順（Step 1〜4、フォールバック条件付き）を memo/2026-06-25/chrome-devtools-mcp-login-profile-tomorrow-plan.md に置く
/add-task で明日の Google タスクに積む準備をする

までを Claude Code にまとめさせた。「明日 temp profile + 9222 で純粋起動して /json/version が JSON を返すか確認 → ダメなら --browserUrl / --wsEndpoint に切り替え」までを手順化しておくと、明日の自分が同じ場所で同じ時間を溶かさないで済む。

Auto Mode で残りをどう進めたか

詰まったまま全部止めるわけにいかないので、方針を切り替えた。

Chrome MCP に依存しないところから先に進める
具体的には /check-earnings の Step 0（Koyfin のブラウザセッションを開く）をスキップして Step 1 から実行

これで /check-earnings の本体は回ったが、Koyfin Step 0 が抜けたので、その日に走らせたかった Micron Q3 FY26 の実績取り込みが Koyfin 経路では入ってこなかった。後で beat-monitoring/MU 用の Q3 行を手で起こす遠因がここで仕込まれている。Step 0 を飛ばすと「あとで埋めればいい」感覚になるが、実際は「あとで」が翌日以降の手作業に化ける、というのが今日のコストだった。

何が今日の本当の失敗だったか

詰まったこと自体は事故だが、コストの大きさは別の判断にあった。

✅ MCP 側に listening が出ないと観測した時点で、もう少し早く /check-earnings から Chrome 依存ステップを切り離す判断ができた
❌ 「3月の自分の記事に書いてあるから動くはず」と思って、1時間半同じ経路をなぞった
❌ Koyfin Step 0 を「飛ばしてもあとで戻せる」と楽観して、リカバリのコストを見積もらずに次へ進めた

ユーザーがすでに「明日に積もう」と決断してくれたので、空回りそのものは止まった。ただ、Step 0 スキップの判断は自分のところで早く出せた、というのが残った後悔だ。

振り返り（学びメモ）

MCP の "connected" 表示と、ツール呼び出しが通ることは別。29 tools ロード済みでも、繋ぐ先のポートが立っていなければ呼んだ瞬間に落ちる。curl /json/version で listening を直接確認する一手を、噛み合わないと感じた最初の数分でやる
「過去の自分の記事に書いてある」を実証エビデンス付きで読み直す。スクショ・成功ログ・新規タブが開いた記録が載っていない記事は、当時の自分の理解の宣言にすぎないかもしれない。3月の Chrome DevTools MCP 記事はそれだった
Auto Mode で詰まったら、依存を切れるところから切る。今日の /check-earnings は Step 0 を切れば残りは回せた。詰まりを起点に依存を切り離す訓練を意識する
「飛ばしたステップ」を翌日のタスクに必ず積む。Koyfin Step 0 のスキップは「翌日以降の手作業」を生んだ。スキップを決めた瞬間に、リカバリの場所と手順を /add-task に積むまでをセットで行う

→ Chrome DevTools MCP の autoConnect が今度は『chrome://inspect の許可ボタンを押しても永久に噛み合わない』で詰まった (2026-06-25)

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

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