AIエージェント Core Web Vitals:Field Dataがすべてを変える理由
AIエージェントをCore Web Vitalsデータに接続するMCPサーバーは3種類あります。Googleがランキングに実際に使用するデータを提供するのは、そのうちの1つだけです。
AIコーディングエージェントは、MCPサーバーを通じてWebパフォーマンスデータに接続できるようになりました。監査を実行し、ボトルネックをトレースし、コード修正を生成する一連の作業を自動化します。この作業には、Chrome DevTools、Lighthouse、Real User Monitoringという3種類のMCPサーバーが存在します。修正がユーザーの役に立つのか、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データにエージェントを接続します。現在、MCPサーバーを内蔵する商用RUMプラットフォームはCoreDashのみであり、MCP対応のコーディングエージェントにリアルタイムのfield dataを提供します。
これら3つが可能にするワークフローは、測定・修正・再測定のループです。エージェントがボトルネックを特定し、コード修正を生成・適用し、再度テストします。エージェントが使用するデータの種類によって、その修正が実際のユーザーに役立つかどうかが決まります。
Lighthouseのみを使用するエージェントの問題点
GoogleはランキングにLighthouseのスコアを使用しません。Googleは、実際のChromeユーザーから28日間のローリングウィンドウで収集したCrUX field dataを使用します。エージェントがLighthouseを実行し、変更を加え、再度Lighthouseを実行したとしても、検索順位には全く意味のないループです。
lab dataとfield dataのギャップは実在します。2025 Web Almanacによると、モバイルサイトの52%がfield dataで少なくとも1つのCore Web Vitalsの基準を満たしていません。それらのサイトの多くはLighthouseでは良好なスコアを出しています。
INPは最大の死角です。INPは、ユーザーセッション全体を通じた実際のクリック、タップ、キー入力に対するサイトの応答速度を測定します。これに相当するlab dataはありません。LighthouseはTotal Blocking Timeを代替として使用しますが、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診断ガイドでは、AIエージェントが最も苦労する指標について取り上げています。これはラボ環境ではシミュレートできないためです。
診断の背後にある概念は比例的推論です。エージェントは、絶対的なしきい値を超えているフェーズではなく、全体の時間のうち最大の割合を占めているフェーズをボトルネックとして特定します。これにより、効果的な修正方法が変わります。