エラーバジェットとSLO/SLIの基礎から実装まで

Contents

1 1. エラーバジェットの基礎と SLO／SLI との関係
- 1.1 なぜエラーバジェットが必要なのか
2 2. ビジネス目標に合わせた SLO 設計の指針
- 2.1 2‑1. ビジネス KPI と顧客期待をマッピングする
- 2.2 2‑2. 設計フロー
3 3. エラーバジェットの算出方法と具体例
- 3.1 3‑1. 基本式
- 3.2 3‑2. 計算例
  - 3.2.1 「金額化」表現の置き換え
4 4. ツール別エラーバジェット実装手順
5 5. エラーバジェット活用フローとベストプラクティス
6 6. FAQ（よくある質問）
7 7. 参考文献
- 7.1 まとめ

スポンサードリンク

1. エラーバジェットの基礎と SLO／SLI との関係

用語	定義
SLI (Service Level Indicator)	実際に測定する指標。例：成功リクエスト率、レイテンシのパーセンタイル
SLO (Service Level Objective)	SLI に対して設定した目標値（例：99.9 % の可用性）
エラーバジェット	SLO から導かれる「許容できる失敗時間」計算式は `Error Budget = (1 - SLO) × 期間(秒)`

なぜエラーバジェットが必要なのか

可視化：障害率が目標を超えた瞬間に「予算消費」が発生し、数値で把握できる。
意思決定のトリガー：残予算が減少したらリリーススローダウンや自動化投資を検討する根拠になる。

ポイントまとめ
エラーバジェットは SLI と SLO の関係性から算出され、サービス信頼性の「財務的」な見える化手段です。

2. ビジネス目標に合わせた SLO 設計の指針

2‑1. ビジネス KPI と顧客期待をマッピングする

ビジネス指標	顧客が許容できるダウンタイム	推奨 SLI（例）	提案 SLO
EC サイトの月間売上 10 % 成長	カート追加や決済中の停止は離脱率 ↑	カート追加成功率	99.97 % （≈ 2 h／月）
SaaS の SLA 契約（年次更新率 95 %）	サービス停止が契約違反になる	API 応答成功率 (200 OK)	99.95 % （≈ 22 min／日）
モバイルゲームの同時接続数増加	ラグや切断はユーザー体験を損なう	平均レイテンシ ≤ 150 ms	99.9 %（≤ 150 ms の時間比率）

2‑2. 設計フロー

ビジネスゴールを明確化（売上、継続率、契約遵守など）。
顧客インタビューやデータ分析で許容ダウンタイムを定量化。
最も価値に直結する SLI を 1〜2 個選択。
ビジネス要件とエンジニアリソースを踏まえて SLO を設定。

ポイントまとめ
SLO は単なる技術指標ではなく、ビジネス目標と顧客期待を結びつけた「価値基準」です。

3. エラーバジェットの算出方法と具体例

3‑1. 基本式

[
\text{Error Budget (秒)} = (1 - \text{SLO}) \times \text{期間(秒)}
]

注意：SLO は小数（例: 99.9 % → 0.999）で入力してください。

3‑2. 計算例

前提	SLO	期間	エラーバジェット
月間 (30 日)	0.999	30 × 24 × 60 × 60 = 2 592 000 s	2 592 s ≈ 43 分
四半期 (90 日)	0.999	7 776 000 s	7 776 s ≈ 129 分
年間 (365 日)	0.9995	31 536 000 s	15 768 s ≈ 262 分（≈ 4.4 時間）

「金額化」表現の置き換え

エラーバジェットは「時間」単位で示すことが一般的です。金銭価値に換算したい場合は、障害1分あたりの損失額（売上減少やサポートコスト）を掛け合わせれば算出できますが、本稿では 時間換算 に留めます。

ポイントまとめ
エラーバジェットは SLO と期間だけで簡単に求まります。月次・四半期・年次の予算を可視化すれば、運用判断が格段にスムーズになります。

4. ツール別エラーバジェット実装手順

4‑1. Prometheus + Grafana

(a) SLI メトリクス収集（Prometheus 設定例）

scrape_configs:
  - job_name: 'api'
    static_configs:
      - targets: ['api.example.com:9090']

scrape_configs:

- job_name: 'api'

static_configs:

- targets: ['api.example.com:9090']

(b) エラーバジェット計算用 Recording Rule

# 成功率（200 OK の比率）
success_rate = sum(rate(http_requests_total{status=~&quot;2..&quot;}[5m]))
               / sum(rate(http_requests_total[5m]))

# エラーバジェット残量（秒）※月間 30 日前提
error_budget_remaining_seconds = (1 - 0.999) * 30*24*60*60
                                 - (1 - success_rate) * $__range

# 成功率（200 OK の比率）

success_rate = sum(rate(http_requests_total{status=~"2.."}[5m]))

/ sum(rate(http_requests_total[5m]))

# エラーバジェット残量（秒）※月間 30 日前提

error_budget_remaining_seconds = (1 - 0.999) * 30*24*60*60

- (1 - success_rate) * $__range

(c) Grafana パネル構成

パネル	内容
Success Rate	時系列グラフ、目標ライン 99.9 %
Error Budget Remaining	Stat パネルで残秒数 → 分単位にフォーマット、20 % 以下は黄色、5 % 以下は赤色アラート

実装ポイント
- Recording Rule により計算負荷を削減。
- Stat パネルの「Unit」を「seconds」→「minutes」に変換し、経営層にも直感的に提示。

4‑2. Instana

SLI 定義：Service Availability = requests.success / requests.total を選択。
SLO 作成：Instana UI の「SLO」タブで目標 99.95 %（月間）を設定。
エラーバジェットウィジェット：自動生成される「Error Budget Burn Rate」チャートをダッシュボードに追加。燃焼率が 1.0 を超えると赤色で警告。
通知連携：Slack／PagerDuty と即時連携し、予算消費が閾値を超えたら担当者へプッシュ。

実装ポイント
コード不要で UI だけで完結できるため、スタートアップや小規模チームに最適です。

4‑3. Google Cloud Monitoring (GCM)

手順	操作内容
1	`cloud.googleapis.com/loadbalancing/https/request_count` と `response_code_class` を組み合わせ、成功率メトリクスを算出。
2	「Service Monitoring」 → 「SLO」画面で Good Service Ratio（例: 99.9 %）と期間 `30d` を設定。
3	自動生成される「Error Budget Remaining」ウィジェットを Cloud Dashboard に配置。
4	アラートポリシー `error_budget_remaining < 0.2` → Pub/Sub → Cloud Function でデプロイパイプラインを自動スローダウン。

実装ポイント
GCP の IAM と連携すれば、権限管理が一元化でき、運用コスト削減に寄与します。

5. エラーバジェット活用フローとベストプラクティス

5‑1. 日常的なオペレーション

フェーズ	アクション
監視	ダッシュボードで残エラーバジェットをリアルタイム表示。燃焼率 (Burn Rate) が 1.0 を超えたら自動アラート。
レビュー	月例ミーティングで前月の消費率と原因分析を共有。次月の SLO 修正や追加 SLIs の検討材料に。
意思決定	残予算が 20 % 以下 → リリーススケジュールを見直す、またはトイリング削減施策（自動化）へ投資。

5‑2. 落とし穴と回避策

落とし穴	内容	回避策
過大 SLO 設定	ビジネスに見合わない高目標でエンジニアが過負荷になる	顧客期待とリソース上限を合わせた「適正 SLO」ガイドラインを策定
計測漏れ	重要 SLIs が監視対象外になる	CI パイプラインで `terraform validate` または `helm test` を実行し、SLI 定義の有無を検証
アラート疲弊	エラーバジェット閾値が頻繁にトリガーされる	燃焼率ベース（例: Burn Rate > 1.5）でダイナミックにアラートレベルを調整
可視化不足	ダッシュボードが散在し、ステークホルダーが全体像を把握できない	統一パネル（Remaining Budget・Burn Rate）を中心にした「SRE Overview」ダッシュボードを作成

5‑3. 成功事例ハイライト

大手 EC 企業：エラーバジェット可視化でリリース頻度を月 4 回 → 2 回に減少。障害対応時間は 30 % 短縮、売上への影響も 0.3 % 減少。
SaaS スタートアップ：Instana の自動 SLO 機能導入で設定工数が 80 %削減。予算消費アラートに即応できるようになり、顧客満足度（CSAT）が 5 ポイント上昇。

ポイントまとめ
エラーバジェットは「測定」→「可視化」→「意思決定」のサイクルを回すことで、リリース速度と信頼性の最適バランスを実現します。

6. FAQ（よくある質問）

質問	回答
SLO と SLA の違いは？	SLO は内部目標、SLA は顧客と結ぶ契約上の保証。エラーバジェットは主に SLO から算出しますが、SLA にも応用可能です。
エラーバジェットがマイナスになるケースは？	実際の障害率が SLO を超えている状態です。このときはリリースを凍結し、根本原因を迅速に解決することが求められます。
複数の SLI がある場合はどう扱う？	主要な 1〜2 個に絞り、それぞれに独立したエラーバジェットを設定します。総合的な判断は「最も消費が早い」SLI の予算で行います。
エラーバジェットの期間は何日がベスト？	ビジネスサイクルに合わせて選択。月次はリリース計画と相性が良く、四半期は長期的なトレンド把握に有効です。

7. 参考文献

Zenn – SRE の主要な原則 - エラーバジェット
https://zenn.dev/persona/books/7820d83da01b4f/viewer/e00e28 （参照日：2026‑04‑10）
app‑tatsujin – エラーバジェットとは？SLO・SLIとの関係と計算方法
https://app-tatsujin.com/error-budget-slo-sli-guide/ （参照日：2026‑04‑09）
Instana – Instana で実現する SRE のベストプラクティス（Note記事）
https://note.shiftinc.jp/n/n2344bed789e5 （参照日：2026‑04‑08）
ops‑today – SRE の心臓部・エラーバジェット完全ガイド
https://ops-today.com/topics-14785/ （参照日：2026‑04‑07）
Google Cloud – Service Monitoring の SLO とエラーバジェット（公式ドキュメント）
https://cloud.google.com/monitoring/slo （参照日：2026‑04‑06）

まとめ

エラーバジェットは時間で測る「障害予算」。SLO と期間だけで簡単に計算でき、月次・四半期・年次の可視化が運用判断を支援します。
ビジネス指標と顧客期待をマッピングし、適切な SLI／SLO を設定することが成功の鍵です。
Prometheus/Grafana、Instana、Google Cloud Monitoring いずれでも実装は可能。録画ルールや UI ウィジェットで負荷を最小化しましょう。
組織全体でエラーバジェットを活用すれば、リリースペースと信頼性のバランスが取れた持続的成長が実現します。

次のステップ：自社サービスの主要 SLI を 1 つ選び、今月の SLO とエラーバジェットを算出し、ダッシュボードに表示させてみましょう。

スポンサードリンク