レッスン2：IaaS／PaaS／SaaS——3 つの提供形態の階層

このレッスンで学ぶこと

IaaS・PaaS・SaaS の 3 つの提供形態を区別できる
各階層で利用者と事業者の責任分界がどう変わるかを説明できる
ピザ屋の例えで 3 階層を腹落ちさせる
オンプレミス・コロケーション・マネージドサービスの位置づけを把握する
FaaS（サーバーレス）の予告を理解する

前のレッスンでは、クラウドの定義と NIST が示す 5 つの本質的特徴を整理しました。今回のレッスンでは、クラウドサービスを語るときに必ず登場する 3 つの提供形態、IaaS・PaaS・SaaS の階層を扱います。同じ「クラウド」でも、どの階層を借りるかで、利用者の責任範囲も、運用の手間も、コスト構造も大きく変わります。この階層を理解できれば、社内で「うちのシステムは IaaS にすべきか、SaaS で十分か」を話し合えるようになります。

クラウドの 3 階層

クラウドサービスは、提供範囲の広さによって、伝統的に 3 つの階層に分けて語られます。

階層	略称	提供される範囲	代表サービスの例
Infrastructure as a Service	IaaS	サーバー・ストレージ・ネットワークの「インフラ」	Amazon EC2、Azure Virtual Machines、Google Compute Engine
Platform as a Service	PaaS	インフラ＋ OS ＋ DB ＋アプリ実行基盤	Heroku、Azure App Service、Google App Engine
Software as a Service	SaaS	業務に使えるアプリケーションそのもの	Microsoft 365、Salesforce、Slack、Workday

「Infrastructure（インフラ）」「Platform（プラットフォーム）」「Software（ソフトウェア）」と、提供される範囲が下から上に積み上がるイメージです。「下の階層」を借りるほど自由度が高く、「上の階層」を借りるほど運用が楽になります。

階層を図で見る

3 階層を構成要素のレイヤーで描くと、次のようになります。

flowchart TD
  subgraph On["オンプレミス（自社所有）"]
    O1[アプリケーション]
    O2[ランタイム・ミドルウェア]
    O3[OS]
    O4[サーバー・ストレージ・ネットワーク]
    O5[電源・空調・建物]
  end
  subgraph IaaS["IaaS"]
    I1[アプリケーション 自社]
    I2[ランタイム・ミドルウェア 自社]
    I3[OS 自社]
    I4[サーバー・ストレージ・ネットワーク 事業者]
    I5[電源・空調・建物 事業者]
  end
  subgraph PaaS["PaaS"]
    P1[アプリケーション 自社]
    P2[ランタイム・ミドルウェア 事業者]
    P3[OS 事業者]
    P4[サーバー・ストレージ・ネットワーク 事業者]
    P5[電源・空調・建物 事業者]
  end
  subgraph SaaS["SaaS"]
    A1[アプリケーション 事業者]
    A2[ランタイム・ミドルウェア 事業者]
    A3[OS 事業者]
    A4[サーバー・ストレージ・ネットワーク 事業者]
    A5[電源・空調・建物 事業者]
  end

上に行くほど自社が管理する範囲（青く塗りたいレイヤー）が減り、事業者に任せる範囲が増えていきます。逆に、上に行くほど「自社の業務に合わせて細かく作り込む自由」は減ります。

💡 ポイント 「クラウド」と一括りに語ると、組織内で議論がかみ合わなくなります。「うちは IaaS に乗せるのか、SaaS で十分か」を最初に決めるだけで、検討の半分は終わります。

ピザ屋の例え

3 階層を「ピザを食べる方法」で例える、業界で有名な比喩があります。

ピザを食べる方法	クラウドでの対応
材料を全部買って、自宅で生地から作って焼いて食べる	オンプレミス
生地と具材は別々に買って、自宅で組み合わせて焼いて食べる	IaaS
出来上がったピザ生地（ベース）を買って、自宅で具材を乗せて焼いて食べる	PaaS
出来上がったピザを注文して、自宅で食べる（皿だけ自分で用意）	SaaS

「皿（運用ルール・社員教育）」だけは、どの形態でも自社で用意します。

この例えで腹落ちすること

どの階層でも「食べる人（利用者）」の責任はゼロにはならない
上の階層に行くほど、楽だけれど、自分の好みに合わせて作り込む自由は減る
下の階層に行くほど、自由だけれど、運用の手間と専門知識が必要になる
「IaaS が一番偉い」「SaaS が一番楽だから最高」というのは正しくない。要件で選ぶ

📝 補足 「材料を全部買って自宅で作る」が「オンプレミスより難しい」と感じる方もいるかもしれません。実際には、オンプレでは小麦の畑から所有する必要はなく、ハードウェアを買うのも事業者からの調達です。比喩の精度はここまでです。

各階層の責任分界

3 階層の本質は、「責任分界」がどこにあるかという問題です。

IaaS の責任分界

IaaS（Infrastructure as a Service）は、サーバー・ストレージ・ネットワーク・データセンターの物理設備を事業者が提供し、その上の OS ・ミドルウェア・アプリケーションの運用を利用者が担う形態です。

事業者が管理：物理サーバー、ハードディスク、物理ネットワーク機器、電源、空調、建物のセキュリティ
利用者が管理：OS のパッチ適用、ミドルウェアの設定、アプリケーションの開発・運用、データ管理、ネットワーク設定（仮想ネットワークの構成）

IaaS の代表例は、AWS の Amazon EC2、Azure の Azure Virtual Machines、Google Cloud の Compute Engine です。仮想マシン（virtual machine：物理サーバー上に作る論理的なコンピューター）を借りて、自社の OS と業務アプリを動かす形が典型的です。

IaaS は「自由度の高さ」が魅力です。OS の種類、ミドルウェアのバージョン、ネットワーク構成を自社の判断で決められます。一方で、運用の手間と OS レベルの専門知識が必要になります。

PaaS の責任分界

PaaS（Platform as a Service）は、IaaS に加えて、OS とアプリ実行基盤（ランタイム・ミドルウェア）を事業者が提供する形態です。

事業者が管理：物理設備、OS、ミドルウェア、アプリの実行基盤（言語ランタイム、Web サーバー、データベースエンジンなど）
利用者が管理：アプリケーションのコード、データ、設定ファイル

PaaS の代表例は、Heroku、Azure App Service、Google App Engine、AWS Elastic Beanstalk です。開発者は「コードをデプロイするだけで動く」状態を得られます。

PaaS の魅力は「OS パッチや実行基盤の運用から解放される」ことです。スタートアップや小規模チームが、運用人員を増やさずにサービスを動かせる利点があります。一方で、対応する言語・ミドルウェアの種類は事業者が決めるため、特殊な要件には合わせづらいことがあります。

SaaS の責任分界

SaaS（Software as a Service）は、業務に使えるアプリケーションそのものを事業者が提供する形態です。

事業者が管理：物理設備、OS、ミドルウェア、アプリケーション本体、アップデート、機能改善
利用者が管理：利用者のアカウント管理、データの入力・管理、利用ルール、業務プロセス

SaaS の代表例は、Microsoft 365、Google Workspace、Salesforce、Slack、Workday、Zoom、Notion、Asana など、業務で使うクラウドサービスのほぼすべてです。

SaaS の魅力は「契約してアカウントを発行すれば、すぐに業務で使える」点です。インフラ・アプリ運用の手間がほぼゼロになります。一方で、自社の業務プロセスを SaaS の仕様に合わせる必要があり、機能のカスタマイズには限界があります。

「上ほど楽、下ほど自由」のトレードオフ

3 階層の責任分界は、「楽さ」と「自由度」のトレードオフを示しています。SaaS は最も楽ですが、業務を SaaS に合わせます。IaaS は最も自由ですが、運用の負担が大きくなります。組織の規模・スキル・予算・業務要件に応じて、どの階層を選ぶか（あるいはレイヤーで使い分けるか）が現場の判断です。

⚠️ 注意 「全部 SaaS にすれば楽」と単純化するのは危険です。SaaS が乱立すると、データが各 SaaS に分散し、退職者管理・コンプライアンス対応が複雑になります。SaaS の利用統制は、レッスン 7 のセキュリティで再び触れます。

オンプレ・コロケーション・マネージドサービスの位置づけ

クラウドの 3 階層の周辺には、いくつかの「中間の選択肢」があります。

コロケーション（colocation）

自社が所有するサーバー機器を、事業者のデータセンターに置かせてもらう形態です。設備（電源・空調・建物・物理ネットワーク）は事業者の責任、ハードウェアと OS 以上は自社の責任になります。災害対策・回線品質・物理セキュリティの観点で、自社建物より優れるため、いまでも採用されます。「ハウジング（housing）」とも呼ばれます。

ハウステッド（hosted）／レンタルサーバー

事業者がハードウェアを所有し、利用者に専有または共有で貸し出す形態。「レンタルサーバー」「専用サーバー」「VPS（Virtual Private Server）」が該当します。NIST のクラウドの 5 つの特徴（特にオンデマンド・セルフサービス、迅速な弾力性、計測可能なサービス）を満たさないことが多く、クラウドとは区別されます。

マネージドサービス（managed service）

事業者が運用を一部または全部代行するサービスです。マネージド DB・マネージド Kubernetes など、特定のソフトウェアの運用を引き受けるサービスを指します。クラウド事業者の標準サービスの多くは、すでにマネージドサービスの性格を持ちます。

FaaS（サーバーレス）

PaaS の先にある形態として、FaaS（Function as a Service：関数単位での実行サービス）があります。利用者は「関数（短いプログラムの断片）」をアップロードするだけで、サーバーの存在を意識せずに処理を実行できます。代表例は AWS Lambda、Azure Functions、Google Cloud Functions です。「サーバーレス（serverless）」と呼ばれ、レッスン 5 で詳しく扱います。

3 階層をどう使い分けるか

実際の業務では、3 階層を組み合わせて使うことが普通です。

メール・チャット・ファイル共有：SaaS（Microsoft 365、Google Workspace、Slack など）
顧客管理・営業支援：SaaS（Salesforce、HubSpot など）
社内業務システム：IaaS または PaaS で自社開発、あるいは SaaS で代替
データ分析基盤：PaaS のデータウェアハウス、または IaaS 上に構築
業務に必須の特殊要件アプリ：IaaS でフル自社開発

経営層が「うちはクラウドにしたい」と言ったとき、現場で起きるのは「どの階層を、どの業務領域に当てるか」の議論です。3 階層を区別する語彙を持つことで、その議論を建設的に進められます。

講師の現場メモ：「ピザの例えで腹落ちした製造業の現場」

私（山下）が外資系クラウド事業者でソリューションアーキテクトをしていた頃、ある中堅の食品製造業の経営層に説明した日のことです。

「クラウドって AWS とか Azure とか、いろいろあるよね。違いがわからない」「IaaS と SaaS、どっちが正解？」「うちは食品工場だから、IT は素人なんだ」

私は数枚のスライドで NIST の定義と 3 階層を説明しましたが、社長の表情は曇ったままです。15 分経っても理解の手応えがありません。

そこで、私は資料を閉じてホワイトボードに向かい、「ピザを食べる方法で例えますね」と切り出しました。

材料から作る、生地から作る、ベースを買う、出来上がりを注文する——。

5 分経った頃、社長が膝を打って「あ、それなら『うちは出来上がりを注文する』でいいよ。皿だけ自分で用意するんだろう？」と言ってくれました。常務も「ただ、特殊な仕込みが必要な料理（基幹システム）だけは生地から作るほうがいいな」と続けました。経営層自身が「うちの業務領域ごとに、IaaS と SaaS を使い分けたい」という意思決定の言葉を発するようになりました。

私はその日、技術用語より腹落ちする比喩のほうが、ずっと業務判断を進めると痛感しました。本コースで「ピザの例え」を入れたのは、その夕方のホワイトボードの空気を、皆さんにも体験していただきたかったからです。

まとめ

このレッスンでは、以下のことを学びました。

クラウドサービスは IaaS・PaaS・SaaS の 3 階層で語られる
IaaS はインフラ、PaaS はインフラ＋実行基盤、SaaS はアプリそのものを事業者が提供
上に行くほど楽だが自由度が下がり、下に行くほど自由だが運用の手間と専門知識が必要
ピザ屋の例え：材料から作る（オンプレ）、生地から（IaaS）、ベースに乗せて（PaaS）、出来上がり（SaaS）
コロケーション・ホスティング・マネージドサービスは「中間の選択肢」、ホスティングは NIST 5 特徴の多くを満たさず、クラウドとは区別される
FaaS（サーバーレス）は PaaS の先にある形態で、レッスン 5 で詳しく扱う
業務領域ごとに 3 階層を使い分けるのが現実の運用

次のレッスンでは、主要クラウドプロバイダー（AWS・Azure・GCP）の特徴と、日本の選択肢、業界別の選定傾向を整理します。

確認クイズ

このレッスンの理解度をチェックしましょう。