GitHub Trendingで38,600スターに達したプロジェクトがある——ChromeDevTools公式のchrome-devtools-mcpだ。v0.25.0が3日前にリリースされ、829回のコミット、77のオープンイシュー、29のPRがキューに入っている。これはコミュニティのおもちゃではない。Chromeチーム自身がメンテナンスしているインフラだ。
何が解決されるのか
Claude Code、Cursor、その他のコーディングエージェントでフロントエンドを書いたことがある人なら、共通の悩みを知っているだろう。エージェントはコードを書けるが、デバッグは基本的に当て推量だ。CSSレイアウトのバグを直すようお願いすると、3バージョン出してくるがどれもちょっとズレている。なぜなら、ブラウザが実際にレンダリングしているものを見られないからだ。
これまでの解決策は大きく2つだった。一つはエージェントにPlaywrightでスクリーンショットを撮らせ、ビジョンモデルにページを「見て」もらう方法。遅くて情報密度も低い。もう一つは人間がDevToolsを開いて、ネットワークリクエスト、コンソールエラー、DOM構造を一つずつエージェントに貼り付ける方法。面倒で、見落としも起きやすい。
chrome-devtools-mcpは第三の道を進む。MCPプロトコル経由でエージェントがChrome DevToolsに直接接続する——ブラウザでF12を押すのと同じことだ。ただし今回はDevToolsを操作するのがエージェントというだけ。
具体的に何ができるか
リポジトリの構造から見ると、このMCPが公開している機能はDevToolsのコアパネルをカバーしている：
- DOM操作と検査——エージェントがDOMツリーを直接クエリ・変更可能。もうCSSセレクターの当て推量は不要
- コンソールの読み書き——JavaScriptの実行、コンソール出力の読み取り、エラーのキャッチ
- ネットワークリクエスト分析——XHR/fetchリクエストの完全なチェーンをヘッダー、ボディ、タイミング込みで検査
- パフォーマンスパネル——パフォーマンスデータへのアクセス
- フォームフィル——複雑なフォーム用の専用
fill_formスキル（チェックボックスのエッジケース修正は2日前にマージされたばかり）
さらに重要なのは、.claude-pluginディレクトリが含まれていることだ。つまりClaude Codeが追加設定なしでプラグインとして直接ロードできる。
なぜ今このタイミングが重要なのか
MCPプロトコル自体は以前から存在していたが、これまでの実装の多くはAPIラッパーだった。天気クエリ、データベース操作、ファイル検索など。このレベルのブラウザDevToolsエンドポイントは別次元だ。理由は：
- すべてのフロントエンド開発の共通インターフェースであること。どのフレームワークやビルドツールを使っていようが、最終的にはすべてブラウザ上で動く
- Chrome公式の裏打ちが安定性を意味すること。個人開発者がメンテナンスするサードパーティスクリプトではなく、Chromiumプロジェクトの一部だ
- 829回のコミットはこれが実験的プロジェクトではないことを示している。v0.25.0が3日前にリリースされ、CLI自動接続、フォームフィル評価などの修正が含まれている。イテレーションのペースは健全だ。
まだ完璧ではない部分
77のオープンイシューからは、実際の使用における摩擦点が見えてくる：接続の安定性、特定のDevTools APIのカバレッジ不足、複数タブシナリオでの挙動の一貫性の欠如など。0.xバージョンのプロジェクトとしては正常だが、CI/CDで自動化テストに使う場合は、もう数回の安定版リリースを待った方がいいだろう。
また、これは主にコーディングエージェントシナリオ向けに設計されている。単なるブラウザ自動化が目的なら、Playwrightエコシステムの方がはるかに成熟している。
結論
フロントエンドコードを書いていて、コーディングエージェントを開発補助に使っているなら、このプロジェクトは試す価値がある。設定は簡単（npx @chrome/devtools-mcpで起動）で、「エージェントがブラウザを見られない」という実際の問題を解決している。
ただし、人間のデバッグを完全に置き換えると期待してはいけない。複雑なインタラクション、アニメーションのタイミング、クロスブラウザの互換性——これらのシナリオでは、人間の目の方がまだエージェントより信頼できる。
主な情報源：