本記事について：PD（システム）試験（仮称）「シラバス（案 Ver0.2）」（IPA・2026年7月31日更新）の科目A-2（専門知識）を根拠に解説する教科書記事です。科目A-2の出題範囲の細目は2026年7月31日に初めて公開されました。試験名は仮称、科目A-1（共通知識）・試験時間・出題数・配点・合格基準は未公表、内容は検討段階の「案」で今後変更の可能性があります。（最終更新：2026年7月31日／出典：IPA公式）
この記事は、PD-S（システム）試験（仮称）の科目A-2「大分類4：デジタル技術／中分類15：クラウド」の教科書です。シラバス案がこの中分類に挙げる用語例を1つも飛ばさずに取り上げ、それぞれ「何を指す言葉か」「なぜこの試験で問われるのか」「実務ではどう使い分けるのか」を前提知識ゼロから解説します。読み終えると、クラウドを「安く早く借りられる箱」ではなく、可用性・コスト・責任分界を設計する対象として説明できるようになります。
この中分類の全体像 — 小分類2つ・項目5つ
シラバス案は、中分類15「クラウド」の【内容】を次のように定めています。
シラバス案の記載
変化するビジネス環境に迅速に対応できる柔軟な資源配分とスケーラビリティを実現するために必要な，クラウドサービス及び仮想化基盤技術に関する専門的な知識を問う。
ここで注目すべきは、目的が「柔軟な資源配分」と「スケーラビリティ」だと明示されている点です。つまりこの中分類は「クラウド製品の名前を知っているか」ではなく、必要なときに必要なだけ資源を割り当て、変化に追随できる状態をどう作るかを問う設計になっています。以下で見る用語も、すべてこの目的に紐づけて覚えると定着します。
出題範囲は小分類2つ・項目5つという構成です。
図1：中分類15「クラウド」の全体像 — 小分類2つと、その下の項目5つ
1. クラウドサービスの特徴 — 「どこに置くか」と「どこまで任せるか」
1-1. クラウドサービス（XaaS）とは
クラウドサービス（XaaS） 「X as a Service」の総称。サーバやストレージなどの資源（IaaS）、アプリケーションの実行基盤（PaaS）、業務アプリそのもの（SaaS）といったように、従来は自前で保有していたものを、ネットワーク越しにサービスとして利用する形態をまとめて指します。
XaaSの本質は所有から利用への転換です。自社で機器を買えば、調達に数か月かかり、ピークに合わせて余分に買う必要があり、使わない時間も費用が発生します。サービスとして借りれば、必要なときに必要な量だけ確保して、不要になれば返せる。シラバス案が言う「柔軟な資源配分」「スケーラビリティ」は、まさにこの性質を指しています。
1-2. 置き場所の形 — パブリック／コミュニティ／ハイブリッド
| 用語 | だれと共用するか | 典型的な採用理由 |
|---|---|---|
| パブリッククラウド | 不特定多数の利用者と共用する | 初期投資が不要で、規模の経済により単価が低い。調達が速い |
| コミュニティクラウド | 共通の関心事・要件をもつ特定の組織群で共同利用する | 同じ業界規制・監査要件・接続要件をもつ組織どうしで、要件を満たした環境を共同で持てる |
| ハイブリッドクラウド | 形態の異なる複数の環境を組み合わせて連携させる | 機微なデータは手元に残し、変動の大きい処理はパブリックに逃がす、といった使い分けができる |
シラバス案の用語例に並ぶのはパブリック／コミュニティ／ハイブリッドの3つで、「プライベートクラウド」という語は列挙されていません。ただし用語例は網羅リストではないため、「出ないから覚えなくてよい」と読むのは危険です。共用範囲の広さで並べて理解しておくのが安全です。
1-3. 運用の任せ方 — アンマネージド／マネージド／フルマネージド
同じサービスでも、構築・運用の作業をどこまで事業者に任せるかで3段階に分かれます。ここは「借りる範囲」ではなく「面倒を見てもらう範囲」の話である点に注意してください。
| モデル | 利用者がやること | 引き換えに得るもの／失うもの |
|---|---|---|
| アンマネージドモデル | 構築・設定・監視・更新の大半を自分で行う | 自由度と制御性が高い。反面、運用の人手と習熟が要る |
| マネージドモデル | 一部（監視・バックアップ・更新の適用など）を事業者に任せる | 運用負荷を下げつつ、要所は自分で握れる |
| フルマネージドモデル | 基盤の運用はほぼ事業者に任せ、利用者は使うことに専念する | 運用負荷は最小。反面、細かい制御や独自チューニングの余地は小さくなる |
1-4. 共有責任モデル — この中分類の一番の山場
共有責任モデル クラウドの安全性・可用性は事業者と利用者が責任を分担して成り立つ、という考え方。どこまでが事業者の責任で、どこからが利用者の責任かはサービス形態（IaaS／PaaS／SaaS）によって動くのがポイントです。
図2：共有責任モデル — IaaS・PaaS・SaaSで責任の線が動く
図の通り、上に行くほど利用者の責任、下に行くほど事業者の責任で、サービスが高度になるほど利用者の担当範囲は狭くなります。ただし、どの形態でも「データ」は常に利用者側に残ることに注目してください。誰にどの権限を与えるか、何を暗号化するか、どこまで保管するか——これらは事業者に委ねられません。「SaaSだからセキュリティは事業者任せでよい」という理解が誤りなのは、この一点によります。
1-5. リージョン
リージョン クラウド事業者が設備を展開する地理的なまとまり。どのリージョンを選ぶかは、利用者からの距離（応答速度）、データを国内外のどこに置くかという要件、そして災害の同時被災リスクに直結します。
2. 可用性・継続性 — 「どこまで壊れても止まらないか」を設計する
2-1. AZとエッジロケーション
アベイラビリティゾーン（AZ） 1つのリージョンの中にある、電源・空調・ネットワークなどが互いに独立した設備のまとまり。AZを分けておけば、片方の設備が丸ごと停止しても、もう片方で処理を続けられます。
エッジロケーション 利用者に地理的に近い場所に置かれ、コンテンツの配信や一部の処理を手前で肩代わりする拠点。目的は可用性そのものより応答の速さと、中心となる設備への負荷集中の緩和にあります。
2-2. マルチAZ構成とマルチリージョン構成の違い
| 構成 | 耐えられる事象 | コスト・複雑さ |
|---|---|---|
| マルチAZ構成 | 同一リージョン内の特定の設備の障害（電源・空調・機器など） | 比較的小さい。距離が近いためデータの同期も取りやすい |
| マルチリージョン構成 | リージョン全体に及ぶ事象（広域災害、リージョン規模の障害） | 大きい。距離があるぶん遅延が増え、データ整合性の設計が難しくなる |
クロスリージョンレプリケーション（CRR） あるリージョンのデータを、別のリージョンへ複製しておく仕組み。マルチリージョン構成やDRを支える土台になります。
2-3. DRと、その評価指標 RTO／RPO／RLO
ディザスタリカバリ（DR） 災害や大規模障害でシステムが失われたときに、あらかじめ用意した別の環境で復旧させる備え。クラウドは平常時に資源を寝かせておく必要が小さいため、DRと相性がよい領域です。
DRの良し悪しは感覚ではなく3つの指標で合意します。ここは仕分け問題の定番です。
| 指標 | 何を決めるか | 覚え方 |
|---|---|---|
| RTO（目標復旧時間） | 障害発生からいつまでに復旧させるか | 時間軸で「未来」を向く。止まってよい長さ |
| RPO（目標復旧時点） | どの時点のデータまで戻せればよいか＝失ってよいデータの幅 | 時間軸で「過去」を向く。データの損失量 |
| RLO（目標復旧レベル） | どの水準まで復旧すればよいか（全機能か、基幹業務だけか） | 質・範囲の話。「まず何を戻すか」 |
3. コスト管理 — 使った分だけ、を放置しない
クラウドは初期投資を小さくできますが、使い方を管理しなければ費用は際限なく伸びます。この項目は、その管理手段を並べたものです。
3-1. 課金・購入のモデル
| モデル | 仕組み | 向いている使い方 |
|---|---|---|
| 従量課金 | 使った量・時間に応じて支払う | 需要が読めない、立ち上げ期、一時的な処理 |
| リザーブド利用（RI） | 一定期間の利用を前もって約束する代わりに単価を下げる | 年間を通じて動かし続ける土台の部分 |
| スポット型利用 | 事業者の余剰資源を安く使う。状況により中断されうる | 途中で止まっても再実行できるバッチ処理・検証環境 |
3-2. 無駄を削る — ライトサイジングとストレージ階層化
ライトサイジング 実際の使用状況を測り、過剰に大きい資源を適正なサイズへ調整すること。「念のため大きめ」を放置しないための活動です。
ストレージ階層化 データをアクセス頻度に応じて置き分けること。よく読むデータは取り出しの速いホットバケットへ、時々読むものはウォームバケットへ、めったに読まない長期保管は単価の安いコールドバケットへ。コールドは保管が安い代わりに、取り出しに時間や追加費用がかかるのが一般的です。
3-3. FinOpsという運営のしかた
FinOps クラウドの費用を、財務部門・エンジニア・事業部門が協働して継続的に最適化していく運営の考え方。費用を「後から経理が集計するもの」ではなく、使う人がその場で意識して動かせるものにするのが要点です。
FinOpsを回すには、まず現状が見えていなければなりません。そのための道具が次の2つです。
- タグベースのコスト配分 各資源に「部門」「プロジェクト」「環境（本番・検証）」といったタグを付け、費用を誰の責任範囲かに割り当てる。タグの付け忘れがあると、そこだけ「持ち主不明の費用」になります。
- コストの可視化 誰が・何に・いくら使っているかをダッシュボードなどで見える状態にする。増えたときに気づける状態を作ることが、削減そのものより先に来ます。
3-4. クラウドポータビリティ
クラウドポータビリティ あるクラウドで動かしているものを、別のクラウドや自社環境へどれだけ移しやすいかという度合い。特定の事業者に強く依存する（ロックインされる）と、価格交渉力を失い、方針転換のコストが跳ね上がります。
4. クラウド移行 — 何を、どう移すかを先に決める
4-1. 移行アセスメント
クラウド移行アセスメント 移行に着手する前に、既存のシステム資産を棚卸しし、移行の可否・優先順位・方式・効果とリスクを評価する作業。ここを飛ばして「とりあえず全部移す」と、移した先で費用が増えるだけの結果になりがちです。
4-2. 移行の戦略的なアプローチ（5つのR）
シラバス案は、移行の戦略的なアプローチとしてRehost，Replatform，Refactor，Retain，Retire などを挙げています（「など」と書かれているため、これで全部と決めつけないでください）。
| アプローチ | やること | 費用・効果 |
|---|---|---|
| Rehost | 構成をほぼ変えずにそのまま移す（いわゆるリフト＆シフト） | 手間は小さいが、クラウドの利点は活かしきれない |
| Replatform | 大枠は変えずに一部だけクラウド向けに置き換える（例：DBをマネージドサービスへ） | 中程度の手間で、運用負荷の軽減など具体的な効果を得る |
| Refactor | アプリの構造そのものを作り替える | 手間と費用は最大。スケーラビリティなど利点を最大限に引き出せる |
| Retain | 移さずに今の場所へ残す | 移す価値が薄い、または制約で移せないものを見極める判断 |
| Retire | 使われていないものを廃止する | 最も費用対効果が高いことがある。移行は棚卸しの好機 |
4-3. モダナイゼーションとランディングゾーン
モダナイゼーション 老朽化した仕組みを、現在の技術・構造へ刷新すること。単に置き場所を変えるRehostと違い、作り方や運用の仕方まで今日的なものに改めるところまでを指します。
ランディングゾーン 本格的な移行を始める前に整えておく、統制の効いた「着地点」。組織のアカウント構成、ネットワーク、権限管理、ログの取得、課金の分け方といった土台をあらかじめ設計しておく考え方です。
5. 基盤技術 — クラウドを支えている仕組み
5-1. 3種類の仮想化
クラウドの「必要なだけ切り出して貸す」を成立させているのが仮想化です。対象ごとに3つあります。
- サーバ仮想化 1台の物理サーバの上に複数の仮想サーバを作り、CPUやメモリを論理的に分け合う。
- ネットワーク仮想化 物理的な配線構成とは独立に、論理的なネットワークをソフトウェアで定義する。
- ストレージ仮想化 複数の物理的な記憶装置をひとまとめに扱い、必要な容量を論理的に切り出す。
5-2. コンテナ関連の3語
| 用語 | 意味 | 役割のたとえ |
|---|---|---|
| コンテナイメージ | アプリと実行に必要なものをまとめた、変更しないパッケージ | 設計図・型 |
| コンテナレジストリ | イメージを保管し、配布する置き場 | 倉庫 |
| コンテナネットワーク | コンテナ間や外部との通信を担う仮想的なネットワーク | 配線 |
コンテナは、同じイメージからどこでも同じ状態で起動できることが最大の利点です。「開発環境では動いたのに本番で動かない」を減らし、必要に応じて素早く増減させられる——これが「柔軟な資源配分」の実装手段になります。
5-3. ベアメタルクラウド
ベアメタルクラウド 仮想化の層を挟まず、物理サーバをそのまま貸し出す形態。仮想化のわずかな性能低下も許容できない処理、ハードウェア構成に条件がある処理、ライセンスの都合で物理占有が必要な場合などに選ばれます。「クラウド＝すべて仮想化」ではない、という例外として押さえてください。
5-4. IaCとPaC
| 用語 | コードで書くもの | 効果 |
|---|---|---|
| IaC（Infrastructure as Code） | インフラの構成（どんな資源をどう作るか） | 手作業のばらつきを排除し、同じ環境を何度でも再現できる。変更履歴も残る |
| PaC（Policy as Code） | 守るべきルール（セキュリティ基準・構成の決まりごと） | ルール違反を人のレビュー頼みにせず、自動で検査・抑止できる |
5-5. 関連するOSS
シラバス案は、クラウド・仮想化関連のOSSとして次の6つを挙げています（「など」付き）。名前と役割の対応を押さえておけば十分です。
| OSS | 担う役割 |
|---|---|
| Xen | サーバ仮想化のためのハイパーバイザ |
| KVM | Linuxカーネルに組み込まれた仮想化の仕組み |
| Ceph | 分散型のストレージ基盤 |
| Docker | コンテナの作成・実行を担う |
| Kubernetes | 多数のコンテナの配置・増減・復旧をまとめて管理する（オーケストレーション） |
| OpenStack | IaaS基盤そのものを構築するためのソフトウェア群 |
6. 混同しやすい概念の仕分け
| 迷いやすい組 | 切り分けの一言 |
|---|---|
| RTO ⇔ RPO | RTOは復旧までの時間、RPOは失ってよいデータの幅。「さかのぼる」ならRPO |
| マルチAZ ⇔ マルチリージョン | AZはリージョン内の設備障害対策、リージョンは広域災害対策 |
| Rehost ⇔ Replatform ⇔ Refactor | そのまま／一部差し替え／作り替え。手間と効果が順に大きくなる |
| マネージド ⇔ IaaS/PaaS/SaaS | 前者は運用をどこまで任せるか、後者は何を借りるか。別の軸 |
| IaC ⇔ PaC | 作るものを書く ⇔ 守らせることを書く |
| ホット ⇔ コールドバケット | 取り出しが速く保管が高い ⇔ 保管が安く取り出しに時間・費用 |
確認クイズ（当サイト独自の予想問題）
事業継続の要件として「障害が発生しても、失われるデータは直近15分ぶんまでに抑えたい」と合意した。この要件が定めている指標はどれか。
「大規模な災害でリージョン全体が利用できなくなっても、業務を継続できるようにしたい」という要件に対して、最も適切な構成はどれか。
夜間に実行するバッチ処理があり、途中で中断されても最初からやり直せば支障がない。費用を抑える利用形態として最も適切なものはどれか。
既存の業務アプリを、クラウドのスケーラビリティを最大限に活かせるようアプリの構造そのものを作り替えて移行することにした。この戦略的なアプローチはどれか。
まとめ：中分類15で身につけること
- この中分類の目的は「柔軟な資源配分」と「スケーラビリティ」。用語はすべてこの目的に紐づけて覚える。
- 共有責任モデルが最大の山場。IaaS→PaaS→SaaSと責任の線は上がるが、データは常に利用者の責任に残る。
- 可用性はマルチAZ（リージョン内）とマルチリージョン（広域災害）を区別し、DRはRTO／RPO／RLOの3指標で合意する。
- コストは課金モデルの使い分け（従量・RI・スポット）＋ライトサイジング＋階層化で削り、タグと可視化を土台にFinOpsで回し続ける。
- 移行はアセスメントが先。Rehost／Replatform／Refactorに加え、Retain・Retire＝移さない判断を含められるかが問われる。土台はランディングゾーン。
- 基盤技術は3つの仮想化・コンテナ3語・ベアメタル・IaC／PaC・OSS6つ。IaCは作るもの、PaCは守らせること。
関連記事・次に読む
出典（一次情報）
- IPA「プロフェッショナルデジタルスキル（システム）試験（仮称）シラバス（案 Ver0.2）」【目標とする知識（専門知識）】大分類4：デジタル技術／中分類15：クラウド（2026年7月31日更新）[link]。本文中の【内容】と用語例の引用は同シラバス案からの原文引用です。
- IPA「情報処理技術者試験・情報処理安全確保支援士試験 出題範囲等の改定案 Ver.1.0」（2026年3月）
※試験名は仮称、内容は検討段階の案です。試験の形式・時間・配点・合格基準は未公表のため本記事では扱いません。各用語の技術解説は一般に確立した知識に基づく当サイトの解説であり、シラバスの記載そのものではありません（シラバス案が示すのは用語の並びまでで、定義や使い分けは記載されていません）。特定のクラウド事業者の仕様・料金体系には踏み込んでいません。確認クイズは当サイト独自の予想問題です。正式シラバス公開時に内容を更新します。
