SPA にするか、サーバーサイドレンダリングのままか — 受託開発での判断軸

「フロントは React にしますか？」と聞かれる機会が一気に増えました。
ただ、受託開発で SPA を選ぶかどうかは、技術の良し悪しよりも
そのシステムを誰が何年運用するかで決まります。実際の判断軸を整理します。

SPA にすると増えるもの

分離すると開発体験は良くなりますが、確実に増えるものがあります。

• ビルド工程（Node のバージョン、依存の更新、CI）
• 認証の扱い（Cookie か Token か、CSRF/XSS 対策の設計が変わる）
• SEO対応（SSR/SSG を入れないと初期表示が空になる）
• デプロイ対象が2つになる

小規模な業務システムでこれを背負うと、運用コストが機能価値を上回ります。

判断に使っている質問

実際は次の4つで、ほぼ決まります。

1. 検索エンジンからの流入が要るか

要るなら、素直なサーバーサイドレンダリングか、SSR/SSG を備えたフレームワークが要ります。
社内システムなら不要です。

2. 画面の更新頻度が高いか

チャット、リアルタイム編集、複雑なフォーム分岐のような
「1画面の中で状態が激しく動く」画面は SPA が有利です。
一覧と詳細と編集だけなら、サーバー側で描いたほうが早く終わります。

3. 引き継ぐ人がいるか

これが実務では一番大きい要素です。
納品後に社内の担当者が触るなら、ビルドが必要な構成は事実上メンテ不能になります。
「HTMLを直せば直る」構成の価値は、想像以上に高いです。

4. 画面数はどれくらいか

10画面程度なら、分離のコストが回収できません。

折衷案が現実的

実際に多く採っているのは、サーバーサイドで描いて、必要な画面だけ動的にする構成です。

<!-- 一覧は普通にサーバーで描画 -->
{% for item in items %}
  <tr>...</tr>
{% endfor %}

<!-- 検索だけ非同期で差し替える -->
<input name="q" data-async-target="#result">

この構成なら、ビルド工程を持たずに「必要なところだけ SPA っぽく」できます。
更新の激しい画面だけ後から React に置き換えることもできます。

まとめ

技術の新しさで選ぶと、運用フェーズで必ず後悔します。
「3年後に誰が直すか」を先に決めてから構成を選ぶようにしています。