Chrome DevTools MCP徹底入門 — AIコーディングエージェントに「目」と「実ブラウザ」を与える

AIエージェントに「実ブラウザの目」を持たせる

AIコーディングエージェントはコードを書くのは得意ですが、書いたコードが実際のブラウザでどう動くかを知らない ——これが長らく「生成したUIコードが微妙にズレる」「パフォーマンス劣化を提案できない」 といった弱点の根本原因でした。

Chrome DevTools MCPは、この空白を埋めるためにGoogleのChromeチームが公開したMCPサーバーです。 Claude Code・Gemini CLI・Cursor・Copilotなどのエージェントから、 実際に立ち上がったChromeを操作し、DevToolsそのものの機能 （トレース、Lighthouse、コンソール、ネットワーク、スクリーンショット等）をツールとして呼び出せるようになります。

なぜPuppeteer/Playwright MCPだけでは足りないのか

ブラウザ操作系のMCPとしては既にPuppeteer/Playwrightベースのものが存在します。 では何が違うのか。ざっくり整理すると次のようになります。

つまりChrome DevTools MCPの本質は「ブラウザを操作できる」ことではなく、 DevToolsという最強のWeb検証ツールをAIのコンテキストへ構造化して流し込める点にあります。 パフォーマンス最適化・Core Web Vitals調査・実環境再現型のデバッグに特に効きます。

全体アーキテクチャ

graph LR
    subgraph "AI Agent"
        A["Claude Code / Cursor / Gemini"]
    end
    subgraph "MCP Layer"
        B["chrome-devtools-mcp<br/>(29 tools)"]
    end
    subgraph "Browser Automation"
        C["Puppeteer"]
    end
    subgraph "Chrome"
        D["DevTools Protocol (CDP)"]
        E["Trace / Console / Network"]
        F["Lighthouse / Insights"]
    end
    A -- "tool calls" --> B
    B -- "drives" --> C
    C -- "CDP" --> D
    D --> E
    D --> F
    F -- "structured results" --> B
    B -- "tool results" --> A

内部的にはPuppeteerでChromeを起動し、Chrome DevTools Protocol（CDP）経由でDevTools機能を呼び出しています。 つまりHeadless/Headedどちらでも動き、ローカルに既に起動しているChromeへのアタッチも可能です。 開発中のdevサーバー（例: npm run dev）に対して、 エージェントが直接アクセスして検証できる——というのが体験として大きい違いです。

29ツールの全体像

ツールは6ドメインに整理されます。全体像を把握しておくと、プロンプトで「どの能力を使わせたいか」を明示しやすくなります。

Claude Codeへのセットアップ

導入は極めて軽量で、npx経由で起動できます。

.mcp.json（プロジェクトルート）:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

プロジェクトルートに配置すると、Claude Codeは起動時にMCPサーバーを自動的にspawnし、 29ツールをすべて利用可能な状態にします。認証は不要です（ローカルのChromeを立ち上げるだけ）。

実践ワークフロー①：パフォーマンス回帰の特定

典型的な使い方は「devサーバーの特定ページが遅い気がする」というシーンです。 エージェントに対して次のようにタスクを渡します。

Claude Codeへの指示例:

http://localhost:3000/articles/xxx のLCPとTBTを計測して、
上位3つのパフォーマンス問題をDevToolsのInsightsから抽出し、
該当するReactコンポーネントを特定してください。

この時エージェントが内部で実行する流れは概ね次のようになります。

sequenceDiagram
    participant U as User
    participant A as Claude Code
    participant M as chrome-devtools-mcp
    participant C as Chrome
    U->>A: "このページを計測して"
    A->>M: navigate_page(url)
    M->>C: load & render
    A->>M: performance_start_trace()
    A->>M: navigate_page(reload)
    A->>M: performance_stop_trace()
    M-->>A: trace summary
    A->>M: performance_analyze_insight("LCP")
    M-->>A: {lcp: 3.1s, culprit: "hero-image"}
    A->>U: 原因候補と修正提案

重要なのは、エージェントが数値を自分で測った上で修正提案を返すことです。 「たぶん画像最適化が効きそう」というそれっぽい助言ではなく、 「LCPが3.1秒で、原因はhero-imageの遅延読み込み（DevTools Insights実測）」 という事実ベースの会話ができます。

実践ワークフロー②：コンソールエラーからの原因特定

「ページを開くと何か落ちているけど、再現手順が面倒」というよくあるケース。 list_console_messagesとevaluate_scriptの組み合わせで、 エージェント自身に調査させられます。

Claude Codeへの指示例:

localhost:3000 のトップページを開いてコンソールを確認し、
エラーが出ているならsource mapを辿って該当ファイル:行を特定してから修正案を出してください。

Chrome DevTools MCPのコンソールツールはsource map対応のスタックトレースを返します。 つまりバンドル後のファイル名ではなく、元のTypeScriptのどの行で落ちたかがそのままエージェントのコンテキストに入ります。 「エラーメッセージをコピペして貼る」という手動ステップが丸ごと消えるのが地味ですが大きい価値です。

実践ワークフロー③：Core Web VitalsのCI監査

PRごとに「パフォーマンスが劣化していないか」を自動検証する使い方も実用段階です。 lighthouse_auditとperformance_analyze_insightを PRのプレビューデプロイURLに対して走らせ、結果をPRコメントとして投稿する——という流れが成立します。

ハマりどころと回避策

• ローカルのChromeを占拠する: ユーザーが使っているChromeプロファイルにアタッチすると副作用が出ます。専用プロファイル（--user-data-dir）を指定しましょう。
• ツール呼び出しが多くなりトークン消費が激しい: navigate_page→wait_for→take_snapshot…と1タスクで10回以上のtool callが走ることがあります。タスクを小分けに切る・スクショ戻り値のサイズを制限する等で対処。
• devサーバーのHMRでトレースが汚れる: 開発時の計測はHMR関連のLong Taskが混ざります。正確な計測はビルド成果物（npm run preview）に対して行うのが鉄則です。
• ネットワーク条件の固定忘れ: emulateで回線・CPUスロットリングを指定しないと、環境依存で評価がブレます。「Fast 4G + 4x CPU slowdown」のような基準を決めておくと会話が安定します。

まとめ

Chrome DevTools MCPは、AIコーディングエージェントに「実ブラウザの目」を与えるための最小にして強力な拡張です。 書く能力と測る能力が同じエージェントに揃ったことで、 パフォーマンスやUI崩れのような実行しないと分からない問題に対しても 根拠ある会話ができるようになります。

まずは.mcp.jsonに1ブロック追加し、 「このページのLCPを測って」とClaude Codeに投げるところから始めてみるのがおすすめです。 DevToolsでやっていた往復作業がエージェント側に吸収されていく感覚が、使ってみると一番腑に落ちます。