SRE（Site Reliability Engineering，サイト信頼性エンジニアリング）は，サービスの信頼性を保つ運用の仕事を， ソフトウェア開発の手法（自動化や計測）で行うという考え方です。 大規模な Web サービスを運営する企業が始めた取組みで，今では運用チームの役割や働き方の名前としても広く使われています。 開発チームと運用チームが連携する DevOps を，運用の側から具体的な仕組みにしたもの，と捉えると分かりやすいです。
シラバスでの扱い
IPA が 2023年12月25日に公開した応用情報技術者試験シラバス Ver.7.0 で， 「大分類4：開発技術」の「中分類13：ソフトウェア開発管理技術」にある「DevOps」の用語例に， CALMS フレームワーク・カオスエンジニアリング・Four Keys・オブザーバビリティなどと並んで加わりました（その前の Ver.6.3 にはありません）。 この改訂は，ペーパー方式では令和6年度秋期試験から適用されています。
当サイトが収録している過去問（令和7年度秋期まで）では，SRE・SLO・エラーバジェットはまだ出題されていません。 同じ用語例に並ぶカオスエンジニアリングは，情報処理安全確保支援士の令和5年度秋期に正解として出ています。
出典：応用情報技術者試験 シラバス Ver.7.0， 同 Ver.7.2， 同 Ver.6.3（いずれも2026年10月4日に確認）
SLI・SLO・SLA
SRE は，信頼性を「なんとなく安定している」ではなく数値で決めるところから始めます。
| 用語 | 意味 | 例 |
|---|---|---|
| SLI（サービスレベル指標） | 信頼性を測る指標 | 正常に応答したリクエストの割合，応答時間 |
| SLO（サービスレベル目標） | SLI について，提供者が自ら決める目標値 | 30日間で 99.9% のリクエストに正常に応答する |
| SLA（サービスレベル合意書） | 顧客と合意した約束。守れないと返金などの取決めがある | 月間の稼働率 99.5% を下回ったら料金を一部返す |
SLO は顧客との約束（SLA）より厳しめに決めておくのが普通です。 SLO を割り込みそうな段階で手を打てば，SLA を破る前に立て直せるからです。
エラーバジェット
SLO が 99.9% なら，残りの 0.1% は失敗してもよい量です。これをエラーバジェット（失敗の予算）と呼びます。 30日間（43,200分）で考えると，0.1% は 43.2分です。この範囲なら，新しい機能を出して一時的に不安定になっても目標は守れます。
- 予算が残っているとき：新しい機能のリリースを進める
- 予算を使い切りそうなとき：リリースを止め，信頼性を高める作業（障害の原因の除去，テストや監視の強化）を優先する
「速くリリースしたい開発」と「止めたくない運用」は対立しがちですが，エラーバジェットという共通の数字を使うことで， どちらを優先するかを話し合いではなくデータで決められるようにします。100% の信頼性を目標にしないのが SRE の特徴です。
そのほかの考え方
- トイルの削減：手作業で，繰り返し発生し，自動化できるのに人が行っている運用の作業をトイル（苦役）と呼び，自動化して減らす
- 非難しないポストモーテム：障害のあとに振り返りの報告書を書く。個人の責任を問うのではなく，仕組みの問題として再発防止策を考える
- 計測：オブザーバビリティで状態を把握し，Four Keys（デプロイの頻度，変更のリードタイム，変更障害率，平均修復時間（MTTR））で開発と運用の成果を測る
- カオスエンジニアリング：本番に近い環境で意図的に障害を起こし，壊れ方を確かめて備える
試験での問われ方（予想）
- 午前：SRE やエラーバジェットの説明を選ぶ形。DevOps，カオスエンジニアリング，オブザーバビリティとの見分け
- 計算：SLO からエラーバジェット（許される停止時間）を求める形。ITサービスマネージャの午前Ⅱで出てきた MTBF・MTRS の計算と同じ考え方です
- ITサービスマネージャの午後：SLA と SLO の関係，エラーバジェットを使い切ったときのリリースの判断，障害の振り返りの進め方を問う事例
近い論点で出題された過去問
カオスエンジニアリングと，可用性の指標の問題です。
- 情報処理安全確保支援士 午前Ⅱ 令和5年度 秋期 問22目的別のサービスが多数連携して動作する大規模な分散型のシステムでは，障害時の挙動を予知することが…
- ITサービスマネージャ 午前Ⅱ 令和4年度 春期 問3ITIL 2011 edition では，可用性管理における KPI の例として，平均サービス・…
- 午前Ⅰ（高度試験 共通） 平成29年度 春期 問20ITIL 2011 edition の可用性管理プロセスにおいて，IT サービスの可用性と信頼性…
予想問題（オリジナル）
当サイトが作ったオリジナルの問題です。IPA の過去問ではありません。ほかの用語の予想問題の一覧
問1SRE（Site Reliability Engineering）におけるエラーバジェットの説明として，適切なものはどれか。
- ア障害が発生したときに，原因となった担当者を特定し，再発防止の責任を負わせるための記録である。
- イ本番環境で意図的に障害を発生させ，システムの耐障害性を確かめる手法である。
- ウサービスレベル目標（SLO）を下回らない範囲で許容される失敗の量であり，使い切りそうになったら新機能のリリースより信頼性の改善を優先する判断に使う。
- エ顧客と合意したサービスレベルを達成できなかった場合に，提供者が顧客に支払う返金の上限額である。
正解と解説
正解：ウ
エラーバジェットは 100% から SLO を引いた分で，リリースの速さと信頼性の釣り合いを取るための共通の数字です。
- ア：SRE のポストモーテムは，個人を非難せず仕組みの問題として扱います。
- イ：カオスエンジニアリングの説明です（情報処理安全確保支援士 令和5年度秋期 問22 で出題）。
- エ：SLA の違反時の取決めの話で，エラーバジェットではありません。
問2あるサービスの SLO を「30日間で，リクエストの 99.95% に正常に応答する」と定めた。リクエストが30日間に一定の割合で届くとき，全てのリクエストに応答できない停止が何分を超えると，その30日間のエラーバジェットを使い切るか。
- ア2.16
- イ21.6
- ウ43.2
- エ216
正解と解説
正解：イ
30日間は 30 × 24 × 60 ＝ 43,200分です。エラーバジェットは 100% − 99.95% ＝ 0.05% なので，43,200 × 0.0005 ＝ 21.6分です。
- ア：0.005% として計算した値です。
- ウ：SLO が 99.9%（エラーバジェット 0.1%）のときの値です。
- エ：0.5% として計算した値です。
関連する用語
DevSecOps オブザーバビリティ（可観測性） SLA（サービスレベル合意書） 稼働率（MTBF・MTTR） Kubernetes（コンテナオーケストレーション）