はじめに
「Next.jsのApp Router、SSRやSSG、ISRの違いが前より分かりづらくなっていませんか？」
「公式ドキュメントを読んでも、React Server Components（RSC）との関係や、どれを選べばいいかピンとこない…」
私たちが直面しがちな“レンダリング戦略の迷子状態”、このモヤモヤを一緒にほぐしましょう。
この記事では、App Router前提でレンダリング手法の全体像・比較・選び方を整理します。
RSCの基礎から、最新技術の活かし方まで、比較表＆フローチャートで実務判断に直結する視点で解説します。
（Next.jsやフロントエンドフレームワークの選び方については『フロントエンドフレームワーク徹底比較！React・Vue・Angular違いと選び方』もご参照ください）
用語解説：Next.js
ReactベースのWebアプリケーションフレームワーク。SSRやSSGなど多様なレンダリング手法をサポートし、SEOやパフォーマンスに優れる。用語解説：App Router
Next.js 13以降で導入された新しいルーティング方式。ページやレイアウトの構成が柔軟になり、サーバー中心設計が強化された。用語解説：SSR（Server Side Rendering）
ページのHTMLをリクエストごとにサーバーで生成し、最新データを即時反映できるレンダリング手法。用語解説：SSG（Static Site Generation）
ビルド時にHTMLを生成し、静的ファイルとして配信する方式。初期表示が高速でサーバー負荷が低い。用語解説：ISR（Incremental Static Regeneration）
静的生成（SSG）に「定期的な再生成」を加えた手法。一定間隔で最新データを反映できる。用語解説：React Server Components（RSC）
サーバー上でのみ実行されるReactコンポーネント。クライアントへのJS配信量を減らし、パフォーマンス向上に寄与する。
App Router登場で変わったNext.jsの「常識」
App Routerの導入は、単なる新機能追加ではありません。設計思想そのものが「サーバー中心」へ大転換しました。
用語解説：サーバー中心設計
データ取得やレンダリング処理をできる限りサーバー側で行い、クライアント（ブラウザ）への負荷やJS配信量を最小化する設計思想。
Pages Routerとの最大の違い──RSCが標準土台
Pages Router時代は「ページ単位」でSSR/SSGを選びました。
App RouterではReact Server Components（RSC）がデフォルトに。サーバーで全コンポーネントがまず実行されるため、SSRやSSGは「RSCをどう“いつ・どこで”HTMLに変換するか」を制御するレイヤーに進化しています。
クライアントのみで動かしたい場合は、コンポーネント先頭に'use client';を記述します。
用語解説：Pages Router
従来のNext.jsのルーティング方式。pagesディレクトリ内のファイルが自動的にルートとなる。用語解説：’use client’
コンポーネントをクライアントサイドでのみ実行したい場合に先頭へ記載するディレクティブ。インタラクションや状態管理が必要な場合に利用。
サーバー中心思想──“送るJSは最小限”が鉄則
App Routerは、初期表示速度とSEOの両立を狙い、「サーバーで極限までレンダリング＋データ取得」する方針です。
クライアント（ブラウザ）へのJS配信量を抑え、UX改善・バンドル肥大化を防ぐのが狙い。
これを意識すると、各レンダリング手法の“選びどころ”が見えてきます。
用語解説：クライアント
ユーザーが操作するブラウザやアプリケーション。サーバーからHTMLやJSを受け取り、画面を表示する。用語解説：バンドル
複数のJSやCSSファイルを1つにまとめたもの。肥大化すると表示速度やUXに悪影響を及ぼす。用語解説：SEO
検索エンジン最適化。HTMLとしてページ内容が見えることが重要。
1枚でわかる！SSR/SSG/ISR/CSRの比較
いつ・どこでHTMLが生成され、データ鮮度は？
この2軸で整理すると、違いが腹落ちします。
| 評価軸 | SSG（静的生成） | SSR（サーバー生成） | ISR（静的再生成） | CSR（クライアント生成） |
|---|---|---|---|---|
| 初期表示速度 | ◎ 最速 | ◯ 速い | ◎ 最速 | △ 遅い |
| データ鮮度 | △ ビルド時 | ◎ 最新 | ◯ 準最新 | ◎ 最新（表示後） |
| SEO | ◎ 最適 | ◎ 最適 | ◎ 最適 | △ 不利 |
| サーバーコスト | ◎ 最小 | ◯ 中 | △ 小 | ◎ 最小 |
| 実装(App Router) | ◎ デフォルトで容易 | ◯ fetchのキャッシュ制御 |
◯ revalidate要設定 |
◯ 'use client'要記載 |
（SSR・SSG・CSRの違いと現場での使い分けについては『SQL IN・EXISTS・JOINの違い徹底解説｜安全で速い選び方と実践7チェック』や『CSS GridとFlexbox徹底比較！違い・使い分け・選び方完全ガイド【2025年版】』も参考になります）
用語解説：CSR（Client Side Rendering）
クライアント（ブラウザ）でJSを実行し、動的にHTMLを生成する方式。インタラクション性は高いが、初期表示やSEOは不利。用語解説：データ鮮度
表示されるデータがどれだけ最新かを示す指標。SSRは常に最新、SSGはビルド時点、ISRは一定間隔で更新。用語解説：サーバーコスト
サーバー側でHTMLを生成・配信する際の負荷やコスト。SSG/CSRは低く、SSR/ISRは高くなりやすい。
App Router流 SSR/SSG/ISR/CSRの実践とユースケース
どのAPI/オプションで、どう振る舞いが決まるか──現場視点で押さえておきたいポイントを解説します。
SSG：デフォルトで静的生成（最速・省コスト）
fetchで特にオプションを指定しなければ、ビルド時に静的HTML生成＝SSG。
更新頻度が低いページ（コーポレート、ブログ等）に最適です。
SSR：キャッシュ無効化で常に最新データ
fetchで{ cache: 'no-store' }や{ revalidate: 0 }を指定すれば毎回サーバーでHTML生成（SSR）。
ユーザー固有ページや動的EC在庫表示など、鮮度が命の場面で活用。
（APIやデータ取得の基礎については『APIとは？SES現場で役立つ基礎〜Postman活用まで完全ガイド』もご参照ください）
用語解説：fetch
データ取得のためのWeb API。Next.jsではキャッシュや再検証のオプションを指定することでレンダリング方式を制御できる。用語解説：revalidate
ISRやSSRで、データの再取得・再生成タイミングを秒数で指定するオプション。用語解説：cache
fetchのキャッシュ戦略を指定するオプション。’no-store’で毎回取得、’force-cache’でキャッシュ優先など。用語解説：キャッシュ
一度取得したデータやHTMLを一時保存し、再利用する仕組み。パフォーマンス向上やサーバー負荷軽減に役立つ。
ISR：revalidateで定期的に再生成
fetchのrevalidateに秒数指定（例：{ next: { revalidate: 60 } }）。
アクセスの多いニュースサイトや準リアルタイム性が求められる情報系に◎。
パフォーマンス最大化の新技術
Streaming：<Suspense>活用でSSR高速化
SSRは本来「全データ取得後にページ表示」ですが、
Streaming＋<Suspense>を使えば「まず静的部分のみ表示→重い部分はあとから描画」。
“真っ白で待たされる”体験を避け、UX劇的向上が狙えます。
用語解説：Streaming
サーバーから部分的にHTMLを順次送信し、先に表示できる部分から描画する技術。待ち時間を短縮しUXを向上させる。用語解説：Suspense
Reactのコンポーネント。データ取得や遅延読み込み時にローディング表示などを制御できる。
Server Actions：APIレスでサーバー更新
フォーム送信などのデータ更新も「API Route不要」でOK。
Server Actionsを活用すれば、クライアントJSを挟まずサーバーで直接処理・再レンダリングできます。
用語解説：Server Actions
Next.js 13.4以降で利用可能な新機能。API Routeを使わず、サーバー側で直接データ更新や副作用処理を実行できる。用語解説：API Route
Next.jsでAPIエンドポイントを作成するための仕組み。外部連携や再利用ロジックに適する。
迷ったら？最適手法フローチャート
選び方の“地図”を用意しました──自分のケースにあてはめてみてください。
-
全ユーザーで共通＋低更新頻度？
- Yes→ SSGがベスト
- No→2へ
-
常に最新データ必須？（例：ユーザー固有情報）
- Yes→ SSR＋必要に応じStreaming
- No→3へ
-
定期的更新で十分？
- Yes→ ISR
- No→表示後にクライアント処理要→CSR（‘use client’;）
用語解説：静的生成（SSG）
ビルド時にHTMLを生成し、サーバーやCDNから配信する方式。パフォーマンスとコストに優れる。用語解説：サーバー生成（SSR）
リクエストごとにサーバーでHTMLを生成し、常に最新データを反映できる。用語解説：静的再生成（ISR）
SSGの静的ページを一定間隔で自動再生成し、データ鮮度を高める。用語解説：クライアント生成（CSR）
クライアント側でJSを実行し、動的にHTMLを生成する方式。
FAQ：現場で本当に困る疑問をピックアップ
-
Q. SEO最強は？
A. SSG/SSR/ISRいずれもサーバー生成ゆえ同等。“HTMLとして見える”ことが大前提です。 -
Q. App RouterでCSRはもう使わない？
A. 状態管理やインタラクションが必要な箇所は‘use client’;必須、部分的CSRは現役です。 -
Q. Partial Prerendering（PPR）って何？
A. 静的ページ内に動的な「穴」を持たせる次世代技術。今後主流化が予想されますが、SSR/SSG/ISR理解が土台です。 -
Q. キャッシュ戦略はどう考える？
A. まずはfetchのcacheとrevalidateオプションで挙動をコントロール。“迷ったらまずこれ”がシンプル。 -
Q. Server ActionsとAPI Route、どちらを使う？
A. 単発更新はServer Actions、外部連携や再利用ロジックはAPI Route分離推奨。 -
Q. Pages Router→App Router移行、どこから？
A. まずは静的ページ（会社概要等）をSSGで。構造に慣れてから動的ページへ段階的に拡大が安全です。
用語解説：Partial Prerendering（PPR）
静的ページの一部だけを動的に生成する技術。今後のNext.jsで注目される。用語解説：状態管理
アプリ内でデータやUIの状態を一元的に管理する仕組み。ReactではuseStateやReduxなどが代表例。用語解説：インタラクション
ユーザーの操作に応じて画面が動的に変化すること。ボタン操作や入力フォームなど。
まとめ：もう迷わない！App Router時代のベストプラクティス
RSC基盤の「サーバー中心設計」で静的・動的を柔軟にハイブリッド化できるのが現代Next.js。
（TypeScriptやフロントエンドの型安全・開発効率化については『TypeScript Promise型定義完全解説｜any撲滅と使い分け』もご参照ください）
用語解説：ハイブリッド化
静的生成と動的生成をページやコンポーネント単位で柔軟に組み合わせる設計。用語解説：体感速度
ユーザーが「速い」と感じる表示速度。初期表示や操作レスポンスの速さが重要。用語解説：開発体験（DX）
開発者が感じる使いやすさや効率性。Next.jsはDX向上にも注力している。
- 基本はSSG（静的生成）でパフォーマンス重視
- 動的データにはSSR/ISRを適切にミックス
- 体感速度＆開発体験UPにはStreaming/Server Actionsも積極活用
比較表とフローチャートを片手に、
「この要件にはこれ！」と自信を持って提案できるエンジニアを目指しましょう。
ぜひコードをコピペして、まずは動かしてみてください。
