シングルテナントとマルチテナントの違い｜比較表・選定基準とテナント分離の実装

シングルテナントは顧客ごとに専用の環境を用意する構成、マルチテナントは1つの環境を複数の顧客が共有する構成です。ただしAWSは、この二分法ではなく「どのリソースを専用にし、どのリソースを共有するか」で設計を語るよう整理しています。違いの比較から、テナント分離の実装方式、判断を誤りやすい境界までまとめます。

まとめ

• 構造上の違いは、テナントごとにスタックを分けるか（専用＝サイロ）、共有するか（共有＝プール）の一点に集約される。コスト・カスタマイズ性・障害波及の差はすべてここから派生する。
• AWSはSaaSアーキテクチャの文脈で「シングルテナント」という語を避け、サイロ／プールという表現を使う。専用スタックを持つ顧客でも、オンボーディングや運用は共有基盤で管理されるためだ。
• 現実の設計解はサイロとプールの混合（ブリッジモデル）になることが多い。規制要件の厳しいデータストアだけサイロにし、アプリ層はプールにする、といったサービス単位の使い分けが基本になる。
• データ分離は「DB分離」「スキーマ分離」「共有テーブル＋行レベルセキュリティ（RLS）」の3方式。PostgreSQLのRLSはテーブル所有者が既定でポリシーをバイパスするため、FORCE ROW LEVEL SECURITY を付けないと分離が効かない。
• マルチテナントを避けるべきなのは、テナント固有のコード改変を約束している場合と、他テナントの負荷影響を契約上許容できない場合。どちらかに該当するなら共有化のコストメリットは幻想に終わる。

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

構造の違いと、そこから派生する差

シングルテナントでは、顧客（テナント）ごとにアプリケーションとデータベースのスタックを丸ごと複製します。マルチテナントでは、同一のアプリケーションコードとデータベースを全テナントが共有し、テナントIDによって見えるデータを切り分けます。

この構造差が、そのままコストと運用の差になります。専用スタックは顧客数に比例してインフラ費と運用対象が増えます。共有スタックはリソース利用率を上げられる代わりに、1テナントの障害や過負荷が他テナントへ波及する経路を持ちます。

専用スタックでも、課金・監視・デプロイパイプラインはベンダー側で共通化されているのが普通です。表の「当該テナントのみ」は業務データと実行環境についての話で、共通の運用基盤が落ちれば影響は全顧客に及びます。

どちらを選ぶかの判断基準

判断は顧客数ではなく契約内容から入ります。テナントごとにコードを変える約束をしているなら共有スタックは維持できず、サイロが必然です。逆に、機能差を料金プランとフィーチャーフラグで表現できるなら、プールでほぼ問題ありません。

規制要件は、データストアだけを分ければ満たせることが多い点に注意してください。「金融だから全部専用」ではなく、監査対象のデータを持つコンポーネントを特定して、そこだけサイロ化するほうが費用対効果に優れます。

マルチテナントの定義とSaaSにおける位置づけ

テナントの意味と共有の構造

テナントとは、サービスを利用する組織単位（企業・部門・個人）を指し、賃貸ビルの「入居者」が語源です。マルチテナントアーキテクチャは、1棟のビル（インフラとアプリケーション）を複数の入居者が共有し、各戸の鍵（認証とテナント境界）で互いの部屋に入れないようにする構造にあたります。

SalesforceやMicrosoft 365といった主要SaaSはこの構造を採ります。SaaSとは？読み方（サース）と意味を、代表例・種類・PaaS/IaaSとの違いから整理で扱っているとおり、月額課金で即座に利用開始できるSaaSの経済性は、共有によるリソース効率が前提になっています。

シングルテナントと呼ばれる専用環境の実態

シングルテナントは、顧客専用のインスタンスとデータベースを割り当てる構成です。オンプレミスの延長として理解されがちですが、実際にはクラウド上に顧客ごとのスタックをテンプレートから複製する形が主流です。専用といっても、課金・監視・デプロイパイプラインはベンダー側で共通化されています。

AWSがサイロ・プール・ブリッジで語る理由

「シングルテナント」という区分の曖昧さ

AWSはホワイトペーパー「SaaS アーキテクチャの基礎」に「シングルテナントという用語の削除」という節を置き、この語は一般に避けられるとしています（2022年公開・現在は参考資料扱い）。挙げられている理由は2点です。各テナントが独自のスタックを持つ場合でも、オンボーディング・アイデンティティ・運用管理は共有の仕組みで動いており、システム全体としてはマルチテナントモデルで運営されていること。そして、すべての環境はリソースの一部または全部が共有か専用かのバリエーションにすぎず、絶対的な区分が存在しないことです。

この整理に立つと「シングルテナントかマルチテナントか」という問い自体が粗すぎます。ベンダーの提案書に「弊社はシングルテナントなので安全です」とあれば、どのリソースが専用でどのリソースが共有なのかを個別に確認すべきです。専用なのはデータベースだけで、アプリケーション層は他社と共有、という構成は珍しくありません。

サイロ・プール・ブリッジの3モデル

AWSの現行ガイダンスであるWell-ArchitectedフレームワークのSaaSレンズは、リソース単位で語れる用語を定義しています。テナント専用にリソースをデプロイするのがサイロ、テナント間でリソースを共有するのがプール。そして現実の設計は、同レンズがブリッジモデルと呼ぶ両者の混合になります。

ブリッジでは、あるマイクロサービスはサイロ、別のサービスはプールとして構成します。サイロを選ぶ理由は規制プロファイルと他テナントからの影響可能性、プールを選ぶ理由は俊敏性・アクセスパターン・コストです。設計時にこの粒度で意思決定できていれば、全社一律で専用環境という過剰投資も、規制データまで共有テーブルに載せる事故も避けられます。

テナント分離の方式とRLS実装

DB分離・スキーマ分離・共有テーブルの比較

データ層の分離方式は次の3つに整理できます。下に行くほどコスト効率が上がり、分離の強度と実装難易度のトレードオフが厳しくなります。

スキーマ分離を採る場合、スキーマがDB内でどの層に位置する概念かを踏まえた設計が前提になります。データベースのスキーマとは？三層スキーマ（外部・概念・内部）の違いと設計・管理の実務で三層スキーマを確認しておくと、テナント別スキーマが概念スキーマの複製であって外部スキーマの分離ではない点が明確になります。

PostgreSQL RLSの所有者バイパスとFORCE指定

共有テーブル方式では、アプリケーションのWHERE tenant_id = ? を1箇所書き忘れただけで他テナントのデータが漏れます。これをDB側で強制するのが行レベルセキュリティ（RLS）です。

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
ALTER TABLE orders FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.tenant_id', true)::uuid)
  WITH CHECK (tenant_id = current_setting('app.tenant_id', true)::uuid);

2行目が要点です。PostgreSQLの公式ドキュメントは、スーパーユーザおよびBYPASSRLS属性を持つロールは常にRLSをバイパスし、テーブル所有者も通常はバイパスすると明記しています。アプリケーションがテーブル所有者ロールで接続していると、RLSを有効化してポリシーを書いても分離はまったく機能しません。FORCE ROW LEVEL SECURITY を指定して初めて、所有者もポリシーの対象になります。

current_setting の第2引数 true も落とせません。これを省くと、セッション変数が未設定のまま来たリクエストで「設定パラメータが認識できない」エラーになり、クエリ自体が落ちます。true を渡せば未設定時はNULLとなり、条件が偽になって0行を返します。接続プールを使う構成では、リクエストごとに set_config でテナントIDを詰め直す処理が漏れることがあるため、落ちるより閉じる側に倒しておきます。WITH CHECK を明示しておけば、書き込み時に他テナントのIDを混入させることも防げます。

逆方向の事故もあります。ENABLE ROW LEVEL SECURITY だけを実行してポリシーを作らないと既定拒否ポリシーが適用され、スーパーユーザ・BYPASSRLSロール・テーブル所有者を除いて1行も見えなくなります。本番投入後に全データが消えたように見える障害の典型です。設定手順とDB製品ごとの差異はRow Level Security（RLS）とは？行単位アクセス制御の仕組みとDB別の設定方法を解説にまとめています。

テナント境界は認証基盤と揃える

テナント境界を決めるのはDBだけではありません。どのテナントに属するユーザーかを判定する認証基盤にも同じ精度が要ります。Keycloakとは？メリット・デメリットとAuth0・Okta・Cognito比較で導入を判断【2026年版】で扱っているように、IDプロバイダ側のテナント（レルム、組織）設計とDBのテナントIDは1対1で対応づけておく必要があります。トークンのクレームからテナントIDを取り出し、そのままセッション変数へ渡す経路を1本に固定するのが安全です。

ノイジーネイバー問題への対処

上限を切り、分け、それでも駄目なら移す

共有環境では、1テナントの重いバッチや暴走クエリがCPUやコネクションを占有し、他テナントの応答を悪化させます。これがノイジーネイバー（うるさい隣人）問題です。

まずテナント単位のレート制限とクエリタイムアウトで上限を切ります。次にコネクションプールをテナント階層で分け、1テナントが全接続を食い潰さないようにします。それでも影響が出る大口テナントは、そのサービスだけサイロへ移す。これがブリッジモデルの実践形です。

監視はテナント別メトリクスで取る

監視を全体平均で見ていると、平均値の裏に沈んだ特定テナントの劣化を検知できません。レイテンシとエラー率は必ずテナントIDでラベル付けし、テナント別の分布として観測します。上位テナントのp95がじりじり悪化していれば、それはサイロへ移す判断のトリガーになります。

マルチテナントを選ぶべきでない場面

テナント固有のコード改変を約束している

共有コードベースに顧客別の分岐を積み上げると、リリースのたびに全顧客分の回帰試験が必要になり、共有によるはずの運用コスト削減が消えます。個別要件が定常的に発生する受託色の強い契約なら、最初からサイロにしたほうが安く済みます。

他テナントの影響を契約上許容できない

可用性SLAを顧客ごとに結んでいる、あるいは監査で「他社データと同一のテーブルに置かない」ことを求められているなら、論理分離では要件を満たせません。この判断は技術ではなく契約と規制から降りてくるため、設計に入る前に確認しておく項目です。

よくある質問

シングルテナントとマルチテナントの違いは何ですか？

顧客ごとに専用のアプリケーションとデータベースを持つのがシングルテナント、1つの環境を複数顧客で共有するのがマルチテナントです。差はコスト（比例か逓減か）、カスタマイズ範囲（コード改変か設定か）、障害の波及範囲、データ分離の方式に現れます。

マルチテナントとは何ですか？

1つのアプリケーションとインフラを複数のテナント（利用組織）が共有し、テナントIDによってデータと設定を論理的に分離する構成です。SaaSの標準的な実装形態で、リソースを共有することで1テナントあたりのコストを下げられます。

マルチテナントのデメリットは何ですか？

他テナントの負荷が自社の応答速度に影響するノイジーネイバー問題、データ分離が実装依存になること、カスタマイズが設定の範囲に限られること、1つの障害が全テナントに波及しうることです。分離はRLSやスキーマ分離で強化できますが、設定ミスが即座に情報漏えいになる点は残ります。

シングルテナントのメリットは何ですか？

データが物理的に分離されるため規制対応の説明が容易で、他テナントの負荷影響を受けず、テナント固有のカスタマイズやバージョン固定に対応できます。代償はテナント数に比例するインフラ費と、アップデートを顧客数だけ繰り返す運用負荷です。

AWSでいうマルチテナントとは何を指しますか？

AWSはSaaSアーキテクチャの文脈で、テナント専用リソースを「サイロ」、共有リソースを「プール」と呼び、「シングルテナント」という用語は避けています。専用スタックの顧客でも運用・課金基盤は共有されており、システム全体はマルチテナントとして運営されるためです。EC2のDedicated Instances等のテナンシー設定とは別概念なので混同しないでください。

テナント分離はどの方式を選べばよいですか？

テナント数が数十以下で規制要件が重いならテナント別DB、数百規模でスキーマ変更の自動適用が組めるならテナント別スキーマ、数千規模でコスト効率を最優先するなら共有テーブル＋RLSが基本線です。全社一律で決めず、規制対象データを持つサービスだけサイロにするブリッジ構成を先に検討してください。

関連記事

• Row Level Security（RLS）とは？行単位アクセス制御の仕組みとDB別の設定方法を解説
• データベースのスキーマとは？三層スキーマ（外部・概念・内部）の違いと設計・管理の実務
• Keycloakとは？メリット・デメリットとAuth0・Okta・Cognito比較で導入を判断【2026年版】
• SaaSとは？読み方（サース）と意味を、代表例・種類・PaaS/IaaSとの違いから整理