IaaS・PaaS・SaaS を一気に理解する：クラウド三大サービスモデルの境界・起源・選び方

結論から言うと： IaaS は「インフラ」を売り、OS のインストールからミドルウェア・アプリの構築まで自分でやる。PaaS は「開発・実行プラットフォーム」を売り、利用者は主にコードとデータに集中する。SaaS は「完成品のソフトウェア」を売り、ログインすればすぐ使える。 一言で覚えるなら：自分で細かく制御したいほど IaaS に近づき、運用を減らして速く届けたいほど PaaS に近づき、すぐ使いたいほど SaaS に近づく。 多くの企業のベストプラクティスは「三択」ではなく、組み合わせて使うことだ。

はじめに：なぜ今もこの三つの言葉を語るのか

IaaS・PaaS・SaaS はクラウドコンピューティングにおける最も古典的な三つのサービスモデルである。2011 年、NIST（米国国立標準技術研究所）は《The NIST Definition of Cloud Computing》（SP 800-145）で、これらをクラウドの三大サービスモデルとして正式に定義した。

十数年が経った今でも、この概念は古びるどころか、むしろ重要性を増している。コンテナ、Serverless、AI プラットフォームが次々と登場し、新しいプロダクトの宣伝文句は多種多様だが、「技術スタックのどの層を誰が管理するのか」という原点に立ち返れば、ほとんどのクラウドサービスは即座に位置づけられる。本記事はこの原点から出発し、三つのモデルの定義・責任境界・歴史的起源・現在の主要プロダクト・選び方を一気に整理する。

一、三つのモデルとは何か：本質は「技術スタックを誰が管理するか」

まず技術スタック全体を見てみよう。下から順に、物理データセンター、サーバーとネットワーク機器、仮想化層、OS、ランタイムとミドルウェア、アプリケーションコード、そして最上位にデータと業務設定がある。三つのモデルの違いは、本質的にクラウド事業者がどの層まで面倒を見てくれるかの違いである。

エンドユーザー / 事業部門
        │
        ▼
┌──────────────────────────────────┐
│ SaaS：完成品アプリ                 │ ← CRM / メール / コラボレーション
├──────────────────────────────────┤
│ PaaS：マネージド実行プラットフォーム │ ← Web App / コンテナ基盤 / FaaS
├──────────────────────────────────┤
│ IaaS：計算 / ストレージ / ネットワーク│ ← 仮想マシン / ブロックストレージ / VPC
├──────────────────────────────────┤
│ 物理データセンター / サーバー / 回線  │
└──────────────────────────────────┘

• IaaS（Infrastructure as a Service）：クラウド事業者が仮想化された計算・ストレージ・ネットワークを提供する。OS より上——OS の導入、パッチ適用、ミドルウェアやアプリの構築——はすべて利用者の責任だ。「クラウド上のマシンルームを借りる」に最も近い。
• PaaS（Platform as a Service）：OS・ランタイム・データベース/ミドルウェアなどを事業者がマネージドで提供し、利用者は主にコードを書き、データを管理する。「調理器具一式のそろったキッチンを借りる」——食材を持ち込んで料理するだけでいい。
• SaaS（Software as a Service）：事業者がそのまま使えるソフトウェアを提供し、ログインすれば即利用できる。残る関心事はアカウント、データ、権限、業務フローの設定だけだ。「レストランで料理を注文する」に最も近い。

料理のたとえで通して言えば：オンプレミスの自社データセンターは土地の購入から建物まで全部自前。IaaS は水道・電気・ガスの通ったスケルトンのキッチンを借り、鍋や食器は自分で持ち込む。PaaS は調理器具一式付きのキッチンを借りて、食材だけ持って料理する。SaaS はレストランに行って、出てきた料理をそのまま食べる。

二、責任と管理の境界：コントロールと運用負担は同時に減っていく

次の表は Azure と AWS の責任共有モデル（Shared Responsibility Model）にもとづいて整理したものだ。個別のプロダクトには例外もあるが、大きな方向性は極めて安定している：IaaS から SaaS へ進むほど、利用者のコントロールは減り、運用負担も減る。

特に注意したい点が二つある。

1. どのモデルを選んでも、「データ・ID・権限」は常に利用者自身の責任である。 誰がどのデータにアクセスできるかを、クラウド事業者が代わりに管理してくれることはない。クラウド上のセキュリティ事故の多くは、プラットフォーム自体の侵害ではなく、利用者側の権限設定ミスに起因している。
2. 責任の境界は、同時に能力の境界でもある。 OS へのコントロールを手放すことは、OS 層での深いカスタマイズ能力を手放すことでもある。選定で問うべきは「どのモデルが先進的か」ではなく、「自分はどの層までコントロールする必要があるか」だ。

三、どこから来たのか：タイムシェアリングから NIST 標準定義まで

この三つのモデルは突然現れたわけではない。その思想は半世紀以上前にさかのぼる。

• 1960 年代 — タイムシェアリング：複数のユーザーが高価な大型計算機を共有する。「計算資源の共有」という発想の原点。
• 1990 年代 — ASP（Application Service Provider）：ソフトウェアの「オンラインレンタル」が始まる。SaaS の前身と言えるが、当時のネットワークとアーキテクチャの制約で、多くの ASP は成功しなかった。
• 1999 年 — Salesforce がクラウド CRM を開始：「No Software」を掲げ、企業向けソフトウェアをサブスクリプション型のオンラインサービスに変えた。SaaS のビジネスモデルがここでブレイクする。
• 2006 年 — AWS が S3 と EC2 を発表：ストレージと計算力が初めて「従量課金の公共資源」になった。IaaS の決定的な爆発点である。
• 2007 年 — Heroku 創業：git push するだけでデプロイできる究極の体験。「開発者体験ファースト」のマネージドアプリケーションプラットフォームを定義し、PaaS の初期ブームを牽引した。
• 2008 年 — Google App Engine 公開：「大規模自動スケーリング」のマネージドプラットフォームを大手の手本として確立。古典的な「純粋 PaaS」の代表だ。
• 2010 年 — Microsoft Azure 商用化：クラウドプラットフォームが大企業の調達リストに載るようになる。
• 2011 年 — NIST が SP 800-145 を発行：IaaS・PaaS・SaaS は業界の慣用語から標準定義へ昇格した。
• 2020 年代 — コンテナ・Serverless・AI のプラットフォーム化：PaaS と SaaS の境界は進化を続け、「XaaS」ファミリーは拡張し続けている。

「各モデルのブームを最も象徴するのは誰か」とだけ問うなら、比較的手堅い答えはこうだ：SaaS は Salesforce、IaaS は AWS、PaaS は Heroku と Google App Engine——前者は開発者文化とデプロイ体験を定義し、後者は大手によるマネージドプラットフォームの能力の規範を打ち立てた。

四、2026 年の主要プロダクト

まず市場の見え方について：IaaS の市場構図が最も明瞭で、PaaS は最も分散しており、SaaS は最も細分化されている。 以下は公式資料と、公開されている調査機関のデータ（Synergy Research、Gartner、Forrester、IDC など）を優先的に参照した。時点は 2026 年 7 月である。

IaaS：ハイパースケーラーの主戦場

Synergy Research Group のデータによれば、2026 年第 1 四半期のグローバルパブリッククラウドインフラ市場では、AWS が約 28%、Microsoft Azure が約 21%、Google Cloud が約 14% のシェアを持ち、三社が第一グループを固めている。

PaaS：「純粋マネージドプラットフォーム」から「クラウドネイティブアプリケーションプラットフォーム」へ

PaaS 層は形態の変化が最も大きい。Microsoft は 2025 年の Gartner クラウドネイティブアプリケーションプラットフォームのマジック・クアドラントでリーダーに位置づけられ、OpenShift は 2025 年の Gartner コンテナ管理のクアドラントでリーダーの一つだ。一方、歴史的な先駆者である Heroku は、公開報道によれば 2026 年に sustaining engineering（維持フェーズ）に入ったとされる。これは PaaS の重心が「マネージドアプリケーションプラットフォーム」から「クラウドネイティブアプリケーションプラットフォーム、コンテナ基盤、FaaS/Serverless」へ移っていることの証左でもある。

SaaS：あらゆる汎用ソフトウェア領域へ

市場での位置づけの参考として：IDC は Salesforce を 13 年連続でグローバル CRM 市場の第 1 位と認定している。Microsoft の 2025 会計年度では商用シート数が成長を続け、コンシューマー向けサブスクリプションは 8,900 万に達した。Google は Workspace が 30 億人超のユーザーと 1,100 万超の有料顧客をカバーすると公表している。

中国発のコラボレーション SaaS では Lark（飛書） も注目株だ。ただしこれは Microsoft 365 や Google Workspace と同じ「コラボレーション SaaS」の軸で比較すべきもので、CRM 系 SaaS と直接比べる対象ではない。

五、どう選ぶか：シンプルな意思決定の流れ

選定は「ニーズの本質」から出発し、三つの問いを順に立てるとよい。

問い 1：必要なのは「完成品の業務ソフトウェア」か？ メール、文書コラボレーション、CRM、人事、カスタマーサポート、会計……答えが Yes なら、まず SaaS を見る。経験則はこうだ：自社のコアな差別化要因にならないソフトウェア能力は、「作る」より先に「買う」を検討すべきである。

問い 2：アプリは自分たちで開発するが、運用は持ちたくないか？ Web/API アプリを速く開発してリリースしたい、チームは大きくない、OS・ランタイム・パッチ・スケーリングを自分で面倒みたくない——なら PaaS が第一候補だ。プラットフォームの制約と一定のベンダーロックインを受け入れる代わりに、デリバリー速度を手に入れる。大企業・マルチクラウド・強いガバナンス要件の環境では、OpenShift のような「クラウドネイティブアプリケーションプラットフォーム」の方が従来型の純粋 PaaS より適していることが多い。

問い 3：下位レイヤーへの完全なコントロールが必要か？ レガシーシステムのクラウド移行、ネットワーク/セキュリティ/ミドルウェアの細かなカスタマイズ、GPU・ベアメタル・非標準アーキテクチャ——これらのシナリオでは IaaS を優先する。自由度は最大だが、運用・コスト管理・アーキテクチャの能力が最も問われる。

そして多くの企業の実際の着地点は組み合わせである。

• コラボレーションや CRM などの汎用能力 → SaaS
• 顧客向けの新規アプリケーション → PaaS
• レガシーシステムと特殊な計算資源 → IaaS

これが今日の企業クラウドアーキテクチャで最もよく見られる形だ。

六、早見表とまとめ

最後に四つのポイントに凝縮しておく。

1. 三つのモデルの本質的な違いは管理境界である。 IaaS から SaaS へ進むほど、コントロールも運用負担も減っていく。
2. データ・ID・権限は、どのモデルでも常に自分の責任だ。
3. 歴史の座標：SaaS は Salesforce（1999）、IaaS は AWS（2006）、PaaS は Heroku（2007）と Google App Engine（2008）を見ればいい。
4. 選定は三択ではない。「コア競争力かどうか」「下位レイヤーのコントロールが必要かどうか」を軸に、三つを組み合わせて使う。

参考資料

• NIST《The NIST Definition of Cloud Computing》(SP 800-145)
• Microsoft Azure《What are IaaS, PaaS, and SaaS?》および責任共有モデルのドキュメント
• AWS《Our Origins》《Amazon EC2》《Shared Responsibility Model》
• Salesforce 公式の会社沿革、IDC グローバル CRM 市場ランキング
• Google App Engine 公式リリース情報とプロダクトドキュメント
• Synergy Research Group 2026Q1 クラウドインフラ市場データ
• Red Hat OpenShift 公式資料と Gartner/Forrester の公開サマリー
• Microsoft 2025 Annual Report、Google Workspace 公式価格ページとプレスリリース