Core Web Vitalsを監視するAIエージェント：MCP経由のfield data

AIコーディングエージェントは、MCPサーバー経由でWebパフォーマンスデータに接続できるようになりました。監査の実行、ボトルネックの追跡、コード修正の生成を自動ループで行います。この用途に使えるMCPサーバーは、Chrome DevTools、Lighthouse、Real User Monitoringの3種類です。その修正が実際のユーザーの役に立つのか、それともGoogleが無視する合成スコアを改善するだけに終わるのかは、どのデータソースを使うかで決まります。

最終レビュー: Arjen Karel（2026年3月）

AIエージェントがCore Web Vitalsで今できること

Model Context Protocol（MCP）は、AIツールが外部データソースへ接続するための標準仕様です。Core Web Vitals の改善作業では、3種類のサーバーが重要になります。

Chrome DevTools MCP を使えば、エージェントがChromeのデバッグ機能を直接操作できるようになります。Googleはこれを2025年末にパブリックプレビューとしてリリースしました。パフォーマンストレースの実行、LCP のフェーズごとの内訳分析、render blocking なリソースの特定を行い、生のトレースデータをエージェントが解析できるコンパクトなサマリーに圧縮します。

Lighthouse MCPサーバー を使えば、エージェントがプログラムからフル監査を実行できます。GitHub上にも複数の実装が存在します。多数のページを一括監査する際に便利です。得られる結果はlab dataです。シミュレートされたデバイスとネットワーク接続環境による合成テストです。

RUM MCPサーバー は、実際の訪問者から得られたReal User Monitoringデータにエージェントを接続します。CoreDash は現在、MCPサーバーを標準搭載した唯一の商用RUMプラットフォームです。MCP対応のあらゆるコーディングエージェントに、リアルタイムのfield dataを提供します。

これら3つのサーバーが実現するワークフローは、「計測、修正、再計測」のループです。エージェントがボトルネックを特定し、修正コードを生成して適用し、再びテストします。エージェントがどの種類のデータを使うかによって、その修正が実際のユーザーの役に立つかどうかが決まります。

Lighthouseだけに頼るエージェントの問題点

Googleは検索順位の決定にLighthouseのスコアを使用していません。 Googleが使用するのは、実際のChromeユーザーから収集された直近28日間の CrUX field data です。Lighthouseを実行し、修正を加え、再びLighthouseを実行する――そんなエージェントが回しているループは、検索での露出にとって何の意味もありません。

labとfieldのギャップは明確です。2025 Web Almanac によると、モバイルサイトの52%がfield dataにおいて少なくとも1つのCore Web Vitalsの基準を満たしていません。そうしたサイトの多くが、Lighthouseでは良好なスコアを出しています。

最大の盲点は INP です。INPは、セッション全体を通じて実際のクリック、タップ、キー入力に対してサイトがどれだけ速く応答するかを計測します。これに相当するlab環境の指標はありません。Lighthouseは代替指標としてTotal Blocking Time（TBT）を使用しますが、TBTが計測するのはページ読み込み中のスレッドのブロックです。対してINPが計測するのは、予測できないタイミングで発生する実際のインタラクション時の応答時間です。エージェントがTBTを「修正」したとしても、実際のINPが改善した保証はどこにもありません。

エージェントが作成した33,596件のプルリクエストを対象とした調査（Alamら、2026年1月）では、AIが生成した修正PR全体のマージ率は65%であることが判明しました。3分の1以上が人間のレビュアーによってリジェクトされています。パフォーマンスの改善には、lab data単体では得られないコンテキストが必要です。

lab dataでは得られない、field dataがもたらすもの

Real User Monitoringは、すべてのデバイスの全訪問者からパフォーマンスデータを収集します。エージェントがLighthouseではなくRUMに接続すると、3つの点が変わります。

実際の訪問者にとって、どのページが本当に遅いのかが分かります。4G環境下の仮想Moto G Powerによる合成テストでスコアが悪かったページではありません。ユーザーがいるのは、ドイツの光回線に繋がったiPhoneかもしれません。あるいは、インドネシアの混雑したモバイル回線上にある低価格なAndroid端末かもしれません。field dataは、ユーザーが実際に体験している状況をそのまま反映します。

CoreDash は、要素レベルでの原因特定データをエージェントに提供します。LCP の遅延を引き起こした具体的な要素。INP 低下の原因となったJavaScriptファイル（Long Animation Framesデータ経由）。シフトしたDOMノード。エージェントは推測に頼ることなく、メトリクスから修正すべき該当コードへと正確に辿り着けます。

さらに、修正が効果を発揮したかを検証できます。変更をデプロイした後、エージェントはfield dataをクエリして、実際のユーザー体験が改善されたことを確認します。これは、大半のAIワークフローが完全にスキップしているステップです。そして、検索順位にとって本当に重要なのは、このステップだけです。

完全なワークフローは次のようになります。field dataで問題を特定し、Chromeで原因を追跡し、コードを修正し、field dataで効果を検証する。調査はエージェントが行います。何を本番にリリースするかを決めるのは、開発者自身です。

次のステップ

CWV Superpowers は、このワークフロー全体を自動化する無料のClaude Codeスキルです。セットアップは2分で完了します。CoreDash のfield dataに接続し、最も深刻なボトルネックを特定して、Chromeで根本原因を追跡した上で修正案を生成します。

個別の指標については、LCP診断ガイド で、低速なLargest Contentful Paintの4つのフェーズを追跡し、具体的なコード修正へと落とし込む手順を解説しています。INP診断ガイド では、lab環境ではシミュレートできず、AIエージェントが最も苦戦する指標を扱っています。

この診断の根底にある概念が、proportional reasoning です。エージェントは、絶対的なしきい値を超えたフェーズではなく、総時間の中で最大の割合を占めるフェーズをボトルネックとして特定します。これにより、成果に直結する修正策が変わってきます。