<h2 id="he89b711621">🔁 状況整理（/blogs 一覧ページ）</h2>Next.js×microCMSでブログ一覧ページを作成中。 アクセス時はSSGで、スクロールでデータを取得する時はCSRと分けている。<h3 id="hffddeb7e52"> 1. /blogs にアクセス</h3>ブログページにアクセスしたら、最初に表示される記事10件はSSG化されており、静的HTMLが返ってくる。<ul><li><code>getStaticProps</code> が実行され、リミット指定をした10件分のブログ記事が事前にビルドされる。（SSG）</li><li><code>revalidate: 30</code> により、30秒経過すると次のアクセス時にバックグラウンドで最新化される。（ISR）</li></ul><h3 id="h90c5266d30"> 2. スクロールで記事の追加読み込み(無限スクロール)</h3>初期記事10件以降の記事は、ユーザーのスクロールで新たに取得する。<ul><li><code>useEffect</code> や <code>IntersectionObserver</code> により、ユーザーのスクロールアクションで <code>/api/blogs?offset=10</code> にリクエストが飛ぶ。</li></ul><h2 id="h926d7ce789">⚡️疑問に思ったこと</h2>❓疑問１｜/blogsページはSSG化されているのになぜユーザーアクションで表示できる？ ユーザーアクションのスクロールでさらに10記事取得してるけれど、/blogsページはSSG化されているので、30秒経過しないと一覧は更新されないのでは？💡無限スクロールでの追加取得はクライアントで描画されているので表示できる 無限スクロールで追加取得は、クライアント側でAPIを経由してリアルタイムに取得している（CSR）。そのため、ページのSSG化関係なく記事は取得され、表示される。<hr>❓疑問２｜ユーザー側でデータ取得（一覧更新）ができるならISRは必要ないのでは？ ユーザー側でAPI経由で記事一覧を更新できるなら、SSG化した/blogsページを<code>revalidate</code>で30秒ごとに最新化（ISR）は必要ないのではないだろうか。二重で更新しているように感じる。💡ISRは/blogsページ初回表示の鮮度を保つために必要！ <code>revalidate</code> は /blogsページ初回表示のために必要。 無限スクロールで2ページ目以降の記事を取得しても、初回の10件はSSG化された静的HTMLなので、次にアクセスしてもキャッシュからページを返す。記事が増えたとしても/blogsのアクセス時のページは古いまま。<code>revalidate</code> をつけておけば、静的にビルドされた初期データも定期的に更新される。 補足：ISRの更新タイミング ISR は次のアクセス時にバックグラウンドで再生成される。指定秒経ったら即座に新しくされるわけではない。<ul><li>アクセスがない場合は再生成されない。</li><li>指定秒経過後の最初のアクセス時：再生成が始まる（古いまま表示される可能性あり）</li><li>次のアクセス時：再生成されたページが表示される</li></ul><hr>❓疑問３｜<code>revalidate</code>をつけていても、revalidate設定時間より短い間に、1回目アクセスと2回目アクセスの間に記事が増えたら？💡APIの結果の整合性（順番ズレ問題）は更新頻度次第【ブログ更新頻度：低〜中（月数回〜週数回）】 通常ユーザーは一覧ページを見たら、他の記事に飛んで、読んだ後に戻ってきたりする。その間にタイミングよく新記事が投稿されて、「初期で取得した10件の記事」と「スクロールで取得した記事」との間で日付のずれが生じて困るといったことはあまり起こることではない。 revalidate: 30 ~ 300秒でも設定可。【 ブログ更新頻度：高い（1日複数回、あるいは自動投稿等）】 新着記事が頻繁に追加されるようなサイトでは、初期表示の10件（SSG）とその後にCSRで取得するデータの順序がずれてしまい、ユーザーに違和感を与える可能性がある。📝このようなケースでは、次のような対策が有効：- 初期10件もCSRで取得し、常に最新に保つ - <code>revalidate</code> の時間を短くして、できるだけ新鮮な静的ページにする - サーバーサイドで順番を制御した中間APIなどを用意する（上級者向け）最適な設計は、「更新頻度」「インフラコスト」「ユーザー体験」のバランスによって決めるのがベスト。<h2 id="ha214098e44">まとめ</h2>SSGは初回アクセスの高速化、CSRは実際の使い心地と分けて考えるSSGは初回アクセスの高速化をしてパフォーマンスを上げてくれる。 そしてCSRは、実装したかった「無限スクロール」というユーザー（私）の使い心地を良くしてくれる。<table><tbody><tr><th colspan="1" rowspan="1">処理</th><th colspan="1" rowspan="1">手段</th><th colspan="1" rowspan="1">データの鮮度</th></tr><tr><td colspan="1" rowspan="1">初回10件表示</td><td colspan="1" rowspan="1"><code>getStaticProps</code> + <code>revalidate</code></td><td colspan="1" rowspan="1">指定秒ごとにバックグラウンドで最新化（ISR）</td></tr><tr><td colspan="1" rowspan="1">追加読み込み</td><td colspan="1" rowspan="1">API + CSR<code>useEffect</code></td><td colspan="1" rowspan="1">毎回リアルタイム取得</td></tr></tbody></table>しかし、SSGは初回表示を高速化をするために静的HTMLを返す。ビルド後にデータ更新されてもデータは古いままキャッシュから返される。 それを改善してくれるのがISRの設定。そしてCSRは私たちの好みの使い方やデータ取得のタイミングを選べるけれど、API取得にはタイムラグが生じるときがある。上記二つのメリット/デメリットを、ページの目的によって使い分けていく必要がある。【 実際の使い方の例 】🚀 getStaticProps は「とりあえず表示を爆速にしたい」 → Topページ、記事一覧の最初の10件などに最適🌀 CSR（useEffect や fetch） は「ユーザー操作に合わせて変化したい」 → 無限スクロール、検索、絞り込み、ボタンクリックでの表示切替などに◎<table><tbody><tr><th colspan="1" rowspan="1">項目</th><th colspan="1" rowspan="1">getStaticProps（SSG/ISR）</th><th colspan="1" rowspan="1">CSR（クライアントサイドレンダリング）</th></tr><tr><td colspan="1" rowspan="1">目的</td><td colspan="1" rowspan="1">ページの事前生成で高速表示</td><td colspan="1" rowspan="1">ユーザー操作に応じた動的な処理・描画</td></tr><tr><td colspan="1" rowspan="1">主な役割</td><td colspan="1" rowspan="1">初回のHTMLを生成（SEO・速度◎）</td><td colspan="1" rowspan="1">無限スクロール・動的フィルター・検索など</td></tr><tr><td colspan="1" rowspan="1">タイミング</td><td colspan="1" rowspan="1">ビルド時 or <code>revalidate</code>で再生成</td><td colspan="1" rowspan="1">ページ表示後のブラウザ内で実行</td></tr><tr><td colspan="1" rowspan="1">データの鮮度</td><td colspan="1" rowspan="1">再生成タイミング次第</td><td colspan="1" rowspan="1">基本リアルタイム（API呼び出し時）</td></tr></tbody></table>その他Next.jsのレンダリング方法は下記記事を参照。<a href="/blogs/nextjs-rendering" target="_blank" rel="noopener noreferrer nofollow">Next.js のレンダリング方式まとめ｜SSG・ISR・SSR・CSR の違いと使い分け</a>

一覧ページをSSG化後、ISR化やCSRでのデータ取得のメリット/デメリットがよく分からなくなったので、疑問に感じたことと併せてまとめてみた。

Next.js×microCMS｜ブログ記事一覧ページをSSG＋CSR(ユーザーアクション)の時のページ生成のまとめ

<h2 id="h7ef41f099b">📝Next.jsのレンダリング（生成）パターン</h2>Next.jsの記事生成のパターンをまとめ。<table><tbody><tr><th colspan="1" rowspan="1">パターン</th><th colspan="1" rowspan="1">説明</th></tr><tr><td colspan="1" rowspan="1">SSG（Static Site Generation）</td><td colspan="1" rowspan="1">完全な静的生成。HTMLは一度だけビルド時に生成。変更は再ビルドで反映。</td></tr><tr><td colspan="1" rowspan="1">SSR（Server Side Rendering）</td><td colspan="1" rowspan="1">毎回リクエスト時にHTMLを生成。getServerSideProps を使用。</td></tr><tr><td colspan="1" rowspan="1">ISR（Incremental Static Regeneration）</td><td colspan="1" rowspan="1">revalidate オプションを使うことで、一定時間ごとに静的HTMLを再生成可能。</td></tr><tr><td colspan="1" rowspan="1">CSR（Client Side Rendering）</td><td colspan="1" rowspan="1">ページはJSでクライアント側で描画され、HTMLは最小限。</td></tr></tbody></table><h2 id="he7dc9e6ba2">レンダリング方式（SSG、SSR、ISR、CSR）のメリット・デメリット</h2>Next.jsのレンダリング方式にはそれぞれメリットデメリットがある。<table><tbody><tr><th colspan="1" rowspan="1">パターン</th><th colspan="1" rowspan="1">メリット</th><th colspan="1" rowspan="1">デメリット</th></tr><tr><td colspan="1" rowspan="1">SSG（Static Site Generation）</td><td colspan="1" rowspan="1">・高速：ビルド時に生成されたHTMLをそのまま返すので表示が速い ・SEOに強い（完全なHTML） ・CDNキャッシュが効きやすい</td><td colspan="1" rowspan="1">・頻繁に更新されるページには不向き ・データが古くなりやすい（再ビルドが必要） ・ページ数が多いとビルド時間が長くなる</td></tr><tr><td colspan="1" rowspan="1">SSR（Server Side Rendering）</td><td colspan="1" rowspan="1">・毎回最新のデータでレンダリング可能 ・SEOにも強い（HTMLを返す） ・ユーザーごとの内容に対応しやすい（認証など）</td><td colspan="1" rowspan="1">・表示速度が遅くなることがある（サーバー負荷） ・キャッシュが効きにくい ・サーバーコスト・インフラ管理が増える</td></tr><tr><td colspan="1" rowspan="1">ISR（Incremental Static Regeneration）</td><td colspan="1" rowspan="1">・SSGの速度＋データの自動更新が可能 ・表示速度と鮮度のバランスが良い ・CDN対応も可能でスケーラブル</td><td colspan="1" rowspan="1">・バグったときに「古いページがキャッシュされたまま」になるリスク ・ユーザーによっては古い内容を一時的に見る可能性がある</td></tr><tr><td colspan="1" rowspan="1">CSR（Client Side Rendering）</td><td colspan="1" rowspan="1">・動的コンテンツに強い（SPAに向いている） ・APIベースで柔軟に構成可能 ・ページ間の遷移が速くなる</td><td colspan="1" rowspan="1">・初回表示が遅い（JSが読み込まれるまで表示されない） ・SEOが弱くなる（クローラーはJSを完全に理解できない場合がある） ・JSエラーで真っ白になるリスク</td></tr></tbody></table><h2 id="h2538350eef">SSG、SSR、ISR、CSRそれぞれの基本挙動</h2><h3 id="ha93f6e9eb4">📝 SSG（Static Site Generation）の基本挙動</h3>SSG化すると、ページのビルド時にサーバーサイドで静的HTMLが生成される。 リロード時も、CDNなどを介して生成済みのHTMLがそのまま返ってくる。<table><tbody><tr><th colspan="1" rowspan="1">タイミング</th><th colspan="1" rowspan="1">起こること</th></tr><tr><td colspan="1" rowspan="1">ビルド時</td><td colspan="1" rowspan="1">getStaticProps＋(getStaticPaths)が実行され、静的HTMLが生成</td></tr><tr><td colspan="1" rowspan="1">アクセス時</td><td colspan="1" rowspan="1">事前に生成済されたHTMLが即座に返される（CDNキャッシュ経由） or 条件により再生成</td></tr><tr><td colspan="1" rowspan="1">更新時</td><td colspan="1" rowspan="1">コードやデータを変更 → 再ビルドが必要（再デプロイ）</td></tr></tbody></table><pre><code class="language-javascript">export const getStaticProps = async () =&gt; {
 const data = await fetchData();// 別コンポーネントでデータを取得
 return {
 props: { data }, // ページコンポーネントに渡すprops
 };
};</code></pre><h3 id="h93c3741095">📝ISR（Incremental Static Regeneration）基本挙動</h3>SSGの派生。 Next.jsが提供する「静的生成（SSG）＋ 動的な再生成」を組み合わせた仕組み。ページを事前にビルドしておくけど、必要に応じてあとから自動で再生成できる → <code>getStaticProps</code> に <code>revalidate</code> をつけることで実現。<code>revalidate</code>時間を設定することで、アクセス時にバックグラウンドで静的HTMLを自動再生成できる。<table><tbody><tr><th colspan="1" rowspan="1">タイミング</th><th colspan="1" rowspan="1">起こること</th></tr><tr><td colspan="1" rowspan="1">ビルド時</td><td colspan="1" rowspan="1"><code>getStaticProps</code> が実行され、初回の静的HTMLを生成</td></tr><tr><td colspan="1" rowspan="1">アクセス時</td><td colspan="1" rowspan="1">生成済みHTMLが返る（再生成されていない場合）</td></tr><tr><td colspan="1" rowspan="1">revalidate経過後のアクセス</td><td colspan="1" rowspan="1">表示はキャッシュ → 裏で<code>getStaticProps</code>が実行され、次回アクセスで新HTMLが配信される</td></tr></tbody></table><pre><code class="language-javascript">export const getStaticProps = async () =&gt; {
 const data = await fetchData();
 return {
 props: { data },
 revalidate: 60, // 60秒ごとに再生成（次のアクセス時に）
 };
};</code></pre><h3 id="hd294c8934e">📝SSR（Server-side Rendering）の基本挙動</h3>毎回リクエストがあるたびに、サーバー側でHTMLを生成して返す。getServerSideProps を使用。 リアルタイム性が必要なページに適している。<table><tbody><tr><th colspan="1" rowspan="1">タイミング</th><th colspan="1" rowspan="1">起こること</th></tr><tr><td colspan="1" rowspan="1">アクセス時（毎回）</td><td colspan="1" rowspan="1"><code>getServerSideProps</code> が実行され、サーバーでHTMLを生成して返す</td></tr><tr><td colspan="1" rowspan="1">キャッシュ</td><td colspan="1" rowspan="1">基本なし（毎回サーバーに負荷）</td></tr><tr><td colspan="1" rowspan="1">ユーザー別データ</td><td colspan="1" rowspan="1">表示内容をユーザーごとに出し分け可能（ログインなど）</td></tr></tbody></table><pre><code class="language-javascript">export const getServerSideProps = async () =&gt; {
 const res = await fetch(&quot;https://api.example.com/blogs&quot;);
 const data = await res.json();

 return {
 props: { data },
 };
};

export default function Blog({ data }) {
 return &lt;div&gt;{data.title}&lt;/div&gt;;
}</code></pre><h3 id="h85f8b93b44">📝CSR（Client-side Rendering）の基本挙動</h3>クライアントサイド（ブラウザ）でJavaScriptがデータを取得して、DOMを描画する方式。 Next.js では useEffect でAPIから取得するなど。<table><tbody><tr><th colspan="1" rowspan="1">タイミング</th><th colspan="1" rowspan="1">起こること</th></tr><tr><td colspan="1" rowspan="1">初回アクセス時</td><td colspan="1" rowspan="1">HTMLはほぼ空（Loading状態）、JSが読み込まれた後に表示</td></tr><tr><td colspan="1" rowspan="1">データ取得</td><td colspan="1" rowspan="1">ブラウザ側でAPIなどからフェッチして描画</td></tr><tr><td colspan="1" rowspan="1">SEO</td><td colspan="1" rowspan="1">JS実行前は中身がないため、SEOにやや弱い（工夫が必要）</td></tr></tbody></table><pre><code class="language-javascript">import { useEffect, useState } from &quot;react&quot;;

export default function Blog() {
 const [data, setData] = useState(null);

 useEffect(() =&gt; {
 fetch(&quot;https://api.example.com/blogs&quot;)
 .then((res) =&gt; res.json())
 .then((json) =&gt; setData(json));
 }, []);

 if (!data) return &lt;div&gt;Loading...&lt;/div&gt;;

 return &lt;div&gt;{data.title}&lt;/div&gt;;
}</code></pre><h2 id="h6356bbf039">⭐️まとめ</h2>それぞれのレンダリング方法に、カスタマイズの柔軟さやメリットデメリットがある。 そのページの目的に合わせたレンダリング方法を選ぶと良い。

SSG / ISR / SSR の違いとは？どんな時に使うの？

Next.js のレンダリング方式まとめ｜SSG・ISR・SSR・CSR の違いと使い分け

<h2 id="h5ab13b7315">⚡️新しく取得した記事にアクセスしたら404エラーに</h2>ブログ記事一覧ページに無限スクロールを設置。最初のアクセス時、10件分はSSGで静的HTMLを生成して表示して、11件目以降はユーザーのスクロールで取得する機能を実装。しかし、11件目以降の記事にアクセスすると404が表示された。<h2 id="hdf9bc7d661">✅原因はfallbackの設定</h2>getStaticPathsの設定で<code>fallback: false</code>にしていたことが原因。 ビルド時getStaticPathsで取得したデータに存在しなかったページは作られず、アクセスしても404になるとのこと。<pre><code class="language-javascript">export const getStaticPaths = async () =&gt; {
 const data = await getBlogDetail();

 const paths = data.contents.map((content) =&gt; `/blogs/${content.id}`);

 return { paths, fallback: false};
};</code></pre>ビルド後に動的ページにアクセスしたいならfallbackの設定が重要。fallbackは、まだ生成されていないページにアクセスされたときの挙動を決めるオプション。<h2 id="hede87d6ba4">fallbackの設定を変えて解決🎉</h2><code>fallback: false</code>→<code>fallback: &quot;blocking&quot;</code>に変更すると初回アクセスでも表示された。🔵blockingの挙動 ユーザーがアクセスするとサーバーがアクセスしたページをSSG化してくれる。 SSG化している間画面には何も表示されず、完了しだい該当ページが表示される。<pre><code class="language-javascript">export const getStaticPaths = async () =&gt; {
 const data = await getBlogDetail();

 const paths = data.contents.map((content) =&gt; `/blogs/${content.id}`);

 return { paths, fallback: &quot;blocking&quot; };
};</code></pre><h2 id="h4d13ded214">🔁fallback の3つの設定</h2>fallbackには下記3つの設定があり、それぞれの挙動が異なる。<table><tbody><tr><th colspan="1" rowspan="1">設定</th><th colspan="1" rowspan="1">挙動</th><th colspan="1" rowspan="1">特徴</th><th colspan="1" rowspan="1">注意点</th></tr><tr><td colspan="1" rowspan="1">false</td><td colspan="1" rowspan="1">ビルド時に定義されたパスのみSSG化。存在しないページは404</td><td colspan="1" rowspan="1">最もシンプル</td><td colspan="1" rowspan="1">ページ追加時に再ビルドが必要。</td></tr><tr><td colspan="1" rowspan="1">true</td><td colspan="1" rowspan="1">ユーザーがアクセスした時に初めてSSG化。ローディングUIが必要</td><td colspan="1" rowspan="1">初回アクセス時に動的に生成</td><td colspan="1" rowspan="1"><code>useRouter().isFallback</code> による分岐が必要</td></tr><tr><td colspan="1" rowspan="1">blocking</td><td colspan="1" rowspan="1">アクセス時にサーバーでSSG化。完了するまで何も表示されない</td><td colspan="1" rowspan="1">SSRのような挙動。ローディング不要</td><td colspan="1" rowspan="1">初回アクセスがやや遅い可能性あり</td></tr></tbody></table>blockingの設定にした場合、もし取得するデータ量が多いと表示までにタイムラグがある。 表示されるまで画面は真っ白な状態になってしまうため、その場合は「ローディング中です」などのローディングUIを準備すると良い💡<h2 id="h7b7bf1c3af">⭐️fallback:trueにしてローディングUIを作る場合</h2><code>useRouter</code> の <code>router.isFallback</code> を使ってローディングUIを表示させる。fallback: true のときは、まだ静的に生成されていないページにアクセスされると、最初はpropsが渡ってこない状態でページが表示され始める。その間は router.isFallback が true になるので、それを使って「ローディング中」のUIを表示させる仕組み。<pre><code class="language-javascript">const CommentID = (props) =&gt; {
 const { fallback } = props;
 const router = useRouter();

 if (router.isFallback) {
 return &lt;div&gt;ローディング中&lt;/div&gt;;
 }</code></pre><h2 id="h1635ddce6f">⚠️Static Generationのfallbackは開発環境と本番環境で挙動が異なる</h2>開発環境 (<code>npm run dev</code>) では、getStaticPropsは常に再実行されるとのこと⚡️ そのため、新たに記事を投稿すると即座に一覧ページに表示される。しかし本番環境では、初回ビルド時に取得したデータしか表示されない。<table><tbody><tr><th colspan="1" rowspan="1">状態</th><th colspan="1" rowspan="1">実行タイミング</th><th colspan="1" rowspan="1">新記事が表示されるか</th></tr><tr><td colspan="1" rowspan="1">本番（<code>next build &amp;&amp; next start</code>）</td><td colspan="1" rowspan="1">getStaticPropsはビルド時のみ1回</td><td colspan="1" rowspan="1">❌ 表示されない（revalidateなしなら）</td></tr><tr><td colspan="1" rowspan="1">開発環境（<code>npm run dev</code>）</td><td colspan="1" rowspan="1">毎回getStaticPropsが走る</td><td colspan="1" rowspan="1">✅ 表示される</td></tr></tbody></table><h3 style="text-align: start" id="h02e6fe86c8">✅ ISR（Incremental Static Regeneration）の設定をしてSSG記事一覧が古くなるのを防ぐ</h3><code>revalidate</code> オプションを使うことで、一定時間ごとに静的HTMLを再生成可能にしてくれる。 設定した時間経過後、最初のアクセス時にバックグラウンドで再生成が走る。<pre><code class="language-javascript">return {
 props: {
 articles: data.contents,
 },
 revalidate: 60, // ← 60秒ごとに再生成OK
};</code></pre>これで、ビルド後も定期的に「自動更新」されるようになった🎉

CSRで新しく取得した記事が404になる原因とその解決方法。fallbackの設定で解決！

SSG

Next.js×microCMS｜ブログ記事一覧ページをSSG＋CSR(ユーザーアクション)の時のページ生成のまとめ

Next.js のレンダリング方式まとめ｜SSG・ISR・SSR・CSR の違いと使い分け

Next.js × microCMS｜SSGで記事を10件のみ生成。ユーザーアクションで取得した11件目へのアクセスは404になる原因と解決方法