SSR・SSG・ISRとは？Webページ生成の3つの方式
Webサイトのリニューアルや新規構築を検討する際、「SSR」「SSG」「ISR」という用語を耳にする機会が増えています。これらはWebページをいつ生成するかという「レンダリング方式」の違いを表す言葉です。
難しく聞こえるかもしれませんが、実は「いつHTMLを作るか」という単純な違いです。この記事では、SSR・SSG・ISRの違いを初心者の方にも分かりやすく解説し、あなたの会社に最適な選択ができるようサポートします。
3つの手法を一言で表すと
まず、それぞれの特徴を端的に理解しましょう。
- SSR（Server Side Rendering）: リクエストのたびにサーバーでHTMLを生成
- SSG（Static Site Generation）: ビルド時に全ページを事前に生成
- ISR（Incremental Static Regeneration）: 定期的に自動で再生成するSSG
ユーザーがブラウザでURLにアクセスすると、サーバーまたはブラウザがHTMLを作成し、画面に表示します。この「どこで、いつHTMLを生成するか」の違いが、3つの手法の本質的な違いです。
なぜ今これらの手法が注目されているのか
現代のWebサイトには、相反する要求が同時に求められます。
- 表示速度の高速化
- SEO対策の強化
- 最新情報の表示
- 運用コストの削減
- 開発・保守の効率化
これらすべてを満たす「完璧な方法」は存在しません。しかし、サイトの特性に合わせて最適な手法を選ぶことで、バランスの取れた運用が可能になります。
特にNext.jsなどのモダンなフレームワークの登場により、中小企業でも「ちょうどいい」選択ができる時代になりました。
SSR（Server Side Rendering）：常に最新データを表示
SSRは、ユーザーがページにアクセスするたびに、サーバー側でHTMLを生成する方式です。
SSRの仕組みと処理フロー
- ユーザーがページにアクセス
- サーバーがデータベースやAPIから最新データを取得
- サーバーがデータを使ってHTMLを生成
- 完成したHTMLをブラウザに送信
- ブラウザが画面に表示
このプロセスはアクセスのたびに毎回実行されるため、常に最新のデータでページが生成されます。
SSRのメリット・デメリット
メリット
- データの鮮度が保証される（常に最新）
- SEO対策がしやすい（完成したHTMLが配信される）
- ユーザーごとのパーソナライズが可能
デメリット
- サーバー負荷が高い（アクセスのたびに処理）
- 運用コストが上がる（月額10,000円〜30,000円程度）
- 表示速度にばらつきが生じる可能性
SSRが向いているサイト
- リアルタイム性が重要: 株価情報、スポーツのスコア表示
- ユーザーごとに内容が変わる: マイページ、会員専用コンテンツ
- 頻繁にデータが更新される: ニュースサイト、SNS
- 在庫や予約状況を表示: ECサイトの商品詳細、予約システム
中小企業では、「顧客管理システムのダッシュボード」や「予約状況を表示する管理画面」など、データの鮮度が最優先される場面でSSRを検討すると良いでしょう。
SSG（Static Site Generation）：高速表示と低コスト運用
SSGは、ビルド時（サイト構築時）に全ページのHTMLを事前生成し、静的ファイルとして配信する方式です。
SSGの仕組みと処理フロー
ビルド時
1. 開発者がビルドコマンドを実行
2. 全ページ分のデータを取得
3. すべてのページのHTMLを一括生成
4. 生成されたHTMLファイルをCDNにアップロード
ユーザーアクセス時
1. ユーザーがページにアクセス
2. CDNから事前生成されたHTMLをそのまま配信
3. ブラウザが即座に表示
重要なのは、ユーザーがアクセスする時点では、すでにHTMLが完成しているという点です。サーバー側で処理を行う必要がないため、非常に高速に配信できます。
SSGのメリット・デメリット
メリット
- 圧倒的な表示速度（0.1秒以下での表示も可能）
- 運用コストが非常に安い（月額0円〜3,000円）
- サーバー負荷がほぼゼロ
- SEO対策に最適
- セキュリティリスクが低い
デメリット
- 更新のたびにビルドが必要
- ビルド時間がかかる（ページ数が多い場合）
- リアルタイムデータの表示が困難
- ユーザーごとのパーソナライズが難しい
SSGが向いているサイト
- 更新頻度が低い: 月に数回程度の更新で十分
- 全ユーザーに同じ内容を表示: パーソナライズが不要
- コンテンツ中心: 情報提供が主な目的
具体例
- コーポレートサイト（会社概要、サービス紹介）
- ブログやオウンドメディア
- 製品カタログ
- ランディングページ（LP）
中小企業の多くが運営する「会社のホームページ」は、まさにSSGが最適です。「ちょうどいい」コストと性能のバランスが実現できます。
ISR（Incremental Static Regeneration）：柔軟性とパフォーマンスの両立
ISRは、SSGの高速性とSSRのデータ鮮度を両立させた手法です。Next.jsで初めて実装され、現在では多くのフレームワークが採用しています。
ISRの仕組みと処理フロー
- 初回ビルド時: SSGと同様に全ページのHTMLを生成
- ユーザーアクセス時: 生成済みのHTMLを高速配信
- 再検証（Revalidation）: 設定した時間が経過したら、バックグラウンドで再生成
- 更新完了後: 次回アクセスから新しいHTMLが配信される
重要なのは「revalidate」という設定です。これは「何秒ごとに再生成するか」を指定するもので、例えば60秒に設定すれば、最大60秒の遅延で最新データが反映されるようになります。
また、「オンデマンド再検証」を使えば、CMSで記事を公開したタイミングで自動的にサイトに反映させることも可能です。
ISRのメリット・デメリット
メリット
- 高速配信を維持（SSG並みの速度）
- 自動更新が可能（設定した間隔で更新）
- サーバー負荷が低い（SSRより大幅に軽い）
- 運用が楽（手動ビルド不要）
- 段階的な生成が可能
デメリット
- 設定の理解が必要（revalidateの適切な値の判断）
- 完全なリアルタイムではない（設定時間分の遅延）
- キャッシュの仕組みの理解が必要
- Next.js依存（他のフレームワークは対応が限定的）
revalidate設定の目安
- ニュースサイト: 60秒〜300秒
- ECサイト商品ページ: 300秒〜3600秒
- ブログ: 3600秒〜86400秒
- コーポレートサイト: 86400秒〜
ISRが向いているサイト
- 定期的に更新される: 1日数回〜数十回の更新
- ある程度の遅延が許容できる: 数分〜数時間の遅延なら問題ない
- CMSで管理: WordPressやHeadless CMSと連携
具体例
- ニュースサイトやメディア
- ECサイトの商品一覧・詳細ページ
- イベント情報サイト
- 不動産サイトの物件情報
中小企業の場合、「定期的に情報を発信したいが、リアルタイムまでは不要」というケースが多く、ISRは理想的な選択肢になります。
SSR・SSG・ISRの違いを比較表で理解する
主要な違いの比較
| 項目 | SSR | SSG | ISR |
|---|---|---|---|
| レンダリング | リクエスト時 | ビルド時 | ビルド時+定期更新 |
| データ鮮度 | 常に最新 | ビルド時の状態 | 設定間隔で更新 |
| 表示速度 | 処理時間に依存 | 最速 | 最速 |
| サーバー負荷 | 高い | ほぼゼロ | 低い |
| 運用コスト | 10,000円〜 | 0円〜3,000円 | 0円〜5,000円 |
| SEO対策 | 優れている | 最適 | 最適 |
| 更新の手間 | 不要 | 手動ビルド必要 | 自動更新 |
あなたのサイトに最適な手法を選ぶ3つの質問
質問1: どのくらいの頻度でコンテンツを更新しますか？
- 常に最新が必要 → SSR
- 月に数回程度 → SSG
- 1日数回〜数十回 → ISR
質問2: データの遅延はどこまで許容できますか？
- 1秒も許容できない → SSR
- 数時間〜1日の遅延は問題ない → SSG
- 数分〜数時間なら許容できる → ISR
質問3: 運用コストをどこまで抑えたいですか？
- コストより性能優先 → SSR
- できるだけ低コストで → SSG
- バランスを取りたい → ISR
実際の導入事例：サイトタイプ別の最適な選択
コーポレートサイト・ブログ
最適な手法: SSG または ISR
コーポレートサイトは更新頻度が低く、全訪問者に同じ内容を見せれば良いため、SSGが最適です。ブログを併設して定期的に記事を投稿する場合は、ISRを選ぶと運用が楽になります。
ECサイト・商品カタログ
最適な手法: ISR または SSR
商品一覧や詳細ページはISRで高速配信しつつ、在庫数や価格は定期的に更新します。カート機能やマイページなど、ユーザーごとに内容が変わる部分はSSRを組み合わせます。
会員制サイト・ダッシュボード
最適な手法: SSR
ユーザーごとに異なる情報を表示し、リアルタイム性が求められる場合はSSR一択です。データの鮮度が最優先されます。
ニュースサイト・メディア
最適な手法: ISR
記事は増えますが、既存記事はあまり変わらないため、ISRが最適です。revalidateを60秒〜300秒に設定すれば、新着記事も数分以内に反映されます。
Next.jsでの実装：基本コード例
App Routerでの実装方法
SSG（デフォルト）
// app/page.tsx
export default async function Page() {
const data = await fetch('https://api.example.com/data');
return <div>{/* コンテンツ */}</div>;
}
ISR（revalidate設定）
// app/page.tsx
export const revalidate = 60; // 60秒ごとに再検証
export default async function Page() {
const data = await fetch('https://api.example.com/data');
return <div>{/* コンテンツ */}</div>;
}
SSR（キャッシュ無効化）
// app/page.tsx
export const dynamic = 'force-dynamic';
export default async function Page() {
const data = await fetch('https://api.example.com/data');
return <div>{/* コンテンツ */}</div>;
}
実装時につまずきやすいポイント
- キャッシュの仕組みの理解不足: Next.jsはデフォルトでキャッシュを活用します
- revalidateの設定ミス: 短すぎるとコスト増、長すぎるとデータが古くなる
- 環境変数の扱い: ビルド時と実行時で異なる動作をする
専門家への相談を検討すべきケース
- 自社に技術者がいない、または技術的な理解に不安がある
- 複数の手法を組み合わせる必要がある
- 既存システムとの連携が必要
- パフォーマンス最適化やSEO対策を徹底したい
Harmonic Societyでは、中小企業向けの「ちょうどいい」システム構築を支援しています。技術的な相談から実装、運用サポートまで一気通貫で対応可能です。
まとめ：自社に合った選択で最適なWebサイトを
3つの手法の違いをおさらい
- SSR: 常に最新データを表示したい場合に最適（コスト高）
- SSG: 更新頻度が低く、高速表示と低コストを実現したい場合に最適
- ISR: 定期的な更新と高速表示を両立したい場合に最適
選択の基準は「更新頻度」と「データ鮮度」
最も重要な判断基準は、どのくらいの頻度で更新し、どこまでデータの鮮度が求められるかです。多くの中小企業のサイトでは、完全なリアルタイム性は不要なケースが多く、SSGやISRで十分な効果が得られます。
まずは小さく始めて、段階的に最適化する
最初から完璧を目指す必要はありません。まずはシンプルな構成で始め、アクセス状況やユーザーの反応を見ながら段階的に最適化していくことをお勧めします。
困ったときは専門家に相談することも一つの手です。技術的な判断に不安がある場合は、ぜひHarmonic Societyにご相談ください。あなたのビジネスに「ちょうどいい」ソリューションをご提案します。