コアウェブバイタルとは？3指標（LCP/INP/CLS）と改善方法を解説
コアウェブバイタルとは
コアウェブバイタル（Core Web Vitals / CWV）とは、Googleがウェブページのユーザー体験を定量的に評価するために定めた指標群の中核をなす3つの測定項目を指す。ページの表示速度・操作への応答性・視覚的な安定性をそれぞれ数値化し、実際のユーザー環境（フィールドデータ＝実際のChromeユーザーから収集した計測値）に基づいて評価する点が特徴だ。
コアウェブバイタルを構成する3指標は次のとおり。
- LCP（Largest Contentful Paint） — 最大コンテンツの表示にかかる時間
- INP（Interaction to Next Paint） — 操作に対する応答性の総合評価（2024年3月にFID＝「最初の1回だけを計測する旧指標」から置き換わった最新指標）
- CLS（Cumulative Layout Shift） — 視覚的レイアウトのズレの累積量
これら3指標はGoogleの「ページ体験」シグナルを構成する要素の一部であり、検索順位の評価基準として公式に採用されている。
検索順位への影響：いつからランキング要因になったか
コアウェブバイタルがGoogleの検索ランキング要因として正式に組み込まれたのは2021年6月のコアアルゴリズムアップデートからだ。それ以前からGoogleはページ速度（モバイル）や安全なブラウジング、HTTPS対応（通信の暗号化によりURLが「https://」で始まる状態）、モバイルフレンドリー（スマートフォンで適切に表示・操作できる設計）を「ページ体験シグナル」として評価していたが、2021年のアップデートでコアウェブバイタルがその中核として加わった。
ページ体験シグナルとランキングの関係について、Googleは次のように説明している。
- ページ体験シグナルはランキングのシグナルの一つである
- コンテンツの関連性と品質が依然として最重要であり、優れたコンテンツはページ体験スコアが低くても上位表示されることがある
- ただし、コンテンツ品質が同水準のページ間では、ページ体験シグナルが差別化要因になり得る
また、ページ体験シグナルはE-E-A-T（経験・専門性・権威性・信頼性）と並ぶ重要な評価要素として位置づけられており、技術面とコンテンツ品質の両輪で対策することが求められる。
3指標の詳細：LCP・INP・CLS
LCP（Largest Contentful Paint）— 最大コンテンツ表示時間
LCPは、ページの読み込み開始からビューポート内で最大サイズのコンテンツ要素が描画されるまでの時間を計測する指標だ。対象となる要素は画像、動画のサムネイル、テキストブロックなど。ファーストビューの「見えた感」を数値化したものと理解するとわかりやすい。
| 評価 | 数値 |
|---|---|
| 良好（Good） | 2.5秒以内 |
| 要改善（Needs Improvement） | 2.5秒〜4.0秒 |
| 不良（Poor） | 4.0秒超 |
LCPが遅くなる主な原因はサーバー応答の遅延、レンダーブロッキングリソース（CSSやJavaScriptの読み込みが画面描画をブロックすること）、画像サイズの最適化不足、クライアントサイドレンダリング（ブラウザ側でJavaScriptを実行してページを組み立てる方式）の過多などだ。
INP（Interaction to Next Paint）— 操作応答性（2024年3月〜）
INPは、ユーザーがページ上で行うすべてのクリック・タップ・キーボード操作に対する応答時間の総合評価を行う指標だ。ページ滞在中のインタラクション全体を測定し、ほぼ最悪値（高パーセンタイル）をページ全体のスコアとして採用する。
2024年3月12日に、それまで採用されていたFID（First Input Delay）がINPに正式置き換えられた。FIDは「最初の操作」のみを測定していたのに対し、INPはページ滞在中のすべての操作を評価対象とするため、より実態に即した応答性の測定が可能になっている。
| 評価 | 数値 |
|---|---|
| 良好（Good） | 200ms以内 |
| 要改善（Needs Improvement） | 200ms〜500ms |
| 不良（Poor） | 500ms超 |
INPが悪化する主な原因はメインスレッドの長時間ブロック、重いJavaScript処理、不要なサードパーティスクリプト、非効率なDOM操作などだ。
CLS（Cumulative Layout Shift）— 累積レイアウトシフト
CLSは、ページ読み込み中および閲覧中に発生する予期しないレイアウトのズレの累積スコアを数値化した指標だ。広告や画像がサイズ未指定で遅れて表示され、テキストが突然ずれるような現象がCLSに直結する。
| 評価 | 数値 |
|---|---|
| 良好（Good） | 0.1以下 |
| 要改善（Needs Improvement） | 0.1〜0.25 |
| 不良（Poor） | 0.25超 |
CLSが悪化する主な原因はサイズ指定のない画像・動画・広告スロット、Webフォントの遅延レンダリング（FOUT/FOIT）、動的コンテンツの挿入などだ。
計測方法：どのツールで確認するか
コアウェブバイタルの計測には、フィールドデータ（実ユーザーデータ）とラボデータ（シミュレーション）の2種類がある。検索順位の評価基準はフィールドデータだが、改善作業にはラボデータも有効だ。
主要な計測ツール
PageSpeed Insights（PSI） Googleが無償提供するページ速度測定ツール（https://pagespeed.web.dev/）。URLを入力するだけでフィールドデータ（CrUX）とラボデータの両方を確認できる。LCP・INP・CLSの数値と改善提案が自動表示される。最も手軽な計測手段だ。
Google Search Console（GSC） — コアウェブバイタルレポート Googleが無償提供するサイト管理ツール（略称：GSC）。サイト全体のページをURLグループ単位で「良好・要改善・不良」に分類して表示する。問題のあるURLを一覧で把握するのに適しており、定期的なモニタリングに使う。
Chrome DevTools — Lighthouseパネル ブラウザ上でシミュレーション計測を実行できる。実装変更後のローカル環境での確認や詳細なボトルネック分析に有効。
CrUX（Chrome User Experience Report） Chromeユーザーから収集した実際のフィールドデータを提供するGoogleのデータセット。BigQueryやPageSpeed InsightsのAPIを通じて取得できる。
改善施策チェックリスト
LCP 改善
- サーバー応答時間（TTFB）を200ms以下に改善する
- ヒーロー画像・アイキャッチ画像を WebP/AVIF に変換し適切なサイズに圧縮する
- ファーストビューの画像に
fetchpriority="high"を付与してプリロードする - レンダーブロッキングCSSを最小化し、クリティカルCSSをインライン化する
- CDNを活用してアセット配信を高速化する
INP 改善
- 長時間タスク（50ms超のJavaScript実行）を分割してメインスレッドを解放する
- サードパーティスクリプト（タグマネージャー、チャットウィジェット等）を遅延ロードする
- イベントハンドラーを軽量化し、重い処理はWeb Workerに委譲する
- 不要なJavaScriptバンドルを削除・遅延化してTBTを削減する
CLS 改善
<img>タグにwidthとheight属性を必ず指定する（アスペクト比の事前確保）- 広告スロットに最小サイズのプレースホルダーを用意する
- Webフォントに
font-display: optionalまたはswapを設定する - 動的に挿入するUI要素（バナー、通知等）はビューポート外または予約済みスペースに表示する
数値だけ見ても「なぜ」が分からない問題
コアウェブバイタルの各指標を計測ツールで確認すると、「LCPが3.2秒（要改善）」「CLSが0.08（良好）」といった数値は得られる。しかし、その数値がユーザー行動にどう影響しているかは、数値単体では分からないという現実がある。
実務でよく起きるギャップのパターンを挙げると次のとおりだ。
- LCPが遅いのに離脱率が低い — ヒーロー画像が重いだけで、本文テキストが先に表示され読者が待ってくれているケース。LCP改善の優先度は実は低い。
- CLSスコアが良好なのにラビッドクリック（同じ箇所を短時間に連打する行動＝反応しないと感じたユーザーの焦りを示すシグナル）が多い — レイアウトはズレていないが、ボタンやリンクの反応が鈍く感じられ、ユーザーが何度もタップしているケース。INPの問題かもしれないし、UIの視認性の問題かもしれない。
- INPは改善済みなのにコンバージョンが上がらない — 操作応答性自体は良くなったが、ページ内の導線設計やコンテンツの読みやすさに別の問題がある。
つまり、コアウェブバイタルの数値は「どこで技術的な問題が起きているか」は教えてくれるが、「ユーザーがどこで詰まって、どういう行動をとっているか」はヒートマップ（ページ内でユーザーがクリックやスクロールした箇所を色の濃淡で可視化した図）やスクロール深度（ページのどこまでスクロールされたかを示す指標）といった行動データを合わせて見る必要がある。
Microsoft Clarityは、ヒートマップ・スクロール深度・ラビッドクリック・離脱箇所といったユーザー行動データを無償で収集できるツールだ。コアウェブバイタルの数値と組み合わせることで、「LCPが遅い → ファーストビューで離脱しているか」「CLSは良好 → なのにラビッドクリックが多い場所はどこか」といった問いに、行動データから答えを探せる。
ケンランSEO（pro / business プラン）では、ClarityのデータをSEO順位情報と統合して分析する機能を提供している。具体的には次のような使い方ができる：
- 順位×UX行動の並列分析 — 「順位は良いのに離脱率が高いページ」「CLSスコアは低いのにラビッドクリックが集中している箇所」を発見する
- UX診断エージェント（L3_ux_diagnosis） — ClarityデータをAIが解析し、コアウェブバイタルの観点も含めた改善提案を生成する
- AI改善提案へのナレッジ注入 — サイト固有の業界知識・ページ構造を踏まえた具体的な改善提案（一般論ではなく「あなたのサイト向け」の提案）
Clarity連携はpro（¥4,980/月）またはbusiness（¥9,800/月）プランで利用できる。light / standard プランでは利用不可。大手SEOツールにも順位×UX連携機能を持つものはあるが、月額¥5,000以下の価格帯でClarityとSEO順位を統合分析できるツールは多くない。
関連概念：ページ体験・モバイルフレンドリー・HTTPS
コアウェブバイタルは「ページ体験シグナル」の一部であり、他の要素と合わせて総合的に評価される。
ページ体験（Page Experience） Googleがランキング評価に使用するユーザー体験シグナルの総称。コアウェブバイタル・HTTPS・モバイルフレンドリー・セーフブラウジング（マルウェアやフィッシングなど有害コンテンツが含まれていないこと）・煩わしいインタースティシャルなしの各要素で構成される。
モバイルフレンドリー スマートフォンで適切に表示・操作できるページ設計。Googleはモバイルファーストインデックスを採用しているため、モバイルでのコアウェブバイタルスコアが主要な評価基準となる。デスクトップとモバイルは別々のスコアで評価される点に注意が必要だ。
E-E-A-T 経験・専門性・権威性・信頼性を意味するGoogleのコンテンツ評価基準。ページ体験シグナルは技術的なUQ品質を評価するのに対し、E-E-A-Tはコンテンツそのものの信頼性と専門性を評価する。コアウェブバイタルが良好でもE-E-A-Tが低ければ上位表示は難しく、両者は補完関係にある。
HTTPS 通信の暗号化による安全なページ。HTTPS対応はページ体験シグナルの1つであり、現在ほぼすべての主要サイトが対応済みだ。未対応のサイトはChromeで「保護されていない通信」として警告が表示される。
よくある誤解と正しい理解
「コアウェブバイタルを改善すれば上位表示できる」は正しいか？▼
正しくない。コアウェブバイタルはランキングシグナルの一つであり、上位表示を決定する主要因はコンテンツの品質・関連性・被リンクプロファイルなど多岐にわたる。コアウェブバイタルが「良好」でも、検索意図に合致しないコンテンツや専門性の低い記事は上位表示されない。逆に、スコアが「要改善」でも、コンテンツ品質が突出して高いページは上位を維持することがある。コアウェブバイタルはあくまで「同水準のコンテンツ間でのタイブレーク要因」として機能することを理解しておく必要がある。
モバイルとデスクトップのスコアは共通か？▼
別々に評価される。Googleはモバイルファーストインデックスを採用しているため、モバイルのコアウェブバイタルスコアが検索順位評価の主基準となる。PageSpeed InsightsやSearch Consoleでもモバイル/デスクトップそれぞれのスコアが表示される。モバイルスコアが不良でもデスクトップが良好なケースは少なくなく、特にスマートフォンのCPU性能を考慮したモバイル最適化が重要だ。
「FIDを改善した」は今も有効な施策か？▼
FIDは2024年3月12日にINPへ正式に置き換えられており、現在はFIDがランキング評価の対象外となっている。FID対策（イベントハンドラーの初回応答改善）はINP改善にも有効な部分はあるが、INPはページ全体のインタラクションを評価するため、より広範な最適化が必要だ。2024年3月以降に公開されたSearch Consoleのレポートも、INPを使用した評価に切り替わっている。
PageSpeed InsightsのスコアとSearch Consoleのデータが違う理由は？▼
PageSpeed Insightsはラボデータ（Lighthouseによるシミュレーション）とフィールドデータ（CrUX）の両方を表示するが、Search Consoleのコアウェブバイタルレポートはフィールドデータのみを使用する。また、CrUXは過去28日間の実ユーザーデータを集計するため、直近の改善がスコアに反映されるまでに数週間のラグが生じる。ラボデータで改善を確認しても、フィールドデータに反映されるのは改善後のトラフィックが十分に蓄積されてからだ。
コアウェブバイタルの数値だけ追えばUX改善は完結するか？▼
完結しない。コアウェブバイタルはページの技術的なパフォーマンス（速度・安定性・応答性）を数値化したものであり、「ユーザーが実際にどこで詰まり、どんな行動をとっているか」は計測できない。たとえばLCPが「良好」でも、ページ内の読みにくい箇所でスクロールが止まっていたり、ボタンが分かりにくくてラビッドクリックが発生していたりする問題はCWVスコアには現れない。コアウェブバイタルの改善と並行して、ヒートマップやスクロール深度などの行動データも参照することで、技術起因と体験起因の問題を区別した対策が取れるようになる。