マルチテナント設計とは｜SaaSのテナント分離3方式と選び方

マルチテナントとは｜シングルテナントとの違い

マルチテナントとは、複数の利用組織が同一のシステム基盤を共有し、論理的に分離された状態でサービスを使う方式です。ここでいうテナントは、多くのB2B SaaSでは「契約している顧客企業」の単位にあたります。

対になるのがシングルテナントです。顧客ごとに独立した環境を丸ごと用意する方式で、オンプレミス納品やプライベートクラウド提供がこれに近い形になります。

共有する範囲は連続的に変わる

マルチテナントかシングルテナントかは、二択ではありません。実際には「どこまでを共有するか」の連続的な選択です。

アプリケーションのプロセス、データベースインスタンス、スキーマ、テーブル、ストレージのバケット。この階層のどこに境界線を引くかで、コストとセキュリティのバランスが決まります。

シングルテナントとの比較

ミニFAQ：マルチテナントとマイクロサービスは関係ありますか

別の軸の話です。マルチテナントは「誰のデータをどう分けるか」、マイクロサービスは「アプリケーションをどう分割するか」を扱います。両立もしますし、モノリスのままマルチテナント化することもできます。サービス分割の判断はマイクロサービスとは｜モノリスとの違い・採用判断・案件動向を解説で整理しています。

テナント分離の3方式｜サイロ・ブリッジ・プール

分離方式は、AWSやMicrosoftのSaaS設計ガイダンスで使われるサイロ・ブリッジ・プールの3分類で整理すると見通しがよくなります。Microsoftのマルチテナント SaaS パターンでも、同じ考え方が別の呼び名で説明されています。

サイロモデル（テナントごとに独立）

テナントごとに専用のデータベース、場合によってはインスタンスやアカウントごと分ける方式です。

分離は構成そのもので担保されるため、監査で「他テナントから見えないこと」を示しやすくなります。テナント単位のバックアップやリストアも素直に実行できます。

一方で、テナント数が増えるほど接続数・監視対象・マイグレーション実行回数が線形に増えます。DB・監視・デプロイをテナント単位で持つ構成では、数十規模になると運用の手数が無視しにくくなる傾向があります。どこで重くなるかは、環境構築の自動化がどこまで進んでいるかで変わります。

ブリッジモデル（スキーマや一部リソースを分ける）

データベースインスタンスは共有し、テナントごとにスキーマを分ける構成が代表例です。中間的な選択肢として位置づけられます。

インフラコストはサイロより抑えられ、テーブル定義はテナントごとに独立します。ただしスキーマ数が増えるとマイグレーションの実行対象が増えるため、運用負荷はプールより高くなります。

プールモデル（共有テーブル＋テナントID）

すべてのテナントが同じテーブルを共有し、各行にテナントIDを持たせて分離する方式です。多くのB2B SaaSがここから始めます。

リソース効率とスケーラビリティに優れ、マイグレーションは1回で済みます。その代わり、分離をアプリケーションとDBの実装で担保しなければなりません。絞り込み条件をひとつ書き忘れるだけで越境参照が起きるのがこの方式の急所です。

3方式の比較表

分離方式の選び方｜5つの判断軸

結論から言うと、判断は技術的な優劣ではなく事業要件から降りてきます。以下の5軸を順に確認すると、選択肢が絞れます。

軸1：規制・契約上の要件があるか

医療、金融、公共領域では「データを物理的に分離すること」が調達要件に書かれている場合があります。この条件があると、その顧客についてはサイロ以外の選択肢が消えます。

要件定義の段階で、契約書やセキュリティチェックシートの分離要件を確認しておくのが先決です。

軸2：テナント数はどのくらいを想定するか

テナントが数社〜十数社に留まるならサイロでも回ります。数百〜数千を見込むなら、プールを前提にしないと運用が破綻しやすくなります。

境界は事業モデルと自動化の成熟度で変わります。IaCによる環境構築の自動化が十分でないチームでは、数十規模になるとサイロの運用工数が無視しにくくなる傾向があります。特定の社数を絶対的な境界として扱わず、自社の自動化レベルとあわせて判断してください。

軸3：テナント間のデータ量に極端な偏りがあるか

1社だけが全体の大半のデータを持つ、という状態はプールモデルと相性がよくありません。クエリ性能が特定テナントに引きずられます。

この場合は、大口テナントだけサイロへ切り出すブリッジ的な運用が現実的です。

軸4：課金プランと分離レベルを紐づけるか

エンタープライズプランの付加価値として「専用インスタンス」を売る設計は珍しくありません。課金プランと分離レベルを対応づけると、コスト構造が説明しやすくなります。

逆に単一プランのプロダクトで方式を混在させると、運用が複雑になるだけで回収できないことがあります。

軸5：運用を回す人数は何人か

見落とされやすい軸です。サイロは分離こそ強いものの、監視・パッチ適用・マイグレーションの手数がテナント数に比例します。

運用担当が1〜2名の体制でテナント数十のサイロを抱えると、日常運用だけで手が埋まります。人数が少ないほどプール寄りに倒すのが実務的な判断です。

判断フロー

上の5軸を、実際の意思決定順に並べると次のようになります。

ミニFAQ：後から方式を変更できますか

可能ですが、コストは方向で大きく違います。プールからサイロへの切り出しは、対象テナントのデータを抽出して移すだけなので比較的やりやすい作業です。逆にサイロからプールへの統合は、テナントごとに分岐したスキーマ差分の吸収が必要になり、難易度が跳ね上がります。迷う段階ではプール側から始めたほうが、後戻りの選択肢が残ります。

マルチテナントDB設計の実装ポイント

プールモデルを採る場合、DB設計の巧拙がそのままセキュリティの強度になります。ここは案件面談でも踏み込んで聞かれる領域です。

テナントIDの持たせ方と主キー設計

テナントIDは、原則としてすべての業務テーブルに持たせます。中間テーブルや履歴テーブルも例外にしません。

親テーブルから辿れるから不要、という判断は避けたほうが無難です。テーブル結合を省いた集計クエリやバッチ処理で、テナント条件が抜けやすくなります。

複合主キーにするか、サロゲートキー＋テナントIDのインデックスにするかは、使うORMとの相性で決めるのが現実的です。いずれの場合も、テナントIDを先頭に置いた複合インデックスを用意しておくと、プールモデルのクエリ性能が安定します。

行レベルセキュリティでDB層に強制させる

PostgreSQLの行レベルセキュリティ（Row Level Security）を使うと、テナント条件をDB側で強制できます。適切なロール設計とポリシー設定が前提であれば、アプリケーションが絞り込み条件を書き忘れても、DBが行を返しません。接続ロールの権限、テーブル所有者の扱い、ポリシーを迂回できる権限属性の有無によって成立条件が変わる点は押さえておいてください。

仕組みと設定手順はPostgreSQL公式の行セキュリティポリシーに整理されています。SaaS文脈での設計例はAWSのPostgreSQL の行レベルのセキュリティを備えたマルチテナントデータの分離が参考になります。

導入時に押さえておく点は3つです。

1. テーブル所有者はデフォルトでポリシーを無視できる。所有者にもポリシーを強制する設定を明示するか、テーブル作成用ロールとアプリ接続用ロールを分ける

2. アプリケーションは必ず専用の非所有者ロールで接続する

3. CIのテストDBも本番と同じロール構成にする。管理ロールでテストすると、ポリシーが効いていない状態に気づけない

アプリ層とDB層の二重防御

行レベルセキュリティを入れたからアプリ側は無防備でよい、という話にはなりません。実務では両方に置きます。

アプリ層では、リクエスト受信時にテナントを特定し、リポジトリ層やORMのグローバルスコープでテナント条件を自動付与する形が扱いやすい構成です。DB層はその取りこぼしを受け止める最後の砦という位置づけになります。

レイヤ分割の考え方そのものはクリーンアーキテクチャとは｜4層構造とDDDの関係を実務目線で解説やドメイン駆動設計（DDD）とは｜戦略設計と戦術設計の使いどころで整理しています。

テナントの特定はトークンから行う

テナントIDをリクエストボディやクエリパラメータから受け取る実装は、そのままIDOR（他人のIDを指定すれば見えてしまう脆弱性）になります。

テナントは、認証済みトークンのクレームやセッションから決めます。1人のユーザーが複数テナントに所属しうるプロダクトでは、認証情報から許可されたテナントの候補を出し、その中から現在のコンテキストを確定する形にしてください。候補の検証を省くと、結局リクエスト由来の値を信用したのと同じことになります。JWTを使う場合の注意点はJWTとは｜仕組み・セッション認証との違い・実装の注意点、IDプロバイダを外部に置く場合はKeycloakとは｜Auth0・Oktaとの違いと導入判断が参考になります。

ミニFAQ：MySQLでも同じことができますか

MySQLにはPostgreSQLのRLSに相当するネイティブ機能がありません。VIEWと権限設計で部分的に近づけることはできますが、代替しきれない場面もあるため、アプリ層での強制とテストによる担保の比重が上がります。DBの選定基準そのものはPostgreSQLとは？特徴・MySQLとの違い・案件単価・将来性をフリーランス視点で解説、マネージドサービス側の違いはAWS RDSとは｜マネージドDBの基本・MySQL/PostgreSQLとの違い・案件単価をフリーランス視点で解説で比較しています。

よくある落とし穴と対策

ここからは、現場で繰り返し報告されている失敗パターンです。設計レビューのチェック項目として使えます。

落とし穴1：絞り込み条件の書き忘れ

最も頻出します。ORMのメソッドチェーンでスコープが外れる、手書きのクエリを書いた運用バッチで条件が抜ける、といった形で起きます。

対策は、テナント条件を個々のクエリに委ねないことです。ORMのグローバルスコープと行レベルセキュリティを組み合わせ、書き忘れても結果が返らない状態にします。

落とし穴2：VIEW経由の分離を検証していない

VIEWそのものが危険なわけではありません。問題になるのは、VIEWの所有者・実行権限と、security_invoker や security_barrier といった属性の設定次第で、元テーブルのポリシーが意図した主体に適用されないことがある点です。

既定ではVIEWは所有者の権限で実行されるため、VIEWの所有者が元テーブルのポリシー対象外だと、参照元のポリシーが効いていない状態になりえます。挙動の条件はPostgreSQL公式のビューの作成に関する記述に記載されています。

VIEWを使うなら、元テーブルのポリシーだけで安心せず、VIEW経由でも分離が保たれるかを実際のアプリ接続ロールでテストしてください。

落とし穴3：テーブル所有者がポリシーをバイパスする

前述のとおり、テーブル所有者はデフォルトでポリシーの対象外です。マイグレーション用ロールでアプリケーションを動かしてしまうと、RLSを入れたつもりで何も効いていない状態になります。

落とし穴4：接続プールでテナントコンテキストが混ざる

セッション変数にテナントIDを入れる実装では、コネクションプーリングとの組み合わせに注意が必要です。トランザクション単位でコネクションを使い回す設定の場合、設定漏れがあると前のリクエストのテナントコンテキストが残ります。

対策は、リクエストごとに必ずトランザクション内でテナントを設定するミドルウェアを用意し、設定されていない状態ではクエリを実行させないことです。

落とし穴5：ノイジーネイバー

1つのテナントの重いクエリや大量バッチが、他テナントのレスポンスを巻き込んで悪化させる現象です。プールモデル特有の課題になります。

テナントごとのAPIレート制限、重い処理のキュー分離、スロークエリのテナント別可視化で緩和します。監視のタグ付けについてはDatadogとは｜統合監視SaaSの特徴・Sentryとの違い・案件単価を徹底解説が参考になります。

落とし穴6：1テナントだけ戻せない

「先週の状態に戻してほしい」という要望は、B2B SaaSで実際に来ます。プールモデルでデータベース全体のスナップショットしか持っていないと、1社のためだけに全体を巻き戻すことはできません。

設計時に、論理エクスポートによるテナント単位の抽出手段か、アプリケーション側の論理削除・履歴テーブルを用意しておきます。

落とし穴7：マイグレーションが終わらない

サイロやブリッジでテナント数が増えると、マイグレーションの総実行時間がテナント数に比例して伸びます。1テナント30秒のマイグレーションでも、200テナントあれば100分かかる計算です。

並列実行と、失敗したテナントだけ再実行できる冪等な仕組みを最初から組んでおくと、後が楽になります。

落とし穴の検知方法まとめ

運用設計｜オンボーディング・マイグレーション・復旧

設計時にあまり議論されないまま本番を迎え、あとで効いてくるのが運用側です。

テナントオンボーディングの所要時間

プールモデルなら、テナントの作成は基本的にレコード追加なので数秒〜数分で完了します。サイロは、データベースやスキーマのプロビジョニングが入るため、自動化していても十数分程度かかる構成が一般的です。

無料トライアルからのセルフサインアップを提供するなら、待ち時間を極小化しやすい方式が有利です。サイロでも、非同期プロビジョニングや環境の事前確保で体験を成立させる設計はできます。

マイグレーション戦略

プールは1回で完了します。サイロ・ブリッジでは、テナントごとの実行になるため次の3点を決めておきます。

• 実行順序（カナリアとして特定テナントを先行させるか）

• 失敗時の扱い（そのテナントだけ止めるか、全体をロールバックするか）

• スキーマ差分の許容期間（全テナントが揃うまでアプリはどちらのスキーマでも動くか）

Infrastructure as Codeでテナント環境を定義しておくと、サイロの増設が扱いやすくなります。考え方はTerraformとは？IaCの仕組み・できること・フリーランス案件の単価をエンジニア視点で解説で整理しています。

復旧訓練は設計の一部

テナント単位のリストア手順は、書いただけでは動きません。リリース前に一度、実データに近いダミーで復旧訓練をしておくと、抽出スクリプトの穴が先に見つかります。

大きなスキーマ変更や、復旧経路に影響する変更の前には復旧手順を実際に流す。これだけで、事故時の判断がかなり楽になります。

ケース別の選び方

ケース1：シード期のB2B SaaS

テナント数は10社未満、開発者は2〜3名という段階です。プールモデル＋行レベルセキュリティから始めるのが扱いやすい構成になります。

この段階でサイロを選ぶと、機能開発に使える時間が運用に吸われます。分離要件が出た時点で個別に切り出せばよく、初期から全テナント分の環境を抱える必要はありません。

ケース2：エンタープライズ顧客が入ってきた

既存はプールで回っているが、大口顧客から専用環境やデータ所在地の指定を求められた、という状況です。

全体をサイロへ作り替えるのではなく、その顧客だけ切り出すブリッジ運用が現実的です。アプリケーションのコードは共通のまま、接続先の解決だけをテナント単位で切り替えられる構造にしておくと移行が軽くなります。

ケース3：医療・金融など規制のある業界

調達要件に物理分離が明記されていれば、その時点で選択肢は決まります。設計の議論よりも、要件定義でどこまでが必須条件かを確定させる作業が先です。

「論理分離で要件を満たせるか」を発注側と握れるかどうかで、その後のコスト構造が変わります。ここを曖昧にしたまま設計を進めるのが、この領域で最も高くつくパターンです。

ケース4：シングルテナント構成からの移行

既存顧客ごとに環境を立てていたプロダクトを、マルチテナント化する案件も一定数あります。

難所は、顧客ごとに分岐したスキーマとカスタマイズの吸収です。まずは差分の棚卸しから始め、共通化できるものと設定値として持つものを分類します。移行は一括ではなく、テナント単位で段階的に進める方式が定石です。

SaaS案件でマルチテナント設計はどう問われるか

SaaSプロダクトの開発案件では、マルチテナント設計は要件定義から実装まで広く関わる論点になります。主要フリーランスエージェント数社の公開案件を確認すると、SaaS基盤・認証基盤系の募集要件で「マルチテナント設計の経験」が挙げられているものが見られます。

面談で聞かれやすい質問

• 直近で関わったプロダクトはどの分離方式か。なぜその方式か

• テナント越境を防ぐために、どのレイヤで何をしていたか

• テナント単位のリストア要望にどう対応したか

• テナント数が増えたときに、最初に問題になったのはどこか

いずれも方式名ではなく判断根拠を問う質問です。採用した方式と、そのとき捨てた選択肢を言語化しておくと通りがよくなります。

単価感の目安

以下は、2026年9月時点で首都圏中心の主要フリーランスエージェント数社の公開案件ページを確認した範囲での目安です。SaaS・マルチテナントを明示した公開案件はまだ多くないため、観測ベースの参考値として読んでください。

• SaaSプロダクトのバックエンド開発（実装が主）：月60〜90万円前後の募集が中心

• アーキテクチャ設計や基盤刷新を含む役割：月80〜120万円前後の募集も見られる

後者のレンジで募集される案件は、実務経験5年以上で、SaaSプロダクトの設計から運用まで一貫して関わった経験があり、非機能要件をステークホルダーと詰められる人物像を想定した要件になっているケースが多いです。上記は公開案件ベースの数字で、非公開案件では個別条件により上下します。

自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？で整理しています。

SaaS企業側の契約形態や働き方の傾向はSaaSスタートアップのフリーランスエンジニア案件｜契約・単価・働き方を解説、認証基盤まわりの案件動向は認証基盤・IDaaSエンジニアのフリーランス案件動向｜単価・必要スキル・主要製品が参考になります。実際の募集はフリコンの案件一覧から確認できます。

設計レビュー用チェックリスト

設計が固まったタイミングで、以下を確認してください。

• 契約・規制上の分離要件を文書で確認したか

• 想定テナント数と、3年後の見込みを数値で置いたか

• すべての業務テーブルにテナントIDがあるか（中間・履歴テーブルを含む）

• テナントIDを先頭にした複合インデックスがあるか

• テナントの特定を認証情報から行っているか（リクエストパラメータ由来になっていないか）

• DB層でもテナント条件を強制しているか

• アプリケーションが非所有者ロールで接続しているか

• CIのテストDBが本番と同じロール構成か

• 越境参照を試みる自動テストがCIにあるか

• 1テナントだけリストアする手順が書かれ、実際に試したか

• テナント別のレイテンシとエラー率を可視化しているか

• マイグレーションの総実行時間を計測しているか

まとめ

マルチテナント設計は、サイロ・ブリッジ・プールの3方式から事業要件に合うものを選び、越境参照をアプリとDBの二重で防ぐ設計です。迷う段階ではプールから始め、要求が出たテナントだけ切り出すのが後戻りしやすい進め方になります。

• 分離方式は規制要件・テナント数・データ量の偏り・課金プラン・運用人数の5軸で決める

• プールモデルの急所は絞り込み条件の書き忘れ。行レベルセキュリティでDB層にも強制させる

• テーブル所有者はポリシーを素通りする。接続ロールを分け、CIでも本番と同じ構成にする

• テナント単位のリストアは設計時に手順を決め、リリース前に一度実際に流す

• マイグレーションの総時間はテナント数に比例する。並列化と冪等性を最初から組む

• 案件で問われるのは方式名ではなく判断根拠。採用理由と捨てた選択肢を言語化しておく

次のステップとして、手元のプロダクトで上記のチェックリストを1周してみてください。テナントIDの抜けているテーブルや、管理者向けクエリの経路が先に見つかることが多いです。

参照した一次情報は以下のとおりです。

• マルチテナント SaaS パターン｜Microsoft Learn

• PostgreSQL の行レベルのセキュリティを備えたマルチテナントデータの分離｜AWS

• 行セキュリティポリシー｜PostgreSQL公式ドキュメント

• SaaS Lens｜AWS Well-Architected Framework