- Chrome DevTools MCP サーバーが、コーディングエージェントがアクティブなブラウザーセッションに直接接続できるよう改善
- この機能により、エージェントはログイン済みセッションを再利用したり、DevTools のアクティブなデバッグセッションにアクセスしたりできる
- Chrome M144（ベータ）で**
--autoConnect オプション**を使用すると、MCP サーバーが実行中の Chrome インスタンスに自動接続
- 接続のたびにユーザー承認ダイアログが表示され、デバッグ中は「自動化されたテストソフトウェアによって制御中」のバナーが表示される
- 手動デバッグと AI 支援デバッグを自由に切り替えられるため、開発効率が向上
Chrome DevTools MCP サーバー改善の概要
- Chrome DevTools MCP サーバーが、コーディングエージェントがアクティブなブラウザーセッションに直接接続できるようアップデート
- ユーザーはログイン済みセッションを再利用できるため、追加のログインなしでデバッグ可能
- DevTools UI のNetwork パネルやElements パネルで選択した項目を、エージェントに調査させるよう依頼可能
- 従来の接続方式も維持され、MCP サーバー専用プロファイルの使用、リモートデバッグポート接続、一時プロファイルベースの複数インスタンス実行が可能
動作の仕組み (How it works)
- Chrome M144（現在ベータ）にリモートデバッグ接続要求機能が追加
- MCP サーバーが
--autoConnect オプション付きで実行されると、アクティブな Chrome インスタンスに自動接続し、リモートデバッグセッションを要求
- セキュリティ強化のため、Chrome はリクエストのたびにユーザー承認ダイアログを表示し、承認後にのみ接続を許可
- デバッグセッションが有効になると、ブラウザー上部に**“Chrome is being controlled by automated test software”** バナーが表示
はじめに (Get started)
- 新しいリモートデバッグ機能を使うには、Chrome でリモートデバッグを有効にし、MCP サーバーを設定する必要がある
Step 1: Chrome でリモートデバッグを設定
chrome://inspect/#remote-debugging に移動してリモートデバッグを有効化- ダイアログでデバッグ接続を許可するかどうかを選択
Step 2: MCP サーバーの自動接続を設定
chrome-devtools-mcp サーバー実行時に --autoConnect 引数を追加- 設定例（gemini-cli）:
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": [
"chrome-devtools-mcp@latest",
"--autoConnect",
"--channel=beta"
]
}
}
}
- Chrome M144 が安定チャネルに到達するまでは
--channel=beta の指定が必要
Step 3: 設定をテスト
コーディングエージェントとの統合デバッグ
- アクティブな Chrome インスタンスへの接続により、自動化と手動操作を並行できる
- ユーザーが DevTools で問題のある要素を見つけたあと、その要素をコーディングエージェントに渡して修正を依頼可能
- Network パネルでも同様にリクエストを選択し、エージェントに分析を指示可能
- Chrome DevTools MCP サーバーを通じて、追加パネルのデータアクセス機能を段階的に拡大していく予定
1件のコメント
Hacker Newsの意見
私は Playwright を使ってすべてのリクエストとレスポンスを横取りし、Claude Code が YouTube のようなウェブサイトを巡回しながらクリックや入力を行う間、関連トラフィックを記録している
こうして収集したデータをもとに 強い型付けのAPI を自動生成し、どんなウェブサイトでも内部API経由でやり取りできるようにしている
もちろん利用規約違反の可能性はあるが、広告や画像、マークアップをすべて読み込まなくていいのが利点だ
興味のある人がいれば今週公開する予定
実際、これは Anthropic や OpenAI のような LLM メーカーがすでにやってきたやり方だ
彼らが広告を回避したり著作物をダウンロードしたりするときは「神の贈り物」と呼ばれ、Zuck が同じことをすると「悪魔の呪い」と呼ばれるのは皮肉だ
主に DOM ツリーの特定箇所でページのレイアウトやスタイルを再現したり、レスポンシブ動作を自動でキャプチャしたりする用途だ
Playwright で画面幅を調整しながらスタイル変化を追跡し、スクリーンショットとスタイル階層データ を一緒に保存している
手動の検査ツールもあるが、遅すぎて非効率だ
個人的には MCP より カスタムCLI を自作するほうがずっと効率的だと思う
AI が直接アクセスし、「スキル」を通じて活用するのが本当に強力だ
Claude なら agent-browser さえあれば決定論的なコードをその場で生成できそうだ
DevTools MCP プロジェクト は最近スタンドアロン CLI をリリースした
chrome-devtools-cli のドキュメントを見ると v0.20.0 に含まれている
MCP の トークンコスト問題 を意識していた人には朗報だ
（参考までに、私は DevTools チームで以前働いていて、今も働いている）
私はここ数か月 TideWave を使っている
tidewave.ai はもともと Elixir/LiveView ベースだったが、いまは JS フレームワークと RoR もサポートしている
このツールは単なるブラウザだけでなく、アプリの ランタイムアクセス まで可能だ
つまり、エージェントがデータベースやエンドポイントに直接アクセスできるので非常に強力だ
Google は agentic CLI コーディングではかなり出遅れている
Gemini CLI はひどすぎて、社内ですら使われていないのは明らかだ
MCP はすでに死んだ技術 だと思う。CLI ツールのほうが速く柔軟で、すでに学習済みの環境も多い
本気の開発者なら Playwright と headless Chromium を使うのが定石だ
MCP は初心者にしか魅力がない
CLI だけではセキュリティと運用の複雑さが大きすぎる
ただし Gemini CLI がひどいという点には同意する
Anthropic が改善を試みたが コンテキスト膨張 の問題は依然として残っている
MCP サーバーは使わなくてもコンテキストを消費する
これからは agent skill に移行すべきだ
コード検索、ドキュメントアクセス、バグ参照、RAG データベース接続などに MCP サービスを使っている
（Google 社内の人たちから直接聞いた話だ）
MCP がコンテキストを消費するなら、CLI スキルは無料なのかも疑問だ
すでにこの機能を実装した エージェントスキル がある
chrome-cdp-skill を毎日使っているが、本当に素晴らしい
たとえば codex でローカルの音楽ライブラリを管理しつつ YT Music タブを開き、アルバムを検索して URL を yt-dlp に渡せた
ただし現状では Chrome 専用なので、ほかのブラウザを使うにはバイナリパスを修正する必要がある
ブラウザ自動化 + エージェント分野はすでに競争が激しい
DevTools MCP と新 CLI は Chrome DevTools & Puppeteer チームが保守しているので、より安定していそうだ
それでも オープンソースの競争 がイノベーションを生むのは良いことだ
むしろ playwriter.dev のような安定したツールを使うほうがよいと思う
私は WebSocket プロキシ + Chrome 拡張 を作って、エージェントが DOM を制御できるようにしている
browserbox を通じてセッション Cookie を許可した状態でアクセスできるよう構成している
現在は エージェントのツール利用成功率 を高めるための研究用ミドルウェアとして活用している
この MCP はかなり長く使ってきたが、codex on opencode と一緒に使うときが最も安定していた
とくに SVG 編集 REPL として使ったとき、見事なカスタムアイコンを自動生成してくれて驚いた
Electron アプリ でもリバースエンジニアリングや拡張作業に向いている
playwriter を使ってみたが、既存セッションに接続する方式が驚くほどうまく動いた
私も似たものを Playwright で実装した
以前はトークン消費が激しくコストが高かったが、結果をディスクに保存してエージェントに問い合わせさせる ラッパー を作って解決した
uisnap.dev で確認できる
このプロジェクトが トークン消費問題 を解決したのか気になる
playwright-slim-mcp で確認できる
firefox-devtools-mcp を使ってみたが、標準の Chrome MCP よりはるかに速く効率的だった