【PD-S教科書】4-4 開発プラットフォーム・運用管理・SREを基礎から徹底解説|PaaS・Git・SBOM・SLOとエラーバジェット【シラバス案Ver0.2対応】

PD-S教科書 4-4 開発基盤・運用とSRE(最終回) プロフェッショナルデジタルスキル(システム)
本記事について:PD(システム)試験(仮称)科目B「シラバス(案 Ver0.2)」(IPA・2026年7月31日更新)を根拠に解説する教科書記事です。科目B(技能)の内容はVer0.1から変更ありません(当サイトでVer0.1とVer0.2の全文を突合して確認)。Ver0.2では新たに科目A-2(専門知識)の出題範囲の細目が公開されました。試験名は仮称、科目A-1(共通知識)・試験時間・出題数・配点・合格基準は未公表、内容は検討段階の「案」で今後変更の可能性があります。(最終更新:2026年7月31日/出典:IPA公式

この記事は、PD-S(システム)試験(仮称)科目B 教科書シリーズの最終節、小項目4-4「開発プラットフォームの活用,システムの運用管理,インフラストラクチャの管理,サイト信頼性エンジニアリング(SRE)」です。開発を支える基盤(PaaS・Git・SBOM)の選び方から、社会を支えるシステムの安定運用、そして開発と運用の対立を解く新しい仕事の形SREまで——第4章の締めくくりにふさわしい「作り続けながら、安定して動かし続ける」ための節です。技能の例6つを全展開し、前提知識ゼロから解説します。

この節の全体像 — 開発の基盤・運用の基本・SRE

技能1〜3開発プラットフォーム — 技術動向を調査してメリット・デメリット・限界点を見極め(技能1)、特性・要件から取捨選択して提案し(技能2)、PaaS,Git,SBOMなどをテーラリングして適用を推進する(技能3)。
技能4・5運用管理・利用者支援 — 社会・企業活動を支える基盤システムを安定して維持・運用し(技能4)、円滑な動作を保証し利用者が効果的に使えるようにする活動を計画・実行・改善する(技能5)。
技能6SRE — SREプロセスを導入して開発と運用が協力し、リリースサイクルの向上とサービスの安定を目指す。

技能1〜3:開発プラットフォーム — PaaS・Git・SBOMをおさえる

シラバス案・技能の例①〜③(要旨)
開発プラットフォームに関する技術動向を調査して,メリットやデメリット,技術上の限界点を見極め蓄積するスキル適切な開発プラットフォームを取捨選択して提案するスキル開発プラットフォーム(PaaS,Git,SBOM など)をプロジェクト特性に合わせてテーラリングし,プロジェクト適用を推進するスキル

開発プラットフォームとは、開発チームの仕事を支える基盤・ツール群のこと。4-3の「手法」が進め方の話なら、こちらは道具立ての話です。「調査→取捨選択→テーラリング」という技能の流れは4-3と全く同じ構図なので、ここではシラバス案が名指しする3つの道具を確実に理解します。

図1:シラバス案が名指しする開発プラットフォーム3点 — PaaS・Git・SBOM

開発プラットフォームの3点セット。PaaSはアプリの実行基盤を借りてインフラ管理を任せる。Gitはソースコードの変更履歴を管理し複数人の共同開発を支える。SBOMはソフトウェア部品表で、含まれる部品の一覧により脆弱性発覚時の即応とライセンス管理を可能にする

PaaS:1-4で学んだとおり、アプリの実行環境まで借りるクラウドのサービスモデル。開発の文脈では「インフラの構築・管理をせず、アプリ開発に集中できる基盤」として使う。制約(そのPaaSの流儀に合わせる)とのトレードオフ。
Git:ソースコードのバージョン管理システム。「誰が・いつ・何を・なぜ変えたか」の変更履歴をすべて記録し、任意の時点へ戻せる。またブランチ(本流から分かれた作業用の枝)によって、複数人が同時に別々の変更を進めて後で合流させる共同開発を支える。4-3のCI/CDは「Gitへの反映」を起点に動くため、現代の開発基盤の土台中の土台。
SBOM(Software Bill of Materials/ソフトウェア部品表):そのソフトウェアにどんな部品(OSSライブラリ等)がどのバージョンで含まれているかの一覧。製造業の部品表のソフトウェア版。新語の要注目キーワード。

なぜSBOMが名指しされるほど重要になったのか。現代のソフトウェアは大量のOSS部品の組み合わせでできており、ある部品に重大な脆弱性が見つかったとき、「うちのどのシステムがその部品を使っているか」が分からなければ対応のしようがないからです。SBOMがあれば影響箇所を即座に特定して更新でき、加えて1-5で学んだOSSライセンスの管理にもそのまま使えます。4-3のDevSecOps(セキュリティを最初から)を支える台帳、と位置づけると1本につながります。

技能4・技能5:安定運用と利用者支援

シラバス案・技能の例④
社会や企業活動を支える基盤となるシステムを安定して維持・運用するスキル

「社会や企業活動を支える基盤」という言葉が示すとおり、対象は止まると広く影響が出るシステムです。2-3で学んだ運用の型(構成・変更管理/監視としきい値/障害対応5ステップ/保守計画)が、ネットワークに限らずシステム全般・インフラ全般にそのまま適用されます。加えてシステム運用では、ソフトウェア更新(パッチ)の計画適用、バックアップと復旧試験、処理能力の余裕の監視(キャパシティ管理)が定番の仕事になります。

シラバス案・技能の例⑤
システムが円滑に動作することを保証し,利用者がシステムを効果的に使用できるようにする活動を計画・実行・改善するスキル

見落としがちな視点です——システムは「動いている」だけでは足りず、利用者が使えて初めて価値になります。問い合わせ・困りごとを受け付ける窓口、操作方法の案内やFAQの整備、利用状況から使いにくさを見つけて改善につなげる活動。技能の例が「計画・実行・改善」と書くとおり、窓口対応の記録は「よくある質問=分かりにくい機能」という改善のヒントの山です。

技能6:SRE — 開発の速さと運用の安定を両立させる仕組み

シラバス案・技能の例⑥
SRE プロセスを導入して,開発と運用が協力し,リリースサイクルの向上とサービスの安定を目指すスキル
SRE(Site Reliability Engineering/サイト信頼性エンジニアリング):サービスの信頼性を、勘や根性ではなくソフトウェアエンジニアリングの手法(計測・自動化・目標管理)で実現する運用の考え方・職能。

背景には古典的な対立があります。開発は「新機能を早く出したい(変化させたい)」、運用は「安定させたい(変化させたくない)」——放っておくと綱引きになる両者を、SREは数値の仕組みで協力させます。その中核が次の3点セットです。

図2:SREの核心 — SLI/SLO・エラーバジェット・トイル削減

SREの核心3点。SLI/SLO(信頼性を数値で計測し目標を決める。100%は目指さない)、エラーバジェット(SLOまでの許容量を予算として使い、残っていれば新機能リリース、使い切ったら安定化を優先)、トイル削減(繰り返しの手作業を自動化してエンジニアリングに時間を使う)

SLI/SLO:SLI(サービスレベル指標)=信頼性を測るものさし(成功応答の割合・応答時間など)。SLO(サービスレベル目標)=そのものさしで狙う水準(例:成功応答99.9%)。1-3の非機能要件(稼働率)を、日々の運用で計測・管理する形にしたものと捉えられる。
エラーバジェット(エラー予算):SLOが99.9%なら、残りの0.1%は「使ってよい不安定さの予算」と考える発想。予算が残っている間は新機能のリリースを進めてよい。予算を使い切ったら(障害が多かったら)、新機能を止めて安定化作業を優先する——「攻めるか守るか」を感情論でなく数値で自動的に決めるルール。100%を目指さないことが肝(100%は費用が無限にかかるうえ、リリースが一切できなくなる)。
トイル削減:トイル=繰り返し発生する手作業の運用作業(手動のリリース作業・定型の復旧操作など)。SREはトイルを計測して自動化で減らし、空いた時間を信頼性向上のエンジニアリングに充てる。
シラバス案の文言「開発と運用が協力し,リリースサイクルの向上サービスの安定」——この「と」が核心です。SREは安定だけを目指す仕組みではなく、両立の仕組み。エラーバジェットの説明で「予算が残っていればリリースを進められる」まで言えると、この両立の意味を理解していることが伝わります。1-3の可用性(9の数とコスト)・2-3の監視・4-3のDevOpsが、SREで1つに合流します。

混同しやすい概念の整理

紛らわしいペア 違いの核心
開発手法(4-3) ⇔ 開発プラットフォーム(4-4) 手法=進め方(アジャイル・CI/CD)。プラットフォーム=道具立て(PaaS・Git・SBOM)。どちらも「調査→取捨選択→テーラリング」で選ぶ
Git ⇔ SBOM Git=自分たちが書いたコードの変更履歴を管理。SBOM=取り込んだ部品(OSS等)の一覧を管理。守備範囲が「自作」か「部品」か
SLI ⇔ SLO SLI=ものさし(何を測るか)。SLO=目標値(どこを狙うか)。ものさしが先、目標が後
SLO100% ⇔ エラーバジェット 100%は目指さない(費用が際限なく、リリース不能になる)。SLOとの差分を予算として使い、攻め(リリース)と守り(安定化)を数値で切り替える
従来の運用 ⇔ SRE 従来=手順と人手で守る(開発と分離・変化を避けがち)。SRE=計測・自動化・目標管理で守る(開発と協力し、変化と安定を両立)

確認クイズ(4問)

この節の理解度チェックです(当サイト独自の予想問題。公式の出題ではありません)。

問1|SBOM

SBOM(ソフトウェア部品表)を整備しておく主な利点として、最も適切なものはどれか。




解説:SBOM=含まれる部品の一覧なので、脆弱性発覚時の影響特定(イ)とライセンス管理が主な用途です。アはGit、ウはPaaSの説明——シラバス案が名指しする3つの道具の役割を仕分けられるかが狙いです。

問2|Git

バージョン管理システム(Git)が複数人での開発を支える仕組みの説明として、最も適切なものはどれか。




解説:Gitの本質は全履歴の記録とブランチによる並行作業→合流(ア)。イ(1人ずつ)はバージョン管理が解決した古い働き方です。ウは品質ゲート(CIに組む仕組み)の話、エはSBOMの話です。

問3|エラーバジェット

SLO(サービスレベル目標)を99.9%と定めたサービスにおける「エラーバジェット」の考え方として、最も適切なものはどれか。




解説:エラーバジェット=SLOまでの「使ってよい不安定さの予算」で、攻め(リリース)と守り(安定化)の切り替えを数値で決める仕組みです(エ)。アの100%主義はコストが際限なくリリースも止まるためSREが否定する考え方、ウは逆(使い切ったら守りに入る)です。

問4|SREの目的

SREプロセスを導入する目的として、シラバス案の趣旨に最も合うものはどれか。




解説:シラバス案の文言どおり「開発と運用が協力し,リリースサイクルの向上サービスの安定」=両立が目的です(ウ)。アは安定だけ(両立の放棄)、イは分離(協力の逆)、エはトイル削減の逆です。

まとめ:小項目4-4で身につけること — そしてシリーズ完結

  • 開発プラットフォームは調査→取捨選択→テーラリング(4-3と同じ構図)。名指しの3点=PaaS(実行基盤を借りる)・Git(変更履歴とブランチ)・SBOM(部品表=脆弱性即応とライセンス管理)
  • 安定運用は2-3の型(構成/変更管理・監視・障害対応・保守)をシステム全般へ。利用者が効果的に使えるようにする活動(窓口・FAQ・改善)まで含めて運用。
  • SRE=計測・自動化・目標管理で信頼性を作る:SLI(ものさし)→SLO(目標)→エラーバジェット(攻守の切り替えを数値で)→トイル削減(自動化)。目的はリリースの速さと安定の両立

これでPD-S 科目B 教科書シリーズ全15節(1-1〜4-4)が完結です。第1章「要件とアーキテクチャ」→第2章「ネットワーク」→第3章「フィジカルコンピューティング」→第4章「開発と運用」——貫いていたのは、要件と制約から根拠を持ってトレードオフを判断するという1本の筋でした。区分ハブから全節を見渡して、章をまたいだつながり(非機能要件→稼働率→SLO、レビュー→シフトレフト、など)を確認すると、理解が立体になります。正式シラバス公開時には全記事を更新します。

関連記事・次に読む

« PD-S(システム)試験のトップ(区分ハブ)へ戻る

出典(一次情報)

  • IPA「プロフェッショナルデジタルスキル(システム)試験(仮称)科目B シラバス(案 Ver0.2)」大項目4・小項目4-4(2026年7月31日更新)[link]。本文中の「技能の例」引用は同シラバス案からの原文引用です。
  • IPA「情報処理技術者試験・情報処理安全確保支援士試験 出題範囲等の改定案 Ver.1.0」(2026年3月)

※試験名は仮称、内容は検討段階の案です。試験の形式・時間・配点・合格基準は未公表のため本記事では扱いません。技術解説(PaaS・Git・SBOM・SRE・SLI/SLO・エラーバジェットなど)は一般に確立した知識に基づく当サイトの解説で、シラバスの記載そのものではありません。確認クイズは当サイト独自の予想問題です。正式シラバス公開時に内容を更新します。

Copied title and URL