Chrome DevTools MCP 実践ガイド — AIコーディングエージェントにブラウザ操作とパフォーマンス計測を任せる

Chrome DevTools MCP は、AIコーディングエージェントに実際の Chrome ブラウザの操作・観測権限を与える Google 製の MCP サーバーです。GitHub Trending でも注目度が高く、Claude Code や Cursor から「このページの LCP を計測して」「このボタンを押してエラーが出るか確認して」と指示するだけで、エージェントが自らブラウザを動かして結果を返してくれます。本記事ではセットアップから実務での活用パターン、Playwright MCP との比較検証までまとめます。

Chrome DevTools MCP とは — 何ができるのか

Chrome DevTools MCP（chrome-devtools-mcp）は Chrome DevTools チームが公開している MCP（Model Context Protocol）サーバーです。内部的には Puppeteer と Chrome DevTools Protocol（CDP）を使い、以下のような操作を AI エージェントに提供します。

• ブラウザ自動化: クリック・フォーム入力・ドラッグ&ドロップ・ファイルアップロードなどの操作
• パフォーマンス計測: トレース記録と Core Web Vitals（LCP・CLS・INP など）の抽出
• ネットワーク・コンソール観測: リクエスト一覧の取得、ソースマップ付きのコンソールエラー確認
• メモリ解析: ヒープスナップショットの取得・比較
• エミュレーション: CPU スロットリング、ネットワーク速度、ビューポートの変更

執筆時点の最新バージョンは 1.8.0 で、Node.js ^20.19.0 / ^22.12.0 / >=23 が必要です。ライセンスは Apache-2.0 で、公式にサポートするブラウザは Google Chrome と Chrome for Testing のみとなっています。

セットアップ手順（Claude Code / Cursor / VS Code）

もっとも手軽なのは MCP サーバーとして追加する方法です。Claude Code の場合は次のコマンド一発で登録できます。

claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

スキル（プロンプトテンプレート）まで含めて導入したい場合は、プラグインマーケットプレイス経由でのインストールも用意されています。

# マーケットプレイスを追加
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp

# プラグインをインストール
/plugin install chrome-devtools-mcp@chrome-devtools-plugins

以前 MCP サーバーとして直接登録していた場合は、プラグイン版とコンフリクトしないよう先に削除しておく必要があります。Cursor や VS Code でも mcp.json に同様のエントリを追加するだけで動作します。

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

導入後は「https://developers.chrome.com のパフォーマンスを確認して」のような日本語プロンプトを投げるだけで、エージェントがブラウザを起動して計測を始めます。

主要ツール一覧 — カテゴリ別に整理

chrome-devtools-mcp は 50 前後のツールを公開しており、カテゴリごとに役割が分かれています。全部を覚える必要はなく、まずは太字のツールだけ押さえれば十分です。

入力・ナビゲーション操作

click / fill / fill_form / hover / drag / upload_file / press_key などの操作系と、navigate_page・new_page・list_pages・wait_for などのページ制御系です。フォーム入力からページ遷移まで、Puppeteer を直接書くのと同等のことをエージェントが自然文から組み立てます。

パフォーマンス計測

• performance_start_trace / performance_stop_trace: パフォーマンストレースの記録
• performance_analyze_insight: トレース結果から特定のインサイト（LCP のボトルネックなど）を深掘り

ネットワーク・デバッグ

• list_network_requests / get_network_request: リクエスト一覧と詳細
• list_console_messages / get_console_message: ソースマップ付きコンソールログ
• take_snapshot: アクセシビリティツリーに基づくテキストスナップショット（座標ではなく要素の意味でエージェントに位置を伝える仕組み）
• take_screenshot / lighthouse_audit: スクリーンショット取得、Lighthouse スコアの取得

メモリ解析

take_heapsnapshot / compare_heapsnapshots / get_heapsnapshot_retainers など、ヒープスナップショットの取得から比較・保持パスの解析まで一通り揃っています。メモリリークの原因調査を DevTools を開かずにエージェントへ依頼できます。

実務での活用パターン

1. パフォーマンス改善のトリアージ

このページのパフォーマンストレースを取得して、
LCP のボトルネックになっている要素を特定してください

エージェントは performance_start_trace → ページ操作 → performance_stop_trace → performance_analyze_insight の順にツールを呼び出し、レンダリングブロッキングリソースや画像の遅延読み込み漏れなどを具体的なファイル名付きで報告してくれます。CI に組み込む場合は lighthouse_audit を使い、スコアが閾値を下回ったら PR にコメントするフローも組めます。

2. フロントエンドのデバッグを一次情報から進める

再現条件があいまいなバグ報告に対して、「このフォームを送信してコンソールエラーを確認して」と依頼すると、fill_form → click → list_console_messages の順で実際に操作しながらソースマップ付きのスタックトレースを取得してくれます。スクリーンショットではなく take_snapshot によるアクセシビリティツリーを使うため、実装変更で DOM 構造が変わってもエージェント側の「クリック対象の特定」が壊れにくいのが利点です。

3. E2E シナリオのたたき台生成

新機能のE2Eテストを Playwright で書く前に、Chrome DevTools MCP でエージェントに手動シナリオを実行させ、そのログを元にテストコードの雛形を書いてもらう、という使い方も実務では効果的です。

// エージェントが list_network_requests / take_snapshot の結果を元に
// 生成した Playwright テストの雛形（人間がレビューして仕上げる前提）
import { test, expect } from '@playwright/test';

test('ログインフォームの送信でダッシュボードへ遷移する', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('メールアドレス').fill('user@example.com');
  await page.getByLabel('パスワード').fill('password123');
  await page.getByRole('button', { name: 'ログイン' }).click();
  await expect(page).toHaveURL('/dashboard');
});

Playwright MCP との比較検証

ブラウザ操作系 MCP のもう一つの選択肢が Microsoft の Playwright MCP です。両者は思想が異なるため、目的に応じて使い分けるのが現実的です。

観点	Chrome DevTools MCP	Playwright MCP
対応ブラウザ	Chrome / Chrome for Testing のみ	Chromium・Firefox・WebKit
内部実装	Puppeteer + Chrome DevTools Protocol	Playwright 独自のアクセシビリティ投影
強み	パフォーマンストレース・Lighthouse・メモリ解析など DevTools 由来の深い観測	クロスブラウザ対応、決定的なアクセシビリティスナップショット
ページ表現	take_snapshot（アクセシビリティツリー）+ スクリーンショット	browser_snapshot（YAML 風の独自表現、ref・iframe結合・差分対応）
向いている用途	パフォーマンス改善、メモリリーク調査、ネットワーク/コンソールデバッグ	クロスブラウザ E2E、決定的なテスト自動化

実務では「パフォーマンスやメモリなど DevTools 領域の深掘りは Chrome DevTools MCP、クロスブラウザの E2E 自動化は Playwright MCP」という棲み分けが素直です。両方を同時に MCP サーバーとして登録しておき、エージェントに用途に応じて使い分けさせる運用も可能です。

運用時の注意点

起動オプションの使い分け

# CI などで毎回まっさらな状態から起動したい場合
npx chrome-devtools-mcp@latest --headless --isolated

# 最小限のツールだけで軽量に動かしたい場合
npx chrome-devtools-mcp@latest --slim

--headless は UI なしで起動するオプション（デフォルトは false）、--isolated は一時的なユーザーデータディレクトリを作成しセッション終了時に自動削除するオプションです。CI での自動化には両方を有効にしておくと、ローカルの Chrome プロファイルを汚さずに済みます。逆にログイン状態を維持したまま操作させたい場合は --userDataDir で既存プロファイルを指定します。

セキュリティ・プライバシー面

デフォルトでは利用統計が収集されるため、社内利用では --no-usage-statistics フラグでオプトアウトしておくのが無難です。また、エージェントに実ブラウザの操作権限を渡す以上、本番環境の認証情報が入ったプロファイルをそのまま使わせないよう、--isolated や専用の DevContainer 環境で動かすことをおすすめします。自分自身も MCP 経由でエージェントに強い権限を渡す場面はまだ手探りの部分が多く、権限スコープの設計は継続的に見直しています。

まとめ

項目	ポイント
概要	AI エージェントが実際の Chrome を操作できる Google 製 MCP サーバー
セットアップ	claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest で即導入可能
主要ツール	入力・ナビゲーション / パフォーマンス / ネットワーク・デバッグ / メモリ解析の4系統
活用パターン	パフォーマンストリアージ、コンソールエラー調査、E2Eシナリオのたたき台生成
Playwright MCPとの違い	DevTools 由来の深い観測は Chrome DevTools MCP、クロスブラウザ E2E は Playwright MCP
運用注意点	CIでは --headless --isolated、権限スコープの設計は要検討