「CSR、SSR、SSG、ISR……アルファベット3文字が並びすぎて、結局どれを選べばいいの？」
Web開発を学んでいて、ここで手が止まってしまった経験はありませんか。
迷ったときは難しく考えず、たった1つの軸に戻りましょう。
違いはフレームワークの機能名ではなく、「HTMLをいつ・どこで作るか」です。
この記事では、Next.jsのレンダリング4方式（SSG / SSR / CSR / ISR）の基本構造と
実際の開発現場で迷わない「選び方の基準」、そしてSEOや表示速度との関係を分かりやすく解きほぐしていきます。
※読む時間の目安は約10分です。今回はあえて最新のApp Router特有の複雑な用語には踏み込まず、すべての土台となる「Pages Router」の明快な4大分類をベースに解説します。ここを押さえておくことが、結果的に最新技術を理解する一番の近道になります。
まず結論：迷いを消す「3つの答え」
たくさんの解説記事を読み漁る前に、まずは頭に入れておきたい結論を3点に絞りました。
- ① 4方式の本質は「HTMLを作る場所とタイミング」
-
SSGは「ビルド時（事前）」、SSRは「リクエストごと（サーバー）」、
CSRは「ブラウザ上（JavaScript実行後）」、ISRは「静的ページをあとから裏で更新」です。
この基本軸だけで全体像がすっきり整理できます。
- ② サイト単位ではなく「データや画面ごと」に選ぶ
-
「このWebサイトはSSRで作ろう」と丸ごと決める必要はありません。
「誰が見るデータか」「どれくらいの更新頻度か」によって、1つのサイト内で方式を組み合わせる（ハイブリッド）のが現代のベストプラクティスです。
- ③ SEOや初期表示の弱点は「初回HTMLの空っぽ問題」にある
-
ブラウザでJSを動かして描画するCSRは、検索クローラーや初期アクセス時に「中身が空・Loading表示だけ」になるリスクがあります。
だからこそ、事前にサーバー側で文字を入れておくプリレンダー（SSG/SSR/ISR）が重要視されます。
関連記事として、実際に「なぜSEOのためにISRを選んだのか」という実体験や、CSRでソースが空になって焦った検証ログもまとめています。気になった方はあわせて参考にしてみてください。
なぜ用語ばかりが増えて頭がパンクするのか？
Tomoyaプログラミング学習を始めたばかりの頃、SSGとかSSRとか急に出てきても
『正直、表示方法なんてどうでもいいから動くものを作らせてほしい…』
って思いませんでしたか？
Tomoyaすごくよく分かります。
僕も最初は全く気にしたことがありませんでした。
ただでさえアルファベットの略語が多い世界なのに、今日丸暗記したところで
明日には『あれ、どっちがどっちだっけ？』と忘れてしまうんですよね。
混乱してしまう最大の原因は
「言葉の成り立ち（構造）」を飛ばして、いきなり3文字略語から覚えようとするからです。
Next.jsが解決しようとした出発点に立つと、話は驚くほどシンプルになります。
【公式の出発点】
Next.jsは、基本的にすべてのページを「プリレンダー（事前にHTMLを作る）」しようとします。
全部の描画をブラウザ上のJavaScriptに任せきりにしないためです。
この「事前にHTMLを作る（プリレンダー）」というアプローチには、大きく分けて2つのタイミングしかありません。
- ① Static Generation（SSG）
-
「サイトをビルドするとき」に、あらかじめHTMLファイルを完成させておく方式です。誰がいつアクセスしても同じHTMLを高速で配れます。
- ② Server-side Rendering（SSR）
-
「ユーザーからアクセス（リクエスト）が来たその瞬間」に、サーバーがその都度HTMLを組み立てて返す方式です。
そして、この2つに対して「じゃあ従来のReactみたいにブラウザ側で描画するのは何と呼ぶの？」というのが
というのが、CSR（Client-side Rendering）であり
「SSGの爆速配信を保ちつつ、定期的に裏で最新データに更新できないの？」という工夫から生まれたのが
という工夫から生まれたのが ISR（Incremental Static Regeneration） です。
Tomoyaどうでしょうか？
「表示方法の違い」ではなく、「HTMLをどこで・いつ組み立てるか」という裏方の役割分担として捉えると
頭の整理が一気に進みませんか？
4方式の違いを整理。「いつ」「どこで」作る？
4つの方式を一覧表にまとめました。細かい技術仕様を追う前に、まずは「いつ」「どこで」の2列だけを眺めてみてください。
| 方式 | 一言で言うと | HTMLを「いつ」作るか | どこで描画が決まるか |
|---|---|---|---|
| SSG (Static Site Generation) | ビルド時に作って配る | サイトのビルド時（事前生成） | サーバー（CDNキャッシュに載せて超高速配信） |
| SSR (Server-side Rendering) | リクエスト毎に都度作る | ユーザーがアクセスした瞬間 | サーバー（毎回最新のデータを取って生成） |
| CSR (Client-side Rendering) | ブラウザのJSが描画する | 初回アクセス後（JS実行時） | ブラウザ（届いた最小HTMLにJSが肉付け） |
| ISR (Incremental Static Regeneration) | 静的ページをあとから更新 | 静的配信＋バックグラウンド更新 | サーバー（静的配信しつつ、裏で再生成） |
知っておきたい2大キーワード：プリレンダーとハイドレーション
Next.jsのドキュメントを読むと必ず出てくるのが「プリレンダー」と「ハイドレーション」です。
Tomoya料理に例えるとイメージしやすくなります。
■ プリレンダー（事前生成）
あらかじめ料理（完成したHTML）をお皿に盛り付けておくこと。お客さん（ユーザー）が来た瞬間にすぐ料理を出せるので、待たせる時間が短くなります。
■ ハイドレーション（水分補給・活性化）
届いた静かなお皿（HTML）に、あとから動くフォークやナイフ（JavaScript）を添えて「実際にボタンが押せる状態」にすること。乾いたHTMLにJavaScriptという水分を注いで動くようにするイメージです。
公式ドキュメントが伝えている重要なポイント
Next.jsの公式ドキュメント（Pages Router: Rendering / Data Fetching）では、設計の指針として以下の点を明確に強調しています。
可能な限り Static Generation（SSG） を使用することをお勧めします。ページを一度ビルドしてCDNで提供できるため、サーバーがリクエストごとにページをレンダリングするよりもはるかに高速になります。
ユーザーのリクエストに先立ってページをプリレンダリングできない場合（頻繁に更新されるデータやリクエストごとの個人データなど）、SSGは適していません。その場合は SSR または CSR を検討してください。
Next.js 公式ドキュメント（Pages Router: Data Fetching Basics）より要約引用
- ページ単位でハイブリッドに選べる：
- サイト全体を統一する必要はなく、「トップページとブログはSSG、マイページはSSR、チャット欄はCSR」といった組み合わせが可能です。
- CSRの落とし穴：
- 一部の検索エンジンのクローラーはJavaScriptを実行しないため、初回HTMLが真っ白（空のdivタグやローディングスピナーだけ）に見えてしまうリスクがあります。
- ISRの賢い振る舞い（
revalidate）：- 例えば有効期限を60秒と設定した場合、60秒経過した直後のアクセスには「まず古いキャッシュ」を即座に返し、裏側でこっそり新しいページを再生成します。
- 次のアクセスから新しいページが反映されます。再生成に失敗しても画面が落ちず、最後に成功した古いページを出し続けてくれます。
実践：どれを選ぶべき？「サイト単位」ではなく「データ単位」で決める
実務で一番悩むのが、『自分の作っているこの画面にはどの方式を当てはめるべきか？』という選定ですよね。
Tomoyaそうなんですよね。僕も昔は『ECサイトだからSSRにしよう』みたいにサイト丸ごとで決め打ちしようとして、表示速度が遅くなったりサーバー代がかさんだりと悩みました。
画面内の「データの性質」で逆算するのが一番失敗しません！
選定に迷ったときは、以下の「データの性質 → 最適な方式」の対応表をチェックしてみてください。
| 扱いたいデータの性質 | 推奨する方式 | 選定の理由・メリット |
|---|---|---|
| 誰が見ても同じで、めったに更新されない （企業情報、利用規約、固定記事など） | SSG | CDNに完全キャッシュでき、表示速度が最も速くサーバー負荷もゼロに近い。 |
| 誰が見ても同じだが、定期的に更新される （ブログ記事、商品一覧、ニュース一覧など） | ISR | 全体の再ビルドなしで最新状態を保てる。速度とデータ鮮度のいいとこ取り。 |
| アクセスした「その人専用」のデータ （マイページ、ユーザー設定、カート画面など） | SSR または CSR | 他人のデータと共有できないため。SEOが不要なら画面全体をCSRで作るのが手軽。 |
| ログイン後の操作パネル、ダッシュボード （検索エンジンに見せる必要がない画面） | CSR | 検索クローラーを気にする必要がなく、リッチで滑らかな操作性を重視できる。 |
迷ったときの3ステップ確認フロー
- 「このデータは、誰が見ても同じ内容か？（個人化されているか？）」
→ 全員同じなら SSG / ISR を優先検討。人によって違うなら SSR / CSR へ。 - 「この画面のテキストを、検索エンジン（Google等）に読ませたいか？」
→ 読ませたい（SEO重要）なら、初回HTMLに文字が入る SSG / ISR / SSR。不要（社内ツール等）なら CSR で十分。 - 「更新のきっかけは時間か、それとも管理画面での変更イベントか？」
→ 静的ページの良さを活かしたいならISRを検討。時間指定（定期更新）にするか、変更時のオンデマンド再検証にするかを決定。
SEO・初期表示速度・データ鮮度のトレードオフ
Web開発の現場でいつもぶつかるのが、「検索順位（SEO）」「初期表示のスピード」「データの新しさ（鮮度）」の3つ巴の戦いです。
- 最新データを常に届けたい！ → でも毎回SSRでサーバー生成すると、レスポンスが遅くなって体感速度が落ちる……
- とにかく爆速でページを表示したい！ → SSGで事前ビルドすれば速いけれど、記事を直すたびにサイト全体の再ビルドが必要で鮮度が落ちる……
- 開発を手軽にサクッと済ませたい！ → CSRで作ると楽だけれど、検索エンジンのクローラーに真っ白なページとして認識されるリスクがある……
この「速くしたいけれど、鮮度も落としたくない」という開発者の長年の悩みを解決するために登場したのが、まさに ISR でした。
ユーザーにはCDNからミリ秒単位で静的HTMLを返しつつ、設定した時間が過ぎたらバックグラウンドでそっと最新データをサーバーが取りに行ってキャッシュを差し替える。人間の目には一瞬の表示に見えつつ、裏側では賢く更新し続ける仕組みが整えられています。
現場ですぐできる！「中身が空っぽ」の確認テクニック
自分の作ったページが検索エンジンにどう見えているか不安になったら、ブラウザで一番簡単な確認方法があります。
ブラウザで確認したいページを開き、右クリックして「ページのソースを表示」を選択します（「検証（デベロッパーツール）」ではなく「ソースを表示」です）。
- 文字や見出しが最初からギッシリ書かれている： プリレンダー（SSG / SSR / ISR）がしっかり成功しています。クローラーも人間と同じように本文を読めます。
<div id="root"></div>のように中身がスカスカで、下部に長いscriptタグがあるだけ： CSRの状態です。低スペック端末や一部の検索クローラーでは「何も書かれていない真っ白なページ」に見えている危険性があります。
まとめと次のアクション
最後に、この記事で押さえておきたい要点を振り返ります。
- 4方式の本質は、アルファベットの呪文ではなく「HTMLをいつ・どこで作るか」。
- サイト全体を1つの方式で縛る必要はない。「画面やデータの性質」ごとに組み合わせる。
- まずはSSG/ISRの静的配信をベースに考え、ユーザー固有のデータやリアルタイム性が必須な部分だけSSRやCSRを取り入れる。
今日からできる最初の一歩
まずは難しく考えず、ご自身が開発しているページ（または普段見ているWebサイト）で右クリックして「ページのソースを表示」を押してみてください。
「あ、このサイトはソースの中にちゃんと本文のHTMLがあるからプリレンダーされているんだ」「ここは空っぽだからCSRなんだな」と目で見て実感できるようになれば、レンダリングの仕組みはもう完全にあなたの血肉になっています！
さらに実践的なコード例や、実際にISRを導入してクローラーの挙動を検証したレポートは、以下の記事でも詳しく解説しています。開発のヒントとしてぜひ役立ててみてください。
コメント