CSR・SSR・静的生成とフレームワークの選択

同じ記事が画面に見えても、クローラーが受け取った資料は異なりうる

日曜日の開館案内を表示するには、どこかでデータを読み、HTML要素を作る必要がある。ブラウザーが行う場合、サーバーは最初に読み込み画面だけを送ることがある。サーバーで先に作れば、開館時間と休館日を応答本文に含められる。検索・回答システムはその応答と後続処理から資料を得るため、この違いがSEO・GEO・AEOに関わる。

以下は同じ案内を提供する二つの方式の本文部分だ。CSRの例はブラウザーのJavaScriptで本文を埋める構成、サーバー生成の例はSSRまたは静的生成で本文を含める構成だ。

<!-- ブラウザーで本文を取得する構成の最初の応答 --> <main id="guide">案内を読み込んでいます。</main> <script src="/guide.js" defer></script> <!-- 本文をサーバーで生成した構成の応答 --> <main><article> <h1>図書館の日曜日の開館案内</h1> <p>日曜日は10〜17時開館します。第1日曜日と祝日は休館します。</p> <p>2026年10月から適用します。</p> <a href="/policies/opening-hours">開館時間案内の原文</a> </article></main>

最初の応答には休館日がない。/guide.jsを実行して必要な資料を取得して初めて分かる。二つ目には答え・例外・適用日・根拠リンクがすでにある。HTMLを読むツールは追加の画面組み立てなしで資料を得られる。まずこの違いを確認してから、本文をいつ作るか選ぶ。

本文を受け取る段階が検索結果とAI回答につながる

検索システムは取得した文書の内容を処理してインデックスに入れ、質問に合う資料を選ぶ。ページが「第1日曜日休館」を届けなければ、そのページから条件を得られない。応答HTMLに本文を入れれば、この情報がJavaScript実行と追加API要求の成功だけに依存する状態を減らせる。

GoogleはJavaScriptを実行し、CSRの本文も処理する。その際は収集後にレンダリングを行い、遮断されたリソースや失敗した要求によって内容が抜ける場合がある。SSR・事前レンダリングは主要な本文を応答に含める方法だ。Googleは、すべてのボットがJavaScriptを実行できるわけではないことも説明している。GoogleのJavaScript処理過程

ウェブ資料を使う生成型回答にも、読める文書が必要だ。Googleの生成型検索ではインデックス登録とスニペット表示資格が参加条件に含まれる。本文の配信を直すことは、回答の根拠候補となる文書を検索システムが処理できるようにすることにつながる。その後に、質問との関連性、事実と条件の十分性、実際の出典選択を確認する。Googleの生成型検索要件

例えば「2026年11月1日に訪問できるか」には、日曜日の時間と第1日曜日休館の条件を一緒に読む必要がある。サーバー本文に時間だけを入れても、配信方法は変わるが答えの材料は不足する。レンダリングは資料の配信を解決し、原稿は判断に必要な事実を提供する。外部AIサービスごとの収集・取得方法は、各サービスの文書と実際の引用結果で確認する。

CSRとSSRはデータを読み本文を作る場所が異なる

CSR（Client-Side Rendering）はブラウザーで画面を作る方式だ。本文をブラウザーで取得する構成では、HTML受信→JavaScriptのダウンロード・実行→API要求→段落生成の順に進む。失敗した段階によっては読み込み画面が残ったり、一部の情報だけが表示されたりする。

SSR（Server-Side Rendering）は要求を受けたサーバーがデータを読み、HTMLを作る方式だ。公開案内をサーバーで取得してh1・p・a要素を作れば、応答にタイトル・条件・根拠が入る。ブラウザーは受け取った文章を表示し、必要なボタン操作を後から接続する。

SSRではデータ取得の遅延やサーバーエラーが応答に影響する。変更が少ない同じ案内を要求ごとに作り直す必要がなければ、静的生成やキャッシュを選べる。資料を読めるかと、どれほど速く更新する必要があるかを合わせて生成方式を決める。

静的生成は要求前にHTMLを作っておく方式である

静的生成（SSG、Static Site Generation）は訪問要求の前にパスごとのHTMLを作る。例えばビルド時に紹介文と利用案内を読み、各URLのHTMLを生成してCDNから配信する。接続のたびにDBを読み、同じページを作り直す必要がない。タイトル・本文・リンクがHTMLにあるため、収集面の主要な利点はSSRと共通する。

静的生成したページにもボタンや検索欄を置ける。Reactが生成済みHTMLにイベント処理などの操作を接続することを、ハイドレーション（hydration）という。静的ホスティングのファイルに各パスの本文があるかは別に確認する。すべてのURLが同じ空のindex.htmlを受け取り、ブラウザーで本文を埋めるなら、その本文は依然としてCSRで提供されている。

SSGの運用上の課題は更新だ。ビルド後にCMSの記事を直しても、生成済みHTMLは自動では変わらない。再ビルド・再配信するか、対応ランタイムで該当パスを再生成するようにつなぐ。ISR（Incremental Static Regeneration）は、条件や更新要求に応じて生成済みページを作り直す方式だ。使用するNext.jsのバージョンとキャッシュ設定に合わせ、再検証APIと公開イベントを接続する。

一定時間後に更新する方式では、その間、以前の記事が残ることがある。撤回やアクセス権変更を即時反映する必要があれば、期限切れだけを待たず、キャッシュ無効化と要求時の公開判定を設計する。バックグラウンド再生成では更新中に以前の応答を返すことがあるため、公開・撤回直後の最初の要求も確認する。

Next.jsのビルドはパス別HTMLとサーバー実行コードを用意する

ビルドはソースコードを配信用の成果物に変える作業だ。一般的なReact SPAのビルドはJavaScriptとHTMLの入口を作り、本文はブラウザーに埋めさせることがある。Next.jsではパスのデータ取得と設定に応じ、事前生成HTMLと要求時に実行するサーバーコードを用意する。両方ともビルドは成功しうるため、結果に本文がいつ入るか読む必要がある。

後のNext.js実装実習では、/archive/opening-2025は固定された過去の案内をビルド時に作り、/guides/[slug]は要求ごとに現行公開版を読む。運用サーバーは前者に生成済みHTML、後者にサーバーコードで作った応答を提供する。どちらも本文をクローラーへ送れるが、修正反映の時点は異なる。

静的パスはビルド時の原稿を提供し続けるため、修正後に再生成が必要だ。要求時生成のパスは新しい要求で新しい資料を読めるが、取得キャッシュがあればその更新も必要になる。ビルド完了後に確認するのは、生成されたパス、実際のHTML、修正後の最初の応答の内容だ。

output: exportを使うと、Next.jsはoutディレクトリへ配信用HTML・CSS・JavaScriptを作る。これらは静的サーバーから配信できる。要求ごとのサーバーコード実行やISRは、サーバーランタイムを使う配信で構成する。Next.jsの静的エクスポート

例のファイルでデータ取得とHTML出力を探す

Reactは画面をコンポーネント（component）に分けて構成するライブラリーだ。コンポーネントは見出しや記事一覧など、再利用する画面単位だ。JSXはJavaScript内でHTMLに似た表記を使う構文だ。TypeScriptはデータの形を検査できるようJavaScriptへ型を加えた言語で、tsxファイルはTypeScriptとJSXを併用する。

ビルド（build）はコードを実行環境向けに変換してまとめる作業で、バンドル（bundle）はそのコードファイルだ。開発サーバーは変更を素早く表示し、運用ビルドは実際の配信物を作る。ランタイム（runtime）は成果物を実行する環境で、ブラウザーとサーバーがそれぞれのコードを実行する。

Next.jsのApp Routerはappディレクトリ構造でURLとページを結ぶ。page.tsxはそのURLのページ、layout.tsxは複数ページの共通構造、route.tsはHTTP要求を受けて応答するハンドラーを定義する。[slug]はURLの可変部分で、/guides/opening-hoursならopening-hoursが値となる。src/appを使うリポジトリもある。

generateMetadataはページのデータからタイトル・説明・正規URLを作る関数だ。API（Application Programming Interface）は決まった形式でプログラムが資料や動作を要求する接点だ。公開ページのサーバー関数はDBを直接読むか内部APIを呼べる。DBの接続情報をブラウザーへ渡さず、サーバーで公開条件を適用する。

importは他ファイルのコードを取り込み、awaitは非同期取得の結果を待つ。useEffectはコンポーネントがブラウザーに反映された後で追加作業を実行する。公開本文をuseEffectでしか取得しないと、先の読み込み画面だけの応答になりうる。サーバーpageで資料を読んでJSXのp要素へ出力すれば、サーバー本文に含められる。

Next.jsでも本文の生成場所を追う

App Routerのpageとlayoutは既定でServer Componentだ。サーバー側でデータを読め、静的生成やキャッシュの設定で実行時点が変わる。Server Componentはコンポーネントの実行境界、SSR・SSGはHTMLの生成時点を表す区別だ。

use clientの付いたコンポーネントでも、最初のページ読み込みではサーバーでHTMLを事前生成できる。主要本文がuseEffect後に生まれるか、ブラウザー専用条件で隠れるか、その領域のサーバーレンダリングが無効かを確認する。Server・Client Componentの説明を基にデータが入る時点を確認する。

公開記事をeffectだけで取得しているなら、取得をサーバーpageへ移し、現行公開原稿のタイトル・本文・出典を描画する。いいね・共有・フィルターなど操作が必要な部分だけを小さいClient Componentへ分ける。ブラウザーの空の初期状態がサーバー本文を上書きしないか確認する。サーバーでは現れた文がhydration後に消える場合も検査する。

CMS編集画面の作業版と公開版を分け、本文とメタデータが同じ公開版を読むようにする。レンダリングだけを移して一時保存版を取得すると、検索問題を直すつもりで非公開原稿を露出しかねない。公開取得関数で現行公開版を選び、本文とメタデータへ渡す。

ViteとNext.jsのサーバーレンダリング構成を比較する

Viteは開発サーバーとビルドツールだ。SPA（Single-Page Application）は一つの文書内でJavaScriptにより画面を切り替えるアプリだ。一般的なViteベースのReact SPAはアプリのJavaScriptとHTMLの入口をビルドする。この構成で記事をuseEffectから取得すれば、ページごとの本文生成はブラウザーが担う。個別HTML・正規URL・サイトマップが必要なら、サーバーレンダリングまたは事前生成とメタデータ生成を構成する。

ViteにもSSR機能がある。サーバー入口でコンポーネントを描画してHTMLへ入れる構成か、ViteベースのSSR・静的生成フレームワークを使える。この場合も要求処理、データ取得、ルート別head、404・リダイレクト、キャッシュと更新方法を選ぶ必要がある。ViteのSSRガイドは低水準APIとサーバー・クライアントの入口を説明する。

Next.jsはさらに広いアプリ構造を提供する。App Routerのpage・layout、サーバー取得、静的・動的レンダリング、Metadata API、robots・sitemapファイル規約、リダイレクトと配信ランタイムを一つの構造で扱える。例えばCMS公開版を取得して本文・generateMetadata・JSON-LDを同じ資料から作り、公開変更に合わせて関連キャッシュを更新できる。

公開紹介と保存資料を事前生成し、新規記事は現行公開版を読み、詳細ごとにタイトル・正規URL・出典を示すサイトなら、この統合構造が選ぶ根拠になる。改修後もルート・メタデータ・サイトマップ・サーバー応答を同じアプリ内で追いやすい。公開条件を各所で別々に実装することによる漏れを減らせる。検索システムが収集するのは、この構造が出力したHTML・リンク・メタデータだ。

Vite構成でも同じ公開HTML・メタデータ・ステータスコード・更新機能を提供できる。比較では、自前で実装するルーティング・サーバー取得・キャッシュコードの量、配信環境の対応機能、チームの保守経験を合わせて見る。既存の安定した構成は、まずこの要件を満たすか確認する。

CMS案内数百本のタイトル・本文・canonicalを別のコードで作ると、新種のコンテンツ追加時に経路を落としやすい。Next.jsを選ぶ実務上の理由は、ルート別取得、Metadata API、サイトマップ生成を同じ資料とファイル構造で管理できる点だ。これで実際の出力の漏れや不一致を減らせるか評価する。同じ応答と更新動作をすでに提供するVite SSRや別のサーバー構成も、この要件を満たす。

ページごとに生成時点と更新方法を決める

紹介や保存案内のように配信の間で内容が変わらないページは静的生成で提供できる。CMSで随時公開・撤回する詳細記事は、要求時に現行公開版を読むか公開イベントでキャッシュを更新する。個人化された管理画面では、認証とユーザー別データを先に処理する。

一つのサイトでこれらを併用できる。URLの種類ごとに生成時点、古い内容を出してよい時間、障害時の応答を定める。SSRページでも、先に送る共通構造と後から送る資料をストリーミングで分けられる。

サーバー取得を待って応答を開始すれば、その待機時間は最初のバイト到着時間に含まれる。画面枠を先にストリーミングする場合、本文取得は最初のバイトの後に終わることがある。最初のバイト時間と実際の本文表示時間を一緒に測る。

修正前後のHTMLと実際の検索処理を順に比べる

実習のインストール・実行手順を終えたら以下のコマンドを実行し、二つのURLの完全な応答をそれぞれ保存する。curlはJavaScriptを実行しないため、ブラウザーが後から要求して埋める本文は取得しない。

curl -sS -D current.headers -o current.html http://localhost:3027/guides/opening-hours curl -sS -D archive.headers -o archive.html http://localhost:3027/archive/opening-2025

current.htmlでは開館時間・第1日曜日休館・適用開始日、archive.htmlでは2025年の適用期間と現行案内へのリンクを探す。HTMLパーサーの検査は文字列がscriptデータにしかない場合を区別し、articleの本文・リンク・日付を比べる。ストリーミングでは応答全体とブラウザーの完成DOMを一緒に読む。

次にCMS資料または実習の固定原稿を修正し、同じURLを再要求する。静的ページは再ビルド後、要求時生成ページは新しい要求と必要なキャッシュ更新後に新しい文が出る必要がある。選んだ方式が実際の更新要件を満たすかをこれで確認する。

運用へ適用したら、Search Consoleの収集・レンダリング結果と最終収集日を見る。ウェブ検索を使うAIには同じ基準日の質問を行い、引用URLと休館条件を読む。サーバー応答に新しい文があるか、検索が新しい文書を処理したか、回答が条件を使ったかを順に比較すると、次の修正箇所を絞れる。

SSRのHTMLにimgがあれば、ブラウザーはURLを発見して別の画像要求を送る。HTMLに時間がすぐ含まれていても、写真が5MBの原本ならその転送とデコードは続いて発生する。Next.jsのビルド成功後もCMS写真のcurrentSrcと応答バイトを読む理由はここにある。CMS画像配信の実習ではHTML生成方式を固定し、原本要求と派生版要求だけを変えて比較する。