Chrome DevTools MCP の全ツールをまとめて理解する

Posted at 2026-04-18

AIエージェントから Chrome DevTools を操作・解析するための chrome-devtools-mcp 完全ガイド

chrome-devtools-mcp は、AI コーディングエージェントから 生きた Chrome ブラウザを操作し、調査し、解析する ための MCP サーバーです。公式 README では、Gemini / Claude / Cursor / Copilot などのエージェントが Chrome を制御し、自動操作・デバッグ・パフォーマンス分析 を行えると説明されています。 ([GitHub][1])

公式のツールリファレンスでは、ツールは次の 6 カテゴリ、合計 29 個 に整理されています。 ([GitHub][2])

Input automation: 9
Navigation automation: 6
Emulation: 2
Performance: 4
Network: 2
Debugging: 6 ([GitHub][2])

この記事では、公式の tool-reference.md をベースに、各ツールを「何をするものか」「どんな時に使うか」「似たツールとの違い」まで含めて、実務目線でわかりやすく 解説します。 ([GitHub][2])

まず全体像

chrome-devtools-mcp をひと言で表すと、AI に Chrome DevTools の手と目を渡す仕組みです。
単なるブラウザ自動操作だけではなく、以下まで踏み込めます。 ([GitHub][1])

ボタンやフォームの操作
タブ管理やページ遷移
モバイル表示やネットワーク制限の再現
パフォーマンストレース取得
ネットワークリクエスト確認
console ログ確認
DOM スナップショット取得
スクリーンショット取得
ページ内 JavaScript 実行 ([GitHub][2])

つまり、chrome-devtools-mcp は
「操作する」
「観測する」
「解析する」
を 1 つの流れで扱えるのが強みです。 ([GitHub][1])

1. Input automation

ここは ユーザー操作の再現 を担うカテゴリです。
クリック、入力、ドラッグ、ホバー、キー操作などを行います。公式では 9 ツールあります。 ([GitHub][2])

`click`

何をするツールか
指定した要素をクリックします。ダブルクリックにも対応しています。 ([GitHub][2])

主な用途

ボタン押下
リンククリック
モーダルを開く
UI フローを先に進める

重要ポイント

対象要素は uid で指定します
uid は take_snapshot で取得するのが基本です
dblClick=true でダブルクリックできます ([GitHub][2])

使いどころ

「ログインボタンを押す」
「メニューを開く」
「一覧の詳細リンクを選ぶ」

似たツールとの違い

単純な押下ならまず click
ホバー起点の UI なら hover → click
ドラッグ操作が必要なら drag

`drag`

何をするツールか
ある要素を別の要素へドラッグ＆ドロップします。 ([GitHub][2])

主な用途

並び替え UI
ドラッグ＆ドロップ式アップロード UI
Kanban ボードのカード移動

重要ポイント

from_uid と to_uid が必要
両方ともスナップショット上の uid を使います ([GitHub][2])

使いどころ

「タスクカードを Done に移動」
「画像ブロックを別の領域へ配置」

注意

実装によっては要素座標や特殊イベント依存のケースもあるので、失敗時は take_snapshot で最新状態を見直すと安定します。これは公式が uid ベースの操作前提であることからも自然な運用です。 ([GitHub][2])

`fill`

何をするツールか
単一のフォーム要素に値を入れます。input、textarea、select に対応します。 ([GitHub][2])

主な用途

メールアドレス入力
検索ボックス入力
セレクトボックス選択
テキストエリアへの文章入力

重要ポイント

uid と value が必要
キーボード入力風ではなく、「値を入れる」寄り の操作です ([GitHub][2])

使いどころ

「ログインフォームに ID/PW を入れる」
「都道府県 select を選択する」

似たツールとの違い

単発入力なら fill
複数項目を一気に埋めるなら fill_form
キー入力そのものを再現したいなら type_text

`fill_form`

何をするツールか
複数フォーム要素を一括で埋めます。 ([GitHub][2])

主な用途

会員登録フォーム
住所入力フォーム
検索条件のまとめ入力

重要ポイント

elements 配列で複数要素をまとめて指定
単項目ごとに fill を連打するより、意図が明確になります ([GitHub][2])

使いどころ

「氏名、メール、住所、電話番号を一気に入力したい」
E2E 的な入力工程を短く記述したい

似たツールとの違い

fill は単一項目
fill_form はフォーム全体向き

`handle_dialog`

何をするツールか
ブラウザダイアログを受け入れるか閉じるかを操作します。prompt に文字を入れることもできます。 ([GitHub][2])

対象になるもの

alert
confirm
prompt

重要ポイント

action は accept または dismiss
promptText で入力値を渡せます ([GitHub][2])

使いどころ

「削除してよいですか？」に OK
名前入力 prompt に値を渡す
beforeunload 系とは別物で、そちらは navigate_page 側の設定も関係します ([GitHub][2])

`hover`

何をするツールか
要素の上にマウスカーソルを乗せます。 ([GitHub][2])

主な用途

ホバーで開くメニュー
ツールチップ表示
hover state の UI 検証

重要ポイント

対象指定は uid
目に見えないサブメニューを出す前段として有効です ([GitHub][2])

使いどころ

「プロフィールメニューを開く」
「ホバー時だけ出る削除アイコンを表示する」

`press_key`

何をするツールか
キーまたはキーコンビネーションを送信します。公式でも、fill() では扱いにくい ショートカット・ナビゲーションキー・特殊なキー操作 に使うよう説明されています。 ([GitHub][2])

主な用途

Enter
Tab
Escape
Ctrl+A
Ctrl+Shift+R など ([GitHub][2])

使いどころ

ダイアログを Escape で閉じる
ショートカット操作を再現する
フォーカス移動を Tab で確認する

似たツールとの違い

文字列入力ではなく キー入力
テキストそのものは type_text または fill

`type_text`

何をするツールか
事前にフォーカスされた入力欄へ、キーボード入力として文字列を打ち込みます。必要なら最後に Enter や Tab なども送れます。 ([GitHub][2])

主な用途

検索欄にタイプして Enter
IME やキーイベント依存 UI の検証
input イベントに強く依存するコンポーネント操作

重要ポイント

先に対象をフォーカスしておく必要がある
submitKey で Enter / Tab / Escape を続けられる ([GitHub][2])

使いどころ

fill だとアプリ側のイベントが発火しないケース
リアルな入力挙動を見たいケース

似たツールとの違い

fill は値セット寄り
type_text はタイピング寄り

`upload_file`

何をするツールか
ファイル入力要素、またはファイル選択を開く要素を使ってローカルファイルをアップロードします。 ([GitHub][2])

主な用途

画像アップロード
CSV インポート
添付ファイル送信テスト

重要ポイント

filePath が必要
uid も必要
対象は file input そのものでも、ファイル chooser を開く UI 要素でもよいとされています ([GitHub][2])

使いどころ

「プロフィール画像をアップロード」
「請求書 PDF を添付」

2. Navigation automation

ここは タブやページ遷移の管理 を行うカテゴリです。
公式では 6 ツールです。 ([GitHub][2])

`close_page`

何をするツールか
指定したページ ID のタブを閉じます。
ただし、最後の 1 ページは閉じられません。 ([GitHub][2])

使いどころ

不要なタブ整理
ポップアップタブを閉じる
複数タブ操作後の後片付け

`list_pages`

何をするツールか
現在開いているページ一覧を取得します。パラメータはありません。 ([GitHub][2])

使いどころ

新しいタブが開いたか確認
select_page や close_page の前準備
複数タブの管理

実務で重要

複数タブを扱うときは、まず list_pages で状況把握
次に select_page で文脈を切り替える、という流れが安定です ([GitHub][2])

`navigate_page`

何をするツールか
URL へ移動するだけでなく、戻る・進む・リロード もできます。 ([GitHub][2])

主な用途

URL 遷移
ブラウザ履歴の back / forward
リロード
beforeunload ダイアログ対処

重要ポイント

type は url / back / forward / reload
url は type=url 時のみ必要
ignoreCache は reload 時に便利
initScript で次のドキュメント読み込み前に JS を差し込める
handleBeforeUnload で beforeunload ダイアログ挙動を制御できる ([GitHub][2])

使いどころ

「キャッシュ無視で再読み込み」
「前ページに戻る」
「初期化スクリプトを入れて検証したい」

`new_page`

何をするツールか
新しいタブを開いて URL を読み込みます。 ([GitHub][2])

重要ポイント

url は必須
background=true で背後に開ける
isolatedContext を使うと、cookie / storage を共有しない独立コンテキストでページを開けます ([GitHub][2])

使いどころ

本番系と検証系を分ける
ログイン状態の影響を切り離す
マルチセッション検証

かなり便利な点
isolatedContext があるので、
「同じサイトを別セッション扱いで並行確認」
がやりやすいです。これはログインフローや権限差分検証で特に効きます。 ([GitHub][2])

`select_page`

何をするツールか
今後のツール操作対象となるページを選択します。 ([GitHub][2])

主な用途

複数タブ間の切り替え
popup 遷移後の対象変更
調査対象の明示切り替え

重要ポイント

pageId が必要
bringToFront で前面化も可能 ([GitHub][2])

`wait_for`

何をするツールか
指定した文字列のいずれかがページに現れるまで待機します。 ([GitHub][2])

主な用途

ローディング待ち
遷移完了待ち
成功メッセージ待ち
SPA 更新待ち

重要ポイント

text は空でない配列
どれか 1 つが表示されれば解決
timeout も指定可能 ([GitHub][2])

使いどころ

「保存しました」が出るまで待つ
「ダッシュボード」が表示されるのを待つ

補足
スクリーンショット待ちより、テキストの出現待ち のほうが自動化は安定しやすいです。take_snapshot と併用するとさらに堅くなります。これは公式が snapshot の利用を強く勧めている点とも整合します。 ([GitHub][2])

3. Emulation

ここは 環境再現 のカテゴリです。
端末、回線、CPU、位置情報、カラースキームなどを切り替えます。 ([GitHub][2])

`emulate`

何をするツールか
選択中ページに対して、さまざまなエミュレーションを適用します。 ([GitHub][2])

設定できるもの

colorScheme: dark / light / auto
cpuThrottlingRate
geolocation
networkConditions: Offline / Slow 3G / Fast 3G / Slow 4G / Fast 4G
userAgent
viewport ([GitHub][2])

使いどころ

モバイル表示再現
ダークモード確認
低速回線での表示確認
CPU 制限下での操作体感確認
位置情報依存 UI の確認

かなり実務的な使い方

viewport + mobile + touch
networkConditions=Slow 4G
cpuThrottlingRate
を組み合わせると、「遅い端末・遅い回線の体感に近い再現」 ができます。これは性能改善の優先順位付けで有効です。 ([GitHub][2])

`resize_page`

何をするツールか
ページのウィンドウサイズを変更します。幅と高さを直接指定します。 ([GitHub][2])

使いどころ

レスポンシブのブレークポイント確認
特定サイズでのレイアウト崩れ再現
デスクトップ最小幅の確認

emulate との違い

resize_page はシンプルにサイズ変更
emulate は UA / touch / mobile / DPR まで含めた環境再現

つまり、
サイズだけ見たいなら resize_page
端末っぽさまで再現したいなら emulate
です。 ([GitHub][2])

4. Performance

ここは パフォーマンス調査 のカテゴリです。
公式 README でも、トレースを取り、Core Web Vitals を含む実用的な insight を得られる点が主要機能として挙げられています。 ([GitHub][1])

`performance_analyze_insight`

何をするツールか
トレース結果で提示された特定 Insight について、より詳しい分析情報を取得します。 ([GitHub][2])

主な用途

LCP 改善の深掘り
DocumentLatency の原因調査
トレース結果の個別論点の精査

重要ポイント

insightName
insightSetId
が必要です
insightSetId は、前段のトレース結果で出てきたものを使います ([GitHub][2])

使いどころ

「遅いのは分かったが、どこがボトルネックか詳しく知りたい」

`performance_start_trace`

何をするツールか
パフォーマンストレースを開始します。公式では、フロントエンド性能問題、Core Web Vitals（LCP, INP, CLS）、ページ読み込み速度改善に使うと説明されています。 ([GitHub][2])

主な用途

パフォーマンス記録開始
リロードを含む初期表示計測
trace ファイル保存

重要ポイント

autoStop
filePath
reload
が使える
reload や autoStop を使う場合、事前に navigate_page で対象 URL に移動しておくよう公式で案内されています ([GitHub][2])

使いどころ

「トップページ初回表示の計測」
「改善前後でトレース比較」

`performance_stop_trace`

何をするツールか
進行中のトレースを停止します。必要ならファイル保存もできます。 ([GitHub][2])

使いどころ

手動で任意タイミングに計測終了
操作シナリオを最後まで流してから記録停止

典型パターン

navigate_page
performance_start_trace
操作
performance_stop_trace

`take_memory_snapshot`

何をするツールか
現在ページの heap snapshot を取得します。公式では、JavaScript オブジェクトのメモリ分布分析やメモリリーク調査に使うとされています。 ([GitHub][2])

主な用途

メモリリーク調査
オブジェクトの保持状況確認
長時間利用ページの異常増加確認

重要ポイント

filePath は必須
.heapsnapshot として保存します ([GitHub][2])

使いどころ

SPA で画面遷移を繰り返すとメモリが増え続ける
modal 開閉で GC されない参照を疑う

5. Network

ここは 通信の観測 を担います。
「API が失敗している」「CORS が怪しい」「レスポンスの中身を見たい」という時に重要です。公式ツールは 2 つです。 ([GitHub][2])

`get_network_request`

何をするツールか
特定のネットワークリクエストを取得します。reqid を指定しなければ、DevTools Network パネルで現在選択されているリクエストを返します。 ([GitHub][2])

見られるもの

リクエスト情報
レスポンス情報
body の保存

重要ポイント

reqid は任意
requestFilePath
responseFilePath
で body をファイル保存できる
省略時は inline 返却されます ([GitHub][2])

使いどころ

API エラーのレスポンス内容確認
GraphQL / REST payload の調査
CORS / 認証周りの失敗調査

`list_network_requests`

何をするツールか
選択中ページについて、直近ナビゲーション以降のネットワークリクエスト一覧を取得します。 ([GitHub][2])

重要ポイント

includePreservedRequests=true で過去 3 ナビゲーション分も含められる
pageIdx, pageSize でページング可能
resourceTypes で絞り込みできる ([GitHub][2])

使いどころ

まず一覧を見る
気になる reqid を見つける
詳細は get_network_request で掘る

おすすめ運用
ネットワーク調査は基本的に
list_network_requests → get_network_request
の順がわかりやすいです。これは console 系の
list_console_messages → get_console_message
と同じ構図です。 ([GitHub][2])

6. Debugging

ここは 調査・確認・監査 のカテゴリです。
console、JS 実行、Lighthouse、snapshot、screenshot が入っています。実務ではかなり使用頻度が高い領域です。 ([GitHub][2])

`evaluate_script`

何をするツールか
選択中ページ内で JavaScript 関数を実行し、結果を JSON として返します。戻り値は JSON 化できる値 に限られます。 ([GitHub][2])

主な用途

DOM 状態の確認
document.title 取得
特定要素のテキスト取得
アプリ内部状態の軽い確認

重要ポイント

function は関数宣言文字列
args で引数を渡せる
async 関数も可能と公式例にあります ([GitHub][2])

使いどころ

「表示中のタイトルを取る」
「特定要素の innerText を読む」
「window 配下の状態を軽く確認する」

注意
複雑な DOM オブジェクトそのものを返すのではなく、文字列・数値・配列・JSON 化可能オブジェクトにして返す のが前提です。 ([GitHub][2])

`get_console_message`

何をするツールか
指定した msgid の console message を取得します。 ([GitHub][2])

使いどころ

エラー詳細確認
warn / error の個別精査
stack や関連情報の確認

典型フロー

list_console_messages
気になる msgid を選ぶ
get_console_message で掘る ([GitHub][2])

`lighthouse_audit`

何をするツールか
Lighthouse の accessibility / SEO / best practices の監査結果を取得します。
公式では、performance は含まれない ので、性能監査は performance_start_trace を使うように書かれています。 ([GitHub][2])

重要ポイント

device: desktop / mobile
mode: navigation / snapshot
outputDirPath でレポート保存可能 ([GitHub][2])

mode の違い

navigation: リロードして監査
snapshot: 現在表示状態を監査 ([GitHub][2])

使いどころ

アクセシビリティ観点の自動チェック
noindex / meta / 構造化不備の発見
セキュリティやベストプラクティス確認

`list_console_messages`

何をするツールか
直近ナビゲーション以降の console message 一覧を取得します。 ([GitHub][2])

重要ポイント

includePreservedMessages=true で過去 3 ナビゲーション分も対象
pageIdx, pageSize あり
types で絞り込み可能 ([GitHub][2])

使いどころ

まずページの異常有無を見る
error / warning だけに絞って俯瞰する
詳細は get_console_message

`take_screenshot`

何をするツールか
ページ全体または要素単位のスクリーンショットを撮ります。 ([GitHub][2])

重要ポイント

format: png / jpeg / webp
fullPage=true でページ全体
uid 指定で要素単位キャプチャ
quality は JPEG / WebP 用
fullPage と uid は併用不可 ([GitHub][2])

使いどころ

見た目崩れの証跡取得
Before / After 比較
特定コンポーネントだけの切り出し

よくある誤解
スクショは便利ですが、公式は次の take_snapshot を より優先 するよう案内しています。 ([GitHub][2])

`take_snapshot`

何をするツールか
現在ページの a11y tree ベースのテキストスナップショット を取得します。
要素一覧と一意な uid が含まれます。公式は 「常に最新 snapshot を使うこと」「screenshot より snapshot を優先すること」 を明記しています。 ([GitHub][2])

なぜ重要か

uid を得られる
クリックや入力など他ツールの前提になる
画像ではなく構造化テキストなので、AI が扱いやすい
Elements パネルで選択されている要素も示されます ([GitHub][2])

主な用途

操作対象の特定
DOM 状態確認
アクセシブルネーム確認
自動化の安定化

重要ポイント

verbose=true でフル a11y tree 情報を増やせる
filePath に保存も可能 ([GitHub][2])

実務での位置づけ
このツールはかなり中核です。
click、fill、hover、upload_file など多くの操作が uid を前提にするため、
まず take_snapshot で最新状態を取得する
という流れが基本になります。 ([GitHub][2])

実務でのおすすめ使い分け

1. UI 操作したいとき

まず take_snapshot
必要なら hover
click / fill / fill_form
状態確認に wait_for ([GitHub][2])

2. タブが増えるサイトを触るとき

list_pages
select_page
必要に応じて close_page ([GitHub][2])

3. API エラーを追いたいとき

list_network_requests
get_network_request
あわせて list_console_messages ([GitHub][2])

4. パフォーマンスを見たいとき

navigate_page
performance_start_trace
操作または reload
performance_stop_trace
必要に応じて performance_analyze_insight ([GitHub][2])

5. 見た目を確認したいとき

構造確認は take_snapshot
証跡保存は take_screenshot ([GitHub][2])

よく混同しやすいツール

`fill` と `type_text`

fill: 値を入れる
type_text: キーボードで打つ ([GitHub][2])

入力イベント依存の UI なら type_text が向くことがあります。

`resize_page` と `emulate`

resize_page: サイズ変更だけ
emulate: モバイル、UA、回線、CPU、位置情報まで再現 ([GitHub][2])

`take_screenshot` と `take_snapshot`

take_screenshot: 画像で記録
take_snapshot: 構造化テキストで要素把握、uid 取得
しかも公式は snapshot を優先推奨しています。 ([GitHub][2])

`lighthouse_audit` と `performance_start_trace`

lighthouse_audit: accessibility / SEO / best practices
performance_start_trace: performance / Core Web Vitals 調査 ([GitHub][2])

どのツールから覚えるべきか

最初に覚えるならこの順番がおすすめです。

take_snapshot
click
fill
wait_for
list_console_messages
take_screenshot
list_network_requests
get_network_request
performance_start_trace / performance_stop_trace ([GitHub][2])

理由はシンプルで、
「操作する」→「待つ」→「ログを見る」→「通信を見る」→「性能を見る」
の順で使う機会が多いからです。これは README の主な機能説明とも一致しています。 ([GitHub][1])

まとめ

chrome-devtools-mcp の価値は、単なるブラウザ自動操作ではありません。
Chrome DevTools の観測能力まで AI に渡せる のが本質です。 ([GitHub][1])

特に重要なのは次の 4 点です。

操作の起点は take_snapshot
ページ管理は list_pages / select_page
調査は list_console_messages と list_network_requests
性能は performance_start_trace 系で深掘れる ([GitHub][2])

Web アプリ開発では、
「画面を開いて」「操作して」「失敗した通信を見て」「console を確認して」「必要なら trace を取る」
という流れが非常に多いです。
chrome-devtools-mcp は、その一連の流れを AI エージェントからまとめて扱えるのが強力です。 ([GitHub][1])

参考リンク

公式リポジトリ README ([GitHub][3])
公式ツールリファレンス docs/tool-reference.md ([GitHub][2])

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Chrome DevTools MCP の全ツールをまとめて理解する

まず全体像

1. Input automation

click

drag

fill

fill_form

handle_dialog

hover

press_key

type_text

upload_file

2. Navigation automation

close_page

list_pages

navigate_page

new_page

select_page

wait_for

3. Emulation

emulate

resize_page

4. Performance

performance_analyze_insight

performance_start_trace

performance_stop_trace

take_memory_snapshot

5. Network

get_network_request

list_network_requests

6. Debugging

evaluate_script

get_console_message

lighthouse_audit

list_console_messages

take_screenshot

take_snapshot

実務でのおすすめ使い分け

1. UI 操作したいとき

2. タブが増えるサイトを触るとき

3. API エラーを追いたいとき

4. パフォーマンスを見たいとき

5. 見た目を確認したいとき

よく混同しやすいツール

fill と type_text

resize_page と emulate

take_screenshot と take_snapshot

lighthouse_audit と performance_start_trace

どのツールから覚えるべきか

まとめ

参考リンク

`click`

`drag`

`fill`

`fill_form`

`handle_dialog`

`hover`

`press_key`

`type_text`

`upload_file`

`close_page`

`list_pages`

`navigate_page`

`new_page`

`select_page`

`wait_for`

`emulate`

`resize_page`

`performance_analyze_insight`

`performance_start_trace`

`performance_stop_trace`

`take_memory_snapshot`

`get_network_request`

`list_network_requests`

`evaluate_script`

`get_console_message`

`lighthouse_audit`

`list_console_messages`

`take_screenshot`

`take_snapshot`

`fill` と `type_text`

`resize_page` と `emulate`

`take_screenshot` と `take_snapshot`

`lighthouse_audit` と `performance_start_trace`