SPA/SSR選択ミスがリプレースになる理由

レンダリング方式の選択は後から直せない設計項目

Web開発では「とりあえず作って、後から改善すればよい」と言える領域と、言えない領域があります。
SPAかSSRかの選択は後者です。

この判断を誤ると、機能追加や最適化では解決できず、最終的にリプレース（作り直し）になります。
なぜなら、レンダリング方式はUIではなく、アプリケーションの構造そのものに関係しているからです。

なぜ後から変更できないのか

SPAとSSRの違いは表示方法ではありません。
「データをどこで取得し、いつHTMLが完成するか」です。

項目	SPA	SSR
HTML生成	ブラウザ	サーバ
データ取得	API（後）	レンダリング前
ルーティング	クライアント	サーバ

つまり、通信・ルーティング・キャッシュの前提がすべて変わります。

具体例

SPAの商品ページの流れです。

手順	処理
1	HTML取得
2	JSロード
3	API取得
4	描画

SSRの商品ページです。

手順	処理
1	サーバでデータ取得
2	HTML生成
3	レスポンス

この差は、コンポーネント修正では埋まりません。

実務で起きる典型的な失敗

以下のような流れは非常に多いです。

ケース1：メディアサイトをSPAで構築

• 初期開発は順調
• 記事投稿機能も完成
• 公開後、検索流入が伸びない
• OGPが表示されない
• 表示速度で離脱増加

対応として行われるのは次です。

• メタタグ追加
• Helmet導入
• プリレンダリングツール導入

しかし改善は限定的です。
理由は、問題が表示ではなくHTML生成タイミングだからです。

最終的にSSRへ移行することになります。

ケース2：管理画面をSSRで構築

• SEOを意識してSSR採用
• フォーム入力が多い
• 操作のたびに再描画
• 操作遅延とストレス
• ユーザーから不満

SSRを最適化しても、操作性の問題は残ります。
結局SPAへ作り直しになります。

リプレースになる技術的理由

レンダリング方式は次の部分に影響します。

• ルーティング設計
• API設計
• 状態管理
• キャッシュ
• 認証方式

ルーティング

SPA

router.push("/product/1")

SSR

GET /product/1

サーバの役割が根本的に違います。

認証

SPAはトークン中心、SSRはCookie中心になりやすいです。
ここが最も移行を困難にします。

表面上の対策が効かない理由

よく行われる対処があります。

• SPAにSSRを足す
• SSRにSPAを足す
• 部分的に直す

これらは短期的には効果がありますが、構造問題は残ります。
特にSEO・キャッシュ・パフォーマンスの問題は再発します。

設計時に考えるべきこと

判断基準は技術トレンドではありません。
次の質問で決めると失敗が減ります。

• URLは共有されるか
• 初回表示は重要か
• 長時間操作されるか
• 入力が多いか

性質	選択
閲覧中心	SSR
操作中心	SPA

これが基本です。

注意点

ハイブリッド構成という選択肢もありますが、後付けは難しいです。
最初から分離を前提に設計しないと、依存関係が絡み合います。

特にAPI設計は重要です。
SSR前提とSPA前提ではエンドポイント設計が変わります。

なぜリプレースになるのか

不具合なら修正できます。
性能なら最適化できます。

しかしレンダリング方式の誤りは「正しく動いているが目的を満たさない」状態を作ります。
この状態は改善では解決しません。

まとめ

SPAとSSRの選択はフレームワークの選択ではありません。
サービスの性質の選択です。

サイトが「読まれるもの」か「使われるもの」か。
これを最初に決めるだけで、多くのプロジェクトはリプレースを避けられます。