総務省「令和7年版情報通信白書」によると、国内のSaaS市場規模は2025年に約1.9兆円に達し、年率13%で成長を続けている。自社のノウハウやサービスをSaaSとして提供する「SaaSビジネス」への参入を検討する企業が増える中、最初に直面するのが「マルチテナントアーキテクチャをどう設計するか」という技術的な判断だ。
本記事では、マルチテナントの3つの設計パターンを比較し、技術スタック選定、テナント認証、課金連携、費用の目安まで、SaaS開発に必要な実践知識を体系的に解説する。
目次
1. マルチテナントの3つの設計パターン
マルチテナントアーキテクチャは、複数の顧客（テナント）が同一のアプリケーションを共有する設計だ。データの分離方法によって3パターンに分類される。
3パターンの比較表
| 項目 | DB共有（行レベル分離） | スキーマ分離 | DB分離 |
|---|---|---|---|
| データ分離レベル | 低（行レベル） | 中（スキーマレベル） | 高（DB単位） |
| セキュリティ | 中（tenant_idカラムに依存） | 高 | 最高 |
| コスト効率 | 最高 | 高 | 低 |
| スケーラビリティ | 中（大規模テナントがボトルネック） | 高 | 最高 |
| 運用複雑度 | 低 | 中 | 高 |
| マイグレーション | 簡単（1DB） | 中（テナント数分のスキーマ） | 複雑（テナント数分のDB） |
| 初期開発費用 | 300〜800万円 | 400〜1,000万円 | 600〜1,500万円 |
| テナント数上限目安 | 〜1,000 | 〜500 | 〜100 |
パターン1：DB共有（行レベル分離）
1つのデータベース、1つのスキーマを全テナントで共有し、各テーブルに`tenant_id`カラムを持たせてデータを分離する方式。
メリット
- 開発・運用コストが最も低い
- テナント追加がレコード挿入だけで完了
- DBの接続プール管理が容易
デメリット
- tenant_idのフィルタリング漏れ（データ漏洩リスク）
- 大規模テナントがDB全体の性能に影響
- テナント単位のバックアップ・リストアが困難
適しているケース：テナント数が多い（100〜1,000）が、データ量は少ない。B2C寄りのSaaS、小規模事業者向けSaaS。
パターン2：スキーマ分離
1つのデータベース内にテナントごとのスキーマを作成し、データを分離する方式。PostgreSQLの`search_path`を切り替えてテナントを特定する。
メリット
- DB共有より高いセキュリティ
- テナントごとのカスタマイズ（カラム追加等）が可能
- 性能のある程度の分離
デメリット
- テナント追加時にスキーマ作成が必要
- マイグレーション時にテナント数分の変更が必要
- 数百テナントを超えると接続管理が複雑化
適しているケース：テナント数が中程度（10〜500）で、テナントごとにデータ構造のカスタマイズが必要。B2B SaaSの標準的な選択肢。
パターン3：DB分離
テナントごとに独立したデータベースを用意する方式。セキュリティとカスタマイズの自由度が最高。
メリット
- 最高レベルのデータ分離とセキュリティ
- テナント単位のバックアップ・リストアが容易
- 大規模テナントの性能影響がゼロ
デメリット
- インフラコストが高い（テナント×DB）
- マイグレーションの複雑さ
- テナント追加の自動化が必須
適しているケース：テナント数が少ない（〜100）が、1テナントあたりのデータ量が多い。金融・医療・官公庁向けで高いセキュリティ要件がある。
セクションまとめ：DB共有は低コスト・多テナント向き、スキーマ分離はB2B SaaSの標準選択、DB分離は高セキュリティ・少テナント向き。初期はDB共有またはスキーマ分離で始め、要件に応じて移行するのが現実的だ。
SaaSの設計・開発をお考えの方へ
GXO株式会社では、マルチテナントSaaSの設計・開発を支援しています。アーキテクチャの選定から実装まで、貴社のビジネス要件に最適な設計をご提案します。
2. 技術スタックの選定
マルチテナントSaaSに適した技術スタックの選択肢を3パターン提示する。
推奨技術スタック
| 技術スタック | 初期開発費用目安 | 特徴 | 向いているSaaS |
|---|---|---|---|
| Next.js + Supabase | 300〜800万円 | 開発速度が速い。認証・DB・ストレージが統合 | MVP・スタートアップ向けSaaS |
| Laravel + PostgreSQL | 400〜1,000万円 | 堅牢なバックエンド。エンジニア採用が容易 | 業務系・基幹系SaaS |
| Ruby on Rails + PostgreSQL | 400〜1,000万円 | 開発速度と保守性のバランス。実績豊富 | 汎用B2B SaaS |
各スタックの詳細
Next.js + Supabase
フロントエンドにNext.js（React）、バックエンドにSupabase（PostgreSQL + Auth + Storage + Realtime）を採用する構成。SupabaseのRow Level Security（RLS）を活用すれば、DB共有方式のマルチテナントを最も効率的に実装できる。開発速度が速く、MVPを2〜3ヶ月で市場に投入できる。
- 認証：Supabase Auth（OAuth、メール、マジックリンク対応）
- マルチテナント：RLSポリシーで行レベル分離
- リアルタイム：Supabase Realtimeでライブ更新
- 費用：Supabase Proプラン月額$25〜
Laravel + PostgreSQL
PHPのフレームワークLaravelは、日本国内のエンジニア数が多く、採用が容易だ。tenancyパッケージ（stancl/tenancy等）を活用すれば、スキーマ分離やDB分離のマルチテナントを比較的容易に実装できる。業務系・基幹系のSaaSに適している。
- 認証：Laravel Sanctum / Passport
- マルチテナント：stancl/tenancy パッケージ
- キュー処理：Laravel Queues（非同期処理に強み）
- 費用：サーバー費月額1〜10万円
Ruby on Rails + PostgreSQL
Railsの`apartment` gemやActiveRecord のデフォルトスコープを利用したマルチテナント実装が可能。スタートアップから中規模SaaSまで幅広い実績がある。
- 認証：Devise + カスタムテナント認証
- マルチテナント：apartment gem / acts_as_tenant
- 費用：サーバー費月額1〜10万円
インフラの選択
| インフラ | 月額費用目安 | 特徴 |
|---|---|---|
| Vercel + Supabase | $25〜200 | Next.jsとの親和性最高。自動スケール |
| AWS（ECS + RDS） | 5〜30万円 | 柔軟性が高い。大規模向き |
| さくらクラウド | 2〜15万円 | 日本国内データセンター。コスト効率良好 |
| Heroku | $25〜500 | デプロイが最も簡単。MVPに最適 |
セクションまとめ：MVPはNext.js + Supabase、業務系はLaravel + PostgreSQL、汎用B2BはRuby on Railsが推奨。技術選定はチームのスキルセットと採用市場も考慮して決定する。
3. テナント認証・認可の設計
マルチテナントSaaSの認証・認可は、セキュリティの根幹をなす設計だ。
認証フローの設計パターン
| パターン | 概要 | 複雑度 | セキュリティ |
|---|---|---|---|
| サブドメイン型 | tenant1.app.com でテナント特定 | 中 | 高 |
| パス型 | app.com/tenant1/ でテナント特定 | 低 | 中 |
| ログイン時選択型 | ログイン後にテナントを選択 | 低 | 中 |
| カスタムドメイン型 | tenant1.com でテナント特定 | 高 | 最高 |
テナント認証の実装費用
| 機能 | 開発費用目安 | 工数目安 |
|---|---|---|
| 基本認証（メール+パスワード） | 20〜50万円 | 0.5〜1.5人月 |
| OAuth連携（Google/Microsoft） | 15〜40万円 | 0.5〜1人月 |
| テナント別ロール管理 | 30〜80万円 | 1〜2人月 |
| SSO（SAML/OIDC） | 50〜150万円 | 1.5〜4人月 |
| テナント管理画面 | 40〜100万円 | 1〜2.5人月 |
| 監査ログ | 20〜60万円 | 0.5〜1.5人月 |
認可設計のポイント
RBAC（ロールベースアクセス制御）が最も一般的だ。テナント内で「オーナー」「管理者」「メンバー」「閲覧者」の4ロールを設定するパターンが標準的。
- オーナー：テナント設定・メンバー管理・課金管理
- 管理者：データCRUD・メンバー招待
- メンバー：データCRUD
- 閲覧者：データの参照のみ
エンタープライズ向けSaaSでは、RBAC＋属性ベースアクセス制御（ABAC）の組み合わせが必要になる場合がある。追加費用は50〜150万円。
セクションまとめ：サブドメイン型が最もバランスが良い。認証・認可の基本実装で80〜250万円、SSO対応で＋50〜150万円。セキュリティは妥協せず、初期設計で正しく組み込むことが重要だ。
4. 課金・サブスクリプション連携
SaaSビジネスの収益基盤となる課金システムの設計を解説する。
課金サービスの比較
| サービス名 | 手数料 | 月額費用 | 特徴 | 向いているSaaS |
|---|---|---|---|---|
| Stripe | 3.6% | 0円 | グローバル対応。APIが秀逸 | グローバルSaaS |
| PAY.JP | 3.0〜3.6% | 0円〜 | 日本企業向け。サポートが丁寧 | 国内向けSaaS |
| Stripe Billing | 3.6% + 0.5% | 0円 | サブスクリプション管理が充実 | 定期課金が中心 |
| GMOペイメント | 3.2〜3.5% | 要問合せ | 大規模対応。請求書払い対応 | エンタープライズSaaS |
課金機能の開発費用
| 機能 | 開発費用目安 | 工数目安 |
|---|---|---|
| プラン管理（Freemium/有料プラン） | 20〜60万円 | 0.5〜1.5人月 |
| クレジットカード決済連携 | 20〜50万円 | 0.5〜1.5人月 |
| サブスクリプション管理 | 30〜80万円 | 1〜2人月 |
| 請求書発行・インボイス対応 | 30〜80万円 | 1〜2人月 |
| 利用量ベース課金 | 40〜120万円 | 1〜3人月 |
| プラン変更・アップグレード/ダウングレード | 20〜60万円 | 0.5〜1.5人月 |
| 解約・未払い管理 | 15〜40万円 | 0.5〜1人月 |
課金設計のポイント
料金プランの設計はSaaSのビジネスモデルに直結する。
| 課金モデル | 例 | 実装複雑度 |
|---|---|---|
| 固定料金 | 月額9,800円/テナント | 低 |
| ユーザー数課金 | 月額980円/ユーザー | 中 |
| 利用量課金 | API呼び出し回数×単価 | 高 |
| ハイブリッド | 基本料金＋利用量超過分 | 高 |
セクションまとめ：課金連携の基本実装で100〜300万円。StripeまたはPAY.JPが第一候補。料金プランの設計はビジネスモデルの根幹であり、技術実装以上に重要な意思決定だ。
5. 開発費用の目安
マルチテナントSaaSの開発費用をフェーズ別に整理する。
フェーズ別の費用目安
| フェーズ | 開発内容 | 費用目安 | 期間 |
|---|---|---|---|
| MVP（最小実用製品） | コア機能＋認証＋マルチテナント基盤＋課金 | 300〜800万円 | 2〜4ヶ月 |
| β版 | MVP＋管理画面＋分析＋通知 | 500〜1,200万円 | 3〜6ヶ月 |
| 正式版 | β版＋SSO＋API公開＋監査ログ＋ドキュメント | 800〜2,000万円 | 6〜12ヶ月 |
| エンタープライズ版 | 正式版＋カスタムドメイン＋SLA＋専用環境オプション | 1,500〜3,000万円 | 12〜18ヶ月 |
パターン別の初期開発費用
| アーキテクチャ | 技術スタック | MVP費用 | 正式版費用 |
|---|---|---|---|
| DB共有 + Next.js + Supabase | 最軽量 | 300〜500万円 | 800〜1,200万円 |
| スキーマ分離 + Laravel + PostgreSQL | 標準 | 400〜700万円 | 1,000〜1,500万円 |
| DB分離 + Rails + PostgreSQL | 高セキュリティ | 600〜1,000万円 | 1,500〜2,500万円 |
月額運用コストの目安
| 項目 | MVP期 | 成長期（100テナント） | 拡大期（1,000テナント） |
|---|---|---|---|
| インフラ | 1〜5万円 | 5〜20万円 | 20〜100万円 |
| 決済手数料 | 売上の3〜4% | 同左 | 同左 |
| 保守・運用 | 5〜15万円 | 10〜30万円 | 30〜80万円 |
| 月額合計 | 6〜20万円 | 15〜50万円 | 50〜180万円 |
セクションまとめ：MVPで300〜800万円、正式版で800〜2,000万円が相場。アーキテクチャパターンと技術スタックで費用が大きく変動する。MVPで市場検証してから正式版に投資するアプローチが推奨される。
6. シングルテナントから始めるべきか
「最初からマルチテナントで作るべきか」は、SaaS開発で最も多い相談だ。
シングルテナントが適しているケース
- 顧客数が確定している：初期顧客が5社以下で、急激な増加が見込めない
- 高セキュリティ要件：金融・医療・官公庁向けで、テナント間のデータ分離が絶対条件
- カスタマイズが多い：顧客ごとに機能や画面が大きく異なる
- PMF未検証：ビジネスモデルが確立しておらず、まず1社で成功体験を作りたい
マルチテナントで始めるべきケース
- テナント数が10社以上：最初から10社以上の導入が見込める
- 標準化された機能：顧客間で機能の差が少ない
- セルフサービス型：営業なしで顧客がサインアップする
- スケーラビリティ重視：急速な顧客増加を計画
シングル→マルチの移行コスト
後からシングルテナントをマルチテナントに変換する場合、初期開発費用の40〜60%の追加コストが発生する。具体的には以下の作業が必要だ。
| 移行作業 | 追加費用目安 |
|---|---|
| テナント分離ロジックの追加 | 80〜200万円 |
| 認証・認可のマルチテナント対応 | 50〜150万円 |
| データ移行 | 30〜100万円 |
| テスト・検証 | 50〜150万円 |
| 合計 | 210〜600万円 |
開発会社の選定基準はシステム開発会社の選定基準チェックリスト、AI機能を組み込む場合はAIエージェント開発会社の費用・選定ガイドも参照されたい。
セクションまとめ：PMF未検証ならシングルテナントのMVPで市場検証し、PMF達成後にマルチテナント化するのが安全。PMFが確認済みなら最初からマルチテナントで設計する方がトータルコストが低い。
SaaSの開発・設計をお考えの方へ
GXO株式会社は、マルチテナントSaaSの設計から開発・運用まで一貫して対応します。「SaaSのアーキテクチャをどう設計すべきか」「MVPの費用を抑えたい」など、技術的な相談から対応可能です。
※ 営業電話はしません｜オンライン対応可｜最短翌営業日に回答
7. よくある質問（FAQ）
Q1. マルチテナントSaaSのMVP開発にどのくらいの期間がかかりますか？ 技術スタックにもよりますが、Next.js + Supabaseなら2〜3ヶ月、Laravel + PostgreSQLなら3〜4ヶ月が目安です。コア機能を絞り込むことで期間を短縮できます。
Q2. テナント数が増えた場合のスケーリングはどうすれば良いですか？ DB共有方式なら、リードレプリカの追加やコネクションプーリング（PgBouncer等）で対応可能です。スキーマ分離やDB分離の場合は、テナント単位での水平分割（シャーディング）を検討します。
Q3. 既存のWebアプリケーションをSaaS化できますか？ 可能です。ただし、マルチテナント対応、課金機能、テナント管理画面の追加が必要で、初期開発費用の40〜60%の追加コストが見込まれます。
Q4. Supabaseは本番環境でも使えますか？ 使えます。Supabase ProプランはSLA 99.9%を提供しており、日本リージョン（東京）のサポートも追加されています。ただし、高度なカスタマイズが必要な場合はセルフホスト版の検討も有効です。
Q5. SaaSのセキュリティ対策として最低限必要なものは何ですか？ テナント間データ分離の徹底、通信のTLS暗号化、保存データの暗号化（AES-256）、定期的な脆弱性スキャン、監査ログの5点が最低限必要です。エンタープライズ向けではSOC2認証の取得も求められます。
参考資料
- 総務省「令和7年版情報通信白書」
- IPA「安全なウェブサイトの作り方 改訂第8版」
- AWS「SaaS Architecture Fundamentals」