Chrome DevTools MCP とは？v0.26.0 の 42 ツールで Claude Code から実 Chrome の Lighthouse 監査を AI に任せる方法

「Claude Code や Cursor は賢いけど、結局ブラウザの中身が見えないから、CSS 崩れ・JS エラー・Lighthouse スコア低下は人間が手で確認しないとダメ……」 —— この長年の不満に対し、Google Chrome チームが 2025-09-23 に公開したChrome DevTools MCP（chrome-devtools-mcp）が、設計レベルでの解答を提示しました。

Chrome DevTools MCP は Model Context Protocol (MCP) 準拠の公式 MCP サーバで、Claude Code / Codex / Cursor / Gemini CLI / Cline といった主要 AI コーディングエージェントから、ローカルで動く実 Chrome ブラウザを直接操作できるようにします。 v0.26.0 (2026-05-12 リリース) では 10 カテゴリ・42 ツールを提供し、Lighthouse 監査・Core Web Vitals 計測・ネットワーク監視・メモリスナップショット・Chrome 拡張機能デバッグまでが AI エージェントの「直接の指先」になりました。

本記事は ChromeDevTools/chrome-devtools-mcp GitHub リポジトリ、公式 npm パッケージ、Chrome for Developers Blog、各リリースタグの CHANGELOGを一次情報として参照しています。バージョン番号・リリース日・ツール数・対応クライアント名はすべて公式表記に揃えています。

1. Chrome DevTools MCP とは — AI に「画面を見せる」公式回答

従来の AI コーディング体験には、ある決定的な弱点がありました。LLM は「コードを読んで書ける」けれど「ブラウザの中で何が起きているか」は見えない、というギャップです。CSS が崩れているか、Largest Contentful Paint が悪化したか、特定のリクエストが 404 を返しているか —— これらは人間が DevTools を開いて確認する領域でした。

Chrome DevTools MCP は、この境界線を 「AI エージェント ↔ MCP サーバ ↔ Puppeteer ↔ 実 Chrome」 という単純な 4 層構造で消しに来ました。AI 側から見ると、Chrome は「画像生成サーバや Filesystem サーバと同じ顔をした MCP サーバ」の 1 つに過ぎず、`take_screenshot` や `lighthouse_audit` といったツールを Claude Code や Cursor が呼び出すと、裏で本物の Chrome が起動・操作されます。

ここで重要なのは、Chrome DevTools MCP が独自のプロトコルではなく Anthropic 主導の Model Context Protocol (MCP) に準拠している点です。これは Claude Code、Cursor、Codex、Gemini CLI、Cline など主要 AI 開発ツールがすでに採用している共通インターフェースで、MCP の Host / Client / Server 3 層構造 の中で「Server」に相当するレイヤーになります。

2. 公式情報で確認できる v0.22 → v0.26 の機能進化

chrome-devtools-mcp は週次ペースに近い速さで更新されています。GitHub Releases を一次情報として、直近 5 リリースの差分を抽出すると次のようになります。

とくに見逃せないのが v0.24.0 の「Lighthouse 内エージェント閲覧」と v0.26.0 の --autoConnect の 2 点です。前者は Lighthouse 監査の 結果ページを AI が直接ツール経由で読み取れるようにし、後者は既存の Chrome インスタンスへ自動接続するモードを CLI 引数だけで切り替えられるようにしました。 「認証済みの自分の Chrome を AI に貸す」運用が、設定 1 行で実現できる段階に入っています。

3. アーキテクチャ — 42 ツール × 10 カテゴリと Puppeteer 連携

Chrome DevTools MCP は、Puppeteer（Google 公式のヘッドレス Chrome 操作ライブラリ）を内部で利用し、 標準的な Chrome（または canary / dev / beta）プロセスをホスト OS 上で立ち上げて操作します。AI エージェント側は MCP のツール呼び出しだけを行い、ブラウザの起動 / 終了 / ページ管理 / DOM スナップショット取得などはすべて MCP サーバ側が代理します。

カテゴリと代表的なツール名は次の通りです（公式 docs/tool-reference.md を一次情報として要約）。

4. インストール — Claude Code / Codex / Cursor / Gemini CLI 別の設定

前提として、Node.js v20.19 以上 (最新 LTS) と Chrome 安定版以降が必要です。インストールは npm にパッケージとして公開されており、各クライアントの MCP 設定ファイルに以下のような JSON を追加します。

Claude Code への登録

Claude Code では claude mcp add コマンドで MCP サーバを登録できます（Claude Code Docs: Connect Claude Code to tools via MCP を参照）。

# Claude Code に Chrome DevTools MCP を登録
claude mcp add chrome-devtools npx -- -y chrome-devtools-mcp@latest

# 既存 Chrome に接続して使う場合（v0.26.0 の --autoConnect）
claude mcp add chrome-devtools npx -- -y chrome-devtools-mcp@latest --autoConnect

# 起動確認
claude mcp list

Codex CLI への登録

Codex CLI は ~/.codex/config.toml の [mcp_servers] セクションに MCP サーバ定義を追加します。

# ~/.codex/config.toml
[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest"]

Cursor / VS Code Copilot / Cline への登録

Cursor / VS Code Copilot / Cline は MCP servers 設定 UI（または ~/.cursor/mcp.json 相当の設定ファイル）に同様の JSON を貼り付けます。

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

Gemini CLI への登録

Gemini CLI は ~/.gemini/settings.json の mcpServers フィールドに同じ構造で追加します（Gemini CLI Docs: MCP servers with Gemini CLI を参照）。

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

AI に「実ブラウザで送信前検査」を任せる Sales Claw のアーキテクチャを見る

無料・MIT ライセンス。インストールせずにライブデモも試せます。

無料でダウンロードライブデモを試すGitHub

5. 実践 7 ユースケース — Lighthouse から拡張機能デバッグまで

5-1. Lighthouse 監査の自動化

Claude Code に「https://example.com の Lighthouse スコアを取って、点数が 70 を下回っている指標について改善案を 3 つ提案して」と頼むだけで、AI が lighthouse_audit ツールを呼び出してスコアを取得し、コードまで読みに行きます。

5-2. Core Web Vitals (LCP / INP / CLS) の継続計測

performance_start_trace → ページ操作 → performance_stop_trace → performance_analyze_insight という 4 ステップで、LCP・INP・CLS を含むパフォーマンストレースを取得・分析できます。Chrome for Developers Blog が示す代表的なユースケースで、フロントエンド最適化のループに直接 AI を組み込めます。

5-3. フォーム自動入力と送信前スクリーンショット

fill_form または fill で複数フィールドを一括入力し、take_screenshot で送信前の状態を画像化。AI 営業自動化のように「フォームに何を入力 したか」を監査ログに残す用途で威力を発揮します。

5-4. ネットワークリクエストの監視

list_network_requests と get_network_request で、ページ遷移中に走った API コール・ステータスコード・ペイロードを AI に解析させられます。「Stripe の checkout セッションが 400 を返すのはなぜか」のような調査タスクが、人間が DevTools の Network パネルを見るのと等価に AI から行えます。

5-5. メモリリーク調査（ヒープスナップショット）

take_memory_snapshot でヒープスナップショットを取得し、AI に「どの Detached Node が増えているか」を分析させられます。フロントエンド SPA のメモリリーク調査は従来 DevTools の重い手作業でしたが、ここも AI に任せられる領域に入りました。

5-6. Chrome 拡張機能のデバッグ

v0.22.0 で追加された機能群を --categoryExtensionsフラグ付きで有効化すると、自作 Chrome 拡張のインストール・コンソールメッセージ取得・background スクリプトデバッグまで AI 経由でできます。拡張機能の開発生産性を大きく押し上げます。

5-7. 認証サイト連携（既存 Chrome に AI を貸す）

公式 README は「WebDriver で制御するブラウザではログインを弾く認証サービスがある」と 明記しており、これに対する公式の回避策は「既存 Chrome インスタンスへ接続する」 モードです。v0.26.0 の --autoConnectにより、自分が普段使っている Chrome を起動したまま AI から navigate_page させると、Cookie 認証済みのページに直接アクセスできます。

6. Sales Claw での実装イメージ — 送信前検査の「第 2 防御層」

Sales Claw は、ポリシー制御・送信前自動検査・営業 NG 検出・CAPTCHA 検出時停止・送信頻度制限・監査ログ保存・自動停止条件によって、誤送信と規約違反リスクを下げる設計の OSS ツールです。Chrome DevTools MCP を組み込むと、これまでの送信前検査に 「実 Chrome で人間が見る視点」に近い検査層が加わります。

3 段階防御の構成例:

1. レイヤー 1: LLM 判定 — 問い合わせフォーム文面の生成と「営業 NG」「規約違反語」の自動検出（既存）
2. レイヤー 2: 軽量 Playwright 送信 — フォーム DOM 解析と送信、CAPTCHA 検出時停止（既存）
3. レイヤー 3: Chrome DevTools MCP の送信前検査（新規） — 実 Chrome で送信直前のフォーム状態を take_screenshot で画像化、list_console_messages で JS エラーを取得、list_network_requests で送信 API のステータスを監査ログに保存

# Claude Code から Sales Claw に組み込まれた Chrome DevTools MCP を呼ぶ例
> このフォームに [生成した文面] を入力し、送信ボタンを押す前に
  take_screenshot と list_console_messages を実行して、JS エラーが
  ある場合は送信を中止し、awaiting_approval で停止してください。

この層を入れることで、「フォームの hidden field に未知の追跡パラメータが仕込まれていた」「特定の UA で送信ボタンが描画されないバグがあった」「送信先 API が 500 を返したのに UI は成功扱いになっていた」といった、Playwright だけでは取りきれない異常を 監査ログに残せる形で検知できます。ポリシー制御付き自律運用を 構造的に成立させるための、Sales Claw 流の追加防御線です。

7. ポリシー制御付き自律運用のリスクと安全設計

Chrome DevTools MCP を「ポリシー制御付き自律運用」で使う場合、以下のリスクを 自動検査と設計で下げる必要があります。「安全」を断定するのではなく、 構造的にリスクを下げるアプローチです。

7-1. 認証 Cookie が乗ったブラウザを AI が操作するリスク

• 対策: 業務用ブラウザと AI 接続用ブラウザを --isolated で完全に別プロファイルに分離。--autoConnectを本番マシンで使う場合は、メインアカウントとは別の「Sales Claw 専用 Google アカウント」を作成し、 そちらの Chrome だけを共有
• 残るリスク: AI 接続用プロファイルでログイン済みのサービスの操作権限は AI に渡る。サービスごとに「AI 操作許可」の範囲を明文化して運用

7-2. ツール実行の許可制御漏れ

• 対策: Claude Code 側の --permission-mode ask または acceptEdits を必須化。--dangerously-skip-permissions は本番運用で禁止
• 残るリスク: fill / click 系ツールは「副作用あり」とみなして必ず確認ステップを挟む設計にする

7-3. 同時セッション / リソース消費

• 対策: 1 マシンあたりの Chrome MCP プロセス数に上限を設定。 並列実行とバッチ実行は Sales Claw 側の送信頻度制限と組み合わせる (例: subagent 経由で goal に基づいた段階的バッチ処理に分割)
• 残るリスク: メモリ使用量が想定外に膨らみ得るため、 take_memory_snapshot を定期実行して監視

7-4. 週次更新による挙動差分

• 対策: 本番では chrome-devtools-mcp@0.26.0 のように特定バージョンで固定。CHANGELOG を週次で読み、検証後に上げる
• 残るリスク: Chrome 本体の自動更新で挙動が変わることがあるため、Chrome のバージョンも合わせて記録

7-5. 構造的に残るリスク

• WebDriver 検出を強化した認証サービスは引き続き弾かれる可能性（公式 README 注記）
• サイト構造変更により fill_form が誤った要素に入力する可能性
• 新規 CAPTCHA 方式の検出漏れ（Sales Claw 側で対応するまで誤送信の可能性）
• 第三者 DevTools 連携 / WebMCP は実験フラグ扱い、本番運用は推奨しない

8. 実運用前チェックリスト

9. まとめ — 「AI に実 Chrome を貸す」が当たり前になる年

Chrome DevTools MCP は、AI コーディングエージェントが長年抱えていた 「ブラウザの中身が見えない」問題を、Google 公式の MCP サーバとして正面から解決しに来た存在です。v0.22.0 (拡張機能デバッグ) → v0.24.0 (Lighthouse 内エージェント閲覧) → v0.25.0 (サードパーティ DevTools 連携) → v0.26.0 (autoConnect) と、約 1 ヶ月で AI ブラウザ自動化の「土台」が一段引き上がりました。

Sales Claw のような営業自動化システムにとっては、これは 送信前検査の第 2 防御層を MCP で標準化できるという意味で大きな進歩です。 LLM 判定 → Playwright 送信 → Chrome DevTools MCP の実 Chrome 検査、という 3 段階を「すべての AI クライアントから同じ MCP インターフェースで呼べる」状態が実現します。

次のアクション: まず chrome-devtools-mcp@latest を --isolated 付きでローカルにインストールし、お気に入りのサイトで lighthouse_audit を 1 回叩いてみることです。AI からの初回ツール呼び出しで、本記事の内容のほとんどが体感できます。Sales Claw 側の組み込みについては、クイックスタートガイドと MCP 完全ガイド を併読してください。

読んだら、まず lighthouse_audit を 1 回叩いてみる。

無料・MIT ライセンス。インストールせずにライブデモも試せます。

無料でダウンロードライブデモを試すGitHub