結論先出し: SSG と SSR はどう選ぶ？

Next.js でページを作るとき、まず問うべきは「このページのコンテンツは誰が見ても同じか？」という一点だ。ブログ記事・LP・用語集・コーポレートサイトのように、全ユーザーへ同一の内容を返すならビルド時に HTML を生成する SSG（Static Site Generation）一択。Vercel 等の CDN に静的ファイルを配信させれば、サーバー負荷ゼロで LCP を「Good」基準（2.5秒以下）に収めやすい（出典: web.dev — Largest Contentful Paint）。

一方、「このユーザーの注文履歴」「ログイン中のダッシュボード」「リアルタイムの在庫数」のようにリクエスト時点のデータが必要なページは SSR（Server-Side Rendering）または Next.js の動的ルートが正解だ。

さらに「1時間に1回程度の更新で十分」なコンテンツには ISR（Incremental Static Regeneration）という第3の選択肢がある。SSG の配信速度とSSR の更新鮮度を両立する現実解だ。

短い判断ルール:

  • SSGを選ぶべき人: コンテンツが全ユーザー共通・更新頻度が低〜中・速度とコストを最優先するサイト
  • SSRを選ぶべき人: ログイン・パーソナライズ・リアルタイムデータが必要なページを持つプロダクト
  • ISRを選ぶべき人: 定期更新はあるがリクエストごとの動的生成は不要な中間的コンテンツ（ECカテゴリ・ニュースサイト等）

それぞれの本質

SSG（静的サイト生成）とは

SSG はビルド時にすべての HTML を事前生成し、CDN に配置する戦略だ。Next.js では App Router でデフォルトの挙動となっており、fetch() にキャッシュ設定をしない場合、サーバーコンポーネントは自動的に静的レンダリングされる（出典: Next.js Docs — Static Rendering）。

強み:

  • ページはビルド済みの HTML ファイルとして CDN のエッジから配信されるため、サーバー処理が不要でTTFBが最小化される
  • Core Web Vitals のうち LCP を改善しやすく、Google が定める「Good」基準（2.5秒以下）に収めやすい（出典: web.dev — Largest Contentful Paint）
  • サーバーコストが低く、スパイクトラフィックへの耐性が高い
  • セキュリティ攻撃面（アタックサーフェス）が小さい

弱み:

  • コンテンツ更新のたびに再ビルドが必要（ページ数が数万件になるとビルド時間が課題になる）
  • ユーザー固有のコンテンツやリアルタイムデータは表示できない
  • ビルド時に存在しないパスは 404 になる（dynamicParams: true で回避可能）

SSR（サーバーサイドレンダリング）とは

SSR はリクエストごとにサーバーで HTML を生成して返す戦略だ。Next.js では fetch() に { cache: 'no-store' } を指定するか、cookies() / headers() / searchParams にアクセスすると動的レンダリングに切り替わる（出典: Next.js Docs — Dynamic Rendering）。

強み:

  • リクエスト時点の最新データを取得し、ユーザー固有のコンテンツを返せる
  • ログイン状態・セッション・Cookie に基づいたパーソナライズが可能
  • ビルドなしでコンテンツが即反映される

弱み:

  • リクエストごとにサーバー処理が走るため、TTFB が SSG より長くなりやすい
  • トラフィックの増加に比例してサーバーコストが上昇する
  • LCP を Good 基準内に収めるには Vercel の Streaming や Server Components の段階的レンダリングを活用する追加設計が必要

比較表 — 主要軸で並べる

比較軸SSGSSR
HTMLの生成タイミングビルド時（事前生成）リクエスト時（都度生成）
配信速度（TTFB）最速（CDNエッジから直接）中（サーバー処理が挟まる）
LCP 最適化しやすさ高（静的HTML+CDNで安定）中（Streaming活用で改善可）
INP への影響なし（ハイドレーション後はCSR）なし（同上）
サーバーコスト低（CDN配信・スケール不要）中〜高（トラフィック比例）
更新の即反映再ビルド必要即時反映
パーソナライズ対応不可（全ユーザー共通コンテンツのみ）可（Cookie・セッション参照可）
リアルタイムデータ不可可
SEO適性高（事前生成HTML・Googlebot即クロール）高（SSRも完全なHTML出力）
攻撃面（セキュリティ）小さい（静的ファイル配信）標準（サーバーエンドポイントあり）
向いているページ例ブログ・LP・用語集・会社概要ダッシュボード・検索結果・マイページ

ISR — SSGとSSRのハイブリッド

ISR（Incremental Static Regeneration）は「ビルド時に静的生成しつつ、指定秒数ごとにバックグラウンドで再生成する」戦略だ。Next.js では fetch() の next.revalidate で設定する（出典: Next.js Docs — Incremental Static Regeneration）。

typescript
// 24時間ごとに再生成（ブログ記事等）
const res = await fetch('https://api.example.com/posts', {
  next: { revalidate: 86400 }
});

// 1時間ごとに再生成（ECカテゴリ等）
const res = await fetch('https://api.example.com/categories', {
  next: { revalidate: 3600 }
});

ユーザーへの配信は常に静的キャッシュから行われるため TTFB は SSG 相当。再生成は次リクエスト時にバックグラウンドで走るため、読者は古い版を一時的に受け取ることがある（stale-while-revalidate 方式）。

ISRが向くコンテンツ:

  • ブログ記事（公開後の更新は稀・1日1回程度の鮮度で十分）
  • EC商品カテゴリ（在庫数はAPIで取るが、カテゴリ構造は1時間で十分）
  • 価格ページ（15〜30分間隔の再生成で実用的）
  • ニュース・プレスリリース（最新記事を短サイクルで追加）

使い分けフローチャート

code
ページのコンテンツはユーザーによって異なるか？
├── Yes（ログイン・パーソナライズ・Cart）
│     → SSR（動的レンダリング）
│
└── No（全ユーザー共通）
      └── どのくらいの頻度で更新が必要か？
            ├── ほぼ変わらない・または再ビルドで問題ない
            │     → SSG（静的生成）
            └── 定期的に変わる（数分〜数日単位）
                  ├── 秒単位の鮮度が必要
                  │     → SSR（または Route Handlers でクライアント fetch）
                  └── 数分〜数時間の鮮度で十分
                        → ISR（revalidate 設定）

ケース別: あなたはどちらを選ぶべきか

ケース1: コーポレートサイトや LPを新規構築する

→ SSGを推奨。会社概要・サービス説明・採用ページ・LP は全ユーザーへ同じコンテンツを返せばよい。SSG + Vercel CDN で LCP を安定的に 2.5 秒以下に抑えやすく、表示パフォーマンスが CVR に直結するマーケティングページには最適だ。Google／SOASTA の調査では読み込みが 1 秒から 3 秒に延びると直帰確率が 32% 上昇すると報告されており（出典: Think with Google — Mobile page speed: New industry benchmarks 2017）、SSG による速度確保は CVR 施策の土台になる。コンテンツ更新も再ビルドで十分な頻度のコーポレートサイトには過剰な動的処理は不要だ。

ケース2: SaaS・会員制サービスのダッシュボードを構築する

→ SSRを推奨。ログイン後のユーザーダッシュボード・注文履歴・パーソナライズされたレコメンドは、リクエスト時点のセッション情報と最新データが必要だ。Next.js の Server Components を活用し、機密データの取得をサーバー側に閉じながら CSR の比重を下げる設計が望ましい。認証トークンのハンドリングも cookies() アクセスで SSR に自然に切り替わるため、セキュリティ設計と整合する。TTFB が長くなる課題は Streaming（<Suspense>）で段階的にコンテンツを流すことで体感速度を改善できる。

ケース3: ブログ・pSEOコンテンツを大量に運用する

→ ISRを推奨。月数十〜数百件のブログ記事は SSG で全件ビルドするとビルド時間が伸びる。ISR の revalidate: 86400（24 時間）設定でビルド時間を許容範囲に抑えつつ、新規記事は初回アクセス時に生成・以降はキャッシュ配信するアプローチが現実解だ。SSG の配信速度を保ちながら記事追加のたびに全件再ビルドしなくて済む。Tufe Company のこのサイトも pSEO コンテンツ（用語集・エリア・業種記事）はこの方式で運用している（※ Tufe Company 内部実測 / 2026-05 時点）。

併用設計 — 1プロジェクト内で混在させる

Next.js App Router の強みはルート単位でレンダリング戦略を混在できることだ。同一プロジェクト内で以下のような分離が可能:

code
/                    → SSG（トップページ・静的LP）
/blog/[slug]         → ISR（revalidate: 86400）
/glossary/[slug]     → SSG（用語集・ほぼ変わらない）
/services/*          → SSG
/dashboard           → SSR（認証済みユーザー専用）
/search              → SSR（クエリパラメータを参照）
/api/*               → 動的（Route Handlers）
/tools/*             → CSR（クライアント fetch）

Tufe Company の本サイトもこの方針で運用している。/ /services/* /blog/* /glossary/* /compare/* はすべて SSG または ISR で配信し、API エンドポイントと一部ツールのみ動的処理としている（※ Tufe Company 内部実測 / 2026-05 時点）。

SSGとSEO・LLMOの関係

SSG は Core Web Vitals の観点で有利なだけでなく、AI 検索（LLMO）への対応という側面でも優位性がある。

Googlebot はレンダリング済みの HTML を優先的にクロールするが、SSG の完全な静的 HTML はクロールコストが最小で済む。AI クローラー（GPTBot・ClaudeBot 等）も同様に、サーバー処理待ちなしで完全な HTML を即時取得できる SSG ページの方がコンテンツを正確に把握しやすい。

さらに SSG サイトでは JSON-LD（構造化データ）をコンポーネントとして一元管理でき、ページタイプ別のスキーマを漏れなく実装しやすい。Next.js の <Script type="application/ld+json"> はビルド時に HTML に埋め込まれるため、JavaScript 実行前から Googlebot が構造化データを認識できる。

AI 検索引用の観点で重要な llms.txt も、Next.js の App Router なら app/llms.txt/route.ts で API ルートとして実装し、サイトのコンテンツ一覧を動的に生成できる（静的サイトを前提にした自動更新が可能）。

SSG・SSRの失敗パターン 5件

失敗1: 全ページをSSRにしてパフォーマンスが劣化する

「動的な部分があるページだから」と一括して SSR にすると、全リクエストでサーバー処理が走り TTFB が伸びる。Next.js では Server Components と <Suspense> を組み合わせ、静的な外枠は SSG、動的な部分はクライアント fetch またはストリーミングというハイブリッドが正解だ。

失敗2: ISRの revalidate を短く設定しすぎてSSRと変わらなくなる

revalidate: 1（1秒）に設定すると、実質的に毎リクエストごとに再生成が走り SSR と変わらない負荷になる。ISR は「数分以上の鮮度でよい」コンテンツに使うもので、秒単位の鮮度が必要なら素直に SSR または クライアント fetch を選ぶこと。

失敗3: ビルド時に全ページを生成して CI/CDが遅くなる

pages 数が1万件を超えると SSG のビルド時間が分単位から数十分単位に延びる（※ Tufe Company 内部実測 / N=支援先 EC・メディアサイト 8件 / 2026-05時点。具体的な閾値はホスティング・ビルド構成・ページサイズで変動）。generateStaticParams で優先ページ（トラフィック上位）だけ事前生成し、残りは初回アクセス時に生成（dynamicParams: true + fallback）する戦略に切り替えること（参考: Next.js Docs — generateStaticParams 取得 2026-05）。

失敗4: SSGページにユーザー固有情報を無理やり入れてセキュリティリスクを作る

SSG ページはキャッシュされた HTML が全ユーザーに共通配信される。「このユーザーの名前を表示したい」という要件を SSG ページで実現しようとすると、サーバーコンポーネントでセッション情報を取るか（→ 動的レンダリングに切り替わる）、クライアント fetch で取得する必要がある。無理に実装するとキャッシュに個人情報が乗るリスクがある。

失敗5: SSRページのmetadataを動的生成せず静的にしてしまう

SSR の動的ページで generateMetadata を使わず固定の metadata を設定すると、すべてのURLで同じタイトル・descriptionが出力される。検索エンジンのデュプリケートコンテンツ評価を下げる原因になるため、SSR・ISR・SSG のいずれにおいても generateMetadata でページ固有のメタを生成すること。

よくある誤解

誤解1: 「SSRの方がSEOに有利」

SSR も SSG も完全な HTML を出力するため、Googlebot からの SEO 評価に大きな差はない。むしろ LCP・INP・CLS という Core Web Vitals の指標で、SSG + CDN 配信の方がチューニングしやすく「Good」基準に収めやすい傾向がある。「SSR = 動的だからクローラーに有利」という俗説は誤りだ。

誤解2: 「静的サイトは更新が大変だから使えない」

Next.js の ISR を使えば revalidate に指定した秒数ごとに自動再生成されるため、CMS の更新が即座に反映される。ヘッドレス CMS（Sanity・Contentful 等）の Webhook と組み合わせれば、記事保存時にオンデマンド再検証（revalidatePath）を呼び出してほぼリアルタイムに更新できる（出典: Next.js Docs — Revalidating Data）。

誤解3: 「Next.jsはSSGしかできないのではないか」

Next.js App Router は SSG・SSR・ISR・CSR・Edge Runtime・Streaming をすべてサポートしており、ルート単位で自由に使い分けできる。Pages Router 時代の「getStaticProps = SSG」「getServerSideProps = SSR」という明示的な分離から、App Router では fetch() のキャッシュ設定によって自動的に判断される設計に変わった。

よくある質問

Q1. コストはどちらが安い？

SSG が大幅に安い。CDN に静的ファイルを置くだけなので、Vercel の Hobby プランでも実用的に運用できる。SSR はリクエストごとにサーバーの Function が実行されるため、トラフィックが増えるとコストが比例して増加する。規模によって大きく変わるため、Vercel の使用量ダッシュボードで実測しながら調整することが現実的だ。

Q2. 始めるならどっちから設計すればいい？

SSGをデフォルトとして設計を始め、「これはどうしてもリクエスト時の動的データが必要」というページだけ SSR に切り替えるアプローチが失敗しにくい。最初から全 SSR で設計して後からパフォーマンス問題を解くより、静的化できるものは静的化し、必要な部分だけ動的にする方が構成がシンプルになる。

Q3. SSRのページでもCore Web Vitalsを改善できるか？

できる。Next.js の Server Components + <Suspense> による Streaming レンダリング、Vercel の Edge Runtime 活用（export const runtime = 'edge'）、レスポンスの Cache-Control ヘッダー設定（SWR / stale-while-revalidate）などを組み合わせることで、SSR ページでも LCP を 2.5 秒以下に抑えるチューニングは可能だ。ただし SSG より設計の手間がかかる。

Q4. App RouterとPages Routerで使い分けは変わるか？

基本的な概念（静的 vs 動的）は変わらないが、設定方法が異なる。Pages Router では getStaticProps が SSG、getServerSideProps が SSR と明示的に分離されていた。App Router では fetch() の cache / next.revalidate オプションが分岐点になり、デフォルトが静的レンダリングになっている。新規プロジェクトは App Router を選ぶべきで、Pages Router は既存プロジェクトの保守フェーズでのみ使う（出典: Next.js Docs — App Router vs Pages Router）。

次のステップ 5項

  1. 今すぐ実行: Web CVR診断ツール で現在のサイトの Core Web Vitals スコアを計測し、SSG/SSR どちらの戦略が改善効果を出しやすいか把握する
  2. 構造化データを整備: SSG サイトでは JSON-LD を一元管理しやすい。Schema Markup Library で業種別の JSON-LD テンプレートを取得し、Next.js コンポーネントとして実装する
  3. LLMO対応を追加: SSG + AI Search Integration Pack で llms.txt を自動生成し、AI 検索クローラーへのコンテンツ誘導を整備する
  4. プラットフォーム選定全体を確認: WordPress vs Next.js 比較記事 でフレームワーク選定の全体軸を確認する
  5. ヘッドレス構成を検討中なら: Headless CMS vs WordPressプラグイン LLMO対応の現実コスト で移行コストと LLMO 効果のトレードオフを把握する

SSG・SSRの知識を深めるセルフチェックリスト

現在のサイト設計が適切かを確認する。

  • 全ページを SSR にしていないか（静的に出来るページは SSG で十分）
  • ISR の revalidate 値はコンテンツの更新頻度に合っているか
  • ユーザー固有のデータを SSG ページのサーバーコンポーネントで取っていないか
  • Core Web Vitals の LCP・INP・CLS を PageSpeed Insights で定期計測しているか
  • 動的ページで generateMetadata を使ってページ固有のメタを出力しているか
  • AI クローラー（GPTBot・ClaudeBot 等）を robots.txt でブロックしていないか
  • SSR ページに Cache-Control ヘッダーを適切に設定しているか
  • ビルド時間が長くなってきたら、ISR + オンデマンド再検証への移行を検討したか

Tufe Company が提供するソリューション

Tufe Company は SSG・SSR・ISR の選定から実装・継続的なパフォーマンス改善まで一気通貫で対応している。「どのレンダリング戦略が自社に合うか」の要件整理から入り、構造化データ・Core Web Vitals 最適化・LLMO 対応まで同時に設計する。

関連サービス・プロダクト:

  • Web制作・高速サイト構築サービス — SSG/SSR/ISR の最適な使い分けを要件から設計し、Vercel 等のエッジ配信まで含めた実装を提供
  • Schema Markup Library — Next.js コンポーネントとして使える業種別 JSON-LD テンプレ集。SSG で一元管理するのに最適な形式で提供（JSON-LD の重複・漏れをなくす）
  • LLMO Optimization Pack — SSG/SSR サイト問わず、llms.txt + 構造化データ + AI Overview 引用を最適化するフルパック。Headless 構成にも WP 既存サイトにも対応
  • AI Search Integration Pack — URL を入れるだけで llms.txt / robots.txt / 構造化データを即時生成。SSG サイトの LLMO 入門として最短で土台を整備できる

関連記事・比較:

まとめ: 決定のためのチェックリスト

  • ページのコンテンツが全ユーザー共通かどうか確認した（共通なら SSG が有力）
  • ログイン・セッション・Cookie への依存があるかを洗い出した（依存あれば SSR）
  • 更新頻度を把握し、ISR の revalidate 秒数の候補を出した
  • 1プロジェクト内でルートごとに SSG・SSR・ISR を混在させる設計を検討した
  • Core Web Vitals（LCP・INP・CLS）の目標値を設定し、計測環境を用意した
  • 構造化データ（JSON-LD）を SSG コンポーネントで一元管理する実装方針を決めた
  • AI クローラー向けに llms.txt の設置計画を立てた

判断に迷ったら、無料相談 で御社のページ構成・更新頻度・パフォーマンス要件を確認し、最適なレンダリング戦略をご提案します（45分・オンライン・契約前提なし）。