本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリ第2弾として、レンダリング方式について解説する記事です。
「HTMLをいつ・どこで生成するか」を決める判断で、ブラウザ・サーバ・ビルド時・CDNエッジまで現代は選択肢が多様化しています。本記事ではCSR／SSR／SSG／ISRの4大方式、Hydration・Islands・Streaming SSR・RSCといったモダン技術、「ページ単位で方式を使い分ける」という現代の定石を解説します。
本記事のテーマについてさらに詳しく知りたい方は『ソフトウェアアーキテクチャの基礎』も参考にしてみてください。
そもそもレンダリング方式とは何か
レンダリング方式とは、ざっくり言えば「Webページの中身（HTML）をいつ・どこで組み立てるか」の選択です。
料理に例えると分かりやすいかもしれません。注文を受けてからキッチンで作る（SSR）、事前に作り置きして棚から出すだけ（SSG）、食材だけ渡して客がテーブルで自分で仕上げる（CSR）──それぞれ提供速度・鮮度・手間が異なります。Webページも同じで、組み立てのタイミングと場所によって表示速度・SEO・サーバコストのバランスが変わります。
| 主な方式 | いつ生成 | どこで生成 |
|---|---|---|
| CSR | 実行時 | ブラウザ |
| SSR | リクエスト時 | サーバ |
| SSG(Static Site Generation) | ビルド時 | ビルドサーバ |
| ISR | 初回/更新時 | サーバで再生成 |
現代はページ単位で方式を使い分けるのが本命です。1サイト＝1方式にする必要はありません。
なぜレンダリング方式の選択が重要なのか
もしレンダリング方式を考えずに全ページを同じ方式で作ると、どこかで必ず破綻します。全ページSSRにするとサーバ費用が爆発し、全ページCSRにするとSEOが壊滅します。どのページに何が合うかを、業務要件から逆算して決めるのがフロントエンド設計の腕の見せ所です。
方式選定を誤ったプロジェクトでは、キャンペーン初日にサーバ費用が想定の数倍に膨らんで急遽書き直す、Google検索に一切載らず集客できない、といった事故が現実に起きています。「どのページをどの方式で出すか」を最初に決めるだけで、こうした事故の大半は防げます。
早期の判定フロー
詳細に入る前に、典型的なサイト種別と第一候補を示します。この1枚で当たりをつけてから、各方式の詳細を確認してください。
| サイト種別 | 第一候補 |
|---|---|
| ブログ・ドキュメント | SSG（Astro） |
| 企業サイト・LP | SSG or ISR |
| ECサイト | ISR + 一部 SSR |
| SNS・SaaS | SSR（Next.js App Router） |
| 管理画面・ダッシュボード | CSR（React SPA） |
| リアルタイム性が命のアプリ | CSR |
CSR（Client Side Rendering）
CSR は、ブラウザに「空のHTMLとJS」だけを送り、ブラウザ上でJavaScriptを実行してDOMを構築する方式です。SPA（Single Page Application）の基本形で、React・Vueの素朴な使い方はほぼこれに該当します。
画面遷移時にフルロードせず部分更新できるため、一度ロードしてしまえば操作感は極めて高速です。一方で初回ロード時にJSを全部ダウンロードして実行し、そこからAPIを呼んで描画するため、初回表示が遅くなりがち。またHTMLが空のためGoogleのクローラーに内容が認識されず、SEOに決定的に弱いのも課題です。
| 強み | 弱み |
|---|---|
| 画面遷移が高速・操作感が良い | 初回表示が遅い |
| サーバが静的ファイル配信だけで済む | SEOが弱い・JS必須 |
管理画面・ダッシュボード・ログイン後のアプリ等、SEO不要で操作性重視の用途に最適です。
SSR（Server Side Rendering）
SSR は、リクエストが来るたびにサーバーでHTMLを生成して返す方式です。古典的なPHP・Rails・Djangoと本質は同じですが、モダンなSSRは React / Vue のコンポーネントをサーバー側でレンダリングする点が異なります。
[ブラウザ] ──(request)──→ [サーバ]
React/Vue で HTML生成
←────(完成HTML)──── + Hydration用のJSHTMLが完成した状態でブラウザに届くため、初回表示が速く、SEOも強い。一方でリクエストのたびにサーバで処理が走るため、サーバ負荷とコストが静的配信より大幅に増えます。トラフィックが多いサイトではCDNキャッシュと組み合わせて運用します。
| 強み | 弱み |
|---|---|
| 初回表示が速い・SEOに強い | サーバ負荷・レイテンシ |
| 動的な最新データを返せる | スケール時にコスト増 |
Next.js / Nuxt / Remixの基本モード。SEOとインタラクティブ性の両立が必要な時の本命です。
SSG（Static Site Generation）
SSG は、ビルド時にすべてのページを事前に生成して静的ファイル化し、あとはCDNで配信するだけ、という方式です。リクエスト時にはサーバ処理が一切走らないため、最速・最安・最も障害に強い配信方式になります。
[CI/CDビルド時]
全URL → HTML生成
↓
[CDN配信] ← 事前生成済みAstro・Hugo・Jekyll・Eleventy などが代表的で、コンテンツ中心のサイト（ブログ・ドキュメント・マーケティング）で真価を発揮します。デメリットはビルド時間で、ページ数が数千を超えるとビルドが数十分かかるケースも出てきます。また「更新のたびに全サイト再ビルド」が必要なので、頻繁にコンテンツが変わるサイトには不向きです。
| 強み | 弱み |
|---|---|
| 最速・最安・CDN完結・障害に強い | ビルド時間 |
| ユーザーごとに変わる内容は扱いにくい | 頻繁な更新に弱い |
ブログ・ドキュメント・LPにはSSGが最適です。本シリーズが置かれている senkohome.com もAstro SSGです。
ISR（Incremental Static Regeneration）
ISR は、SSGとSSRのいいとこ取りのハイブリッド方式です。ビルド時に主要ページを事前生成しておき、一定時間経過したら裏側で再生成します。ユーザーには常にキャッシュ済みHTMLが即座に返されるため高速で、かつデータの鮮度も保てます。
1. ビルド時: 主要ページを事前生成
2. アクセス時: 期限内ならキャッシュ即返却
3. 期限切れ: バックグラウンドで再生成
4. 次アクセスから新版が見える（stale-while-revalidate）Next.jsが元祖で、SSGの「更新のたびに全再ビルド」問題を解決しました。ECサイトの商品ページ（価格や在庫は頻繁に変わるが、基本情報は固定）や、ニュースサイトの記事ページなど、「半固定・半動的なコンテンツ」に最適です。
SSGの弱点をそのまま解決した画期的な方式。多ページで一部頻繁更新のサイトに最適です。
HydrationとIslands
Hydration（ハイドレーション）は、SSRやSSGで生成したHTMLにJavaScriptで対話性を付加する処理です。サーバーで生成した「静的なHTML」をブラウザで受け取った後、JSがマウントされイベントリスナーが登録されて初めて、ボタンクリック等のインタラクションが機能するようになります。
[SSR HTML] → ブラウザで表示（まだ動かない）
↓
[JSロード+実行] → Hydration（イベントが有効化）
↓
[インタラクティブになる]問題は、全ページのJSを再実行するためコストが高いこと。これを解決したのが Islands Architecture（島アーキテクチャ）で、「インタラクティブな部分だけJS送信する」という発想の転換です。Astro が代表例で、ページの99%を静的HTMLのまま、カート機能等のインタラクティブ部分だけ小さなJSアイランドとして動かします。
AstroのIslands が現代の最適解で、JS送信量を大幅に削減し、LCPとINPを両立できます。
Streaming SSR
Streaming SSR は、HTMLを一気に全部返すのではなく、準備できた部分から順次ブラウザに流し込む新方式です。モダンなReact / Next.js App Router / Remix が標準サポートしており、「遅いAPIがあるとページ全体がブロックされる」問題を解決します。
<html>
<head>...</head>
<body>
<Header /> ← 即座に送信
<MainContent /> ← 即座に送信
<Suspense> ← ここは fallback UI で先送り
<SlowData /> ← データ到着後に流し込む
</Suspense>
</body>従来のSSRでは、1つでも遅いAPIがあると全HTMLがそれを待つため、「最も遅い部分がページ全体の速度を決める」という問題がありました。Streamingならまず骨組みを返し、遅い部分はローディングUIで先に見せられるため、TTFB（Time To First Byte）が劇的に改善します。
RSC（React Server Components）
RSCは、Reactコンポーネントをサーバー側で実行する新しいパラダイムです。従来のReactは全てブラウザで動いていましたが、RSCはサーバー側で実行され、結果だけをブラウザに送ります。
| Server Components | Client Components | |
|---|---|---|
| 実行場所 | サーバー | ブラウザ |
| JS送信 | しない | する |
| DB直接アクセス | 可能 | 不可 |
| useState / useEffect | 不可 | 可能 |
RSCの最大の価値はJSバンドルの削減です。データ取得や整形といった「表示するだけ」のコンポーネントはサーバーで実行して結果のHTMLだけ送り、インタラクティブな部分だけJS送信できるため、ユーザーがダウンロードするJSサイズが大幅に減ります。
Next.js App Routerのデフォルト。JSバンドル問題の抜本的解決策です。
方式の比較
4つのレンダリング方式を横並びに比較すると、それぞれの得意分野が見えてきます。「どれか一つが万能ではない」ので、業務要件に応じて選ぶ・組み合わせるのが現代的です。
SSGは「ビルド時間と動的更新」が弱く、SSRは「コストと障害耐性」が弱い。といった具合に、各方式には明確なトレードオフがあります。ISRはこのトレードオフをバランスよく解消しますが、そのぶん仕組みが複雑で理解コストが上がります。
「全ページSSR」で燃えた夜（業界事例)
「静的でも十分なマーケティングページまで一律でNext.jsのSSRにしていたプロジェクトで、キャンペーン初日の夜にVercelの関数実行枠を使い切り、深夜に静的書き出しへ切り替える羽目になった」という話が、いろいろな現場で語り草になっています。トラフィックに比例してサーバコストが線形に増えるのがSSRの怖いところで、キャンペーンやSNSバズで一瞬で料金メーターが回ります。
新卒のチームがNext.js SSRでECサイトを組み、金曜夜のテレビ連動キャンペーンで一気にリクエストが跳ねて、月曜朝に請求書を見た上司が青ざめた、という話も似た系統です。教訓はシンプルで、最初からStatic Firstで組めば避けられた事故です。
商品詳細と管理画面を同じ方式で作ろうとすると、必ずどちらかが不幸になる。静的で済むページはSSG/ISR、動的が必要なページだけSSR、ログイン後はCSR、と「ページ単位で使い分ける」のがコスト・UX・運用のすべてを両立させる唯一の方法になります。
「全ページSSR」は時限爆弾。Static Firstでスタートし、必要な部分だけ動的化します。
ページ種別×方式の実務段階表
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
「1サイト＝1方式」が破綻の元なので、ページの性質で方式を明示的に仕分けるのが現代の定石です。
| ページ種別 | 推奨方式 | 理由 | Revalidate間隔 |
|---|---|---|---|
| トップ・LP | SSG | 固定・最速・最安 | ビルド時のみ |
| ブログ・ドキュメント | SSG | 更新頻度低・SEO重要 | ビルド時のみ |
| 商品一覧 | ISR | カタログは半固定・在庫は動的 | 60秒 |
| 商品詳細 | ISR + CSR（在庫のみ） | 基本情報静的・在庫だけ動的 | 300秒 |
| ニュース記事 | ISR | 公開後ほぼ固定 | 600秒 |
| カート | CSR or SSR | ユーザー固有・最新必須 | ― |
| ログイン後ダッシュボード | CSR | SEO不要・操作性重視 | ― |
| 管理画面 | CSR | SEO不要・認証必須 | ― |
ISR revalidate は60〜600秒が標準値です。これより短いと ISR の価値が薄れ（SSR相当）、長すぎるとユーザーが古い情報を見る時間が長くなります。Next.js の revalidate: 60 を起点に、ページ特性に合わせて調整するのが実務です。
同じサイトでもページごとに方式を切ります。1方式に統一するのは諦めるのが現代流です。
やってはいけないこと
方式選定でよく見る失敗を整理します。どれも性能劣化・コスト爆発・SEO喪失につながる典型パターンです。
| 禁じ手 | なぜダメか |
|---|---|
| マーケティングページを全部SSR | トラフィック比例でサーバコスト爆発。Vercel関数実行枠を使い切る定番事故 |
| SEO必須サイトをCSRで構築 | GoogleクローラーのJS実行が数日〜数週間遅延。鮮度が求められるサイトは壊滅 |
| SSGで1万ページ超のサイトを組む | ビルドが30分超え。ISRで増分ビルドに切り替え |
| Streaming SSRのSuspenseなし | 1つの遅いAPIで全HTMLがブロック。TTFB大悪化 |
| Client Componentで全部フェッチ | RSCのメリット消失。データ取得はServer Componentに寄せる |
ISRの revalidate を1秒にする | 実質SSR同等のコスト。60秒以上が実用域 |
| ページ遷移ごとに全データ再取得 | TanStack Queryのキャッシュを活用すれば大幅削減できる |
| 認証必須ページをSSG化 | ログイン状態がビルド時に決まらない。SSR / CSR必須 |
| フォント・画像のpreload忘れ | LCP悪化の典型。Next/Font / Next/Imageで自動化 |
| 「SSRなら何でも速い」と過信 | 遅いAPIで全HTMLがブロックされTTFB大惨事。Streaming SSR必須 |
| 「CSRで作ってSEOは後で」と後回し | SSR乗せ換え工数は新規より大。SEOが要るなら最初からSSG/SSR |
2022年のVercel Serverless Function課金事故は、SSRページにBotがアクセスして数百万円の請求書が届いた事例。「Static First」の発想で、静的で済むページは静的に配信するのが鉄則です。
全部SSRは時限爆弾。ページ種別で切り分けるのが唯一の正解です。
AI判断軸
| AI時代に有利 | AI時代に不利 |
|---|---|
| Next.js App Router（RSC + ファイルルーティング） | 独自SSRフレームワーク・独自ルータ |
| Astro（Islands + シンプルな境界） | 複雑なHydration戦略の手書き |
| 規約ベースのRSC / Client Components境界 | 全部CSRで手書きデータフェッチ |
| 標準Suspense / Streaming | 独自Loading状態管理 |
- ページ単位で方式を使い分け（サイト全体を1方式に統一しない）
- Static First（まずSSG/ISR、必要部分だけSSR/CSR）
- 規約ベースのFWを選ぶ（Next.js App Router / Astro）
- JSバンドル削減を意識（RSC・Islandsで送信量を削る）
規約ベースのFWはAIの生成精度を高める
Next.js App Routerのapp/ディレクトリ規約（page.tsx=ページ、layout.tsx=レイアウト、loading.tsx=サスペンス）は、AIにとって明確な構造ルールです。「/dashboard/settingsページを作って」と指示すれば、AIはapp/dashboard/settings/page.tsxを正確に作成し、必要に応じてlayout.tsxも生成します。
独自のルーティング設計や手書きのSSR設定では、プロジェクト固有のルールをAIに毎回教える必要があり、精度が安定しません。
Server ComponentsとClient Componentsの境界設計
RSC（React Server Components）の"use client"ディレクティブによるコンポーネント分類は、AIが理解しやすい明示的な境界です。ただし、AIは"use client"を付けすぎる傾向があります（サーバで実行できるコンポーネントにも付けてしまう）。データフェッチを含むコンポーネントはServer Component、イベントハンドラを含むコンポーネントはClient Component、という原則をプロジェクトのルールとして明文化しておくとAIの精度が上がります。
ケース別の選び方
レンダリング方式はユースケース単位で選びます。1つのサイト内でページごとに方式を混ぜるのが現代的な設計です。
| ユースケース | 推奨方式 |
|---|---|
| ブログ・ドキュメント | SSG（Astro / Next SSG） |
| ECサイト | ISR + SSR（商品ISR・カートSSR） |
| ログイン必須の管理画面 | CSR（SEO不要） |
| ニュースサイト・メディア | ISR（更新頻度と速度を両立） |
| LP・マーケ | SSG（最速・最安） |
| ダッシュボード系SaaS | SSG + CSR（シェル静的・中身動的） |
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 主なレンダリング方式（ページ単位で整理）
- Hydration戦略（全体 / Islands / Partial）
- RSC採用の是非
- ビルド頻度（SSGの場合）
- ISR再検証期限（revalidate秒数）
- サーバ障害時のフォールバック方式
この記事に関連する記事
まとめ
本記事はレンダリング方式について、CSR/SSR/SSG/ISR・Hydration/Islands・Streaming SSR・RSCまで含めて解説しました。如何だったでしょうか。
「どれが最強か」ではなく「どのページにどれが合うか」ユースケース単位で選び、規約ベースのFWに寄せるのが2026年の現実解です。
次回は状態管理（useState/Context/Redux/Zustand/TanStack Query）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Next.js 公式ドキュメント も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（32/89）