Webアプリ設計におけるレンダリングアーキテクチャの基本概念　SPA・SSR・SSG・ISR

Section 6

Webアプリケーション開発の全体像と設計プロセスの理解

はじめに

この章では、Webアプリケーションのアーキテクチャを、特定のフレームワークやライブラリに依存せずに理解します。

ここでいうアーキテクチャとは、

  • どこで HTML を作るか
  • いつページを作るか
  • どのようにデータを取得し
  • どう更新するか という全体設計のことです。MDN は SPA を、単一の HTML 文書を読み込み、その本文を JavaScript API で更新する実装と定義しています。

web.dev は、Web の描画方式として CSR、SSR、prerendering を整理しています。Next.js の公式ドキュメントは ISR を、静的ページを全体再ビルドなしに更新できる方式として説明しています。

この章の目的は、方式名を暗記することではありません。SPA・SSR・SSG・ISR が、それぞれどの課題に対して、どのような強みと弱みを持つかを説明できるようになることです。

これが理解できれば、React、Vue、Svelte、Next.js、Nuxt、Astro など、使う技術が変わっても本質は見失いません。

この章で学ぶこと

  • SPA・SSR・SSG・ISR の基本概念
  • それぞれが解決しようとしている課題
  • 初期表示速度、SEO、更新性、運用負荷の違い
  • 方式ごとの向き不向き
  • 実際のサービスでの使い分け方

1. なぜアーキテクチャを分けて考えるのか

Webアプリケーションは、どれも同じ方法で作ればよいわけではありません。管理画面のように操作性を重視したい場合もあれば、記事ページのように検索流入や初期表示を重視したい場合もあります。

web.dev が整理するように、CSR、SSR、prerendering はそれぞれ異なる利点と制約を持っています。

そのため、アーキテクチャは技術趣味ではなく、課題に対する設計上の選択として考える必要があります。

1-1. すべてを同じ作り方で考えると何が起こるか

すべてをクライアント側で描画すると、操作は滑らかでも、初期表示が遅くなったり、検索エンジンとの相性が悪くなったりすることがあります。

逆に、すべてをサーバー側で毎回描画すると、初期表示は速くても、サーバー負荷が高くなりやすく、更新頻度や運用コストの面で不利になることがあります。

静的生成を多用すると高速化しやすい一方で、更新のたびに再生成が必要になりやすいです。

1-2. アーキテクチャとは何か

この章でいうアーキテクチャは、次の四つの問いへの答えです。

  1. どこで HTML を生成するのか
  2. いつ HTML を生成するのか
  3. どこでデータを取得するのか
  4. ページや内容をどう更新するのか この四つを整理すると、SPA、SSR、SSG、ISR の違いが見えやすくなります。

1-3. この章で扱う4つの方式

flowchart LR
  A[SPA] --> B[クライアント側で更新]
  C[SSR] --> D[リクエスト時にサーバーで生成]
  E[SSG] --> F[ビルド時に静的生成]
  G[ISR] --> H[静的生成 + 段階的再生成]
  • SPA: 単一の HTML 文書を読み込み、クライアント側で内容を更新する方式
  • SSR: リクエストごとにサーバー側で HTML を生成する方式
  • SSG: ビルド時に静的 HTML を生成して配信する方式
  • ISR: 静的生成の利点を保ちつつ、後から段階的に再生成する方式

この四つは排他的な宗派ではなく、課題に応じて使い分ける道具です。

まとめ

  • アーキテクチャは、どこで・いつ・どう生成し更新するかの設計です。
  • 方式ごとに、速度、SEO、更新性、運用負荷のバランスが異なります。
  • 重要なのは、どれが優れているかではなく、どの課題に向くかです。

2. SPAの基本概念

SPA は Single-page application の略です。MDN は SPA を、単一の Web 文書を読み込み、表示内容を JavaScript API で更新する実装と定義しています。

つまり、最初に土台を読み込み、以後はページ全体を再読み込みせずに、必要な部分だけを書き換えながら体験を作る方式です。

2-1. SPAで何が起こるのか

SPA では、最初のアクセス時に HTML、CSS、JavaScript を取得し、その後はクライアント側の JavaScript が画面を制御します。新しい情報が必要になれば、Fetch API などでデータを取得し、画面の一部を更新します。

ページ遷移の見た目はあっても、実際には完全な再読み込みを行わずに、同じ文書の中で状態を変化させ続けることが多いです。

2-2. SPAの利点

SPA の大きな利点は、アプリのように滑らかな操作感を作りやすいことです。

再読み込みが少ないため、ログイン後の管理画面、ダッシュボード、複雑な入力フォーム、リアルタイムに近い操作体験と相性が良いです。

また、クライアント側状態管理とも結びつけやすいです。

2-3. SPAの弱点

一方で、MDN も SPA には tradeoff disadvantages があると述べています。

代表例は、SEO への不利、状態管理やナビゲーション設計の難しさ、意味のあるパフォーマンス監視の難しさです。

さらに、初期ロード時に JavaScript の負担が大きいと、最初の表示が重くなりやすいです。

まとめ

  • SPA は、単一文書を起点にクライアント側で内容を更新する方式です。
  • 操作体験は滑らかですが、初期ロードや SEO、状態管理に注意が必要です。
  • 管理画面やアプリ的な操作体験が必要な場面に向きやすいです。

3. SSRの基本概念

SSR は Server-side rendering の略で、リクエスト時にサーバーが HTML を生成して返す方式です。

web.dev は SSR を、サーバーがページ用の HTML を生成し、それをクライアントへ返す方式として整理しています。

クライアントはまず完成に近い HTML を受け取れるため、初期表示に有利です。

3-1. SSRで何が起こるのか

SSR では、ユーザーがページを要求するたびに、サーバーが必要なデータを集めて HTML を生成し、その場で返します。つまり、ページ内容がリクエストごとに変わる前提に強い方式です。

ユーザーごとに異なる内容を返したい場合や、最新データを毎回反映したい場合に相性が良いです。

3-2. SSRの利点

SSR の利点は、初期表示が分かりやすく、SEO に強くなりやすいことです。検索エンジンや共有プレビュー向けに、最初から HTML が存在することは大きな利点になります。

また、低性能端末でも、最初の画面が見えやすいことがあります。

3-3. SSRの弱点

SSR は、リクエストごとにサーバー処理が必要になるため、サーバー負荷が増えやすいです。

さらに、毎回生成する設計は、静的配信より運用コストが上がりやすくなります。つまり、SEO と初期表示には強い一方で、毎回処理するコストを負担する方式です。

まとめ

  • SSR は、リクエスト時にサーバーが HTML を生成する方式です。
  • 初期表示や SEO に強いですが、サーバー負荷や運用コストが増えやすいです。
  • 検索流入が重要な公開ページや、毎回内容が変わるページに向きやすいです。

4. SSGの基本概念

SSG は Static Site Generation の略で、ビルド時に HTML を静的生成しておき、そのまま配信する方式です。

web.dev では、prerendering の一つとして、事前に HTML を生成する考え方が説明されています。サーバーはリクエストのたびにページを作らず、完成済みのファイルを返します。

4-1. SSGで何が起こるのか

SSG では、公開前やビルド時にあらかじめ HTML を生成します。そのため、利用者がアクセスした時点では、サーバー側で重い計算をする必要がありません。

静的ファイルとして配信しやすく、高速表示と安定した配信に向きます。

4-2. SSGの利点

SSG の利点は、高速性、安定性、SEO の強さです。記事、ドキュメント、企業サイトなど、更新頻度が極端に高くないページでは、とても相性が良いです。

また、サーバー負荷も小さくなりやすいです。

4-3. SSGの弱点

SSG の弱点は、更新のたびに再生成が必要になりやすいことです。ページ数が多い場合、ビルド時間が長くなりやすく、更新頻度が高いページでは不便になることがあります。

つまり、配信は軽いが、更新の仕組みは別途考える必要があります。

まとめ

  • SSG は、ビルド時に HTML を作っておく方式です。
  • 高速で SEO に強く、安定配信しやすいです。
  • ただし、更新頻度が高いページでは再ビルド負荷が問題になりやすいです。

5. ISRの基本概念

ISR は Incremental Static Regeneration の略です。Next.js の公式ドキュメントは、ISR を静的ページを全体再ビルドなしで更新する仕組みとして説明しています。

SSG の高速性を保ちながら、必要なページだけを段階的に再生成できる考え方です。

5-1. ISRで何が起こるのか

ISR では、まず静的ページを返します。その後、一定時間経過後や条件に応じて、バックグラウンドで新しい静的ページを再生成します。

つまり、リクエストごとに毎回 SSR するのではなく、静的配信を基本にしつつ、更新を段階的に差し込む方式です。

5-2. ISRの利点

ISR の利点は、静的配信の速さを保ちながら、更新負荷を下げやすいことです。大量の商品ページや記事ページのように、更新はあるが毎回 SSR するほどではない場面で有効です。

全ページ再ビルドを避けやすいことも大きな利点です。

5-3. ISRの弱点

ISR は便利ですが、更新タイミングの理解が必要です。「今見えている内容がいつ更新されたものか」という一貫性設計が重要になります。

また、実装としてはフレームワーク依存になりやすく、概念は汎用でも、実装方法は環境ごとに違いやすいです。

まとめ

  • ISR は、静的生成の高速性と更新性のバランスを取る方式です。
  • 全体再ビルドを避けながら、段階的にページを更新できます。
  • ただし、更新タイミングと一貫性の設計が重要です。

6. 4つの方式を比較する

方式を理解するときは、名前を覚えるより、比較軸で整理したほうが実務に強いです。

主な比較軸は、初期表示速度、SEO、更新しやすさ、サーバー負荷、実装難易度、運用しやすさです。

web.dev も、描画方式を比較する際に、パフォーマンスやレンダリング場所の違いを重要視しています。

方式主な特徴強み注意点
SPAクライアント側で更新滑らかな操作体験初期ロード、SEO、状態管理
SSRリクエスト時にサーバー生成初期表示、SEOサーバー負荷
SSGビルド時に静的生成高速、安定、SEO再ビルド負荷
ISR静的生成 + 段階更新高速性と更新性の両立更新タイミング設計

まとめ

  • 万能な方式はありません。
  • 比較軸で整理すると、方式の違いを実務に結びつけやすいです。
  • どの方式が優れているかではなく、どの課題に向くかで選ぶべきです。

7. よくある誤解

アーキテクチャの学習では、方式名だけが独り歩きしやすいです。ここでは、よくある誤解を整理します。

7-1. SPAは古く、SSRが常に正しいという誤解

SPA は古いからダメ、SSR が新しくて正しい、という理解は正確ではありません。

管理画面やアプリ的な操作体験では、SPA の性質が有効な場面があります。MDN も SPA の利点として dynamic experience を挙げています。

7-2. SEOのためにSSR一択という誤解

SEO を考えると、確かに SSR や SSG は有利になりやすいです。しかし、SEO が重要でない領域、たとえばログイン後の業務画面まで同じ方式にする必要はありません。検索流入の重要度で考えるべきです。

7-3. SSGは更新できないという誤解

SSG は更新できないのではなく、更新のたびに再生成が必要になりやすい方式です。そこを補う考え方の一つが ISR です。

7-4. ISRは何でも解決するという誤解

ISR は便利ですが、更新タイミング、一貫性、フレームワーク依存の実装など、設計上の注意点があります。万能ではありません。

7-5. 1つのサービスで1方式しか使えないという誤解

実際のサービスでは、公開ページは SSG や SSR、管理画面は SPA 的設計、一覧ページは ISR というように、複数方式を併用することが珍しくありません。

アーキテクチャはサービス単位ではなく、ページや機能単位で考えることもできます。

まとめ

  • 方式を善悪で覚えると誤解しやすいです。
  • 方式ごとに得意な課題が違うと理解することが重要です。
  • 実際のサービスでは、複数方式の併用も十分ありえます。

8. 実際のサービスではどう使い分けるのか

アーキテクチャは、サービス全体に一つだけ適用する必要はありません。

公開ページと管理画面、一覧と詳細、更新頻度が高いページと低いページでは、求める条件が違うからです。

8-1. 公開ページと管理画面で分ける考え方

  • 公開ページ: SEO と初期表示が重要 → SSR / SSG / ISR が候補
  • 管理画面: 操作性と状態管理が重要 → SPA が候補

8-2. 一覧ページと詳細ページで分ける考え方

  • 一覧: 更新頻度が高い、検索流入も重要 → ISR や SSR が候補
  • 詳細: 比較的安定、検索対象になりやすい → SSG / ISR / SSR が候補

8-3. 更新頻度とSEO重要度で分ける考え方

  • 更新少 + SEO重要 → SSG
  • 更新中 + SEO重要 → ISR / SSR
  • SEO低 + 体験重視 → SPA

まとめ

  • アーキテクチャは、ページや機能単位でも選べます。
  • 検索流入、更新頻度、操作性の三つが重要な判断軸です。
  • 一つの方式に統一するより、課題ごとに選ぶほうが合理的なことがあります。

9. 具体例で考える

9-1. コーポレートサイト

会社概要、採用、問い合わせなどが中心なら、内容変化は比較的少なく、初期表示や SEO が重要です。SSG と相性が良いです。

9-2. ブログ・メディア

記事一覧や記事詳細は検索流入が重要です。一方で更新も継続的にあります。そのため、SSG や ISR が候補になります。

9-3. ECサイト

商品詳細やカテゴリ一覧は SEO が重要で、価格や在庫更新もあります。ISR や SSR が向きやすいです。カートやマイページは SPA 的な操作性も欲しくなります。

9-4. 管理画面

ログイン後に、状態を持ちながら操作を繰り返す管理画面では、SPA 的な設計が向きやすいです。

9-5. SaaSダッシュボード

公開ランディングページは SSG / SSR、ログイン後のダッシュボードは SPA、更新頻度の高い公開一覧は ISR のように、複数方式を併用する構成が現実的です。

まとめ

  • サービス種別によって、求められる特性が違います。
  • 実務では、公開ページと業務画面で方式を分けることが多いです。
  • 具体例に当てはめて考えると、方式選択の理由が見えやすくなります。

10. この章の到達目標

この章を終えた時点で、次の内容を説明できるようになることを目指します。

  • SPA とは何か

  • SSR とは何か

  • SSG とは何か

  • ISR とは何か

  • それぞれの強みと弱み

  • どの課題にどの方式が向くか また、次の区別ができることも重要です。

  • どこで描画するか

  • いつ HTML を生成するか

  • SEO と更新性の違い

  • 配信速度と運用負荷の違い

まとめ

  • この章のゴールは、方式名を言えることではありません。
  • 方式を課題に結びつけて選べることが重要です。
  • フレームワークが変わっても、判断軸が残る状態を目指します。

11. 考えてみよう

  • なぜ一つの方式だけでは、すべての課題を解けないのでしょうか。
  • なぜ SEO、速度、更新性はトレードオフになりやすいのでしょうか。
  • なぜ管理画面と公開ページで方式を分けることがあるのでしょうか。
  • なぜ「どこで」「いつ」生成するかがアーキテクチャの核心なのでしょうか。

12. まとめ

  • SPA は、単一文書を読み込み、JavaScript で本文を更新する方式です。
  • SSR は、サーバーが HTML を生成して返す方式です。
  • SSG は、ビルド時に HTML を静的生成する方式です。
  • ISR は、静的生成の利点を保ちながら、段階的に更新する方式です。
  • 重要なのは、方式名を覚えることではなく、どの課題にどの方式が向くかを判断できるようになることです。

参考文献

前の節Webアプリ設計における役割分担とAI活用の責務設計次の節GitHubリポジトリから学ぶWebアプリ構造分析の基礎
教材トップへ戻る