マルチテナントSaaSの設計と実装｜アーキテクチャの選び方

マルチテナントの3つの分離レベル

マルチテナントアーキテクチャはSaaS開発の根幹をなす設計パターンです。1つのアプリケーションを複数の企業（テナント）が共有して利用するため、「テナント間のデータをどう分離するか」が最大の設計判断になります。

分離レベルは大きく3つ：DB分離型、スキーマ分離型、行レベル分離型です。セキュリティ要件、テナント数、運用コストのバランスで選択します。

テナント数別の推奨パターン

DB分離型（テナントごとに別DB）の特徴

テナントごとに完全に独立したデータベースを持つパターンです。エンタープライズ向けSaaSや、金融・医療など高いセキュリティ要件が求められる業界で採用されます。

メリット：

• データの完全分離により、テナント間のデータ漏洩リスクがゼロ
• テナントごとにバックアップ・リストアが可能
• 特定テナントのパフォーマンス問題が他テナントに影響しない
• テナント単位でのカスタマイズ（スキーマ変更等）が容易

デメリット：

• テナント数が増えるとDB管理コストが線形に増加（10テナントで月額5〜10万円のDB費用）
• マイグレーション（スキーマ変更）を全DBに適用する必要がある
• テナント横断のレポート・分析が困難

スキーマ分離型（同一DB、別スキーマ）の特徴

1つのデータベース内で、テナントごとに別のスキーマ（名前空間）を作成するパターンです。PostgreSQLのスキーマ機能を活用するケースが多く見られます。

メリット：

• DB分離型に近いセキュリティを確保しつつ、DBの管理コストを抑えられる
• テナントごとのバックアップ・リストアが可能（pg_dump -n schema_name）
• マイグレーションは全スキーマに一括適用可能（スクリプト化が前提）

デメリット：

• テナント数が1,000を超えると、コネクションプール管理が複雑になる
• テナント作成のたびにスキーマ生成+初期データ投入が必要
• ORM（Eloquent, Prisma等）のマルチスキーマ対応に工夫が必要

行レベル分離型（同一テーブル、tenant_id列）の特徴

すべてのテナントのデータを同一テーブルに格納し、tenant_id列で区別するパターンです。最もシンプルで、SaaS開発の多くがこのパターンを採用しています。

メリット：

• 実装がシンプル（全クエリにWHERE tenant_id = ?を追加するだけ）
• テナント数の増加に対してスケーラブル（10万テナントでも対応可能）
• 運用コストが最も低い（DB1つ、マイグレーション1回）

デメリット：

• tenant_idの付け忘れによるデータ漏洩リスク（最大のリスク）
• テナント単位のバックアップ・リストアが困難
• 大規模テナントがDBを占有するノイジーネイバー問題

必須の対策：PostgreSQLのRLS（Row Level Security）を必ず有効にし、アプリケーション層とDB層の2重でテナント分離を実装してください。アプリケーション側のバグでtenant_idフィルタが漏れても、RLSが防御壁になります。

セキュリティ設計（テナント間のデータ隔離）

マルチテナントSaaSで最も重大なセキュリティインシデントは「テナントAのデータがテナントBに見えてしまう」ことです。以下の3層でデータ隔離を実装します。

• RLS（Row Level Security）: PostgreSQLのRLSでテナント間のデータ漏洩を防止。SET app.current_tenant = 'tenant_id' でセッションごとにテナントを設定し、ポリシーで自動フィルタリング
• APIゲートウェイ: リクエストのJWTトークンからテナントIDを検証し、APIレイヤーでテナント横断アクセスをブロック
• 監査ログ: テナント横断のデータアクセスを検知するアラートを設定。「テナントAのユーザーがテナントBのリソースにアクセスしようとした」ログを即座に検知

セキュリティテストとして、定期的にペネトレーションテストを実施し、テナント間のデータ漏洩がないことを確認してください。OWASP Top 10のA01（アクセス制御の不備）に該当するリスクです。

パフォーマンス設計（ノイジーネイバー問題）

ノイジーネイバー問題とは、1つのテナントが大量のリソースを消費し、他テナントのパフォーマンスに影響を与える問題です。行レベル分離型で特に顕著ですが、スキーマ分離型でも発生します。

実装上のポイントとして、レート制限はRedisを使ったスライディングウィンドウ方式が効率的です。テナントごとに「1分間あたり100リクエスト」「1日あたり10,000リクエスト」などの制限を設定し、超過時は429（Too Many Requests）を返します。

マイグレーション戦略

マルチテナントSaaSのマイグレーション（スキーマ変更）は、分離パターンによって複雑さが大きく異なります。

行レベル分離型：通常のマイグレーションと同じ。1回の実行で全テナントに適用。最もシンプル。

スキーマ分離型：全スキーマに対してマイグレーションを順次実行するスクリプトが必要。並列実行でスピードアップ可能だが、途中で失敗した場合のロールバック戦略を事前に設計しておくこと。

DB分離型：全DBに対してマイグレーションを実行。Blue/Green デプロイメント方式で、旧バージョンと新バージョンを並行稼働させ、段階的に切り替えるのが安全です。

いずれのパターンでも、ダウンタイムゼロのマイグレーションを実現するために、カラム追加→データ移行→旧カラム削除の3段階デプロイを採用してください。

あわせて読みたい

• SaaS開発ガイド｜プロダクト設計からリリースまでの全工程【2026年版】
• SaaSの料金モデル設計｜サブスクリプション課金の種類と最適な価格設定
• SaaSのMVP開発｜最小限の機能で市場検証する方法
• 【2026年版】システム開発の費用相場まとめ｜種類別・規模別に徹底解説
• プロトタイプ開発とは？メリット・費用・進め方をわかりやすく解説

まとめ

マルチテナントSaaSの設計は、DB分離型・スキーマ分離型・行レベル分離型の3パターンから、テナント数・セキュリティ要件・運用コストに応じて選択します。

10社以下ならDB分離型、10〜100社ならスキーマ分離型、100社以上なら行レベル分離型が目安です。いずれのパターンでも、RLSの導入、APIレイヤーでのテナント検証、監査ログによる異常検知の3層セキュリティは必須です。

ノイジーネイバー問題にはレート制限とリソースクォータで対応し、大規模テナントは専用インフラへの移行も視野に入れてください。

マルチテナントSaaS設計のご相談は、お問い合わせからお気軽にどうぞ。FUNBREWでは無料相談を受け付けています。