Chrome DevTools MCPとは、Claude CodeなどのAIコーディングエージェントにChromeブラウザの計測・操作能力を与えるGoogle公式のMCPサーバーです。npx経由のコマンド1行で登録でき、パフォーマンストレースの記録・ネットワークリクエストの解析・コンソールの読み取りをAIに任せられるようになります。
AIコーディングには「生成したコードが実際にブラウザでどう動くかを、AI自身が確認できない」という弱点がありました。コンソールエラーもレイアウト崩れも、人間がDevToolsを開いて貼り付けて伝える必要があった——このギャップを公式に埋めるのがChrome DevTools MCPです。
この記事では、Chrome公式ブログ・公式GitHubリポジトリ・web.devを中心とする一次情報（いずれも2026年7月確認）を根拠に、接続手順から「LCP改善をAIに任せる」「バグ調査をAIに任せる」実践パターン、稼働中ブラウザへの接続、セキュリティ上の注意までを整理します。
Chrome DevTools MCPとは
Chrome for Developers公式ブログ（2025年9月23日）で「public preview」として発表されました。コーディングエージェントが生成したコードを、実際のブラウザ上で検証できるようにするのが狙いです。2026年7月時点でもpublic preview表記のまま更新が続いており（npmでv1.6.0まで継続リリース）、「正式版」と宣言されたわけではない点は押さえておきましょう。
実体は公式リポジトリChromeDevTools/chrome-devtools-mcp（Apache-2.0ライセンス）で公開されているOSSで、内部ではPuppeteerがライブのChromeを自動操作します。MCPそのものの仕組み（サーバーの種類・scope・設定の実体）は、Claude CodeのMCP・Hooks・Skills活用ガイドで解説しています。
連携でできること
ツールは約50個（バージョンにより増減）あり、入力自動化・ナビゲーション・エミュレーション・パフォーマンス・ネットワーク・デバッグなどのカテゴリに分かれています。実務でよく使うのは次の表のツール群です。
| ツール名 | できること |
|---|---|
| performance_start_trace / performance_stop_trace | パフォーマンストレースの記録開始・停止 |
| performance_analyze_insight | 記録したトレースからボトルネックを分析 |
| list_network_requests / get_network_request | ネットワークリクエスト一覧・個別詳細の取得 |
| list_console_messages | コンソールメッセージ（エラー・警告）の読み取り |
| take_screenshot / take_snapshot | 画面のスクリーンショット・DOMスナップショット取得 |
| navigate_page / click / fill_form | ページ遷移・クリック・フォーム入力の自動操作 |
| evaluate_script | ページ上でJavaScriptを実行 |
| lighthouse_audit | Lighthouse監査の実行 |
公式ブログが挙げる想定ユースケースは「変更がブラウザで正しく動くかの検証」「画像が読み込まれない原因の調査」「フォーム送信が失敗するバグのデバッグ」「Make it load faster（表示速度の改善）」の4つ。つまり、実装後の検証・デバッグ・高速化という、これまで人間がDevToolsで担っていた作業がそのまま対象です。
事前準備
公式READMEの動作要件は次の2つだけです。APIキーもアカウント登録も不要です。
- Node.js（最新LTS）
- Chrome（現行stable以降）
サーバー本体はnpx経由で毎回最新版が起動されるため、個別のインストール作業はありません。
接続手順：コマンド1行で完了
公式READMEに記載されたClaude Code向けの登録コマンドは次の1行です。通常のターミナル（Claude Codeセッションの外）で実行します。
claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest–scope user を付けているので全プロジェクトで使えます。FigmaやNotionのMCPと違いOAuth認証はなく、登録すればそのまま使えます。Claude Codeを起動して /mcp でchrome-devtoolsが接続済みになっていれば準備完了です。動作確認には、次のような簡単な指示が向いています。
https://example.com を開いて、コンソールにエラーが出ていないか確認して。
エラーがあれば原因の当たりも付けて報告して。Chromeが自動で立ち上がり、Claude Codeがページを開いてlist_console_messagesで実測した結果を返してくれれば接続成功です。
実践①：パフォーマンス計測とLCP改善
Chrome DevTools MCPの本領はパフォーマンス改善です。判定基準として、web.dev公式ガイド（2025年9月更新）によると、Largest Contentful Paint（LCP）は75パーセンタイルで2.5秒以下が「良好」です。この計測と改善のループをAIに回してもらいます。
http://localhost:3000 のパフォーマンストレースを記録して、
LCPを悪化させている要因を特定してください。
- performance_start_trace → 読み込み → performance_stop_trace の順で計測
- performance_analyze_insight でボトルネックを分析
- 原因がこのリポジトリのコードにあれば修正案を提示（まだ書き換えない）
- 修正後に再計測して、改善幅を数値で報告することポイントは最後の1行です。「修正→再計測→数値で報告」まで指示すると、感覚ではなく実測ベースの改善ループになります。画像の遅延読み込み・レンダーブロッキングCSS・巨大なヒーロー画像といった定番のLCP要因は、この流れでかなりの精度で特定されます。
実践②：バグ調査とデバッグ
「画像が表示されない」「フォームが送信できない」といったバグ調査もそのまま任せられます。Claude Codeはlist_network_requestsで失敗したリクエストを見つけ、list_console_messagesでエラーを読み、take_screenshotで見た目を確認し、必要ならevaluate_scriptでページ内の状態を直接調べます。人間がDevToolsの3つのパネルを行き来していた調査を、AIが一続きでやる形です。
たとえば「一覧ページのサムネイルが表示されない」という報告を受けた場合、調査は次のような流れになります。
- take_screenshotで症状を視覚的に確認する（どの画像が欠けているか）
- list_network_requestsで失敗したリクエストを絞り込み、get_network_requestでステータスとURLを特定する
- 特定したURLをもとに、リポジトリ側のコードを検索してパスの組み立てミスや環境変数の不足を突き止める
- 修正後にnavigate_pageで再読み込みし、同じリクエストが成功に変わったことを確認して完了報告する
「症状の確認→原因の実測→コード修正→再実測」の全工程がブラウザ実測ベースで進むのがポイントです。コードだけを見て推測で直すよりも、手戻りが目に見えて減ります。
ただし、AIに任せる場合も「DevToolsで何が見えるか」を人間側が知っているほど、指示と検収の精度が上がります。手動でのDevTools検証手順はChrome DevTools検証ガイドにまとめているので、本記事のAI自動化とセットで押さえるのがおすすめです。
発展：稼働中のChromeセッションに接続する
基本形は「MCPサーバーが新しいChromeを起動する」動作ですが、Chrome公式ブログ（2025年12月11日）では、–autoConnectオプションで普段使っている稼働中のChromeセッションに接続し、DevTools UIで選択中の要素やリクエストをそのままAIに調査させる機能が案内されています。
ただしこの機能はChrome M144以上が条件です（公式ブログ・2025年12月11日）。現行のChrome stableはこの要件をすでに満たしているため（2026年7月時点の実測）、Chromeを最新stableに更新していれば追加のチャンネル設定は不要です。導入初期は基本形（自動起動）で運用し、実セッション接続は運用に慣れてからの発展オプションと考えるのが安全です。
セキュリティ上の注意
公式READMEのDisclaimerは、このサーバーが「ブラウザの内容をMCPクライアントに露出し、データの閲覧・デバッグ・改変を許す」こと、そして「MCPクライアントに渡したくない機密情報や個人情報を扱わせないこと」を明記しています。実務では次の線引きを推奨します。
- 調査対象は開発中のlocalhost・検証環境を基本にする
- ログイン済みの個人アカウント（ネットバンキング・SNS等）を開いたセッションには接続しない
- 実セッション接続（–autoConnect）を使うときは、開いているタブの内容がAIから見える前提で扱う
- フォーム自動入力に本物の個人情報を渡さない（テストデータを使う）
よくあるつまずきと対処法
導入時につまずきやすいポイントを症状別にまとめます。いずれも公式の動作要件・仕様に紐づくものです。
| 症状 | 原因と対処 |
|---|---|
| /mcp にchrome-devtoolsが出てこない | 登録コマンドをClaude Codeセッション内で実行している、または再起動していない。通常のターミナルで実行し、Claude Codeを再起動する |
| サーバー起動時にNode関連のエラーが出る | Node.jsが古い。公式要件は最新LTS。バージョンを更新して再実行する |
| Chromeが起動しない・見つからない | Chromeが未インストールか古い。公式要件は現行stable以降。更新して再実行する |
| 稼働中のChromeに接続できない | 実セッション接続（–autoConnect）はChrome M144以上が条件。Chromeを最新stableに更新して再試行するか、基本形（自動起動）で運用する |
| ページは開くが操作対象を見つけられない | クリック等の操作系はtake_snapshotでDOM構造を取得してから要素を指定させると安定する。「まずスナップショットを取って」と指示に含める |
Chrome DevTools MCPに関するFAQ
Q. Chrome DevTools MCPは無料で使えますか？
無料です。Apache-2.0ライセンスのOSSとして公式リポジトリで公開されており、APIキーや課金は不要です。必要なのはNode.js（最新LTS）とChrome（現行stable以降）だけです。
Q. 対応しているのはClaude Codeだけですか？
いいえ。MCP対応クライアント共通の仕組みで、公式READMEにはClaude Codeのほか各種MCPクライアント向けの設定例（npx経由のstdio型）が掲載されています。本記事のコマンドを各ツールのMCP設定に読み替えれば同様に使えます。
Q. 普段使いのChromeのタブを直接調査させられますか？
可能です。–autoConnectによる稼働中セッションへの接続はChrome M144以上が条件で、現行のstable版はこの要件を満たしています。まずは「MCPが起動する専用Chrome」での運用から始め、慣れてから実セッション接続に進むのが安全です。
Q. 本番サイトの計測にも使えますか？
公開ページの計測自体は可能です。ただし公式が明記する通りブラウザの内容はMCPクライアントに露出するため、ログインが必要なページや機密情報を含む画面は避け、開発・検証環境を基本にするのが推奨です。
Q. 手動のDevTools操作はもう覚えなくてよいですか？
覚えておく価値はむしろ上がります。AIへの指示（何をどのパネル相当のツールで測らせるか）と、返ってきた結果の検収は、DevToolsで何が見えるかを知っている人ほど正確にできます。手動検証とAI自動化は代替ではなく相補の関係です。
まとめ
Chrome DevTools MCPは、AIコーディングの弱点だった「ブラウザでの実測」をGoogle公式の仕組みで埋めるツールです。要点をまとめます。
- 接続は claude mcp add chrome-devtools –scope user npx chrome-devtools-mcp@latest の1行。認証不要
- 約50ツールでパフォーマンス計測・ネットワーク解析・コンソール読み取り・ページ操作をカバー
- LCP改善は「計測→分析→修正→再計測を数値で報告」までワンセットで指示する
- 実セッション接続（–autoConnect）はM144が条件の発展オプション
- ブラウザ内容はAIに露出する。機密情報を扱うセッションには繋がない
まずは自分の開発中サイトで「コンソールエラーを確認して」から始めて、パフォーマンス改善ループまで広げてみてください。
関連記事もあわせてどうぞ。