SSR/SSG/ISRの違いを、発注・稟議に使えるレベルで理解する方法（Next.js編）

SSR/SSG/ISRとは何か：まず「いつHTMLを作るか」で理解する

SSR/SSG/ISRの違いは、突き詰めると「ユーザーがページを開く瞬間に、どのタイミングでHTML（画面の骨組み）を用意するか」の違いです。ここを押さえると、開発者でなくても発注・稟議に必要な判断ができます。特にNext.jsは、この3つをページ単位で選べるため、要件の言語化が重要になります。

まず用語を「業務の例え」で置き換えます。

• SSR（Server-Side Rendering）：来客が来るたびに、その場で資料を印刷して渡す。常に最新だが、その分「印刷待ち」が起こりやすい。
• SSG（Static Site Generation）：あらかじめ必要部数を印刷して受付に置く。配布は速いが、内容を更新するたびに刷り直しが必要。
• ISR（Incremental Static Regeneration）：基本は受付に置いておき、一定時間ごとに裏で差し替える。配布は速く、更新の手間も抑えられる。

この「印刷モデル」を稟議に落とすと、比較観点は次の4つに収束します。速度（UX）、情報の鮮度、運用コスト、障害時の影響です。例えば採用サイト・サービスLPのように更新頻度が低く、アクセスが急増する可能性がある場合はSSG/ISRが強く、在庫・価格・予約枠など常に最新が必須ならSSRが候補になります。

なお、実際のWebでは「最初に返すHTML」と「その後にブラウザで動くJavaScript」が協調します。Next.jsではSSR/SSG/ISRの選択に加え、キャッシュやCDN、APIの設計が体感速度とコストを左右します。発注側としては、技術選定を丸投げするのではなく、ページ種別ごとの要件（鮮度・速度・更新頻度・編集フロー）を提示できると、見積もりのブレが減ります。

発注・稟議で効く比較軸：性能・鮮度・費用・運用・リスク

稟議で必要なのは「なぜその方式なのか」を説明できる根拠です。以下の比較軸を埋めるだけで、説明が通りやすくなります。特にNext.js案件では、ページ単位で方式が混在しやすいため、表にして合意形成すると失敗が減ります。

ここでポイントは、SSR/SSG/ISRを「どれか一つに決める」ことではありません。企業サイト・サービスサイトでは、トップ/LP/導入事例/ブログ/料金/ログイン後画面など、ページの性質が違います。Next.jsは、ページの性質に応じてSSR/SSG/ISR（またはキャッシュ戦略）を使い分けられるため、「どのページをどの方式にするか」が意思決定の中心になります。

費用面の考え方も整理しましょう。SSRはアクセスが増えるほどサーバーが処理する回数が増え、インフラ費・スケール設計が効いてきます。一方SSGは配布がCDN中心になりやすく、アクセス急増に強い反面、更新のたびにビルド・配布（再生成）が走ります。ISRはその中間で、更新頻度と鮮度のバランスを取るための方式です。稟議では「ピーク時に落ちないためのコスト」と「更新運用の人件費」の両方を数字で見積もると説得力が出ます。

SSR（サーバーで毎回生成）：最新性が最優先のページに強い

SSRは、ユーザーのリクエストごとにサーバー側でHTMLを組み立てて返します。常に最新情報を返しやすく、ユーザーごとに内容を変える（会員ランク表示、権限別メニュー、在庫・価格のリアルタイム反映など）と相性が良いのが特徴です。Next.jsでは、サーバーコンポーネントやルート単位のレンダリング方式、キャッシュ制御によってSSR相当の挙動を実現します。

発注側がSSRを選びたくなる典型は次の通りです。

• 価格・在庫・予約枠・納期など「古いと困る」情報が中心
• 会員ごとに内容が違う（マイページ、管理画面、社内ポータル）
• 検索条件や絞り込みが多く、組み合わせが膨大

一方で注意点があります。SSRはサーバーが毎回処理するため、アクセス増加時に遅くなったり、最悪タイムアウトしたりします。稟議・要件定義では、次を確認してください。想定同時アクセス、ピークの作りやすさ（広告・SNS・TV）、バックエンドAPIの応答時間です。SSR自体が悪いのではなく、SSRにするなら「落ちないための設計」を同時に買う必要があります。

また、SSRは「最新だからOK」と思われがちですが、裏側で叩くAPIが遅いと全体が遅くなります。発注時には、ページ表示に必要なAPIの数や、APIのSLA（応答目標）、キャッシュの方針（例えば数十秒は許容できるか）を握ると、開発会社の提案が具体化します。Next.jsの場合、CDN/エッジキャッシュ、アプリ側キャッシュ、DB側の最適化など複数レイヤーがあるため、「どこにキャッシュを置くか」まで含めて提案してもらうのが実務的です。

SSG（事前生成）：落ちにくく速い、ただし更新運用が肝

SSGは、ビルド時（公開前）にページのHTMLをまとめて生成し、静的ファイルとして配布する考え方です。配布はCDNで行えるため高速で、アクセスが急増しても落ちにくいのが強みです。企業のコーポレートサイトや、サービス説明、導入事例、技術ブログなど「更新頻度がそこまで高くない」コンテンツはSSGで成果が出やすいです。Next.jsはSSGを得意としており、サイト全体の体感速度と安定性を上げやすい選択肢です。

ただしSSGのボトルネックは「更新」です。ページ内容を変更したら、再ビルドして再配布が必要になります。発注・稟議では更新頻度と公開の締め切りを必ず詰めてください。例えば「法務チェック後、即時に反映したい」「キャンペーン開始時刻に合わせたい」などがある場合、更新フローとビルド時間がリスクになります。

SSG向きの業務シーンは次の通りです。

• 採用ページ、会社概要、サービスLPなど、更新は月数回程度
• SEOを重視する記事・事例（検索流入が主目的）
• 障害時も最低限の情報提供を止めたくない（BCP観点）

一方で「SSGにしたのに、結局遅い/運用が回らない」失敗もあります。原因は、静的HTMLのはずが、初回表示に大量のJavaScriptや外部タグが入っていて重いケース、あるいはCMS更新のたびに長時間ビルドが走り公開が遅れるケースです。要件としては、ページ速度目標（LCPなどの指標）、外部計測タグの上限や運用ルール、ビルド時間の目標を契約前に確認すると安心です。Next.jsではサイト規模が大きいほどビルド時間が伸びやすいので、ISRや分割ビルド、コンテンツ設計の工夫が必要になります。

ISR（段階的に再生成）：速度と鮮度のバランスを取り、運用も現実的にする

ISRは、基本はSSGのように静的配布しつつ、一定間隔や条件に応じてページを再生成して差し替える方式です。「静的の速さ・落ちにくさ」と「更新のしやすさ」のバランスを取れます。Next.js文脈では、ページやルートのキャッシュ再検証（revalidate）やオンデマンド再生成などを組み合わせて実現することが多いです。

発注側がISRを採用すると効果が出やすいのは、次のようなケースです。

• 新着情報・ブログ・導入事例など、更新はあるが「数分の遅れは許容できる」
• 商品一覧・店舗一覧など、頻繁に変わるがリアルタイムでなくても業務が回る
• 大規模サイトでSSGだとビルドが重く、公開が間に合わない

ISRを稟議で通すコツは、「許容できる古さ」を決めることです。例えば「記事は最大10分遅れでもOK」「料金は即時反映が必要」など、ページ種別ごとにSLAを置きます。ここが曖昧だと、開発会社は安全側に倒してSSRに寄せがちで、結果としてインフラ費が膨らみます。逆に更新要件が厳しいのにISRで逃げると、ユーザーや現場のクレームにつながります。許容遅延（例：5分/1時間/24時間）を明文化するだけで、設計の質が上がります。

注意点として、ISRは「仕組みが良いから運用が不要」ではありません。再生成の失敗時にどう検知するか、CMS更新と再生成をどう連携するか、誤って古い内容が長時間残った場合の対処（手動の再生成やキャッシュクリア）が必要です。発注時には、再生成の監視・ログ、失敗時の復旧手順、オンデマンド再生成（更新ボタンで即反映）の有無を確認してください。Next.jsでISRを採用する場合、ホスティング基盤やCDNの仕様で挙動が変わることがあるため、環境前提（どこにデプロイするか）まで含めて提案を受けるのが実務的です。

Next.js案件の稟議を通す要件定義テンプレ：ページ分類と質問集

専門知識がなくても、発注側が押さえるべきは「方式の選択」ではなく「要件の言語化」です。Next.jsはSSR/SSG/ISRを混在させられるため、ページごとに必要十分な方式を選ぶのが費用対効果の王道です。ここでは、稟議に貼れるレベルのテンプレを提示します。この項目を埋めて開発会社に投げるだけで、見積もりの精度が上がります。

次に、見積もり比較で効く質問集です。提案依頼書（RFP）や稟議資料にそのまま入れられます。

• どのページをSSR/SSG/ISRにし、理由は何ですか（鮮度要件・速度目標との対応を説明してもらう）
• キャッシュ方針（CDN/サーバー/ブラウザ）と、更新時の反映手順はどうなりますか
• ピークアクセス時の想定と、落ちないためのスケール設計・コスト試算はありますか
• CMS連携（WordPress/Headless CMS等）の場合、公開承認フローと即時反映の可否は
• 運用監視：再生成失敗や表示遅延をどう検知し、誰が対応しますか
• SEO：インデックスされるべきページ、noindex対象、構造化データ、ページ速度改善の方針は
• セキュリティ：ログイン領域の認可、API保護、個人情報の取り扱い、脆弱性対応の範囲は

この質問にきちんと答えられる開発会社は、設計と運用をセットで考えています。逆に「全部SSRが安全です」「とりあえずSSGにしましょう」のような一択回答しか出ない場合、要件の解像度が合っていない可能性があります。Next.jsは自由度が高い分、要件を整理しないと、速度・コスト・運用のどれかでしわ寄せが出やすい点に注意してください。

まとめ

SSR/SSG/ISRは「どれが正解か」ではなく、ページごとの鮮度要件・速度目標・運用フローに合わせて選ぶのが本質です。SSRは最新性やユーザー別表示に強い一方、ピーク時コストと設計が重要。SSGは高速・安定でSEOにも向きますが、更新運用とビルド時間が要注意。ISRはその中間として、許容できる更新遅延を明文化すると効果を発揮します。

Next.jsはSSR/SSG/ISRを混在できるため、発注・稟議では「ページ分類テンプレ」と「質問集」を使い、方式選定の理由を可視化するのが近道です。まずは自社サイトを「固定情報」「コンテンツ」「一覧」「ユーザー別」に分け、各タイプの鮮度SLA（何分古くてよいか）とピーク想定を決めてください。そこから先は、提案内容の比較ができるようになり、見積もりの妥当性も判断しやすくなります。