クラウドの形態はIaaS・PaaS・SaaSの3つで語られますが、違いは「機能の多さ」ではありません。システムを層に切ったとき、どこまでを提供者が持ち、どこからが利用者の担当になるか——その線の位置だけが違います。この線を責任分界点と呼び、線が決まると「パッチは誰が当てるか」「バックアップは誰が取るか」「ログはどこまで見えるか」が自動的に決まります。逆に言えば、形態を取り違えると担当の答えを全部外します。
クラウドは提供者（サービスを用意して貸す側）と利用者（借りて自社の業務を載せる側）の2者で成り立ちます。貸し借りの単位が違うのが3形態で、IaaSは仮想サーバ・仮想ネットワーク・ストレージといった基盤（インフラ）を貸す形態、PaaSはその上にOSと実行環境（ミドルウェア・データベース・言語処理系）まで載せてアプリを動かす土台を貸す形態、SaaSは業務アプリそのものを完成品として使わせる形態です。「as a Service」＝所有せず、使った分だけ借りるという点は3つに共通します。
層で見る責任分界点
システムを下から物理設備 → 仮想化基盤 → OS → ミドルウェア → アプリケーション → データの6層に切ります。形態が変わると、この積み木のどの高さで線が引かれるかが変わります。
| 層（上ほど業務に近い） | オンプレミス | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| データ（業務データ・設定・利用者アカウント） | どの形態でも利用者 | |||
| アプリケーション | 利用者 | 提供者 | ||
| ミドルウェア（実行環境・データベース） | 利用者 | 提供者 | ||
| OS | 利用者 | 提供者 | ||
| 仮想化基盤（ハイパバイザ） | 利用者 | 提供者 | ||
| 物理設備（機器・電源・建物） | 利用者 | 提供者 | ||
階段状に線が上がっていくのが分かります。IaaSはOSの下、PaaSはミドルウェアの上（アプリの下）、SaaSはアプリの上に線が引かれ、いちばん上のデータだけは3形態とも利用者側に残ります。この「階段」と「データは常に利用者」の2点が、責任分界点の図の全部です。
この考え方を提供者側は責任共有モデルと呼びます。「共有」といっても半分ずつ持ち合うのではなく、層で上下に分割して、それぞれが自分の側を全部持つという意味です。境目は契約書（利用規約・SLA）に書かれるので、実務では契約で線の位置を確認するのが最初の仕事になります。
線が決まると担当が決まる
午後で狙われるのはここです。設問は「クラウドに移したあと、この作業は誰がやるのか」を必ず聞いてきます。作業ごとにその作業が触る層を考え、線の上か下かで答えを出します。
覚えるのは対応表ではなく手順です。①その作業はどの層を触るか ②その形態で線はどこか ③上なら利用者・下なら提供者。形態が決まると答えが決まるので、設問で形態が明示されていれば担当は一意に決まります。
設問文から形態を見分ける
形態が「IaaS」と明記されない設問もあります。その場合は利用者が何を操作しているかを本文から拾えば、線の位置が逆算できます。
| 本文にこう書いてあれば | 形態 | そこから決まること |
|---|---|---|
| 仮想サーバを構築し、OSを導入して設定した | IaaS | OS以上の修正プログラム適用・ログ取得・障害調査は利用者。自由度が高い分、運用の宿題も多い。 |
| 用意された実行環境に自社開発のプログラムを配置した | PaaS | OS・ミドルウェアの保守は提供者。ただしアプリの脆弱性は利用者の責任のまま残る。 |
| 提供される業務機能を、設定を変えて利用した | SaaS | 利用者に残るのは設定・権限・データ。作り込みはできず、取れるログも提供者が出す範囲に限られる。 |
見分けの決め手は「利用者がOSに触っているか」「利用者がプログラムを作っているか」の2問です。OSに触っていればIaaS、触らず自作プログラムを載せていればPaaS、どちらもしていなければSaaS——この順で切ると迷いません。
オンプレミスと比べる
責任分界点の話と対で問われるのが、自社で機器を持つ（オンプレミス）のとの比較です。費用の性格が変わる点が要点になります。
オンプレミス
- 初期費用が大きい：機器・ライセンス・設置工事を先に買う（資産として計上し、減価償却していく）。
- 調達に時間がかかる：見積・発注・納品・設置・設定で数週間〜数か月。使い始めるまでが長い。
- 増減しにくい：繁忙期に合わせて買うと、閑散期は遊ぶ。減らしても費用は戻らない。
- 全層を自社で持つ：自由度は最大だが、物理設備からアプリまで運用要員が要る。
- 止めた分の費用は減らない：使わなくても固定的に発生する。
クラウド
- 初期費用が小さい：買わずに借りるので、費用は使った分の従量課金（毎月の経費として発生）。
- 調達が速い：申込みから利用開始まで短く、試してから決めることができる。
- 増減しやすい：需要に合わせて増やし、不要になれば減らす。負荷変動が大きい業務に向く。
- 下の層は提供者に任せる：運用要員を上の層（アプリ・データ）に集められる。
- 長期・定常負荷では割高になり得る：常時フル稼働なら総額で逆転することもある。
比較の判断軸は「負荷が変動するか」と「いつまでに要るか」です。負荷が読めず立上げを急ぐならクラウド、負荷が一定で長期間使い続けるなら自社保有が有利になり得る——設問文の「利用者数が読めない」「短期間で開始したい」「繁忙期だけ増える」といった記述が、そのまま選択の根拠になります。
核は「作業が触る層」を先に決めることです。設問は形態の定義そのものより、移行後に誰が何をするかを聞きます。OSの修正プログラム適用・ミドルウェアの版数管理はIaaSなら利用者、PaaS以上なら提供者。アカウント管理とアクセス権の設定は全形態で利用者（これはデータ層に属します）。そして暗号化の鍵をどちらが持つかが問われたら、鍵は利用者側に置けるかを見ます。答えに詰まったら「この作業をやめたとき、困るのは誰の資産か」を考えると層が特定できます。
「クラウドだから安全」は誤りです。提供者が守るのは線より下の層だけで、データの管理責任は形態を問わず利用者に残ります。設定を公開のままにして中身が読める状態にした、退職者のアカウントを消し忘れた、権限を広く付けすぎた——これらは提供者の設備がいくら堅牢でも防げず、利用者側の過失になります。「基盤が安全なこと」と「自分のデータが安全なこと」は別の話で、後者は移行しても自分の宿題として残ると考えてください。
可用性と責任の関係
もう一段深いところがここです。提供者はSLA（サービスレベル合意）で稼働率を示しますが、その数値が保証しているのは提供者が持つ層の稼働であって、利用者のアプリが動き続けることではありません。混同すると可用性設計を丸ごと落とします。
- 保証の対象がずれている：IaaSのSLAは仮想サーバや基盤の稼働を対象にします。利用者のアプリが自分のバグや設定ミスで落ちても、SLAは満たされたままです。基盤が生きていてもサービスは止まり得ます。
- 直列につながると全体は下がる：稼働率99.9%の基盤の上に、利用者側の可用性が99.9%のアプリを載せると、全体はおよそ0.999×0.999≒99.8%。層をまたいで掛け算になるので、提供者のSLAが利用者のサービス目標の上限だと考えるのが安全です。連携先が増えるほど全体はさらに下がります。
- SLA違反の補償は返金であることが多い：停止で失った売上や信用は戻りません。金銭補償と業務継続は別物で、業務を止めない工夫（複数拠点への分散、縮退運転、代替手段）は利用者の設計責任です。
- 計画停止は稼働率の計算から除かれることがある：保守の告知が事前にあれば停止に数えない取り決めが一般的です。「99.9%だから年間8時間しか止まらない」と読むと外します。何を停止時間に算入するかを合意文書で確かめます。
- 復旧の主導権は提供者側にある：基盤側の障害が起きたとき、利用者は原因を調べることも復旧を早めることもできず、公表される情報を待つしかありません。だから利用者の可用性設計は「早く直す」ではなく「止まっても業務が続く」側に寄せます。
まとめると、責任分界点は障害時の動ける範囲も決めています。線より下で起きたことに利用者は手を出せない——この前提を置いたうえで、目標復旧時間や縮退運転の手順を自分の側で用意しておくのが、クラウド利用時の可用性設計です。