本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリ第2弾として、レンダリング方式について解説する記事です。
「HTMLをいつ・どこで生成するか」を決める判断で、ブラウザ・サーバ・ビルド時・CDNエッジまで現代は選択肢が多様化しています。本記事ではCSR／SSR／SSG／ISRの4大方式、Hydration・Islands・Streaming SSR・RSCといったモダン技術、「ページ単位で方式を使い分ける」という現代の定石を解説します。
このカテゴリの他の記事
「いつ・どこで」HTMLを作るか
| 主な方式 | いつ生成 | どこで生成 |
|---|---|---|
| CSR（Client Side Rendering） | 実行時 | ブラウザ |
| SSR（Server Side Rendering） | リクエスト時 | サーバ |
| SSG(Static Site Generation) | ビルド時 | ビルドサーバ |
| ISR（Incremental Static Regeneration） | 初回/更新時 | サーバで再生成 |
選定はパフォーマンス・SEO・運用コストに直結します。全ページSSRにするとサーバ費用が爆発し、全ページCSRにするとSEOが壊滅します。どのページに何が合うかを、業務要件から逆算して決めるのがフロントエンド設計の腕の見せ所です。
現代はページ単位で方式を使い分けるのが本命です。1サイト＝1方式にする必要はありません。
早期の判定フロー
詳細に入る前に、典型的なサイト種別と第一候補を示します。この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の素朴な使い方はほぼこれに該当します。
flowchart TB
BROWSER([ブラウザ])
HTML["index.html + bundle.js<br/>（ほぼ空のHTML）"]
EXEC["JS実行 → DOM構築"]
API["API取得 → 画面更新"]
BROWSER --> HTML --> EXEC --> API
classDef browser fill:#fef3c7,stroke:#d97706;
classDef step fill:#dbeafe,stroke:#2563eb;
class BROWSER browser;
class HTML,EXEC,API step;画面遷移時にフルロードせず部分更新できるため、一度ロードしてしまえば操作感は極めて高速です。一方で初回ロード時に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 Server Components）は、Reactコンポーネントをサーバー側で実行する新しいパラダイムです。従来のReactは全てブラウザで動いていましたが、RSCはサーバー側で実行され、結果だけをブラウザに送ります。
| Server Components | Client Components | |
|---|---|---|
| 実行場所 | サーバー | ブラウザ |
| JS送信 | しない | する |
| DB直接アクセス | 可能 | 不可 |
| useState / useEffect | 不可 | 可能 |
RSCの最大の価値はJSバンドルの削減です。データ取得や整形といった「表示するだけ」のコンポーネントはサーバーで実行して結果のHTMLだけ送り、インタラクティブな部分だけJS送信できるため、ユーザーがダウンロードするJSサイズが大幅に減ります。
Next.js App Routerのデフォルト。JSバンドル問題の抜本的解決策です。
方式の比較
4つのレンダリング方式を横並びに比較すると、それぞれの得意分野が見えてきます。「どれか一つが万能ではない」ので、業務要件に応じて選ぶ・組み合わせるのが現代的です。
flowchart LR
subgraph CSR["CSR (Client Side)"]
CSR1["ブラウザでJSが<br/>HTML組み立て"]
end
subgraph SSR["SSR (Server Side)"]
SSR1["リクエスト毎に<br/>サーバでHTML生成"]
end
subgraph SSG["SSG (Static)"]
SSG1["ビルド時に<br/>静的HTML生成"]
end
subgraph ISR["ISR (Incremental)"]
ISR1["SSGをベースに<br/>古いページだけ再生成"]
end
REQ([HTTPリクエスト]) --> CSR1
REQ --> SSR1
REQ --> SSG1
REQ --> ISR1
CSR1 -. "SEO×<br/>初回表示遅" .- BAD1[弱]
SSR1 -. "コスト高<br/>サーバ依存" .- BAD2[弱]
SSG1 -. "動的更新×" .- BAD3[弱]
ISR1 -. "理解コスト" .- BAD4[弱]
classDef ok fill:#dbeafe,stroke:#2563eb;
classDef bad fill:#fee2e2,stroke:#dc2626;
class CSR,SSR,SSG,ISR ok;
class BAD1,BAD2,BAD3,BAD4 bad;| 観点 | CSR | SSR | SSG | ISR |
|---|---|---|---|---|
| 初回表示 | × | ◎ | ◎ | ◎ |
| SEO | × | ◎ | ◎ | ◎ |
| サーバコスト | ◎ | × | ◎ | ◯ |
| 動的更新 | ◎ | ◎ | × | ◯ |
| 障害耐性 | ◯ | × | ◎ | ◯ |
| ビルド時間 | ◯ | ◯ | × | ◯ |
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で自動化 |
2022年のVercel Serverless Function課金事故は、SSRページにBotがアクセスして数百万円の請求書が届いた事例。「Static First」の発想で、静的で済むページは静的に配信するのが鉄則です。
全部SSRは時限爆弾。ページ種別で切り分けるのが唯一の正解です。
AI時代の視点
AI駆動開発が前提になると、レンダリング方式は「AIが理解しやすい規約ベース」の方式が圧勝します。Next.js App Routerのようにファイルベースルーティング + サーバ/クライアント境界が明確な設計は、AIが「どこで何が動くか」を自動で正しく書き分けられるため、生成コードの精度が格段に上がります。
| AI時代に有利 | AI時代に不利 |
|---|---|
| Next.js App Router（RSC + ファイルルーティング） | 独自SSRフレームワーク・独自ルータ |
| Astro（Islands + シンプルな境界） | 複雑なHydration戦略の手書き |
| 規約ベースのRSC / Client Components境界 | 全部CSRで手書きでデータフェッチ |
| 標準化されたSuspense / Streaming | 独自Loading状態管理 |
AIは「use client ディレクティブ」や「loading.tsx / error.tsx」のようなNext.jsの規約を完璧に理解しており、プロンプトで「商品詳細ページを作って」と伝えるだけで、適切なRSC/CSR配置・Suspense境界・エラーハンドリングまで自動生成します。「規約ベースのフレームワークほどAI精度が上がる」という原則が、現代のフロント選定を大きく変えています。
よくある勘違い
- SSRなら何でも速い → 1つの遅いAPIで全部ブロックされ、TTFBが大惨事になります。Streaming SSR / Suspenseで遅い部分を切り離す設計が必要
- CSRで作ればSEOは後で対応 → 後からSSRに乗せ換える工数は新規で作るより大きい。SEOが要るなら最初からSSG/SSR/ISRで組む
- SSGなら常に最強 → ページ数が1万を超えるとビルドが30分超えて運用が詰みます。ISRで増分ビルドに切り替える
- RSCは新しいから避ける → App RouterはすでにNext.jsのデフォルト。避けるほうが少数派の道になりつつある
ケース別の選び方
レンダリング方式はユースケース単位で選びます。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秒数）
- サーバ障害時のフォールバック方式
最終的な判断の仕方
レンダリング方式の核心は「1サイト=1方式ではなく、ページ単位で使い分ける」ことです。全ページSSRにすれば初回表示とSEOは強いですがサーバコストが線形に爆発し、全ページCSRにすれば安いですがSEOが壊滅し、全ページSSGにすれば速いですが更新に弱い。どれも単独では成立しません。
ブログ・ドキュメント・LPはSSG、ECの商品ページはISR、カート・ダッシュボードはCSR、認証必須の管理画面もCSR、ニュース記事はISR。「ページのユースケースから逆算」して方式を選び、ハイブリッドに組むのが現代の定石です。
決定的な軸は「規約ベースのフレームワークに寄せる」ことです。Next.js App Router の use client ディレクティブ・loading.tsx・error.tsx、Astro の Islands・Frontmatter。これらはAIが完璧に理解している規約で、プロンプト一行で適切なRSC/CSR境界・Suspense境界・エラーハンドリングまで書き分けられます。
独自SSRフレームワーク・独自ルータ・手書きHydration戦略はAI生成精度を下げ、結局工数で損します。「Static Firstで始め、必要な部分だけ動的化する」段階的な育て方が、コストとUXとAI生産性の全てを両立させます。
選定の優先順位をまとめると次の通りです。
- ページ単位で方式を使い分け（サイト全体を1方式に統一しない）
- Static First（まずSSG/ISR、必要部分だけSSR/CSR）
- 規約ベースのFWを選ぶ（Next.js App Router / Astro）
- JSバンドル削減を意識（RSC・Islandsで送信量を削る）
まとめ
本記事はレンダリング方式について、CSR/SSR/SSG/ISR・Hydration/Islands・Streaming SSR・RSCまで含めて解説しました。如何だったでしょうか。
「どれが最強か」ではなく「どのページにどれが合うか」ユースケース単位で選び、規約ベースのFWに寄せるのが2026年の現実解です。
次回は状態管理（useState/Context/Redux/Zustand/TanStack Query）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（32/89）