マルチテナントSaaSの設計方法｜契約企業ごとのデータ分離・権限・DB設計を解説

法人向けのSaaSやWebサービスを開発するとき、重要になるのが「契約企業ごとのデータをどう分けるか」という設計です。

例えば、案件管理SaaSを複数企業へ提供するとします。

株式会社Aの社員には、株式会社Aの顧客・案件だけを表示する。

株式会社Bの社員には、株式会社Bの顧客・案件だけを表示する。

当然ながら、A社のユーザーがB社のデータを閲覧できてはいけません。

こうした複数の契約企業を一つのシステムで管理する構成を考えるときに登場するのが、マルチテナントという考え方です。

結論からいうと、マルチテナントSaaSの設計で最も重要なのは、

すべての処理で「現在どのテナントのユーザーなのか」を明確にし、データ取得・更新・権限判定のすべてでテナント境界を守ることです。

代表的なデータ分離方式には、

同じDB・同じテーブルでtenant_idによって分離する
同じDBでテナントごとにスキーマを分ける
テナントごとにデータベースを分ける

などがあります。

どの方式を選ぶかによって、開発コスト、運用負荷、セキュリティ、拡張性が変わります。

この記事では、マルチテナントSaaSの基本から、契約企業、ユーザー、データ、権限、課金をどのように設計すればよいのか、具体例を交えて解説します。

マルチテナントSaaSとは

マルチテナントとは、一つのシステム基盤を複数の顧客・組織で利用するアーキテクチャです。

ここでいう「テナント」は、一般的には契約企業や契約組織を指します。

例えば案件管理SaaSなら、

SaaS
├─ 株式会社A
│ ├─ 山田さん
│ ├─ 佐藤さん
│ └─ A社の案件
│
├─ 株式会社B
│ ├─ 鈴木さん
│ ├─ 田中さん
│ └─ B社の案件
│
└─ 株式会社C
├─ 高橋さん
└─ C社の案件

という構造です。

同じWebサービスを利用していても、それぞれの企業は自社のデータだけを利用します。

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

マルチテナントと比較されるものにシングルテナントがあります。

マルチテナント

一つのシステムを複数企業で共有します。

シングルテナント

顧客ごとに独立したシステム環境を用意します。

例えば100社へサービスを提供する場合、

マルチテナントなら、

1つのアプリケーション
＋
複数テナント

として管理できます。

シングルテナントなら、

A社用環境
B社用環境
C社用環境
……

のように企業ごとの環境を管理します。

マルチテナントには、サービスを共通化しやすいメリットがあります。

一方、テナント間のデータ分離を正しく設計しなければならないため、アプリケーション設計では慎重さが必要です。

マルチテナントSaaSの基本構造

BtoB SaaSでは、まず次の4つを分けて考えると整理しやすくなります。

テナント
ユーザー
メンバーシップ
業務データ

例えば、

株式会社A
↓
テナント

山田太郎
↓
ユーザー

山田太郎が株式会社Aに所属している
↓
メンバーシップ

株式会社Aの案件
↓
業務データ

という関係です。

単純なサービスでは、

user
→ tenant_id

だけでも実装できる場合があります。

しかし、一人のユーザーが複数企業へ所属する可能性がある場合は、

users

tenants

tenant_members

のように分けるほうが柔軟です。

tenant_idとは

マルチテナント設計でよく使われるのがtenant_idです。

例えば案件テーブルを、

id	tenant_id	name	status
1	100	A社案件1	商談中
2	100	A社案件2	受注
3	200	B社案件1	商談中

とします。

tenant_id = 100

が株式会社A、

tenant_id = 200

が株式会社Bです。

A社のユーザーがログインした場合は、

tenant_id = 100

のデータだけを取得します。

例えば概念的には、

SELECT *
FROM projects
WHERE tenant_id = 100

という検索です。

これが最も基本的なテナント分離です。

マルチテナントで絶対に避けたい「tenant_idの付け忘れ」

tenant_id方式では、一つ大きな注意点があります。

例えば本来、

WHERE tenant_id = 100

を付ける必要がある検索で、開発者が条件を付け忘れたとします。

すると、

SELECT *
FROM projects

となり、すべてのテナントの案件を取得してしまう可能性があります。

これはマルチテナントSaaSにおける重大な問題です。

そのため、

「開発者が毎回気を付ける」

だけに依存しない設計が重要です。

例えば、

Repository層でtenant_idを必須にする
ORMの共通処理にテナント条件を入れる
PostgreSQLのRLSを利用する
APIで認証済みテナント情報から条件を生成する
テナント境界をテストする

など、複数の方法を組み合わせます。

マルチテナントSaaSのDB設計は主に3パターン

データの分離方法には、大きく3つの考え方があります。

1．同じDB・同じテーブルでtenant_idを使う

代表的な構成です。

例えば、

projects

customers

contracts

などすべての業務テーブルにtenant_idを持たせます。

メリット

実装・運用を共通化しやすい
テナント追加が容易
DB管理コストを抑えやすい
SaaSとしてスケールさせやすい

デメリット

tenant_id条件の漏れが重大事故につながる
テナント単位のバックアップ・復元が難しくなる場合がある
大規模テナントによる負荷の影響を受ける可能性がある

小〜中規模のSaaSでは非常に使いやすい方式です。

2．同じDBでスキーマをテナントごとに分ける

例えばPostgreSQLなら、

tenant_a.projects

tenant_b.projects

tenant_c.projects

のような構成です。

メリット

テナントごとのデータ境界が分かりやすい
同一DB内で一定の分離ができる

デメリット

テナント数が増えるとスキーマ管理が複雑になる
マイグレーションを大量のスキーマへ適用する必要がある
運用自動化が重要になる

顧客数が限定されているサービスでは検討できる方式です。

3．テナントごとにデータベースを分ける

例えば、

A社
→ database_a

B社
→ database_b

C社
→ database_c

という方式です。

メリット

データを物理的・論理的に強く分離しやすい
テナント単位のバックアップや復元を行いやすい
大口顧客だけ専用環境へ分離しやすい

デメリット

DB数が増える
マイグレーション管理が複雑
接続先管理が必要
運用コストが高くなる

セキュリティ要件が高い企業向けSaaSなどで検討することがあります。

3つの方式を比較

項目	tenant_id方式	スキーマ分離	DB分離
開発しやすさ	◎	○	△
運用しやすさ	◎	△	△
テナント追加	◎	○	△
データ分離	○	○〜◎	◎
コスト	低	中	高
大規模SaaS	◎	△	条件次第
個別バックアップ	△	○	◎

どれが正解というわけではありません。

顧客数、データ量、セキュリティ要求、運用体制などによって判断します。

最初から「1社1DB」にすれば安全とは限らない

データ分離を考えると、

「会社ごとにDBを分ければ一番安全なのでは？」

と思うかもしれません。

しかしDBを分けるほど、

DB作成
バックアップ
マイグレーション
監視
接続管理
障害対応

の対象が増えます。

顧客が1,000社になれば、1,000個のDBを管理する可能性があります。

運用を自動化できていなければ、システム全体が複雑になります。

セキュリティだけでなく、運用可能性まで含めて判断する必要があります。

SaaSでは「契約企業」と「ユーザー」を分ける

BtoCサービスでは、

ユーザー
→ 契約

でも成立することがあります。

しかしBtoB SaaSでは、

企業
→ 契約
→ 複数ユーザー

という構造になることが多くあります。

例えば、

株式会社A
↓
Standardプラン契約
↓
社員20人利用

という形です。

そのため、

users

だけではなく、

tenants

tenant_members

subscriptions

などを分けて設計します。

一人が複数テナントへ所属するケースも考える

例えば税理士向けSaaSを考えてみましょう。

一人の税理士が、

株式会社A

株式会社B

株式会社C

のデータを管理する可能性があります。

その場合、

users.tenant_id

だけでは対応しにくくなります。

そこで、

users

tenants

tenant_members

という中間テーブルを使います。

例えば、

user_id	tenant_id	role
10	100	admin
10	200	member
10	300	viewer

という構成です。

これにより、一人のユーザーが複数テナントへ参加できます。

現在のテナントをどう決めるか

複数テナントへ所属できる場合は、

「現在どのテナントとして操作しているか」

を決める必要があります。

例えば画面上で、

株式会社A ▼

のようなテナント切り替え機能を用意します。

ユーザーが株式会社Aを選択した場合、

current_tenant_id = 100

として、そのテナントのデータだけを処理します。

ここでも重要なのは、フロントエンドから送られてきたtenant_idを無条件に信用しないことです。

ユーザーが、

tenant_id = 200

へ書き換えてAPIを呼び出したとしても、

「このユーザーは本当に200へ所属しているか」

をサーバー側で確認する必要があります。

tenant_idはフロントエンド任せにしない

例えばAPIが、

GET /projects?tenant_id=100

になっているとします。

ユーザーがリクエストを、

tenant_id=200

へ書き換えた場合にB社のデータが取得できてはいけません。

正しくは、

ログインユーザー
↓
所属テナントを確認
↓
アクセス可能なtenant_idを確定
↓
DB検索

という流れにします。

つまり、

tenant_idはユーザー入力ではなく、認証・認可済みのサーバー側情報から確定する

という考え方が重要です。

認証とテナント分離は別に考える

ログインに成功したからといって、すべてのデータへアクセスできるわけではありません。

例えば、

山田さん
↓
ログイン成功
↓
株式会社A所属

であれば、

株式会社Aのデータ
→ アクセス可能

株式会社Bのデータ
→ アクセス不可

です。

つまり、

認証

誰なのか。

テナント認可

どの会社へ所属しているのか。

RBAC

その会社の中で何ができるのか。

を分けて考えます。

マルチテナントとRBACを組み合わせる

同じ企業内でも全員が同じ権限とは限りません。

例えば、

株式会社A
↓
オーナー
管理者
一般ユーザー
閲覧ユーザー

という違いがあります。

オーナー

契約変更
メンバー管理
請求確認
全データ管理

管理者

メンバー管理
業務設定
データ編集

一般ユーザー

通常業務

閲覧ユーザー

閲覧のみ

という設計です。

このようなロールベースアクセス制御をRBACと呼びます。

SaaSでは、

テナント境界
＋
テナント内のRBAC

という2段階で考えることが重要です。

マルチテナントのデータベース設計例

例えば案件管理SaaSなら、次のようなテーブル構造が考えられます。

tenants

契約企業です。

id
name
status
created_at

users

ログインユーザーです。

id
email
name
created_at

tenant_members

ユーザーとテナントの関係です。

tenant_id
user_id
role
status

customers

顧客情報です。

id
tenant_id
name
email
created_at

projects

案件です。

id
tenant_id
customer_id
name
status
owner_user_id

subscriptions

SaaS契約情報です。

id
tenant_id
plan_id
status
current_period_start
current_period_end

このように、業務データだけでなく契約情報もtenant_idと紐付けます。

ユニーク制約にもtenant_idを含める

マルチテナントでは、ユニーク制約にも注意が必要です。

例えば商品コードを、

ABC001

として管理するとします。

A社もABC001という商品コードを使い、

B社もABC001を使う可能性があります。

そのため、

product_code

だけをUNIQUEにすると、B社が同じコードを登録できません。

そこで、

tenant_id
＋
product_code

の組み合わせをユニークにします。

つまり、

株式会社A × ABC001
→ 登録可能

株式会社B × ABC001
→ 登録可能

株式会社A × ABC001をもう一度
→ 登録不可

という設計です。

これは、

社員番号
顧客コード
商品コード
案件番号

などでもよく発生します。

インデックスにもtenant_idを考慮する

例えば案件一覧で、

SELECT *
FROM projects
WHERE tenant_id = ?
AND status = ?

という検索を頻繁に行うなら、

tenant_id
＋
status

など、実際の検索パターンに応じたインデックスを検討します。

マルチテナントでは多くの検索にtenant_idが含まれるため、インデックス設計にも影響します。

ただし、インデックスは増やせばよいわけではありません。

データ量、更新頻度、検索条件を見ながら決めます。

PostgreSQLのRLSを使う方法もある

PostgreSQLではRow Level Security（RLS）という仕組みを利用できます。

RLSを使うと、データベース側で、

「現在のテナントIDと一致する行だけ取得できる」

というルールを設定できます。

例えばアプリケーション側の実装ミスでtenant_id条件が抜けた場合でも、DB側でアクセスを制限できる構成を作れます。

マルチテナントの安全性を高める選択肢の一つです。

ただし、RLSを導入すれば自動的に安全になるわけではありません。

DB接続方法
管理者権限
バッチ処理
マイグレーション
テスト

なども含めて設計する必要があります。

ファイルストレージにもテナント分離が必要

マルチテナントで見落とされやすいのがファイルです。

例えば、

契約書
見積書
商品画像
添付ファイル
CSV
PDF

などをS3などのオブジェクトストレージに保存するとします。

DBではtenant_idを分けていても、

files/document.pdf

のように保存しているだけでは不十分です。

例えば、

tenants/100/contracts/abc.pdf

tenants/200/contracts/xyz.pdf

のように、テナント単位で保存場所を整理する方法があります。

さらにダウンロード時にも、

「そのユーザーが該当テナントへ所属しているか」

を確認する必要があります。

DBだけではなく、ファイル・キャッシュ・検索インデックスなどもテナント境界を意識します。

キャッシュでもデータ混在に注意する

例えば顧客一覧をキャッシュするときに、

customers:list

というキーだけを使ったとします。

A社が検索
↓
A社顧客一覧をキャッシュ

その後B社が検索
↓
同じキーからA社データ取得

となれば重大な問題です。

そのため、

tenant:100:customers:list

tenant:200:customers:list

のようにテナントを含めたキャッシュキーを利用します。

マルチテナント設計では、DB以外のすべてのデータ保存先でも同じ考え方が必要です。

バックグラウンド処理にもtenant_idを持たせる

例えば、

メール送信
CSV生成
PDF作成
AI分析
月次集計

などをバックグラウンドジョブとして実行する場合があります。

ジョブデータにも、

tenant_id

を持たせます。

例えば、

job_id
tenant_id
user_id
target_id

などです。

バックグラウンド処理ではログインセッションが存在しないことも多いため、明示的なテナント情報が重要になります。

SaaSのURLでテナントを分ける方法

テナントを識別する方法としてURLを利用する場合もあります。

例えば、

サブドメイン

company-a.example.com

company-b.example.com

パス

example.com/company-a/

example.com/company-b/

ログイン後に切り替え

app.example.com

へアクセスし、ログイン後にテナントを選択します。

どの方式でも、URLだけでアクセス許可を判断してはいけません。

company-a

という文字列をURLへ入力しただけでA社へアクセスできないよう、必ずサーバー側で所属確認を行います。

テナント作成時のオンボーディングを設計する

新しい企業が契約したときには、

企業登録
↓
テナント作成
↓
初期管理者作成
↓
料金プラン設定
↓
初期設定
↓
利用開始

という流れがあります。

例えば、

企業名を登録
tenantsへレコード作成
契約者をownerとしてtenant_membersへ追加
subscriptionを作成
初期マスターを登録
招待メール送信

などです。

SaaSでは、企業追加を開発会社が手作業で行うのではなく、自動化できる構造にしておくと拡張しやすくなります。

テナントごとの設定をどう管理するか

SaaSでは企業ごとに設定を変えたいことがあります。

例えば、

A社
→ 承認機能あり

B社
→ 承認機能なし

C社
→ 独自ロゴ表示

などです。

このような場合、

tenant_settings

などで企業ごとの設定を管理する方法があります。

ただし、顧客ごとの特殊仕様を大量に追加すると、

A社の場合
B社の場合
C社の場合

という条件分岐だらけになります。

SaaSとしてスケールさせたい場合は、

「個別カスタマイズ」

より、

「設定可能な標準機能」

として設計できないか検討することが重要です。

Feature Flagで機能差を管理する

例えばEnterpriseプランだけ新しい分析機能を利用できるようにする場合、

tenant_features

などで機能の有効・無効を管理する方法があります。

例えば、

tenant	feature	enabled
A社	ai_analysis	true
A社	api	false
B社	ai_analysis	true
B社	api	true

という構造です。

これにより、

料金プラン
＋
個別契約
＋
段階リリース

などに対応しやすくなります。

契約プランもテナント単位で管理する

BtoB SaaSでは一般的に、

ユーザー
→ 契約

ではなく、

テナント
→ 契約

です。

例えば、

株式会社A
↓
Proプラン
↓
20ユーザー

という構造です。

そのためsubscriptionsはuser_idではなくtenant_idと紐付けることを検討します。

さらに、

最大ユーザー数
ストレージ上限
API利用回数
AI利用回数

などもテナント単位で管理することがあります。

利用量もテナント単位で集計する

例えば料金プランが、

Standard
→ 月1,000回までAI利用可能

の場合です。

20人のユーザーがそれぞれ1,000回使えるのではなく、

株式会社A全体で1,000回

という契約かもしれません。

その場合、

tenant_id
＋
利用期間
＋
利用量

で集計します。

SaaSでは「ユーザー単位」と「契約企業単位」を混同しないことが重要です。

テナント削除・解約時のデータをどうするか

契約企業が解約したときも設計が必要です。

例えば、

解約申請
↓
契約期間終了
↓
ログイン停止
↓
30日間データ保持
↓
データ削除

というルールです。

検討項目には、

即時利用停止か
契約期間終了まで利用可能か
データ保持期間
再契約時の復元
バックアップ上のデータ
法的な保存義務

などがあります。

単純にtenantsレコードを削除するだけではありません。

テナントを物理削除するか論理削除するか

例えばtenantテーブルに、

status = active

status = suspended

status = canceled

などの状態を持たせる方法があります。

契約終了後すぐに物理削除せず、

解約済み
↓
ログイン不可
↓
一定期間保持
↓
完全削除

とする設計もあります。

ただし、個人情報などの削除ルールはサービスの利用規約や法的要件も確認して決める必要があります。

SaaS運営者の管理画面は特に注意する

SaaSには、利用企業側とは別にサービス運営者向けの管理画面が必要になることがあります。

例えば、

テナント一覧
契約状況
利用人数
障害調査
サポート対応

などです。

ここで、

「運営者だから全企業のデータを自由に閲覧できる」

という設計にすると、強い権限が集中します。

そのため、

運営管理者
サポート担当
請求担当

などのロールを分けたり、顧客データへの代理アクセスを限定したりする方法があります。

サポート目的の代理ログインにも証跡を残す

例えば顧客から、

「画面がおかしいので確認してください」

と言われた場合、サポート担当が顧客テナントへ代理ログインする機能を用意するケースがあります。

便利ですが、非常に強い機能です。

そのため、

誰が
どのテナントへ
いつ
何の目的で
どの操作を行ったか

を記録できるようにします。

必要に応じて顧客側の承認を求める設計も考えられます。

マルチテナントSaaSのテストで確認したいこと

テナント分離は自動テストでも重点的に確認したい部分です。

例えば、

テスト1

A社ユーザーがA社案件を取得できる
→ 成功

テスト2

A社ユーザーがB社案件IDを指定する
→ 拒否

テスト3

A社ユーザーがB社顧客を更新する
→ 拒否

テスト4

A社ユーザーがB社ファイルURLへアクセスする
→ 拒否

テスト5

A社ユーザーがリクエストのtenant_idを書き換える
→ 拒否

というテストです。

単純な正常系だけでなく、意図的に別テナントへアクセスするテストを用意することが重要です。

【チェックリスト】マルチテナントSaaSの設計

SaaS開発前には、次の項目を整理してみてください。

テナント

テナントとは企業か組織か：
1ユーザーが複数テナントへ所属するか：
テナント切り替えは必要か：
テナント削除方法：

データ分離

tenant_id方式：
スキーマ分離：
DB分離：
ファイル分離：
キャッシュ分離：

ユーザー

オーナー：
管理者：
一般ユーザー：
閲覧ユーザー：
招待機能：

権限

RBACを使うか：
テナント管理者の権限：
SaaS運営者の権限：
代理ログイン：

契約

テナント単位の料金プラン：
ユーザー数上限：
利用量上限：
無料トライアル：
解約処理：

データベース

tenant_id：
複合ユニーク制約：
インデックス：
RLS：
バックアップ：

運用

テナント新規作成：
利用停止：
解約：
データ削除：
操作ログ：

マルチテナントSaaSでよくある設計ミス

1．すべてのテーブルにtenant_idを付ければ完成だと考える

tenant_idは重要ですが、それだけでは不十分です。

API
ファイル
キャッシュ
バックグラウンド処理
検索インデックス

などもテナント単位で分離する必要があります。

2．フロントエンドから渡されたtenant_idを信用する

ユーザーはリクエスト内容を書き換えられます。

必ずログインユーザーの所属情報をサーバー側で確認します。

3．ユーザーとテナントを1対1で固定する

最初は問題なくても、

「一人が複数組織へ所属したい」

という要件が追加される場合があります。

サービスの特性によっては中間テーブルを利用した設計を検討します。

4．プランとユーザー権限を混同する

Proプランだからといって、その企業の全ユーザーが管理者である必要はありません。

料金プランによる機能制限と、組織内のRBACは分けて考えます。

5．顧客ごとの条件分岐を増やしすぎる

「A社だけこの処理」

「B社だけこの画面」

を増やすと、SaaSのコードが複雑になります。

可能であれば設定・Feature Flag・標準機能として吸収できないか検討します。

6．一覧検索ではtenant_idを付けるが詳細取得で忘れる

例えば一覧では、

WHERE tenant_id = 100

としていても、

GET /projects/123

の詳細取得時にproject_idだけで検索してしまうケースです。

IDを直接指定するAPIでも、

project_id
＋
tenant_id

で確認する必要があります。

マルチテナントSaaSに関するよくある質問

マルチテナントとは簡単にいうと何ですか？

一つのSaaSを複数の契約企業・組織が利用し、それぞれのデータを分離して管理する構成です。

BtoB SaaSでは、契約企業を「テナント」として扱うケースが多くあります。

マルチテナントでは必ずtenant_idが必要ですか？

データ分離方式によります。

同じテーブルを複数テナントで共有する方式ではtenant_idを利用するのが代表的です。

テナントごとにDBを完全分離する場合などは別の設計もあります。

tenant_id方式は安全ですか？

適切に設計すれば広く利用できる方式ですが、検索条件の付け忘れなどを防ぐ必要があります。

アプリケーションの共通化、RLS、テストなど複数の対策を組み合わせることが重要です。

テナントごとにDBを分けるべきですか？

必ずしも必要ではありません。

顧客数、セキュリティ要件、バックアップ要件、運用コストなどを考慮して判断します。

小〜中規模SaaSでは共有DB＋tenant_id方式が適するケースもあります。

SaaSでユーザーが複数企業へ所属する場合はどう設計しますか？

usersとtenantsを直接1対多にせず、tenant_membersなどの中間テーブルで多対多にする方法があります。

これにより、一人のユーザーを複数テナントへ所属させられます。

テナント内の管理者権限はどう管理しますか？

tenant_membersなどにroleを持たせ、owner、admin、member、viewerなどを設定する方法があります。

より複雑な権限が必要な場合はRBACとしてrolesやpermissionsを分離します。

SaaS運営会社はすべてのテナントデータを見られるようにすべきですか？

必ずしもそうする必要はありません。

サポートや保守に必要な範囲で権限を分け、強い権限を持つ操作についてはログを記録する設計が重要です。

hiro-dev-labではマルチテナントSaaSの設計段階から相談できます

マルチテナントSaaSでは、

「ログイン機能を作る」

「tenant_idをテーブルへ追加する」

だけでは十分ではありません。

実際には、

契約企業
↓
ユーザー
↓
所属
↓
権限
↓
業務データ
↓
契約プラン
↓
利用量
↓
解約・データ削除

まで一貫して設計する必要があります。

hiro-dev-labでは、Webサービス・業務システム開発の観点から、

SaaSの要求整理
要件定義
テナントモデルの設計
マルチテナントDB設計
ユーザー・組織設計
RBAC・権限設計
認証・認可設計
料金プラン・契約管理設計
管理画面設計
API設計
Webサービス開発

など、必要な段階から相談できます。

例えば、

「法人向けSaaSを作りたいが、会社ごとのデータをどう分ければよいか分からない」

「tenant_id方式とDB分離のどちらがよいか判断できない」

「契約企業の中に複数ユーザーと管理者を作りたい」

「将来的に数百社・数千社へ提供できる構成にしたい」

といった段階でも、想定する顧客数・データ量・運用方法を整理することで適切な構成が見えてきます。

マルチテナントSaaSで最も重要なのは、単に複数企業を登録できることではありません。

どの処理を実行してもテナント境界が崩れず、契約企業ごとのデータ・権限・設定を安全に管理できる仕組みを設計することが重要です。