SSRがマルチテナントWebに向いている理由

マルチテナントWebではSSRのほうが自然に設計できる

SaaSなどのマルチテナントWebを設計するとき、SPAよりSSRのほうが扱いやすくなる場面が多くあります。
理由は単純で、マルチテナントは「ユーザーごとに別のWebサイトを返す」アプリケーションだからです。

同じURLにアクセスしても、ログインしている企業や契約プランによって画面構成が変わる。
これがマルチテナントの基本的な特徴です。

SSRはリクエスト単位でHTMLを生成します。
つまり「アクセスしたユーザーの情報を見て、返すページを変える」という処理が得意です。

マルチテナントの本質は“ページが人によって違う”こと

例えば管理画面型のSaaSを考えてみます。

同じURLでも次の差が発生します。

要素	変化内容
ロゴ	企業ごとに違う
メニュー	契約プランごとに違う
表示項目	権限ごとに違う
テーマカラー	企業設定ごとに違う

つまりマルチテナントとは、単なるログイン機能ではありません。
ページテンプレート自体がユーザーごとに変化するWebです。

ここでSPAとSSRの違いが出ます。

SPAで起きる問題：表示前に大量の情報が必要

SPAはまず共通HTMLを返します。

<div id="app"></div>

その後、JavaScriptがAPIを呼び出し、ユーザー情報を取得してから画面を組み立てます。

つまりSPAでは次の手順になります。

• JSダウンロード
• JS実行
• 認証確認
• テナント情報取得
• メニュー取得
• 画面描画

マルチテナントでは必要なデータが多いため、最初の表示が遅くなりがちです。
特に権限・ロール・設定が複雑なSaaSほど顕著です。

SSRでは「最初から完成した画面」を返せる

SSRではサーバがユーザーを識別してからHTMLを生成します。

<header style="background:#2a6df4">
  <img src="/tenantA/logo.png">
</header>
<nav>
  <li>請求書</li>
  <li>契約管理</li>
</nav>

ブラウザは受信直後に表示できます。
追加のAPI呼び出しを待つ必要がありません。

つまりSSRは、

• テナント判定
• 権限判定
• UI構築

をサーバ側で完結できます。
マルチテナントと相性が良い理由はここです。

キャッシュ設計とも相性が良い

もう一つ重要な理由があります。
マルチテナントではキャッシュ戦略が難しくなります。

SPAではAPIレスポンスをキャッシュしますが、テナントごとに内容が違うため再利用しにくくなります。
一方SSRでは、HTMLをテナント単位でキャッシュできます。

例：CDNキャッシュキー

キー	意味
/tenantA/dashboard	A社のダッシュボード
/tenantB/dashboard	B社のダッシュボード

これによりサーバ負荷を抑えながら高速表示が可能になります。

セキュリティ面でも有利になる

SPAでは権限チェックの一部がクライアントに残ります。
APIは当然サーバで保護しますが、UI制御はJavaScriptです。

つまり、

• ボタンを非表示にする
• メニューを隠す

といった処理はクライアント依存になります。
実装を誤ると「見えてはいけない操作」が表示される事故が起きます。

SSRではそもそもHTMLを生成しないため、安全側に倒しやすくなります。

ただしSSRにも弱点がある

マルチテナントと相性が良いとはいえ、万能ではありません。
最も大きな問題はサーバ負荷です。

テナントごとにページを生成するため、

• アクセス増加
• 企業数増加
• 機能増加

に比例してCPU負荷が増えます。
ピーク時にレスポンスが急激に悪化することがあります。

特に帳票系SaaSでは顕著です。

SPAのほうが向くケースもある

リアルタイム性が重要な場合はSPAが有利です。

• チャット
• コラボ編集
• ライブ監視画面

これらは常時更新されるため、SSRで毎回レンダリングすると逆効果になります。

どう理解すればよいか

マルチテナントWebの難しさは「ログイン後に別サイトになる」点にあります。
ユーザーによってサイト構造が変わる以上、サーバがUI構築を担当するほうが自然です。

SSRはページを生成する技術というより、リクエストに応じてUIを構成するサーバアプリケーションです。

一方SPAは、共通UIにデータを流し込むクライアントアプリケーションです。

テナントごとに構造が変わるならSSR、
同じ構造でデータだけ変わるならSPA。

この視点で選ぶと、設計の迷いがかなり減るはずです。