マルチテナントとは
マルチテナントとは、一つのアプリケーションとインフラを複数の顧客企業で共有しつつ、それぞれの顧客のデータや設定は互いに見えないよう分けて提供するシステム構成のことです。
平易に言えば「一棟のマンションに複数の世帯が住んでいる状態」です。建物（サーバーやプログラム）は共通でも、各部屋（顧客ごとのデータ）には鍵がかかっていて、隣の部屋には入れません。ここでいう「テナント」は、SaaSを契約した一社一社、つまり入居者にあたります。
反対に、顧客ごとに専用のシステム一式を用意する構成を「シングルテナント」と呼びます。業務SaaSの多くは、運用の手間とコストを抑えるためにマルチテナントで作られています。
仕組み・ポイント
マルチテナントの設計で最初に決めるのは、データをどの単位で分けるかです。代表的な方式は三つあります。
| 方式 | 分け方 | 向いている場面 | 注意点 |
|---|---|---|---|
| 行で分ける（共有DB・共有テーブル） | 全テーブルにテナントIDを持たせる | 小規模な顧客が多数いるSaaS | 条件の付け忘れが情報漏えいに直結する |
| スキーマで分ける | 同じDB内でテナントごとに領域を分ける | 顧客数が中程度で分離も重視したい | 構造変更を全スキーマに反映する手間 |
| DBで分ける | テナントごとに別のデータベース | 大企業顧客や厳しい分離要件 | 運用対象が増え、コストも上がる |
方式は一つに決め打ちする必要はなく、通常の顧客は共有方式、特別な要件のある大口顧客だけは専用DB、という混在も可能です。ただし混在させるほど運用は複雑になります。
データ以外にも、テナント単位で考えるべき要素があります。
- 利用者とロール：同じ人が複数のテナントに所属するか
- 設定：ロゴ、項目名、通知先など顧客ごとに変えたいもの
- 認証：顧客ごとにSSO（シングルサインオン）を設定させるか
- 料金：プランや利用量をテナントごとに管理する
- 性能：一社の大量処理が他社を遅くしないか
実務での使い方・具体例
ある会社が、自社で使っていた案件管理の仕組みを、同業他社にも提供するSaaSにしようとしている場面を考えます。最初は自社専用に作られているため、テーブルに「会社」という概念がありません。
この場合の進め方は次のようになります。
- すべてのデータに「どのテナントのものか」を表す列を追加する
- ログインした利用者がどのテナントに属するかを判定する仕組みを作る
- データを読み書きする処理すべてで、テナントの条件が必ず付くようにする（共通部品や、データベース側の行単位のアクセス制御を使う）
- テナントをまたいで見えてしまわないかを確かめる自動テストを用意する
- 顧客の招待、利用停止、解約時のデータ削除の手順を決める
特に3と4が肝心です。画面一つ、APIひとつで条件を付け忘れると、他社のデータが表示されてしまいます。仕組みで漏れを防ぎ、テストで確認する二重の備えが必要です。
もう一つ、運用面で早めに決めておきたいのが「顧客ごとの違いをどこまで認めるか」です。項目名の変更や帳票のロゴ差し替えのように設定画面で吸収できる違いと、業務フローそのものが異なる違いとでは、扱いがまったく変わります。前者は設定値としてテナントごとに保存し、後者は原則として製品の標準機能に寄せてもらう、という線引きを営業段階から共有しておくと、受注のたびに個別開発が積み重なる事態を防げます。
利用量の偏りにも備えます。特定の顧客が大量のデータ取り込みや集計を行うと、同じ基盤を使う他の顧客まで遅くなることがあります。重い処理は順番待ちの仕組みに回す、テナントごとに同時実行数の上限を設けるなど、一社の負荷が全体に波及しない作りにしておくと安心です。
よくある誤解と注意点
- マルチテナントは後から足せる、と考えがち：既存システムを後からマルチテナント化すると、ほぼ全ての処理に手が入ります。SaaS化の可能性があるなら、最初からテナントの概念を入れておく方が安く済みます。
- 大口顧客の要望で専用化が増えていく：個別対応を重ねると、事実上のシングルテナントが並ぶ状態になり、保守が重くなります。設定で吸収できる範囲を先に決めておきます。
- バックアップと復元の単位：一社分だけ過去の状態に戻したい、という依頼は意外と多いものです。共有DB方式ではこれが難しくなるため、復元の要件を先に確認します。
- セキュリティ審査で問われる：法人顧客のセキュリティチェックでは、データ分離の方式を説明できることが求められます。
関連用語
- RBAC（ロールベースアクセス制御）：テナント内で「誰が何をできるか」を役割で決める仕組み
- SSO（シングルサインオン）：法人顧客から要望されやすい、自社認証基盤でのログイン
- 監査ログ：テナントごとの操作履歴。法人向けSaaSで求められやすい
- データベース設計：テナント分離方式の選択はデータベース設計の中心課題
- 実践記事：SaaSのマルチテナント設計：データ分離方式の選び方と注意点
Otsumuに相談できること
自社SaaSの立ち上げや、社内システムのSaaS化では、マルチテナントの設計が後々の保守費用と信頼性を左右します。想定する顧客層や分離要件を伺い、最初の版に必要な範囲と後回しにできる範囲を分けて設計します。詳しくはSaaS開発をご覧ください。
30分の無料相談で、構想段階からご相談いただけます。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01