AIエージェントでLCPを修正する：フィールドデータからコードの修正まで
CWV Superpowersを使用した完全なLCP診断ワークフロー：フィールドデータにおけるボトルネックフェーズの特定から、具体的なコード変更まで。
遅いLargest Contentful Paintには、4つの考えられる原因がある。フィールドデータに接続されたAIエージェントは、実際のボトルネックがどれであるかを特定し、Chromeでトレースを行い、修正を生成できる。これはCWV Superpowersを使用した完全なLCP診断ワークフローである。
最終レビュー：Arjen Karel（2026年3月）
Table of Contents!
LCPの4つのフェーズ
GoogleはLCPを4つのフェーズに分類している。それぞれ原因が異なり、修正方法も異なる。
TTFBは、ナビゲーション開始からHTMLレスポンスの最初のバイトを受け取るまでの時間である。遅いサーバー、CDNの欠如、キャッシュなし、長いデータベースクエリなどが原因となる。TTFBがボトルネックの場合、サーバーを修正するまで他の改善は意味をなさない。
Load Delayは、HTMLを受信してからブラウザがLCPリソースをリクエストするまでの空白時間である。これはリソース発見の問題である。LCP画像がCSSの背景に設定されていたり、JavaScript経由でロードされたり、リダイレクトチェーンの奥深くに埋もれている場合、ブラウザはそれが必要だと気づくまで取得を開始できない。
Load Timeは、リクエストされたLCPリソースがダウンロードされるまでの時間である。大きな画像、圧縮の欠如、遅いCDN、レスポンシブなsrcsetがないことなどが原因となる。
Render Delayは、リソースのダウンロードが完了してから、ブラウザが実際にそれを画面に描画するまでの空白時間である。レンダリングをブロックするスクリプト、Webフォントのロード、またはLCP要素が表示される前にDOMを操作するJavaScriptなどが原因となる。
比例的推論によるボトルネックの特定
Core Web Vitalsに関する公開データは、Core Web Vitalsの本当の問題を見つけるには不十分である。 LighthouseはシミュレートされたMoto G Powerで合成テストを実行し、1つのLCP時間を報告する。CrUXは、28日間の実際のChromeデータをURLごとに単一のp75値に集約する。どちらも何を修正すべきかは教えてくれない。
さらに悪いことに、 どちらも意味のあるセグメンテーションができない。CrUXは、キャッシュされたページビュー、キャッシュされていないページビュー、新規訪問、およびページの再読み込みを1つのp75に統合してしまう。これらは別の問題として扱うべきである。キャッシュされたページビューには、古いキャッシュの検証によるTTFBのボトルネックがあるかもしれない。ページの再読み込みには、ブラウザが毎回LCP画像を遅れて発見するというリソース発見の問題が隠れているかもしれない。混合されたp75は、両方の問題を隠してしまう。
CrUXは 2025年にLCPのサブパートを追加したが、これは役立つ。しかし、依然として要素、ビューポート、または任意のフィルタリングがない28日間のp75である。「過去1ヶ月間にこのURLにアクセスしたすべての訪問者」のフェーズの割合が表示されるだけで、問題が存在する特定のデバイスタイプ、国、またはページテンプレートで何が起こっているかは分からない。
RUMデータは、これらすべての次元でセグメント化する。CWV Superpowersは、そのセグメント化されたデータを照会し、比例的に解釈する。ボトルネックは、失敗している特定のセグメントの合計時間のうち最大の割合を占めるフェーズである。無意味な平均やLighthouseのシミュレーションではなく、実際のデータである！
具体例。モバイルの製品ページにおけるLCPが3,800msである。キャッシュされたページビューでの初回訪問者の実際のユーザーからの内訳は以下の通り：
- TTFB: 600ms (28.7%)
- Load Delay: 1,900ms (44.6%)
- Load Time: 800ms (19.3%)
- Render Delay: 500ms (7.4%)
Load Delayが明らかなボトルネックである。LCPの合計時間の半分は、ブラウザが画像の存在を発見するのを待っている時間である。Lighthouse、CrUX、または手動の調査では、この問題を引き起こした訪問者の特性の正確な組み合わせを見つけるのは非常に困難であっただろう。
このアプローチの完全な説明については、Webパフォーマンスのための比例的推論を参照してほしい。
ブラウザが画像を遅れて発見する理由
Load Delayは、私が見る最も一般的なLCPのボトルネックである。これは、ブラウザがHTMLを受信したにもかかわらず、ずっと後になるまでヒーロー画像が必要であると認識しなかったことを意味する。
一般的な原因は3つある。画像がCSS背景画像であり、プリロードスキャナーからは見えない場合。画像のURLがJavaScriptで構築されている場合。または、画像は技術的にはHTML内にあるが、ブラウザが過剰に尊重する遅延読み込み属性を持っている場合である。
Chromeトレースを開いてみよう。ネットワークウォーターフォールにおいて、HTMLの到着と画像リクエストの発行の間に大きな空白があるのが分かるはずだ。その空白がLoad Delayである。私が監査するサイトでは、モバイルで1,500〜2,500msになる。ブラウザがHTMLを持っているのにヒーロー画像が必要だとはまったく気づかない、まるまる2秒間である。
エージェントも同じ空白を見ている。エージェントはウォーターフォールをCoreDashの内訳と照合し、画像が遅れた理由を正確に教えてくれる。
診断結果はどのようになるか
出力は次のようになる：
AIにより特定された原因： /product/running-shoes-42のLCP画像div.hero-banner > img.product-mainは、プリロードヒントがなく、fetchpriority="high"もないため、1,980ms遅れて発見された。CoreDashデータ：モバイルでのLCPは3,820ms（Poor）、p75。Load Delayが全体の52%を占めるボトルネックとなっている。Chromeトレースで確認：ネットワークウォーターフォールで、HTMLの最初のバイトと画像リクエストの間に1,940msの空白がある。
これが診断のすべてである。エージェントはファイルを見つけ、差分を記述した。あなたはそれを確認してリリースするだけだ。
フェーズごとの典型的な修正方法
Load Delay： <head>にプリロードヒントを追加する。LCP画像にfetchpriority="high"を設定する。画像をCSSの背景やJavaScriptから、プリロードスキャナーが見つけることができるHTML内に移動する。
Load Time： WebPまたはAVIFに変換する。実際の表示サイズに合わせて画像の寸法を縮小する。モバイルユーザーがデスクトップサイズの画像をダウンロードしないように、レスポンシブなsrcsetを追加する。Core Web Vitalsのための画像最適化を参照してほしい。
Render Delay： LCP要素が表示される前に実行されるレンダリングをブロックするスクリプトを削除または遅延させる。LCPテキスト要素に影響を与えるWebフォントのfont-displayを確認する。103 Early Hintsを使用してCSSをより早く配信する。
TTFB： CDNを追加する。サーバーサイドキャッシュを有効にする。データベースクエリの時間を短縮する。103 Early Hintsを使用し、サーバーがレスポンスを生成している間にブラウザがリソースのプリロードを開始できるようにする。
修正の検証
デプロイ後、同じページとデバイスセグメントのCoreDashのフィールドデータを照会する。フィールドデータは、実際のユーザーがページを読み込むと更新される。私は通常、24〜48時間のトラフィックが発生した後に確認している。LCPのp75は低下し、ボトルネックフェーズの分布はシフトするはずだ。
これが、数値を修正することとUXを修正することの違いである。CrUXの更新を28日間待ったり、Lighthouseを再実行してスコアが上がることを祈ったりすることはない。問題が存在したデバイスやネットワークセグメントにおける、実際のユーザー数の改善を確認できる。
INPの診断（ラボでは測定できない指標）についても、同じセグメント化されたワークフローが適用される。3つのCore Web Vitalsすべてにわたって、AIエージェントがフィールドデータとラボデータをどのように使用するかについての広範な視点については、AIエージェントによるCore Web Vitalsデバッグを参照してほしい。
