AIコーディングエージェントの弱点は、ずっと同じだった。コードは書ける。でも「書いたページが実際どう動くか」は見えていない。目隠しでピアノを弾くようなもの。Chrome DevTools MCPは、ここに目を付ける。ブラウザの計測機能を、そのままエージェントの手に渡す。
エージェントに「ブラウザの目」を与えるという発想
このMCPサーバーがやることは、要するにChrome DevToolsをツールとしてエージェントに公開することだ。パフォーマンストレースの記録、ネットワークリクエストの解析、コンソールメッセージの取得、スクリーンショット。人間がDevToolsを開いてやっていた作業を、エージェントが自分で叩ける。
中でも私が試したかったのが、パフォーマンス計測まわりだ。performance_start_trace と performance_stop_trace でページ動作中のトレースを記録し、performance_analyze_insight でそこから指標を抽出する。LCP(Largest Contentful Paint)やTBT(Total Blocking Time)、CLSといったCore Web Vitalsを、エージェントが自分で読む。
この「自分で読む」がポイントだと思う。これまでのエージェントは、人間が貼り付けた数字を解釈することしかできなかった。私がDevToolsのスクショを撮って、それを説明して、ようやく会話が始まる。Chrome DevTools MCPは、その前段——計測そのもの——をエージェント側に寄せた。指標を取りに行くところから任せられる。手数が一段減る。
実際に試した結果:遅いトップページを「診断」させた
題材に選んだのは、自分が前に組んで放置していた個人サイト。体感で「なんか重い」とは思っていたが、原因を突き止める気力がなく寝かせていたページだ。
エージェントに「このページのパフォーマンスを計測して、LCPが遅い原因を特定して」とだけ伝えた。すると performance_start_trace でリロードを挟んだトレースを取り、insightを解析し、こう返してきた。LCP要素はヒーロー画像。そのうちの大半が、最適化されていない巨大なPNGの読み込み待ちだと。
私がDevToolsを開いてウォーターフォールを睨んで犯人を当てるのに、いつもなら15分前後。今回は計測から指摘まで、3分ほどで核心に着いた。さらに「次の打ち手」まで添えてきたのが良かった。画像をWebPに変換し、明示的な幅高さを指定してCLSを抑える。言われた通りにしたら、再計測でLCPがはっきり縮んだ。
具体的な数字を出すと、もとのLCPは4秒台の後半。画像をWebPに変換し、ヒーロー画像に fetchpriority="high" を足し、サイズ属性を明示しただけで、再計測では2秒台の前半まで落ちた。半分とは言わないが、それに近い。CLSも、画像のサイズ未指定が原因のガタつきが消えて、ほぼゼロになった。やったこと自体は教科書的だ。新しい技術は何も使っていない。違うのは、その教科書のどのページを開けばいいかを、エージェントが一瞬で当てた点だ。
「推測でチューニング」から「計測で会話」へ
これまでエージェントにパフォーマンス改善を頼むと、一般論が返ってきがちだった。「画像を最適化しましょう」「不要なJSを削りましょう」。正しいが、当たり前すぎる。検索すれば誰でも辿り着くし、それで直るなら最初から困っていない。
トレースという一次データを握らせると、会話の質が変わる。「このページの、この要素が、この理由で遅い」という固有名詞の話になる。推測のチューニングから、計測に基づく対話へ。フロントの性能改善で一番だるい「原因の切り分け」を、エージェントが肩代わりしてくれる感覚がある。データが間に入るだけで、改善の議論はこんなに具体的になるのか、と少し驚いた。
注意点:あくまで「補助線」であって万能ではない
過信は禁物だと感じた点も書いておく。トレースは実行環境に強く依存する。私のローカルで取った数字と、本番のCDN配信下の数字は当然ずれる。回線やキャッシュの状態でも値は揺れる。エージェントの指摘も、あくまでその一回の計測に基づくスナップショットだ。鵜呑みにせず、何度か計って傾向で見るのがいい。
それでも「どこを見ればいいか」の当たりを一瞬で付けてくれる価値は大きい。最終判断は人間がやる。エージェントが引いてくれるのは、あくまで補助線。この距離感を守れば、強力な相棒になる。
もう一つ、コンソールのエラーやネットワークの失敗リクエストも一緒に拾える点は実務的だ。パフォーマンスの裏には、たいてい余計な再描画や、失敗してリトライしているリクエストが潜んでいる。トレースだけでなく、こうした「周辺の証拠」をまとめて見られると、原因の筋読みが立てやすい。フロントの不具合調査は、結局この証拠集めが八割だ。そこを肩代わりしてもらえる。
結論:重いと感じるページを一つ、診断させてみる
導入は驚くほど軽い。Node環境があれば、MCP対応エージェントの設定にサーバーを足すだけ。まず一つ、「なんとなく重い」と放置しているページを診断させてみてほしい。原因の固有名詞が返ってきた瞬間、たぶん手放せなくなる。ブラウザの目を持ったエージェントは、思っていたより頼りになる。
付け加えるなら、これはフロント専門でない人にこそ刺さると思う。バックエンドが本業で、たまたまフロントも面倒を見ている——そういう立場の人は、Core Web Vitalsの細かい指標を追う時間が取りにくい。エージェントが計測と一次診断を肩代わりしてくれるなら、その「片手間のフロント」の質が底上げされる。専門家の代わりにはならない。けれど、専門外の人間が最低限の改善に辿り着くまでの距離を、確実に縮めてくれる。私にとっての価値は、むしろそこにある。性能改善は一部のエキスパートだけのものではなくなりつつある。
