コーディングエージェントにバグを相談するとき、正直ちょっとした手間がありますよね。
コンソールに出ているエラーをコピーして、ネットワークタブのレスポンスをテキストに書き起こして、DOMのどこが崩れているかを言葉で説明して——そうやって「ブラウザで見えていること」を自分でテキストに変換してから渡している。
エージェントはコードしか見えていないので、ブラウザの実際の状態を知るすべがないんです。
chrome-devtools-mcp は、その「自分でDevToolsを開いて確認する」フェーズをエージェントに肩代わりさせるためのブリッジです。
DOM・ネットワーク・コンソール・パフォーマンスという観察系の情報を、エージェントが直接読めるようにする仕組みです。
GoogleのChromeチームが開発していて、2025年9月にパブリックプレビューが始まりました。
Addy Osmaniが「AIにブラウザの目を与える」と表現していたのが、個人的にはいちばんしっくりきます。
AIエージェントにDevToolsを「見せる」という発想
エージェントにデバッグを手伝ってもらうとき、今の典型的な流れはこうです。
ブラウザでバグを再現して、DevToolsを開いてコンソールエラーを確認して、ネットワークタブで怪しいリクエストを探して、それをコピーしてチャットに貼り付ける。
この流れ、別に苦ではないんですが、「ブラウザで見えていることをテキストに変換する」という作業が地味に挟まっています。
エラーが複数あったり、ネットワークリクエストが多かったりすると、どれを貼るべきかの判断も必要になる。
つまり、エージェントに渡す前の「観察・整理」フェーズを、ずっと自分でやっているわけです。
chrome-devtools-mcp はそこを変えます。
エージェントが直接、今開いているChromeのDevToolsにアクセスできるようになります。
コンソールに何が出ているか、どのAPIコールが失敗しているか、DOMがどういう構造になっているか——それをエージェント自身が読みにいける。
「エラーを教えて」ではなく「自分でDevToolsを見て診断して」と頼める、というのが本質的な変化です。
一言で言えば「エージェントとDevToolsをつなぐブリッジ」です。
Anthropicが2024年末に公開したModel Context Protocolという標準規格の上に乗っていて、chrome-devtools-mcpはそのサーバー実装のひとつ、という位置づけです。
エージェント側から見ると、DevToolsが「呼び出せるツール群」として見えるようになる、というイメージです。
「操作する」ツールと「診る」ツールは別物
Playwright MCPやBrowserbaseのようなツールも、エージェントとブラウザをつなぐという点では似ています。
ただ、目的がかなり違います。
Playwright MCPは「エージェントがブラウザを動かす」ための仕組みです。
クリック・フォーム入力・ページ遷移・スクリーンショット撮影——テストシナリオを走らせたり、繰り返し操作を自動化したりするのが得意な領域です。
Chrome以外のブラウザ（Firefox・WebKit）にも対応していて、クロスブラウザのE2Eテストを回したい場面では有力な選択肢です。
chrome-devtools-mcp は逆で、「今ブラウザで起きていることを読む」ための仕組みです。
既存のChromeセッションに接続して、状態を観察・診断することに特化しています。
ブラウザを動かすのではなく、今の状態を診る。
データの取り方にも差があります。
Playwright MCPはアクセシビリティツリーのスナップショットを使ってUIのセマンティクスを読み取るアプローチです。
chrome-devtools-mcpはDevToolsプロトコルに直接話しかけるので、コンソールログ・ネットワークリクエストの詳細・パフォーマンストレースといった低レイヤーの情報にアクセスできます。
「UIとして何が見えているか」ではなく「ブラウザの中で何が起きているか」を知りたいときに強い理由はここにあります。
得意な場面を並べると、違いがはっきりします。
操作・自動化系（Playwright MCPなど）が向く場面：
- E2Eテストのシナリオを自動実行したい
- フォーム入力・ボタンクリックをエージェントに代行させたい
- Chrome以外のブラウザでも動かしたい
観察・診断系（chrome-devtools-mcp）が向く場面：
- 再現手順は決まっていて、その状態を詳しく診断したい
- コンソールエラー・ネットワークログ・DOM構造をエージェントに読ませたい
- パフォーマンストレースを取ってボトルネックを特定したい
「再現はできている、原因がわからない」という場面にはchrome-devtools-mcpが向いて、「この操作を自動化したい」という場面にはPlaywright MCPが向く、という使い分けです。
セットアップ：npx一行からClaudeに繋ぐまで
前提として、Chromeを リモートデバッグポートつき で起動する必要があります。
chrome-devtools-mcpはこのポートを通じてDevToolsに接続するので、通常の起動では動きません。
まずChromeを以下のコマンドで起動します。
# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
# Linux
google-chrome --remote-debugging-port=9222
# Windows（PowerShell）
& "C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222
Chromeを先に起動してからMCPサーバーを立ち上げる、という順序が重要です。
逆にすると接続先がなくてエラーになります。
ここがいちばんつまずきやすいポイントです。
MCPサーバー自体はnpxで起動できます。
インストール不要で、以下の一行で動きます。
npx -y chrome-devtools-mcp@latest
ClaudeやCursorなどのエージェントから使うには、mcpServersの設定を追加します。
Claude Desktopの場合は claude_desktop_config.json に、Cursorの場合は .cursor/mcp.json に、以下を追記します。
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest"]
}
}
}
設定を保存してエージェントを再起動すると、chrome-devtools-mcpのツール群が使えるようになります。
動作確認は公式ドキュメントにある以下のプロンプトが手っ取り早いです。
Check the performance of https://example.com
エージェントがブラウザを開いてパフォーマンストレースを記録し、結果を返してきます。
ここまで動けばセットアップは完了です。
チームで使う場合は、この設定ファイルをリポジトリにコミットしておくと、メンバーが環境を作るときに手間が省けます。
3つのユースケース：エージェントに何を聞いて、何が返ってくるか
① レイアウト崩れの特定（DOM検査）
ボタンが消えている、要素が重なっている——そういうレイアウト崩れの原因を調べるとき、従来はElementsパネルで地道に掘っていくしかありませんでした。
特定の画面サイズでだけ崩れる、特定のデータが入ったときだけ崩れる、といったケースだと、再現してから該当要素を探してCSSを確認して……という手順が毎回発生します。
右上の「送信」ボタンが表示されていない。
DOMを確認して、ボタンが存在するかどうか、CSSで非表示になっていないかを調べて。
このプロンプトを受けたエージェントは、get_dom_snapshot などのツールを呼び出してDOM全体のスナップショットを取得します。
該当要素の display や visibility の値、親要素の overflow 設定、z-index の重なりなどを確認して、「このクラスに display: none が当たっています」「親の overflow: hidden で切れています」といった診断を返してくれます。
「どの要素を疑うか」の当たりをつけるのが難しいケースほど、エージェントに丸ごと渡してしまったほうが早いことが多いです。
② APIレスポンス確認（ネットワークタブ）
データが表示されない、フォームの送信が失敗する——そういうときはネットワークタブを開いてリクエストを確認するのが定番ですよね。
リクエストが多いページだと、該当のAPIコールを探すだけでも地味に時間がかかります。
直近のAPIコールの一覧を見せて。
特に /api/users へのリクエストがあれば、そのステータスコードとレスポンスボディを教えて。
エージェントは get_network_requests などのツールでネットワークログを取得して、該当するリクエストを絞り込みます。
「ステータス401が返っています。レスポンスボディには認証エラーのメッセージが含まれています」といった形で、フィルタリングと読み取りをまとめてやってくれます。
さらに「このエラーの原因と修正案を出して」と続ければ、コードの修正提案まで一気に進められます。
ネットワークタブを自分で開いて確認する作業と、その結果をエージェントに説明する作業、両方が省けるわけです。
③ コンソールエラーの一括診断
ページを開いたらコンソールに赤いエラーが複数出ている、でも全部が重要なわけでもない——そういう状況はよくあります。
どのエラーが今の症状に関係していて、どれが無視してよいノイズなのかを仕分けるのが、意外と面倒です。
コンソールに出ているエラーと警告を全部拾って、それぞれの原因と修正案を出して。
エージェントは list_console_messages を呼び出して、エラー・警告・情報ログを種別ごとに取得します。
単純にログを列挙するだけでなく、DOM構造やネットワークの状態と照らし合わせながら優先度をつけて診断してくれます。
特に、引き継いだコードベースや久しぶりに触るプロジェクトで、コンソールが散らかっている状態から始めるとき、この使い方は重宝します。
使いどころの判断と、現時点での限界
いちばん向いているのは「再現手順が決まっていて、その状態を診断したい」場面です。
バグが再現できている、でも原因がわからない——そこにchrome-devtools-mcpを差し込むと、観察フェーズをエージェントに丸投げできます。
冒頭で話した「ブラウザで見えていることをテキストに変換する」という手間が、ここで消えます。
一方で、制約もあります。
認証が必要なページ については、ログイン操作そのものはエージェントに任せられません。
自分でブラウザを操作してログインした状態を作ってから、そのセッションをエージェントに渡す、という手順になります。
chrome-devtools-mcpは既存セッションに接続する仕組みなので、ログイン後の状態を観察すること自体は問題なくできます。
「制約」というより「使い方の前提」として覚えておくと混乱しません。
もうひとつは 動的なインタラクション途中の状態 の観察です。
ドラッグ操作の途中・アニメーション実行中・ホバー時だけ現れる要素——こういった「一瞬しか存在しない状態」の捕捉は苦手です。
こういう場面は今のところ自分でDevToolsを操作するしかありません。
実用上もうひとつ気にしておきたいのが、トークンコストの問題です。
MCPサーバーを複数接続すると、ツール定義だけで数万トークンを消費することがあります。
chrome-devtools-mcpを常時接続しておくより、デバッグが必要な場面でだけ有効にする使い方のほうが現実的かもしれません。
日常のデバッグフローで言えば、「再現→観察→仮説→修正」という流れの 「観察」フェーズを担うツール として位置づけるのが正確です。
修正コードを書くのはエージェントの別の能力、再現手順を自動化するのはPlaywright MCPの領域——それぞれ役割が分かれていて、chrome-devtools-mcpはその間の「診断」を担います。
まずは手元のプロジェクトでコンソールエラーの一括診断から試してみると、どういう場面で使えるかの感覚がつかめるはずです。
株式会社ホコサキは、山口県宇部を拠点にWeb制作・業務システム開発・AI活用支援を手がけています。
chrome-devtools-mcpのような開発ツールの導入から、日常のエンジニアリングワークフローへの組み込みまで、実務に即した形でサポートしています。
ご相談は お問い合わせページ からどうぞ。