シングルテナントとマルチテナントの違い｜比較表・メリット・デメリットと分離方式

シングルテナントは顧客ごとに専用の環境を用意する構成、マルチテナントは1つの環境を複数の顧客が共有する構成です。賃貸に例えるなら一戸建てと集合住宅の差で、コスト・カスタマイズの自由度・障害の波及範囲はこの差から決まります。ただし実際のSaaSは両者の混合が多く、AWSも「どのリソースを専用にし、どれを共有するか」で設計を語るよう整理しています。比較表とメリット・デメリットから、データベースやKubernetesでのテナント分離の実装、マルチテナントを選ぶべきでない場面まで順に扱います。

まとめ

• 違いは、テナントごとにスタックを分けるか（専用＝サイロ）、共有するか（共有＝プール）の一点にある。コスト・カスタマイズ性・障害の波及範囲の差はすべてここから派生する。
• マルチテナントの利点はコストと更新の一括化、弱点はデータ分離が実装に依存することと、他テナントの負荷を受けること。シングルテナントはその裏返しで、テナント数に比例して費用と運用が増える。
• AWSはSaaS設計の文脈で「シングルテナント」という語を避け、サイロ／プールと呼ぶ。現実の設計はサービス単位で両者を混ぜるブリッジモデルになることが多い。
• 「専用環境なら安全」とは限らない。NSAはクラウドの脆弱性を4クラスに分け、共有テナンシー由来のものの広がりを「稀」と評価している。設定ミスや過剰な権限は専用環境でも減らない。
• データ分離は「DB分離」「スキーマ分離」「共有テーブル＋行レベルセキュリティ（RLS）」の3方式。PostgreSQLのRLSはテーブル所有者が既定でポリシーをバイパスするため、アプリケーションが所有者ロールで接続するなら FORCE ROW LEVEL SECURITY が必要になる。所有者でない通常のロールにはFORCE指定がなくてもRLSが適用されるが、スーパーユーザーとBYPASSRLS属性を持つロールは例外となる。
• 顧客別のコード系列を保守する契約がある場合と、契約で共有を禁じられた資源がある場合は、その部分をマルチテナントにしない。

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

専用・共有構成のコスト・運用・分離の比較

シングルテナントでは、顧客（テナント）ごとにアプリケーションとデータベースのスタックを丸ごと複製します。マルチテナントでは複数の顧客がアプリケーションなどの資源を共有します。共有DBでテナントIDによりデータを分ける構成のほか、アプリケーションを共有し、DBはテナントごとに分ける構成もあります。

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

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

テナント方式の選定基準と契約上の制約

判断は顧客数ではなく契約内容から入ります。顧客別の独立したコード系列とリリース日程を維持する契約なら、対象コンポーネントをサイロ化する方針を優先します。機能差を料金プランとフィーチャーフラグで表現でき、分離・性能・復旧要件も満たせるなら、プールを選択します。

規制要件は、対象となる制度とデータを特定し、保存先だけでなくアクセス制御・監査・運用を含めて確認します。そのうえで、監査対象かどうかだけで専用化を決めず、契約・規制・脅威モデルから専用化が必要と判断したリソースをサイロ化します。共有構成で要件を満たせる部分をプールに残せば、専用化の費用を対象部分に絞れます。

マルチテナントとシングルテナントのメリット・デメリット

マルチテナントのメリットはコストと更新の一括化

インフラ費を複数テナントで分担できる点が利点です。共有資源の利用率が上がれば、1テナントあたりの費用を抑えられます。次に効くのが更新の一括化で、修正やセキュリティパッチを1回のデプロイで全顧客に届けられます。全テナントを同じ版へ更新する運用なら、サポート対象のバージョンを集約できます。

新規顧客のオンボーディングも速くなります。テナントIDを発行して設定を登録すれば利用を始められ、インフラの構築を待ちません。月額課金で即日使い始められるSaaSでは、こうした共有が費用を抑える手段になります。ただし、専用リソースを使うSaaSでも、オンボーディングや運用の共通化は可能です。SaaSそのものの定義や代表例はSaaS（サース）とは？意味・読み方とPaaS・IaaS・ASPとの違い、メリット・デメリットで整理しています。

マルチテナントのデメリットと分離実装の責任範囲

重い順に挙げると、まずデータ分離がアプリケーションとDB設定の正しさに依存する点です。WHERE tenant_id = ? の書き忘れや、後述するRLSの設定ミスがそのまま他社データの露出になります。物理的な壁が無いぶん、1つのバグの影響範囲が全顧客に広がります。

次に、他テナントの重い処理が自社の応答を悪化させるノイジーネイバー問題、1つの障害が全テナントに及ぶこと、製品によってカスタマイズ範囲や更新時期の選択が制限されることが続きます。ただし、SalesforceのApexのように独自コードで拡張できる製品もあり、カスタマイズ範囲と更新時期の選択可否は別々に確認します。

シングルテナントの分離範囲と運用負荷

シングルテナントはこれらの裏返しです。専用のDBや実行環境は分離範囲を説明しやすくしますが、物理基盤を共有する場合は他テナントの負荷影響が残ります。個別のコード改変やバージョン固定への対応可否は、製品仕様と契約によります。

代償は2つです。インフラ費と運用対象がテナント数に比例して増えること、そしてアップデートを顧客の数だけ繰り返すことです。後者は放置すると、古い版を使い続ける顧客が増えてセキュリティパッチが行き渡らないリスクに変わります。共有構成でも、複数のデプロイ先がある場合は更新状況の管理が必要です。

「テナント」の意味とクラウドでの使われ方

SaaSのテナントは契約する組織の単位

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

テナントとユーザーは別物です。1つのテナントの中に複数のユーザーが属し、データや設定はテナント単位で分かれます。設計で最初に決めるのは「何をテナントとするか」で、企業単位か部門単位かで、課金・権限・データ分離の単位がすべて変わります。

Microsoft Entra IDのテナントは組織ごとのディレクトリ

Microsoft 365やAzureでいう「テナント」は意味がずれます。Microsoft Learnのテナント作成ガイドは、テナントを「組織を表す」ものとし、組織がAzure・Microsoft Intune・Microsoft 365などへのサインアップでMicrosoftとの関係を築いたときに受け取るMicrosoft Entra IDの専用インスタンスと説明しています。ここでのテナントは「組織ごとのIDディレクトリ」であり、アプリケーションのスタックを専用にするかどうかとは無関係です。

Microsoft自身も区別しています。Azureのマルチテナントソリューションの設計ガイドは、顧客やユーザー群を指すテナントと、個々のディレクトリを指すMicrosoft Entraのテナントについて「用語は同じでも概念は異なる」と書き、後者は必ず「Microsoft Entra tenant」とフルネームで呼んでいます。Microsoft 365の文脈で「テナントを作る」「テナント間で移行する」と言われたら、このディレクトリの話です。

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

シングルテナントは、顧客専用のインスタンスとデータベースを割り当てる構成です。オンプレミスの延長として理解されがちですが、クラウド上に顧客ごとのスタックをテンプレートから複製する実装もあります。AWSのSaaSレンズは、テナントごとの独立したスタックや専用DBをサイロの例として示しています。専用環境の料金や個別変更の可否は、構成名ではなく製品仕様と契約で確認します。

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

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

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

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

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

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

ブリッジでは、あるマイクロサービスはサイロ、別のサービスはプールとして構成します。サイロを選ぶ理由は規制プロファイルと他テナントからの影響可能性、プールを選ぶ理由は俊敏性・アクセスパターン・コストです。この粒度で分離要件を確認すると、不要な専用化と、共有禁止の要件に反するデータ配置を避けやすくなります。規制対象のデータでも、共有構成が認められるかは制度・契約・実装によります。AWS上でサイロとプールをどう切り分けるかの設計は、AWS・Google Cloud・Azureのインフラ構築支援でも扱っています。

シングルテナントなら安全かという問いとNSAの評価

共有テナンシーの脆弱性は「稀・高度」という評価

米国家安全保障局（NSA）が2020年1月22日付で公表した「Mitigating Cloud Vulnerabilities」は、クラウドの脆弱性を設定ミス、不十分なアクセス制御、共有テナンシーの脆弱性、サプライチェーンの脆弱性の4クラスに分けています。このうち共有テナンシーの脆弱性については、広がりを「稀」、攻撃者に求められる技術水準を「高」と定性的に評価しています。2020年時点の評価であり、攻撃の発生率を測定した統計ではありません。隣のテナントから仮想化基盤の欠陥を突いて侵入する攻撃は、成立させるのに高い技術が要る、広がりの小さいリスクという位置づけです。

4クラスのうち設定ミスと不十分なアクセス制御は、利用者側の運用で生まれるリスクで、専用環境を選んでも減りません。公開設定のままのストレージや、権限を絞っていない管理者アカウントは、シングルテナントでもそのまま露出につながります。セキュリティを理由にシングルテナントを求める前に、自社が防ぎたい脅威が「隣のテナントからの侵入」なのか「設定ミスによる露出」なのかを分けて考えるべきです。前者が規制や契約で求められるならサイロ化し、後者が主なら共有環境のまま設定監査とアクセス制御に投資するほうが効果があります。

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

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

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

テナント別DBは個別の復元や設定変更を重視する場合、テナント別スキーマは名前空間と変更運用を分けたい場合の候補です。共有テーブル＋RLSは資源共有の効率を重視する場合の候補ですが、採用前に負荷・分離・テナント別復元の要件を確認します。スキーマ分離を採る場合は、データスキーマとは？データベースのスキーマと三層スキーマ（外部・概念・内部）の違い・設計と管理の実務で三層スキーマを確認しておくと、三層スキーマの「概念スキーマ・外部スキーマ」と、PostgreSQLなどでテーブルをまとめる名前空間としての「スキーマ」を区別できます。テナント別スキーマ方式では、名前空間とアクセス権をテナントごとに管理します。

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

共有テーブル方式では、アプリケーションの WHERE tenant_id = ? を1箇所書き忘れただけで他テナントのデータが漏れます。これをDB側で制限するのが行レベルセキュリティ（RLS）です。以下はordersテーブルにuuid型のtenant_id列があり、アプリケーションがスーパーユーザーでもBYPASSRLSロールでもないことを前提とする設定例です。

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
ALTER TABLE orders FORCE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = NULLIF(current_setting('app.tenant_id', true), '')::uuid)
  WITH CHECK (tenant_id = NULLIF(current_setting('app.tenant_id', true), '')::uuid);

-- リクエストごとに、トランザクションの中で認可済みのテナントIDを設定する
BEGIN;
SELECT set_config('app.tenant_id', '22222222-2222-2222-2222-222222222222', true);
SELECT id FROM orders;   -- テナント22222222...の行だけが返る
COMMIT;

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

current_setting の第2引数 true は、設定が存在しない場合にエラーではなくNULLを返すための指定です。省くと、テナントIDを設定しないまま来たリクエストでエラーになります。NULLとの比較結果はNULLなので、その行は返りません。

もう1つの落とし穴が空文字列です。PostgreSQL 18.6で確かめると、set_config('app.tenant_id', …, true) の第3引数 true で現在のトランザクションの間だけ値を設定した場合、コミット後の同じセッションでは current_setting('app.tenant_id', true) が NULL ではなく空文字列を返しました。このとき NULLIF を付けない素のポリシーは invalid input syntax for type uuid: "" で失敗します。上のコードのように NULLIF(…, '') で空文字列をNULLに変えておくと、同じ状況で0行になりました。同じ環境で、テナント22222222…を設定したトランザクションから別テナントの行をINSERTすると new row violates row-level security policy で拒否されます。

接続プールでは、前のリクエストのテナントIDが接続に残らないよう、認可済みのテナントIDをトランザクションごとに第3引数 true で設定します。テナントIDを決められないリクエストは、SQLを実行する前にアプリケーション側で拒否します。

逆方向の事故もあります。ENABLE ROW LEVEL SECURITY だけを実行してポリシーを作らないと既定拒否が適用され、テーブル所有者などを除いて1行も見えなくなります。データは削除されていないのに、アプリケーションからは全件が消えたように見えます。DB製品ごとの差異はRLS（Row Level Security）とは？DBの行レベルセキュリティの仕組みと設定例にまとめています。

認証基盤とDBのテナント境界の対応

テナント境界を決めるのはDBだけではありません。どのテナントに属するユーザーかを判定する認証基盤にも同じ精度が要ります。Keycloakとは？Oktaとの違いと連携手順｜Auth0・Cognito比較で導入を判断【2026年10月】で扱っているように、IDプロバイダの識別子とDBのテナントIDの対応を明示します。Keycloakでは1つのレルム内に複数の組織を置けるため、レルム単位か組織単位かを設計に合わせて選びます。トークンの署名・発行者・対象APIを検証し、利用者が選択したテナントへの所属と権限を確認したうえで、認可済みのテナントIDをDBのトランザクションに設定する経路を一元化します。

Kubernetesでのマルチテナンシーと分離の段階

Namespace単位でテナントを分ける方式と3つの設定

コンテナ基盤でも同じ選択が出てきます。Kubernetes公式ドキュメントのMulti-tenancyは、クラスタを共有する主な方法として「テナントごとのNamespace」と「テナントごとの仮想コントロールプレーン」の2つを挙げています。Namespace方式はリソースコストがほぼかからない一方、CRD・StorageClass・Webhookのように Namespace に属さないリソースは分離できません。分離の強さは「ハード」「ソフト」と呼ばれることもありますが、同ドキュメントは単一の定義は無く、連続した幅として捉えるべきだとしています。

Namespace方式で最低限そろえるのは次の3つです。

• ResourceQuota：テナントごとにCPU・メモリやPod数の上限を切る。CPU・メモリのQuotaでは、対象にしたrequestsまたはlimitsの値が各コンテナに必要になる。Pod数などの個数Quotaだけでは、この要件は生じない。
• NetworkPolicy：既定ではクラスタ内の全Podが互いに通信でき、通信も暗号化されない。全拒否を既定にしてDNSだけ許可し、必要な通信を足していく。NetworkPolicyに対応したCNIプラグインが無いと、ポリシーは無視される。
• RBAC：テナントの利用者に、自分のNamespaceの中だけを操作できる権限を与える。

仮想コントロールプレーンと専用クラスタを選ぶ条件

テナントがAPIサーバーへのアクセスやCRDの導入を求めるなら、仮想コントロールプレーンが候補になります。テナントごとにAPIサーバー・コントローラーマネージャー・etcdを持たせ、ワーカーノードは共有する方式で、コントロールプレーン側のノイジーネイバーやCRDの衝突を避けられます。ただしノード上の干渉や攻撃はこの方式でも残るため、データプレーンの分離は別に必要です。

互いを信頼できないテナントを同居させる「ハード」なマルチテナンシーで、VMすら境界として不十分と判断するなら、公式ドキュメントも専用クラスタ（場合によっては専用ハードウェア）を選択肢に挙げています。クラスタの役割そのものはコンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説で整理しています。

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

ノイジーネイバー対策の制限・分離・専用化

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

まずテナント単位のレート制限とクエリタイムアウトで上限を切ります。次にコネクションプールをテナント階層で分け、1テナントが全接続を食い潰さないようにします。それでも影響が出る大口テナントは、そのサービスだけサイロへ移す。これがブリッジモデルの実践形です。原因の切り分け方はノイジーネイバー（Noisy Neighbor）問題とは？原因の切り分けと対策をKubernetes・SaaS別に解説で詳しく扱っています。

テナント別の遅延・エラー率の監視

監視を全体平均で見ていると、平均値の裏に沈んだ特定テナントの劣化を検知できません。レイテンシとエラー率はテナント別に分析できる形で記録します。PrometheusなどでテナントIDをラベルにする場合は時系列数の増加を見積もり、必要に応じてログやトレースでの集計を併用します。負荷の大きいテナントのp95（応答時間の95パーセンタイル）が継続して悪化したら、まず原因を切り分けます。他テナントとの資源競合が原因で、制限や増強でも目標を満たせない場合は、そのサービスのサイロ化を検討します。

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

顧客固有のコード改変と独立リリースの要件

共有コードベースに顧客別の分岐を積み上げると、リリースのたびに全顧客分の回帰試験が必要になり、共有によるはずの運用コスト削減が消えます。顧客別のコード系列を継続保守する契約なら、対象サービスのサイロ化を優先して検討します。AWSのSaaSレンズが前提とする共通の管理・デプロイと、個別版を維持する受託運用は区別します。

契約で求められる性能・データの分離範囲

顧客別の可用性SLAがあるだけでは、共有構成を排除する理由にはなりません。契約で共有を禁じる資源を特定し、同一テーブルへの格納が禁止される場合は、テーブル・スキーマ・DBなど必要な単位で分離します。この判断は技術ではなく契約と規制から降りてくるため、設計に入る前に確認します。

よくある質問

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

顧客ごとに専用のアプリケーションとデータベースを持つのがシングルテナント、1つの環境を複数顧客で共有するのがマルチテナントです。比較するのは、費用と運用対象の増え方、契約上のカスタマイズ範囲、障害の波及範囲、DB・実行環境・物理基盤それぞれの共有範囲です。

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

1つのアプリケーションとインフラを複数のテナント（利用組織）が共有する構成です。共有DBでテナントIDによってデータを論理的に分ける形が典型ですが、アプリケーションだけ共有してDBはテナントごとに分ける構成もあります。SaaSの標準的な実装形態で、リソースを共有することで1テナントあたりのコストを下げ、更新を全顧客へ一括で届けられます。

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

最も重いのは、データ分離がアプリケーションとDB設定の正しさに依存することです。アクセスを過剰に許可する設定ミスは、他社データの露出につながります。ほかに、他テナントの負荷が自社の応答に響くノイジーネイバー問題、障害が全テナントに波及しうること、製品によってカスタマイズ範囲が制限されることがあります。

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

専用のDBや実行環境により分離範囲を明確にできますが、物理基盤を共有する場合は他テナントの負荷影響が残ります。個別カスタマイズやバージョン固定の可否は製品仕様と契約によります。代償はテナント数に比例するインフラ費と、アップデートを顧客数だけ繰り返す運用負荷です。

ITでいうテナントとは何ですか？

サービスを契約して使う組織単位（企業・部門・個人）のことで、英語の「借主・入居者」が語源です。1つのテナントに複数のユーザーが属します。Microsoft 365やAzureでは、組織ごとのMicrosoft Entra IDのディレクトリを指す意味で使われるため、文脈で読み分けます。

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

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

関連記事

• RLS（Row Level Security）とは？DBの行レベルセキュリティの仕組みと設定例
• ノイジーネイバー（Noisy Neighbor）問題とは？原因の切り分けと対策をKubernetes・SaaS別に解説
• データスキーマとは？データベースのスキーマと三層スキーマ（外部・概念・内部）の違い・設計と管理の実務
• Keycloakとは？Oktaとの違いと連携手順｜Auth0・Cognito比較で導入を判断【2026年10月】
• SaaS（サース）とは？意味・読み方とPaaS・IaaS・ASPとの違い、メリット・デメリット