SaaSのマルチテナント設計｜RLS・スキーマ・DB分離の選び方と判断フロー【2026年版】

SaaSのマルチテナント設計で最初に決めるべきは、「テナント（顧客）同士のデータと処理を、どのレベルで分離するか」です。分離の考え方は、テナントごとに資源を専有させるサイロ、全テナントで資源を共有するプール、両者を組み合わせるブリッジの3モデルに整理でき、データベースの実装ではDB分離・スキーマ分離・行レベル分離（RLS）の3方式に対応します。

唯一の正解はなく、最適な方式は「テナント数・コンプライアンス要件・コスト・カスタマイズの幅」から逆算して決まります。本記事では、3つの分離モデルとデータ分離方式の違い、方式を選ぶ判断フロー、ノイジーネイバーや移行といった実務上の勘所までを、特定のクラウドに依存しない中立な視点で解説します。

マルチテナントとシングルテナントの違い

マルチテナントとは、1つのシステム（アプリケーションとインフラ）を複数の顧客＝テナントで共有し、データやアクセスを論理的に分離して提供する方式です。これに対してシングルテナントは、テナントごとに独立したシステム一式を用意します。

SaaSの多くがマルチテナントを採用する理由は、サーバーやデータベースを共有することでインフラ原価を抑え、テナントが増えても運用負荷が比例して膨らみにくいからです。一方のシングルテナントは、分離が強くカスタマイズしやすい反面、テナント数に比例してコストと運用が重くなります。

なお、これは機能単位でシステムを分割するマイクロサービスアーキテクチャとは別の軸の話です。マルチテナントは「顧客単位の分離」、マイクロサービスは「機能単位の分割」を指し、両者は併用もできます。重要なのは「マルチかシングルか」の二択ではなく、共有と分離のバランスをどこで取るかという設計判断です。

テナント分離の3モデル：サイロ・プール・ブリッジ

テナント分離の考え方は、AWSやMicrosoftの設計ガイドでも共通して、サイロ・プール・ブリッジの3モデルで整理されます。結論から言えば、分離の強さとコスト効率はトレードオフの関係にあります。

• サイロモデル：テナントごとに専用のリソース（コンピュートやデータベース）を割り当てます。分離が最も強く、カスタマイズやコンプライアンス対応に優れますが、コストと運用負荷は最大になります。少数・大口や規制業界のテナントに向きます。
• プールモデル：全テナントが共有リソースを使い、識別子で論理的に分離します。コスト効率と拡張性が最も高い反面、後述するノイジーネイバーや情報混入への作り込みが必須です。多数の中小テナントに向きます。
• ブリッジモデル：サイロとプールを組み合わせます。共通部分は共有しつつ、機微なデータや大口テナントだけ専有させる、現実的な折衷案です。

多くのSaaSは、コスト効率の高いプールを基本にしながら、要件の厳しいテナントだけブリッジで専有させる構成に落ち着きます。

データ分離の3方式と比較（DB・スキーマ・行レベル）

3つの分離モデルをデータベースの実装に落とすと、DB分離・スキーマ分離・行レベル分離の3方式に対応します。それぞれの特徴を整理したものが次の早見表です。

観点	DB分離（サイロ）	スキーマ分離（ブリッジ）	行レベル分離（プール）
構成	テナントごとに別データベース	1つのDB内にテナントごとのスキーマ	共通テーブル＋tenant_id列
分離の強さ	最も強い	中程度	論理分離（RLSが前提）
コスト効率	低い	中程度	最も高い
カスタマイズ性	高い	やや高い	低い
マイグレーション	DB数が増え煩雑	スキーマ数の上限に注意	一括適用で容易
個別バックアップ・削除	テナント単位で容易	スキーマ単位で可能	個別抽出が難しい
向くテナント規模	少数・大口	数十〜数百	多数・小口

実務では、立ち上げ期は行レベル分離で素早く始め、規制対応や大口テナントが増えた段階で一部をスキーマ分離やDB分離へ寄せる、という組み合わせが現実的です。

分離方式を選ぶ判断フロー

唯一の正解がないため、自社の制約から逆算して選ぶのが定石です。AWSやAzureの公式ガイドはいずれも自社サービスを前提に書かれているため、ここでは特定のクラウドに依存しない判断軸を示します。次の順で検討すると迷いません。

1. コンプライアンスとデータ主権：医療や金融など、テナントごとのデータの物理分離や監査が求められるなら、サイロ（DB分離）が出発点になります。
2. テナント数と単価：少数・大口ならサイロ寄り、多数・小口ならプール寄りが原価的に合理的です。
3. カスタマイズの幅：テナントごとにデータ構造や機能が大きく異なるなら、スキーマ分離以上を検討します。
4. コストと採算：粗利率を重視するならプール型でインフラを共有します。分離方式はSaaSのユニットエコノミクス（LTV÷CAC）に直結します。
5. 運用体制の成熟度：DBが多数に分かれるサイロは、マイグレーションや監視の自動化が前提になります。

判断に迷う場合は、プールを基本に置き、要件が厳しいテナントだけブリッジで個別対応する構成から検討すると、過不足のない設計に収束しやすくなります。

行レベル分離を支えるRLSの実装

最もコスト効率が高いプール型（行レベル分離）では、1つのクエリのミスが他テナントへの情報漏えいに直結します。これを防ぐ仕組みが、データベース側で行単位のアクセスを強制するRLS（行レベルセキュリティ）です。

PostgreSQLでは、対象テーブルにtenant_id列を持たせ、セッションのテナントIDと一致する行だけを操作できるようにポリシーを定義します。

-- テナントIDをセッション変数として設定（接続時にアプリ側で実行）
set app.current_tenant = '6f0c8b3a-...';

-- 対象テーブルでRLSを有効化
alter table documents enable row level security;

-- 自テナントの行だけにアクセスを限定するポリシー
create policy tenant_isolation on documents
  using (tenant_id = current_setting('app.current_tenant')::uuid);

アプリ側に実装漏れがあってもデータベースが最後の砦になる点が、tenant_idでの絞り込みをアプリ任せにしないRLSの価値です。RLSポリシーの基本的な書き方や認証との接続は、Next.js × Supabase AuthでのRLS設定で具体的に解説しています。なお、管理用の特権キー（service role）はRLSを迂回するため、その取り扱いには注意が必要です。

ノイジーネイバーとテナント識別の注意点

プール型で必ず向き合うのがノイジーネイバー問題です。これは、一部のテナントが大量のリクエストや重いクエリを発行し、他テナントの性能まで巻き込んで劣化させる現象を指します。対策としては、テナント単位のレート制限・リソースクォータ・接続数の制御に加え、特に負荷の重いテナントだけをブリッジ構成で隔離する方法が有効です。

あわせて設計が必要なのがテナント識別です。サブドメイン（tenant.example.com）、ログイン後のトークン（JWTのクレーム）、リクエストヘッダーのいずれかでテナントを特定し、リクエストの最初の段階で確定させます。テナントをまたいだアクセスを認証・認可で確実に遮断することは、分離方式を問わない大前提です。

成長段階に応じた分離方式の移行

分離方式は一度決めたら固定ではなく、事業の成長に合わせて見直すものです。立ち上げ期はプール型（行レベル分離）でスピードとコストを優先し、PMF後にエンタープライズや規制業界のテナントが増えた段階で、その層だけをスキーマ分離やDB分離へ移すのが定石です。

この「論理分離から物理分離への部分移行」を見据えるなら、初期からすべてのテーブルにtenant_idを通し、テナント識別をアプリの共通層に隠蔽しておくと、後の移行コストを大きく下げられます。SaaS全体の費用感や進め方の前提は、SaaS開発の費用相場と進め方もあわせて参考にしてください。

よくある質問（FAQ）

マルチテナントとマイクロサービスは何が違いますか？

マルチテナントは「顧客（テナント）単位の分離」、マイクロサービスは「機能単位のシステム分割」で、別の軸の話です。両者は併用でき、機能をマイクロサービスで分けつつ、各サービス内でマルチテナント設計を行うこともあります。

小規模なSaaSでも最初からRLSは必要ですか？

プール型（共有テーブル）を採用するなら、規模に関わらず最初からRLSを有効にすることを推奨します。後付けは移行コストが高く、その間の情報漏えいリスクも大きいためです。

サイロとプールはどちらが安全ですか？

分離の強さだけならサイロですが、「安全＝サイロ」ではありません。プールでもRLSとテナント識別を正しく設計すれば、実務上は十分な分離が得られます。コストと運用を含めた現実解は、プールやブリッジにあることが多いです。

まとめ

SaaSのマルチテナント設計は、サイロ・プール・ブリッジの分離モデルと、DB・スキーマ・行レベルのデータ分離方式を、自社の制約から選ぶ作業です。コンプライアンス・テナント規模・コスト・カスタマイズの4軸で逆算すれば、過不足のない方式に収束します。

特に立ち上げ期は、行レベル分離（RLS）とテナント識別の共通化で素早く始め、成長に応じて一部を物理分離へ寄せる設計が、コストとリスクのバランスに優れます。これらは後からの変更が重いため、最初の設計判断が事業の採算性とスケーラビリティを長く左右する点を押さえておくことが重要です。