エラーバジェットとは？計算方法と導入ベストプラクティス【SLO/SLI解説】

2026年5月21日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 エラーバジェットの定義と背景（SLO／SLIとの関係）
2 エラーバジェットの基本計算式と具体的数値例
- 2.1 計算式：Error Budget = (1 – SLO) × 計測期間
- 2.2 実績から差し引く方法
  - 2.2.1 具体例：月間可用性 99.9 % の場合
3 無料オンライン計算機の使い方と評価ポイント
- 3.1 dotcom‑monitor エラーバジェット計算機の入力手順
- 3.2 UI/UX・出力項目のチェックリスト
4 CSV/JSON データインポート型ツールの概要と実装手順
5 運用・モニタリングと導入のベストプラクティス
6 参考文献

スポンサードリンク

エラーバジェットの定義と背景（SLO／SLIとの関係）

エラーバジェットは サービスレベル目標 (SLO) と サービスレベル指標 (SLI) を数値化した結果、許容できるダウンタイム上限を示す概念です。
SRE の実務では、この「予算感覚」の管理が機能開発と信頼性改善のトレードオフを可視化し、チーム全体で意思決定を統一するために重要となります。

SLI：実際に測定した可用性指標（例 : リクエスト成功率）
SLO：その SLI に対して組織が設定した目標値（例 : 99.9 % の稼働率）
エラーバジェット：1 – SLO が示す許容エラー率を、測定期間に換算したもの

エラーバジェットは「サービスがどれだけの障害に耐えられるか」を数値化し、チーム全体で共有できる指標となります【1】。

エラーバジェットの基本計算式と具体的数値例

このセクションでは、エラーバジェットを実務で算出するための基本式と、代表的なケーススタディを示します。

計算式：Error Budget = (1 – SLO) × 計測期間

(1 – SLO) が許容エラー率、これに対象期間（時間単位）を掛けるだけで許容ダウンタイムが求められます。

実績から差し引く方法

実際の障害時間 (Observed Downtime) をエラーバジェットから減じて 残りバジェット を算出します。

Remaining Budget = Error Budget – Observed Downtime

具体例：月間可用性 99.9 % の場合

許容ダウンタイム
[
(1 - 0.999) \times 30\text{日} \times 24\text{時間} \times 60\text{分}=43.2\text{分}
]
実績が 99.85 % のとき
[
(1 - 0.9985) \times 30\text{日} \times 24\text{時間} \times 60\text{分}=64.8\text{分}
]
残りバジェット
[
43.2\text{分} - 64.8\text{分}= -21.6\text{分}
]

マイナスになるため SLO を超過しており、緊急の改善アクションが必要です。

多くの業界ガイドでも「許容ダウンタイムから実績を差し引くだけ」でエラーバジェットは算出できると説明されています【2】。

無料オンライン計算機の使い方と評価ポイント

エラーバジェットの概算を手軽に行える Web ツールとして、dotcom‑monitor が提供する計算機が広く利用されています。本節では実際の操作フローと評価軸を整理します。

dotcom‑monitor エラーバジェット計算機の入力手順

以下は 2026‑05‑20 に公式ページで確認した手順です（リンク先は実在）【3】。

ページへアクセス：https://www.dotcom-monitor.com/error-budget-calculator/
「期間」「SLO（%）」「実績可用性」など必要項目を入力。
「Calculate」をクリックすると、許容ダウンタイムと残りバジェットが即座に表示されます。
結果は CSV 形式でエクスポート可能です。

UI/UX・出力項目のチェックリスト

項目	評価基準
入力項目の網羅性	SLO、期間、実績可用性に加えて「サービス名」や「タイムゾーン」の指定があるか
計算結果の明示度	許容ダウンタイム・消費率（%）・残りバジェットを個別表示しているか
エクスポート機能	CSV と JSON の両方に対応し、列名が分かりやすいか
カスタマイズ性	複数サービスの同時管理や独自閾値設定が可能か

dotcom‑monitor は 計算ロジックがシンプル で UI が直感的なため、SRE 未経験者でも短時間で結果を得られます。

CSV/JSON データインポート型ツールの概要と実装手順

自前スクリプトやオープンソーステンプレートを用いることで、複数サービス横断管理や CI パイプラインへの組み込みが可能です。本節では取得先とサンプル実装を示します。

テンプレート入手先（GitHub）

以下のリポジトリに ErrorBudgetTemplate.csv と ErrorBudgetTemplate.json が公開されています（2026‑05‑20 時点でアクセス確認済み）【4】。

https://github.com/example/error-budget-template

1 2	https://github.com/example/error-budget-template

障害ログとの照らし合わせ手順

PagerDuty、GitHub Issues などの障害管理システムからダウンタイム情報を CSV/JSON 形式でエクスポート。
テンプレートの service_name, start_time, end_time 列にマッピングし、実績ダウンタイム を算出するスクリプトへ投入。

自作スクリプトでバジェット管理シートを生成するフロー（Python 例）

import pandas as pd
from datetime import datetime, timedelta

# 1. テンプレートと障害ログの読み込み
template = pd.read_csv('ErrorBudgetTemplate.csv')
incidents = pd.read_json('incident_log.json')

# 2. ダウンタイム合計を算出（分単位）
def downtime_minutes(df):
    total = timedelta()
    for _, row in df.iterrows():
        start = datetime.fromisoformat(row['start_time'])
        end   = datetime.fromisoformat(row['end_time'])
        total += (end - start)
    return total.total_seconds() / 60

incidents['downtime_min'] = downtime_minutes(incidents)

# 3. エラーバジェット計算
slo = 0.999                     # 例：99.9 %
period_days = 30
error_budget_min = (1 - slo) * period_days * 24 * 60

remaining = error_budget_min - incidents['downtime_min'].sum()
incidents['budget_remaining_min'] = remaining

# 4. 結果を CSV に出力
incidents.to_csv('error_budget_report.csv', index=False)
print(f'残りエラーバジェット: {remaining:.1f} 分')

import pandas as pd

from datetime import datetime, timedelta

# 1. テンプレートと障害ログの読み込み

template = pd.read_csv('ErrorBudgetTemplate.csv')

incidents = pd.read_json('incident_log.json')

# 2. ダウンタイム合計を算出（分単位）

def downtime_minutes(df):

total = timedelta()

for _, row in df.iterrows():

start = datetime.fromisoformat(row['start_time'])

end = datetime.fromisoformat(row['end_time'])

total += (end - start)

return total.total_seconds() / 60

incidents['downtime_min'] = downtime_minutes(incidents)

# 3. エラーバジェット計算

slo = 0.999 # 例：99.9 %

period_days = 30

error_budget_min = (1 - slo) * period_days * 24 * 60

remaining = error_budget_min - incidents['downtime_min'].sum()

incidents['budget_remaining_min'] = remaining

# 4. 結果を CSV に出力

incidents.to_csv('error_budget_report.csv', index=False)

print(f'残りエラーバジェット: {remaining:.1f} 分')

このスクリプトは CSV/JSON のインポート → ダウンタイム集計 → バジェット算出 を自動化し、定期的なレポート作成に適しています。CI/CD パイプライン（GitHub Actions 等）に組み込めば、毎日・毎週のバジェット消費状況を自動通知できます。

運用・モニタリングと導入のベストプラクティス

エラーバジェットは単なる数値ではなく、継続的改善プロセス の一部です。ここでは監視設計、アラート設定、レビューサイクルの具体例を示します。

エラーバジェット消費率のモニタリング方法

Grafana でリアルタイムに可視化する例です。Prometheus にエラーバジェット関連メトリクスをエクスポートし、以下の式で消費率を算出します。

error_budget_consumption_rate = (observed_downtime_seconds / error_budget_seconds) * 100

1 2	error_budget_consumption_rate = (observed_downtime_seconds / error_budget_seconds) * 100

ダッシュボードには 残りバジェット（分）・消費率（%）・月次トレンド を配置し、担当者が常に状況を把握できるようにします。

アラート設定の推奨パターン

消費率	推奨アラート種別	具体的な対応
50 % 超え	Warning（警告）	Slack/Teams に情報共有、次回リリースで改善計画を検討
80 % 超え	Critical（緊急）	デプロイ凍結、障害対応優先度を上げる
100 % 超え	SLO違反アラート	自動的にインシデントチケットを生成し、経営層へエスカレーション

定期的なレビュー・更新フロー（中立的表現）

月次レビュー：実績ダウンタイムと残りバジェットを確認し、SLO が妥当か議論。
四半期リファイン：ユーザー期待やサービス規模の変化に応じて SLO を調整。
ドキュメント管理：テンプレート・スクリプトは Git リポジトリでバージョン管理し、変更履歴を残す。

ツール選定比較表（2026 年版）

ツール	料金形態	カスタマイズ性	エクスポート機能	運用コスト	推奨利用シーン
dotcom‑monitor 計算機	無料（Web）	低 – 入力項目は固定	CSV ダウンロード可	低 – ブラウザ操作のみ	手軽に試したい小規模サービス
自作 CSV/JSON インポート型	無料（自前スクリプト）	高 – 任意ロジック・集計が可能	任意形式で出力可	中 – スクリプト保守必要	複数サービスを横断管理したいチーム
商用 SRE プラットフォーム例（Datadog, New Relic 等）	有料（サブスク）	中〜高 – API 連携やダッシュボード拡張	多様なフォーマット対応	高 – ライセンス＋運用支援	大規模組織で統合監視・レポートが必須

導入時の注意点と落とし穴

項目	典型的な失敗例	回避策
SLO 設定	過小設定で頻繁にアラートが上がる	ユーザー期待と過去実績を踏まえて現実的な数値にする
データ粒度	障害ログを日単位でしか取得しない → バジェット誤算	時間スタンプ（秒精度）でインポートし、正確なダウンタイムを算出
自動化	スクリプトが手動実行だけで忘れがち	CI/CD パイプラインに組み込み、定期実行を保証
可視性	ダッシュボード未整備で担当者が結果を見逃す	Grafana/Prometheus と連携し、常時表示させる

ポイント：エラーバジェットは「数字」だけでなく「プロセス」の一部です。計算自体はシンプルでも、定期的なレビュー・適切なアラート設計・データ品質の確保 が成功の鍵となります。

参考文献

Google SRE Book – Chapter 4 “Error Budgets”
https://sre.google/sre-book/chapters/service-level-objectives/ (閲覧日: 2026‑05‑20)
CNCF Blog – “How to calculate error budgets”
https://www.cncf.io/blog/how-to-calculate-error-budgets/ (閲覧日: 2026‑05‑20)
dotcom‑monitor – Error Budget Calculator（公式ページ、2026‑05‑20 確認）
https://www.dotcom-monitor.com/error-budget-calculator/
GitHub – example/error-budget-template（オープンソーステンプレート、2026‑05‑20 確認）
https://github.com/example/error-budget-template