🔍 技術調査 - chrome-devtools-mcp（Chrome DevTools for agents）

検証日: 2026-05-24 / 対象バージョン: v1.0.1（2026-05-18 リリース）/ 分類: Browser Automation / QA / Coding Agent

概要

「Chrome DevTools for agents」の実体は、Google Chrome チームが公開する MCP サーバー兼 CLI chrome-devtools-mcp（GitHub: ChromeDevTools/chrome-devtools-mcp、Apache-2.0）です。

公式はこのツールの問題意識を次のように表現しています。

"Coding agents face a fundamental problem: they are not able to see what the code they generate actually does when it runs in the browser."

AI コーディングエージェントは、生成したコードがブラウザ上で実際にどう動くか見えません。この「目隠しプログラミング（coding blindfolded）」状態を解消する基盤が chrome-devtools-mcp です。エージェントが「コード修正 → ブラウザで自動検証」というフィードバックループを回せるようにします。

技術的な実体

内部アーキテクチャは 3 層で構成されます。

プロダクト情報

v1.0.0 到達後も公式は「public preview」と明記しています。方針変更の可能性に注意してください。

「AI assistance パネル（Gemini in DevTools）」との違い

混同しやすいですが別物です。

特徴

1. 45 ツール / 10 カテゴリによる包括的な観測能力

エージェントが Chrome 上で行える操作は 4 系統に整理されます。

実験的フラグで利用できる追加カテゴリとして、Memory（ヒープスナップショット）・Extensions（拡張機能デバッグ）・WebMCP があります。

2. 稼働中 Chrome への attach — 3 系統の接続方式

--autoConnect を使うと、エージェントがユーザーの認証済みセッションを引き継いで検証を実行できます。ただし公式 README も「リモートデバッグポートを開くと同一マシンの任意プロセスがブラウザを制御可能になる」と警告しています。セキュリティ上の配慮が必要です（ベストプラクティス節を参照）。

3. 複数エージェントへの対応

Antigravity 2.0 はブラウザ sub-agent としてプリバンドルされています。Claude Code・Codex・Gemini CLI は構築方法に示すコマンドで追加できます。特定エージェントに依存しない検証基盤として扱える点が特徴です。

4. 観測（debugging）の専門基盤という役割分担

公式の位置づけおよび複数の分析が一致して提示する整理軸は「Playwright MCP = 操作（driving）、chrome-devtools-mcp = 観測（debugging）」です。

"What Playwright tells you is what happened from the user's perspective. What Chrome DevTools MCP tells you is why it happened from the browser's perspective."

競合ツールとの比較

定量比較（リポジトリ規模、2026-05-23 取得）:

機能比較:

実務での推奨構成は競合ではなく補完関係です。詳細はベストプラクティス節の役割分担を参照してください。

構造

システムコンテキスト図

コンテナ図

コンポーネント図

ツールカテゴリ

接続モード

データ

概念モデル

図中の Tool からカテゴリへの矢印は代表 2 カテゴリ（InputAutomation / Debugging）のみ描画しています。実際は全 10 カテゴリが同一の ToolCategory 配下で McpServer の単一ツールレジストリに属します。

情報モデル

uid 体系の補足

take_snapshot は現在の Page の a11y ツリーを走査し、各インタラクティブ要素に uid（文字列）を付与して返します。uid は スナップショット取得時点のみ有効で、公式の操作指針は「Always use the latest snapshot」です。エージェントは uid を click / fill / hover / drag / upload_file の引数として渡します。これにより座標指定なしに要素を操作できます。座標指定の click_at は実験的フラグが別途必要です。

構築方法

前提条件

エージェント別セットアップ

Claude Code（MCP のみ）

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

Claude Code（Plugin 版 = MCP + Skills 同梱、推奨）

Claude Code のチャット画面で以下を順に実行します。

/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
/plugin install chrome-devtools-mcp@chrome-devtools-plugins

インストール後に Claude Code を再起動し、/skills でロードされていることを確認してください。すでに MCP のみ版をインストール済みの場合は、プラグイン化の前に削除してください。

Codex

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

Windows 11 環境では .codex/config.toml に以下を追記します。

[mcp_servers.chrome-devtools]
command = "cmd"
args = ["/c", "npx", "-y", "chrome-devtools-mcp@latest"]
env = { SystemRoot="C:\\Windows", PROGRAMFILES="C:\\Program Files" }
startup_timeout_ms = 20_000

Gemini CLI

# MCP のみ（プロジェクト単位）
gemini mcp add chrome-devtools npx chrome-devtools-mcp@latest

# user スコープ
gemini mcp add -s user chrome-devtools npx chrome-devtools-mcp@latest

# Extension 版（MCP + Skills 同梱）
gemini extensions install --auto-update https://github.com/ChromeDevTools/chrome-devtools-mcp

接続モード

MCP サーバーが Chrome に接続する方法は複数あります。既定はサーバーが Chrome を自前で起動します。

--wsHeaders（--ws-headers）フラグは --wsEndpoint との併用時のみ有効です。認証ヘッダを JSON で渡します。

URL 接続の Chrome 起動例（macOS）:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-profile-stable

MCP の設定例（--browserUrl を使う場合）:

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

主要フラグ一覧

テレメトリ制御:

利用方法

必須パラメータ早見表

基本作法: take_snapshot で uid を取得してから操作する

エージェントが要素を操作する際の基本フローは次の通りです。

1. take_snapshot を呼び出してページの a11y ツリーを取得する
2. スナップショット内の各要素に付与された uid を確認する
3. click / fill / hover 等に uid を渡して操作する

take_snapshot はスクリーンショットよりもトークン効率が高く、要素の uid を確実に取得できます。視覚的な確認が必要な場合を除いて優先します。

ナビゲーションと操作

navigate_page(type="url", url="https://example.com")
navigate_page(type="reload")

take_snapshot()
→ uid: "s4e2" のリンクを確認

click(uid="s4e2")
fill(uid="s4e2", value="検索ワード")

スクリーンショット取得

take_screenshot(format="png", fullPage=true)
take_screenshot(uid="s4e2")

パフォーマンストレース

ページ読み込みのパフォーマンスを計測します。LCP / INP / CLS を取得できます。

performance_start_trace(reload=true)
performance_stop_trace()
performance_analyze_insight(insightName="LCPBreakdown", insightSetId="<trace_result_id>")

performance_analyze_insight は insightName と insightSetId の両方が必須です。insightSetId はトレース結果に含まれる ID を渡します。

注: lighthouse_audit は performance カテゴリを評価しません。パフォーマンス計測はトレース系ツールを使用します。

Lighthouse 監査

lighthouse_audit(
  device="desktop",
  mode="navigation"
)

• 評価対象は accessibility / SEO / best-practices / agentic browsing の 4 観点で、performance は除外されます（カテゴリ選択パラメータはなく、ツールが上記観点を一括評価します）
• device: desktop または mobile
• mode: navigation または snapshot
• outputDirPath: 監査結果の出力先ディレクトリ

ネットワークリクエスト確認

list_network_requests(resourceTypes=["fetch", "xhr"])

resourceTypes を省略するとすべてのリクエストを返します。詳細は get_network_request で取得できます。

運用

稼働中 Chrome への attach 運用

常駐 Chrome に CDP で接続する方式は、認証済みセッションや拡張機能の状態を引き継いで検証できる点で実用的です。接続方法は 2 系統あります。

--autoConnect（Chrome 144 以降推奨）

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

Chrome 側で chrome://inspect/#remote-debugging を開いてリモートデバッグを有効化し、許可ダイアログを承認します。MCP 側はブラウザを起動せず、起動済みの Chrome に接続します。

--browserUrl（リモートデバッグポート指定）

# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-profile-dev

Chrome を専用の --user-data-dir 付きで起動し、セキュリティ上のリスクを分離します。

headful 前提のための CI 組み込みと使い分け

chrome-devtools-mcp の既定動作は headful（GUI あり）です。CI 環境でそのまま実行すると画面が存在せずブラウザ起動に失敗します。

CI に組み込む場合の構成例:

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

ただし CI への常設組み込みには不安定性（Issue #1921 / #1914、後述）が障壁になります。決定論的な回帰テストは Playwright に任せ、chrome-devtools-mcp は開発ループ内の観測専用と位置づける役割分担が現実的です。

トークン消費の管理

デフォルトスキーマは全 45 ツールのメタデータを含み、ツール発見のたびにコンテキストを消費します（Issue #340 で公式に認識済み）。対策の --slim フラグは slim 専用の navigate / evaluate / screenshot の 3 ツールに絞り、コンテキスト消費を抑えます。

# --slim: 3 ツールのみ
npx -y chrome-devtools-mcp@latest --slim --headless

複数 MCP を並列利用する構成では --slim の利用を推奨します。

ベストプラクティス

セキュリティ — リモートデバッグポートの二重リスクを理解する

誤解: --autoConnect や --browserUrl=:9222 で常駐 Chrome に接続しても、セキュリティリスクは軽微である。

反証（公式 README の自認）:

"Enabling the remote debugging port opens up a debugging port on the running browser instance. Any application on your machine can connect to this port and control the browser."

• :9222 を開いたまま常駐させると、同一マシン上の任意プロセスがブラウザ全体を制御できます。
• DOM / コンソール / ネットワーク応答は出力サニタイズなしでモデルコンテキストに渡ります。悪意あるページに埋め込まれた指示が LLM の行動空間に直結します（Web 由来 prompt injection）。
• Issue #1247（CLOSED, セキュリティ監査）でツール記述インジェクションと出力サニタイズ欠如が指摘されています。独立監査（stacklok/dockyard #407）でも critical 問題として報告されています。

推奨:

• 認証情報・Cookie を含む本番プロファイルは絶対に共有しない。
• --isolated（使い捨て user-data-dir）または専用の非認証プロファイルで運用する。
• 信頼できないサイトを MCP セッション中に開かない。

# 安全な運用例: 専用プロファイル + ヘッドレス + isolated
npx -y chrome-devtools-mcp@latest --headless --isolated

検証の役割分担 — 観測・行動・証跡の 3 レイヤ

誤解: chrome-devtools-mcp だけで CI 回帰テストまで完結できる。

反証: 複数の二次分析（Steve Kinney・test-lab.ai 等、参考リンク参照）が「chrome-devtools-mcp は observe に最適化、Playwright は act に最適化」と整理しています。WebKit を駆動できず test runner を所有しないため、クロスブラウザの決定論的回帰テストは不得手です。

推奨（役割分担）:

自己申告化の防止 — エージェントの「検証した」を鵜呑みにしない

誤解: エージェントに「完了条件にブラウザ検証を含める」と指示すれば必ず実行される。

反証: Issue #940（OPEN）で「明示指示なしでは MCP ツールを自動起動しない」ことが確認されています。エージェントが MCP ツールを呼んでも誤用により検証が失敗し、そのまま完了報告する事例も公式 eval で報告されています。

推奨:

• 完了条件にブラウザ検証ツールの呼び出しを明示的に記述する（「take_screenshot / lighthouse_audit を実行して結果ファイルを添付すること」等）。
• スクリーンショット・Lighthouse JSON・コンソールログを成果物として要求し、人間がレビューできる状態にする。
• 「検証しました」報告は証跡ファイルで裏付けるまで承認しない運用にする。

Storybook を完了条件の対象に含める

コンポーネント単位の自律監査を chrome-devtools-mcp で実現する事例として、CyberAgent の Spindle デザインシステムの取り組みが報告されています（二次情報、定量値は未確認）。Storybook を :6006 で起動し MCP 経由で各 story を Lighthouse 監査する構成は、コンポーネント数の増加に比例してスケールします。

# Storybook を起動した状態で接続する例
npx -y chrome-devtools-mcp@latest --browserUrl=http://localhost:6006

CLAUDE.md 等に既定デバッグサーバとして Storybook URL を明記し、完了条件に「各 story の Lighthouse accessibility スコアが閾値以上」を加えることで制度化できます（二次情報に基づく推奨）。

トラブルシューティング

症状 → 原因 → 対処 一覧

既知 Issue 一覧（2026-05-24 時点）

Issue 番号・状態は gh issue view <番号> --repo ChromeDevTools/chrome-devtools-mcp で再確認を推奨します。

まとめ

chrome-devtools-mcp は、AI コーディングエージェントに「生成したコードがブラウザでどう動くか」を観測させる MCP サーバー兼 CLI です。Playwright MCP（操作）と役割分担しつつ、Lighthouse 監査・Core Web Vitals 計測・ライブデバッグを開発ループ内の自己検証に組み込めます。リモートデバッグポートのセキュリティリスクと「検証したと自己申告する」問題を理解し、証跡ファイルで裏付ける運用が前提になります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 公式ドキュメント
  • Chrome DevTools for agents（Chrome for Developers 公式）
  • Chrome DevTools (MCP) for your AI agent（2025-09-23 発表ブログ）
  • Streamline your AI coding workflow with Chrome DevTools for agents 1.0（2026-05-19）
  • Get started with Chrome DevTools for agents
  • Chrome リモートデバッグ
• GitHub
  • ChromeDevTools/chrome-devtools-mcp
  • docs/tool-reference.md（v1.0.1）
  • docs/cli.md
  • microsoft/playwright-mcp
  • browser-use/browser-use
  • Issue #1247（セキュリティ監査）
  • stacklok/dockyard #407（独立セキュリティ監査）
• 記事
  • deepwiki: ChromeDevTools/chrome-devtools-mcp
  • npm: chrome-devtools-mcp
  • Steve Kinney 比較記事（二次情報）
  • test-lab.ai 比較記事（二次情報）