Notta

【NIST準拠】SaaSとは｜PaaS・IaaS・ASPとの違いと選び方の基準

お役立ち記事

Share

Notta

Check!

  • SaaSはクラウド3分類のうち「完成ソフト提供型」（NIST準拠）
  • 企業のクラウド利用率は80.6%（総務省・2024年）
  • 選定はISMAP・個人情報保護・解約条件の3点が起点

「SaaS（サース）」という言葉は耳にするものの、「PaaSやIaaSと何が違うのか」「ASPやオンプレミスとどう違うのか」を正確に説明できる人は意外と少ない。総務省「令和7年版 情報通信白書」によれば、企業のクラウドサービス利用率は2024年に80.6%に達しており、もはやクラウド・SaaSは特別な選択肢ではなく業務基盤そのものとなった。本記事では、米国NIST（国立標準技術研究所）の国際標準「SP 800-145」と総務省の公式定義に基づき、SaaSの定義・PaaS/IaaS/ASPとの違い・マルチテナント構造・ISMAP制度・選定基準までを、個人事業主・中小企業・中堅大企業のいずれの読者にも適した粒度で体系的に整理する。

おすすめ記事

目次

開く

閉じる
  1. SaaSとは何か｜NIST・総務省の公式定義
  2. SaaS・PaaS・IaaSの違い｜クラウド3分類と責任分界点
  3. SaaSとASP・オンプレミスの違い｜歴史的な経緯と現在地
  4. SaaSの基本構造｜マルチテナントとサブスクリプション
  5. 日本企業のクラウド・SaaS利用状況｜2024年は80.6%が利用
  6. SaaSのセキュリティと信頼性｜ISMAP制度と利用者責任
  7. SaaS選定の前に確認すべき5つの基準
  8. よくある質問（FAQ）
  9. まとめ｜SaaSの本質は「責任分界の再設計」
  10. 参考文献
  11. 関連記事

SaaSとは何か｜NIST・総務省の公式定義

SaaSは「Software as a Service」の略で、サービス事業者がクラウド上で運用しているソフトウェアを、利用者がネットワーク経由で使う形態のクラウドサービスを指す。米国NIST（National Institute of Standards and Technology／国立標準技術研究所）が発行する「SP 800-145：The NIST Definition of Cloud Computing」は、SaaSを含むクラウドコンピューティングの国際的な参照定義として、日本の総務省・経済産業省の各種ガイドラインや、政府情報システムのセキュリティ評価制度（ISMAP）の基礎にも採用されている。

NIST SP 800-145におけるSaaSの定義は次のとおりである。「利用者は、提供事業者のクラウドインフラ上で稼働するアプリケーションを使用できる。利用者はWebブラウザのようなシンクライアントやプログラムインタフェースから各種クライアントデバイスを通じてアクセスする。利用者は、ネットワーク・サーバー・OS・ストレージ、個別のアプリケーション機能などの基盤を管理または制御しない（限定的なユーザー固有の設定を除く）」。つまりSaaSとは、利用者から見れば「ブラウザでログインすれば、いつでも誰でも、最新版のソフトウェアが使える状態」を実現する仕組みを指す。

SaaSの基本構造｜「提供者⇔ネットワーク⇔利用者」の3層 提供事業者 アプリケーション データ・OS・ミドルウェア サーバー・ストレージ ネットワーク・物理設備 インターネット （HTTPS / API） 利用者（企業・個人） Webブラウザ （PC・スマホ・タブレット） アプリ・API連携 利用者は基盤を 管理しない 出典：NIST SP 800-145 / 総務省「令和7年版 情報通信白書」を基に作成
図1：SaaSは提供事業者がインフラ・アプリ全体を運用し、利用者はネットワーク経由で利用する

総務省「令和7年版 情報通信白書」によれば、企業のクラウドサービス全般の利用率は2024年に80.6%に達した（一部部門含む）。10年前は40%前後だったことを踏まえると、約10年でほぼ倍増している。クラウドサービスはもはや「IT先進企業の選択肢」ではなく、業務基盤そのもの。SaaSはその中で利用者数・サービス本数とも最大の領域を占めるカテゴリで、利用率が高いのは「ファイル保管・データ共有」「社内情報共有・ポータル」「電子メール」「給与・財務会計・人事」「スケジュール共有」といったバックオフィス系の業務領域だと示されている。

SaaS・PaaS・IaaSの違い｜クラウド3分類と責任分界点

NIST SP 800-145はクラウドコンピューティングを「5つの基本特性／3つのサービスモデル／4つの展開モデル」の枠組みで定義している。このうちサービスモデル（IaaS／PaaS／SaaS）の違いは、「提供者がどこまで運用責任を持ち、利用者がどこから先を扱うか」という責任分界点の違いとして理解するのが最も実務的だ。

SaaS / PaaS / IaaS の責任分界点 レイヤー IaaS PaaS SaaS アプリケーション 利用者 利用者 提供者 データ 利用者 利用者 利用者（※） ランタイム・OS 利用者 提供者 提供者 仮想化・サーバー 提供者 提供者 提供者 ストレージ 提供者 提供者 提供者 ネットワーク 提供者 提供者 提供者 ※ SaaSのデータは提供者が物理的に保有・運用するが、所有権・管理責任は利用者にある（個情委ガイドライン） 提供者の責任範囲が広いほど、利用者の運用負担は小さい（IaaS < PaaS < SaaS の順で利用者の責任が縮小） 出典：NIST SP 800-145 を基に作成
図2：レイヤーごとに「提供者／利用者」のどちらが管理するかが異なる

具体的には、IaaS（Infrastructure as a Service）はサーバー・ストレージ・ネットワークといった「ITインフラ」をサービスとして提供し、OSやアプリケーションは利用者側が用意する。PaaS（Platform as a Service）はOS・ミドルウェアまで提供事業者が用意し、利用者は自社のアプリケーションだけを載せる。そしてSaaSでは、アプリケーションそのものまで提供事業者が運用するため、利用者は基本的にWebブラウザでログインして使うだけでよい。IaaSからPaaS、SaaSへと進むほど、利用者の運用負担は小さくなり、自由度は下がる──というのが基本的な対比関係である。

分類提供範囲主な利用者像代表的な用途
SaaSアプリ＋データ管理基盤＋インフラすべて業務担当者・経営層（非エンジニア中心）会計、人事、CRM、グループウェア
PaaSOS・ミドルウェア・実行環境アプリ開発者自社サービス開発・運用基盤
IaaSサーバー・ストレージ・ネットワークインフラエンジニアサーバー仮想化、ファイル基盤、独自システム

SaaSとASP・オンプレミスの違い｜歴史的な経緯と現在地

SaaSと混同されやすい用語にASP（Application Service Provider）とオンプレミス（On-premises）がある。とくにASPは1990年代後半〜2000年代前半にかけて広まった概念で、「Webブラウザでソフトを使う」点ではSaaSと似ているが、技術的な仕組みと提供形態には明確な違いがある。

SaaS / ASP / オンプレミス の対比 SaaS 2000年代〜現在 提供方式 マルチテナント （複数顧客で共有） 課金 月額／年額（サブスク） アクセス Webブラウザ＋API アップデート 提供者が自動反映 （全顧客同時） ASP 1990年代後半〜 提供方式 シングルテナント （顧客ごとに環境） 課金 月額／個別契約 アクセス Webブラウザ中心 アップデート 顧客ごとに個別実施 が一般的 オンプレミス 従来型 提供方式 自社設置 （資産として保有） 課金 買い切り＋保守料 アクセス 社内ネットワーク中心 アップデート 自社で計画・実施
図3：SaaSとASP・オンプレミスは提供方式・課金・更新の三点で性格が分かれる

最大の違いは「マルチテナントか／シングルテナントか」という設計思想にある。SaaSは1つのソフトウェアを多数の顧客で共有するマルチテナント方式を前提に設計されており、提供事業者が機能更新を行えば全顧客に同時反映される。一方でASPは顧客ごとに環境を分けるシングルテナントが基本で、機能更新も顧客単位で個別に実施されることが多かった。この設計の違いが、SaaSの低コスト性・拡張性・全顧客同時アップデートを可能にしている。

オンプレミスは「自社のサーバールームに機器を設置し、ソフトウェアもライセンスを買い切る」従来型の運用形態。経済産業省「DXレポート2.1」「同2.2」では、レガシーシステム（多くがオンプレミス）の維持コストがIT予算の大半を占めることがDX阻害要因として指摘されており、SaaSやクラウドへの段階的な移行が推奨されている。ただしオンプレミスにもデータ主権・カスタマイズ自由度・閉域接続といった強みがあり、業種や規模、扱うデータの性質によっては併用するハイブリッド構成が現実解となるケースも少なくない。

SaaSの基本構造｜マルチテナントとサブスクリプション

SaaSをSaaSたらしめている設計的特徴は、大きく分けて「マルチテナント」「サブスクリプション課金」「ブラウザ／APIアクセス」「自動アップデート」の4点にまとめられる。これらはNIST SP 800-145が示すクラウドの基本特性（オンデマンド・セルフサービス／広範なネットワークアクセス／リソースプール／迅速な伸縮性／計測可能なサービス）の現れとも言える。

マルチテナント構造｜1つのソフトウェアを多数の顧客で共有 SaaSの単一基盤 アプリ・OS・サーバー ストレージ （提供事業者が運用） 顧客A（個人事業主） 自社データ・設定 顧客B（中小企業） 自社データ・設定 顧客C（大企業） 自社データ・設定 顧客D 自社データ・設定 顧客E 自社データ・設定 顧客F … 自社データ・設定 データは論理的に分離されつつ、基盤は共有。コスト低減と自動アップデートを両立する
図4：マルチテナント方式により、多数の顧客が単一の基盤を共有しながらデータは論理的に分離される

マルチテナント方式では、データは論理的に分離（テナント分離）されつつも、アプリケーション本体・OS・サーバーは共有される。この設計により、提供事業者は機能改善を一度実装すれば全顧客に同時反映でき、利用者側はパッチ適用やバージョン管理の手間から解放される。一方で、テナント分離が不適切だと別顧客のデータが見えてしまう「テナント間漏洩」のリスクが生じるため、IPA「クラウド利用者のための情報セキュリティチェックシート」は、テナント分離の方式や暗号化の仕組みをサービス選定時に確認するよう求めている。

課金面の特徴はサブスクリプション（継続課金）である。月額・年額が中心で、ユーザー数・利用量・機能プランによって金額が変動するのが一般的だ。買い切り型ソフトと違い、初期投資は小さいが、利用が長期化すれば総額がオンプレミスを上回るケースもある。経理処理上は資産計上ではなく経費計上となるため、減価償却の負担がない反面、毎期コストが発生し続ける点を踏まえてキャッシュフロー計画を組み立てる必要がある。

日本企業のクラウド・SaaS利用状況｜2024年は80.6%が利用

日本企業のクラウドサービス利用率は、総務省「通信利用動向調査」と「令和7年版 情報通信白書」のデータで継続的に把握できる。2024年は80.6%の企業が「全社」または「一部事業所・部門」でクラウドサービスを利用しており、約10年前の水準と比べてほぼ倍増した。利用が多い業務領域は、「ファイル保管・データ共有」「社内情報共有・ポータル」「電子メール」「給与・財務会計・人事」「スケジュール共有」と、いずれもバックオフィス系のSaaSが上位を占める。

企業のクラウド利用率と業務領域別マップ 企業のクラウド利用率 80.6 % （2024年） 10年で約2倍に増加 2014年 約40% ↓ 2024年 80.6% （総務省・通信利用動向調査） 主要な業務領域別の代表的なSaaSカテゴリ ファイル保管・データ共有 オンラインストレージ／文書管理 社内情報共有・ポータル グループウェア／社内ポータル 電子メール クラウドメール／会議システム 給与・財務会計・人事 会計／給与計算／勤怠管理 スケジュール共有 カレンダー／予約管理 営業支援（CRM／SFA） 顧客管理／案件管理 マーケティング・MA 広告／メール配信／分析 カスタマーサポート 問い合わせ管理／FAQ プロジェクト管理 タスク管理／工数管理 業種特化（Vertical SaaS） 医療／建設／教育／士業など 利用率上位はバックオフィス系。次いで営業・マーケ・サポートに拡大している
図5：クラウド利用率の伸びと、主要な業務領域別SaaSの地図

業務領域別では、近年とくに営業（CRM／SFA）、マーケティング・MA、カスタマーサポートといったフロントオフィス系SaaSの伸びが目立つ。また、特定の業種に特化したVertical SaaS（業種特化型SaaS）──医療・建設・教育・士業・物流などの業界固有の業務を支援するサービス群──も新しい領域として広がっている。これに対し、業種を問わず使われるバックオフィスSaaS（会計・人事など）はHorizontal SaaS（横断型SaaS）と呼ばれることもある。

なお、中小企業庁「2022年版 中小企業白書」第2-3-59図によれば、コミュニケーション分野とバックオフィス分野はクラウド型・パッケージソフトの導入率が高い一方で、セールス分野では約3割、サプライチェーン分野では約4割の企業が依然としてオンプレミス型を中心に運用していると示されている。業務領域ごとに「どこまでクラウド／SaaS化されているか」は段階差が大きく、自社の業務マップと照らし合わせた判断が欠かせない。

SaaSのセキュリティと信頼性｜ISMAP制度と利用者責任

SaaSは便利な反面、「自社のデータを外部の事業者に預ける」構造であるため、セキュリティ・コンプライアンスの確認が欠かせない。日本ではこの課題に対する政府の取り組みとして、ISMAP（Information system Security Management and Assessment Program／政府情報システムのためのセキュリティ評価制度）が運用されている。ISMAPは、政府が求めるセキュリティ要件を満たすクラウドサービスをあらかじめ評価・登録し、政府機関等が調達する際に参照する制度で、内閣サイバーセキュリティセンター（NISC）・デジタル庁・総務省・経済産業省が共同で運営している。

ISMAP制度の流れ Step 1 基準策定 国際標準を踏まえた ISMAP管理基準 Step 2 事業者が監査 クラウド事業者が 登録監査機関の監査 Step 3 リスト登録 ISMAP等クラウド サービスリストへ Step 4 調達・利用 政府機関は原則 リストから調達 民間企業もリストを参照可能 ・「ISMAP等クラウドサービスリスト」は公開されており、民間企業のSaaS選定でも参照できる ・SaaS事業者にとっては、ISMAP登録が日本のクラウド市場での信頼性指標として機能する ・SaaS向けに「ISMAP-LIU（Low Impact Use）」の枠組みも整備されており、リスクの低い用途のSaaSに対応 出典：NISC「政府情報システムのためのセキュリティ評価制度（ISMAP）」／デジタル庁「ISMAP-LIU登録促進のための取組み」 SaaS選定時、ISMAP登録の有無は信頼性の客観的な目安として有効に使える
図6：ISMAP制度は政府調達向けの仕組みだが、民間企業もリストを参考にできる

ISMAPで登録されたクラウドサービスは「ISMAP等クラウドサービスリスト」として公開されており、政府機関は原則としてここに掲載されたサービスから調達する。重要なのは、民間企業もこのリストを自社のSaaS選定の参考にできる点だ。日本の政府が求める水準のセキュリティ評価をクリアしている事実は、規模を問わずSaaS選定の重要な信頼性指標として機能する。さらに、SaaSのうちリスクが比較的低い用途向けに「ISMAP-LIU（Low Impact Use）」という枠組みも整備されており、要件を満たしやすくなっている。

セキュリティの観点ではもう一つ、「責任共有モデル」を理解しておきたい。SaaSは多くのレイヤーを提供事業者が運用するが、「データの中身」や「アカウント管理」「アクセス権限の設定」などは利用者側の責任として残る。経済産業省・総務省「AI事業者ガイドライン」や個人情報保護委員会「クラウドサービスでの個人情報取扱い」、IPA「クラウド利用者のための情報セキュリティチェックシート」は、利用者が確認すべき項目として「アクセス制御」「ログ監査」「データ暗号化」「データの所在国」「契約終了時のデータ削除」などを挙げている。「SaaSだから安全」とは言えず、利用者側の運用設計とあわせて初めて安全性が成立する。

SaaS選定の前に確認すべき5つの基準

SaaSの選定では「機能の多さ」より、「自社の業務・規模・コンプライアンス要件にどれだけ合うか」のフィットを見ることが本質的に重要となる。ここでは、個人事業主・中小企業・中堅大企業のいずれの規模でも共通して確認したい5つの基準を整理する。なお、特定サービスを推奨するランキング・比較レビューは景品表示法・ステルスマーケティング規制の観点でリスクが高いため本記事では行わず、あくまで「選び方の枠組み」として整理する。

SaaS選定で確認すべき5つの基準 1 業務フィット：自社の業務に必要な機能が標準でカバーされているか 追加カスタマイズやAPI連携が必要になる範囲を見極める。Vertical SaaSとHorizontal SaaSの判別から 2 セキュリティ・コンプライアンス：ISMAP・暗号化・データ所在の確認 個人情報保護法・業種別ガイドラインへの対応、ISMAP登録の有無、データセンター所在国を確認する 3 運用ガバナンス：ID・権限・SSO・監査ログ SSO（シングルサインオン）、退職者のアカウント停止、操作ログ取得など、人の出入りに耐える設計か 4 解約・データポータビリティ：契約終了時にデータをどう持ち出せるか ベンダーロックイン回避のため、エクスポート形式・データ削除条件・ASPやレガシーへの移行可否を確認 5 コスト構造：月額・ユーザー単価・アップグレードの天井 人数増加や上位プランへの移行で総額がどう変化するか、3年程度の保有コストで試算する 出典：IPA「クラウド利用者のための情報セキュリティチェックシート」／個人情報保護委員会／公正取引委員会「クラウドサービスにおける独占禁止法上の検討」を基に整理
図7：機能性だけでなく、運用・解約まで含めた5つの観点で選ぶ

個人事業主・フリーランスであれば、まずは「無料／個人プランで業務が完結するか」と「データのエクスポートが容易か」の2点を最優先に確認したい。サブスクリプションは積み上がるとコストが膨らむため、1ツールで複数業務を兼ねられるオールインワン型を選びがちだが、解約時のデータ持ち出し条件まで含めて判断すると後悔が少ない。

中小企業では、複数のSaaSを並行利用するケースが多く、ID統合（SSO）と退職時の権限管理が課題になりやすい。10〜50ユーザー規模になれば、Microsoft 365やGoogle Workspaceなどの統合グループウェアをID基盤として、他のSaaSをそこに紐付ける設計が現実解となる。クラウド事業者やSaaSプロバイダのプラン体系で、SSO機能が上位プランにしか含まれていないケースもあるため、初期プラン選定時の確認が欠かせない。

中堅・大企業では、全社ガバナンスの観点から、SaaSの一元管理（SaaS管理プラットフォーム／IDaaS）、ISMAP登録の有無、個人情報保護法・GDPR等の海外法令対応、ベンダーロックイン回避のための代替手段確保、データ所在国の管理など、確認すべき項目が一気に増える。公正取引委員会「クラウドサービスの取引実態に関する報告書」では、クラウド事業者の市場集中とロックインの観点からも、契約条件の精査が重要だと指摘されている。CFO・経理部長・情報システム部長が三者で確認する体制を組むのが安全だ。

よくある質問（FAQ）

Q. SaaS、PaaS、IaaSのうち、中小企業はどれを最優先で考えるべきですか？

A. 一般論として、システムの構築・運用人員を抱えにくい個人事業主・中小企業ほど、SaaSを基本に据えるのが合理的だと整理できます。会計・人事・グループウェアといった「業種を問わない業務領域」はSaaSで揃え、自社固有のシステムが必要な場合にPaaSやIaaSを検討するという階層構造が現実的です。NIST SP 800-145の定義どおり、SaaSはOS・サーバー・ストレージなどの基盤を提供者が運用するため、利用者側の運用負担が最も小さい構造になっています。

Q. SaaSとASPは結局のところ同じものですか？

A. 「Webブラウザで使う」という見え方は似ていますが、技術的・契約的には別物として整理するのが正確です。ASPは1990年代後半に広まった概念で、顧客ごとに環境を分けるシングルテナント方式が一般的でした。SaaSはNIST SP 800-145に基づく明確な定義を持ち、マルチテナント・サブスクリプション・自動アップデートを前提とした設計になっています。現在ではほとんどのWeb型業務ソフトがSaaSとして提供されており、ASPという呼称は次第に使われなくなっています。

Q. ISMAP登録されていないSaaSは安全ではないということでしょうか？

A. そう断定することはできません。ISMAPは政府機関の調達向けに整備された制度であり、評価には相応のコスト・期間がかかるため、対象を限定して登録している事業者も少なくありません。ISMAP未登録のSaaSであっても、ISO/IEC 27001（ISMS）、ISO/IEC 27017（クラウドセキュリティ）、SOC 2 Type II、PCI DSSなどの第三者認証や、IPA「クラウド利用者のための情報セキュリティチェックシート」に沿った確認で安全性を評価することは十分可能です。ISMAP登録は「客観指標の一つ」と位置づけ、自社の要件に合った確認方法と組み合わせるのが現実的です。

Q. SaaSの導入で個人情報保護法上、特に気をつける点はありますか？

A. 個人情報保護委員会「クラウドサービスでの個人情報取扱い」では、SaaS事業者が個人データを「取り扱うことになっている」かどうか、データ所在国がどこか、提供事業者と利用者の契約上の責任分界がどう定められているかが重要なポイントとして整理されています。とくに海外データセンターに保管される場合は、外国にある第三者への提供に関する規制への対応が必要です。SaaS事業者の利用規約・データ処理契約（DPA）・サブプロセッサー一覧などを契約段階で確認する運用が求められます。

Q. 「SaaSオワコン」「SaaSの死」といった議論を見かけました。SaaS導入は今からでも遅くないでしょうか？

A. 海外を中心に「AIの登場でSaaS事業者の価値が再定義される」という議論はあり、SaaS市場の成長率や評価が見直されつつあるのは事実です。一方で、総務省「令和7年版 情報通信白書」が示すとおり、日本企業のクラウドサービス利用率は2024年に80.6%まで伸び、業務基盤としてのSaaSはむしろ重要度を増しています。「SaaSという形態」が消えるのではなく、「AIを内包したSaaS」「業務特化のVertical SaaS」へと中身が進化していると捉えるのが妥当です。導入の判断軸は変わらず、本記事の選定5基準（業務フィット／セキュリティ／運用ガバナンス／解約・ポータビリティ／コスト構造）で評価するのが現実的です。

Q. オンプレミスからSaaSへ移行する場合、どこから始めるべきですか？

A. 中小企業庁「2022年版 中小企業白書」のデータでも示されているとおり、まずはコミュニケーション系（メール・グループウェア・スケジュール）とバックオフィス系（会計・給与・勤怠）から段階的にSaaSへ切り替える流れが定着しています。経済産業省「DXレポート2.2」も、レガシーシステム維持のためのIT予算比率を下げ、クラウド・SaaSへの段階移行を通じて「攻めのIT投資」に資源を振り向けることを推奨しています。一気に全システムを置き換えるのではなく、業務影響の小さい領域から検証することが定石です。

まとめ｜SaaSの本質は「責任分界の再設計」

SaaSとは、NIST SP 800-145の定義に従えば「提供事業者のクラウドインフラ上で稼働するアプリケーションを、利用者がWebブラウザやAPI経由で使う形態」を指す。本質を一言でまとめるなら、「ITインフラの所有・運用負担を提供者側に寄せ、利用者は業務に集中する」ための責任分界の再設計だと言える。総務省「令和7年版 情報通信白書」のデータが示すとおり、企業のクラウド利用率は2024年に80.6%に達し、SaaSはもはや一部の先進企業の選択肢ではなく、業務基盤の標準となった。

一方で、「外部に預ける」構造である以上、ISMAP・個人情報保護・解約条件・運用ガバナンスといった利用者側の確認事項は依然として残る。SaaSの選定では、機能の多寡で決めるのではなく、「業務フィット／セキュリティ／運用ガバナンス／解約・ポータビリティ／コスト構造」の5つの観点を、自社の規模と業務に応じて重みづけして判断するのが本筋となる。

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

  1. 自社で利用中のSaaSを棚卸しする。サービス名・契約者・契約金額・主管部署・解約条件をリスト化し、重複契約・休眠アカウントを洗い出す
  2. ISMAPクラウドサービスリストで主要SaaSを確認する。NISC公式サイトでリストを開き、自社で使う／検討中のSaaSが登録されているかを把握する
  3. SaaS選定の社内基準を5つの観点で文章化する。本記事の5基準を雛形に、自社の事業規模・業種に合わせた優先順位（重みづけ）をドキュメントとして1枚にまとめる

参考文献

関連記事

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

あなたへのおすすめ記事

同じカテゴリの記事を探す

同じタグの記事を探す

同じタグの記事はありません

掲載希望の方はこちら
top