SaaSの技術構造｜XaaSの全体像

2026/08/25 お役立ち記事

Check!

XaaSの3層構造とSaaSの位置づけがわかる
マルチテナント方式とスケーラビリティの仕組みがわかる
Vertical・Horizontal SaaSの違いがわかる

複数の企業が同じSaaSを使っているのに、他社のデータが見えることはありません。この仕組みを支えているのがマルチテナントという技術です。本記事では、SaaSとIaaS・PaaSの技術構造を、クラウドの全体像(XaaS)として整理します。SaaS・PaaS・IaaS・ASPの基本的な違いや選び方はSaaSとPaaS・IaaS・ASPの違いを解説した記事で整理しています。

クラウドの技術構造とSaaSの位置づけ(XaaS全体像)

NIST(米国国立標準技術研究所)のSP 800-145に基づくと、クラウドは3層構造で整理でき、SaaSはその中で完成したアプリケーションをそのまま利用する形態に位置づけられます。SaaSでは、利用者が管理するのはユーザー設定や自社データに限られ、PaaSとIaaSはそれより下層の技術基盤に位置します。この3層をまとめて「XaaS(X as a Service)」と呼ぶこともあります。

SaaSを支える仕組み

マルチテナント方式とスケーラビリティという2つの技術が、SaaSの仕組みを支えています。マルチテナント方式では、複数の顧客が1つのアプリケーション基盤を共用しながら、データは論理的に分離される仕組みが取られています。スケーラビリティによって、利用者数の増減にもシステム側で柔軟に対応できます。

層	技術的な位置づけ
SaaS	完成アプリケーション(マルチテナントで提供)
PaaS	開発・実行基盤
IaaS	サーバー等のインフラ

図1:XaaSの3層構造

Vertical SaaSとHorizontal SaaSの違い

Vertical SaaS(業界特化型)は特定業界の業務慣行に合わせて設計され、Horizontal SaaS(業務横断型)は業種を問わず使える機能を提供するという発展方向の違いがあります。技術基盤としては同じマルチテナント方式を採用していても、対象とする業務範囲が異なります。

Horizontal SaaSの中でも、社内のスケジュール共有やファイル管理を担うグループウェアは、マルチテナント方式による技術基盤を体感しやすい身近な例です。

グループウェアについて見る →

SaaS・PaaS・IaaSの関係

3層は独立した選択肢ではなく、SaaSベンダー自身がPaaSやIaaS上にサービスを構築しているという関係にあります。利用者から見える層がSaaSであっても、その裏側には下層の技術基盤が存在しています。

マルチテナント方式のメリットと注意点

マルチテナント方式は、SaaSベンダー側にとってはコスト効率と機能改善のスピードで大きなメリットがある一方、利用者側にとっては注意しておきたい特性もあります。

ベンダー側にとってのメリットは、すべての顧客が同一のシステム基盤を共有するため、インフラの維持コストを顧客数で分散でき、結果として利用料金を抑えやすくなる点です。また、新機能の追加やセキュリティパッチの適用も、基盤側で一度実施すれば全顧客に同時に反映されるため、シングルテナント方式のように顧客ごとに個別対応する必要がなく、開発・運用の効率が高くなります。この効率性が、SaaSの月額料金がシングルテナント型のASPやオンプレミス型のシステムと比べて抑えられやすい理由の一つになっています。

一方、利用者側が注意しておきたい点として、個別のカスタマイズ性には限界がある点が挙げられます。マルチテナント方式は、すべての顧客が同じシステム基盤を使う前提のため、特定の顧客だけのために大幅な機能改修を行うことは基本的にできません。自社の業務フローに合わせて大きくカスタマイズしたい場合は、マルチテナント型のSaaSではなく、個別に構築するシステムやシングルテナント型のサービスを検討する必要があります。また、ベンダー側でシステム障害が発生した場合、同じ基盤を共有する全顧客が同時に影響を受ける可能性がある点も、マルチテナント方式ならではの特性として理解しておくとよいでしょう。

技術構造の理解でよくある失敗パターン3つ

マルチテナントとシングルテナントを混同する、データの論理的分離を物理的分離と誤解する、Vertical・Horizontalの違いを技術基盤の違いと誤解するという3つが、技術構造の理解でよく見られる失敗の典型です。

失敗パターン1:マルチテナントとシングルテナントを混同する。複数顧客での共用方式と、個別システムの違いを取り違えるケースです。両者の仕組みの違いを理解することが回避策になります。

失敗パターン2:データの論理的分離を物理的分離と誤解する。同一基盤上でのデータ分離の仕組みを誤解し、セキュリティ上の懸念を過大評価するケースです。論理的分離の仕組みを理解することが回避策になります。

失敗パターン3:Vertical・Horizontalの違いを技術基盤の違いと誤解する。両者は対象業務範囲の違いであり、技術基盤自体は共通していることを見落とすケースです。分類の観点を正しく理解することが回避策になります。

API連携とiPaaSの位置づけ

複数のSaaSを組み合わせて使う企業が増えるなか、SaaS同士をつなぐAPI(アプリケーション間の連携インターフェース)と、その連携を仲介するiPaaS(Integration Platform as a Service)という仕組みも、SaaSの技術構造を理解するうえで押さえておきたい要素です。

APIは、あるSaaSが持つデータや機能を、別のシステムから呼び出して利用できるようにする仕組みです。たとえば、会計SaaSと顧客管理SaaSをAPIで連携させることで、顧客管理システムに登録した取引先の情報を、会計システム側で二重入力せずに利用できるようになります。多くのSaaSは、自社の機能を外部から利用できるようAPIを公開しており、このAPIがどれだけ充実しているかが、他システムとの連携のしやすさを左右します。

iPaaSは、複数のSaaS間のAPI連携を、プログラミングの専門知識がなくても設定できるようにする中間層のサービスです。SaaSの数が増えるほど、個別にAPI連携を実装する手間が積み重なっていきますが、iPaaSを介することで、画面上の設定だけで複数のSaaS間のデータ連携を構築できるようになります。技術構造としては、SaaS・PaaS・IaaSという3層モデルとは別の軸に位置する概念ですが、複数のSaaSを組み合わせて使う場面が増えている今、あわせて理解しておく価値のある仕組みです。

SaaSのセキュリティと可用性をどう考えるか

マルチテナント方式のSaaSを選ぶ際は、データの論理的分離がどのように実装されているかに加えて、可用性(サービスが継続して使える状態を保つ仕組み)をベンダーがどう担保しているかも技術構造の一部として確認しておく価値があります。SaaSは利用者側がインフラ層を直接管理しない形態であるため、可用性の担保はベンダー側の責任範囲になります。

データの論理的分離には、いくつかの実装パターンがあります。代表的なものとして、1つのデータベース内で顧客ごとにIDを分けて管理する方式や、顧客ごとに独立したスキーマ(データベース内の区画)を割り当てる方式などが挙げられます。どちらの方式でも、アプリケーション層とデータベース層の双方でアクセス制御が設計されていることが前提となり、片方の制御だけに依存する設計は、実装の不備が生じた場合にデータ漏えいのリスクにつながりかねません。SaaSを選定する際は、こうした分離の実装方式そのものを外部から確認することは難しいため、第三者機関によるセキュリティ認証(ISMS認証やSOC2報告書など)を取得しているかどうかが、間接的な判断材料の一つになります。

可用性については、SaaSベンダーがSLA(サービス品質保証、稼働率の目標値などを定めた契約条件)を公開しているかどうかを確認するとよいでしょう。マルチテナント方式では、システム基盤を共有する性質上、大規模障害が発生した場合に複数の顧客が同時に影響を受ける可能性があります。このリスクを完全にゼロにすることはできませんが、ベンダーがどの程度の稼働率を目標としているか、障害発生時の通知体制やバックアップ方針をどう定めているかを事前に確認しておくことで、自社の業務継続計画(BCP)に組み込む際の判断材料になります。特に基幹業務に近いSaaSを導入する場合は、可用性に関する情報開示の姿勢そのものも、ベンダー選定の技術的な評価軸として考慮しておきたいポイントです。

SaaS選定時に確認したい技術的なチェックポイント

ここまで見てきた技術構造をふまえると、SaaSを選定する際に確認しておきたい技術的な観点は、大きく分けてデータ分離の考え方、拡張性、連携のしやすさの3つに整理できます。これらは導入後に変更しにくい要素であるため、契約前の段階で確認しておくことが望ましいポイントです。

1つ目は、データ分離の考え方です。前述のとおり、マルチテナント方式では複数顧客が同一の基盤を共有するため、自社のデータがどのような単位で論理的に分離されているか、契約書や公開資料で確認できる範囲を把握しておくことが望ましいでしょう。特に、業界によっては監督官庁のガイドラインでデータの保管場所や管理体制に関する要件が定められている場合があるため、該当する業種であれば事前に自社のコンプライアンス部門とも確認しておくと安心です。

2つ目は、拡張性です。スケーラビリティは前述の通りSaaSの基本的な特性ですが、実際の対応幅はベンダーやプランによって差があります。利用ユーザー数やデータ量が増加した場合に、プラン変更だけで対応できるのか、それとも別途カスタム対応が必要になるのかは、事業の成長速度によっては重要な判断材料になります。

3つ目は、連携のしやすさです。前述のAPIやiPaaSの観点にも関わりますが、自社が既に利用している他のSaaSと連携できるかどうかは、業務効率に直結します。APIが公開されているか、主要なiPaaSサービスとの連携実績があるかを確認しておくことで、将来的にSaaSの利用数が増えた場合でも、データ連携の手間を抑えやすくなります。

導入担当者が押さえておきたい社内説明のポイント

SaaSの技術構造は、情報システム部門だけでなく、経営層や導入部門への説明が必要になる場面も多いテーマです。マルチテナント方式によってコストが抑えられている仕組みや、データが論理的に分離されている点、ベンダー側の可用性への取り組みなどを、専門用語をかみ砕いて共有できると、社内での合意形成がスムーズになります。特に、他社とシステム基盤を共有することへの不安が社内で挙がりやすい場合は、論理的分離の仕組みと第三者認証の取得状況をあわせて説明することで、懸念に対する具体的な根拠を示しやすくなります。

よくある質問(FAQ)

Q1. ASPとの関係はどうなっていますか?

A. ASPはSaaSに先行する形態で、シングルテナント方式という点でSaaSとは技術的に異なります。

Q2. プライベートクラウド上でSaaSを運用できますか?

A. 運用形態によって可能な場合があり、提供事業者の仕組みによって異なります。

Q3. マルチテナント環境でのデータ隔離はどう行われますか?

A. 同一のシステム基盤上で、顧客ごとにデータを論理的に分離する仕組みが取られています。

Q4. Vertical・Horizontal SaaSはどう選べばよいですか?

A. 特定業界の業務慣行に合わせたい場合はVertical、幅広い業務に使いたい場合はHorizontalが適しています。

Q5. XaaSとは何ですか?

A. SaaS・PaaS・IaaSといったクラウドの3層をまとめて指す呼び方です。

Q6. SaaSベンダーはどの層の上でサービスを構築していますか?

A. 多くの場合、PaaSやIaaSといった下層の技術基盤の上にSaaSを構築しています。

まとめ｜今日からできる3つのこと

マルチテナントとシングルテナントを区別する:混同しません。
論理的分離の仕組みを理解する:誤解しません。
Vertical・Horizontalを対象業務範囲で区別する:技術基盤の違いと混同しません。

この記事に興味を持った方におすすめ