「マルチテナントで契約すれば安く済むが、セキュリティが心配だ」「シングルテナントプランは月額が高いが、本当にその価値があるのか判断できない」――SaaS 導入や受託開発の見積を取る場面で、こうした迷いに直面する情報システム担当者は少なくありません。
ベンダーの提案書や見積書に「マルチテナント」「シングルテナント」と書かれていても、語の意味が分かるだけでは判断できません。知りたいのは、その違いが見積の金額差、契約条件、保守・アップデートの負担にどう効くのか、そして稟議でどう説明するのかではないでしょうか。
Web 上の情報の多くは、エンジニア向けの技術解説か、「マルチテナント＝安い／シングルテナント＝安全」といった浅い比較に留まっています。さらに、同じ「マルチテナント」でも、テナントごとに専用データベースを持つ設計と、全テナントで 1 つのテーブルを共有する設計（サイロ・プール・ブリッジ）では、セキュリティ・パフォーマンス・カスタマイズ性が大きく異なります。この違いを知らずに契約すると、「想定と違った」というトラブルにつながります。
本記事では、マルチテナントとシングルテナントの違いを 5 つの観点で比較し、見積・契約・保守にどう影響するかを整理したうえで、自社の状況に合わせて判断できる 4 軸の選定基準を提示します。Fit to Standard のデメリット、DB の分離方式（インスタンス分離とスキーマ分離）、AWS・Azure での構成と料金の見方も、発注者が理解しておくべき範囲に絞って解説します。業界別の典型パターンと、ベンダーへ確認すべき 5 つの質問も用意しました。読み終える頃には、社内稟議や経営層への説明で使える判断根拠を持てる状態になっているはずです。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
マルチテナントとは？1つのシステムを複数の顧客で共有する仕組み
マルチテナント（Multi-Tenant）とは、1つのシステム・インフラを複数の顧客組織で共有して利用する方式のことです。「テナント」という言葉が示す通り、1棟の雑居ビルに複数の企業が入居するイメージに近い構造をしています。それぞれのテナント（利用者組織）は、他のテナントの存在を意識することなく、自社専用のサービスとして利用できます。
現代のクラウドサービス、特に SaaS（Software as a Service）の多くはこのマルチテナント方式で構築されています。1つのシステムを多くの顧客で共有することで、開発・運用コストを利用者間で分散でき、月額数千円〜数万円といった低価格でサービス提供を実現しているのです。
発注判断で押さえる3つのポイント（見積・契約・保守への影響）
語の意味を理解したら、次に発注判断への影響を確認しましょう。マルチテナントかシングルテナントかは、次の 3 点に表れます。
発注判断の場面 | マルチテナントの場合 | シングルテナントの場合 |
|---|---|---|
見積 | 月額のライセンス料が中心。初期構築費は小さいか無償のことが多い | 専用環境の構築費と、環境単位の運用費が見積に載る。インフラ費用が固定費になりやすい |
契約 | 利用規約・SLA が標準化されており、個別の条件交渉は限られる。契約の主な論点は SLA と責任範囲 | 個別契約になりやすく、保守範囲・アップデート時期・データの取り扱いを個別に取り決められる |
保守・アップデート | ベンダー主導で全顧客に一斉適用。時期は選べない | 自社の検証スケジュールと調整して適用できる。その分、調整の手間と費用が発生する |
見積書の金額差の多くは、この「専用環境を誰が負担するか」の違いから生じます。提案書に方式が明記されていない場合は、見積依頼の段階で方式を確認しておくと、複数ベンダーの見積を同じ条件で比較できます。
「テナント」とは何か（利用者組織の単位）
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 ユーザーあたりの単価」ではなく「環境単位」の固定料金になることが多く、大規模利用ではマルチテナントより割安になる場合もあります。
クラウド料金の見方（Azure・AWS を円で見積もるときの注意）
シングルテナントや、サイロモデルのマルチテナントでは、見積の根拠として Azure や AWS の利用料が出てくることがあります。「Azure 料金は何円くらいか」を調べたくなりますが、クラウド料金は次の理由で、記事や他社事例の金額をそのまま自社の見積に当てはめることができません。
- 料金は従量課金で、仮想マシンの性能、データベースの種類、ストレージ容量、通信量、稼働時間によって変わります
- 料金は米ドル建てで公表され、円換算額は為替レートで変動します
- 冗長構成（複数拠点での構成）やバックアップを加えると、同じ機能でも費用が変わります
そのため、発注者としては金額そのものよりも、ベンダーの見積にどの項目が含まれているかを確認する方が実務的です。
- クラウド利用料は、見積に含まれていますか。それとも別途実費請求ですか
- 為替変動があった場合、円建ての請求額はどう扱われますか
- 想定している利用量（ユーザー数・データ量・稼働時間）は、見積の前提として明記されていますか
具体的な金額の目安は、各クラウド事業者が公開している公式の料金表や料金計算ツールで、前提条件を置いて試算できます。ベンダーからは、その試算の前提を書面で受け取っておくと、稟議での説明に使えます。
セキュリティ・データ分離の違い
セキュリティ観点での違いは「データ分離のレイヤー」に集約されます。
マルチテナントでは、データ分離はソフトウェアレベルで実現されます。同じデータベースの同じテーブル内に複数テナントのデータが並んでおり、「テナント ID」による絞り込みで論理的に分離するのが典型です。適切に設計されていれば安全ですが、アプリケーション実装のバグや権限設定の誤りが情報漏洩に直結するリスクがあります。
シングルテナントでは、そもそもデータベース自体が顧客ごとに分離されています。仮に他テナント向けのシステムに脆弱性があっても、自社データへの影響は物理的に遮断されます。金融・医療のように「万一の漏洩が事業継続に致命的」な業界でシングルテナントが選ばれる根拠は、この分離レベルにあります。
なお、AWS が公開しているSaaS のテナント分離戦略ホワイトペーパーでは、マルチテナント環境でも適切な分離戦略（サイロ／プール／ブリッジ）を選択すれば、多くのユースケースで十分な安全性が確保できるとされています。「マルチテナント＝危険」と一律に判断せず、後述するアーキテクチャの中身を確認することが重要です。
DBのインスタンス分離とスキーマ分離の違い
データ分離の中身を確認するときに、ベンダーから「データベースはスキーマで分離しています」「インスタンスを分けています」と説明されることがあります。専門外の方向けに、違いを整理します。
分離の単位 | 分離の度合い | 費用・運用への影響 |
|---|---|---|
テーブル内でテナント ID を使って分ける | 低い（同じテーブルを共有） | 費用は最も低いが、実装ミスが他社データの閲覧につながるリスクがある |
スキーマ（同じDB内の区画）で分ける | 中程度（テーブルはテナントごとに別。DB 基盤は共有） | 費用と分離のバランスがよい。DB の負荷は他テナントと共有される |
インスタンス（DB サーバー自体）で分ける | 高い（DB 基盤から別） | 費用は高い。負荷・障害・バックアップを個別に扱える |
発注者が押さえるポイントは、分離の度合いが上がるほど、費用が上がり、他社の影響を受けにくくなるという関係です。たとえば、バックアップや復元をテナント単位で依頼したい場合、スキーマ分離やインスタンス分離であれば対応しやすく、テーブル共有では難しくなる傾向があります。契約前に「自社データだけを指定時点に戻せるか」を確認しておくと、保守条件の判断材料になります。
カスタマイズ性・アップデート運用の違い
マルチテナントでは、全顧客が同じアプリケーションコードを使うため、個別カスタマイズには制限があります。一般的には、ベンダーが用意した「設定範囲」内でのカスタマイズに留まります（画面レイアウト・ワークフロー定義・項目追加など）。逆に言えば、全顧客に対して機能アップデートが自動的に適用されるため、常に最新版を使い続けられるメリットもあります。
シングルテナントでは、顧客ごとに独立したコードを持てるため、業務プロセスに合わせた深いカスタマイズが可能です。ただし、アップデートも顧客ごとに調整する必要があるため、「アップデートのタイミングを制御できる」代わりに「最新機能への追随が遅れがち」というトレードオフが発生します。基幹業務システムのように「業務停止が許されない・アップデートテストを慎重に行いたい」システムでは、この制御性が価値になります。
マルチテナントのメリット・デメリット
マルチテナント方式のメリットとデメリットを整理します。デメリットについては「実際にはどう回避されているか」も併せて説明し、判断材料として使える情報を提供します。
マルチテナントのメリット
- 低コストで導入・利用可能: インフラを多数の顧客で共有するため、月額料金が抑えられる。初期費用も無償または低額のベンダーが多い
- 迅速な導入: 環境構築が不要で、契約後すぐに利用開始できる（数日〜数週間）
- 自動アップデート: ベンダーが常に最新版を提供するため、機能追加・脆弱性対応の恩恵をすぐに受けられる
- 高いスケーラビリティ: ユーザー数の増減に応じて、契約ライセンス数だけを調整すれば済む
- 運用負荷の低さ: サーバーの監視・パッチ適用・バックアップなどをベンダーが実施
マルチテナントのデメリットと現実的な対策
- カスタマイズ範囲の制限: ベンダーが用意した設定範囲内でしかカスタマイズできない → 対策: 業務プロセス側をサービスに合わせる「Fit to Standard」の発想が近年主流。カスタマイズ要件が本質的か再検討する（詳細は次項）
- 他テナントの負荷影響（ノイジーネイバー問題）: 隣接テナントの大量アクセスで自社のレスポンスが遅くなる可能性 → 対策: ベンダーはテナントごとのリソース上限（スロットリング）を設定して影響を抑えている
- アップデートタイミングを制御できない: ベンダーの都合で機能が変わる → 対策: 事前告知期間を SLA で確認し、業務検証時間を確保する
- データ分離への不安: 同じデータベース内に他社データが存在する → 対策: ベンダーの分離アーキテクチャ（サイロ／プール／ブリッジ）を確認し、必要な分離レベルを持つプランを選ぶ
Fit to Standard のデメリットと、発注時の対処
Fit to Standard とは、自社の業務をシステムの標準機能に合わせて見直す考え方です。カスタマイズを抑えられるため、導入費用の圧縮、アップデート時の改修不要、保守の簡素化といったメリットがあります。一方で、発注者として次のデメリットも理解したうえで判断する必要があります。
デメリット | 発注時に起こりやすいこと | 対処の例 |
|---|---|---|
現場の業務変更の負担 | 業務手順の変更に現場が反発し、定着に時間がかかる | 導入前に変更される業務を一覧化し、現場責任者と合意しておく |
競争力の源泉まで標準化される | 他社と差別化している業務まで画一化してしまう | 差別化に必要な業務だけを「標準化しない領域」として切り分け、その部分を別途開発・連携で補う |
標準で満たせない要件の後出し | 稼働後に追加要望が出て、想定外の費用がかかる | 要件を「必須」「できれば」「不要」に分け、標準で満たせない必須要件は契約前に洗い出す |
ベンダーの機能追加に依存する | 要望した機能がいつ実装されるか分からない | ロードマップの共有範囲と、要望の受付方法を確認する |
稟議では「Fit to Standard で費用を抑える」とだけ書くと、業務変更のリスクが見えなくなります。費用を抑えられる分、どの業務を変えるのかを併記すると、判断する側が内容を評価しやすくなります。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
シングルテナントのメリット・デメリット
シングルテナントは「高セキュリティ・高柔軟性」の反面、コスト・運用面での負担が大きい方式です。追加コストを支払う価値があるかを判断するための材料として、メリット・デメリットを整理します。
シングルテナントのメリット
- 高いセキュリティ: 物理・論理両面で他テナントから分離。データ漏洩リスクを最小化
- カスタマイズの自由度: 業務プロセスに合わせた深い改修が可能
- アップデートの制御: 自社の検証タイミングでアップデートを適用でき、業務停止リスクを回避
- パフォーマンスの独占: 他テナントの負荷影響を受けず、安定した処理速度を確保
- 監査対応のしやすさ: 「他社と共有していない」ことを監査時に明示できる
- 専用構成による法令対応: 業界固有の規制要件（例: 医療の 3 省 2 ガイドライン、金融の FISC 安全対策基準）に合わせた個別設計が可能
シングルテナントのデメリット
- 高いコスト: 初期構築・月額運用コストが数倍〜十数倍になるケースも
- 導入期間の長さ: 環境構築・カスタマイズに数週間〜数ヶ月要する
- 運用負荷の増加: アップデート適用・バックアップ・監視などの調整が自社側にも発生
- 自社側の責任範囲が広がる: カスタマイズや設定変更を自社主導で行う場合、そのメンテナンス責任が発生する
- 最新機能への追随が遅れがち: マルチテナントのように全顧客一斉更新ができない
「シングルテナント＝完全に安全・自由」ではなく、責任範囲・運用負荷の一部が自社側に移る点を理解しておく必要があります。追加コストがこれらのメリットに見合うかを冷静に判断しましょう。
マルチテナントのアーキテクチャは3種類ある（サイロ・プール・ブリッジ）
「マルチテナントです」とベンダーが説明する場合、実際には 3 つの異なるアーキテクチャパターンがあります。この違いは、セキュリティ・コスト・パフォーマンスに直結するため、発注者としても概要を理解しておく必要があります。
「サイロ／プール／ブリッジ」という 3 モデルの分類は、AWS の公式ガイダンスであるSaaS レンズ（Well-Architected Framework）で定義されている用語です。一方、Microsoft Azure のマルチテナント SaaS パターン解説では、「スタンドアロン」「テナントごとのデータベース」「シャード化されたマルチテナントデータベース」といった別の分類体系で整理されており、名称や分類粒度は AWS のものと異なります。両者は用語こそ違うものの、「どこまでリソースを分離するか」という基本的な設計思想は共通しています。本記事では発注者にとって理解しやすい AWS の 3 モデル分類を用い、「どのモデルなら自社の要件を満たせるか」を判断できる粒度で説明します。クラウドインフラの基礎知識を押さえたい方は、クラウドインフラの基本ガイドも併せてご覧ください。
AWS・Azure のアーキテクチャを発注者が確認するときの視点
提案書に AWS や Azure のアーキテクチャ図が載っている場合、構成の細部を理解する必要はありません。次の対応関係を押さえておくと、見積と構成の整合性を確認できます。
確認項目 | 見る場所 | 見積・保守への影響 |
|---|---|---|
テナントごとにDBを分けているか | 図中のデータベースの数と、テナントとの対応 | 分けるほどインフラ費用が増える |
アプリケーションサーバーが共有か専用か | サーバー（コンピュート）の配置 | 共有は費用が低く、専用は負荷の独立性が高い |
複数拠点・冗長構成になっているか | 拠点（リージョン・ゾーン）の記載 | 障害時の復旧性が上がる一方、利用料が増える |
バックアップの単位と保管期間 | バックアップの記載 | 復元の粒度（全体かテナント単位か）に影響する |
図が提示されない場合は、「自社データを格納するDBは、他社と共有されていますか」「障害時の復旧単位はどこまでですか」の 2 点だけでも書面で確認しておくと、後述のベンダー確認質問に接続できます。
サイロモデル（テナント別インフラ分離）
サイロモデルは、テナントごとに独立したインフラ・データベースを用意する方式です。マルチテナントの中では最も分離度が高く、実質的にシングルテナントに近い構造といえます。
- 特徴: テナントごとに専用データベース・専用アプリケーションインスタンスを用意
- メリット: 高いセキュリティ・カスタマイズ性・パフォーマンスの独立性
- デメリット: インフラコストが高い・テナント数増加時の管理が複雑
大企業向けや、規制要件の厳しい業界を対象とした 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 軸 → マルチテナントで十分。ベンダーの標準プランを選ぶ
稟議に使える比較表のつくり方（稟議システム・複数案の比較）
稟議書や、稟議システムに添付する比較資料では、「マルチテナント案」と「シングルテナント案」を同じ項目で並べると判断しやすくなります。稟議システムそのものの製品比較ではなく、稟議に添付する方式比較として、次の項目を揃えることをおすすめします。
項目 | マルチテナント案 | シングルテナント案 |
|---|---|---|
初期費用 | ベンダー見積の値を記載 | ベンダー見積の値を記載 |
月額・年額費用 | 同上（利用量の前提も併記） | 同上（環境単位の費用と運用費を分けて記載） |
契約条件 | SLA の稼働率と補償内容 | 保守範囲・アップデート時期の取り決め |
データ分離の水準 | ベンダーの回答（サイロ／プール／ブリッジ） | 専用環境の範囲 |
保守・アップデート | ベンダー主導（時期は選べない） | 自社調整（検証の手間が発生） |
自社の追加負担 | 業務変更（Fit to Standard）の範囲 | 運用調整の人員・工数 |
4 軸の該当数 | 該当する軸の数と根拠 | 同左 |
金額の欄には、ベンダーから書面で受け取った見積の数値と前提条件を転記してください。方式の選択理由は、4 軸の該当数と根拠を添えると説明しやすくなります。費用の見方をさらに整理したい場合は、システム開発の費用を正しく理解するガイドブックに見積チェックリストがまとまっています。
業界別に見る選定パターン
業界特性による典型的な選定パターンを紹介します。ただし「金融は必ずシングルテナント」といった単純な結論ではなく、「取り扱うデータ種別と規制要件」によって判断が分かれる点に注意してください。
金融業界
- 典型的な選定: シングルテナント（またはサイロモデルのマルチテナント）
- 理由: 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 観点でトレードオフがある
- 方式の違いは、見積（専用環境の費用負担）、契約（SLA と個別条件）、保守（アップデートの主導権）に表れる
Step 2: 4 軸で自社状況を評価
- データ機密性・法規制対応 → 医療・金融・政府調達要件は要注意
- カスタマイズ要件 → 標準機能で対応可能か、独自プロセスが必須か（Fit to Standard の業務変更負担も考慮）
- 利用規模・成長速度 → 大規模利用では料金モデルが逆転することも
- 予算・運用体制 → 追加コストと運用負荷を許容できるか
Step 3: 判断結果に応じた次のアクション
- 3 軸以上でシングルテナント推奨 → シングルテナントプランの見積取得を進める
- 1〜2 軸で該当 → シングルテナントとサイロモデルのマルチテナントを比較検討する
- 該当なし → マルチテナントの標準プランで進める。ベンダーへの 5 つの質問を投げる
Step 4: ベンダーへの確認と稟議準備
- マルチテナントの場合、本記事で紹介した 5 つの質問（データ分離アーキテクチャ／ノイジーネイバー対策／SLA／インシデント時対応／カスタマイズ範囲）を書面で確認
- クラウド利用料の扱い（見積に含むか、実費か、為替の扱い）と、見積の前提条件を書面で受け取る
- 稟議書・経営層への説明では、「なぜこの方式を選んだか」を 4 軸の判断根拠と比較表で提示
なお、複数のクラウド・SaaS を組み合わせて運用する場合の考え方は、姉妹記事マルチクラウドとはにまとめています。テナント方式の選定と並行して、クラウド基盤自体の構成戦略も整理しておくと、意思決定の一貫性が高まります。
方式選択は、契約後の変更が事実上の再構築となるほど後戻りが困難な意思決定です。ベンダーの営業トークや「シングルテナントの方が安全」といった一般論に流されず、自社の状況に照らして冷静に判断してください。本記事の 4 軸チェックリストとベンダー確認質問リストが、その判断の一助になれば幸いです。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- マルチテナントとシングルテナントで迷ったら、まずどちらを基準に検討すべきですか？
まずマルチテナント（サイロモデル）を基準に検討し、記事内の4軸（データ機密性・カスタマイズ要件・利用規模・予算）で3軸以上シングルテナント推奨に該当する場合のみ、シングルテナントへの切り替えを本格検討するのが現実的です。
- ベンダーが「マルチテナントだから安全性に問題はない」と説明してきた場合、そのまま信じてよいですか？
そのまま信じず、データ分離のアーキテクチャ（サイロ・プール・ブリッジのどれか）を確認してください。同じ「マルチテナント」でもプールモデルとサイロモデルでは分離レベルが大きく異なり、自社のセキュリティポリシーを満たせるかは中身次第です。
- 一度マルチテナントで契約したあと、シングルテナントに移行することはできますか？
技術的には可能ですが、データ移行やシステム再設計を伴う事実上の再構築になるため、コスト・期間ともに大きな負担が発生します。移行を前提にした計画は現実的ではないため、契約前に4軸でデータ機密性・利用規模・規制対応まで将来の事業展開を見込んで判断することが重要です。
- 予算が限られている中小企業でも、扱うデータの機密性が高ければシングルテナントを選ぶべきですか？
機密性が高い場合でも、まずはマルチテナントのサイロモデル（テナント別インフラ分離）で要件を満たせないか確認するのが現実的です。実質的な分離レベルはシングルテナントに近く、コストを抑えながら機密性要件に対応できる可能性があります。
- マルチテナントの契約前に、稟議書のエビデンスとして残しておくべきことは何ですか？
データ分離アーキテクチャ・ノイジーネイバー対策・SLAの補償内容・インシデント時の切り分け範囲・カスタマイズ可能範囲の5点を、口頭ではなく書面でベンダーから回答を得て残しておくことが重要です。曖昧な回答しか得られない項目は、稟議上のリスクとして明記しておきましょう。
