Chrome DevTools MCPの話題を追っていて、いちばん大きい変化は「AIがブラウザを操作できるようになった」ことではなく、AIがブラウザ上の事実をDevTools経由で確認できるようになったことだと感じています。

参考にした記事では、Chrome DevTools MCPを「普段使っているChromeをAIに操作させるためのインタフェース」と捉え、SaaS上の操作や売上取得のような実例に踏み込んでいました。

この記事ではそこから一歩ずらして、開発チームで使う前提の実務QA・調査・レビュー運用に落とします。

結論

Chrome DevTools MCPは、AIエージェントに「ブラウザを触らせるツール」として導入すると危険です。

最初に狙うべき使い方は、次の3つです。

用途	任せること	任せないこと
UI確認	DOM、スクリーンショット、表示崩れの確認	本番データ更新
障害調査	Console、Network、HTTPステータス、JSエラー確認	自動復旧や設定変更
性能調査	Trace、LCP/CLS/TBTの原因仮説	数字だけでの自動リリース判断

つまり、最初の導入ゴールはこうです。

AIにブラウザ操作を任せる
  ではなく
AIにブラウザ上の事実確認を任せる

この順番で始めると、SeleniumやPlaywrightの代替ではなく、人間のレビュー前にブラウザ証跡を集めるQA補助レイヤーとして使えます。

背景

Chrome DevTools MCPは、MCPクライアントからChrome DevToolsの機能へアクセスするためのMCPサーバーです。

公式READMEでは、AIコーディングアシスタントがライブChromeを制御・検査でき、ブラウザ自動化、デバッグ、パフォーマンス分析に使えると説明されています。Chrome for Developersの公式記事でも、コード変更のリアルタイム検証、Network/Consoleエラー診断、ユーザー操作のシミュレーション、スタイルやレイアウトの確認、パフォーマンス監査が用途として挙げられています。

ここで重要なのは、従来のブラウザ自動化と役割が少し違うことです。

観点	Playwright / Puppeteer	Chrome DevTools MCP
主目的	テストコードとして再現可能にする	AIがその場で調査・操作する
入力	スクリプト	自然言語 + MCP tool
得意	CIでの回帰テスト	調査、原因特定、レビュー補助
苦手	事前に書いていない調査	権限境界が曖昧な運用

だから、Chrome DevTools MCPは「テストコードが不要になるもの」ではありません。

テストコードを書く前後の調査、レビュー、再現確認を速くするものとして見る方が実務では安定します。

実装・運用テンプレート

ここからは、チーム導入時にそのまま使えるテンプレートです。

1. まずは専用Chromeプロファイルで起動する

普段使いのChromeには、ログイン済みSaaS、管理画面、社内ツール、個人アカウントが入っています。

Chrome DevTools MCPはブラウザの中身をAIクライアントへ見せるため、最初から普段使いのChromeへ接続するのは避けた方が安全です。

検証用プロファイルを分けます。

mkdir -p ~/.chrome-mcp-profiles/devtools-mcp-work

npx chrome-devtools-mcp@latest \
  --user-data-dir="$HOME/.chrome-mcp-profiles/devtools-mcp-work" \
  --viewport=1440x900 \
  --no-usage-statistics

パフォーマンス調査でCrUX連携を使わない方針なら、次も付けます。

npx chrome-devtools-mcp@latest \
  --user-data-dir="$HOME/.chrome-mcp-profiles/devtools-mcp-work" \
  --viewport=1440x900 \
  --no-usage-statistics \
  --no-performance-crux

最低限のブラウザ操作だけでよい場合は、slimモードから始めるのも現実的です。

npx chrome-devtools-mcp@latest --slim --headless

2. Codex / Claude Code向けMCP設定

MCPクライアントの設定例です。

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--user-data-dir=/Users/YOUR_NAME/.chrome-mcp-profiles/devtools-mcp-work",
        "--viewport=1440x900",
        "--no-usage-statistics"
      ]
    }
  }
}

チーム共有のAGENTS.mdやCLAUDE.mdには、ブラウザ操作の境界も書きます。

# Browser QA rules

AI agent may use Chrome DevTools MCP for:
- checking DOM state
- collecting screenshots
- checking console errors
- checking failed network requests
- recording performance traces on local or staging URLs

AI agent must not:
- change production data
- submit forms that send email, payment, or external notifications
- access personal browser profiles
- store cookies, tokens, or screenshots containing secrets in the repository
- treat visual inspection as a replacement for automated tests

Allowed environments:
- localhost
- staging
- preview deployments

Human approval is required before:
- logging into production admin
- downloading customer data
- submitting a destructive action

3. PRレビュー用プロンプト

PRレビューでは、AIに「画面を見て」と投げるだけだと結果が散ります。

次のテンプレートを使います。

You are doing browser QA for this pull request.

Target URL:
- http://localhost:3000

Changed area:
- /settings/billing

Use Chrome DevTools MCP to check:
- page loads without console errors
- no failed network requests related to this page
- main CTA is visible and clickable
- layout does not overflow at 375px and 1440px widths
- changed copy appears exactly as expected

Do not:
- submit payment forms
- change production data
- log into personal accounts
- make code changes unless explicitly asked

Return:
1. Checked URLs
2. Console errors
3. Failed network requests
4. Visual/layout concerns
5. Screenshots or trace names if captured
6. Manual review points

4. 調査結果の出力フォーマット

AIの調査結果は、PRコメントへそのまま貼れる粒度にします。

## Browser QA Report

| item | result | evidence |
|---|---|---|
| URL | pass | `http://localhost:3000/settings/billing` |
| Console | pass | no error-level logs |
| Network | warn | `/api/billing/plans` returned 304; expected |
| Mobile layout | fail | CTA overlaps footer at 375px |
| Desktop layout | pass | 1440px screenshot checked |
| Performance | not checked | outside scope |

## Findings

- [P1] Mobile CTA overlaps the footer at 375px.

## Human review needed

- Confirm whether the 304 response is expected in staging.
- Confirm billing copy with product owner.

「見ました」ではなく、何を、どのURLで、どの証跡で見たかを書かせるのがポイントです。

5. 実務チェックリスト

導入初日に使うチェックリストです。

# Chrome DevTools MCP導入チェックリスト

## 環境

- [ ] 専用Chromeプロファイルを作った
- [ ] 普段使いChromeには接続していない
- [ ] localhost / staging / previewだけを対象にした
- [ ] production adminは対象外にした

## 権限

- [ ] フォーム送信を禁止した
- [ ] ダウンロード対象を明示した
- [ ] 個人情報・顧客情報をスクリーンショットに残さない
- [ ] MCPクライアントのログ保存先を確認した

## QA観点

- [ ] DOM上の対象要素を確認する
- [ ] Console errorを見る
- [ ] Network failed requestを見る
- [ ] 主要viewportで表示を見る
- [ ] 必要な場合だけPerformance traceを見る

## レポート

- [ ] URLを書いた
- [ ] 実行した操作を書いた
- [ ] エラーの有無を書いた
- [ ] 人間が判断すべき点を書いた

6. n8nや定期実行に入れる場合の境界

Chrome DevTools MCPをn8nや日次ジョブに組み込む場合、いきなり本番SaaSの操作自動化へ寄せない方がよいです。

最初は読み取り専用の定期チェックにします。

job: browser-qa-smoke-check
schedule: "weekdays 09:00"
target:
  - "https://preview.example.com/"
  - "https://preview.example.com/pricing"
checks:
  - page_load
  - console_error
  - network_error
  - visible_text
  - screenshot
forbidden:
  - form_submit
  - production_login
  - download_customer_data
  - payment_action
output:
  - markdown_report
  - screenshot_links
  - manual_review_required

毎朝のQAでは、AIに修正まで任せるより、壊れている画面を発見してIssue化するところまでに留めるのが扱いやすいです。

失敗パターン

失敗1: 普段使いChromeに接続する

普段使いChromeには、想像以上に強いセッションがあります。

管理画面、広告、決済、クラウド、SNS、メール、社内SaaSなどへログイン済みなら、AIエージェントから見える世界も広がります。公式READMEでも、ブラウザ内の情報がMCPクライアントへ露出し得る点に注意喚起があります。

最初は専用プロファイル、専用テストアカウント、stagingだけに絞ります。

失敗2: 「操作できる」を「任せてよい」と混同する

Chrome DevTools MCPは、クリック、入力、スクリーンショット、Network確認、Console確認、Trace取得などができます。

しかし、できることと任せてよいことは別です。

特に次は、人間承認の前に実行させない方がよいです。

- 本番DBへ影響する保存
- メール送信
- 決済操作
- 権限変更
- 外部公開
- 顧客データのダウンロード

失敗3: E2Eテストを全部置き換えようとする

AIによるブラウザ確認は、調査やレビュー補助には強いです。

一方で、回帰テストとしての再現性、差分管理、CIでの安定実行はPlaywrightなどのテストコードの方が向いています。

使い分けはこうです。

毎回必ず守りたい仕様
  -> Playwright / unit test / integration test

今回のPRで気になる画面確認
  -> Chrome DevTools MCP

原因がまだ分からない不具合調査
  -> Chrome DevTools MCP + 人間レビュー

失敗4: スクリーンショットを保存しすぎる

スクリーンショットは便利ですが、社内情報や個人情報が写り込みます。

保存ルールを決めます。

Screenshot policy:
- localhostとpreviewだけ保存可
- 顧客情報が写る画面は保存禁止
- 保存先は一時ディレクトリ
- PRに添付する前に人間が確認
- 30日以上残さない

失敗5: 失敗時にAIへ自動修正まで任せる

ブラウザQAでエラーを見つけた直後に、自動で修正PRまで作らせると、原因仮説が雑なままコード変更へ進みがちです。

最初は次の2段階に分けます。

まとめ

Chrome DevTools MCPは、ブラウザ自動化の新しい入口です。

ただし実務導入では、最初から「AIにSaaSを操作させる」方向へ進めるより、次の順番が安全です。

専用Chromeプロファイルを作る
localhost / staging / previewだけを見る
DOM、Console、Network、Traceの証跡を集める
PRレビュー用のBrowser QA Reportを作る
人間が判断してから修正タスクへ進める

Chrome DevTools MCPの価値は、AIがクリックできることではありません。

AIがブラウザ上の事実を集め、人間が判断しやすい形に整えられることです。

この前提で導入すると、AIエージェントは「なんとなく画面を見た人」ではなく、レビュー前の調査担当として機能します。

参考リンク

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。