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エージェントは「なんとなく画面を見た人」ではなく、レビュー前の調査担当として機能します。
参考リンク
- Chrome DevTools (MCP) for your AI agent - Chrome for Developers
- ChromeDevTools/chrome-devtools-mcp - GitHub
- chrome-devtools-mcp CLI options
- Model Context Protocol Specification
- 参考記事: Chrome DevTools MCP が凄い。人類が「プログラムにやってほしかったこと」が簡単にできる時代がきた！！
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。