本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリ第2弾として、レンダリング方式について解説する記事です。
「HTMLをいつ・どこで生成するか」を決める判断で、ブラウザ・サーバ・ビルド時・CDNエッジまで現代は選択肢が多様化しています。本記事ではCSR／SSR／SSG／ISRの4大方式、Hydration・Islands・Streaming SSR・RSCといったモダン技術、「ページ単位で方式を使い分ける」という現代の定石を解説します。
本記事のテーマについてさらに詳しく知りたい方は『ソフトウェアアーキテクチャの基礎』も参考にしてみてください。
この記事の結論
- 「どれが最強か」ではなく「どのページにどれが合うか」で選ぶ
- Static First。まずSSG / ISR、必要な部分だけSSR / CSR
- 規約ベースのフレームワーク（Next.js App Router / Astro）に寄せる
この記事を読む前に
本記事はブラウザ側（画面側）の仕組みの話が中心です。IT用語にあまり馴染みがない方は、基礎編の「Webサービスが動く仕組み」と「プログラムとAPIの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもレンダリング方式とは何か
レンダリング方式とは、ざっくり言えば「Webページの中身（HTML）をいつ・どこで組み立てるか」の選択です。
料理に例えると、注文を受けてからキッチンで作る（SSR）、事前に作り置きして棚から出すだけ（SSG）、食材だけ渡して客がテーブルで自分で仕上げる（CSR）──それぞれ提供速度・鮮度・手間が異なります。
| 主な方式 | いつ生成 | どこで生成 |
|---|---|---|
| CSR | 実行時 | ブラウザ |
| SSR | リクエスト時 | サーバ |
| SSG | ビルド時 | ビルドサーバ |
| ISR | 初回 / 更新時 | サーバで再生成 |
なぜレンダリング方式の選択が重要なのか
もし全ページを同じ方式で作ると、どこかで必ず破綻します。全ページSSRにするとサーバ費用が爆発し、全ページCSRにするとSEOが壊滅します。方式選定を誤ったプロジェクトでは、キャンペーン初日にサーバ費用が想定の数倍に膨らんで急遽書き直す、Google検索に一切載らず集客できない、といった事故が現実に起きています。「どのページをどの方式で出すか」を最初に決めるだけで、こうした事故の大半は防げます。
4大方式の特徴
CSR ― SEO不要・操作性重視の管理画面向け
CSRは、ブラウザに「空のHTMLとJS」だけを送り、ブラウザ上でJavaScriptを実行してDOMを構築する方式です。SPAの基本形で、一度ロードしてしまえば画面遷移は部分更新のため操作感は極めて高速です。一方で初回表示が遅く、HTMLが空のためSEOに決定的に弱い。管理画面・ダッシュボード・ログイン後のアプリに最適です。
SSR ― SEOとインタラクティブ性の両立
SSRは、リクエストが来るたびにサーバーでReact / VueコンポーネントからHTMLを生成して返す方式です。HTMLが完成した状態で届くため初回表示が速くSEOも強い。代わりにリクエストごとにサーバ処理が走るため、負荷とコストが静的配信より大幅に増えます。Next.js / Nuxt / Remixの基本モードです。
SSG ― 最速・最安・最も障害に強い
SSGは、ビルド時にすべてのページを事前生成して静的ファイル化し、あとはCDNで配信するだけの方式です。リクエスト時にサーバ処理が一切走らないため、最速・最安・最も障害に強い。Astro・Hugo等が代表で、ブログ・ドキュメント・LPで真価を発揮します（本シリーズのsenkohome.comもAstro SSGです）。弱点はビルド時間と、「更新のたびに全再ビルド」が必要なことです。
ISR ― SSGとSSRのいいとこ取り
ISRは、ビルド時に事前生成しつつ、一定時間経過したら裏側で再生成するハイブリッド方式です。ユーザーには常にキャッシュ済みHTMLが即座に返り、データの鮮度も保てます。ECの商品ページやニュース記事など「半固定・半動的なコンテンツ」に最適で、SSGの全再ビルド問題をそのまま解決した方式です。
モダン技術 ― Hydration・Islands・Streaming・RSC
Hydrationは、SSR / SSGで生成した静的HTMLにJSで対話性を付加する処理です。問題は全ページのJSを再実行するためコストが高いことで、これを解決したのがIslands Architectureです。Astroが代表例で、ページの99%を静的HTMLのまま、カート機能等のインタラクティブ部分だけ小さなJSアイランドとして動かします。JS送信量を大幅に削減し、LCPとINPを両立できる現代の最適解です。
Streaming SSRは、HTMLを一気に返すのではなく準備できた部分から順次流し込む方式です。従来のSSRは1つでも遅いAPIがあると全HTMLがそれを待ちましたが、Streamingならまず骨組みを返し、遅い部分はSuspenseのローディングUIで先に見せられるため、TTFBが劇的に改善します。
RSC（React Server Components）は、Reactコンポーネントをサーバー側で実行し、結果だけをブラウザに送るパラダイムです。「表示するだけ」のコンポーネントはJSを送信せず、DBに直接アクセスでき、インタラクティブな部分（useState等を使う部分）だけClient ComponentとしてJS送信します。最大の価値はJSバンドルの削減で、Next.js App Routerのデフォルトです。
どう選べばいいのか ― ページ種別×方式の段階表
※ 2026年4月時点の業界相場値です。
「1サイト＝1方式」が破綻の元なので、ページの性質で方式を明示的に仕分けるのが現代の定石です。
| ページ種別 | 推奨方式 | Revalidate間隔 |
|---|---|---|
| トップ・LP・ブログ・ドキュメント | SSG | ビルド時のみ |
| 商品一覧・商品詳細 | ISR（+在庫のみCSR） | 60〜300秒 |
| ニュース記事 | ISR | 600秒 |
| カート・SNS・SaaS画面 | SSR or CSR | ― |
| ログイン後ダッシュボード・管理画面 | CSR | ― |
ISRのrevalidateは60〜600秒が標準値です。短すぎるとSSR相当のコストになり、長すぎるとユーザーが古い情報を見ます。認証必須ページはログイン状態がビルド時に決まらないためSSG化できず、SSR / CSRが必須です。
3つのシナリオで考える
個人開発・スタートアップの場合
ブログやLP、ポートフォリオであれば、AstroやNext.jsによるSSGの一択だと思います。CDN配信になるのでサーバ障害とは無縁になりますし、コストもほぼゼロで済んでしまいます。アプリを作る場合も、まずはSSGにしておいて、ログイン後だけCSRにするという単純な2分割で十分です。
中小SaaSの場合
マーケページはSSG、商品一覧・詳細はISR（revalidateは60〜300秒）、SaaS画面はSSRかCSRという形で、ページ種別ごとの仕分けを明示的に設計する段階に入ります。SEOが売上に直結するECであるほど、ISRの効果は大きくなると考えています。
大企業の場合
この規模では既存資産との共存が論点になってきます。レガシーのサーバサイドレンダリング（JSPやRails等）を残しつつ、新規画面だけNext.jsのSSRやISRに切り出していく、Strangler Fig型の段階移行が現実解でしょう。全面リプレースのビッグバンだけは避けるべきです。
AI判断軸 ― 規約ベースのFWがAIの生成精度を高める
ファイル規約はAIへの明確な構造ルール
Next.js App Routerの app/ ディレクトリ規約（page.tsx=ページ、layout.tsx=レイアウト、loading.tsx=サスペンス）は、AIにとって明確な構造ルールです。「/dashboard/settingsページを作って」と指示すれば、AIは app/dashboard/settings/page.tsx を正確に作成します。独自のルーティング設計や手書きのSSR設定では、プロジェクト固有のルールをAIに毎回教える必要があり、精度が安定しません。
Server / Client Componentsの境界設計
RSCの "use client" ディレクティブによる分類はAIが理解しやすい明示的な境界ですが、AIは "use client" を付けすぎる傾向があります。「データフェッチを含むコンポーネントはServer Component、イベントハンドラを含むコンポーネントはClient Component」という原則をプロジェクトのルールとして明文化しておくと、AIの精度が上がります。
やってはいけないこと
性能劣化・コスト爆発・SEO喪失につながる典型を、特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| マーケティングページを全部SSR | トラフィック比例でコスト爆発、関数実行枠を使い切る定番事故 → Static Firstにする |
| SEO必須サイトをCSRで構築 | クローラーのJS実行が遅延し検索流入が壊滅する → SSG / SSRにする |
| 「CSRで作ってSEOは後で」と後回し | SSR乗せ換え工数は新規より大きい → SEOが要るなら最初から方式を決める |
| SSGで1万ページ超のサイトを組む | ビルドが30分超えになる → ISRで増分ビルドに切り替える |
| Streaming SSRのSuspenseなし | 1つの遅いAPIで全HTMLがブロックされる → Suspense境界を切る |
ISRの revalidate を1秒にする | 実質SSR同等のコストになる → 60秒以上を実用域にする |
2022年のVercel Serverless Function課金事故は、SSRページにBotがアクセスして数百万円の請求書が届いた事例です。静的で済むページは静的に配信するのが鉄則です。
筆者メモ ― 「全ページSSR」で燃えた夜
静的でも十分なマーケティングページまで一律でNext.jsのSSRにしていたプロジェクトで、キャンペーン初日の夜にVercelの関数実行枠を使い切り、深夜に静的書き出しへ切り替える羽目になった──いろいろな現場で語り草になっている話です。トラフィックに比例してサーバコストが線形に増えるのがSSRの怖いところで、キャンペーンやSNSバズで一瞬で料金メーターが回ります。
教訓はシンプルで、最初からStatic Firstで組めば避けられた事故です。静的で済むページはSSG/ISR、動的が必要なページだけSSR、ログイン後はCSR、と「ページ単位で使い分ける」のがコスト・UX・運用のすべてを両立させる唯一の方法です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 主なレンダリング方式（ページ単位で整理）
- Hydration戦略（全体 / Islands / Partial）
- RSC採用の是非とServer / Client境界のルール
- ビルド頻度（SSGの場合）
- ISR再検証期限（revalidate秒数）
この記事に関連する記事
まとめ
本記事はレンダリング方式について、CSR/SSR/SSG/ISR・Hydration/Islands・Streaming SSR・RSCまで含めて解説しました。如何だったでしょうか。
「どれが最強か」ではなく「どのページにどれが合うか」。ユースケース単位で選び、規約ベースのFWに寄せるのが2026年の現実解です。
次回は状態管理（useState/Context/Redux/Zustand/TanStack Query）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Next.js 公式ドキュメント も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（38/95）