CSR・SSR・SSG・ISRの違いを図解で理解する
フロントエンド開発トレンドCSR・SSR・SSG・ISRの違いをわかりやすく解説します。それぞれのHTMLが「いつ・どこで」生成されるかを整理し、コーポレートサイトへの推奨適用例もまとめています。
はじめに
Next.jsを使ったフロントエンド開発の文脈で必ず出てくる「CSR・SSR・SSG・ISR」というアルファベット4種類。それぞれ異なるレンダリング（画面表示）の方法を指しており、どれを選ぶかによってWebサイトの表示速度・SEO・更新の仕組みが大きく変わります。
本記事では、非エンジニアの担当者にも理解できるよう、各レンダリング方式を「いつ・どこでHTMLが生成されるか」という観点からわかりやすく解説します。
レンダリングとは何か
「レンダリング（Rendering）」とは、コンテンツデータをブラウザに表示できるHTML形式に変換するプロセスです。
ユーザーがWebサイトを開くと、ブラウザはHTMLを受け取って画面に表示します。このHTMLが「いつ・どこで」生成されるかによって、4つのレンダリング方式に分類されます。
CSR（Client-Side Rendering：クライアントサイドレンダリング）
仕組み
HTMLの生成をユーザーのブラウザ（クライアント）上で行う方式です。
メリット・デメリット
メリット：ページ遷移が速い（一度読み込んだら次のページへの移動がスムーズ）・リアルタイムな更新が得意
デメリット：初期表示が遅い（JavaScriptの読み込みを待つ必要がある）・SEOが弱い（検索エンジンのクロール時にコンテンツが存在しない可能性）
向いているユースケース
ログイン後の管理ダッシュボード（SEOが不要）
リアルタイムで更新されるデータ（株価・チャット等）
頻繁にデータが変わるインタラクティブなアプリ
SSR（Server-Side Rendering：サーバーサイドレンダリング）
仕組み
HTMLの生成をサーバー上でリクエストごとに行う方式です。
WordPressが採用している基本的な仕組みがSSRに相当します。
メリット・デメリット
メリット：SEOに強い（完全なHTMLが返るため検索エンジンが読める）・常に最新データを表示できます
デメリット：リクエストのたびにサーバー処理が発生するため、高負荷時に遅くなることがある・サーバーコストが高いです
向いているユースケース
ユーザーごとにパーソナライズされたコンテンツ（マイページ等）
リアルタイムで最新データが必要でSEOも重要なページ
ログイン状態によって異なるコンテンツを表示するページ
SSG（Static Site Generation：静的サイト生成）
仕組み
HTMLの生成をビルド時（デプロイ前）に行い、生成済みのHTMLをCDNで配信する方式です。
メリット・デメリット
メリット：最速の表示速度（CDNから静的ファイルを返すだけ）・サーバー負荷がない・セキュリティが高い・コストが低いです
デメリット：コンテンツを更新するたびにビルドが必要・ビルド時間が長くなると更新が遅れる・ユーザーごとに異なるコンテンツには対応しにくい
向いているユースケース
コーポレートサイト（更新頻度が低い）
ランディングページ
ドキュメントサイト
ブログ（記事数が少ない場合）
ISR（Incremental Static Regeneration：インクリメンタル静的再生成）
仕組み
SSGのメリット（高速・低コスト）を維持しながら、コンテンツを定期的に自動更新するNext.js独自の方式です。
「60秒ごとに自動更新」「コンテンツ変更時にオンデマンドで再生成」という設定が可能です。
メリット・デメリット
メリット：SSGの速度を維持しながらコンテンツを自動更新・大量ページがあってもビルド時間が増大しない・キャッシュ戦略の柔軟な設計が可能
デメリット：設定が複雑・更新のタイミングがリアルタイムではない（設定した間隔に依存）
向いているユースケース
大量の記事を持つブログ・ニュースサイト
ヘッドレスCMSと連携したサイト（コンテンツ更新を自動反映）
ECサイトの商品ページ（在庫状況等の更新が必要だが完全リアルタイムでなくてもよい）
4つのレンダリング方式の比較表
比較軸 | CSR | SSR | SSG | ISR |
HTMLの生成タイミング | アクセス時（ブラウザ） | アクセス時（サーバー） | ビルド時 | ビルド時＋定期再生成 |
初期表示速度 | 遅い | 中程度 | 最速 | 最速 |
SEO | 弱い | 強い | 最強 | 最強 |
コンテンツの鮮度 | リアルタイム | リアルタイム | ビルド時 | 設定間隔ごと |
サーバー負荷 | なし | 高い | なし | 低い |
向いているサイト | SPAアプリ | 動的な個人化 | コーポレートサイト | メディア・EC |
Next.jsでの実際の使い方
Next.jsのApp Routerでは、ページ・コンポーネントのコードで使い方を決める。
Server Components（デフォルト）：SSR/SSGに近い動作。サーバーサイドでのデータ取得・HTMLの生成。
fetchのキャッシュ設定でISR相当を実現：
cache: 'force-cache' → ビルド時に生成してキャッシュ（SSG相当）
next: { revalidate: 60 } → 60秒ごとに再生成（ISR相当）
cache: 'no-store' → アクセスのたびに生成（SSR相当）
'use client'ディレクティブ：クライアントコンポーネントの宣言（CSR相当）
一つのNext.jsサイトの中で、ページ・コンポーネントごとに最適なレンダリング方式を使い分けることができます。これがNext.jsの大きな強みの一つです。
コーポレートサイトへの推奨適用例
ページ | 推奨方式 | 理由 |
トップページ | SSG | 更新頻度低・SEO最重要・最速表示が必要 |
サービス説明ページ | SSG | 同上 |
ニュース一覧 | ISR（5分更新） | 定期的な更新が必要・SEO重要 |
ニュース詳細 | ISR（1時間更新） | 公開後の変更は少ない |
問い合わせフォーム | Server + Client Components | フォームの送信部分のみCSR |
マイページ | SSR | ユーザーごとに異なるコンテンツ |
まとめ
4つのレンダリング方式を「いつ・どこでHTMLを生成するか」で整理しました。コーポレートサイト・オウンドメディアではSSG＋ISRの組み合わせが最もパフォーマンスとSEOに優れ、ユーザーごとのパーソナライゼーションが必要な部分だけSSRを採用するというアプローチが現代のベストプラクティスです。
次の記事では、Next.jsのApp Routerを実際にどう使うかを入門レベルで解説します。
エージェント型Web・AIアプリ
開発のご相談
chot inc.ではエージェント型Webの設計・構築・
運用を
一貫してサポートしています。