もう DevTools のログを AI に貼らなくていい ― MCP + Chrome DevTools 入門

開発

傳知輝

公開日:2026/06/15

読了目安:約5分

MCP + Chrome DevTools で、Web アプリ開発の調査フローを会話ベースに変える

Web アプリのデバッグで一番時間を食うのは、コードを書くことではありません。
「裏で何が起きているか」を読み解くことです。そして実は、そこが今いちばん AI に任せやすい領域になりました。

例えば、こんな場面です。

保存ボタンを押したとき、どの API が呼ばれているのか分からない
一見同じように見える request が何本も流れていて、本命がどれか分からない
Console に warning や error が出ているが、どこから手をつければよいか分からない
AI に相談したいが、結局 DevTools を人間が読んでログを貼る必要がある

この「調査して、理解して、共有する」部分は、開発の中でもかなり手間がかかる作業です。
しかも厄介なのは、ここが単なる作業ではなく、 観測・解釈・仮説立て を同時に要求することです。

最近、この部分の進め方がかなり変わりました。
きっかけは、 MCP を通して AI が Chrome DevTools を直接見られるようにしたこと です。

この記事では、MCP + DevTools を使うことで、

何が変わるのか
どんな場面で便利なのか
どうやって導入するのか

を紹介します。

なぜ DevTools の調査は面倒なのか

Chrome DevTools 自体は昔から非常に強力です。
Network タブも Console も、Web アプリ開発には欠かせません。

ただ、現場で本当に大変なのは「ツールが弱いこと」ではなく、 人間がその出力を読み解くコスト です。

典型的な流れを整理すると、こうなります。

Chrome DevTools を開く
Network を眺める
怪しそうな request を開く
header / payload / response を読む
外れだったら次を見る
ある程度分かったら AI やチームメンバーに共有する
共有内容をもとに実装を直す
もう一度 DevTools に戻って確認する

これが単純な画面ならまだ良いですが、実際の業務アプリや SaaS はそう簡単ではありません。

request の数が多い
ログイン状態や権限で挙動が変わる
iframe や別ドメインをまたいでいる
テレメトリや設定 API のようなノイズが大量に流れている
API 名や payload の構造を読むのにドメイン知識が必要

つまり、人が頑張れば DevTools を読み解くことはできても、 それを毎回繰り返すのはかなり非効率 です。

MCP を使うと何が変わるのか

MCP を使うと、AI がブラウザや DevTools と接続できるようになります。
今回の文脈では、 AI が Chrome DevTools の観測対象に直接触れられる というのが一番大きなポイントです。

イメージとしては、これまで

人が観測する
人が要約する
AI に渡す

だった流れが、

AI が観測する
AI が候補を絞る
AI が仮説を立てる
AI がそのまま実装まで進める

に変わる、ということです。

ここで重要なのは、MCP が単なる「操作自動化」ではないことです。
本質は、 観測の共有コストを下げること にあります。

例えば、

「Console でこの文字列を検索して」
「Network でこの request を探して」
「この response の構造を見て」
「いま見えているログが古いものか最新のものか切り分けて」

といった指示を、会話だけで渡せます。

これによって、AI とのやり取りが推測ベースではなく、 観測ベース に変わります。

実際に便利だったポイント

実際に使ってみて便利だったのは、単に「AI が見てくれる」ことではありません。
調査の流れそのものが短くなった ことです。

例えば、ある画面でデータ取得の流れを追いたいとします。
従来なら、人が DevTools の Network を眺めて、候補 request を何本も開いては閉じてを繰り返します。

MCP + DevTools だと、これを次のように進められます。

AI に「本命の取得 API を探して」と依頼する
AI が Network 候補を絞る
AI が「これは設定 API」「これはテレメトリ」と外れを切る
AI が request body と response body を見る
AI が「必要な field はこれ」とまとめる
そのままコード修正に進む

この一連の流れが会話で繋がっているのが大きいです。

便利だったポイントをもう少し具体的に書くと、次のようになります。

1. Console の検索を AI に任せられる

Console に大量のログが出ているとき、人が 1 つずつ読むのは大変です。
MCP があると、AI に

特定のログ文字列を探させる
出ている回数を確認させる
直近の出現タイミングを見る

といったことを頼めます。

これだけでも、かなり時短になります。

2. Network のノイズ除去が速い

本当に辛いのは、候補 request が多い場面です。
設定取得、feature flag、telemetry、session keepalive のような request が大量に流れていると、目視で本命を掘るのはかなり疲れます。

AI に「calendar を含むものを優先」「設定系は除外」「iframe 側も見て」といった方針を与えると、かなり早く探索できます。

3. request / response の構造把握が速い

DevTools を見ながら、

この field が title
この field が event id
この field が time range

といった整理を、そのまま AI に任せられるのは大きいです。

人が JSON を眺めて説明する手間が減ります。

4. 調査結果をそのまま修正に接続できる

これはかなり重要です。
観測と修正が分断されていないので、

「この response の構造に合わせて parser を直す」
「この request の仕様が分かったので polling できる」
「この field を title に使う」

といった修正を、観測結果の直後に進められます。

どういう場面で特に効果が高いか

MCP + DevTools は何でも万能に解決するわけではありません。
ただ、ブラウザ観測が本質の課題にはかなり強いです。

特に向いているのは次のようなケースです。

Web アプリの保存処理や取得処理を追いたいとき

「このボタンを押すと何が呼ばれるのか」を知りたいとき、Network を AI と一緒に追えるのは非常に便利です。

既存 SaaS の挙動を調査したいとき

管理画面やダッシュボード系のアプリでは、見た目より裏側の通信が複雑なことが多いです。
このときに DevTools を会話の中へ持ち込めるのは強いです。

iframe や複数ドメインが絡むとき

現代の Web アプリでは、親ページの中で別のドメインのアプリが動いていることも珍しくありません。
このとき、人が「どこを見ればいいか」で迷う時間が長くなります。
AI に探索を任せる価値が高いです。

調査しながら修正まで進めたいとき

単に「原因を知る」だけでなく、その場でコードを直したいケースでは特に有効です。
観測、仮説、修正、再確認のループが短くなります。

逆に、どんな場面では向かないか

逆に、MCP + DevTools があまり主役にならない場面もあります。

ブラウザの外で完結する処理
ネイティブアプリ内部の通信
サーバーの内部状態が本質の問題
そもそも request / response がブラウザに出てこない処理

こうしたケースでは、DevTools を見ても得られる情報が少ないので、別の手段を取った方が早いこともあります。

つまり、 「ブラウザの通信やログを観測する必要があるか」 が、使いどころを見極める一番分かりやすい基準です。

開発フローがどう変わるか

個人的に一番大きいのは、AI とのやり取りが「相談」から「共同観測」に変わることです。

これまでの AI 活用は、

人が状況を要約する
AI が推測ベースで提案する

ことが多かったと思います。

MCP + DevTools を使うと、

AI が実際の Console / Network を見る
人と同じ画面情報を持つ
その上で提案する

という形になります。

この違いはかなり大きいです。

なぜなら、開発で厄介な問題の多くは、 情報不足のまま仮説を立てて外すこと だからです。
観測対象を直接見られるだけで、仮説の精度が上がります。

さらに、会話ログそのものが調査ログになるのも便利です。

何を外れと判断したか
なぜその request を本命と見たか
どの field を title と解釈したか

がそのまま残ります。

これは個人開発でも便利ですが、チーム開発だとさらに効きます。

導入方法（Claude / Codex / Cursor）

ここまで読んで「試してみたい」と思ったら、導入はとても簡単です。
使うのは、Chrome DevTools チームが公式に提供している MCP サーバー chrome-devtools-mcp です。
どのツールでも、内部的には次のコマンドでサーバーを起動しているだけです。

npx -y chrome-devtools-mcp@latest

事前準備

Node.js（LTS 版） がインストールされていること
Chrome（stable 以降） がインストールされていること

この 2 つが揃っていれば、別途インストール作業は不要です。npx が初回実行時にサーバー本体を自動で取得します。

Claude（Claude Code）

ターミナルで次の 1 行を実行するだけです。

claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

--scope user を付けると、すべてのプロジェクトから使えるようになります。追加後は /mcp で接続状態を確認できます。

Codex（Codex CLI）

こちらもコマンド 1 行で追加できます。

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest

Cursor

~/.cursor/mcp.json（プロジェクト限定にしたい場合は、リポジトリ直下の .cursor/mcp.json）に次を追記します。

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

保存後、Cursor の Settings → MCP でサーバーが有効になっていれば準備完了です。

よく使うオプション

必要に応じて args（コマンドの引数）にフラグを足せます。

--headless … ブラウザの画面を表示せず、バックグラウンドで動かす
--isolated … 使い捨てのプロファイルで起動し、終了時に自動でクリーンアップする
--browser-url=http://127.0.0.1:9222 … すでに起動している Chrome に接続する

ログイン済みの状態をそのまま調査したいときは --browser-url で既存の Chrome に繋ぐ、CI など画面が不要な場面では --headless を使う、といった使い分けが便利です。

導入後のおすすめの使い方

実際に使うなら、最初から大きなことを狙うより、次のような小さな用途から始めるのがおすすめです。

パターン 1: Console 調査の補助

「この warning がどこで出ているか見て」
「この文字列を Console で検索して」
「直近で何回出たか見て」

まずはここからでも十分価値があります。

パターン 2: 本命 request の特定

「保存時に動く request を絞って」
「候補を 3 本までに絞って」
「外れを先に除外して」

Network の探索補助として使う形です。

パターン 3: response の構造を理解する

「この response で title はどこ？」
「一覧表示に必要な field を抜き出して」
「id / start / end / status の候補を見て」

API parser を書く前の整理が速くなります。

パターン 4: 調査から修正まで一気に進める

「本命 request を見つけて」
「必要 field を整理して」
「その形に合わせて parser を直して」

ここまで行くと、かなり開発体験が変わります。

まとめ

MCP + Chrome DevTools の良さは、単に AI が便利になることではありません。
本質は、 AI が DevTools を見られることで、調査の出発点が会話だけで成立する ようになることです。

これにより、

Network の候補絞り込み
request / response の理解
Console の検索
ノイズ通信の除外
実装修正への接続

がかなり進めやすくなります。

特に、Web アプリ開発で

DevTools を開いて
ログを読んで
AI に貼って
また戻る

を繰り返している人ほど、効果を感じやすいはずです。

もしこれまで AI を「相談相手」としてだけ使っていたなら、
次は 「DevTools を一緒に見る相手」 として使ってみると、開発の進み方が変わるかもしれません。

傳知輝

エンジニア

出身は愛知、育ちは東京です。未経験での中途入社ですが、前職で少しだけ触れていたGoogle Apps Scriptを利用したスプレッドシートの仕組みが、同僚から『業務効率につながった』と評価されたことをきっかけに、プログラミング自体に強い興味を持ち始めました。そこから学びを深め、現在はエンジニアとして新しい挑戦を続けています。

ブログ一覧に戻る