1.2クラウドサービスの種類と責任共有モデル

クラウドのサービスは数百種類ありますが、「どこまでをクラウド事業者（プロバイダー）が面倒を見て、どこからを自分で管理するか」という1つの軸で整理すると一気に見通しがよくなります。この軸の上に並ぶ代表的な3段階が IaaS・PaaS・SaaS です。左へ行くほど自由度（コントロール）が高い代わりに手間（管理の責任）が増え、右へ行くほど手間が減る代わりに細かい制御はできなくなる——この「自由度と手間のトレードオフ」が、3モデルを理解する核心です。歴史的にも、すべてを自前で抱えるオンプレミスから出発し、まず物理サーバーを仮想化して貸し出す IaaS が生まれ、次にアプリ開発に集中できる PaaS、そして完成品をそのまま使う SaaS へと、「任せられる範囲を増やす」方向に進化してきました。

この軸を「管理スタック」で具体化すると正確に理解できます。下から 物理ハードウェア → 仮想化基盤 → OS → ランタイム/ミドルウェア → アプリケーション → データ という層が積み上がっており、各モデルは「どの層までをプロバイダーが管理するか」で線引きが変わります。オンプレミスは全層が自分、IaaS は OS の手前まで（仮想化基盤まで）がプロバイダー、PaaS は OS とランタイムまでがプロバイダー、SaaS はアプリまでプロバイダー、という具合です。以降、この層の積み上がりを念頭に各モデルを見ていきます。

1.2.1出発点：オンプレミス

3モデルを理解する前に、比較の基準となる オンプレミス（on-premises）を押さえましょう。オンプレミスとは、サーバーやネットワーク機器を自社で購入・所有し、自社の建物やデータセンターに設置して運用する従来型のスタイルです。電源・空調・物理セキュリティ・ハードウェアの故障対応・OS やソフトの更新・バックアップまで、すべてを自分たちで担います。自由度は最大ですが、初期投資（CapEx）が大きく、需要が増えたときの増設にも時間がかかります。クラウドの IaaS・PaaS・SaaS は、この「全部自前」の負担を、段階的にプロバイダーへ移していくものだと捉えると、3モデルの違いがすっきり整理できます。

1.2.2IaaS — インフラを借りる

IaaS（Infrastructure as a Service）は、仮想マシン・仮想ネットワーク・ストレージといった生のインフラを借りるモデルです。プロバイダーは物理サーバー・電源・冷却・仮想化基盤（ハイパーバイザー）までを用意し、利用者はOS から上——OS のインストールとパッチ適用、ミドルウェア、アプリ、データ——を自分で管理します。3モデルの中で最も自由度が高い反面、運用の手間も最も大きくなります。

代表は Azure Virtual Machines（VM） です。ほかにも、同じ VM を自動で増減させる 仮想マシンスケールセット（VMSS）、VM をつなぐ 仮想ネットワーク（VNet）、データを保存する マネージドディスク、入口で負荷を分散する ロードバランサー なども IaaS の構成要素です。これらを組み合わせれば、オンプレミスのデータセンターとほぼ同等の構成を、物理機器を買わずにクラウド上に再現できます。

• リフト＆シフト移行：既存のオンプレ サーバーを、構成をほぼ変えずにクラウドへ「持ち上げて移す」。
• 開発・テスト環境：必要なときだけ VM を立て、終わったら削除してコストを抑える。
• 特殊な OS・ソフト構成：特定の OS バージョンや独自ミドルウェアが必要で、PaaS では収まらない場合。

1.2.3PaaS — 実行基盤を借りる

PaaS（Platform as a Service）は、アプリを動かすための実行基盤（プラットフォーム）を借りるモデルです。OS・ランタイム・パッチ適用・スケーリングの土台はプロバイダーが管理し、利用者はアプリのコードとデータに集中できます。サーバーの面倒（OS 更新やセキュリティパッチ）から解放されるため、開発スピードが上がるのが最大の利点です。

代表例は、Web アプリをデプロイするだけで動く Azure App Service、フルマネージドのリレーショナル DB である Azure SQL Database、グローバル分散の NoSQL である Azure Cosmos DB などです。OS の存在を意識せずスケールや冗長化を任せられるため、「インフラは任せたいが、アプリの作りは自分で決めたい」という多くの開発現場の標準的な選択肢になっています。

1.2.4SaaS — 完成したソフトを使う

SaaS（Software as a Service）は、完成したソフトウェアを、ブラウザなどからそのまま利用するモデルです。インストールもサーバー管理も不要で、申し込めばすぐ使え、更新やバックアップもプロバイダー任せ。利用者が管理するのは基本的に自分のデータとアカウント設定だけです。

代表例は Microsoft 365（メールの Exchange Online、Teams、OneDrive など）や Dynamics 365（営業・会計などの業務アプリ）です。手間は最小ですが、ソフトの仕様はプロバイダーが決めるため、細かいカスタマイズの自由度は最も低くなります。「車輪の再発明」をせず、メールや会計のようなどの会社も必要とする定型業務を、最短で使い始めたいときに最適です。

1.2.5発展：サーバーレスと FaaS

PaaS をさらに突き詰めたのが サーバーレス で、その代表が FaaS（Function as a Service）＝ Azure Functions です。サーバーの存在を一切意識せず、イベント（HTTP 要求やキューへの投入、タイマーなど）が来たときだけコードが実行され、実行した分（時間・回数）だけ課金されます。待機中の費用がほぼゼロになるため、たまにしか動かない処理や、夜間バッチ・通知・自動化に向きます。「サーバーレス」という名前ですが、裏ではプロバイダーがサーバーを動かしています——利用者がサーバーを意識・管理しなくてよい、という意味です。AZ-900 では「サーバーレス＝サーバー管理が不要で、使った分だけ課金」という性質を押さえれば十分です。

1.2.63モデルの比較

1.2.7どれを選ぶ？ 選定の考え方

モデル選びに唯一の正解はなく、要件（自由度・スピード・運用負荷・コスト）に照らして決めるのが原則です。迷ったら「できるだけ右（任せられる方）を選び、要件が許さないときだけ左へ寄せる」と考えると失敗しにくくなります。次の表は、よくある要望に対するおおまかな指針です。

1.2.8シナリオで理解する

1.2.9責任共有モデル

クラウドのセキュリティを語るうえで最重要の考え方が 責任共有モデル です。これは「セキュリティと運用の責任を、プロバイダーと利用者で分担する」という取り決めで、どこまでが事業者の責任で、どこからが自分の責任かをレイヤー（層）ごとに定めます。重要なのは、この境界がサービスモデルによって動くこと。IaaS では利用者が OS から上を持つので責任範囲が広く、SaaS ではアプリまで事業者が見るので責任範囲が狭くなります。「クラウドに載せたから安全」ではなく、自分の責任範囲は自分で守る——これがクラウドセキュリティの出発点です。

次の表は、代表的なレイヤーごとに「誰の責任か」を3モデルで並べたものです（◎＝その責任を主に負う側）。上のレイヤーほど利用者寄り、下のレイヤーほどプロバイダー寄りになり、IaaS→PaaS→SaaS と進むにつれて利用者の◎が減っていくのが読み取れます。

モデル別に具体化すると分かりやすくなります。IaaS の VM を使うなら、OS のパッチ適用・ウイルス対策・アプリの脆弱性対応まで利用者の仕事です。PaaS の App Service なら OS とランタイムの更新は事業者がやってくれるので、利用者はアプリのコードと設定（認証・アクセス制御）に責任を持ちます。SaaS の Microsoft 365 では、ソフトの維持は事業者任せでよく、利用者の主な仕事は「誰に・どのデータへのアクセスを許すか」という ID とデータの管理に絞られます。どのモデルでも“データ・ID・デバイス”だけは必ず手元に残る、という一点を軸に考えると整理できます。

1.2.10周辺知識：オンプレミスとの位置づけ

この3モデルの左隣に オンプレミス（自社で物理サーバーまで所有・管理）を置くと、全体像がつながります。オンプレミス→IaaS→PaaS→SaaS と右へ進むほど、管理の手間と前払いの投資（CapEx）が減り、その代わり事業者へ委ねる範囲が増えるという一貫した流れです。実際の企業では、規制の厳しいシステムはオンプレミスや IaaS、社内の定型業務は SaaS、自社開発の Web サービスは PaaS、というように複数モデルを組み合わせて使うのが普通です。「どれが正解」ではなく、要件（自由度・スピード・コスト・コンプライアンス）に応じて選ぶ、という視点が大切です。

1.2.11この節のまとめ

• 3モデルは「自由度↔手間」の1軸：IaaS＝インフラ（自由・手間大）／PaaS＝実行基盤（中庸）／SaaS＝完成ソフト（手間小・自由小）
• 例：VM=IaaS／App Service・SQL Database=PaaS／Microsoft 365=SaaS。さらに Azure Functions=サーバーレス/FaaS
• 責任共有モデル：境界はモデルで動く。データ・ID・デバイスは常に利用者／物理は常にプロバイダー
• オンプレ→IaaS→PaaS→SaaS で手間と CapEx が減り、委ねる範囲が増える。実務は複数モデルの組合せ