2025年9月23日にchrome for developersの公式からDevTools MCPが発表されました。
Qiitaでもすでにいくつか記事になって話題になっています。
私自身、フロントエンドエンジニアを名乗ってはいるので開発において便利そうなものはしっかりと試していきたいと思い、試した結果を記事にしました。

Chrome DevTools MCPとは

コーディングエージェントには根本的な問題があります。生成したコードがブラウザで実行されたときに実際に何をするのかを確認できないことです。目隠しをしてプログラミングしているようなものです。
Chrome DevTools MCP サーバーはこれを変更します。AI コーディングアシスタントは、Chrome でウェブページを直接デバッグし、DevTools のデバッグ機能とパフォーマンス分析情報を活用できます。これにより、問題の特定と修正の精度が向上します。
*公式より引用

メインブラウザでChromeを使用している方は多いと思いますし、私自身もメインブラウザとして開発環境でも使っています。
このMCPを使えば、Chromeを通じてWebページのパフォーマンス改善やコンソールエラーの確認・原因調査などを行ってくれます。

できること

以下のような事ができます。
公式ページの内容を日本語訳しましたが、詳しい内容は公式のtool-reference.mdを確認してください。

入力操作
- click: 要素をクリック
- drag: 要素をドラッグ
- fill: テキスト入力
- fill_form: フォームへの一括入力
- handle_dialog: アラートやダイアログの操作
- hover: マウスオーバー
- upload_file: ファイルのアップロード
ナビゲーション
- Maps_page: ページの移動
- new_page: 新しいページの作成
- close_page: ページのクローズ
- list_pages: 開いているページの一覧表示
- select_page: ページの切り替え
- Maps_page_history: ページ履歴の移動
- wait_for: 特定の要素や条件が満たされるまで待機
エミュレーション
- emulate_cpu: CPU速度の調整
- emulate_network: ネットワーク速度の調整
- resize_page: ページのリサイズ
パフォーマンス
- performance_start_trace: パフォーマンス計測の開始
- performance_stop_trace: パフォーマンス計測の停止
- performance_analyze_insight: パフォーマンス分析結果の確認
ネットワーク
- list_network_requests: ネットワークリクエストの一覧表示
- get_network_request: 特定のリクエストの詳細取得
デバッグ

導入

導入方法も公式のGitHubに記載されています。
私はGemini CLIを使用しているので、公式に書いてあるとおりのコマンドを入力します(グローバルで使用したいので、以下のコマンドにしています）

gemini mcp add -s user chrome-devtools npx chrome-devtools-mcp@latest

Gemini CLIの設定ファイルの~/.gemini/settings.jsonを確認すると以下が追加されていました。

setting.json

"chrome-devtools": {
      "command": "npx",
       "args": [
         "chrome-devtools-mcp@latest"
      ]
}

実行する

設定は終わったので、実際に試してみます。

「https://qiita.com/
上記のWebサイトのLCPをチェックしてください」

とプロンプトを入力すると新たに検証用のChromeブラウザが立ち上がります。
Chromeのログイン情報などは引き継がれずに、あくまでも検証用としてのChromeブラウザのようです。

Chromeは自動テストソフトウェアによって制御されていますとページ上部に表示されているのが分かります。

実行したらperformance_start_traceが実行され、結果が出力されます。

次はスクリーンショットを撮ってもらいます。

「このページのスクリーンショットを撮ってください。スクリーンショットはDesktopに保存してください。」

実際に撮ってもらったのが以下の画像です。

問題なくできていそうです。
この後「モバイル時のスクリーンショットも撮って、desktopに保存してください」とプロンプトを投げたところ、実際のモバイルサイズ時のスクリーンショットも撮ってくれました。

では部分的に撮ってもらうのはどうなのか？
ヘッダー部分だけのスクリーンショットが欲しかったので、以下のようなプロンプトを投げてみました。

「idにGlobalHeader-react-componentの文字列が入っている箇所だけをスクリーンショットに撮ることはできますか？」

結論から言うとダメでした。

スクリーンショットの文字が小さいので以下に書きおこしました。

お待たせいたしました。idにGlobalHeader-react-componentを含む要素を見つけました。
これはヘッダー全体を囲む要素のようです。
しかし、この要素を直接スクリーンショットとして撮影することができませんでした。
私が使用しているツールでは、この要素が単一の撮影可能な要素として認識されないためです。
つきましては、大変恐縮ですが、以前ご提案させていただいた以下のいずれかの方法で対応させていただけますでしょうか。

1. ヘッダーに含まれる特定の要素（例：「Qiitaロゴ」、「検索バー」）のスクリーンショットを撮る。
2. ページ全体のスクリーンショットを撮り、ご自身でヘッダー部分を切り抜いていただく。

どちらの方法がよろしいでしょうか？

いや、ChromeにはCapture Node ScreenShotというものがあるはずでは？と思いプロンプトを投げ直してみました。

「idがGlobalHeader-react-componentの文字列が入っている箇所をCapture Node ScreenShotとして撮ることはできますか？」

以下AIの回答。

「Capture Node Screenshot」は、特定の要素（ノード）のスクリーンショットを撮影する機能ですね。
私が使用しているtake_screenshotツールも、uidを指定することで同様の機能を提供します。

しかし、以前お伝えした通り、idにGlobalHeader-react-componentを含む要素は、
ページの複数の要素をまとめているコンテナであり、私のツールでは単一の要素として認識できず、
uidを取得することができません。
そのため、この要素を直接「Capture Node Screenshot」として撮影することは困難です。

大変恐縮ですが、ヘッダー全体のスクリーンショットをご希望の場合は、
ページ全体のスクリーンショットを撮影し、必要な部分を切り抜いていただく方法が最善となります。

もし、ヘッダー内の特定の要素（ロゴや検索バーなど）のスクリーンショットでもよろしければ、
再度ご指定ください。

さらに食い下がります。

「ではuidを取得できるようにするためにはどうすればよいですか？」

以下AIの回答

ご質問ありがとうございます。uidは、私がページの内容を把握するために
take_snapshotというツールを実行した際に、ページ内の主要な要素に対して自動的に割り当てられる
一意のIDです。

このuidの割り当てはツールの内部的な処理によるもので、私やユーザーが特定の要素にuidを任意に付与したり、
変更したりすることはできません。

今回の場合、idにGlobalHeader-react-componentを含む要素は、ページのレイアウトを構成するための
コンテナ（複数の要素をまとめる箱）のような役割を果たしており、take_snapshotツールがuidを
割り当てる対象の「主要な要素」とは見なされなかったため、uidが付与されていない状況です。

そのため、この要素をuidを使って直接指定することはできず、
スクリーンショットの撮影ができない、という状況です。

ご理解いただけましたでしょうか。

AIに諭されました。
全体のスクリーンショットは可能だけど部分的には無理な様です。

パフォーマンスは計測してくれましたが、アクセシビリティに関してはどうでしょう？

「このサイトはWebアクセシビリティに準拠していない箇所はありますか？」

以下AIの回答

はい、追加のチェックが完了しました。結果は以下の通りです。

1. 代替テキストのない画像 (alt属性)

3枚の画像にalt属性がありませんでした。これらは主にトラッキング用の非表示画像のようですが、
スクリーンリーダーのユーザーに不要な情報を与えないためにも、alt=""のように空のalt属性を
設定することが推奨されます。

2. テキストのないリンク

多くのリンクがテキストを持たないように見えましたが、詳しく調べると、ほとんどのリンクは
内部にalt属性を持つ画像を含んでおり、これはアクセシビリティの観点からは問題ありません。
しかし、一部のリンクは、スクリーンリーダーのユーザーがリンクの目的を理解するのが
難しい可能性があります。

3. ラベルのない入力フィールド

検索入力フィールドに、関連付けられた<label>がありませんでした。
placeholder属性（「記事、質問を検索」）が設定されていますが、スクリーンリーダーのユーザーにとっては、
<label>があった方がより明確になります。

まとめ

全体として、このサイトは多くのアクセシビリティプラクティスに従っていますが、
上記のように、画像のalt属性、一部のリンク、入力フィールドのラベルについては改善の余地があります。

アクセシビリティチェックもしてくれそうですね。

感想

いくつか試してみましたが、パフォーマンスやアクセシビリティ、コンソールエラーの原因の調査など、このMCP一つで色々と賄えそうな印象がありました。
実際のコーディングに関してもこういったMCPを使用することによって、より便利になりそうな気がしています。

参考