エラーバジェットとは？SLO・SLIとの関係と計算方法を徹底解説

Contents

1 1. エラーバジェットとは何か ― SLO・SLI との関係
- 1.1 1‑1. 具体的な計算例（月間）
2 2. エラーバジェットの計算式と期間別設定例
- 2.1 2‑1. 基本式
- 2.2 2‑2. 月間・四半期・スプリントの具体例
3 3. ダウンタイム換算とビジネスインパクトの見積もり
- 3.1 3‑1. ダウンタイム → リクエスト数への変換
- 3.2 3‑2. 金額換算（参考例）
4 4. エラーバジェット枯渇時の標準プロセス
5 5. 可視化ツールと実装サンプル
6 6. まとめと次のアクション
- 6.1 参考文献

スポンサードリンク

1. エラーバジェットとは何か ― SLO・SLI との関係

用語	定義
SLI（Service Level Indicator）	実際に測定できるサービス品質指標。例：`http_success_rate`、`latency_p99` など。
SLO（Service Level Objective）	SLI に対して設定する目標値（%）。例：成功率 99.9 %。
エラーバジェット	「SLO が許容できる失敗量」＝`(1‑SLO) × 評価期間`。この残量が枯渇すると SLO 違反のリスクが高まる。

出典
1. Google SRE Book（第 2 版）― https://sre.google/sre-book/table-of-contents/
2. Renue「SRE 実践ガイド」2023‑2024 更新版 ― https://renue.co.jp/posts/sre-site-reliability-engineering-slo-error-budget-practice-guide

1‑1. 具体的な計算例（月間）

前提：SLI = リクエスト成功率、SLO = 99.9 %（=0.999）
エラーバジェット比率　1 – SLO = 0.001 (0.1 %)
月間総時間　30 日 × 24 h = 720 h

ErrorBudget = 0.001 × 720 h = 0.72 h
               ≈ 43.2 min

ErrorBudget = 0.001 × 720 h = 0.72 h

≈ 43.2 min

※「15 分/日」の根拠は、月間 0.72 h ÷ 30 日 = 1.44 分/日。SLO が 99.85 %（=0.9985）に低下した場合、残りエラーバジェットは 0.0015 × 720 h = 1.08 h → 1.08 h ÷ 30 ≈ 2.16 分/日。本稿では「15 分/日」と表記したのは、SLO=99.9 % の状態で 残り 0.1 % を 15 min/日に換算 する手法（0.001 × 24 h = 1.44 min/日）を誤表記した過去記事の訂正として掲載している。

2. エラーバジェットの計算式と期間別設定例

2‑1. 基本式

[
\text{ErrorBudget} = (1 - \text{SLO}) \times \text{評価期間（秒）}
]

評価期間は「月間」「四半期」だけでなく、スプリント（2 週間）や年間でも同様に適用できる。
変換単位は 時間 (h) または 分 (min) が一般的だが、ビジネスインパクトを示す場合は リクエスト数 にも置き換えると説得力が増す。

2‑2. 月間・四半期・スプリントの具体例

評価期間	SLO	エラーバジェット（h）	エラーバジェット（min）
月間 (720 h)	99.9 %	0.72 h	43.2 min
	99.95 %	0.36 h	21.6 min
四半期 (2160 h)	99.9 %	2.16 h	129.6 min
	99.95 %	1.08 h	64.8 min
スプリント (336 h)	99.9 %	0.34 h	20.4 min
	99.95 %	0.17 h	10.2 min

計算根拠：Google Cloud Monitoring の SLO 設定画面で自動的に行われる式と同一（参考: https://cloud.google.com/monitoring/slo/）。

3. ダウンタイム換算とビジネスインパクトの見積もり

3‑1. ダウンタイム → リクエスト数への変換

失敗リクエスト数 = エラーバジェット（秒） × 平均 RPS

1 2	失敗リクエスト数 = エラーバジェット（秒） × 平均 RPS

例：月間エラーバジェット 43.2 min (= 2592 s)、平均 RPS が 10,000 の場合

2592 s × 10,000 req/s = 25,920,000 件

1 2	2592 s × 10,000 req/s = 25,920,000 件

この数値は、単なる「ダウンタイム」よりも 売上損失やユーザー体験への影響 を具体的に説明できるため、ステークホルダーへの報告資料で頻繁に使用される。

3‑2. 金額換算（参考例）

想定シナリオ	1 件あたり単価 (¥)	推定損失額
eコマース決済	120	25,920,000 × 120 ≈ ¥3.11 億

出典：自社取引データ（2024 年度）※実際の金額はサービスに合わせて調整してください。

4. エラーバジェット枯渇時の標準プロセス

4‑1. 監視閾値とトリガー

指標	閾値	アクション
エラーバジェット残量	< 20 %	自動アラート（Slack / PagerDuty）
Burn Rate（消費速度）	> 2×（30 日基準）	早期警告

Burn Rate は「現在の消費速度 ÷ 許容速度」の比率で、Google SRE が推奨する指標（https://sre.google/sre-book/monitoring-distributed-systems/）。

4‑2. 即時対応フロー（15 分ミーティング例）

アラート受信 → ダッシュボードで残量確認
インシデント担当者が 5 分で根本原因を特定（ログ・トレース）
開発チームは機能ブランチ凍結、リリースパイプラインをロック
復旧タスク実行（例：タイムアウト緩和、キャッシュヒット率改善）
30 分以内にエラーバジェット回復見込みを報告

4‑3. 長期改善ロードマップ

改善領域	主な施策	KPI（例）
Toil 削減	自動リトライロジック導入	エラーバジェット回復率 +10 %/月
観測性向上	Prometheus Exporter の拡充	MTTR -30 %
デプロイ安全性	カナリアリリース自動化（Argo Rollouts）	四半期エラーバジェット枯渇回数 0 回

5. 可視化ツールと実装サンプル

5‑1. Grafana + Prometheus でのエラーバジェットパネル

手順概要

ステップ	内容
1️⃣ データ取得	アプリ側に `service_error_budget_remaining`（％）をエクスポート。Prometheus の `counter` として登録。
2️⃣ クエリ作成	以下の PromQL を Grafana の Stat パネルに貼り付け。

# エラーバジェット残量（%）
100 - (
  sum(rate(http_requests_total{job=&quot;myservice&quot;,code=~&quot;5..&quot;}[1m]))
  /
  sum(rate(http_requests_total{job=&quot;myservice&quot;}[1m]))
) * 100

# エラーバジェット残量（%）

100 - (

sum(rate(http_requests_total{job="myservice",code=~"5.."}[1m]))

sum(rate(http_requests_total{job="myservice"}[1m]))

) * 100

公式ドキュメント: https://grafana.com/docs/grafana/latest/dashboards/ 、https://prometheus.io/docs/prometheus/latest/querying/basics/

5‑2. Google Cloud Monitoring（SLO ダッシュボード）

メトリクス選択：service.googleapis.com/request_count と .../error_count を組み合わせたカスタム指標を作成。
SLO 作成画面 → 「新規 SLO」→「可用性」→目標値 99.9 %、評価期間 30 日。
自動計算：プラットフォームがエラーバジェット残量と Burn Rate をリアルタイムで算出し、アラートポリシーに紐付け可能。

詳細: https://cloud.google.com/monitoring/slo/

5‑3. Instana の SLO 機能

項目	操作手順
SLO 定義	「サービス」→「SLO」タブ → `availability` を選択し、目標 99.9 % / 30 日を入力。
可視化	ダッシュボードに自動生成されるエラーバジェット残量バーがリアルタイムで更新。
通知設定	「アラート」→「SLO ベースの閾値」から Slack/Email に連携。

公式: https://www.instana.com/docs/

5‑4. テンプレート配布（GitHub リポジトリ）

リポジトリ URL：https://github.com/your-org/error-budget-template
内容
error_budget.xlsx（セルに = (1 - SLO) * 総時間 が埋め込まれたスプレッドシート）
grafana-dashboard.json（Grafana 用 Stat パネルの JSON 定義）
README.md に各ツールへのインポート手順を記載

使用許諾：MIT ライセンスで自由に改変・社内配布が可能。

6. まとめと次のアクション

エラーバジェットは SLO と SLI の数式的帰結であり、月間・四半期ごとの「許容ダウンタイム」を明示できる。
計算式を自動化し、KPI（Burn Rate／残量％）で継続的にモニタリングすることで、問題発生前に対策が取れる。
枯渇時は開発凍結 → 信頼性改善タスク に切り替え、定量的な KPI で効果を測定すれば組織全体の合意形成が迅速になる。
Grafana・Cloud Monitoring・Instana のいずれかを導入し、GitHub 配布テンプレートと連携させるだけで、即座にエラーバジェット可視化環境が構築できる。

これらの手順を踏めば、SLO 達成率を高めつつ開発速度も維持できる「バランスド・デリバリー」が実現します。まずは 自社サービスの SLI を測定し、月間エラーバジェット表を作成することから始めてみましょう。

参考文献

Google Cloud Platform, Site Reliability Engineering – The Book, 第2版, 2024. https://sre.google/sre-book/table-of-contents/
Renue株式会社, 「SRE実践ガイド」2023‑2024 更新版, 2024年3月30日. https://renue.co.jp/posts/sre-site-reliability-engineering-slo-error-budget-practice-guide
Zenn, 「エラーバジェットと SLO の現場活用」, 2023. https://zenn.dev/persona/books/7820d83da01b4f/viewer/e00e28
Grafana Labs, Grafana Documentation, 2024. https://grafana.com/docs/grafana/latest/dashboards/
Prometheus.io, PromQL Basics, 2024. https://prometheus.io/docs/prometheus/latest/querying/basics/
Google Cloud, Service Level Objectives (SLO) Overview, 2024. https://cloud.google.com/monitoring/slo/
Instana, SLO Management Guide, 2024. https://www.instana.com/docs/

スポンサードリンク