サーバーサイドレンダリングとは？HTML共有・AI生成サイトでの意味をやさしく解説

ひとことで言うと

サーバーサイドレンダリング（SSR）はリクエストのたびにサーバーでHTMLを生成して返す方式で、Next.js（`getServerSideProps`）やNuxt.js、SvelteKitなどのフレームワークが対応しています。静的レンダリングと異なり、データベースや外部APIから最新データを取得してHTMLに反映できるため、ユーザーごとにコンテンツを変えたりリアルタイム情報を初期表示に含めたりできます。

ただしSSRでは毎回サーバーがHTMLを生成するため、サーバープロセスが常に動いている必要があります。ギガサイト便のような「ファイルをアップするだけ」の静的共有サービスにはSSRアプリをそのまま配置できません。プレビュー共有のためだけにSSRを使うケースは少なく、多くの場合は静的エクスポートか静的スナップショットの方が運用が楽です。

• 相手がログインなしで開ける状態か確認する
• PCとスマホで最低1回ずつ表示を確認する
• 内部情報・個人情報・不要な外部送信が残っていないか見る
• レビュー期限と修正時の差し替え方を決めておく

HTML共有で関係する場面

AIで生成したNext.jsアプリをSSRのままプレビュー共有したい場合、VercelやRailwayなどのサーバーを持つホスティングにデプロイする必要があります。URLを発行してすぐに共有できるため便利ですが、デプロイに数分かかることと、サーバー費用が発生する点が違いです。一方、確認用として一度きりのプレビューなら`next export`で静的HTMLに書き出してギガサイト便で共有する方が素早くコストもゼロです。

SSRが必要な場面は「表示するデータが確認者のログイン状態や時刻によって変わる」ケースです。例えばCRM画面のプレビューで特定の営業担当に絞った案件一覧を見せたい場合、静的HTMLではダミーデータを埋め込む必要がありますが、SSRであれば実データベースから取得して表示できます。この場合はSSRの利便性がコストを上回ります。

よくある誤解

「SSRとSPAは対立するもの」という誤解があります。Next.jsはSSRとクライアントサイドのReactを組み合わせており、初回表示はSSRでHTMLを返し、以降のページ遷移はクライアントサイドで行うハイブリッド構成が一般的です。AI生成のNext.jsアプリもこの構成になっていることが多く、静的エクスポートに切り替えると一部の動的ルートが使えなくなることがあります。

「SSRはSEOに強いから必ず選ぶべき」という考えも場合によります。プレビュー共有の用途であればSEOは不要なため、静的HTMLの方が配信が速く管理も簡単です。最終的な公開サイトがSSRを必要とする場合でも、プレビュー段階では静的スナップショットで十分なことがほとんどです。

安全に使うための注意点

SSRアプリをプレビュー共有する際は、環境変数（APIキー・DBパスワード）がブラウザに露出しないよう注意が必要です。Next.jsでは`NEXT_PUBLIC_`プレフィックスがない環境変数はクライアントには届きませんが、`NEXT_PUBLIC_`付きの変数はビルドに含まれてしまいます。AI生成コードに不必要な`NEXT_PUBLIC_`変数が含まれていないかを共有前に確認してください。

SSRアプリをVercel等にデプロイしてプレビューURLを共有する場合、デプロイURLは公開状態になることが多いです。確認者以外がアクセスできないよう、Vercelの「Password Protection」機能やギガサイト便のメール認証のような保護を組み合わせてください。アクセス制御なしのプレビューURLをSlackなどのオープンなチャンネルに貼ると、意図しない第三者が閲覧できる状態になります。