この記事は、PD-S（システム）試験（仮称）科目B 第1章の4節目、小項目1-4「クラウドサービスの活用，マイクロサービス化，仮想化，マイグレーションなどを考慮したシステムアーキテクチャ設計」の教科書です。1-1の技能5で「システム方式（アーキテクチャ）の策定はトレードオフの意思決定」と学びました。本節はそのクラウド前提の各論です。旧制度の試験ではクラウドはまだ「トピックの1つ」でしたが、新シラバス案では独立した小項目に昇格しており、新試験の性格をよく表す領域です。技能の例4つを全展開し、IaaS/PaaS/SaaSの区別からマイクロサービス、リフト＆シフト、クラウド運用の落とし穴まで、前提知識ゼロから解説します。
この節の全体像 — 「設計する」だけでなく「提案し、合意を得て、運用する」まで
シラバス案は小項目1-4に「目標とする技能の例」を4つ挙げています。並べてみると、単なる設計技術ではなくクラウド活用のライフサイクル全体をカバーしていることが分かります。
前提知識①：クラウドとは何か — IaaS・PaaS・SaaSの責任範囲
クラウドは「どこまで借りるか」で3つのサービスモデルに大別されます。下の層（設備）から上の層（アプリ）のどこまでを事業者に任せるかという積み木で理解するのが定番です。
図1：IaaS・PaaS・SaaS — どこまで事業者に任せるか（責任範囲の違い）
| モデル | 借りる範囲 | 自分で管理する範囲 | 例えるなら |
|---|---|---|---|
| IaaS（Infrastructure as a Service） | サーバ・ストレージ・ネットワークなどのインフラ | OS・ミドルウェア・アプリ・データ | 更地と建物の骨組みを借りて、内装は全部自分でやる |
| PaaS（Platform as a Service） | アプリの実行環境（OS・ミドルウェアまで） | アプリとデータ | 厨房設備つきの店舗を借りて、料理だけ自分で作る |
| SaaS（Software as a Service） | アプリケーションそのもの | データと利用方法（設定） | できあがった料理を注文して食べる |
下に行くほど自由度が高く運用負担が重い、上に行くほど楽だが業務をサービスの仕様に合わせる必要がある——この自由度と運用負担のトレードオフが、あらゆるクラウド設計判断の土台です。
前提知識②：仮想化とコンテナ — クラウドを支える土台技術
クラウド事業者が「サーバを数分で用意できる」のは、この仮想化技術で計算資源をソフトウェア的に切り出しているからです。シラバス案の小項目名にある「仮想化」は、クラウド活用アーキテクチャの前提技術としておさえておきましょう（ネットワークの仮想化は第2章で扱います）。
技能1：クラウドを活用したアーキテクチャを設計・運用する
システム要件や特性を踏まえて，運用コスト，信頼性，パフォーマンスを最適化した上で，マイクロサービスや仮想環境などのクラウドサービスを活用したシステムアーキテクチャを設計し運用するスキル
この技能の中心概念がマイクロサービスです。従来型との対比で理解します。
| 観点 | モノリシック | マイクロサービス |
|---|---|---|
| 変更・リリース | 一部の修正でも全体を再リリース | サービス単位で独立してリリース可能 |
| 性能の増強 | 全体をまとめて増強（無駄が出やすい） | 負荷の高いサービスだけ増強できる |
| 障害の影響 | 1か所の障害が全体停止につながりやすい | 設計次第で該当サービスのみに限定できる |
| 難しさ | 構造が単純で把握しやすい | サービス間連携・データ整合・監視の設計が複雑 |
| 向くケース | 小規模・変更頻度が低いシステム | 大規模・頻繁に更新し部分ごとに負荷が違うシステム |
技能2・技能3：モダナイゼーションを提案し、リフト＆シフトの合意を得る
最新のクラウドサービスの技術動向を把握し，クラウドのサービスを活用したモダナイゼーションやマイグレーションを提案するスキル
システムの将来像を見据え，オンプレミスシステムのクラウドリフト・クラウドシフトの提案をステークホルダに説明し合意を得るスキル
そして移行の進め方を表すのがリフトとシフトです。
図2：クラウドリフトとクラウドシフト — 段階的なクラウド移行の定石
定石は「まずリフトで移し、その後シフトで最適化する」二段階です。一気に作り替えようとすると移行と刷新のリスクが同時に来るため、段階を分けてリスクを分散します。
技能4：クラウド運用の課題を調査し、解決する
クラウドサービスを活用したシステム運用における課題や問題点を調査し，解決するスキル
クラウドは「移したら終わり」ではなく、運用してみて初めて出会う課題があります。代表的なものをおさえましょう。
- コストの膨張：従量課金は便利な反面、使い過ぎ・消し忘れ・過剰スペックがそのまま請求に跳ね返る。リソースの棚卸しと利用状況の継続的な監視・見直しが必須。
- 責任分界の理解：クラウドでは「事業者が守る範囲」と「利用者が守る範囲」が分かれる（責任共有の考え方）。設備の物理的な安全は事業者側でも、アクセス権限の設定やデータの管理は利用者の責任。「クラウドだから安全」ではない。
- 設定ミスによる事故：ストレージの公開設定ミス・過剰な権限付与など、利用者側の設定不備は情報漏えいの典型的な原因。設定の点検を運用に組み込む。
- 性能・障害への備え：クラウド側の障害や仕様変更は利用者にはコントロールできない。重要システムでは冗長構成や代替手段を設計しておく。
混同しやすい概念の整理
| 紛らわしいペア | 違いの核心 |
|---|---|
| IaaS ⇔ PaaS ⇔ SaaS | 借りる範囲の違い。インフラだけ＝IaaS、実行環境まで＝PaaS、アプリまで＝SaaS。下ほど自由で重い、上ほど楽で制約あり |
| クラウドリフト ⇔ クラウドシフト | リフト＝構成を変えずに移す（早い・低リスク・効果限定）。シフト＝クラウドに合わせて作り替える（コスト・期間がかかるが効果大）。定石は リフト→シフト の二段階 |
| マイグレーション ⇔ モダナイゼーション | マイグレーション＝引っ越し（環境の移行）。モダナイゼーション＝建て替え（技術・構造の刷新）。リフトは前者寄り、シフトは後者寄り |
| 仮想マシン ⇔ コンテナ | 仮想マシン＝OSごと丸ごと隔離（重いが独立性高い）。コンテナ＝OSを共有して実行環境だけ隔離（軽く速い） |
| モノリシック ⇔ マイクロサービス | 1つの大きなアプリ ⇔ 独立した小さなサービスの集合。大規模・高頻度更新ならマイクロサービスが活きるが、複雑さのコストを常に払う |
確認クイズ（4問）
この節の理解度チェックです（当サイト独自の予想問題。公式の出題ではありません）。
クラウド事業者からアプリケーションの実行環境（OS・ミドルウェアまで）の提供を受け、自社ではアプリケーションとデータだけを管理する形態はどれか。
クラウドリフトの説明として、最も適切なものはどれか。
マイクロサービスアーキテクチャの説明として、最も適切なものはどれか。
クラウド活用システムの運用に関する記述として、最も適切なものはどれか。
まとめ：小項目1-4で身につけること
- 技能4つ＝設計・運用する → 提案する → 合意を得る → 運用課題を解決する。技術だけでなく説明・合意形成まで含むのがこの小項目の特徴。
- IaaS/PaaS/SaaSは「どこまで借りるか」の積み木。下ほど自由で運用が重く、上ほど楽で制約が強い。仮想化はクラウドの土台技術、コンテナは軽量な隔離。
- マイクロサービスの本質は独立性（サービス単位の変更・増強）。ただし複雑さの代償があり、要件（運用コスト・信頼性・パフォーマンス）から選ぶのが技能1。
- リフト（そのまま移す）→シフト（作り替える）の二段階が移行の定石。合意形成は数年スパンの総コスト比較と、金額化しにくい利点・新コストの正直な提示で。
- クラウド運用の落とし穴＝コスト膨張・責任分界の誤解・設定ミス・クラウド側障害。調査→解決の筋道で対処する。
関連記事・次に読む
出典（一次情報）
- IPA「プロフェッショナルデジタルスキル（システム）試験（仮称）科目B シラバス（案 Ver0.2）」大項目1・小項目1-4（2026年7月31日更新）[link]。本文中の「技能の例」引用は同シラバス案からの原文引用です。
- IPA「情報処理技術者試験・情報処理安全確保支援士試験 出題範囲等の改定案 Ver.1.0」（2026年3月）
※試験名は仮称、内容は検討段階の案です。試験の形式・時間・配点・合格基準は未公表のため本記事では扱いません。技術解説（IaaS/PaaS/SaaS、仮想化・コンテナ、マイクロサービス、リフト＆シフトなど）は一般に確立した知識に基づく当サイトの解説で、シラバスの記載そのものではありません。確認クイズは当サイト独自の予想問題です。正式シラバス公開時に内容を更新します。
