Claude Code + Chrome DevTools MCP：AI にブラウザを本当に見せる

何が解き放たれるか

エラーを貼り付けてもらうのを待つのではなく、agent 自身が動いているブラウザを読むためのコネクタです。

1. 1

   Google 自身の解説から始める

   developers.chrome.com の記事が最短の入門です。このサーバーが何か、なぜ重要か、何を読めるのかを説明しています。隣の Performance パネルがその価値そのものです——Largest Contentful Paint 0.98 s は良好、Cumulative Layout Shift 0.29 は不良で、まさに agent が自分で読めるようになった数値です。記事の性能 prompt は 'Localhost:8080 is loading slowly. Make it load faster.' です。

   

2. 2

   設定を貼り、スモークテストを走らせる

   同じ記事が、クライアント設定ファイルにそのまま貼れる mcpServers ブロックと、1 行のスモークテスト——'Please check the LCP of web.dev.'——を公開しています。最初の確認にちょうどよく、実在のページの LCP を測れるならブラウザ接続は生きています。

   

3. 3

   3 つの前提を確認する

   README の Requirements は短いです。Node.js v20.19 以降の latest maintenance LTS、Chrome の現行安定版、そして npm。ほかに入れるものはありません——MCP クライアントが起動時に npx 経由でサーバーを取得します。

   

Claude Code に導入する

README の 1 行か、エディタ側の追加手順か——そのあとツールを起動するエントリを確認します。

1. 4

   Claude Code のインストール 1 行

   README の MCP Client configuration には Claude Code の項目があり、コマンドは明快です——claude mcp add chrome-devtools npx chrome-devtools-mcp@latest。1 回実行すればそのスコープにサーバーが登録され、JSON を手で編集する必要はありません。

   

2. 5

   エディタ側から追加する

   Claude Code CLI ではなく VS Code の中で作業するなら、VS Code の MCP ドキュメントに複数の登録方法があります。動画が勧めるのはそのうち 2 つ、コマンドラインとユーザー設定ファイルだけです。コマンドライン側が code --add-mcp の例で、引用符の扱いに非常に敏感です。

   

3. 6

   26 のツールを起動するエントリ

   最初の試行は失敗しました——JSON 内の二重引用符をエスケープする必要があったためです。成功するとターミナルは 'Added MCP servers: chrome-devtools' と表示し、ユーザーの mcp.json に chrome-devtools エントリが追加され、npx で chrome-devtools-mcp@latest を実行します。起動後は 'Start | 26 tools' と注記されます。

   

ツールの範囲

26 のツールが実際に何をカバーするのか、agent 自身のグループ分けで見ます。

1. 7

   ナビゲーションとページ管理

   VS Code を再起動すると、agent がツールを用途別に列挙します。Navigation and Page Management には navigate_page、navigate_page_history、new_page、list_pages、select_page、close_page、resize_page。Page Interaction には click、fill、fill_form、hover、drag、upload_file、handle_dialog、wait_for。この半分が、agent に実際のタブを操作させる力です。

   

2. 8

   分析、console、ネットワーク

   一覧の残り半分は診断用です。Page Analysis には take_snapshot、take_screenshot、evaluate_script、list_console_messages、list_network_requests が入ります。最後の 2 つが「これがエラーです」を「これは agent 自身が取得した証拠です」に変える鍵です。

   

壊れたページをこれでデバッグする

中身が欠けたローカルページを、手作業のコピペなしで 2 つの具体的な失敗まで特定します。

1. 9

   見て分かる壊れたページから始める

   題材はローカルの Add Employee ページです。左のナビゲーションに画像の読み込み失敗アイコンが出て、Name、Department、Email の各フィールドは空のまま——見れば分かる異常で、これまでは console の出力をチャットに貼るしかなかった状況そのものです。

   

2. 10

   根本原因を尋ね、ツールを承認する

   prompt はあえて素っ気なく、ファイルパスと「根本原因を」という一言だけ。すると agent はすぐに new_page ツールの実行許可を求め、対象は file:///E:/Development/RESTApi-main/frontend/add.html です。承認すると本物の Chrome が開き、自分でそこへ遷移し、続けて list_console_messages と list_network_requests を連鎖させます。

   

3. 11

   6 件のリクエスト、名指しされた 2 つの失敗

   list_network_requests はそのページの 6 件のリクエストを返し、agent は 2 つの主要な問題を報告します。images/logo2.svg が net::ERR_FILE_NOT_FOUND、http://localhost:5000/api/employees が net::ERR_CONNECTION_REFUSED です。提示される修正も具体的で、logo.svg を logo2.svg に改名するか HTML 側を logo.svg に向けること、そして .NET の EmployeeApi プロジェクトを起動することです。

   

4. 12

   同じ証拠が自分の DevTools にある

   agent の記録に手入力された行は 1 つもありません。Chrome 自身の Application と Console パネルを並べると、内容は 1 行ずつ一致します。logo2.svg と localhost:5000/api/employees にそれぞれ Failed to load resource が出て、Console の issue は 2 件です。agent が読んだのはブラウザで、同じ証拠をあなた自身が確認できます。

   

5. 13

   Network パネルが 2 つの失敗を裏づける

   Network パネルがループを閉じます。6 件のうち add.html、styles.css、avatar2.svg、app.js は 200 を返し、logo2.svg と employees の fetch は失敗として表示されます——6 requests、7.5 kB transferred、Finish 2.34 s。隣には agent の診断があり、「エラーを取得 → 修正 → 再テスト」というフィードバックループ、それこそが以前欠けていた部分です。

   

関連する Claude Code ガイド