AI予測モデルを用いたサイト表示速度（Core Web Vitals）の自動最適化

LCP2.5秒の壁を突破する：AI行動予測とSpeculation Rules APIによる動的プリフェッチ実装詳解

2026年1月5日約12分で読めます

文字サイズ:

LCP2.5秒の壁を突破する：AI行動予測とSpeculation Rules APIによる動的プリフェッチ実装詳解

この記事の要点

AIによるユーザー行動予測でリソースを先読み
Core Web Vitals（特にLCP）の劇的な改善
Speculation Rules APIを活用した次世代の高速化

導入：静的な最適化の限界と「予測」への転換

Webパフォーマンス改善のプロジェクトにおいて、「これ以上何をすればいいのか分からない」という課題に直面することは少なくありません。画像の次世代フォーマット化、JavaScriptの遅延読み込み、CDNのキャッシュ設定など、教科書通りの施策をすべて行っても、LCP（Largest Contentful Paint）が2.5秒の壁を切れない、あるいはINP（Interaction to Next Paint）が改善しないといったケースです。

このような状況において、静的なリソース最適化だけで対応できる範囲には限界があります。

ユーザーが次にどのページを開くか分からない状態で、すべてのリソースを最適化しようとするのは、効率的とは言えません。これからのWebパフォーマンスは、「ユーザーが次に何をするか」を予測し、先回りして準備する「投機的（Speculative）な戦術」が重要になると考えられます。

しかし、安易なプリフェッチ（先読み）は、ユーザーの通信帯域を無駄に消費する可能性があります。予測精度が低いまま大量のリソースを先読みすることは、UXを向上させるどころか、逆にネットワークを圧迫し、体験を悪化させるリスクさえあります。

本記事では、この課題を解決するアプローチとして、AIによる高精度な行動予測と、ブラウザの最新標準であるSpeculation Rules APIを組み合わせた実装手法を解説します。AIを実用的な手段として活用し、データサイエンスとフロントエンドエンジニアリングを融合させることで、投資対効果（ROI）を最大化しつつユーザー体験を向上させるための実践的な手法を紐解いていきます。

1. AI予測による速度最適化のアプローチと準備

なぜ「予測」が必要なのか：静的最適化の限界

従来の<link rel="prefetch">やdns-prefetchといったResource Hintは、開発者が「重要だと思われるリソース」を手動、あるいは静的なルールで指定するものでした。しかし、ユーザーの関心は文脈によって変わります。トップページから「製品一覧」に行く人もいれば、「採用情報」を見る人もいます。これら全てをプリフェッチすれば、初期ロードが重くなり、本末転倒です。

ここで、AIを用いた予測アプローチが有効になります。過去の膨大なアクセスログから「現在のページがAなら、70%の確率でBへ、20%でCへ遷移する」という確率モデルを構築します。この確率に基づいて、「本当に遷移する可能性が高いページだけ」をブラウザに先読みさせるのです。

実装の全体像：データ収集から推論、プリフェッチ実行まで

今回構築するシステムの全体像は以下の通りです。

データ収集: Google Analytics 4 (GA4) の生データをBigQueryへエクスポート。
モデル学習: BigQuery上で遷移確率（マルコフ連鎖など）を計算し、学習モデル（または確率テーブル）を生成。
推論・配信: ユーザーがページを閲覧中、現在地に基づいて次ページの候補を予測。
ブラウザ制御: Speculation Rules APIを用いて、ブラウザに「投機的読み込み」を指示。

前提環境と必要なツールセット

実装に着手する前に、以下のスタックが利用可能か確認してください。

Google Analytics 4 (GA4): ユーザー行動の追跡。
BigQuery: GA4データの格納とSQLによる分析。
Node.js環境: ビルドプロセス（Webpack/Vite）への組み込み。
Speculation Rules API対応ブラウザ: 主にChrome 108以降（非対応ブラウザへのフォールバックも解説します）。

これらの環境を前提として、データパイプラインの構築手順を見ていきましょう。

2. Step 1：ユーザー行動データの収集と学習用データセット構築

Step 1：ユーザー行動データの収集と学習用データセット構築 - Section Image

AIモデルの精度は、入力されるデータの品質に大きく依存します。Webサイトの遷移予測において最も重要なのは、「ページAからページBへの遷移」をいかに正確に抽出するかです。

GA4/BigQueryを用いた遷移データの抽出クエリ

GA4のデータはイベントベースです。page_viewイベントを時系列に並べ、セッションごとに「前のページ」と「次のページ」のペアを作成する必要があります。以下は、BigQueryで遷移ペアを抽出するための基本的なSQLクエリです。

WITH PageViews AS (
  SELECT
    user_pseudo_id,
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id,
    event_timestamp,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_location
  FROM
    `your-project.analytics_123456789.events_*`
  WHERE
    event_name = 'page_view'
    AND _TABLE_SUFFIX BETWEEN '20231001' AND '20231031'
)

SELECT
  CurrentPage,
  NextPage,
  COUNT(*) AS Transitions
FROM (
  SELECT
    page_location AS CurrentPage,
    LEAD(page_location) OVER (
      PARTITION BY user_pseudo_id, session_id 
      ORDER BY event_timestamp
    ) AS NextPage
  FROM
    PageViews
)
WHERE
  NextPage IS NOT NULL
GROUP BY
  CurrentPage, NextPage
HAVING
  Transitions > 10 -- ノイズ除去のための閾値
ORDER BY
  CurrentPage, Transitions DESC

解説:
このクエリでは、LEAD関数を使って「次のページ」を取得しています。PARTITION BYでセッションごとに区切ることで、異なるセッション間の無関係な遷移が混ざるのを防いでいます。

データの整形：ページパスと次ページ遷移のペアリング

生のURLにはクエリパラメータ（?utm_source=...など）が含まれていることが多く、そのままでは同一ページとして集計されません。SQL内、あるいはデータ抽出後の処理で、以下のような正規化を行う必要があります。

クエリパラメータの削除（サイト内検索など意味のあるパラメータは残す）。
末尾のスラッシュの統一。
アンカーリンク（#section）の除去。

プライバシーへの配慮とデータ利用の同意管理

プロジェクトを推進する上で、プライバシーや倫理的な側面への配慮は不可欠です。ユーザーの行動データをAI学習に利用する場合、GDPRやCCPAなどの規制に抵触しないよう注意が必要です。GA4の設定でIPアドレスの匿名化が行われているか、Cookie同意バナーで「分析用Cookie」への同意が得られたユーザーのデータのみを使用しているかなど、法務担当者と連携した確認プロセスを設けることが重要です。パフォーマンス向上のために、ユーザーからの信頼やコンプライアンスを犠牲にすることは避けるべきです。

3. Step 2：遷移予測モデル（Markov Chain / ML）の実装

データが揃ったら、次は「予測モデル」の実装です。ここでは、Googleが開発に関与していたオープンソースライブラリ「Guess.js」のアプローチを参考にしつつ、より現代的かつ持続可能な実装方法を検討します。

軽量モデルの選択：クライアントサイド推論 vs サーバーサイド推論

予測を行う場所には、大きく分けて2つの選択肢があります。

ビルド時/サーバーサイド: 過去のデータから「ページA→ページB」という静的なマッピングファイル（JSONなど）を生成し、クライアントに配信する。
クライアントサイド（リアルタイム）: TensorFlow.jsなどをブラウザで動かし、ユーザーのリアルタイムな操作（マウスの動きなど）も含めて推論する。

実務的なプロジェクト運用の観点からは、「ビルド時生成モデル（マルコフ連鎖ベース）」の採用が推奨されます。

クライアントサイドでの推論は強力ですが、ブラウザのメインスレッドを占有しやすく、Interaction to Next Paint (INP) などのCore Web Vitals指標を悪化させるリスクがあります。一方、ビルド時生成モデルは「過去に多くの人が通った道は、次も通る可能性が高い」という単純な法則に基づいており、実行時のオーバーヘッドがほぼゼロです。

Guess.jsライブラリを活用した簡易実装フロー

Guess.jsは、Google Analytics (GA) のデータを解析し、Webpackなどのバンドラと連携してプリフェッチ命令を自動生成する先駆的なライブラリです。概念を理解するために、Webpack設定ファイル（webpack.config.js）への導入例を見てみましょう。

const { GuessPlugin } = require('guess-webpack');

// 日付設定の動的な生成（直近30日を対象とする例）
const today = new Date();
const thirtyDaysAgo = new Date();
thirtyDaysAgo.setDate(today.getDate() - 30);

module.exports = {
  // ...既存の設定
  plugins: [
    new GuessPlugin({
      // GAのビューID
      GA: '12345678',
      
      // BigQueryやローカルファイルからデータを取得する場合の設定（実運用ではこちらを推奨）
      // reportProvider: () => Promise.resolve(JSON.parse(fs.readFileSync('./routes.json'))),
      
      runtime: {
        delegate: false, // ブラウザ側での実行制御をオフにし、データのみを利用
      },
      routeProvider: false,
      period: {
        startDate: thirtyDaysAgo,
        endDate: today
      }
    })
  ]
};

このプラグインを導入すると、ビルド時にGAからデータを取得し、各ページバンドルの中に「次に遷移する確率が高いルート情報」を埋め込んでくれます。

注意点として、 Guess.js自体は更新頻度が低下している場合があります。そのため、現代的なプロジェクトでは、この「GAデータから遷移確率を算出するロジック」のみを参考にし、Node.jsスクリプト等で自前のJSON生成処理（ETLパイプライン）を構築するのが一般的です。

また、より高度な予測モデル（TensorFlow等）を自作してサーバーサイドで学習させる場合、Python環境の構築には注意が必要です。最新のTensorFlow環境（特にWindowsでのGPU利用時）ではWSL2（Windows Subsystem for Linux 2）の使用が推奨されるなど、プラットフォームごとの要件が変化しています。学習環境を構築する際は、必ず公式サイトで最新のセットアップガイドを確認してください。

今回は、Guess.js等で生成された「予測データ（JSON）」のみを利用し、プリフェッチの実行部分は最新のSpeculation Rules APIに合わせて自作するアプローチを採用します。

4. Step 3：Speculation Rules APIによる投機的プリフェッチの適用

Step 3：Speculation Rules APIによる投機的プリフェッチの適用 - Section Image

ここからは、予測結果を実際のパフォーマンス改善につなげる実装フェーズです。AI（統計モデル）が弾き出した予測結果に基づき、ブラウザに対して強力な先読み指示を出します。

Speculation Rules APIの基本構文とJSON設定

Speculation Rules APIは、<script type="speculationrules">タグの中にJSON形式でルールを記述します。従来の<link rel="prefetch">と異なり、ドキュメント全体のプリレンダリング（描画まで完了させる）も可能です。

{
  "prefetch": [
    {
      "source": "list",
      "urls": ["/next-page", "/another-page"],
      "requires": ["anonymous-client-ip-when-cross-origin"]
    }
  ],
  "prerender": [
    {
      "source": "list",
      "urls": ["/highly-likely-page"],
      "score": 0.8
    }
  ]
}

AI予測スコアに基づく動的なルール注入スクリプト

予測確率（Confidence Score）に応じて、処理を使い分けるのが重要です。

確率 80%以上: prerender（ページを完全に描画しておく。遷移は一瞬。）
確率 50%以上: prefetch（リソースだけダウンロードしておく。）
それ以下: 何もしない（帯域節約。）

以下は、予測データを受け取り、動的にSpeculation RulesをDOMに挿入するJavaScript関数の例です。

/**
 * 予測データに基づいてSpeculation Rulesを注入する
 * @param {Array<{url: string, score: number}>} predictions
 */
function injectSpeculationRules(predictions) {
  // 既存のルールがあれば削除（SPA遷移時などのため）
  const existing = document.getElementById('ai-speculation-rules');
  if (existing) existing.remove();

  const prerenderUrls = [];
  const prefetchUrls = [];

  predictions.forEach(p => {
    if (p.score >= 0.8) {
      prerenderUrls.push(p.url);
    } else if (p.score >= 0.5) {
      prefetchUrls.push(p.url);
    }
  });

  const rules = {
    prerender: [
      {
        source: 'list',
        urls: prerenderUrls
      }
    ],
    prefetch: [
      {
        source: 'list',
        urls: prefetchUrls
      }
    ]
  };

  const script = document.createElement('script');
  script.type = 'speculationrules';
  script.id = 'ai-speculation-rules';
  script.textContent = JSON.stringify(rules);
  document.body.appendChild(script);
}

この関数を、ページ遷移完了時（Next.jsならuseEffectやRouterイベント）に呼び出し、現在のページに対応する予測データを渡します。

ブラウザ互換性とフォールバック

Speculation Rules APIはまだ全ブラウザでサポートされていません（主にChrome/Edge系）。SafariやFirefox向けには、従来の<link rel="prefetch">を動的に生成するフォールバック処理を実装する必要があります。機能検知を行い、APIが存在しない場合は従来のメソッドに切り替えるフォールバックロジックを組み込むことが、堅牢なシステム構築において重要です。

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  // Speculation Rules APIを使用
  injectSpeculationRules(predictions);
} else {
  // 従来のlink prefetchを使用
  injectLinkPrefetch(predictions);
}

5. Step 4：効果測定とパラメータチューニング

4. Step 3：Speculation Rules APIによる投機的プリフェッチの適用 - Section Image 3

システムは実装して終わりではなく、AIモデルが期待通りに機能し、ROIに貢献しているかを継続的にモニタリングする必要があります。

Chrome UX Report (CrUX) とLighthouseでの検証

導入後、Core Web Vitalsのスコアがどう変化したかを確認します。

LCP (Largest Contentful Paint): プリレンダリングが成功すれば、ほぼ0秒に近い遷移が可能になり、LCPは改善すると考えられます。
INP (Interaction to Next Paint): 必要なリソースが既にキャッシュにあれば、クリック後の反応速度も向上すると考えられます。

予測精度（Precision/Recall）のモニタリング体制

「予測したページにユーザーが実際に遷移したか」を計測します。この検証を怠ると、不要な通信が発生し、インフラコストの増加を招く恐れがあります。

Precision（適合率）: プリフェッチしたページのうち、実際に遷移された割合。
Recall（再現率）: 実際に遷移したページのうち、プリフェッチ済みだった割合。

Precisionが低い場合は、予測モデルの閾値（スコア0.5など）を厳しく見直すべきです。予測精度の低下は、サーバーコストの増加やユーザーの通信帯域の浪費に直結するため、定期的なチューニングが求められます。

「無駄な読み込み」による帯域圧迫の回避設定

ユーザーがモバイル回線（4G/5G）を使用している場合や、「データセーバー」モードをオンにしている場合は、プリフェッチを抑制する配慮が必要です。navigator.connection.saveData プロパティを確認し、trueの場合はプリフェッチを無効化、あるいはprerenderではなく軽量なprefetchに留めるなどの動的制御を実装してください。

6. トラブルシューティングと本番運用の注意点

最後に、本番運用に向けてプロジェクトマネジメントの観点から注意すべき点を整理します。

Private情報を含むページのプリフェッチ除外設定

システム運用上、特に注意すべきなのが「ログアウトURL」や「決済確定URL」のプリフェッチです。予測モデルが「ユーザーは次にログアウトする可能性が高い」と判断し、ブラウザがそれを先読みした瞬間、ユーザーは意図せずログアウトさせられてしまう可能性があります。

GETリクエストで副作用が発生するURL（本来あってはなりませんが）や、認証が必要なマイページなどは、除外リスト（Blocklist）に登録し、絶対にプリフェッチ対象にならないよう制御してください。

動的コンテンツ（カート情報等）の扱い

prerenderを使用する場合、ページがバックグラウンドで描画されます。そのため、例えば「カートの中身」が更新されたのに、プリレンダリングされた古い状態のページが表示されてしまうリスクがあります。BroadCastChannel APIなどを使って、タブ間で状態を同期するか、動的なデータはクライアントサイドでのフェッチ（SWRなど）に依存する設計にする必要があります。

まとめ：AIは「魔法」ではなく「高精度の羅針盤」

AIによる予測とSpeculation Rules APIの組み合わせは、パフォーマンス改善における強力な手段となります。しかし、AIはあくまで課題解決のための手段です。適切なデータパイプラインの構築、プライバシーへの配慮、そして継続的な精度のモニタリングといった堅実なプロジェクト運営があって初めて、実用的な価値と高いROIを生み出します。

本記事で解説したアプローチが、次世代のWebパフォーマンス向上と、ビジネス課題の解決に向けた一助となれば幸いです。

LCP2.5秒の壁を突破する：AI行動予測とSpeculation Rules APIによる動的プリフェッチ実装詳解 - Conclusion Image

コメントは1週間で消えます

コメントを読み込み中...