Claude Code に Chrome DevTools MCP いれて監査が便利

でるとは思ってたけど、Chrome DevTools MCP は、Google の Chrome DevTools チームが作ってる公式ツール

Claude Code、Codex、Antigravity に「かます」ことができる

中身は Puppeteer（Chrome を自動操作するライブラリ）経由で本物の Chrome を駆動してるから、シミュレーションやなく実ブラウザの計測値が返ってくるわけ

要するに、Claude に「本物のブラウザの目と手」を持たせるやつだと思えばいいね

ほんで、Google だけじゃなくて、Vercel、Supabase 、AxiomなんかもCLIから見れるようになってるやん？

「ブラウザで何回もページ移動するのダルい勢」からすると、DevTools 開くの、ちょいちょいストレスだったからマジ助かるよね！（圧）

あらゆるサービスを、Claude Code 内で完結させるっていうのがおいらの目標です

X で毎日 AI 情報を配信してるコムテです。Claude Code 速報やテクニックを配信しています

そうそう、今週あたりから、izanami で、AI系の記事書いてくれたら、X で pickup するで！記事中で PR してくれてもOKよ

Chrome DevTools MCP

Chrome DevTools MCP のライセンスは Apache-2.0、リポジトリは GitHub に公開されてる

そして 2026/5/19 に Chrome DevTools for agents の 1.0 が stable リリースされたばっかりやな

出たての鮮度がある今のうちに触っておくと美味しい。提供形態は MCP サーバー / CLI / Agent Skills の3系統あって、自分の使ってるエージェントに合わせて選べる

Claude Code に Chrome DevTools MCP いれてサービスの監査をしよう

Lighthouse 監査。

Claude Code に Chrome DevTools MCP を入れて自分のサイトを健康診断させたら、実ユーザーの CLS が 0.30 で思いっきり不合格だった

手元で再現しない不合格を、プロンプト1行で炙り出せるじゃん

ツールの名前を覚えてた時代はもう終わりっぽいですねえ

監査は人間が DevTools を開いてポチポチやるものから、Claude Code に投げるものに変わった。実際にやってみたら、自分が見落としてた不合格がボロボロ出てきたので、その手触りを書いておく

結論：プロンプト1行で健康診断でき、lab では見えない実ユーザーの不合格まで炙り出せる

ツールの正体が分かったところで、結論を先に置いておく

Claude Code に Chrome DevTools MCP を入れると、ツール名を一切覚えずに自然文1行でサイトの監査ができる

しかもそれが一番効く場面は、自分の手元では絶対に再現しない不合格を見つけてくれるところにある

つまり「自分の環境では問題ない」っていう一番タチの悪い思い込みを、Claude Code が勝手に剥がしにくる。ここからは導入の手順と、実際に出てきた監査結果を順番に見ていく

導入は2行（Claude Code の場合）

Claude Code に入れるのはめっちゃ簡単で、コマンド2行で終わる

前提は Node.js の LTS（長期サポート版）と Chrome が入ってることだけやね

まずマーケットプレイスを追加する

続けてプラグインをインストールする

これで MCP サーバー本体に加えて、専用の Skill が6個ついてくる

Skill っていうのは Claude が状況に応じて勝手に参照する手順書みたいなもので、入ってるのは以下のやつ

• a11y-debugging（アクセシビリティのデバッグ）
• chrome-devtools（基本操作）
• chrome-devtools-cli（CLI 連携）
• debug-optimize-lcp（LCP 改善）
• memory-leak-debugging（メモリリーク追跡）
• troubleshooting（トラブル切り分け）

ツール自体はデフォルトで一通り有効になってて、emulation / performance / network 系は最初からオンになってる

extensions / third-party / webmcp 系は opt-in（手動で有効化）になってるので、必要になったら足す感じやな

Claude Code 以外でも使えて、横並びで手順を置いておく

どのエージェントを使ってても、公式の agents ページに導入手順がまとまってるので、迷ったらここを見る

使い方：プロンプトを投げるだけ

ここが一番気持ちいいところで、たくさんあるツール名を一個も覚えなくていい

やることは自然文を1行投げるだけやな

ワイが実際に投げたのはこれ

これだけで、Claude が裏でツールを自動的に選んで順番に叩いてくれる

なんつーか、今どきよね（ワイは、コマンドっぽいのが好きだけどね）

こっちが指示しなくても、こんな流れを勝手に組み立てる

• ページを開く（navigate_page）
• Lighthouse を回す（lighthouse_audit）
• トレースを取る（performance_start_trace）
• コンソールメッセージを拾う（list_console_messages）

あー、自動で ブラウザ開いてたよ

つまり監査のスキルが「ツールの操作手順」から「何を聞きたいか」に移った

これが Agentic（AI エージェント主導）な開発体験の、なにげにデカい変化だと思う

実測：自分のサイトの健康診断結果

御託はいいので、実際に自分のブログを健康診断させた結果を出す

Lighthouse のカテゴリ別スコアはこうだった

SEO と Best Practices は満点だったので、ここは普段の運用で十分整ってた

ほんで問題は下の2つだ

Accessibility が 91 で、満点まであと一歩

そして一番ヤバかったのが Agentic Browsing で、ここは黄信号だった

よくないね

スコアの内訳だけ見ても「ふーん」で終わるけど、本番はここからだ

Core Web Vitals を lab と field の両方で測らせたら、思い込みが一発で崩れた

一番の発見：lab では CLS 0.00 なのに、実ユーザー（field）は CLS 0.30 で不合格

これがこの記事を書いた理由そのもの。Core Web Vitals を2つの計測源で並べたらこうなった

CLS（Cumulative Layout Shift、レイアウトのガタつき具合）が、手元では 0.00 なのに実ユーザーでは 0.30

良好基準の 0.1 をブッちぎって不合格だった

LCP（Largest Contentful Paint、主要コンテンツの表示速度）も lab は 1370ms で爆速なのに、field は 2482ms でギリギリ「要改善」のラインだ

ここで lab と field の違いを押さえておく

lab は自分の手元で1回リロードして測る理想環境の値で、field は CrUX（Chrome User Experience Report、実際のユーザー環境を集めた Google のデータ）の実測値だ

p75 っていうのは「ユーザーの上から75%が体感した値」で、つまり遅い側のユーザーまで含めた現実の数字になる

なんでこんなに差が出るのか。理由はシンプルで言い切れる

この lab と field が乖離する仕組みは、web.dev の公式記事が裏付けてる。手元の Lighthouse だけ見て安心するのが、いかに危ういかがよく分かる

うーん、リンク先は英語にスイッチしてな！

つまり手元で何回 Lighthouse を回しても、実ユーザーが踏んでる地雷には永遠に気づけなかった

これがまじでおっかない

Claude Code が field データまで引っ張ってきたから、初めて不合格が表に出た

根本原因と打ち手（優先度順）

Claude には「直すべき所を優先度順に」って頼んでたので、原因と打ち手をセットで返してきた

優先度順に並べる

1. ヒーロー画像の寸法未確保 → CLS の主因
2. コンソール404 → 内部リンクの prefix ミス
3. link-name 監査0点 → A11y と AI可読性を同時直撃
4. テキストのコントラスト不足 → WCAG AA 未達
5. 画像ホストへの preconnect ゼロ
6. Google Tag Manager が重い

1つ目が CLS の犯人だった

ヒーロー画像（ページ冒頭の大きい画像）に幅と高さを指定してないと、画像が読み込まれた瞬間にレイアウトが下にズレてガタつく

打ち手は width / height か aspect-ratio を先に確保すること、それと next/image で priority などを使って優先読み込みすることだ

2つ目のコンソール404 は、内部リンクの prefix（パスの接頭辞）がズレてて、実在しないパスへ prefetch（先読み）してたのが原因だった

地味やけど無駄なリクエストとエラーログを垂れ流してたわけだ

3つ目が個人的に一番おもろかった

link-name 監査（リンクに名前がついてるかのチェック）が0点で、これが Accessibility と Agentic Browsing の両方を同時に殴ってた

4つ目は薄いグレーの文字色が WCAG AA（アクセシビリティ基準）の 4.5:1 コントラスト比に届いてなかった

濃い階調に振れば解決する

5つ目は画像ホストへの preconnect（事前接続）がゼロで、6つ目は Google Tag Manager が重いっていう、よくあるやつだった

優先度の高い上3つを潰すだけで、CLS の不合格とエラーログとアクセシビリティが一気に改善する見込みが立った

手作業で DevTools を3タブ往復してたら、この優先順位付けまで自分でやらなあかんかった

AI可読性（Agentic Browsing）は SEO の次の戦場

ここで Agentic Browsing をもう一段掘り下げる

これは Lighthouse 13.3 の experimental（実験的）カテゴリで、AI エージェントがそのページを読めるか・操作できるかを測る指標だ

人間やなく AI 来訪者向けの健康診断っていう新しい発想になる

測ってる信号は4つ

• アクセシビリティツリー（names / labels = link-name）
• CLS
• llms.txt（AI 向けのサイト案内ファイル）
• WebMCP（ページが AI に機能を提供する規格）

採点の詳細は公式に出てて、pass / fail の比率で評価される仕組み

注目したいのは、4信号のうち link-name と CLS が、人間向けの Accessibility・Core Web Vitals と完全に被ってるところだ

さっきの「1つ直すと2カテゴリ上がる」がここでも効く

つまり A11y を真面目にやってきた人は、知らんうちに AI可読性の貯金もできてた

逆にここをサボってきたサイトは、人間にも AI にも読みにくいまま放置されてる

監査は人間が覚えるものから、AI に投げるものになった

ちょい後半はAIに書いてもらったけど、まぁいいやろ

今回やったことを一段引いて振り返る

Claude Code × Web パフォーマンス、そして Claude Code × LLMO（大規模言語モデル最適化）の交差点に、地味だけど効く鉱脈があった

• 監査はツール名を覚える作業から、自然文1行に変わった
• lab だけ見る安心は危険、field で実ユーザーの不合格が出る
• A11y 対応がそのまま AI可読性対応になる

DevTools のタブを覚えてた時代から、「直すべき所を優先度順に教えて」の1行で済む時代になった

覚えるべきは API やなく、何を聞くかだけやな

そして Agentic Browsing っていう新カテゴリは、AI可読性が SEO の次の戦場になることを告げてる

英語圏には Claude Code × Web パフォーマンスのコンテンツが大量にあるけど、日本語で field データの不合格まで踏み込んだ実測記事はまだ少ない

やっぱし今のうちに自分のサイトを Claude Code に健康診断させて、人間にも AI にも読まれるサイトに整えておくと、後で効いてくる