Chrome DevTools MCPでAIエージェントに性能調査を任せる：Performance・Network・Console・Lighthouseの分け方

3行まとめ

Trace

遅さの入口をperformanceで見る。

Network

待ち時間と失敗requestを分ける。

Console

実行時errorとwarningを拾う。

Lighthouse

最後に総合auditで確認する。

DevTools MCPは、AI agentへ調査材料を渡す入口として使います。

• Chrome DevTools MCPは、AIエージェントにChromeを操作させるだけでなく、Performance trace、Network request、Console message、Lighthouse auditを調査材料として渡せる点が強みです。
• 最初からログイン済みChromeや既存profileへつなぐのではなく、public URL、最小権限、短い調査promptから始め、必要になった段階で接続先Chromeを広げます。
• 便利さの裏側で、browser content、cookie、localStorage、PII、社内画面の情報がagentへ見えるため、調査範囲と報告形式を先に固定します。

本文の事実確認には、Chrome for DevelopersのChrome DevTools for agents docs、Get started guide、ChromeDevTools/chrome-devtools-mcp READMEを使っています。Xで見かけるDevTools MCP、AI coding agent、Lighthouse、browser debuggingへの投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

用途

性能調査、通信確認、エラー確認を分けます。

接続

新規Chromeか既存sessionかを選びます。

権限

cookieやPIIが見える範囲を制限します。

運用

AI agentの報告形式を固定します。

先に任せる調査を決めると、権限を広げすぎません。

• Chrome DevTools MCPで任せやすい調査と任せにくい調査
• Performance trace、Network、Console、Lighthouseの役割分担
• Playwright MCPとChrome DevTools MCPをどう使い分けるか
• 既存Chrome sessionへ接続するときの権限リスク
• usage statisticsや外部送信を導入前にどう説明するか
• チーム導入初週に確認する順番

Chrome DevTools MCPは、AIエージェントに「この画面、なぜ遅いのか見て」と頼むための入口として使えます。手でDevToolsを開き、Performanceを記録し、Networkを見て、Consoleを確認し、Lighthouseを回す流れを、agentの調査手順へ落とし込めます。

ただし、DevToolsはブラウザの中身を見る道具です。ログイン済み画面へつなぐと、agentはそのsessionで見える情報を調べられます。この記事では、導入時に便利さだけを見ないよう、調査の種類と権限を分けて整理します。

前提知識

項目	内容	見方
MCP server		live Chromeをagentから調べます。
Trace		performance traceを記録して分析します。
Debug		network、console、screenshotを見ます。
Security		browser contentをagentへ見せる前提です。

Chromeを調べる権限は、web pageの内容を見る権限でもあります。

Chrome for Developersでは、Chrome DevTools for agentsを、AI agentがChrome browserとやり取りして、codeをtestし、user flowをemulateし、出荷前にbugを捕まえるための仕組みとして説明しています。Get started guideでは、chrome-devtools-mcp packageを使い、coding agentからlive Chrome browserをcontrol、inspectできると説明されています。

公式READMEでも、Chrome DevTools MCPはModel Context Protocol serverとして動き、AI coding assistantへDevToolsの力を渡すものとされています。主な機能は、performance traceの記録とinsight抽出、network requestやconsole messageの確認、screenshot、browser automationです。

この記事の扱う範囲

項目	役割
Performance trace	遅い画面で、処理、描画、待ちの入口を探す
Network request	API、asset、status、timing、payloadを確認する
Console message	runtime error、warning、stack traceを拾う
Lighthouse	performance、accessibility、SEOなどの総合点検に使う
Chrome session	新規Chrome、headless、既存session、isolated profileを分ける
Security	browser contentや認証済み情報をagentへ見せる前提を整理する

2026年5月31日時点で公開されているChrome for DevelopersとChromeDevTools/chrome-devtools-mcp READMEを確認しています。導入時には、利用するMCP client、Chrome version、Node.js、npm、社内のデータ取り扱い規程を確認してください。

注意点

この記事は、AIエージェントに本番アカウントや社内管理画面を無条件に渡すための記事ではありません。まず公開URLや検証用環境で使い、必要な場合だけ既存Chrome sessionへの接続を検討する前提です。

まず4つの調査に分ける

項目	内容	見方
Performance		遅い画面の原因候補を探します。
Network		API、asset、statusを確認します。
Console		runtime errorとwarningを拾います。
Lighthouse		a11y、SEO、performanceを点検します。

一度に全部任せず、証跡の種類ごとに依頼を分けます。

Chrome DevTools MCPを入れるときは、「ブラウザを操作できるようになった」で止めず、どの調査を任せるのかを4つに分けます。

調査	agentに頼むこと	出力してほしいもの
Performance	遅い操作をtraceし、原因候補を挙げる	重い処理、長いtask、次に見るfile
Network	requestの失敗や遅延を確認する	status、URL、timing、payloadの要約
Console	errorやwarningを拾う	message、stack trace、再現手順
Lighthouse	PR前の総合点検をする	performance、a11y、SEOの改善候補

この4つを混ぜると、agentの報告が「なんとなく遅そう」「エラーがありそう」になりがちです。最初のpromptでは、調査の種類を1つに絞ります。

よい依頼の形

たとえばPerformanceなら、「このURLを開き、初回表示から主要操作までのtraceを取り、遅さの候補を3つに絞って、根拠となるtrace insightと次に見るファイルを分けて報告して」と頼みます。Networkなら、「4xx/5xx、遅いrequest、過大payload、redirectを分けて、ユーザー影響が大きい順に並べて」と頼みます。

悪い依頼の形

「サイトを見て直して」だけだと、agentは画面操作、性能、通信、Console、Lighthouseを一度に混ぜます。調査の切り口がぼやけると、PRに残すべき証跡もぼやけます。

Performance traceで遅さの入口を見る

1. Start

   対象URLと操作手順を決める。

2. Record

   performance traceを記録する。

3. Insight

   重い処理や待ちを抽出する。

4. Action

   次に見るfileやrequestへ絞る。

traceは結論ではなく、次に調べる場所を絞る材料です。

Chrome DevTools MCPの価値が出やすいのはPerformance traceです。Chrome for DevelopersのGet started guideでも、setup確認の例として、指定URLのperformanceを確認し、browserがperformance traceを記録する流れが示されています。

Performance traceは、遅さの最終回答ではありません。最初に見るべき入口です。長いtask、rendering、script実行、layout、network待ちなど、どの方向へ掘るべきかを決める材料になります。

agentへ渡す手順

1. 対象URLを1つに絞る
2. 初回表示か、特定操作後かを決める
3. traceを記録する
4. insightを3つ以内に絞る
5. 次に見るrequest、component、bundle、APIを分ける

この順番にすると、報告が実装作業へつながります。逆に、最初から「改善して」と頼むと、traceの根拠が弱いままCSSやJavaScriptを触り始めることがあります。

判断基準

traceで見るのは、原因の断定ではなく「次の調査先」です。Long taskが見えたらJavaScript実行を追い、network待ちが目立つならrequestを追い、renderingが重いならDOM量や画像を見ます。

Networkで待ち時間と失敗を分ける

項目	内容	見方
Status		4xx、5xx、redirectを確認します。
Timing		待ち時間が長いrequestを見ます。
Payload		過大なassetやresponseを探します。
Order		critical path上の詰まりを分けます。

Networkは、重い処理と外部待ちを分けるために使います。

Network確認では、statusとtimingを分けて見ます。4xxや5xxは失敗として扱いやすい一方、200でも遅いrequest、redirectが多いrequest、payloadが大きすぎるassetは、ユーザー体験を落とします。

ChromeDevTools/chrome-devtools-mcp READMEのtool一覧では、Networkのtoolとしてrequest一覧の取得や個別request確認が示されています。agentへは「失敗一覧」だけでなく、「待ち時間が長いもの」「初期表示に効くもの」「後回しにできるもの」を分けて出させると実務で使いやすくなります。

Network報告の型

見るもの	報告内容
status	4xx、5xx、redirect、blockedを分ける
timing	待ち時間が長いrequestを上位から並べる
payload	大きいasset、重いJSON、不要なresponseを確認する
order	初期表示前に待っているrequestを拾う

Networkの報告は、URLだけでは足りません。ユーザー操作、画面状態、再現した時刻、関係しそうなConsole messageも一緒に残します。

Playwright MCPとの違い

前回整理したPlaywright MCPでAIエージェントにブラウザ検証を任せる手順は、snapshotを使った操作確認やE2E補助に寄せています。Chrome DevTools MCPは、操作そのものより、DevToolsから見えるtrace、network、console、Lighthouseを調査材料にする用途で分けると重複しません。

Consoleで実行時エラーを拾う

Error

ユーザー操作を止める候補です。

Warning

将来の不具合や設定漏れを見ます。

Source map

stack traceから実装箇所へ寄せます。

Noise

既知の外部script由来は分けます。

Consoleは数ではなく、ユーザー影響で優先度を付けます。

Console確認は、AIエージェントに任せやすい一方で、ノイズが混ざりやすい領域です。extension由来、外部script由来、広告由来、開発時だけ出るwarning、source mapの欠落などが混ざると、重要なerrorを見失います。

ChromeDevTools/chrome-devtools-mcp READMEでは、browser console messageの確認やsource-mapped stack traceへの言及があります。実務では、Console messageを数で見るより、ユーザー操作を止めるか、data保存を壊すか、開発者がすぐ直せるかで優先度を付けます。

優先度の付け方

優先度	例	対応
高	form送信が止まる、画面が白くなる	すぐ修正候補へ入れる
中	特定操作でerrorが出るが回避可能	再現手順を残して修正
低	外部scriptのwarning、既知のnoise	除外理由を残す

Console確認をagentに頼むときは、「errorとwarningを分けて、ユーザー影響と再現手順を添えて」と指示します。「全部直して」ではなく、「直すべきものと、今は除外するものを分けて」と頼むのが扱いやすいです。

Lighthouseは最後の総合確認に使う

Performance

改善前後の傾向を見ます。

A11y

見落としやすい操作性を拾います。

SEO

基本metadataと構造を点検します。

Checklist

PR前の確認項目にします。

Lighthouseは原因特定より、抜け漏れ確認に向いています。

Chrome for DevelopersのDevTools for agents pageでは、Lighthouseを使ったproactive QAとして、accessibility、SEO、performanceのauditを出荷前のchecklistにできると説明されています。

Lighthouseは便利ですが、最初の原因調査に使うより、最後の総合確認に向いています。Performance traceで遅さの入口を見て、Networkで外部待ちを見て、Consoleでruntime errorを見たあとに、PR前の抜け漏れ確認として使うと役割がはっきりします。

PR前に見る項目

• Performance scoreの変化
• accessibilityの重大な指摘
• SEO metadataやheading構造の基本的な不足
• best practicesの明らかな警告
• 改善しない項目の理由

LighthouseのscoreだけをPRの合否にすると、数値に振り回されます。agentには、score、主要指摘、ユーザー影響、今回のPRで対応するかどうかを分けて報告させます。

接続先Chromeとprofileを分ける

項目	内容	見方
New Chrome		通常は新しいChromeで始めます。
Headless		背景実行ではUIなしを選びます。
Existing		既存session接続は慎重に使います。
Isolated		temporary profileで混線を減らします。

既存Chromeへつなぐほど、agentへ見える情報も増えます。

Chrome DevTools MCPの導入で一番注意したいのは、どのChromeに接続するかです。Get started guideでは、通常は新しいChrome instanceを使い、必要に応じてheadless modeや既存browser sessionへの接続を設定できると説明されています。

既存sessionへ接続すると、agentはログイン済みアカウント、cookie、localStorage、ページ内の個人情報、社内情報へ近づきます。公式docsでも、browser contentがagentへ見えること、active authenticated sessionへ接続するとagentがユーザーの代わりに操作できる点が警告されています。

接続方式の分け方

方式	使う場面	注意点
新規Chrome	public page、通常の調査	最初の選択肢にする
headless	背景実行、定型調査	目視が必要な調査とは分ける
isolated profile	session混線を避けたい	毎回状態が変わる前提で見る
existing session	SSOや再現済み画面が必要	PIIと認証権限を渡す判断になる

既存sessionは最後に判断する

既存Chromeへつなぐ理由が「ログインが面倒だから」だけなら、まずstaging用のtest accountやpublic pageで代替できないかを見ます。SSO、2FA、社内proxy、特定cookieが必要な場合だけ、prompt、対象URL、操作禁止範囲、報告形式を決めてから使います。

usage statisticsと外部送信を確認する

項目	内容	見方
Stats		usage statisticsの扱いを確認します。
Prompt		agentへ渡す内容を制限します。
Session		ログイン情報やPIIを含めない。
Policy		社内規程とclient設定を合わせます。

調査できることと、送ってよい情報は別の判断です。

Chrome DevTools MCPに限らず、AIエージェントへbrowser調査を渡すときは、どの情報がどこへ送られるのかを確認します。MCP server自体がlocalに動いていても、MCP client側のmodel providerへprompt、tool result、page内容、console message、network情報が渡る可能性があります。

公式READMEには、Chrome DevTools MCPがbrowser instanceのcontentをMCP clientsへ公開し、inspect、debug、modifyできることへの注意があります。これは「MCP serverが危険」という話ではなく、DevTools相当の強い観測権限をagentへ渡すという話です。

導入前に決めること

項目	決める内容
対象URL	public、staging、本番、社内画面を分ける
account	test accountか、個人accountかを分ける
data	PII、secret、token、customer dataを含めない
logs	tool resultをどこに保存するか決める
prompt	agentへ貼ってよい情報を制限する

usage statisticsやtelemetryの扱いは、使うclient、plugin、MCP server versionで変わる可能性があります。導入前に公式設定を読み、社内規程と合わない場合は無効化や別環境運用を検討します。

最小設定の形

項目	内容	見方
Install		npxでMCP serverを追加します。
No login		public pageから確認します。
Headless optional		必要ならUIなしで実行します。
Report		trace、request、consoleを分けて報告。

最初はログイン済みsessionを渡さず、公開URLで動作を見ます。

Chrome for DevelopersのGet started guideでは、Codex向けに codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest の形が示されています。JSON設定では、mcpServersにchrome-devtoolsを追加し、npxでchrome-devtools-mcp@latestを起動する形です。

最初の設定は、機能を広げるよりも、調査の型を固めるために使います。public URLでperformance promptを試し、NetworkとConsoleの報告形式を決め、Lighthouseを最後に回す流れを作ります。

最初のprompt例

指定URLをChrome DevTools MCPで確認してください。
1. Performance traceを記録し、遅さの候補を3つに絞る
2. Networkで失敗requestと遅いrequestを分ける
3. Console errorをユーザー影響順に並べる
4. Lighthouseは最後に実行し、今回対応する項目と見送る項目を分ける
ログイン済みsessionや個人情報を含む画面には進まないでください。

このpromptは万能ではありませんが、調査範囲を明示できます。重要なのは、agentに「見つけたものを全部直す」ではなく、「証跡を分類して報告する」役割を先に持たせることです。

導入初週の進め方

1. 1日目

   public URLでperformance promptを試す。

2. 2日目

   networkとconsoleの報告形式を固定。

3. 3日目

   LighthouseをPR前確認に入れる。

4. 5日目

   stagingでログイン不要の画面を確認。

5. 7日目

   既存session接続の要否をreview。

権限を広げる前に、報告の型を先に固めます。

初週は、権限を広げる週ではなく、報告の型を固める週にします。Chrome DevTools MCPは強力なので、最初から本番ログイン画面へつなぐより、公開URLと検証用画面で使い方を固めた方が失敗が少なくなります。

日	やること	完了条件
1日目	public URLでPerformance traceを試す	報告が重い処理、network待ち、次の調査先に分かれる
2日目	NetworkとConsoleの報告形式を決める	status、timing、error、warningが分かれる
3日目	LighthouseをPR前確認に入れる	scoreだけでなく主要指摘と対応方針が出る
5日目	stagingのログイン不要画面へ広げる	PIIやsecretを含まない範囲で確認できる
7日目	既存session接続の要否をreviewする	使う理由、禁止操作、保存ログが決まる

チームで固定する報告項目

• 対象URLと操作手順
• 使用したtoolの種類
• Performance traceの要点
• Networkで見つけたrequest
• Console errorとユーザー影響
• Lighthouseの主要指摘
• 今回直すもの、見送るもの

この報告項目をPR templateへ入れておくと、agentの調査がレビューしやすくなります。PRに残す証跡の考え方は、AIエージェントPRテンプレートの作り方でも整理しています。

FAQ

Playwright MCP?

操作確認と性能調査で使い分けます。

Login?

既存session接続は最後に判断します。

Lighthouse?

最後の総合点検として使います。

CI?

自動保証は別途testへ落とします。

迷ったら、agentに見せるbrowser情報の広さを先に見ます。

Playwright MCPとどちらを使うべきですか

操作確認やE2E補助はPlaywright MCP、DevTools由来の性能、Network、Console、Lighthouse調査はChrome DevTools MCP、と分けると判断しやすいです。どちらか一方に寄せるより、用途で分けた方が権限も説明しやすくなります。

既存Chrome sessionへ接続してよいですか

必要な場合だけにします。既存sessionには、ログイン済みaccount、cookie、localStorage、閲覧中の社内情報が含まれることがあります。公式docsにも、active authenticated sessionに接続するとagentがユーザーの代わりに行動できる点が警告されています。

Lighthouseのscoreで合否を決めてよいですか

scoreだけで合否を決めるのは避けます。Lighthouseは、a11y、SEO、performanceの抜け漏れを拾うchecklistとして使い、今回のPRで対応するものと見送るものを分けます。

CIに入れれば十分ですか

Chrome DevTools MCPはagentによる調査に向いています。毎回保証したい項目は、Playwright Test、unit test、Lighthouse CIなど、再現可能なtestへ落とします。agentの調査は、原因候補を絞る入口として扱います。

参照した主な情報源

• Chrome for Developers: Chrome DevTools for agents

https://developer.chrome.com/docs/devtools/agents

• Chrome for Developers: Get started with Chrome DevTools for agents

https://developer.chrome.com/docs/devtools/agents/get-started

• ChromeDevTools/chrome-devtools-mcp README

https://github.com/ChromeDevTools/chrome-devtools-mcp

• Model Context Protocol

https://modelcontextprotocol.io/

次に読むなら

更新履歴

1. 2026年5月31日

   Chrome for DevelopersとChromeDevTools/chrome-devtools-mcp READMEを確認して初版を作成しました。

導入時には公式docsと利用clientのMCP設定を確認してください。

• 2026年5月31日: Chrome for DevelopersとChromeDevTools/chrome-devtools-mcp READMEを確認し、初版を作成しました。