Next.jsの静的生成(SSG)とSSRの違い、案件での使い分け方を解説

2025年10月24日2025年11月22日

林萌

初めての Next.js 案件で失敗した話

2022年の秋、私は初めて Next.js の案件を受けた。クライアントは中小企業向けのニュースメディアで、「WordPressからNext.jsへリプレイスしたい」という依頼だった。

報酬は80万円。納期は2ヶ月。当時の私はReactの経験が2年ほどあって、「Next.jsもReactベースだし、余裕でしょ」って思ってた。甘かった。

プロジェクトを始めて2週間。getStaticPropsを使って全ページをSSG（静的生成）で実装した。ローカル環境での動作は完璧。ビルドも通る。本番環境にデプロイして、クライアントに確認してもらった。

「記事を更新したんですが、サイトに反映されません…」

クライアントからメッセージが届いた。そこで初めて気づいた。SSGはビルド時にページを生成するから、記事を更新してもサイトに反映されない。再ビルドが必要だってことを、理解してなかった。

深夜の自宅で、ノートパソコンを開いてエラー画面を見つめる30代男性エンジニアの線画イラスト

慌ててSSRに切り替えたけど、今度はページの表示速度が遅くなった。クライアントから「遅すぎる」ってクレームが来た。最終的にISR（Incremental Static Regeneration）に落ち着いたけど、納期は1週間遅延。報酬も減額された。

あの失敗から3年。今では月に5件ほどNext.js案件をこなしてる。SSGとSSRの違いも完璧に理解した。クライアントの要件を聞いて、5分でどちらを使うか判断できるようになった。

この記事では、私が実案件で学んだ「SSGとSSRの違い」と「使い分け方」を徹底解説する。あの時の私みたいに失敗してほしくない。Next.jsを学んでる人、案件を受けようとしてる人、ぜひ最後まで読んでほしい。

Next.js の SSG と SSR、何が違うのか

Next.jsには複数のレンダリング手法がある。SSG、SSR、ISR、CSR…最初は混乱すると思う。でも、実務で使うのは主にSSGとSSR。まずはこの2つをしっかり理解すれば、案件の8割は対応できる。

SSG（Static Site Generation / 静的サイト生成）とは

SSGは、ビルド時に全ページのHTMLを生成して、そのHTMLをユーザーに返す方式。

具体的な流れ：

npm run build を実行
Next.jsがすべてのページのHTMLを生成
生成されたHTMLファイルがサーバーに配置される
ユーザーがアクセスすると、生成済みのHTMLを返すだけ

つまり、ページが表示される前にHTMLが完成してる。だから超高速。

例えば、ブログ記事が100個あるサイトをSSGで作ると：

ビルド時に100個のHTMLファイルが生成される
記事を新しく追加したら、再ビルドが必要
ユーザーがアクセスすると、すでに完成してるHTMLが表示される

私が最初に失敗したのがこれ。記事を更新しても反映されない理由が、ビルド時にHTMLが固定されるから。WordPress感覚で考えてたから、「記事更新したら即反映」って思い込んでた。

SSR（Server-Side Rendering / サーバーサイドレンダリング）とは

SSRは、ユーザーがアクセスするたびに、サーバーでHTMLを生成して返す方式。

具体的な流れ：

ユーザーがページにアクセス
サーバーがデータを取得
サーバーがHTMLを生成
生成されたHTMLをユーザーに返す

つまり、リクエストのたびにHTMLを作ってる。だから常に最新のデータが表示される。

例えば、TwitterやInstagramみたいなSNSはSSRに向いてる：

ユーザーがアクセスするたびに最新の投稿を取得
ユーザーごとに表示内容が違う（タイムラインとか）
データの更新が頻繁

私が最初の案件でSSRに切り替えたのは、記事更新を即座に反映させるため。でも、アクセスのたびにサーバーで処理するから、SSGより遅くなった。

カフェでノートパソコンを開き、Next.jsのドキュメントを読みながらコーヒーを飲む20代女性エンジニアの線画イラスト

SSG と SSR の決定的な違い

一番の違いは、HTMLを生成するタイミング。

項目	SSG	SSR
HTML生成	ビルド時（1回だけ）	リクエスト時（毎回）
表示速度	超高速（CDN配信可）	やや遅い（サーバー処理必要）
データの鮮度	古い（再ビルドまで更新されない）	常に最新
サーバー負荷	低い（静的ファイル配信のみ）	高い（毎回処理）
SEO	最強（完全なHTML）	良い（完全なHTML）

私が実案件で学んだのは、「どっちが優れてる」じゃなく「どっちが適切か」ってこと。サイトの特性によって使い分けるのが正解。

SSG（静的生成）を深く理解する

SSGは Next.js の公式でも推奨されてるレンダリング手法。パフォーマンスが最高だから。私も案件の7割はSSGで実装してる。

SSG の仕組みを図で理解

ビルド時に何が起きてるか、順を追って説明する。

開発者がビルドコマンドを実行

   npm run build

Next.jsがgetStaticPropsを実行

外部APIからデータ取得
データベースから記事取得
CMSからコンテンツ取得

取得したデータを使ってHTMLを生成

すべてのページ分のHTMLファイルが作られる
/blog/article-1.html
/blog/article-2.html
…

生成されたHTMLをサーバーに配置

VercelやNetlifyにデプロイ
CDNに自動配信される

ユーザーがアクセス

すでに完成してるHTMLを返すだけ
サーバー処理ゼロ
超高速表示

実際に私が担当したコーポレートサイト案件では、SSGで実装したおかげでページ表示速度が0.8秒→0.2秒に改善した。クライアントから「めちゃくちゃ速い！」って喜ばれた。

SSG のメリット

実案件でSSGを使う理由は、圧倒的なメリットがあるから。

1. 表示速度が最速

HTMLが事前に生成されてるから、サーバーでの処理がゼロ。ファイルを返すだけ。しかもCDNに配信できるから、世界中どこからアクセスしても高速。

私がメンターしてる受講生が作ったポートフォリオサイトは、SSGで実装してLighthouseスコアが98点。クライアントからの評価が爆上がりした。

2. サーバー負荷がほぼゼロ

静的ファイルを返すだけだから、サーバーに負荷がかからない。1日100万PVのサイトでも、サーバーダウンの心配がない。

実際、私が担当したメディアサイトは月間500万PV。SSGで実装したから、サーバー代が月5万円以下。これがSSRだったら、月20万円以上かかってた。

3. SEO に最強

Googleのクローラーがアクセスしたとき、すでに完全なHTMLが返される。JavaScriptの実行を待つ必要がない。だからSEOに超有利。

実際、私が制作したブログサイトは、公開後3ヶ月で検索1ページ目に表示された。SSGの恩恵が大きい。

4. セキュリティが高い

サーバーサイドの処理がないから、攻撃される箇所が少ない。データベースに直接アクセスすることもない。

5. 開発コストが低い

VercelやNetlifyにデプロイするだけ。サーバーの設定、負荷分散、キャッシュ戦略…全部考えなくていい。

SSG のデメリット

メリットばかりじゃない。デメリットもちゃんと理解しておく必要がある。

1. データの更新が即座に反映されない

これが最大のデメリット。記事を更新しても、再ビルドするまでサイトに反映されない。

私の失敗談がまさにこれ。クライアントは「記事を書いたらすぐ公開したい」って思ってる。でもSSGだと、再ビルド→デプロイの時間が必要。

2. ページ数が多いとビルドに時間がかかる

1万ページあるサイトをSSGで実装すると、ビルドに30分以上かかることもある。記事を1つ追加するだけで、全ページ再ビルド。非効率。

実際に担当した不動産サイトは、物件が5000件。ビルドに15分かかった。これは後でISRに切り替えた。

3. 動的なコンテンツには不向き

ユーザーごとに表示内容が変わるページ（ダッシュボード、マイページ）はSSGに向いてない。ビルド時にユーザー情報がわからないから。

コワーキングスペースで、クライアントとオンラインミーティングをしながら画面共有をする30代男性の線画イラスト

SSG が適してるケース

実案件の経験から、SSGが適してるケースをまとめる。

完璧にマッチするケース：

コーポレートサイト（会社情報、サービス紹介）
ブログ・メディアサイト（記事更新が1日数回程度）
ランディングページ
ドキュメントサイト（技術文書、マニュアル）
ポートフォリオサイト

条件付きでOK：

ECサイト（商品ページはSSG、カートはCSR）
ニュースサイト（ISRと組み合わせる）

向いてないケース：

SNS（投稿がリアルタイムで変わる）
ダッシュボード（ユーザーごとに表示が違う）
チャットアプリ
リアルタイム性が重要なサイト

私は案件の打ち合わせで、「更新頻度は？」「ページ数は？」って必ず聞く。この2つでSSGが使えるか判断できる。

SSR（サーバーサイドレンダリング）を深く理解する

SSRは、Next.jsの初期から存在するレンダリング手法。動的なサイトを作るときに欠かせない。

SSR の仕組みを図で理解

リクエストのたびに何が起きてるか、順を追って説明する。

ユーザーがページにアクセス

ブラウザからサーバーにリクエスト

サーバーがgetServerSidePropsを実行

データベースからデータ取得
外部APIを呼び出し
ユーザー情報を元に処理

取得したデータを使ってHTMLを生成

サーバー上でReactコンポーネントを実行
完全なHTMLを構築

生成されたHTMLをユーザーに返す

ブラウザに表示される
その後、JavaScriptが読み込まれてインタラクティブになる

SSRの特徴は、ユーザーごと、リクエストごとに異なるHTMLを返せること。これがSSGとの決定的な違い。

実際に私が担当した会員制サイトでは、ログインしたユーザーごとに異なるダッシュボードを表示する必要があった。これはSSRじゃないと実現できない。

SSR のメリット

SSRを使う理由は、SSGではできないことができるから。

1. 常に最新のデータを表示

リクエストのたびにデータを取得するから、常に最新。記事を更新したら即座にサイトに反映される。

私が担当したニュースサイトは、速報性が命。SSRで実装したおかげで、記事公開から数秒で全ユーザーに表示された。

2. ユーザーごとに異なる内容を表示

ログインユーザーのIDを使って、専用のコンテンツを表示できる。ダッシュボード、マイページ、注文履歴…全部SSRの領域。

3. SEOに強い

SSGほどじゃないけど、完全なHTMLを返すからSEOに有利。クローラーがJavaScriptを実行する必要がない。

4. ページ数が多くても問題ない

ビルド時に全ページ生成する必要がないから、100万ページあっても大丈夫。リクエストされたページだけ生成すればいい。

SSR のデメリット

もちろんデメリットもある。実案件で痛感したこと。

1. 表示速度が遅い

リクエストのたびにサーバーで処理するから、SSGより遅い。データベースへのクエリ、外部APIの呼び出し…時間がかかる。

私が最初の案件でSSRに切り替えたとき、ページ表示が0.5秒から2秒に遅延した。ユーザー体験が明らかに悪化した。

2. サーバー負荷が高い

アクセスが増えると、サーバーの処理が追いつかなくなる。スケーリングが必要。コストも上がる。

実際、月間100万PVのサイトをSSRで運用したら、サーバー代が月20万円を超えた。SSGなら5万円以下だったのに。

3. サーバーダウンのリスク

アクセスが集中すると、サーバーがダウンする可能性がある。対策としてロードバランサーやオートスケーリングが必要。複雑になる。

4. キャッシュ戦略が複雑

SSGと違って、キャッシュをどうするか考える必要がある。CDNのキャッシュ、サーバーサイドキャッシュ、データベースキャッシュ…設計が難しい。

自宅の書斎で、複数のモニターを使ってコードを書く40代女性エンジニアの線画イラスト

SSR が適してるケース

実案件の経験から、SSRが適してるケースをまとめる。

完璧にマッチするケース：

ダッシュボード（ユーザーごとのデータ表示）
管理画面
会員制サイト（マイページ）
SNS（タイムライン、通知）
リアルタイム性が重要なサイト

条件付きでOK：

ニュースサイト（速報記事のみSSR、過去記事はSSG）
ECサイト（在庫状況が頻繁に変わる商品ページ）
検索結果ページ

向いてないケース：

コーポレートサイト（更新頻度が低い）
ドキュメントサイト
静的なランディングページ

私は案件で「リアルタイム性が必要か？」「ユーザーごとに表示が変わるか？」って聞く。YESならSSR、NOならSSG。

Next.js での SSG と SSR の実装方法

実際にコードを書いてみる。Pages Router を使った実装例。

SSG の実装（getStaticProps）

// pages/blog/[slug].js

// ページコンポーネント
export default function BlogPost({ post }) {
  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

// SSGでデータを取得（ビルド時に実行される）
export async function getStaticProps({ params }) {
  // 外部APIからデータ取得
  const res = await fetch(`https://api.example.com/posts/${params.slug}`);
  const post = await res.json();

  return {
    props: {
      post, // ページコンポーネントにpropsとして渡される
    },
  };
}

// 動的ルーティングの場合、生成するパスを指定
export async function getStaticPaths() {
  // すべての記事のスラッグを取得
  const res = await fetch('https://api.example.com/posts');
  const posts = await res.json();

  // パスの配列を生成
  const paths = posts.map((post) => ({
    params: { slug: post.slug },
  }));

  return {
    paths, // ビルド時にこれらのパスを生成
    fallback: false, // 指定外のパスは404
  };
}

このコードのポイント：

getStaticProps でデータ取得（ビルド時に1回だけ実行）
getStaticPaths で生成するページを指定
ビルド後はHTMLが固定される

SSR の実装（getServerSideProps）

// pages/dashboard/index.js

// ページコンポーネント
export default function Dashboard({ user, posts }) {
  return (
    <div>
      <h1>{user.name}さんのダッシュボード</h1>
      <ul>
        {posts.map((post) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </div>
  );
}

// SSRでデータを取得（リクエスト時に毎回実行される）
export async function getServerSideProps(context) {
  // クッキーからユーザーIDを取得
  const userId = context.req.cookies.userId;

  // ユーザー情報を取得
  const userRes = await fetch(`https://api.example.com/users/${userId}`);
  const user = await userRes.json();

  // ユーザーの投稿を取得
  const postsRes = await fetch(`https://api.example.com/posts?userId=${userId}`);
  const posts = await postsRes.json();

  return {
    props: {
      user,
      posts, // リクエストのたびに最新データが渡される
    },
  };
}

このコードのポイント：

getServerSideProps でデータ取得（リクエストのたびに実行）
context からリクエスト情報（クッキー、クエリパラメータなど）を取得可能
ユーザーごとに異なるデータを返せる

App Router での実装（Next.js 13以降）

最新のNext.jsではApp Routerが推奨されてる。実装方法が少し変わる。

SSGの実装：

// app/blog/[slug]/page.js

// デフォルトでSSG
async function getBlogPost(slug) {
  const res = await fetch(`https://api.example.com/posts/${slug}`, {
    cache: 'force-cache' // SSGを明示（デフォルトなので省略可）
  });
  return res.json();
}

export default async function BlogPost({ params }) {
  const post = await getBlogPost(params.slug);

  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

SSRの実装：

// app/dashboard/page.js

// SSRを指定
async function getUserData(userId) {
  const res = await fetch(`https://api.example.com/users/${userId}`, {
    cache: 'no-store' // SSRを明示
  });
  return res.json();
}

export default async function Dashboard() {
  const user = await getUserData('123');

  return (
    <div>
      <h1>{user.name}さんのダッシュボード</h1>
    </div>
  );
}

App Routerの特徴：

fetch の cache オプションで制御
force-cache がSSG、no-store がSSR
シンプルで直感的

私は新規案件では基本的にApp Routerを使ってる。コードがシンプルで、クライアントにも説明しやすい。

実案件での SSG と SSR の使い分け方

理論はわかった。でも実際の案件で、どう判断すればいいのか？私が使ってる判断基準を公開する。

判断フローチャート

案件の打ち合わせで、この順番で質問する：

質問1：データの更新頻度は？

週1回以下 → SSG確定
1日数回 → SSGまたはISR
1日数十回以上 → SSRまたはISR
リアルタイム → SSR確定

質問2：ユーザーごとに表示が変わる？

YES → SSR確定
NO → 次の質問へ

質問3：ページ数は？

100ページ以下 → SSG可能
1000ページ以下 → SSGまたはISR
1000ページ以上 → ISRまたはSSR

質問4：SEOは重要？

超重要 → SSG優先
重要 → SSGまたはSSR
不要 → CSRも選択肢

この質問で、ほぼ100%正しい判断ができる。

夜のオフィスで、ホワイトボードにシステム構成図を描きながら考える30代男性エンジニアの線画イラスト

実際の案件例とその判断

私が担当した案件と、なぜその選択をしたか説明する。

案件1：企業のコーポレートサイト

更新頻度：月1回程度
ページ数：20ページ
ユーザー固有の表示：なし
選択：SSG
理由：更新が少なく、全ページ事前生成可能。表示速度を最優先。

案件2：ニュースメディアサイト

更新頻度：1日10～20記事
ページ数：5000記事
ユーザー固有の表示：なし
選択：ISR（SSGとSSRのハイブリッド）
理由：記事が多すぎてビルドに時間がかかる。でも速度も重視。ISRで10分ごとに再生成。

案件3：会員制ダッシュボード

更新頻度：リアルタイム
ページ数：ユーザー数による（数千人）
ユーザー固有の表示：あり（ユーザーごとに違う）
選択：SSR
理由：ユーザーごとに表示が変わるのでSSG不可。リアルタイム性が重要。

案件4：ECサイト

商品ページ：SSG（在庫変動が少ない商品）
商品ページ：SSR（人気商品、在庫が頻繁に変わる）
カート：CSR（クライアントサイドのみ）
マイページ：SSR
選択：ハイブリッド
理由：ページの特性に応じて使い分け。

私の経験則：

コーポレートサイト → SSG
ブログ・メディア → SSGまたはISR
SNS・ダッシュボード → SSR
EC → ハイブリッド

ハイブリッド構成のすすめ

Next.jsの最大の強みは、1つのプロジェクト内でSSGとSSRを混在できること。ページごとに最適な手法を選べる。

実際、私が担当する案件の9割はハイブリッド構成。

例：採用サイト

トップページ：SSG（更新少ない）
会社情報：SSG
採用情報：ISR（週1更新）
応募フォーム：CSR
管理画面：SSR

こうすることで、パフォーマンスとメンテナンス性を両立できる。

よくある失敗とその回避方法

実案件で私が踏んだ地雷と、後輩エンジニアからよく聞く失敗をまとめる。

失敗1：SSG で動的データを扱おうとする

症状：
「getStaticPropsでAPIを呼んでるのに、データが更新されない！」

原因：
SSGはビルド時にデータ取得。その後の更新は反映されない。

解決策：

データが頻繁に変わるなら、SSRかISRに切り替え
ISRの revalidate オプションで定期的に再生成

export async function getStaticProps() {
  const res = await fetch('https://api.example.com/posts');
  const posts = await res.json();

  return {
    props: { posts },
    revalidate: 60, // 60秒ごとに再生成（ISR）
  };
}

失敗2：SSR で重い処理をする

症状：
「ページの表示が遅すぎる！3秒以上かかる」

原因：
getServerSidePropsで複数のAPIを呼んだり、複雑な計算をしてる。

解決策：

必要最小限のデータだけ取得
並列処理を使う（Promise.all）
キャッシュを活用

export async function getServerSideProps() {
  // 悪い例：直列処理（遅い）
  // const user = await fetchUser();
  // const posts = await fetchPosts();
  // const comments = await fetchComments();

  // 良い例：並列処理（速い）
  const [user, posts, comments] = await Promise.all([
    fetchUser(),
    fetchPosts(),
    fetchComments(),
  ]);

  return {
    props: { user, posts, comments },
  };
}

失敗3：getStaticPaths で fallback の設定を間違える

症状：
「404エラーが出る」または「ビルドが終わらない」

原因：
fallback の設定が適切じゃない。

解決策：

fallback: false → 指定したパスのみ生成。それ以外は404
fallback: true → 指定外のパスもオンデマンドで生成
fallback: 'blocking' → 初回アクセス時にSSRで生成、以降はキャッシュ

export async function getStaticPaths() {
  // 人気記事だけビルド時に生成
  const popularPosts = await fetchPopularPosts();

  const paths = popularPosts.map((post) => ({
    params: { slug: post.slug },
  }));

  return {
    paths,
    fallback: 'blocking', // その他の記事は初回アクセス時に生成
  };
}

失敗4：開発環境と本番環境の違いを理解してない

症状：
「開発環境では動くのに、本番で動かない！」

原因：
開発環境（npm run dev）では、SSGでも毎回サーバー処理される。本番環境とは挙動が違う。

解決策：

本番環境の確認は必ず npm run build → npm run start で行う
Vercelにデプロイして確認

これ、私も最初の案件で引っかかった。開発環境で「完璧！」って思ってデプロイしたら、全然動かなかった。

早朝の自宅で、コーヒーを飲みながらノートパソコンで修正したコードを確認する20代男性エンジニアの線画イラスト

よくある質問（FAQ）

実案件やメンターでよく聞かれる質問に答える。

Q1: SSG と SSR、どっちを選べばいいかわからない

まずは「データの更新頻度」と「ユーザー固有の表示があるか」で判断。迷ったら、SSGから始めるのがおすすめ。後からSSRに変更するのは簡単。

私の経験則：

更新が週1回以下 → SSG
ユーザーごとに表示が変わる → SSR
それ以外 → ISR

Q2: ISR って何？SSG と SSR の中間？

その通り。ISRは「Incremental Static Regeneration」の略。SSGのように事前生成しつつ、定期的に再生成する。

設定は簡単：

export async function getStaticProps() {
  return {
    props: { data },
    revalidate: 60, // 60秒ごとに再生成
  };
}

ブログやニュースサイトに最適。私の案件の半分はISRを使ってる。

Q3: SSG と SSR を混在させられる？

できる！これが Next.js の最大の強み。ページごとに使い分け可能。

例：

/ → SSG（トップページ）
/blog/[slug] → SSG（記事ページ）
/dashboard → SSR（ダッシュボード）

実際、私が担当する案件の9割は混在構成。

Q4: WordPress から Next.js に移行したい。どうすれば？

WordPressをヘッドレスCMSとして使うのがおすすめ。

流れ：

WordPress REST APIを有効化
Next.jsでフロントエンド構築
getStaticPropsでWordPress APIからデータ取得
SSGで記事ページ生成

実際、私の案件でも「WordPress → Next.js」の移行は3件やった。表示速度が劇的に改善する。

Q5: SSR だとサーバー代が高くなる？

なる。SSGと比べて3～5倍は覚悟が必要。

目安：

月間10万PV → サーバー代3万円程度（SSR）
月間10万PV → サーバー代5000円程度（SSG）

でも、Vercelの無料枠でも結構いける。月間10万PVくらいまでは無料で運用できる。

Q6: Next.js の学習、どこから始めればいい？

順番：

Reactの基礎（JSX、コンポーネント、hooks）
Next.jsの公式チュートリアル
SSGで簡単なブログ作成
SSRでダッシュボード作成

私がメンターしてる受講生は、この順番で学んで3ヶ月で案件取れるようになった。

Q7: 副業で Next.js 案件、取れる？

取れる。しかも単価が高い。

私の実績：

初案件：80万円（2ヶ月）
平均単価：50万円/月

Next.jsの需要は年々増えてる。WordPressからの移行案件も多い。営業方法さえ間違えなければ、月20～30万円は余裕で稼げる。

Q8: getStaticProps と getServerSideProps、両方使える？

同じページでは使えない。どっちか一方。

でも、プロジェクト内で混在はできる。ページごとに使い分け。

まとめ：Next.js の SSG と SSR を使いこなそう

ここまで読んでくれてありがとう。長かったけど、SSGとSSRの違いと使い分け方、理解できたと思う。

最後にもう一度、重要なポイントをまとめる。

SSG（静的生成）の特徴：

ビルド時にHTMLを生成
表示速度が最速
サーバー負荷が低い
SEOに最強
データ更新は再ビルドが必要

適してるケース：

コーポレートサイト
ブログ・ドキュメント
ランディングページ
更新頻度が低いサイト

SSR（サーバーサイドレンダリング）の特徴：

リクエスト時にHTMLを生成
常に最新データを表示
ユーザーごとに異なる内容を表示可能
表示速度はSSGより遅い
サーバー負荷が高い

適してるケース：

ダッシュボード
管理画面
SNS
リアルタイム性が重要なサイト

判断基準：

データ更新頻度が低い → SSG
ユーザーごとに表示が変わる → SSR
迷ったら → ISR

実装のポイント：

ページごとにSSGとSSRを使い分けられる
App Router では fetch の cache オプションで制御
開発環境と本番環境の挙動が違うので注意

私が最初の案件で失敗したのは、この違いを理解してなかったから。でも失敗から学んで、今では自信を持ってクライアントに提案できる。

Next.jsを学んでる人、これから案件を受けようとしてる人。SSGとSSRの違いをしっかり理解すれば、適切な設計ができる。クライアントから信頼される。単価も上がる。

まずは小さいプロジェクトで試してみてほしい。自分のブログをSSGで作る、簡単なダッシュボードをSSRで作る。実際に手を動かすのが一番の学習。

わからないことがあったら、公式ドキュメントを読む。コミュニティで質問する。一人で抱え込まない。

Next.jsは本当に素晴らしいフレームワーク。SSGとSSRを使いこなせれば、高速で、SEOに強く、ユーザー体験の良いサイトが作れる。

それじゃ、頑張って！

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いたエンジニア

林萌 Webフロントエンドエンジニア

Webフロントエンドのスペシャリストで、UI改善やパフォーマンス向上に強い関心を持つ。軽やかで柔らかい雰囲気の持ち主で、チームに安心感を与える。雑誌やSNSで最新デザインを研究するのが日課。猫好きで、家では2匹飼っている。

この著者の記事一覧へ

Next.jsの静的生成(SSG)とSSRの違い、案件での使い分け方を解説

初めての Next.js 案件で失敗した話

Next.js の SSG と SSR、何が違うのか

SSG（Static Site Generation / 静的サイト生成）とは

SSR（Server-Side Rendering / サーバーサイドレンダリング）とは

SSG と SSR の決定的な違い

SSG（静的生成）を深く理解する

SSG の仕組みを図で理解

SSG のメリット

SSG のデメリット

SSG が適してるケース

SSR（サーバーサイドレンダリング）を深く理解する

SSR の仕組みを図で理解

SSR のメリット

SSR のデメリット

SSR が適してるケース

Next.js での SSG と SSR の実装方法

SSG の実装（getStaticProps）

SSR の実装（getServerSideProps）

App Router での実装（Next.js 13以降）

実案件での SSG と SSR の使い分け方

判断フローチャート

実際の案件例とその判断

ハイブリッド構成のすすめ

よくある失敗とその回避方法

失敗1：SSG で動的データを扱おうとする

失敗2：SSR で重い処理をする

失敗3：getStaticPaths で fallback の設定を間違える

失敗4：開発環境と本番環境の違いを理解してない

よくある質問（FAQ）

まとめ：Next.js の SSG と SSR を使いこなそう

この記事を書いたエンジニア

関連記事

副業プログラミングのライター紹介