「マルチテナントで契約すれば安く済むが、セキュリティが心配だ」「シングルテナントプランは月額が高いが、本当にその価値があるのか判断できない」――SaaS 導入や自社サービスの SaaS 化を検討する場面で、こうした迷いに直面する情報システム担当者は少なくありません。
問題は、Web 上で見つかる情報の多くが「エンジニア向けの技術解説」または「マルチテナント＝安い／シングルテナント＝安全」といった浅い比較に留まっていることです。実際の意思決定では、自社のデータ機密性・カスタマイズ要件・利用規模・予算といった複数の軸を同時に考慮する必要があります。抽象的な比較記事だけでは、稟議書にも経営層への説明にも使えません。
さらに厄介なのは、「マルチテナントです」というベンダーの説明の裏に、実は複数のアーキテクチャパターン（サイロ・プール・ブリッジ）が存在することです。同じ「マルチテナント」でも、テナントごとに専用データベースを持つ設計と、全テナントで1つのテーブルを共有する設計では、セキュリティ・パフォーマンス・カスタマイズ性が大きく異なります。この違いを知らずに契約すると、後から「想定と違った」というトラブルにつながります。
本記事では、マルチテナントとシングルテナントの違いを 5 つの観点で比較したうえで、自社の状況に合わせて即座に判断できる 4 軸の選定基準を提示します。さらに、業界別の典型パターン、そしてマルチテナント方式を採用する際にベンダーへ確認すべき 5 つの質問リストも用意しました。読み終える頃には、社内稟議や経営層への説明で使える判断根拠を持てる状態になっているはずです。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
マルチテナントとは？1つのシステムを複数の顧客で共有する仕組み
マルチテナント（Multi-Tenant）とは、1つのシステム・インフラを複数の顧客組織で共有して利用する方式のことです。「テナント」という言葉が示す通り、1棟の雑居ビルに複数の企業が入居するイメージに近い構造をしています。それぞれのテナント（利用者組織）は、他のテナントの存在を意識することなく、自社専用のサービスとして利用できます。
現代のクラウドサービス、特に SaaS（Software as a Service）の多くはこのマルチテナント方式で構築されています。1つのシステムを多くの顧客で共有することで、開発・運用コストを利用者間で分散でき、月額数千円〜数万円といった低価格でサービス提供を実現しているのです。
「テナント」とは何か（利用者組織の単位）
IT の文脈における「テナント」とは、システムを利用する1つの組織・法人・グループを指します。たとえば、あるビジネスチャットサービスを 100 社の企業が利用している場合、その 100 社のそれぞれが 1 つのテナントに該当します。
テナントは通常、以下の単位で識別されます。
- 企業単位: 「A 商事」「B 製造」といった法人ごと
- 部門単位: 大企業の場合、事業部ごとに別テナントとする運用もある
- 契約単位: 同一法人でも複数プランを契約している場合、プランごとに別テナントとなるケース
各テナントは他のテナントのデータを見ることができず、自社の管理者権限で自社のユーザー・データ・設定のみを管理できます。この「論理的なデータ分離」がマルチテナントの根幹となる仕組みです。
マルチテナントの身近な事例（SaaSの裏側で採用されている構成）
普段何気なく使っているクラウドサービスの多くが、実はマルチテナント方式で提供されています。たとえば以下のようなサービスです。
- Google Workspace（Gmail、Google Drive）: 何億もの企業・個人が同じインフラを共有
- Microsoft 365: 世界中の企業が共通のクラウド基盤を利用
- Slack、Chatwork: 企業ごとにワークスペースが分離されているが、システム自体は共有
- Salesforce: マルチテナント SaaS の代表例。ワンコード・ワンインフラで多数の企業に提供
これらのサービスを「他社と同じサーバーを使っている」と意識して使う人は少ないでしょう。しかし裏側では、テナントごとにデータが論理的に分離されつつ、コンピュータリソース自体は多数の企業で共有されているのです。この設計により、ユーザーは低コストで高機能なサービスを受けられます。
シングルテナントとは？1顧客専用の環境を用意する方式
シングルテナント（Single-Tenant）とは、1つの顧客組織に対してシステム・インフラを専有で提供する方式のことです。マルチテナントが「雑居ビル」だとすれば、シングルテナントは「1社専用の自社ビル」に相当します。
同じ SaaS でも、シングルテナント方式で提供されるサービスは、テナントごとに独立したサーバー・データベース・アプリケーションインスタンスが構築されます。他社と物理的にも論理的にも分離されているため、データ漏洩リスクの低減や、他テナントの負荷影響からの独立性を得られます。
シングルテナントの基本構造
シングルテナントの基本構造では、契約テナントごとに以下のリソースが個別に用意されます。
- アプリケーションサーバー: 顧客専用のインスタンスが起動
- データベース: 顧客専用のデータベース（または独立したスキーマ）を保有
- ストレージ: 顧客ごとに独立したストレージ領域を割り当て
- 設定・カスタマイズ: 顧客ごとに自由にカスタマイズ可能
たとえば、大企業向けの基幹業務システムや、規制業界向けの業務システムでは、この方式が採用されることが多くあります。専用環境ゆえに、他テナントの影響を一切受けず、業務要件に合わせた深いカスタマイズが可能です。
オンプレミスとシングルテナントの違い
「専用環境」というと、自社の建物内にサーバーを置くオンプレミスを思い浮かべる方もいるかもしれません。しかし、シングルテナントとオンプレミスは異なる概念です。
項目 | シングルテナント（クラウド） | オンプレミス |
|---|---|---|
インフラの所有者 | クラウド事業者・SaaS ベンダー | 自社 |
物理サーバーの設置場所 | クラウド事業者のデータセンター | 自社の建物内・自社契約のデータセンター |
ハードウェア調達 | 不要 | 自社で購入・保守 |
運用保守の主体 | ベンダーが実施 | 自社 IT 部門・委託先が実施 |
初期コスト | 中〜高（構築費用） | 高（機材購入・設置） |
シングルテナントはあくまでクラウド上での「専有」であり、物理サーバーはクラウド事業者が所有・管理します。一方、オンプレミスは物理的にサーバーを自社で保有する形態です。「クラウドの利便性」と「専有環境の安心感」を両立したい場合の中間的な選択肢がシングルテナントである、と理解するとよいでしょう。オンプレミスとクラウドの費用差を数値で比較したい場合は、オンプレミスとクラウドのTCO比較も参考にしてください。
マルチテナントとシングルテナントの違いを5つの観点で比較
両者の違いを、意思決定に直結する 5 つの観点で比較します。単なる◯×の対比ではなく、「なぜそうなるのか」の理由まで押さえることで、自社への当てはめがしやすくなります。
5観点の比較表
観点 | マルチテナント | シングルテナント |
|---|---|---|
コスト | 低（共有によるスケールメリット） | 高（専用環境の運用コスト） |
セキュリティ・データ分離 | 論理分離（ソフトウェアレベル） | 物理・論理分離（インフラレベル） |
カスタマイズ性 | 制限あり（設定範囲内） | 自由度が高い |
アップデート・保守 | ベンダー主導で自動適用 | 顧客と協議した上で適用 |
パフォーマンス | 他テナントの影響を受ける可能性 | 独占的に利用可能 |
コスト構造の違い（初期費用・月額・スケール時）
マルチテナントのコスト構造は、開発・運用コストを全顧客で按分する仕組みのため、1 顧客あたりの負担が圧倒的に低くなります。特に月額料金の低さが際立ち、初期費用を無償または低額に抑えるベンダーも多く存在します。ユーザー数が増加してもインフラを段階的にスケールアウトできるため、スケール時のコスト増加も緩やかです。
シングルテナントのコスト構造は、専用インフラの構築・運用コストが 1 顧客に集約される形になります。初期構築費用として数百万円〜数千万円、月額運用費として数十万円〜数百万円という規模になるケースも珍しくありません。ただし、大規模利用時には「1 ユーザーあたりの単価」ではなく「環境単位」の固定料金になることが多く、大規模利用ではマルチテナントより割安になる場合もあります。
セキュリティ・データ分離の違い
セキュリティ観点での違いは「データ分離のレイヤー」に集約されます。
マルチテナントでは、データ分離はソフトウェアレベルで実現されます。同じデータベースの同じテーブル内に複数テナントのデータが並んでおり、「テナント ID」による絞り込みで論理的に分離するのが典型です。適切に設計されていれば安全ですが、アプリケーション実装のバグや権限設定の誤りが情報漏洩に直結するリスクがあります。
シングルテナントでは、そもそもデータベース自体が顧客ごとに分離されています。仮に他テナント向けのシステムに脆弱性があっても、自社データへの影響は物理的に遮断されます。金融・医療のように「万一の漏洩が事業継続に致命的」な業界でシングルテナントが選ばれる根拠は、この分離レベルにあります。
なお、AWS が公開しているSaaS のテナント分離戦略ホワイトペーパーでは、マルチテナント環境でも適切な分離戦略（サイロ／プール／ブリッジ）を選択すれば、多くのユースケースで十分な安全性が確保できるとされています。「マルチテナント＝危険」と一律に判断せず、後述するアーキテクチャの中身を確認することが重要です。
カスタマイズ性・アップデート運用の違い
マルチテナントでは、全顧客が同じアプリケーションコードを使うため、個別カスタマイズには制限があります。一般的には、ベンダーが用意した「設定範囲」内でのカスタマイズに留まります（画面レイアウト・ワークフロー定義・項目追加など）。逆に言えば、全顧客に対して機能アップデートが自動的に適用されるため、常に最新版を使い続けられるメリットもあります。
シングルテナントでは、顧客ごとに独立したコードを持てるため、業務プロセスに合わせた深いカスタマイズが可能です。ただし、アップデートも顧客ごとに調整する必要があるため、「アップデートのタイミングを制御できる」代わりに「最新機能への追随が遅れがち」というトレードオフが発生します。基幹業務システムのように「業務停止が許されない・アップデートテストを慎重に行いたい」システムでは、この制御性が価値になります。
マルチテナントのメリット・デメリット
マルチテナント方式のメリットとデメリットを整理します。デメリットについては「実際にはどう回避されているか」も併せて説明し、判断材料として使える情報を提供します。
マルチテナントのメリット
- 低コストで導入・利用可能: インフラを多数の顧客で共有するため、月額料金が抑えられる。初期費用も無償または低額のベンダーが多い
- 迅速な導入: 環境構築が不要で、契約後すぐに利用開始できる（数日〜数週間）
- 自動アップデート: ベンダーが常に最新版を提供するため、機能追加・脆弱性対応の恩恵をすぐに受けられる
- 高いスケーラビリティ: ユーザー数の増減に応じて、契約ライセンス数だけを調整すれば済む
- 運用負荷の低さ: サーバーの監視・パッチ適用・バックアップなどをベンダーが実施
マルチテナントのデメリットと現実的な対策
- カスタマイズ範囲の制限: ベンダーが用意した設定範囲内でしかカスタマイズできない → 対策: 業務プロセス側をサービスに合わせる「Fit to Standard」の発想が近年主流。カスタマイズ要件が本質的か再検討する
- 他テナントの負荷影響（ノイジーネイバー問題）: 隣接テナントの大量アクセスで自社のレスポンスが遅くなる可能性 → 対策: ベンダーはテナントごとのリソース上限（スロットリング）を設定して影響を抑えている
- アップデートタイミングを制御できない: ベンダーの都合で機能が変わる → 対策: 事前告知期間を SLA で確認し、業務検証時間を確保する
- データ分離への不安: 同じデータベース内に他社データが存在する → 対策: ベンダーの分離アーキテクチャ（サイロ／プール／ブリッジ）を確認し、必要な分離レベルを持つプランを選ぶ
「マルチテナント＝安いだけ／セキュリティが不安」という浅い理解ではなく、上記のように「デメリットへの現実的な対策」を含めて判断することが重要です。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
シングルテナントのメリット・デメリット
シングルテナントは「高セキュリティ・高柔軟性」の反面、コスト・運用面での負担が大きい方式です。追加コストを支払う価値があるかを判断するための材料として、メリット・デメリットを整理します。
シングルテナントのメリット
- 高いセキュリティ: 物理・論理両面で他テナントから分離。データ漏洩リスクを最小化
- カスタマイズの自由度: 業務プロセスに合わせた深い改修が可能
- アップデートの制御: 自社の検証タイミングでアップデートを適用でき、業務停止リスクを回避
- パフォーマンスの独占: 他テナントの負荷影響を受けず、安定した処理速度を確保
- 監査対応のしやすさ: 「他社と共有していない」ことを監査時に明示できる
- 専用構成による法令対応: 業界固有の規制要件（例: 医療の 3 省 2 ガイドライン、金融の FISC 安全対策基準）に合わせた個別設計が可能
シングルテナントのデメリット
- 高いコスト: 初期構築・月額運用コストが数倍〜十数倍になるケースも
- 導入期間の長さ: 環境構築・カスタマイズに数週間〜数ヶ月要する
- 運用負荷の増加: アップデート適用・バックアップ・監視などの調整が自社側にも発生
- 自社側の責任範囲が広がる: カスタマイズや設定変更を自社主導で行う場合、そのメンテナンス責任が発生する
- 最新機能への追随が遅れがち: マルチテナントのように全顧客一斉更新ができない
「シングルテナント＝完全に安全・自由」ではなく、責任範囲・運用負荷の一部が自社側に移る点を理解しておく必要があります。追加コストがこれらのメリットに見合うかを冷静に判断しましょう。
マルチテナントのアーキテクチャは3種類ある（サイロ・プール・ブリッジ）
「マルチテナントです」とベンダーが説明する場合、実際には 3 つの異なるアーキテクチャパターンがあります。この違いは、セキュリティ・コスト・パフォーマンスに直結するため、発注者としても概要を理解しておく必要があります。
「サイロ／プール／ブリッジ」という 3 モデルの分類は、AWS の公式ガイダンスであるSaaS レンズ（Well-Architected Framework）で定義されている用語です。一方、Microsoft Azure のマルチテナント SaaS パターン解説では、「スタンドアロン」「テナントごとのデータベース」「シャード化されたマルチテナントデータベース」といった別の分類体系で整理されており、名称や分類粒度は AWS のものと異なります。両者は用語こそ違うものの、「どこまでリソースを分離するか」という基本的な設計思想は共通しています。本記事では発注者にとって理解しやすい AWS の 3 モデル分類を用い、「どのモデルなら自社の要件を満たせるか」を判断できる粒度で説明します。クラウドインフラの基礎知識を押さえたい方は、クラウドインフラの基本ガイドも併せてご覧ください。
サイロモデル（テナント別インフラ分離）
サイロモデルは、テナントごとに独立したインフラ・データベースを用意する方式です。マルチテナントの中では最も分離度が高く、実質的にシングルテナントに近い構造といえます。
- 特徴: テナントごとに専用データベース・専用アプリケーションインスタンスを用意
- メリット: 高いセキュリティ・カスタマイズ性・パフォーマンスの独立性
- デメリット: インフラコストが高い・テナント数増加時の管理が複雑
大企業向けや、規制要件の厳しい業界を対象とした SaaS で採用されることが多いモデルです。ベンダーが「シングルテナント」と呼んでいるものが、実はこのサイロモデルによるマルチテナント運用というケースもあります。
プールモデル（完全共有型）
プールモデルは、全テナントが同じデータベース・同じテーブルを共有し、「テナント ID」で論理分離する方式です。マルチテナントの中で最もコスト効率が高い一方、分離レベルは最も低くなります。
- 特徴: 単一データベース・単一テーブル内でテナント ID による絞り込みでデータ分離
- メリット: インフラコストが最も低い・リソース利用効率が最高
- デメリット: アプリケーション実装ミスによる情報漏洩リスク・他テナントの負荷影響を受けやすい
安価なコンシューマー向け SaaS や、中小企業向けの汎用業務システムで採用されることが多いモデルです。多くの一般的な SaaS はこのモデルをベースにしています。
ブリッジモデル（ハイブリッド型）
ブリッジモデルは、サイロとプールを組み合わせた方式です。たとえば「アプリケーションサーバーは共有・データベースだけテナント別」といった構成が典型例です。
- 特徴: 一部のリソースは共有、機密性の高いデータは分離
- メリット: コストと分離のバランスを最適化できる
- デメリット: 設計・運用が複雑になる
近年の SaaS は、単純なサイロ／プールではなく、ブリッジモデルで実装されるケースが増えています。契約時には、どのリソースが共有／分離されているかを確認することが重要です。
マルチテナントとシングルテナントの選定基準｜4つの判断軸
ここからが本記事の中核です。自社の状況に照らして、マルチテナントかシングルテナントかを判断できる 4 つの軸を提示します。全ての軸を同時に検討し、複数の軸で「シングルテナント推奨」に該当する場合は、追加コストを払う価値がある可能性が高いといえます。
そもそも「既存 SaaS を使うか、独自に開発するか」から迷っている場合は、SaaS導入とスクラッチ開発の比較を先に確認することで、方式選定の前提となる意思決定を整理できます。
判断軸①: データ機密性・法規制対応
取り扱うデータの機密性が高い場合や、業界固有の規制対応が必要な場合はシングルテナントが有力候補となります。
シングルテナント推奨のケース:
- 個人の医療情報を扱う（要配慮個人情報。厚生労働省の「医療情報システムの安全管理に関するガイドライン」等の 3 省 2 ガイドライン対応が必要）
- 金融機関の顧客口座・取引データを扱う（FISC 安全対策基準など）
- 未公開の経営情報・M&A 関連情報を扱う
- 政府・自治体向けシステムで、専用環境が調達要件になっている
マルチテナントで問題ないケース:
- 一般的な業務データ（顧客管理・案件管理・会計・人事情報など）
- 業界特有の厳格な規制対応が不要
- ベンダーが提供するデータ分離水準（例: サイロモデル）で自社の情報セキュリティポリシーを満たせる
「マルチテナント＝機密情報に不向き」と一律に判断する必要はありません。ベンダーがサイロモデルを採用していれば、実質的な分離レベルは高く、規制対応の要件を満たせるケースも多くあります。
判断軸②: カスタマイズ要件
業務プロセスに合わせた深いカスタマイズが必要な場合は、シングルテナントが選択肢となります。
シングルテナント推奨のケース:
- 独自の業務プロセスがあり、既存 SaaS の設定範囲では対応不可能
- 他社と差別化されたオペレーションが競争力の源泉
- 過去のシステム資産（既存データベース・レガシー連携）との深い統合が必要
マルチテナントで問題ないケース:
- 業界標準の業務プロセスで運用可能（Fit to Standard で対応）
- 設定範囲内のカスタマイズ（項目追加・ワークフロー定義など）で十分
- 業務プロセスを SaaS 側に合わせて標準化することを許容
近年は「Fit to Standard」（業務を SaaS の標準機能に合わせる）の考え方が広がっており、多くの企業がこの方針を採用しています。カスタマイズ要件が本質的か、標準化で対応できないかを再検討することが重要です。
判断軸③: 利用規模・成長速度
利用ユーザー数や取扱データ量が大きい場合、または急速な成長が予想される場合は、方式選択が総コストに大きく影響します。
シングルテナント推奨のケース:
- 大規模利用（数千〜数万ユーザー規模）で、環境単位の料金の方が割安になる
- パフォーマンスを独占的に確保したい（他テナントの影響を受けたくない）
- 独立したスケーリング要件がある（急激なトラフィック増減）
マルチテナントで問題ないケース:
- 数人〜数百人規模の利用
- ライセンス単位で柔軟にスケールできれば十分
- 一般的な業務ピークで、他テナント影響を許容できる
シングルテナントは大規模利用時に「1 ユーザーあたり単価」ではなく「環境単位の固定料金」になることが多く、規模によっては逆にコストメリットが出るケースがあります。ベンダーに規模別の料金モデルを確認しましょう。
判断軸④: 予算・運用体制
追加コストと運用負担を許容できるかは、方式選択の現実的な制約となります。
シングルテナント推奨のケース:
- 初期構築費・月額運用費として数百万〜数千万円規模を確保できる
- 社内に IT インフラを管理・調整できる人員が存在する
- ベンダーとの継続的な調整（アップデートスケジュール等）を運用できる
マルチテナントで問題ないケース:
- 月額数万円〜数十万円程度の予算内で導入したい
- 情シス人員が限られており、運用は極力ベンダー任せにしたい
- サービスの継続提供・自動アップデートを重視
判断結果の目安:
- 4 軸のうち 3 軸以上でシングルテナント推奨に該当 → シングルテナントを本気で検討する価値あり
- 該当が 1〜2 軸 → シングルテナントとマルチテナント（サイロモデル）の両プランを比較する
- 0 軸 → マルチテナントで十分。ベンダーの標準プランを選ぶ
業界別に見る選定パターン
業界特性による典型的な選定パターンを紹介します。ただし「金融は必ずシングルテナント」といった単純な結論ではなく、「取り扱うデータ種別と規制要件」によって判断が分かれる点に注意してください。
金融業界
- 典型的な選定: シングルテナント（またはサイロモデルのマルチテナント）
- 理由: FISC 安全対策基準や金融庁のガイドライン対応、顧客口座・取引データの機密性
- 例外パターン: 決済代行・KYC 支援など、機密度が中程度のデータを扱う場合はマルチテナント SaaS が採用されるケースも増加
金融・SaaS 事業者に対する第三者認証としては SOC 2 も広く求められます。詳細はSOC 2レポートとクラウドセキュリティで解説しています。
医療・ヘルスケア業界
- 典型的な選定: シングルテナント（オンプレミス選択もまだ多い）
- 理由: 個人情報保護法上の要配慮個人情報の取り扱い、医療情報システム提供事業者向けの 3 省 2 ガイドラインへの準拠、24 時間 365 日の安定稼働要求
- 例外パターン: 医療従事者向けの学習・情報共有ツール等、個人特定性の低い用途ではマルチテナントも許容
製造業
- 典型的な選定: 分野により分岐
- 設計データ・研究開発情報 → シングルテナント（機密性・知財保護）
- 生産管理・受発注・在庫管理 → マルチテナント SaaS で十分
- IoT・製造ライン監視 → データ量・リアルタイム性からシングルテナントが選ばれることも
- 理由: 用途ごとにデータ機密性・パフォーマンス要件が大きく異なるため
一般 SaaS 利用（IT・小売・サービス業など）
- 典型的な選定: マルチテナント（標準プラン）
- 理由: 業務データの機密性は中程度、標準機能で業務要件を満たせる、コスト効率を重視
- 例外パターン: 大規模利用（数千ユーザー超）、独自業務プロセス、監査要件が特殊な場合はシングルテナントを検討
自社の業界だけでなく、「業界内でどのデータを扱うか」を分解して判断することが重要です。
マルチテナントを選ぶ場合にベンダーへ確認すべき5つの質問
マルチテナント方式の SaaS を契約する場合、発注者として以下の 5 つを確認することで、後々のトラブルを大幅に減らせます。これらは競合記事ではあまり取り上げられない、実務的な確認事項です。
質問①: データ分離のアーキテクチャは何ですか？
「マルチテナント」の中身が、サイロ・プール・ブリッジのどれに該当するかを確認します。特に自社のセキュリティポリシーで「他社とデータベースを共有しないこと」が要件になっている場合、プールモデルは要件を満たせない可能性があります。
具体的な確認例:
- 「データベースはテナントごとに分離されていますか？それとも同一テーブル内でテナント ID で管理されていますか？」
- 「一部のリソースだけ共有／分離という形式（ブリッジモデル）ですか？」
質問②: 他テナントの負荷影響（ノイジーネイバー問題）への対策は？
マルチテナントでは、他社の大量アクセスや大規模データ処理が自社のレスポンスに影響する可能性があります。この対策としてベンダーが実施している制御を確認します。
具体的な確認例:
- 「テナントごとに CPU・メモリ・API リクエスト数の上限（スロットリング）は設定されていますか？」
- 「他テナントの大規模処理時に、自社サービスへの影響を防ぐ仕組みは？」
- 「過去に他テナント影響で SLA を満たせなかった事例はありますか？」
質問③: SLA（サービスレベル合意）の稼働率・補償内容は？
マルチテナント SaaS では、稼働率 SLA が「99.9%」「99.95%」などの数値で提示されます。ただし、稼働率だけでなく「未達時の補償内容」まで確認することが重要です。
具体的な確認例:
- 「稼働率 SLA の対象範囲は？（計画停止・ネットワーク障害を除外している場合が多い）」
- 「SLA 未達時の補償は返金ですか、それとも次月クーポン等ですか？」
- 「経済産業省のSaaS 向け SLA ガイドラインに準拠していますか？」
質問④: セキュリティインシデント発生時の切り分け範囲は？
他テナントで情報漏洩やセキュリティインシデントが発生した場合、自社への影響範囲と対応フローを事前に把握しておく必要があります。
具体的な確認例:
- 「他テナントに脆弱性攻撃があった場合、自社サービスに影響しますか？」
- 「インシデント発生時の通知フローは？（全テナント通知か個別通知か）」
- 「監査ログは自社データだけを分離して取得できますか？」
質問⑤: カスタマイズ・拡張の可能な範囲は？
マルチテナントで実現できるカスタマイズの範囲を、契約前に明確にしておきます。「後から拡張したい」と思ったときに、追加開発が有料か、そもそも不可能かで運用計画が大きく変わります。
具体的な確認例:
- 「項目追加・画面レイアウト変更・ワークフロー定義はどこまで可能ですか？」
- 「独自の外部システム連携が必要な場合、API 提供や Webhook はありますか？」
- 「将来的にサイロモデル（テナント別分離）プランへのアップグレードは可能ですか？」
これらの質問への回答を書面で得ることで、「言った・言わない」のトラブルを避け、稟議書・契約書のエビデンスとして活用できます。
まとめ｜自社状況に合わせた方式選択が事業成功の鍵
マルチテナントとシングルテナントの選択は、単なるコスト比較ではなく、データ機密性・カスタマイズ要件・利用規模・予算の 4 軸から総合判断すべき戦略的な意思決定です。本記事の要点を、判断フローの形で振り返ります。
Step 1: 前提の共有
- マルチテナントは「1 システムを複数の顧客で共有」、シングルテナントは「1 顧客専用の環境」
- コスト・セキュリティ・カスタマイズ性・アップデート運用・パフォーマンスの 5 観点でトレードオフがある
Step 2: 4 軸で自社状況を評価
- データ機密性・法規制対応 → 医療・金融・政府調達要件は要注意
- カスタマイズ要件 → 標準機能で対応可能か、独自プロセスが必須か
- 利用規模・成長速度 → 大規模利用では料金モデルが逆転することも
- 予算・運用体制 → 追加コストと運用負荷を許容できるか
Step 3: 判断結果に応じた次のアクション
- 3 軸以上でシングルテナント推奨 → シングルテナントプランの見積取得を進める
- 1〜2 軸で該当 → シングルテナントとサイロモデルのマルチテナントを比較検討する
- 該当なし → マルチテナントの標準プランで進める。ベンダーへの 5 つの質問を投げる
Step 4: ベンダーへの確認と稟議準備
- マルチテナントの場合、本記事で紹介した 5 つの質問（データ分離アーキテクチャ／ノイジーネイバー対策／SLA／インシデント時対応／カスタマイズ範囲）を書面で確認
- 稟議書・経営層への説明では、「なぜこの方式を選んだか」を 4 軸の判断根拠として提示
なお、複数のクラウド・SaaS を組み合わせて運用する場合の考え方は、姉妹記事マルチクラウドとはにまとめています。テナント方式の選定と並行して、クラウド基盤自体の構成戦略も整理しておくと、意思決定の一貫性が高まります。
方式選択は、契約後の変更が事実上の再構築となるほど後戻りが困難な意思決定です。ベンダーの営業トークや「シングルテナントの方が安全」といった一般論に流されず、自社の状況に照らして冷静に判断してください。本記事の 4 軸チェックリストとベンダー確認質問リストが、その判断の一助になれば幸いです。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- マルチテナントとシングルテナントで迷ったら、まずどちらを基準に検討すべきですか？
まずマルチテナント（サイロモデル）を基準に検討し、記事内の4軸（データ機密性・カスタマイズ要件・利用規模・予算）で3軸以上シングルテナント推奨に該当する場合のみ、シングルテナントへの切り替えを本格検討するのが現実的です。
- ベンダーが「マルチテナントだから安全性に問題はない」と説明してきた場合、そのまま信じてよいですか？
そのまま信じず、データ分離のアーキテクチャ（サイロ・プール・ブリッジのどれか）を確認してください。同じ「マルチテナント」でもプールモデルとサイロモデルでは分離レベルが大きく異なり、自社のセキュリティポリシーを満たせるかは中身次第です。
- 一度マルチテナントで契約したあと、シングルテナントに移行することはできますか？
技術的には可能ですが、データ移行やシステム再設計を伴う事実上の再構築になるため、コスト・期間ともに大きな負担が発生します。移行を前提にした計画は現実的ではないため、契約前に4軸でデータ機密性・利用規模・規制対応まで将来の事業展開を見込んで判断することが重要です。
- 予算が限られている中小企業でも、扱うデータの機密性が高ければシングルテナントを選ぶべきですか？
機密性が高い場合でも、まずはマルチテナントのサイロモデル（テナント別インフラ分離）で要件を満たせないか確認するのが現実的です。実質的な分離レベルはシングルテナントに近く、コストを抑えながら機密性要件に対応できる可能性があります。
- マルチテナントの契約前に、稟議書のエビデンスとして残しておくべきことは何ですか？
データ分離アーキテクチャ・ノイジーネイバー対策・SLAの補償内容・インシデント時の切り分け範囲・カスタマイズ可能範囲の5点を、口頭ではなく書面でベンダーから回答を得て残しておくことが重要です。曖昧な回答しか得られない項目は、稟議上のリスクとして明記しておきましょう。
