計測してわかったAI時代のページ速度の現実【Core Web Vitals入門】
自分のサイトを初めてPageSpeed Insightsで計測したとき、正直ちょっと焦りました。
デスクトップは92点で問題なし。ところがモバイルを見ると60点、LCP 6.9秒という数字が出てきました。「6.9秒って、読み込みにそんなにかかってたのか」と、初めてそのことに気づいた瞬間でした。
SEOやAI最適化の設定をいろいろ整えてきたつもりでも、ページ速度という基本的なところが抜けていました。AIクローラーはページ速度をどう評価しているのか。そしてモバイルが遅いと何が困るのか。この記事では、実測データをもとにCore Web Vitalsの基本と改善の考え方を整理します。
Core Web Vitalsとは？3つの指標をわかりやすく
Core Web VitalsはGoogleが定めたページ体験の評価指標で、現在は以下の3つで構成されています。
| 指標 | 意味 | 良好の目安 | AI観測ラボの実測値 |
|---|---|---|---|
| LCP（Largest Contentful Paint） | 最大コンテンツの読み込み時間 | 2.5秒以内 | デスクトップ 1.3秒 / モバイル 6.9秒 |
| CLS（Cumulative Layout Shift） | レイアウトのズレ・ガタつき | 0.1以下 | デスクトップ 0（良好） |
| INP（Interaction to Next Paint） | 操作への応答速度 | 200ms以内 | デスクトップ 288ms（要改善） |
今回の計測でとくに気になったのはモバイルのLCPです。6.9秒というのは「良好（2.5秒以内）」どころか「改善が必要（4.0秒超）」の基準をも大きく超えています。ページを開いてから最大コンテンツが表示されるまでに約7秒かかっているということで、スマホで見ているユーザーにとってはかなりストレスのある体験になっていた可能性があります。
なぜAI時代にページ速度が重要なのか
ページ速度がSEOに影響することは広く知られていますが、AI検索が普及した現在、さらに別の文脈でも重要になっています。
AIクローラーはクロール効率を重視する
ChatGPT（GPTBot）やPerplexity、ClaudeなどのAIクローラーは、大量のページを短時間でクロールします。このときレスポンスが遅いページはクロールをスキップされたり、優先度が下げられたりする可能性があります。robots.txtやllms.txtでアクセスを許可していても、実際に読み込まれなければ意味がありません。
AIクローラーの動作については、AIクローラーとは？引用されるサイト設計の基本と8つの対策でも詳しく解説しています。
モバイルファーストはAIにも適用される
Googleはモバイルファーストインデックスを採用しており、モバイル版のページを基準にインデックスと評価を行っています。AIのGoogleインデックスへの依存度を考えると、モバイルのスコアが低いことはAI検索への露出にも間接的に影響します。
ページ速度はE-E-A-Tの信頼性シグナルにもなる
表示が遅い・レイアウトがガタつくサイトは、ユーザー体験が悪く離脱率が高くなります。AIはユーザーから信頼されているページを優先的に参照する傾向があるため、ページ速度の改善はE-E-A-Tの強化にもつながります。E-E-A-T全体の整備についてはE-E-A-TをAI時代に最適化する実践ガイドを参考にしてください。
モバイルが遅くなる主な原因
デスクトップとモバイルでスコアがこれほど差がつく主な原因は3つです。
① 画像の最適化不足
モバイル回線でJPEGやPNGの大きな画像を読み込むと、LCPが一気に悪化します。WebP形式への変換と適切なサイズ指定が最初の改善ポイントです。またヒーロー画像など最初に表示されるコンテンツには loading="eager" と fetchpriority="high" を指定しておくと、LCP改善に効果的です。
② レンダリングを妨げるJavaScript・CSS
ページ読み込み時に実行されるJSやCSSが多いと、コンテンツの表示が遅れます。使っていないプラグインのスクリプトや、ファーストビューに不要なCSSが原因になっていることが多いです。
原因となっているスクリプトはChrome DevToolsで特定できます。手順は以下の通りです。
- Chromeでサイトを開き、F12でDevToolsを起動
- 「パフォーマンス」タブ → 録画ボタンを押してページをリロード
- フレームの中で赤くなっている箇所（長いタスク）がボトルネック
- 「ソース」タブ → Ctrl+Shift+P → 「coverage」と入力 → 「Show Coverage」を選択
- リロードすると、各JSとCSSの未使用率（赤いバー）が表示される
未使用率が高いスクリプトは削除かページ単位での読み込み制御の候補です。WordPressの場合は 「Asset CleanUp」 を使うとページごとに不要なスクリプトをオフにできます。
③ サーバーの応答速度（TTFB）
TTFB（Time to First Byte）とは、ブラウザがリクエストを送信してから最初の1バイトが返ってくるまでの時間です。TTFBが遅いとLCPを含むその後のすべての処理が連鎖的に遅くなります。
TTFBの目安は 800ms以内 が良好とされています。PageSpeed Insightsの「サーバーの初期応答時間を短縮する」という警告が出ている場合はTTFBが原因です。
改善策としては、キャッシュの導入（後述）、CDNの利用、サーバープランのアップグレードが有効です。共有サーバーでリソースが逼迫している場合は、上位プランへの移行が最も根本的な解決策になります。
WordPressでの改善方法
① 画像をWebPに変換・遅延読み込みを設定する
プラグイン 「EWWW Image Optimizer」 または 「Imagify」 を使うと、既存画像のWebP変換と圧縮が自動で行えます。新規アップロード時も自動変換されるので、設定しておくだけで維持できます。
また、ファーストビュー以外の画像には loading="lazy" を指定しておくと、スクロールしてから初めて読み込まれるようになりLCPの改善につながります。WordPressはデフォルトで遅延読み込みが有効ですが、ヒーロー画像には適用しないよう注意が必要です。
② キャッシュプラグインを導入する
「W3 Total Cache」 や 「WP Super Cache」 を使うと、ページをHTMLとして保存しておくことでサーバーの処理負荷を減らし、表示速度が改善されます。ConoHa WINGなどのレンタルサーバーを使っている場合は、サーバー側のキャッシュ機能と競合しないよう設定を確認しましょう。
③ 不要なプラグインを削除・JSを遅延読み込みする
使っていないプラグインはスクリプトを読み込んでいることがあります。定期的に棚卸しして不要なものは削除しましょう。「Asset CleanUp」 を使うと、ページごとに不要なスクリプトをオフにできます。
④ CDNを活用する
Cloudflareの無料プランを使うと、静的ファイルをCDN経由で配信できるためモバイル回線でも高速化されます。設定も比較的かんたんで、ConoHa WINGなどの主要サーバーはCloudflareとの連携に対応しています。
AIクローラーはモバイルの挙動をどこまで見ているか
ここが正直一番気になるところだと思います。AIクローラーはモバイルのレンダリング状態をどこまで考慮しているのでしょうか。
AIクローラーはURL単位でページを取得する
GPTBot（OpenAI）・ClaudeBot（Anthropic）・PerplexityBotはいずれもURL単位でHTTPリクエストを送り、HTMLを取得します。このとき基本的にはデスクトップ版のUser-Agentでアクセスしてくることがほとんどで、モバイル版のレンダリングを再現しているわけではありません。
つまり厳密に言えば、AIクローラーが「モバイルで遅い」という状況を直接体験しているわけではないということです。
ただしGoogleインデックス経由の評価は別の話
問題は、AIが参照するソースの多くがGoogleのインデックス情報に依存しているという点です。GoogleはモバイルファーストインデックスでSPのパフォーマンスを基準に評価しています。モバイルスコアが低いとGoogleの評価が下がり、結果としてAIが参照するリストから外れる可能性があります。
SPレンダリングが悪いとAIにノイズとして映る可能性
もう一つ考えられるのは、モバイルで表示崩れやCLSが発生しているページは、AIがHTMLを解析する際にコンテンツ構造が読みにくくなるリスクです。レイアウトのガタつきやJSによって後から書き換えられるコンテンツは、AIが意図したテキストを正確に抽出できないケースがあります。構造化データやE-E-A-Tの整備と同様に、AIにとって読みやすいHTML構造を保つという観点でもページ速度は無関係ではありません。
モバイル60点のサイトはAIに引用されるのか
結論から言うと、モバイルスコアが60点でもAIに引用されることはあります。AIクローラーが直接モバイルのレンダリング速度を評価しているわけではないからです。
ただし以下の間接的なリスクは無視できません。
- Googleの評価低下 → AIが参照するインデックスからの露出減
- HTMLが重い → クロールバジェットの消費 → クロール頻度が下がる
- ユーザー体験が悪い → 離脱率上昇 → AIが「信頼されていないページ」と判断しやすくなる
つまり「今すぐ引用されなくなる」わけではないが、長期的に引用される確率が下がっていくという理解が正確だと思います。
改善してから反映されるまでの時間
ページ速度を改善した後に見落としがちなのが、「改善したのになぜかスコアが変わらない」「AIに引用される気配がない」という状況です。これはほとんどの場合、インデックスの更新に時間がかかっているのが原因です。
Search Consoleでインデックス再リクエストをする
ページを改善したら、Google Search ConsoleのURL検査ツールから「インデックス登録をリクエスト」を送信しましょう。これをしないと次にGooglebotが自然にクロールしてくるまで待つことになり、数日〜数週間かかることもあります。
手順はシンプルです。Search Console → URL検査 → 対象URLを入力 → 「インデックス登録をリクエスト」ボタンを押す。これだけでGoogleへの再クロール要求が出せます。
再インデックスからAIクローラーが再訪するまでの時間感覚
リクエスト後にGooglebotが再訪するまでは数日〜1週間程度が目安です。ただしGoogleのインデックスが更新されてからAIがその情報を反映するまでにさらに時間差があります。
GPTBotやClaudeBotなどのAIクローラーが自発的に再訪するサイクルは、サイトの更新頻度や被リンク数によって変わりますが、一般的には数週間〜1ヶ月単位で見ておく必要があります。
改善してすぐに結果を求めるのではなく、「Search Consoleでリクエスト → 1〜2週間後に再計測 → さらに1ヶ月後にAI引用状況を確認」という流れで焦らず検証するのが現実的です。
INP 288msを実際に改善してみよう
AI観測ラボのデスクトップ計測でINPが288ms（要改善）という結果が出ていました。INPはページ上での操作（クリック・タップ・キーボード入力）に対してどれだけ素早く画面が反応するかを示す指標で、200ms以内が良好とされています。
INPが遅くなる主な原因はメインスレッドの詰まりです。重いJavaScriptが実行されている間は、ユーザーの操作への応答が後回しになります。
具体的な改善手順：
- Chrome DevToolsの「パフォーマンス」タブで「INP」を確認し、どのインタラクションが遅いかを特定する
- 「Long Tasks（50ms超のタスク）」を洗い出し、原因スクリプトを特定する
- WordPressの場合、重いJSを持つプラグイン（スライダー・チャット系・ポップアップ系）を見直す
- JavaScriptを
deferまたはasync属性で非同期読み込みにする - 「Asset CleanUp」 や 「Perfmatters」 で不要なスクリプトをページ単位でオフにする
INPはLCPほど即効性がある改善ではなく、原因特定に少し手間がかかります。まずLCPとTTFBを改善してから取り組むのが現実的な順序です。
余談：DevToolsのエミュレーションが良くてもPSIが低い理由
Chrome DevToolsのモバイルエミュレーション（iPhone 14 Pro Maxなど）で計測すると全指標グリーンになることがあります。しかしPageSpeed Insightsでは60点という結果が出る、というギャップが生じることがあります。
これはDevToolsのエミュレーションがブラウザ上での模擬にすぎず、実際のモバイル回線の遅さや端末の処理能力を再現していないからです。PageSpeed Insightsはより現実のモバイル環境に近い条件で計測するため、こちらの数値の方が実態に近いと考えてください。
さらに言うと、speedtestで回線速度が良好でない環境のユーザーも当然アクセスしてきます。PageSpeed Insightsのスコア改善は「回線が遅い環境のユーザーへの配慮」でもあります。エミュレーションで安心せず、PSIの数値を基準に改善を進めましょう。
優先度・即効性マップ：どれから手をつけるか
改善項目が多いと何から始めればいいか迷います。即効性と難易度で整理するとこうなります。
| 改善項目 | 即効性 | 難易度 | 優先度 |
|---|---|---|---|
| 画像をWebPに変換（EWWW等） | 高 | ★☆☆ | 🔴 最優先 |
| キャッシュプラグイン導入 | 高 | ★☆☆ | 🔴 最優先 |
| 不要プラグイン削除 | 中〜高 | ★☆☆ | 🔴 最優先 |
| ヒーロー画像にfetchpriority=”high” | 高 | ★★☆ | 🟠 早めに対応 |
| CDN（Cloudflare）導入 | 中 | ★★☆ | 🟠 早めに対応 |
| レンダリングブロックJS特定・除去 | 中 | ★★★ | 🟡 余裕があれば |
| INP改善（Long Tasks特定） | 低〜中 | ★★★ | 🟡 余裕があれば |
| サーバープランのアップグレード | 高 | ★☆☆ | 🔵 費用対効果で判断 |
まず最優先の3つ（画像変換・キャッシュ・不要プラグイン削除）だけ対応しても、モバイルスコアが10〜20点改善するケースは珍しくありません。難しいことに手を出す前に、この3つをやりきるのが一番コスパの高い動き方です。
計測・改善のチェックリスト
| 確認項目 | 難易度 |
|---|---|
| PageSpeed Insightsでモバイル・デスクトップ両方を計測した | ★☆☆ |
| LCP・CLS・INPの現状スコアを把握した | ★☆☆ |
| 画像をWebP形式に変換している（EWWW等） | ★☆☆ |
| ヒーロー画像にfetchpriority=”high”を指定している | ★★☆ |
| キャッシュプラグインを導入している | ★☆☆ |
| 不要なプラグインを削除した | ★☆☆ |
| CDN（Cloudflare等）を導入している | ★★☆ |
| 改善後に再計測して数値の変化を確認した | ★☆☆ |
| Search ConsoleでインデックスリクエストをURLごとに送信した | ★☆☆ |
| 1〜2週間後に再計測してスコア変化を記録した | ★☆☆ |
まとめ：計測→改善→再リクエスト→待つ、がセットで1サイクル
ページ速度の改善は「なんとなく遅い気がする」という感覚では動けません。まずPageSpeed Insightsで現状を数値化することが第一歩です。
今回AI観測ラボを計測してみてわかったのは、デスクトップが問題なくてもモバイルが全然別のスコアになっているということです。AIクローラーがモバイルのレンダリングを直接体験しているわけではないとしても、Googleインデックスへの影響・クロールバジェットの消費・ユーザー体験の悪化という3つの間接経路でAIへの露出に影響します。
改善したらSearch Consoleで再インデックスをリクエストして、1〜2週間後に再計測する。AIへの反映はさらにその先になるので、焦らず1ヶ月単位で検証する。このサイクルを回すことが現実的な改善の進め方です。
他のAI最適化設定との組み合わせについては、AIクローラーとは？引用されるサイト設計の基本と8つの対策も参考にしてみてください。
参考文献
- PageSpeed Insights – Google
- Core Web Vitals – web.dev
- Core Web Vitals and Google Search – Google Search Central
- Largest Contentful Paint (LCP) – web.dev
- Interaction to Next Paint (INP) – web.dev
- Google Search Console – Google
※ 本記事はAI観測ラボが独自に計測・検証した内容をもとに執筆しています。
あなたのサイトは、
AIに見えていますか？
URLを入力するだけで30秒。8項目を自動診断し、優先度別の改善プランを提示します。完全無料・登録不要。
