「ISRにしたのに、またSSR？」で手が止まっていませんか。
この記事は手順解説ではありません。
PowerSという1つの画面で、ISRの次にSSRを選んだときの判断を記録したものです。
読む時間の目安は約8分です。
結論を先に
- SSR（サーバーサイドレンダリング）は、見に来るたびにサーバーがHTMLを作る方式です。ISRは先にHTMLを作って置き、あとから作り直します。
- PowerSでは最初、「これはSSRが必要だ」と考えました。ところが実際にURLとページのソースを確認すると、使っていたのはSSRではなく Server Action（ボタン操作からサーバー側の処理を直接呼び出す仕組み）でした。
- 見分ける軸は方式の略語ではありません。「その画面のデータは、リクエストごとに変わるか」です。ここは変わりませんでしたが、実装の呼び方は正しく直す必要がありました。
- 体感速度・公式の数値・検索順位は測っていないため、この記事では触れません。
ここから、その判断の中身を順番に振り返ります。
なぜISRだけでは足りなかったか
結論：
ISRで足りる条件と、足りない条件が分かれたからです。
snackのISR記事では、SSRを「来るたびに作る方式」として一度保留にしました。一覧を人ごとに毎回作り直す必要がなかったため、そのときはISRを選びました。
PowerSでは、その前提が崩れました。
PowerSには2種類のページがあります。/category/* /concerns/* /guide/* のような、悩み別・石別の解説記事は、内容の更新頻度がそれほど高くないため、ISR（またはSSG）で十分でした。一方でトップページの診断フォームだけは事情が違いました。
ISRは、朝刊を先に刷って置いておき、時間が来たら新しい号に差し替えるイメージです。
サーバー側の処理も同じで、注文（ボタン操作）が入るたびにその場で作る仕込みです。
在庫として並べておける一覧と、いま届いた注文票では、作り方の前提がそもそも違います。
何を確認したか（穴を埋める前でも使えるチェック）
- その画面のデータを「誰が・いつの時点で」見るのかを、一文で書けるか
- 同じHTMLを複数人に配ってよいのか、本人専用なのか
- Bot（検索エンジンなどがページを読み取るプログラム）に読ませたい本文が、最初に返るHTMLの中に必要か（必要ならCSRの検討からは外れます）
| 条件 | 取る行動 |
|---|---|
| 一覧は共通で、あとから更新が増える | ISRを検討する（snack側の記録） |
| リクエストごとに本人だけ／その瞬間の状態が必要 | SSRを検討する（本記事の対象） |
| ほぼ変わらない説明文 | SSGを検討する |
| Botに読ませる本文が最初のHTMLに無くてよい | その部分はCSRを検討する |
ニックネーム・生年月日・悩みの内容という、そのとき入力された情報をもとに、外部のAIへリクエストを送って鑑定文をその場で生成する必要がありました。
さらに、1日に使える回数の上限をIPアドレスごとに確認する処理も、リクエストのたびにサーバー側で行う必要がありました。
あらかじめ結果を用意しておく（ISR）ことも、ビルド時に固定しておく（SSG）こともできなかったため
診断結果を返す部分にはSSRの仕組みが必要だと確信しました。
条件が分かったところで、次はその判断が本当に正しかったかを確認した過程を見ていきます。
確認して分かったこと：SSRではなくServer Actionだった
結論：
「サーバー側で処理している」＝SSR、とは限りませんでした。
実際にフォームへテスト入力をして「無料で鑑定する」を押し、アドレスバーのURLを見ました。結果はhttps://powers.snack-new-arrival.com/のままで、URLは変わりませんでした。
次に、右クリックから「ページのソースを表示」（Ctrl+U）を開き、Ctrl+Fで鑑定文の一部を検索しましたが、見つかりませんでした。
これは、ボタンを押した瞬間にJavaScriptがサーバー側の処理（Server Action）を直接呼び出し、結果だけを画面に書き足していたためです。ページ全体をサーバーが作り直しているわけではないので、厳密には「SSR」ではありませんでした。
Server Actionは、CSR・SSR・SSG・ISRという「ページ全体をいつ・どこで作るか」の話とは別の概念です。ボタン操作などから、サーバー側の処理（外部AIの呼び出しや、利用回数のチェックなど）を直接呼び出すための仕組みです。
とはいえ、判断の軸そのものは変わりませんでした。
「その画面のデータは、リクエストごとに変わるか」という点で、あらかじめ用意しておく（ISR）ことも、ビルド時に固定しておく（SSG）こともできなかったため、リクエストのたびにサーバー処理が必要、という結論は合っていました。呼び方だけがSSRではなくServer Actionだった、ということです。
確認の中身が分かったところで、次はPowerSの中で具体的に何をどう解決したのかをまとめます。
PowerSのどこをSSRにしたか
結論：
サイト全体ではなく、必要だった画面（または画面の一部）だけです。
この節では、次の3点を実際の事実で埋めます（未確認の内容は書きません）。
- PowerS：無料パワーストーン診断 / 無料パワーストーン診断｜AIがあなたの運命の石を提案
- Server Actionが返す内容：そのとき入力された情報（ニックネーム・生年月日・悩み）をもとにAIが生成した鑑定文と、おすすめのパワーストーン。加えて、その日にあと何回使えるかという残り回数の情報
- ホスティング環境：Firebase App Hosting
Firebase App Hostingは、Next.jsのSSRやServer Actionのようなサーバー側の処理をそのまま動かせるホスティングです。
以前からあるFirebase Hosting（静的ファイル配信専用）とは別物で、この違いがあったからこそ、診断のようなサーバー処理が必要な機能もVPSを使わずに実現できました。
細かい手順のコピペは書きません。確認した順番だけを残します。
- 対象のページ（トップページの診断フォーム）を開く
- テスト用のニックネームで実際にフォームを送信し、結果が出るまで進める
- アドレスバーのURLが変わるかどうかを確認する
- 変わらなければ「ページのソースを表示」で鑑定文を検索し、見つかるかどうかを確認する
対象画面が決まったら、今度はISRとの違いをもう一段はっきりさせておきます。
ISRとの切り分け
結論：
切り分けは「更新の仕方」ではなく「いつ・どこで処理するか」です。
| 方式 | 公開したサイトで起きること | PowerS／snackでの位置 |
|---|---|---|
| ISR | 一度作ったHTMLを出す。時間が経ったら（またはオンデマンドで）裏側で作り直す | /category/* /concerns/* /guide/* など、更新頻度は高くない |
| Server Action | ボタン操作などをきっかけに、必要な処理をサーバー側で直接実行する。ページ全体の作り直しではない | 診断結果を返す部分 |
snack記事の言い方をそのまま借りると、次のようになります。
- ISR：先に作って、あとで作り直す
- Server Action：必要なときだけ、ボタン操作からサーバー側の処理を直接呼び出す
Tomoya同じアプリの中で、ISRとServer Actionが混在してもかまいません。
ページ単位でハイブリッドに使い分けるという公式の考え方は、比較記事のほうで扱っています。
ここではPowerSの1画面の話にとどめます。
ここまでの判断を踏まえて、迷いやすいポイントだけ先に共有しておきます。
ここで迷いやすいポイント
- 「SSRの方が新しいから全部SSRにする」にしない。必要のない画面まで毎回生成する必要はありません
- 「ISRにしたからSSRの話は終わり」にしない。データの性質が違えば、別の選択になります
- 「サーバー側で処理している」＝SSR、と決めつけない。URLが変わらないままボタン操作で処理を呼び出しているなら、それはServer Actionです（本記事のPowerSがそうでした）
- 体感が速くなった／遅くなったは、測っていないなら書きません（本記事でも数値は仮置きしていません）
最後に、AIに実装を任せる際、どこまで自分で決めたかを振り返ります。
丸投げしなかった判断
結論：
「SSRにして」とだけAIに渡すと、略語の実装そのものに寄ってしまい、
「どの画面のどのデータか」が抜けやすくなります。
| 決めた軸 | 中身 |
|---|---|
| 目的 | 本人のその瞬間の入力に対する結果のみ。結果は保存されず、共有URLも無いため、Botに読ませる想定ではない |
| 対象 | PowerSの1画面（トップページの診断結果を返す部分）に限定。snack・空HTML記事と混ぜない |
| 成功の見方 | リクエストのたびに必要な処理（AI呼び出し・回数チェック）がサーバー側で行われているか。速度のスコアでは成功と判断しない |
| やらないこと | SSRのみ等に偏らない事 |
Tomoya自分で確認した具体は、前の節に書いたとおりです。
テスト送信をしてURLの変化を見て、変わらなければページのソースを検索する。この2つだけで、「SSR」という言葉が正確かどうかが分かりました。
AIエージェントには、自分の要件を伝える事でその意図を汲んで計画してくれるので、どこだけに絞るのかを決めて置くと偏らずに上手く行ってくれます。
まとめと次の行動
- SSRは来るたびにHTMLを作ります。ISRは先に出してあとで作り直します
- PowerSでは当初「SSRが必要」と考えましたが、確認するとURLもHTMLも変わらず、実際に使っていたのはServer Action（ボタン操作からサーバー処理を直接呼び出す仕組み）でした
- 呼び方は違っても、「リクエストごとに変わるデータは、あらかじめ作っておけない」という判断の軸は変わりません
- 「サーバー側で処理している」という言葉だけでSSRだと決めつけず、URLとページのソースを確認したことが、今回の一番の学びです
- 速度や検索順位については、この記事では書いていません
Tomoya次にやることは2つです。
①自分が見ている画面について「共通の一覧なのか、本人のその瞬間の情報なのか」を一文で書き出すこと。
②そして、ボタン操作でURLが変わるかどうかを実際に確認することです。
続けて読むなら、こちらもどうぞ。
※本記事はNext.jsの仕様に基づく判断の記録です。仕様は今後変わる可能性があります。検索順位や表示速度を保証するものではありません。
コメント