← 記事一覧
Chrome DevTools MCPで画面・通信・ログを照合するという、確認項目を整理した図解
確認する情報を整理した編集図版。操作画面や実験結果を描いたものではありません。
ツールと環境公式文書・バージョン固定の公開ソース・利用者の不具合報告の照合

Chrome DevTools MCPで「直った」を確かめる。画面・通信・ログを残す手順

AIが直したWeb画面を、見た目だけで完成にしていませんか。Chrome DevTools MCPで同じ操作のスクリーンショット・通信・コンソールを確認し、修正前後の証拠を残す手順を整理します。

AIがWeb画面を修正したら、同じURL・画面幅・操作でやり直し、見た目、失敗した通信、コンソールエラーを一緒に確認しよう。Chrome DevTools MCPを使うと、この三つをコーディングエージェントから調べられる。先に「何ができれば直ったと言えるか」を決めておくと、修正の前後を比べやすい。

この記事では、開発中のサイトで「スマホ幅のメニューを開くと表示がおかしい」という場面を例に、検証の頼み方を整理する。公式文書と公開報告に基づく手順案で、編集部によるMCP接続・修正実験は行っていない。

まずテスト用のChromeに接続する

Chrome DevTools MCPは、現在「Chrome DevTools for agents」の一部として案内されている。MCPは、AIにブラウザーなどの道具を接続するための仕組みだ。利用にはMCP対応のエージェント、Node.jsの現行LTSとnpm、安定版Chromeを用意する。日本語の公式導入ガイド

Chrome for Developers公式:Chrome DevTools for agentsの導入(2026年4月23日、英語、3分20秒から)出典:Chrome for Developers(公式YouTube)

動画:Chrome for Developers「How to set up Chrome DevTools for agents」(2026年4月23日、英語)。3分20秒から導入、3分58秒から設定ファイルの説明。再生できない場合はYouTubeで見る。

初回は、個人用のログイン状態を持ち込まない

まずは自分で管理するローカル環境や検証用サイトを使う。日常用Chromeのメールや管理画面を丸ごと接続する必要はない。標準では別のChromeを起動でき、--isolatedを指定すれば、終了時に片付けられる一時プロファイルを使える。プロファイルはCookieなどのブラウザー情報を保存する場所だ。

mcpServers形式の設定を使うクライアントでは、次のように登録する。すでに同名の接続がある場合は重複を作らず、設定を確認してから変更する。

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@1.10.1",
        "--isolated",
        "--redact-network-headers",
        "--usage-statistics=false",
        "--performance-crux=false"
      ]
    }
  }
}

ここでは確認時の最新リリースである1.10.1に版を固定した。更新するときは変更履歴を読み、設定も確認し直す。設定ファイルの場所やMCPの再読み込み方法はクライアントごとに異なる。1.10.1のリリース(英語)

追加した設定は、一時プロファイルの使用、一部の機密ヘッダーの伏せ字化、利用統計の停止、性能トレースのURLをCrUX APIへ送る機能の停止を指定している。AIクライアント自体へのデータ送信を止める設定ではない。テスト用のデータだけを使うことが前提になる。1.10.1の設定一覧(英語)

伏せ字の範囲にも注意したい。2026年9月15日のIssue #2752で、yogurtearl氏はヘッダー以外のURLや本文にも秘密情報が入り得ると指摘し、開発側も追加対応を議論している。確認時はOpenで、全面的な自動除去が保証された状態ではない。実アカウントのCookie、認証情報、顧客データを含む通信を、気軽にAIへ読ませないようにしたい。利用者の提案と開発側の回答(英語)

ツールの登録と、ブラウザーへの接続を別々に確かめる

最初の依頼は「テスト用URLを開き、ページタイトルと現在のURLだけ返してください」で十分だ。エージェントがMCPを認識していることに加え、実際にChromeのページへ接続できたかを確かめる。

ログイン済みの状態でしか再現しない問題なら、Chrome 144以降の--autoConnectも選べる。ただし、接続先プロファイルのタブやCookieなどをエージェントが扱える。使う範囲を決め、chrome://inspect/#remote-debuggingの設定と接続時の許可内容を読んでから使おう。既存セッションへの接続

接続待ちで止まる場合は、許可ダイアログも見る。expiren氏は2026年9月19日、Windows 11・Chrome 153・MCP 1.9.0・OpenCodeなどの組み合わせで、最初のツール呼び出しが許可待ちの間にタイムアウトする現象を報告した。10月5日には開発側の参加者も、許可未完了で60秒後にタイムアウトすることを確認している。すべての環境で起きるとは扱わず、接続先、MCP版、クライアント、許可画面の状態を添えて調べたい。Issue #2778(英語)

画面・通信・ログを、同じ操作の証拠として残す

Chrome for Developers公式:ブラウザー操作・端末条件・Lighthouseの実演解説(2026年5月22日、英語)出典:Chrome for Developers(公式YouTube)

動画:Chrome for Developers「Supercharge your AI coding workflow with Chrome DevTools for agents」(2026年5月22日、英語)。ブラウザー操作、端末条件の再現、Lighthouse監査を扱うGoogle I/Oの実演解説。YouTubeで見る

最初から「全部直して」と頼むより、まず一つの症状を再現させる。以下は自分のURLと実際のメニュー名に置き換えて使う依頼例だ。画面幅は今回の確認条件であり、すべてのサイトの推奨値ではない。

テスト用URLを開き、画面幅390px・高さ844pxで確認してください。初期表示のスクリーンショットを残し、メニューボタンを開いて、予定している5項目が読めるか、閉じる操作ができるかを確認してください。初期表示と操作後それぞれの通信エラーとコンソールエラーを記録し、観測した事実と原因の推測を分けて報告してください。コードはまだ変更しないでください。

1.URLと画面の条件を記録する

対象タブを特定し、URL、画面幅と高さ、ログインの有無、再現手順をそろえる。PC幅も確認するなら、例えば1280pxで同じ操作を行う。

端末のエミュレーションは、画面幅やタッチ操作などの条件を再現する機能だ。Chrome上でiPhone相当の条件を使っても、Safariのエンジンで試したことにはならない。Safari固有の不具合が疑われるときは、そのブラウザーで別に確認する。公式のエミュレーション説明

2.操作対象と、操作後の見た目を分けて見る

エージェントはtake_snapshotで、ボタン名などのページ構造と操作対象のIDを取得できる。一方、重なり、欠け、文字の読みにくさを見るにはtake_screenshotの画像も必要になる。メニューを開く前後の画像を同じサイズで残し、人も見比べよう。

「ボタンをクリックできた」だけでは、メニュー項目が読めるか、画面の外へはみ出していないかまでは分からない。何を確認する画像なのか、保存時に「初期表示」「メニュー展開後」と名前を付けておくと追いやすい。

3.別ページへ移る前に、通信とログを取る

list_network_requestsとlist_console_messagesで、その操作中の通信とログを確認する。必要な通信だけを選んでget_network_requestで詳細を調べる。標準の一覧は直近のページ移動以降が対象なので、問題を再現したら別ページへ進む前に記録する。過去3回分のページ移動を含める設定もある。ツール仕様(英語)

例えば、項目が空なのにメニュー自体は開くなら、データ取得の通信が失敗していないかを見る。通信に異常がなく、項目も存在しているのに読めないなら、重なりや色など表示側を調べる。この切り分けは調査の順番であり、通信の成功だけで機能全体を合格にするものではない。

ネットワーク用のツールが見つからないときは、起動引数に--slimが入っていないか確認する。slimはナビゲーション・スクリプト実行・スクリーンショットの3種類に絞る設定なので、今回の通信・ログ調査には通常の構成を使う。

修正後は、同じ確認をもう一度行う

原因と修正案を確認してからコードを直し、同じURL、画面幅、操作で検証を繰り返す。修正前の画像やログを上書きせず、前後が分かる名前で保存する。保存エラーが出たら、返された保存先やMCPの許可済みフォルダーを確認し、ファイルが作られたことまで確かめよう。

最終報告は、次の内容があればレビューしやすい。

  • 確認したURL、画面幅、ChromeとMCPの版
  • メニューを開く・閉じるなど、実際に試した操作
  • 予定した項目が読めるか、修正前後の画像
  • 関連する通信とコンソールエラーの有無
  • まだ試していない画面幅やブラウザー、残っている問題

Lighthouseを追加する場合も、目的を絞りたい。このMCPのlighthouse_auditではアクセシビリティ、SEO、ベストプラクティスなどを調べ、性能評価はperformance_start_traceで別に行う。画面の操作が成功すること、監査で指摘がないこと、速度が改善したことは、それぞれ別に確認する。Lighthouseの公式案内

大切なのは、「直しました」という返答から、どの条件で、何を見て直ったと判断したのかまでたどれることだ。一つの不具合でも、この形で記録を残すと、次の変更で再発したときに比較しやすくなる。

調査方法

確認日:2026年10月12日JST。公式導入ガイド、1.10.1の設定・ツール仕様、公式動画、GitHub上の本人による報告を照合した。本文の依頼例と確認順は編集部の提案で、実行結果ではない。利用者報告は記載された環境の事例として扱い、成功率や性能差には換算していない。

情報源について

← 記事一覧に戻る