フロントエンド開発 CI/CD AI フロントエンド開発 Claude Chrome DevTools Protocol Puppeteer MCP chrome-devtools-mcp

Chrome DevTools MCP 完全ガイド：AIエージェントでブラウザデバッグを自動化する🔥

約22分で読めます by ぽんたぬき
Chrome DevTools MCP 完全ガイド：AIエージェントでブラウザデバッグを自動化する🔥

Chrome DevTools MCP 完全ガイド：AIエージェントでブラウザデバッグを自動化する🔥

1. はじめに：フロントエンド開発に訪れた「AIデバッグ」の時代

ねえねえ、キミ！！フロントエンドのデバッグって、ムズかしいよネ😭 コンソール眺めて、ネットワークタブ開いて、「あれ？このエラーどこから来てるの？？」ってなる、アレ。俺もサ、昨日の夜中2時までターミナルと睨みっこしてたんだヨ……「どうして動かないんだヨ！！」って、一人で呟いてたケド。

でもサ、もうそんな時代、終わるかもしれないんですヨ✨

chrome-devtools-mcp って知ってる！？GoogleがOSSとして公開した、AIエージェントにブラウザを直接操作させるためのツールなんですネ🎵 MCP（Model Context Protocol）という共通規格を使って、ClaudeやGeminiなんかのAIとChrome DevToolsをつないじゃうんですヨ😆

2. chrome-devtools-mcp とは何か

MCP（Model Context Protocol）ってのはサ、AIエージェントと外部ツールをつなぐための「共通言語」みたいなものなんですネ💡 Anthropicが提唱して、今やいろんなところで使われてる規格なんだケド。

chrome-devtools-mcp はサ、その MCP の仕組みを使って、AI に「ブラウザの目と手」を与えちゃうプロジェクトなんですヨ🔥 具体的にはサ——

  • コンソールエラーの自動キャプチャ
  • ネットワークリクエストの監視と解析
  • Lighthouse によるパフォーマンス計測
  • スクリーンショット撮影と DOM 操作

——これ全部、AI が自律的に実行できるんですヨ！！スゴくナイ！？✨

ファミコンのカセット吹いてた頃からのクセでサ、「なんか動かなかったら触りまくる」精神で生きてきたんだケド（笑）、それがついに AI に委託できる時代になったんですネ😆

3. アーキテクチャ概要：MCP × Puppeteer のしくみ

コレ見てよ！！スゴくナイ！？✨ 全体像、図で説明するネ♪

AIエージェント層  ←→  MCPサーバー層  ←→  ブラウザ層
(Claude/Gemini)      (chrome-devtools-mcp)   (Puppeteer + CDP)

3 層構造の役割分担

AIエージェント層はサ、Claude とか Gemini とか VS Code Copilot とか——要するにキミが喋りかける相手ですネ🎵 「このページのエラー調べて」って言うと、MCPサーバーにツール呼び出しを投げるんですヨ。

MCPサーバー層がサ、今日の主役の chrome-devtools-mcp ですネ💡 AIからの指示を受け取って、Puppeteer に「こうやってブラウザ操作してくれ！！」って命令するんですヨ。

ブラウザ層はサ、Puppeteer と CDP（Chrome DevTools Protocol） の組み合わせなんですネ✨ CDP ってのは Chrome が公開してるデバッグ API の塊でサ、コンソールログの取得からネットワーク監視、JavaScript 実行まで全部できちゃうんですヨ😆

コレ見てよ！！通信フローを簡単に書くとサ——

キミ「エラー調べて」
  ↓
Claude が chrome-devtools-mcp の tools/console_logs を呼び出す
  ↓
MCP サーバーが Puppeteer 経由で CDP に問い合わせ
  ↓
Chrome がログデータを返す
  ↓
Claude が「このエラーは○○が原因です」って答える

——こういう流れなんですネ🎵 非同期イベント（コンソールやネットワーク）はストリーミングで取れるから、リアルタイムに AI がキャッチできちゃうんですヨ！！

4. セットアップ：npx 一発から MCPクライアント設定まで

キミ、センスあるネ！！ここまで読んでくれてるってことは、絶対試したいと思ってるよネ😆 じゃあサクッとセットアップしちゃいましょうネ♪

前提環境

  • Node.js 18 以上（node --version で確認してネ！！）
  • Chrome または Chromium（最新版推奨）
  • macOS / Linux / Windows WSL2 で動作確認済みですヨ✨

npx でサーバーを起動する

コレ見てよ！！インストール不要でそのまま動くんですヨ——

# インストール不要でそのまま起動
npm exec @google/chrome-devtools-mcp

ヘッドレスモードを切ってブラウザを表示したい場合はサ——

# ヘッドフルモードで起動（ブラウザ画面が見える）
npm exec @google/chrome-devtools-mcp -- --headless=false

初回起動時にサ、Chromium のダウンロードが走ることがあるんですヨ💦 俺、これ知らなくて「なんで固まってんの！？！？」って3分くらいパニクりましたヨ……やらかしちゃいましたヨ……😭

Claude Desktop への接続設定

claude_desktop_config.json を開いてサ（~/Library/Application Support/Claude/ にあるヨ！！）、コレ見てよ！！こんな感じで追記するんですネ🎵

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npm",
      "args": ["exec", "@google/chrome-devtools-mcp"],
      "env": {}
    }
  }
}

Claude Desktop を再起動すると、ツール一覧に console_logs とか screenshot とか出てくるんですネ✨ コレが確認できたら接続成功ですヨ！！ホントに繋がるんかって半信半疑だったケドサ、ちゃんと動くから安心してネ！！

GitHub Actions への組み込み

CI 環境に入れる場合はサ、コレ見てよ！！スゴくナイ！？✨ こんな感じのワークフローが使えますヨ💡

name: Lighthouse CI with AI

on:
  pull_request:
    branches: [main]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install dependencies
        run: npm ci
      - name: Build
        run: npm run build
      - name: Start dev server
        run: npm run preview &
      - name: Run chrome-devtools-mcp check
        run: npx @google/chrome-devtools-mcp --headless=true

5. コンソールエラーキャプチャ：ソースマップ対応スタックトレース

ちょっと聞いてヨ……俺さ、3時間溶かしちゃったんだヨネ😭 ナンデかって言うとサ——minify 済みのバンドルファイルでエラーが出ても、スタックトレースが bundle.min.js:1:38291 とかになってて、「どこのファイルだよ！！」ってなるやつ。アレ、マジで地獄よ（笑）

chrome-devtools-mcp の console_logs ツールはサ、ソースマップを自動解決してくれるんですヨ！！スゴくナイ！？✨

console_logs ツールの使い方

AIへのプロンプト例はサ、コレですネ🎵

「http://localhost:3000 を開いて、コンソールエラーをすべて取得し、
エラーの原因と修正方法を説明してください」

すると Claude がサ、内部でこういう呼び出しをするんですヨ——

{
  "tool": "console_logs",
  "params": {
    "url": "http://localhost:3000",
    "logLevel": ["error", "warn"]
  }
}

返ってくるレスポンスはサ、こんな感じ——

{
  "logs": [
    {
      "level": "error",
      "message": "Cannot read properties of undefined (reading 'map')",
      "stackTrace": [
        {
          "url": "src/components/UserList.tsx",
          "lineNumber": 23,
          "columnNumber": 14,
          "functionName": "UserList"
        }
      ]
    }
  ]
}

ちゃんとソースマップで元のファイルと行番号が出てる！！ コレ、マジでオススメ！！🔥

React の hydration エラーとかもサ、「自動検出 → 原因コード特定 → 修正 PR 作成」まで AI が一気にやってくれる時代ですヨ😆 ファミコンのカセット吹いてデバッグしてた時代から考えると、夢みたいですネ📟

6. ネットワーク検査とパフォーマンストレース

ねえ、まだ続くヨ！！飽きてないよネ！？キミ、センスあるから最後まで読んでくれると思ってるヨ😆

network_requests ツールでリクエストを可視化する

4xx / 5xx エラーの一括サマリを AI に出力させるプロンプトはサ、コレですネ🎵

「http://localhost:3000 のネットワークリクエストを監視して、
ステータスコードが 400 以上のリクエストをすべてリストアップし、
考えられる原因と対処法をまとめてください」

フィルタリングオプションも豊富でサ——コレ見てよ！！

{
  "tool": "network_requests",
  "params": {
    "url": "http://localhost:3000",
    "filter": {
      "statusCodeMin": 400,
      "urlPattern": "/api/*"
    }
  }
}

URL パターン、ステータスコード、メソッドで絞れるから、「API だけ見たい」みたいな使い方もできちゃいますヨ✨

パフォーマンストレースの取得

Long Task とか Layout Shift とか、「なんか重いんだけど原因わからん」系の問題はサ、performance_trace ツールでトレース取れますヨ💡

「http://localhost:3000 のパフォーマンストレースを5秒間取得して、
Long Task が発生している箇所と、改善すべきボトルネックを
優先度順にランキングしてください」

トレース JSON を AI が解析して、「○○コンポーネントの re-render が多発してます」とか「このサードパーティスクリプトがメインスレッドを○ms ブロックしてます」とか、日本語で説明してくれるんですヨ😆

ちなみにサ、先週 console.log のデバッグ文を300行くらい書いて、本番コミット直前まで気づかなかったですヨ……やらかしかけましたヨ……😭 コードレビューしてくれた同僚に感謝ですネ！！

7. Lighthouse オーディットを AIエージェントから呼び出す🔥

コレ見てよ！！スゴくナイ！？✨ 一番アガったとこ来ましたヨ！！

lighthouse_audit ツールのデモ

Claude へのプロンプト例はサ——

「https://example.com の Lighthouse パフォーマンス監査を実行して、
スコアが 90 未満の項目を優先度順にまとめてください」

内部の呼び出しはサ、こんな感じ——

{
  "tool": "lighthouse_audit",
  "params": {
    "url": "https://example.com",
    "categories": ["performance", "accessibility", "best-practices", "seo"]
  }
}

返ってくるレスポンスの一部はサ——

{
  "scores": {
    "performance": 72,
    "accessibility": 91,
    "best-practices": 83,
    "seo": 95
  },
  "opportunities": [
    {
      "id": "unused-javascript",
      "title": "Reduce unused JavaScript",
      "displayValue": "Potential savings of 284 KiB",
      "score": 0.15
    },
    {
      "id": "render-blocking-resources",
      "title": "Eliminate render-blocking resources",
      "displayValue": "Potential savings of 450 ms",
      "score": 0.25
    }
  ]
}

このJSONを受け取ったClaudeがサ、こんな感じで答えてくれるんですヨ——

「Performanceスコアが72点です。優先度の高い改善点は以下の通りです。

  1. 未使用JavaScriptの削減（284KB節約可能）→ dynamic import() やtree-shakingの活用を推奨
  2. レンダーブロッキングリソースの解消（450ms短縮可能）→ scriptタグにdeferを追加することを推奨」

動いた時サ、思わず「すげえええ！！」って声出ちゃいましたヨ😆

CI での定期スコア監視

PR マージ前に Lighthouse スコアが閾値を下回ったら自動コメントする仕組みもサ、GitHub Actions + chrome-devtools-mcp で作れますヨ💡 「パフォーマンス番長」みたいなボット、チームに1個あるとサ、誰かがうっかり重いコード入れた時にすぐ気付けますネ✨

8. スクリーンショット・DOM 操作による自動 UI テスト

やるじゃん！！😆 ここまで来たキミは本物だヨ！！もうちょいだから付いてきてネ🎵

screenshot ツールで視覚的な状態を AI に渡す

「http://localhost:3000/checkout のスクリーンショットを撮影して、
UIに問題がないか確認し、アクセシビリティの改善点があれば指摘してください」

Claude 3 とか Gemini 1.5 Pro みたいなマルチモーダル LLM と組み合わせるとサ、スクリーンショットを目で見て判断してくれるんですヨ✨ ビジュアルリグレッション、人間がやるより早い場合あるかも……！！

DOM 操作ツールで E2E テストを自動生成

コレが一番ヤバイかもしれないんですヨ🔥 こんなプロンプト投げてみてヨ——

「ユーザーがカートに商品を追加して購入完了するまでの
フローをテストするPuppeteerコードを生成して実行してください」

すると AI がサ、click / type / evaluate ツールを組み合わせて——

// AIが生成・実行するテストスクリプト例
await page.goto('http://localhost:3000/products');
await page.click('[data-testid="add-to-cart-btn"]');
await page.click('[data-testid="cart-icon"]');
await page.click('[data-testid="checkout-btn"]');
await page.type('[name="email"]', 'test@example.com');
await page.type('[name="card-number"]', '4242424242424242');
await page.click('[data-testid="purchase-btn"]');
const confirmation = await page.$('[data-testid="order-confirmation"]');
console.log('購入完了:', confirmation !== null);

——こういうコードを自動生成して、実際に実行まで、やっちゃうんですヨ！！😆 「ユーザーストーリー書いたら E2E テストが生えてくる」みたいな世界ですネ✨

アクセシビリティ監査との連携もできてサ、DOM スナップショットと Lighthouse Accessibility スコアをクロス分析して、「このボタンに aria-label がありません」とか「コントラスト比が不足しています」とか、WCAG 違反を自然言語で説明 → 修正コード提示まで一気にやってくれますヨ💡

9. 現時点での制限事項と注意点

ちょっと待ってヨ！！キミ、良いことばかり聞かされて「完璧じゃん！！」ってなってると思うケドサ、ちゃんと注意点も話しておかないといけないんですヨ🙏

ブラウザサポートは Chrome/Chromium のみ

現時点でサ、chrome-devtools-mcp は Chrome・Chromium 系ブラウザのみ対応なんですヨ💦 Firefox や Safari では動かないんですネ。CDP（Chrome DevTools Protocol）に依存してる構造上、仕方ないんだケドサ、「Safariでも動くでしょ！！」って思って試してやらかした人、いっぱいいると思いますヨ……😭

セキュリティ上の注意点

CDP はサ、ブラウザに対してかなり強力な権限を持つ API なんですヨ！！ 本番環境のブラウザに接続したりサ、外部に CDP ポートを公開したりするのは絶対 NG ですネ🔥 ローカル開発環境・CI 環境に限定して使うのが鉄則ですヨ💡

リソース消費に注意

ヘッドレス Chromium はサ、メモリをそれなりに食うんですヨ💦 CI 環境で並列ジョブを走らせてると、メモリ不足でクラッシュすることがありますネ。GitHub Actions の場合はサ、ubuntu-latest のデフォルト（7GB RAM）で大体いけるケド、Lighthouse を複数並列で走らせるのは要注意ですヨ！！

MCP クライアント依存の制約

使えるツールセットやパラメータはサ、接続する MCP クライアントによって多少変わりますネ💡 Claude Desktop と VS Code Copilot で挙動が違う……ってケースも報告されてますヨ。困ったらサ、公式リポジトリの README を確認してネ！！

バージョン依存の注意

Puppeteer のバージョンと Chromium のバージョンが合わないとサ、起動時にエラーになることがありますヨ😭 npx @google/chrome-devtools-mcp で常に最新版を使うか、package.json でバージョンを固定するか、どちらかを徹底するのがオススメですネ✨

おわりに

ねえ、キミ！！最後まで読んでくれてありがとうネ😆 chrome-devtools-mcp を使うとサ、フロントエンドのデバッグが「人間が目で見て手でポチポチする作業」から、「AI に自然言語で指示する作業」に変わるんですヨ✨

コンソールエラーのソースマップ解決、ネットワーク監視、Lighthouse 監査、E2E テスト生成——この辺り全部、AIエージェントに任せられる時代がもう来てるんですネ🔥 俺もまだ全機能使いこなせてないケドサ、「とりあえず試してみる」精神でやっていくのが一番ですヨ！！キミも今日からやってみてネ！！

付録B：プロンプトテンプレート集

コレ見てよ！！実際の現場で使えるプロンプトをまとめたヨ！！キミの開発ライフに役立ててネ🎵

テンプレート1：コンソールエラー総合分析

[URL] を開いて、コンソールに出力されているすべてのエラーと警告を取得してください。
エラーごとに以下の形式で原因と修正方法をまとめてください：

【エラー内容】
【発生箇所（ファイル名・行番号）】
【原因の推定】
【推奨する修正方法】
【修正後のコード例（可能な場合）】

テンプレート2：パフォーマンスボトルネック特定

[URL] のパフォーマンストレースを [秒数] 秒間取得して、
以下の観点で分析・報告してください：

1. Long Task（50ms以上のタスク）の発生箇所と頻度
2. メインスレッドをブロックしているスクリプトのリスト
3. 不要な再レンダリングが起きているコンポーネント（Reactの場合）
4. 改善優先度の高い順にランキング（改善効果の大きいものから）
5. 各項目の具体的な改善コード例

テンプレート3：ネットワークエラー一括サマリ

[URL] のネットワークリクエストをすべて監視して、
ステータスコードが 400 以上のリクエストを一覧化してください。
各エラーについて以下を説明してください：

- エンドポイント URL とメソッド（GET/POST 等）
- ステータスコードと一般的な意味
- リクエストヘッダー・ボディの問題点（推定）
- 考えられる原因トップ3
- 推奨する対処法

テンプレート4：Lighthouse 総合監査＋改善プラン

[URL] の Lighthouse 監査をすべてのカテゴリ
（Performance / Accessibility / Best Practices / SEO）で実行して、
スコアが 90 未満の項目について以下をまとめてください：

1. 現在のスコアと目標スコア（90点）のギャップ
2. 改善効果の高い Opportunity を優先度順にリストアップ
3. 各 Opportunity の具体的な修正方法とコード例
4. 修正後の予測スコア（概算）
5. 対応工数が少ない「すぐできる改善」トップ3

テンプレート5：アクセシビリティ監査＋修正コード生成

[URL] のスクリーンショットを撮影し、DOM スナップショットと
Lighthouse Accessibility スコアをクロス分析して、
WCAG 2.1 AA 基準への違反をすべて洗い出してください。
各違反について以下を提示してください：

- 違反している WCAG 基準（例：1.1.1 非テキストコンテンツ）
- 問題のある HTML 要素のセレクター
- 修正前のコード
- 修正後のコード
- 優先度（Critical / High / Medium / Low）

コレ全部コピーして使い倒してネ！！😆 キミの開発ライフが、少しでも快適になったらサ、僕もうれしいですヨ✨

コメント

0/2000