シングルテナント vs マルチテナント設計入門｜SaaSアーキテクチャのコスト・セキュリティ・スケーラビリティを整理する実践ガイド

「SaaSを構築するんだけど、シングルテナントにすべきかマルチテナントにすべきか判断できない」――クラウド移行やプロダクト開発を担当するインフラエンジニアから、こういった相談をよく受けます。オンプレミス時代は1システム=1顧客が当たり前でしたが、クラウドでSaaSを設計する場合は「複数顧客のデータをどう分離するか」という新たな設計課題が生まれます。

この記事では、シングルテナントとマルチテナントの違いをコスト・セキュリティ・スケーラビリティの3軸で整理し、AWSで実際に選ばれている3つのテナント分離モデル（Silo / Pool / Bridge）の実装例と、どのケースでどちらを選ぶべきかの判断基準を現場目線で解説します。

テナント設計がSaaSの命運を分ける理由

クラウドでSaaSを構築する場合、「テナント」とは1つの顧客（契約企業）を指します。10社に同じサービスを提供するとき、10社のデータを物理的に完全分離するのか、論理的に分けるだけで同じインフラを共有するのか――この設計判断が、コスト・セキュリティ・運用のすべてに波及します。

オンプレの感覚でいけば「当然分けるでしょ」となりがちですが、クラウドSaaSでは共有リソースを最大限活用できるかどうかが収益性を左右します。特にスタートアップや初期フェーズのプロダクトでは、インフラコストの圧縮がサービス存続に直結します。

シングルテナントとは何か

シングルテナント（Single-Tenant）とは、顧客ごとに専用のインフラを用意するモデルです。たとえばAWS上で顧客A用のAmazon EC2インスタンス・Amazon RDS・Amazon VPCを独立して構築し、顧客Bには別のセットを用意します。

シングルテナントのメリット

・データの完全隔離: 物理レイヤーでデータが分離されているため、1社の障害が他社に波及しません
・コンプライアンス対応が容易: 金融・医療・政府系など「専用環境必須」の顧客要件を満たしやすい
・カスタマイズの自由度: 顧客ごとに異なる設定（OSバージョン、ミドルウェア設定）に対応できる
・ノイジーネイバー問題がない: 他顧客の高負荷がパフォーマンスに影響しない

シングルテナントのデメリット

・コストが高い: 顧客数が増えるほどインフラコストが線形に増加する
・運用負荷が大きい: パッチ適用・バックアップ・監視を顧客ごとに実施する必要がある
・リソース稼働率が低い: トラフィックが少ない夜間でもリソースが遊んでしまう

マルチテナントとは何か

マルチテナント（Multi-Tenant）とは、複数顧客が同一のインフラ・アプリケーションを共有するモデルです。データはアプリケーション層またはDB層で論理的に分離され、インフラは共有します。

マルチテナントのメリット

・コスト効率が高い: 1台のサーバーで複数顧客を処理できるため、単価を抑えられる
・運用が一元化できる: パッチ適用・バージョンアップを1回の作業で全顧客に反映できる
・リソース利用率が高い: 複数テナントのトラフィックを平準化でき、インフラを最大活用できる

マルチテナントのデメリット

・データ漏洩リスクの管理が必要: テナント間の論理分離が不完全だとデータが混在する恐れがある
・ノイジーネイバー問題: 特定テナントの高負荷が他テナントのパフォーマンスに影響する可能性がある
・カスタマイズが難しい: テナントごとに異なる要件に対応するほどコードが複雑化する

テナント分離の3つのモデル（Silo / Pool / Bridge）

AWSが「SaaS Builder’s Guide」で提唱するモデルが現場で最も参照されています。3つのモデルは排他的な選択ではなく、顧客ティアに応じて組み合わせることもできます。

1. Siloモデル（完全分離）

各テナントに専用のAWSアカウント、または専用のVPC・EC2・RDSを割り当てます。実質的にシングルテナントに近い構成です。

適したケース: 金融・医療・政府系など、コンプライアンス要件が厳しい顧客が対象のエンタープライズSaaS

AWS CLIでのSiloモデル実装例（顧客ごとに独立したVPCとRDSを作成）:

# 顧客Aの専用VPCを作成
aws ec2 create-vpc --cidr-block 10.1.0.0/16 \
  --tag-specifications \
  'ResourceType=vpc,Tags=[{Key=TenantID,Value=tenant-A},{Key=Environment,Value=prod}]'

# 顧客A専用のRDSを作成
aws rds create-db-instance \
  --db-instance-identifier tenant-a-rds \
  --db-instance-class db.t3.medium \
  --engine mysql \
  --master-username admin \
  --master-user-password "SecurePass123!" \
  --vpc-security-group-ids sg-xxxxxxxx \
  --db-subnet-group-name tenant-a-subnet-group \
  --multi-az \
  --tags Key=TenantID,Value=tenant-A

2. Poolモデル（完全共有）

すべてのテナントが同一のインフラを共有します。データの分離は「テナントID」カラムをすべてのテーブルに持たせ、アプリケーション層で制御します。

適したケース: スタートアップ、SMB向けSaaS、コストを最優先したい初期フェーズ

Amazon DynamoDBでのPoolモデル実装例（テナントIDをパーティションキーに含める）:

# テーブル名: orders
# PK: tenant_id#order_id 形式にしてテナント間のデータを論理分離

aws dynamodb put-item \
  --table-name orders \
  --item '{
    "pk":         {"S": "tenantA#order-001"},
    "tenant_id":  {"S": "tenantA"},
    "order_date": {"S": "2026-07-04"},
    "amount":     {"N": "50000"}
  }'

# テナントAのデータだけをクエリ（他テナントのデータは取得されない）
aws dynamodb query \
  --table-name orders \
  --key-condition-expression "begins_with(pk, :prefix)" \
  --expression-attribute-values '{":prefix": {"S": "tenantA#"}}'

3. Bridgeモデル（ハイブリッド）

アプリケーション層はPoolで共有し、データベース（またはストレージ）だけテナントごとに分離するモデルです。コスト効率とデータ分離のバランスが取れた現実的な選択肢です。

適したケース: 中規模SaaS。コスト効率を保ちながら、エンタープライズ顧客向けにデータ分離を証明したい場合

Amazon RDSでのBridgeモデル実装例（同一インスタンスでスキーマ分離）:

-- 同一RDSインスタンス内で、テナントごとにスキーマを分ける（MySQL例）

CREATE SCHEMA tenant_a_db CHARACTER SET utf8mb4;
CREATE SCHEMA tenant_b_db CHARACTER SET utf8mb4;

-- テナントAのユーザーにはtenant_a_dbの権限のみ付与
CREATE USER 'user_tenant_a'@'%' IDENTIFIED BY 'TenantAPass!';
GRANT ALL PRIVILEGES ON tenant_a_db.* TO 'user_tenant_a'@'%';

CREATE USER 'user_tenant_b'@'%' IDENTIFIED BY 'TenantBPass!';
GRANT ALL PRIVILEGES ON tenant_b_db.* TO 'user_tenant_b'@'%';

FLUSH PRIVILEGES;

3つのモデルの比較表

料金の考え方（コスト試算の目安）

50テナントのSaaSを運営する場合、各モデルでAWSの月額料金は大きく変わります（2026年7月時点・東京リージョン ap-northeast-1 の概算・税別）。

Siloモデル（50テナント独立構成）の概算:
・Amazon EC2（t3.small × 50台、約$0.0272/時）: 約$980/月
・Amazon RDS（db.t3.micro × 50台）: 約$650/月
・合計目安: 約$1,800～2,500/月（テナント数に比例して増加）

Poolモデル（50テナント共有構成）の概算:
・Amazon EC2（t3.large × 2台 + Auto Scaling）: 約$120/月
・Amazon RDS（db.t3.medium × 1台、マルチAZ）: 約$160/月
・合計目安: 約$300～500/月（テナント数が増えても大幅には増えない）

同じ50顧客でもモデルによって月額コストが5倍以上変わる計算です。ただし、Poolモデルはコード・設計の複雑さが増すため、開発工数を含めたTCO（総保有コスト）で比較することが重要です。

セキュリティ・コンプライアンスの観点

テナント設計はセキュリティ上の重要な選択でもあります。以下の業界やシナリオではSiloまたはBridgeが選ばれます。

・金融系（銀行・証券）: 金融庁のガイドラインで顧客データの分離要件が厳しく、Siloが主流
・医療系（電子カルテ・PHR）: 医療情報の第三者提供規制からSiloが推奨される
・PCI DSS準拠: カード情報は専用環境での管理が求められるためSilo
・SOC2対応: 論理分離（Bridge/Pool）でも証明可能だが、監査証跡の整備が前提になる

逆に、SMB向けの業務SaaSや個人ユーザー向けB2Cサービスでは、Poolモデルが圧倒的なコスト優位性を持ちます。

クラウドにおける責任範囲の考え方については、クラウドセキュリティの責任共有モデルとは？で詳しく解説しています。テナント分離の設計とあわせて参照してください。

よくある設計ミスと対処法

【ミス1】PoolモデルでテナントIDの検証をサーバー側でしていない

テナントIDでログインしたユーザーが、URLやAPIパラメーターを書き換えて別テナントのデータを取得できてしまう「テナント越え」バグは、Poolモデルの最大リスクです。

対処法: アプリケーション層でリクエストのテナントIDとセッションのテナントIDをサーバー側で必ず検証し、クライアントから渡されるテナントIDを信頼しない設計にします。Amazon Cognitoのアクセストークンにカスタム属性として`tenant_id`を埋め込み、AWS Lambda関数内では常にトークンから取得する実装が有効です。

【ミス2】ノイジーネイバーの予防をしていない

Poolモデルで1テナントが急激にトラフィックを増やすと、他テナントのレスポンスが劣化します。特にRDSの接続数上限に達するケースがよく起こります。

対処法: テナントごとの最大リクエストレートをAmazon API Gatewayのスロットリング機能で設定するか、Amazon DynamoDBのプロビジョニングモードでテナントごとのRCU/WCUを制限する設計が効果的です。

【ミス3】途中からSiloへの移行が困難になる

「最初はPoolで始めて、大手顧客が取れたらSiloに移行しよう」という計画は、データベースのスキーマが共有前提で設計されていると移行コストが膨大になります。

対処法: 最初からテナントIDをすべてのエンティティに持たせ、将来的なスキーマ分離・DB分離に対応できるデータモデルにしておきます。マイクロサービスとモノリシックアーキテクチャの選択と同様、後から変えるコストより、最初に設計するコストのほうがはるかに安いという原則がここでも当てはまります。

どちらを選ぶべきか——現場の判断フロー

以下のフローで考えると、現場での議論がシンプルになります。

・Step 1: ターゲット顧客は「金融・医療・政府系」か？→ YES → Silo（コンプライアンス優先）
・Step 2: 顧客ごとに異なるインフラ要件（OSバージョン・ネットワーク構成）があるか？→ YES → Silo
・Step 3: 初期フェーズでコストを最小化したいか？→ YES → Pool（将来的なデータ分離設計を仕込む）
・Step 4: コスト効率とデータ分離の両立を求めるか？→ YES → Bridge（スキーマ分離 or DB分離）

多くのSaaSは「最初はPool、エンタープライズ顧客獲得後にBridgeへ移行」というパスを取ります。AWS自身もSaaS Builder’s Guideでこのパターンを推奨しています。また、顧客ティアに応じて「フリープランはPool / エンタープライズ契約はSilo」のように組み合わせる手法も実務では一般的です。

本記事のまとめ

テナント設計はSaaSの収益構造・セキュリティ・スケーラビリティのすべてに直結する意思決定です。「とりあえずPoolで始める」場合も、将来のSiloへの移行パスを設計段階から考慮しておくことが、後の痛みを最小化する鍵です。