Chrome DevTools MCP 完全ガイド｜導入から活用テクニックまで | Rust・Go・TypeScriptの実践テックブログ

フロントエンド開発で「コンソールに出たエラーをコピーしてAIに貼り付ける」「スクリーンショットを撮って共有する」といった手作業に時間を取られていないでしょうか。AIコーディングエージェントはソースコードの読み書きには長けていますが、ブラウザ上で実際に何が起きているかを直接知る手段がありませんでした。Chrome DevTools MCPは、この課題を解消するためにGoogle Chrome DevToolsチームが公式に開発したMCPサーバーです。AIエージェントがChromeのDevTools機能へ直接アクセスし、ページの操作・検査・デバッグ・パフォーマンス分析を自律的に実行できるようになります。

2025年9月23日に一般公開プレビュー版がリリースされ、Apache-2.0ライセンスのオープンソースとしてGitHubで公開されています。

Chrome DevTools MCP が解決する開発課題

従来のAIコーディングアシスタントには根本的な制約がありました。生成したコードがブラウザ上でどう動作しているかを「見る」ことができない点です。たとえば、CSSレイアウトの崩れ、JavaScriptの実行時エラー、ネットワークリクエストの失敗といった問題は、ブラウザのDevToolsを開かなければ確認できません。

Chrome DevTools MCPを導入すると、AIエージェントが以下の作業を自動化します。

コンソールエラーの即座の検出と修正 – エラーログを自動取得し、原因特定からコード修正まで一貫して実行
パフォーマンスボトルネックの分析 – トレースを記録してLCP（Largest Contentful Paint）などのCore Web Vitals指標を計測
ネットワークリクエストの監視 – CORSエラーやAPIの失敗レスポンスを捕捉し、原因を診断
レスポンシブデザインの検証 – デバイスエミュレーションで各画面サイズでの表示を確認
リアルタイムなCSS/DOMの調査 – ライブページのスタイルとレイアウトを直接調べて修正

これにより、開発者は「DevToolsを開く → エラーをコピーする → AIに渡す → 修正案を受け取る → 再確認する」という手動ループから解放され、AIエージェントに「このページのエラーを修正して」と指示するだけで済むようになります。

Chrome DevTools MCP の全体像

MCP（Model Context Protocol）の仕組み

MCPはAnthropicが2024年11月に発表したオープンプロトコルです。AIモデルと外部ツール・データソースを標準化された方法で接続する仕組みで、JSON-RPCベースの通信（stdio / SSE / Streamable HTTP）を採用しています。

MCPのアーキテクチャはクライアント-サーバー型です。AIアシスタント（MCPクライアント）がMCPサーバーに対して「ツール」を呼び出し、その結果を受け取ります。Chrome DevTools MCPはMCPサーバー側の実装であり、Chrome DevToolsの機能を「ツール」として公開しています。

仕様の詳細はModel Context Protocol公式サイトで確認できます。

Chrome DevTools Protocol との連携構造

Chrome DevTools MCPの内部では、Chrome DevTools Protocol（CDP）を利用してブラウザと通信しています。CDPはChrome/Chromiumが提供するリモートデバッグ用のプロトコルで、DOM操作・ネットワーク監視・パフォーマンスプロファイリングなど、DevToolsの全機能にプログラムからアクセスするためのインターフェースです。

構造を整理すると次のようになります。

AIエージェント（MCPクライアント）
    ↕ MCP (JSON-RPC / stdio)
Chrome DevTools MCPサーバー（Node.js）
    ↕ CDP (WebSocket)
Chrome / Chromium / Edge ブラウザ

MCPサーバーがCDPの複雑な操作を抽象化し、AIエージェントが扱いやすい粒度のツールとして提供しています。

提供ツール一覧（カテゴリ別）

Chrome DevTools MCPは合計26のツールを6カテゴリに分類して提供しています（GitHub Tool Referenceより）。

入力操作（8ツール）

ツール名	機能
`click`	要素のクリック
`drag`	ドラッグ操作
`fill`	テキスト入力フィールドへの値入力
`fill_form`	フォーム全体への一括入力
`handle_dialog`	ダイアログ（alert/confirm/prompt）の応答
`hover`	要素へのホバー
`press_key`	キーボード入力の送信
`upload_file`	ファイルアップロード

ナビゲーション操作（6ツール）

ツール名	機能
`navigate_page`	指定URLへの遷移
`new_page`	新しいタブを開く
`close_page`	タブを閉じる
`select_page`	タブの切り替え
`list_pages`	開いているタブの一覧取得
`wait_for`	要素の出現やネットワークアイドルの待機

デバッグ（5ツール）

ツール名	機能
`evaluate_script`	JavaScriptの実行
`list_console_messages`	コンソールメッセージの一覧取得
`get_console_message`	特定のコンソールメッセージの詳細取得
`take_screenshot`	スクリーンショットの撮影
`take_snapshot`	ページのアクセシビリティツリー取得

パフォーマンス（3ツール）

ツール名	機能
`performance_start_trace`	パフォーマンストレースの記録開始
`performance_stop_trace`	トレースの記録停止と結果取得
`performance_analyze_insight`	トレース結果の分析・インサイト抽出

ネットワーク（2ツール）

ツール名	機能
`list_network_requests`	ネットワークリクエストの一覧取得
`get_network_request`	特定リクエストのヘッダー・ボディ詳細

エミュレーション（2ツール）

ツール名	機能
`emulate`	デバイスエミュレーション（画面サイズ・UA・視覚障害シミュレーションなど）
`resize_page`	ビューポートサイズの変更

各AIクライアントでの導入手順

Chrome DevTools MCPはnpmパッケージ chrome-devtools-mcp として配布されています。npx で実行するため、グローバルインストールは不要です。

Claude Code での設定

Claude Codeでは1コマンドで登録が完了します。

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

--scope user を指定すると、プロジェクト単位ではなくユーザー単位の設定として保存されます。プロジェクト固有にしたい場合は --scope project に変更してください。

設定後、Claude Codeに「web.devのLCPを計測して」のようなプロンプトを送ると、自動的にChromeが起動しパフォーマンストレースを実行します。

Cursor での設定

プロジェクトルートに .cursor/mcp.json を作成します。

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

Cursorの設定UI（Settings → MCP → Add new global MCP server）から追加することもできます。

VSCode（GitHub Copilot）での設定

.vscode/mcp.json をプロジェクトルートに配置します。

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

VSCodeのコマンドパレットからも登録可能です。

code --add-mcp '{"name":"chrome-devtools","command":"npx","args":["-y","chrome-devtools-mcp@latest"]}'

GitHub Copilot Agent ModeがMCPツールを自動的に認識し、チャットからブラウザ操作を指示できます。

OpenAI Codex CLI での設定

Codex CLIではコマンドラインから登録します。

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest

または ~/.codex/config.toml に手動で追記する方法もあります。

[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest"]

Gemini CLI / Cline / Windsurf での設定

Gemini CLI

gemini mcp add chrome-devtools npx chrome-devtools-mcp@latest

Cline / Windsurf

いずれもMCP設定ファイルに標準的なJSON構成を追記します。

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

Clineの場合はMCPサーバー設定画面、Windsurfの場合は公式のMCP設定ガイドに沿って追加します。

環境別セットアップガイド

macOS / Windows / Linux 共通の事前準備

Chrome DevTools MCPを利用するには以下が必要です。

Node.js – v20.19以降のLTSバージョン（node -v で確認）
Chrome – 現行の安定版（Stable）以降。リモートデバッグの自動接続機能を使う場合はChrome 144以降が必要
npm – Node.jsに同梱されるパッケージマネージャー

Node.jsのバージョンが古い場合は公式サイトからLTS版をインストールしてください。npx コマンドが使えることを確認すれば準備完了です。

node -v    # v20.19.0 以降であること
npx -v     # バージョンが表示されればOK

WSL2 環境での構築手順

WSL2ではLinuxとWindowsのネットワークが分離されているため、いくつかの追加設定が必要です。主に3つのアプローチがあります。

方法1: WSL内にChromeをインストールする（推奨）

WSL2のLinux環境にChrome本体をインストールし、WSLg経由でGUIを表示する方法です。

# WSL2内でChromeをインストール
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo dpkg -i google-chrome-stable_current_amd64.deb
sudo apt-get install -f

MCP設定では --executablePath と --no-sandbox 関連のChrome引数を指定します。

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y", "chrome-devtools-mcp@latest",
        "--executablePath=/usr/bin/google-chrome",
        "--chromeArg=--no-sandbox",
        "--chromeArg=--disable-setuid-sandbox",
        "--chromeArg=--disable-dev-shm-usage"
      ]
    }
  }
}

WSLgが有効なWindows 11環境であれば、このままChromeのGUIウィンドウが表示されます。環境変数 DISPLAY や WAYLAND_DISPLAY が正しく設定されていることを確認してください。

方法2: Windows側のChromeにリモート接続する

Windows側でChromeをリモートデバッグモードで起動し、WSL2からネットワーク経由で接続します。

# Windows側でChromeをリモートデバッグ付きで起動
chrome.exe --remote-debugging-port=9222 --user-data-dir="C:\tmp\chrome-debug"

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y", "chrome-devtools-mcp@latest",
        "--browserUrl=http://127.0.0.1:9222"
      ]
    }
  }
}

WSL2からlocalhostでWindows側にアクセスできない場合は、/etc/resolv.conf のネームサーバーIPを --browserUrl に指定するか、Windows側でポートフォワーディングを設定してください。

方法3: Headlessモードで起動する

GUI不要の場合はヘッドレスモードが最もシンプルです。

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y", "chrome-devtools-mcp@latest",
        "--headless",
        "--executablePath=/usr/bin/google-chrome",
        "--chromeArg=--no-sandbox"
      ]
    }
  }
}

DevContainer での活用方法

DevContainer（VS Code Remote Containers / GitHub Codespaces）では、コンテナ内にChromeの実行環境を構築します。

Dockerfileに以下を追記し、コンテナ内にChromeをインストールします。

RUN apt-get update && apt-get install -y \
    wget gnupg2 \
    && wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | gpg --dearmor -o /usr/share/keyrings/google.gpg \
    && echo "deb [arch=amd64 signed-by=/usr/share/keyrings/google.gpg] http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list \
    && apt-get update && apt-get install -y google-chrome-stable

MCP設定は WSL2のヘッドレス構成と同様に --no-sandbox と --headless を指定します。

chrome-wsl というツールを使うと、DockerコンテナとWSL2のいずれからもホスト側のChromeへプロキシ経由で接続する構成を自動化できます。

リモートデバッグモードの設定

リモートデバッグモードを使うと、既にログイン済みのブラウザセッションをそのままAIエージェントに引き継げます。認証が必要なページのデバッグに特に有効です。

Chrome 144以降の場合（自動接続）

Chromeで chrome://inspect/#remote-debugging を開く
リモートデバッグを有効化する
MCP設定に --autoConnect フラグを追加

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

接続時にChromeがダイアログで許可を求めるため、意図しないアクセスは防止されます。接続中はブラウザ上部に「Chrome is being controlled by automated testing software」というバナーが表示されます。

Chrome 143以前の場合（手動接続）

# リモートデバッグポートを指定してChromeを起動
google-chrome --remote-debugging-port=9222

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y", "chrome-devtools-mcp@latest",
        "--browserUrl=http://127.0.0.1:9222"
      ]
    }
  }
}

http://127.0.0.1:9222/json/version にアクセスすると、WebSocketのエンドポイントURLを取得できます。--wsEndpoint オプションでWebSocket URLを直接指定する方法もあります。

Edge ブラウザでの利用

Microsoft Edgeは内部的にChromiumエンジンを採用しており、Chrome DevTools Protocol（CDP）をサポートしています。そのため --executablePath オプションでEdgeの実行ファイルを指定することで、Chrome DevTools MCPから操作できます。

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y", "chrome-devtools-mcp@latest",
        "--executablePath=/usr/bin/microsoft-edge"
      ]
    }
  }
}

OSごとの代表的なEdge実行ファイルのパスは以下のとおりです。

OS	パス例
Windows	`C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe`
macOS	`/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge`
Linux	`/usr/bin/microsoft-edge`

ただし、Chrome DevTools MCPの公式サポート対象はChromeおよびChromiumです。Edgeは基本的に動作しますが、一部機能でChrome固有のAPIに依存する部分があり、すべてのツールが完全に動作する保証はありません。本番のワークフローに組み込む前に、利用予定のツールが正常に動くかをテストしてください。

実践ユースケース

コンソールエラーの自動検出と修正提案

Chrome DevTools MCPの最も実用的な活用例がランタイムエラーの自動修正です。日本のIT企業サイバーエージェントは、デザインシステム「Spindle」のStorybookコンポーネント検証にこの仕組みを導入しました。AIエージェントが全236ストーリーを約1時間で巡回し、ランタイムエラー1件と警告2件を自動的に検出・修正しています（出典: Chrome for Developers Blog）。

具体的なプロンプトの例を示します。

このページを開いて、コンソールにエラーや警告が出ていないか確認してください。
エラーがあれば原因を特定し、修正コードを提案してください。

AIエージェントは navigate_page でページを開き、list_console_messages でエラーを収集し、evaluate_script で原因を調査するという流れを自律的に実行します。

パフォーマンスボトルネックの特定

Chrome DevTools MCPのパフォーマンスツールは、Chrome DevToolsのPerformanceパネルと同等のトレースをプログラムから実行します。

web.devにアクセスして、ページロードのパフォーマンストレースを取得してください。
LCPが遅い原因を分析してください。

performance_start_trace → ページ操作 → performance_stop_trace → performance_analyze_insight の流れで、LCP・FID・CLSなどのCore Web Vitals指標とボトルネックの詳細分析を取得します。--performance-crux オプションが有効（デフォルト）であれば、Google CrUX APIから実ユーザーのフィールドデータも併せて取得し、ラボデータとの比較が可能です。

レスポンシブデザインの自動チェック

emulate ツールでさまざまなデバイスをシミュレーションし、take_screenshot で各画面サイズのスクリーンショットを撮影できます。

このページをiPhone 15、iPad、デスクトップ（1920x1080）の3パターンで
表示確認し、レイアウト崩れがないか報告してください。

視覚障害シミュレーション（色覚異常など）も emulate ツールで実行可能で、アクセシビリティ検証も自動化できます。

ネットワークリクエストの分析

list_network_requests と get_network_request を使って、APIリクエストの成功・失敗を監視します。

このページを読み込んで、失敗しているネットワークリクエストを一覧で出してください。
CORSエラーがあれば原因と対処法を教えてください。

レスポンスヘッダーの詳細やリクエストボディの内容まで取得できるため、CORS設定の不備やAPI認証エラーの原因を具体的に特定できます。

スクレイピング・データ収集への応用

Chrome DevTools MCPは evaluate_script でページ上の任意のJavaScriptを実行でき、take_snapshot でアクセシビリティツリー（ページの構造化データ）を取得できます。これらを組み合わせることで、SPAなどJavaScriptレンダリングが必要なサイトからのデータ抽出が可能です。

このECサイトの商品一覧ページから、商品名・価格・在庫状況を抽出してJSON形式で出力してください。

navigate_page で遷移し、wait_for でコンテンツの読み込みを待ち、evaluate_script でDOM操作によるデータ抽出を行う流れです。ただし、Webサイトの利用規約やrobots.txtを遵守することが前提です。

Chrome DevTools MCP と Playwright MCP の選び方

機能比較表

比較項目	Chrome DevTools MCP	Playwright MCP
開発元	Google Chrome DevToolsチーム	Microsoft
通信プロトコル	Chrome DevTools Protocol（CDP）	Playwright独自プロトコル
対応ブラウザ	Chrome / Chromium / Edge	Chrome, Firefox, Safari（WebKit）
パフォーマンス分析	トレース・CrUXデータ・詳細なメトリクス	非対応
ネットワーク監視	リクエスト一覧・詳細ボディ取得	基本的なリクエスト一覧
デバイスエミュレーション	デバイス・視覚障害・ジオロケーション	デバイスエミュレーション
スクリーンショット比較	撮影のみ	撮影 + 差分比較
コンソール操作	メッセージ取得・JS実行	JS実行
トークン効率	高効率（コンテキスト消費が少ない）	標準
ライセンス	Apache-2.0	Apache-2.0

使い分け基準

Chrome DevTools MCPが適している場面

パフォーマンスプロファイリングやCore Web Vitalsの計測が必要な場合
ネットワークリクエストの詳細なデバッグが求められる場合
既存のChromeセッション（ログイン状態）を引き継いでデバッグしたい場合
コンソールエラーの検出と修正を自動化したい場合
トークンコストを抑えたい場合

Playwright MCPが適している場面

Firefox・Safari（WebKit）を含むクロスブラウザテストが必要な場合
E2Eテストスイートの一部としてブラウザ操作を組み込む場合
スクリーンショットの差分比較によるビジュアルリグレッションテストを行う場合

併用パターン

Chrome DevTools MCPとPlaywright MCPは排他的なものではなく、同時に登録して使い分けることが可能です。たとえば、開発中のデバッグとパフォーマンス計測にはChrome DevTools MCPを使い、CI環境でのクロスブラウザE2EテストにはPlaywright MCPを使うという組み合わせが効果的です。

AIエージェントに「Chromeでパフォーマンスを計測して、次にPlaywrightでFirefoxでも同じページのスクリーンショットを取って」と指示すれば、それぞれ適切なMCPサーバーのツールが呼び出されます。

運用時の注意点と制限事項

セキュリティ上の考慮事項

Chrome DevTools MCPはブラウザの全コンテンツをAIクライアントに公開します。運用にあたって以下の点を確認してください。

機密データの露出 – ログイン中のページに含まれるセッショントークン、個人情報、社内データがAIクライアント経由で外部に送信される可能性があります。本番環境やセンシティブなデータを扱うページへの接続は慎重に判断してください
CrUX APIへのURL送信 – パフォーマンスツール使用時、デフォルトで対象ページのURLがGoogle CrUX APIに送信されます。社内URLの漏洩を防ぐには --no-performance-crux オプションを指定してください
利用統計の送信 – デフォルトで利用統計がGoogleに送信されます。無効にするには --no-usage-statistics オプションまたは環境変数 CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS=true を設定してください
--isolated モードの活用 – 一時的なプロファイルで起動し、セッション終了時に自動削除される --isolated オプションを使うと、認証情報の残存を防げます

Headless モードの制約

--headless オプションでGUI不要のヘッドレスモードが利用できます。CI/CDパイプラインやサーバー環境で便利ですが、いくつかの制約があります。

ビューポートの最大解像度は3840x2160pxに制限されます
navigate_page や take_screenshot など一部ツールの動作に制限がある場合があります
ブラウザ拡張機能は利用できません

ヘッドレスモードの設定例を示します。

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y", "chrome-devtools-mcp@latest",
        "--headless",
        "--viewport=1920x1080"
      ]
    }
  }
}

OSサンドボックス環境での対応

FlatpakやSnapなどのサンドボックスパッケージマネージャーでインストールされたChromeは、MCPサーバーからの接続に制限がかかることがあります。この場合は、公式の .deb / .rpm パッケージを直接インストールするか、--executablePath でサンドボックス外のChromeバイナリを指定してください。

また、コンテナ環境（Docker / DevContainer）ではChromeのサンドボックス機能とコンテナのセキュリティが競合するため、--chromeArg=--no-sandbox の指定が必要になる場合があります。この設定は信頼できる環境でのみ使用してください。

まとめ

Chrome DevTools MCPは、AIコーディングエージェントにChrome DevToolsの操作権限を与えるMCPサーバーです。コンソールエラーの自動検出、パフォーマンス計測、ネットワーク分析、レスポンシブ検証といったフロントエンド開発のデバッグ作業を、AIエージェントが自律的に実行できるようになります。

導入は npx chrome-devtools-mcp@latest をMCPクライアントに登録するだけで完了します。Claude Code、Cursor、VSCode（GitHub Copilot）、Codex、Gemini CLIなど主要なAIクライアントに対応しています。WSL2やDevContainer環境でも --executablePath や --headless オプションで構築可能です。

現時点では一般公開プレビュー版のため、今後のアップデートで機能追加や安定性の向上が見込まれます。フィードバックはGitHubリポジトリのIssueから送信できます。

Playwright MCPとの併用で、Chrome DevTools MCPによるパフォーマンスデバッグとPlaywright MCPによるクロスブラウザテストを両立できます。開発効率を高めたいフロントエンドエンジニアにとって、有力な選択肢です。

Chrome DevTools MCP が解決する開発課題#

Chrome DevTools MCP の全体像#

MCP（Model Context Protocol）の仕組み#

Chrome DevTools Protocol との連携構造#

提供ツール一覧（カテゴリ別）#

各AIクライアントでの導入手順#

Claude Code での設定#

Cursor での設定#

VSCode（GitHub Copilot）での設定#

OpenAI Codex CLI での設定#

Gemini CLI / Cline / Windsurf での設定#

環境別セットアップガイド#

macOS / Windows / Linux 共通の事前準備#

WSL2 環境での構築手順#

DevContainer での活用方法#

リモートデバッグモードの設定#

Edge ブラウザでの利用#

実践ユースケース#

コンソールエラーの自動検出と修正提案#

パフォーマンスボトルネックの特定#

レスポンシブデザインの自動チェック#

ネットワークリクエストの分析#

スクレイピング・データ収集への応用#

Chrome DevTools MCP と Playwright MCP の選び方#

機能比較表#

使い分け基準#

併用パターン#

運用時の注意点と制限事項#

セキュリティ上の考慮事項#

Headless モードの制約#

OSサンドボックス環境での対応#

まとめ#