SaaSのマルチテナント設計で最初に決めるべきことは、顧客企業（テナント）ごとのデータをどう分けるかです。方式は大きく三つあります。顧客企業ごとにデータベースを分ける「DB分離」、一つのデータベースの中で区画を分ける「スキーマ分離」、同じ表の中で顧客企業を識別する「行レベル分離」です。どれか一つが常に正しいわけではなく、顧客企業の規模、取引先から求められるセキュリティの水準、想定する顧客数、運用できる体制によって、適した方式が変わります。
判断の目安を先に示すと、中小企業や個人事業主向けで多数の顧客を効率よく抱えたいなら行レベル分離、大企業向けで顧客数は限られ、データの物理的な分離を求められるならDB分離、その中間ならスキーマ分離や、方式の組み合わせが候補になります。そして、どの方式を選んでも、「アクセスのたびに必ず顧客企業を確かめる仕組み」を個々の画面の実装に任せず、共通の仕組みとして強制することが、事故を防ぐうえで最も大切です。
この記事は、自社SaaSの開発を検討している事業責任者や、開発会社からマルチテナントの設計方針の提案を受けて判断に迷っている担当者に向けて書いています。三つの方式の違い、選び方の判断基準、実装時の注意点、具体例、よくある失敗を順に説明します。
マルチテナント設計とは：何を決める設計か
マルチテナントとは、一つのシステムを複数の顧客企業で共有しながら、それぞれのデータや設定を互いに見えないように分けて提供する仕組みです。マンションにたとえると、建物（システム）は共有しながら、各部屋（顧客企業）には鍵がかかっていて、他の部屋には入れない状態です。
マルチテナント設計で決めることは、主に次の四つです。
- データの分離方式：顧客企業ごとのデータを、どの単位で分けて保存するか。
- アクセスの制御：利用者がデータにアクセスするとき、その人が所属する顧客企業のデータだけに限定する仕組み。
- 顧客企業ごとの設定：表示や機能、上限などを顧客企業ごとに変える仕組み。
- 運用の単位：バックアップ、復旧、データの削除、更新作業を、顧客企業ごとに行えるか、全体でまとめて行うか。
この中で、後から変えるのが最も難しいのがデータの分離方式です。分離方式を変えるには、すべてのデータの移し替えと、データにアクセスする処理の大部分の見直しが必要になります。SaaS開発全体の中での位置づけは自社SaaSを開発する手順で解説していますが、開発の最初に決めるべき事項です。
3つのデータ分離方式の違い
三つの方式を、主な観点で比べます。
| 観点 | DB分離 | スキーマ分離 | 行レベル分離 |
|---|---|---|---|
| 分け方 | 顧客企業ごとに別のデータベース | 一つのデータベースの中で顧客企業ごとに区画を分ける | すべての顧客企業のデータを同じ表に入れ、行ごとに顧客企業を識別 |
| 分離の強さ | 最も強い | 中程度 | 仕組み次第（実装の確実さに依存） |
| 他社のデータが見える事故の起きにくさ | 起きにくい | 比較的起きにくい | 識別の確認漏れがあると起きうる |
| 顧客が増えたときの運用負荷 | 大きい（データベースの数だけ管理が増える） | 中程度（区画の数だけ更新作業が増える） | 小さい |
| 顧客ごとのバックアップ・復旧 | しやすい | 比較的しやすい | 工夫が必要 |
| 顧客ごとのデータの削除・返却 | しやすい | 比較的しやすい | 工夫が必要 |
| 構造の変更（項目の追加など） | データベースの数だけ反映が必要 | 区画の数だけ反映が必要 | 一度で済む |
| サーバー費用の効率 | 低くなりやすい | 中程度 | 高い |
| 向いている場面 | 大企業向け、顧客数が限られる、物理的な分離を求められる | 中規模の顧客が中心、ある程度の分離の強さが必要 | 中小企業・個人向け、多数の顧客、効率重視 |
DB分離
顧客企業ごとに独立したデータベースを用意する方式です。顧客企業同士のデータが物理的に分かれているため、他社のデータが見えてしまう事故は起きにくくなります。顧客ごとのバックアップや復旧、契約終了時のデータの削除や返却も、データベース単位で行えるため明快です。一方、顧客が増えるたびにデータベースが増え、構造の変更や更新作業をすべてのデータベースに反映する必要があるため、運用の手間と費用が増えます。
スキーマ分離
一つのデータベースの中に、顧客企業ごとの区画（スキーマ）を作る方式です。DB分離ほどではないものの、区画で分かれているため分離は比較的強く、データベースそのものの数は増えないため運用の負荷はDB分離より小さくなります。ただし、構造を変更するときには区画の数だけ反映が必要で、顧客数が非常に多くなると管理が難しくなります。
行レベル分離
すべての顧客企業のデータを同じ表に保存し、各行に「どの顧客企業のデータか」を示す識別子を持たせる方式です。顧客が増えてもデータベースや区画が増えないため、運用の効率とサーバー費用の効率に優れます。多数の中小企業を顧客とするSaaSでよく採用されます。その代わり、データを読み書きするすべての処理で、顧客企業の識別子による絞り込みを確実に行う必要があり、一か所でも漏れると他社のデータが見える事故につながります。
方式を選ぶ判断基準と手順
方式を選ぶときは、次の四つの観点から自社の条件を整理します。
| 観点 | DB分離寄りになる条件 | 行レベル分離寄りになる条件 |
|---|---|---|
| 顧客企業の規模 | 大企業が中心。一社あたりのデータ量が大きい | 中小企業・個人が中心。一社あたりのデータ量は小さい |
| セキュリティの要求 | 取引先から物理的な分離や、専用の環境を求められる | 論理的な分離と、その仕組みの説明で足りる |
| 想定する顧客数 | 数社から数十社程度 | 多数の顧客企業を効率よく抱えたい |
| 運用の体制 | 顧客ごとの環境を管理できる体制がある | 少人数で全体を一括して運用したい |
これをもとに、次の手順で判断します。
- 最初の顧客像を具体的にする：どの規模の会社に、何社くらい使ってもらう想定かを書き出します。
- 想定顧客のセキュリティ要求を確かめる：営業先の候補にヒアリングし、データの分離についてどこまで求められそうかを確認します。チェックシートでどう問われるかは取引先のセキュリティチェックシートへの対応で整理しています。
- 数年後の顧客数を想定する：事業計画上、顧客数がどこまで増えるかを考え、その時点の運用負荷を見積もります。
- 運用の体制を確認する：顧客ごとのデータベースや区画の管理、更新作業を担える体制があるかを確認します。
- 方式を仮決めし、開発会社と弱点の対策を話し合う：選んだ方式の弱点（行レベル分離なら識別の漏れ、DB分離なら運用の手間）にどう備えるかを具体的に決めます。
- 将来の方式の組み合わせの余地を確認する：特定の大口顧客だけ専用の環境を用意する、といった将来の選択肢を残せるかを確認します。
方式を組み合わせる選択肢
実務では、方式を組み合わせることもあります。たとえば、多数の中小企業の顧客は行レベル分離で共有の環境に収容し、高いセキュリティを求める大企業の顧客だけは、専用のデータベースを用意する、という形です。この場合、同じソースコードで両方の環境を動かせる設計にしておくことが前提になります。最初から組み合わせる必要はありませんが、将来その選択肢を残せるように、顧客企業の識別とデータベースの接続先の決め方を共通化しておくと、後から対応しやすくなります。
行レベル分離で事故を防ぐ実装の注意点
行レベル分離は効率に優れる一方、実装の確実さがすべてです。開発会社に確認したい注意点を挙げます。
- 絞り込みを共通の仕組みで強制する：画面や処理ごとに開発者が「顧客企業で絞り込む」条件を書く作りにすると、必ずどこかで漏れが出ます。データにアクセスする共通の層で、顧客企業による絞り込みを自動的にかける仕組みにします。
- データベースの機能で二重に守る：PostgreSQLなど一部のデータベースには、行ごとにアクセスを制限する機能（行レベルセキュリティ）があります。アプリケーション側の仕組みに加えてデータベース側でも制限をかけると、万一の漏れを防ぐ二重の守りになります。採用するかどうかは、性能や運用への影響と合わせて開発会社と検討してください。
- すべての表に顧客企業の識別子を持たせる：一部の表にだけ識別子がないと、そこから他社のデータに到達する経路ができます。顧客企業に属するデータを持つ表には、例外なく識別子を持たせます。
- ファイルや検索の仕組みも分ける：データベースだけでなく、アップロードされたファイルの保存場所、検索用の仕組み、キャッシュ（一時保存）にも顧客企業の区別を持たせます。見落とされやすい部分です。
- テストで他社のデータが見えないことを確かめる：複数の顧客企業のテストデータを用意し、ある顧客企業の利用者で、他社のデータにアクセスできないことを自動テストで確かめます。
- 運営者のアクセスを記録する：運営者が顧客企業のデータを見る機能は、誰がいつ見たかを記録します。記録の考え方は監査ログの用語ページで解説しています。
DB分離・スキーマ分離での注意点
DB分離やスキーマ分離でも、注意すべき点はあります。
- 更新作業の自動化：構造の変更をすべてのデータベースや区画に反映する作業を、手作業ではなく自動化します。反映漏れがあると、一部の顧客だけ不具合が起きる原因になります。
- 接続先の決め方：利用者がログインしたとき、どの顧客企業のデータベースや区画に接続するかを決める仕組みを、確実に作ります。ここを誤ると、別の顧客企業のデータに接続してしまいます。
- 全体の集計：運営者が全顧客企業の利用状況を集計したいとき、データが分かれていると集計の仕組みが別途必要になります。
一部の顧客の負荷が全体に響く問題
資源を共有する方式では、ある顧客企業が大量のデータを一度に取り込んだり、重い集計を繰り返したりすると、同じ環境を使う他の顧客企業の画面まで遅くなることがあります。共有の度合いが高い行レベル分離ほど、この影響を受けやすくなります。対策としては、一度に処理できる量に上限を設ける、重い処理は利用者の操作と切り離して順番に処理する、利用量の多い顧客企業を把握できるように監視する、といった方法があります。プランごとに利用量の上限を決めておけば、料金と負荷の両面で釣り合いを取りやすくなります。この問題は、顧客が少ない最初のうちは表面化しにくいため、設計の段階で意識しておくことが大切です。
具体例：架空の二つのSaaSの方式選び
例1：飲食店向けのシフト管理SaaS
架空の例として、個人経営の飲食店や小規模なチェーンを対象に、スタッフのシフト管理を提供するSaaSを考えます。想定する顧客は多数の小規模事業者で、一社あたりのデータ量は小さく、取引先から物理的なデータ分離を求められる可能性は低いと見込まれました。運用は少人数で行いたいという条件もありました。
この条件から、行レベル分離を選びました。そのうえで、データアクセスの共通の層で顧客企業による絞り込みを強制し、データベース側の行レベルセキュリティでも二重に守る設計にしました。スタッフの写真などのファイルも、保存場所を顧客企業ごとに分けました。複数の店舗のテストデータを用意し、他の店舗のシフトが見えないことを自動テストで確かめる仕組みも、最初の版から組み込みました。
例2：医療機関向けの文書管理SaaS
別の架空の例として、中規模以上の医療機関を対象に、文書の管理を提供するSaaSを考えます。想定する顧客数は多くなく、扱う情報の性質から、顧客からデータの物理的な分離や、契約終了時の確実なデータの削除を求められることが予想されました。
この条件から、DB分離を選びました。顧客ごとにデータベースを用意し、バックアップと復旧、契約終了時の削除を顧客単位で行えるようにしました。運用の手間を抑えるため、新しい顧客の環境の作成と、構造の変更の反映を自動化しました。全顧客の利用状況を把握するために、各データベースから必要な情報だけを集める集計の仕組みを別に用意しました。
二つの例で方式は違いますが、どちらも「顧客像とセキュリティの要求、顧客数、運用の体制」から逆算して選んでいる点は共通しています。
よくある失敗とその避け方
- 流行や開発会社の慣れだけで方式を選ぶ：顧客像やセキュリティの要求を確かめずに選ぶと、後で大口顧客の要求に応えられなかったり、運用負荷に耐えられなくなったりします。四つの観点で条件を整理します。
- 絞り込みを個々の実装に任せる：行レベル分離で最も多い事故の原因です。共通の仕組みで強制します。
- ファイルやキャッシュの分離を忘れる：データベースは分けていても、ファイルの保存場所や一時保存の仕組みで他社のデータが見えることがあります。
- 構造の変更を手作業で反映する：DB分離やスキーマ分離で反映漏れが起き、一部の顧客だけ不具合が出ます。自動化します。
- 最初から過剰な分離を選ぶ：顧客数が増える見込みなのに、念のためとDB分離を選ぶと、運用の負荷と費用が膨らみます。将来の組み合わせの余地を残す設計の方が合理的な場合もあります。
- 顧客ごとの削除や返却を考えていない：契約終了時に、その顧客企業のデータだけを確実に削除・返却できるかは、セキュリティ審査でよく問われます。方式ごとの方法を決めておきます。
マルチテナント設計のチェックリスト
- 最初の顧客像（規模、顧客数、業種）を具体的にした
- 想定顧客のセキュリティ要求を確かめた
- 数年後の顧客数と、そのときの運用負荷を想定した
- 四つの観点から分離方式を選び、その理由を説明できる
- 顧客企業による絞り込みを共通の仕組みで強制している
- ファイル、検索、一時保存にも顧客企業の区別を持たせた
- 他社のデータにアクセスできないことを自動テストで確かめている
- 顧客企業ごとのバックアップ・復旧・削除・返却の方法を決めた
- 運営者による顧客データへのアクセスを記録している
- 将来、大口顧客だけ専用環境にする選択肢を残せるかを確認した
よくある質問
Q. 最初は行レベル分離で始めて、後からDB分離に変えることはできますか？
不可能ではありませんが、データの移し替えと、データにアクセスする処理の見直しが必要になり、大きな作業になります。全体を変えるより、特定の大口顧客だけを専用の環境に移す、という形の方が現実的です。そのためにも、最初から顧客企業の識別と接続先の決め方を共通化しておくことをおすすめします。
Q. 行レベル分離は、セキュリティ審査で不利になりますか？
一概に不利とは言えません。多くのSaaSが行レベル分離を採用しています。大切なのは、どのような仕組みで分離を確実にしているか（共通の層での強制、データベース側での二重の制限、自動テストなど）を具体的に説明できることです。ただし、取引先の基準によっては物理的な分離を求められることもあるため、想定顧客の要求を事前に確かめてください。
Q. 顧客企業ごとに機能や画面を変えたい場合、方式の選び方は変わりますか？
顧客企業ごとの違いが、項目の表示や機能のオンとオフ程度であれば、どの方式でも設定として持たせることで対応できます。顧客ごとに業務の流れやデータの構造まで大きく変える必要があるなら、そもそも一つのSaaSとして提供するのが適切かを含めて検討が必要です。
Q. 権限の設計とマルチテナント設計は別のものですか？
関連していますが、別のものです。マルチテナント設計は顧客企業同士の分離、権限の設計は顧客企業の中での利用者ごとのアクセスの範囲を扱います。両方を組み合わせて初めて、安全なアクセス制御になります。顧客企業の中の権限についてはSaaSの組織管理機能の設計で解説しています。
Otsumuに相談できること
想定する顧客像とセキュリティの要求がはっきりしていて、社内にSaaSの設計経験がある技術者がいる場合は、この記事の判断基準とチェックリストを使って、自社で方式を選び、実装の注意点を押さえながら進めることができます。特に、絞り込みを共通の仕組みで強制するという原則は、どの方式を選んでも守るべきものです。
一方で、中小企業向けと大企業向けの両方を狙っていて方式を決めきれない場合や、開発会社から提案された方式が自社の顧客像に合っているか判断できない場合、すでに公開しているSaaSで顧客の増加や大口顧客の要求に今の方式が耐えられるか不安がある場合は、設計と事業の両方の視点を持つ外部の意見が役に立ちます。分離方式は後から変えにくいため、最初の判断に時間をかける価値があります。
Otsumuは、SaaSの顧客像と事業計画から逆算して、マルチテナントの方式を含む土台の設計を行い、AIを活用した少人数・短期間の開発で最初の版を形にしています。自社SaaSの開発はSaaS開発、既存のシステムの見直しを含む場合はシステム開発をご覧ください。
開発会社の提案書や、想定している顧客像をもとに、方式の選択が条件に合っているかを一緒に確認することもできます。まずは30分の無料相談でお気軽にご相談ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01