エラーバジェット
Error Budget ・ エラーバジェット
SLOが許容する失敗の残量。信頼性とリリース速度のトレードオフを数値で裁く仕組み。
✦ 30秒で試す — 航海100%の信頼性を、あえて目指さないと決めた予算を多く食うのは、どっち？予想してみる概要
エラーバジェット（エラー予算）は、SLO が許容する失敗の「残量」です。SLO が「30日間でリクエストの99.9%が成功する」なら、裏返せば「0.1%までは失敗してよい」ことになります。この0.1% — 停止時間に換算すれば30日で約43分 — が、そのチームに与えられたエラーバジェットです。障害やエラーが起きるたびに予算が消費され、残量がゼロに近づけば慎重に、余裕があれば大胆に動く。信頼性を「守るべき聖域」ではなく「使ってよい予算」として扱い直す発想です。
この道具の真価は、リリースの可否という組織的な対立を数値で裁けることにあります。予算が残っているうちは新機能のリリースも実験も自由に行い、予算を使い切ったらリリースを凍結して信頼性の改善に専念する — 誰かの声の大きさではなく、ユーザー影響の実測値が意思決定を下す仕組みです。
なぜ生まれたか
エラーバジェット以前、開発チームと運用チームは構造的に対立していました。開発の評価は「どれだけ速く機能を出したか」、運用の評価は「どれだけ障害を起こさなかったか」。障害の最大の原因は変更なので、運用は変更を拒みたくなり、開発は運用を「進歩を止める門番」と見なす。この綱引きは、どちらが正しいかを判定する客観的な基準がない限り、政治力の勝負になってしまいます。
Google の SRE が持ち込んだ解決は、「SLO を満たしている限り、残りの信頼性は使ってよい資源である」という再定義でした。100%の信頼性を目指さないと決めた瞬間、100%と SLO の間には「意図的に許容された失敗の余地」が生まれます。これを予算として明示すれば、「リリースしてよいか」という水掛け論は「予算は残っているか」という測定可能な問いに変わります。開発と運用が同じ数字を見て同じルールに従う — エラーバジェットは技術指標であると同時に、組織の合意形成の道具として生まれたのです。
詳細
予算の計算と消費
エラーバジェットの計算は単純です。SLO が99.9%なら予算は0.1%。30日間に100万リクエストを処理するサービスなら、1,000リクエストの失敗までが予算内です。時間ベースの SLO なら、30日 × 0.1% ＝ 約43分の停止時間が予算になります。予算は障害だけでなく、デプロイ直後の一時的なエラー増加、依存サービスの不調、ネットワークの揺らぎなど、SLI を悪化させるすべての事象で消費されます。「大障害ゼロでも小さなエラーの積み重ねで予算が尽きる」ことがある点が、障害件数の管理との違いです。
残量で行動を切り替える
エラーバジェットの運用は、残量に応じた行動の切り替えとしてあらかじめ合意しておきます。
予算が潤沢なうちは、CI/CD パイプラインからの頻繁なリリース、カナリアリリースによる段階的な展開、フィーチャーフラグでの実験を積極的に回します。エラーバジェットはカオスエンジニアリングのような「意図的に障害を起こす訓練」の原資にもなります。予算が残っているからこそ、本番でリスクを取る活動が正当化できるのです。
予算を使い切ったら、合意したポリシーに従ってリリースを凍結し、チームの力を信頼性の改善 — 障害の再発防止、ポストモーテムで挙がった改善項目の消化、テストや自動化の強化 — に振り向けます。予算が回復すれば通常運転に戻ります。重要なのは、この切り替えが罰ではなくルールであることです。事前に経営層まで含めて合意されたポリシーだからこそ、凍結の場面で「今回だけは例外に」という政治を排除できます。
バーンレート — 消費の速さで警報を鳴らす
予算の残量だけでなく、消費の速さ（バーンレート）を見るのが実践上の要点です。バーンレートは「いまのエラー率 ÷ SLO が許すエラー率」で、1倍なら窓の終わりでちょうど予算を使い切るペースを意味します。99.9%の SLO でエラー率が1.44%なら14.4倍。このペースでは1時間で30日分の予算の2%（14.4 × 1/720）が溶け、約2日で予算が尽きます。
難しいのは、どれだけの時間のエラー率で判断するか、つまり窓の長さです。短い窓は激しい障害にすぐ反応しますが、3倍程度でじわじわ燃え続ける劣化は短い時間で見ると閾値に届かず、見逃します。長い窓は遅い燃焼も積み上げて捕まえられますが、反応が鈍く、しかも障害が収まった後も窓の中に障害の時間が残っている間は高い値のまま鳴り続けます。そこで Google の『SRE ワークブック』は、窓を複数組み合わせる方式を勧めています。「1時間窓で14.4倍（予算の2%）」「6時間窓で6倍（5%）」なら人を呼び出し、「3日窓で1倍（10%）」ならチケットを切る。さらに、それぞれの長い窓に12分の1の長さの短い窓（1時間窓なら5分窓）を添え、両方が閾値を超えているときだけ鳴らすことで、復旧後の鳴りっぱなしを防ぎます。
部品で確かめてください。障害の形を30日のタイムラインへ置くと、バーンレートの帯と、3つの窓が鳴った区間、予算の残量が描き変わります。「全面障害」は1時間窓が数分で捕まえますが、3日窓は収まった後も3日近く鳴り続けます。「じわじわ劣化」は短い窓が最後まで黙ったまま、3日窓だけが約1日後に気づきます。
上の障害を1つつかんで、30日のタイムラインへドラッグしてください。
SLO 99.9%・30日の窓（予算は約43分ぶんの失敗）。帯の高さはバーンレート（対数軸）、1倍はちょうど30日で予算を使い切るペース。窓の閾値は『SRE ワークブック』の例（1時間で予算の2%・6時間で5%・3日で10%）にならっています。
このように、監視で SLI を集計し、「速い燃焼は短い窓で、遅い燃焼は長い窓で」捕まえる多段のアラートを組むと、一瞬のスパイクによる誤報を抑えつつ、じわじわ進む劣化も捉えられます。「エラー率が1%を超えた」という閾値の警報は、窓が固定で消費の総量を見ていないため、この両方を同時には満たせません。バーンレートの警報は「このままだと SLO を割る」という未来予測に基づいて鳴る点が本質的な改善です。
落とし穴 — 数字が形骸化するとき
エラーバジェットが機能しなくなる典型例は3つあります。第一に、土台の SLO がユーザー体験と乖離している場合。予算の消費が実害と連動しなければ、凍結にも続行にも説得力がありません。第二に、凍結ポリシーが実際には発動されない場合。「予算は尽きたが今期の目玉機能だから出す」を一度許すと、以後この仕組みは誰にも信用されなくなります。第三に、予算を「使い切らないこと」自体を目標にしてしまう場合です。予算が毎期ほぼ満額残るなら、それは慎重さの証ではなく、リリース速度や実験に投資し損ねているシグナル — SLO が緩すぎるか、チームが必要以上にリスクを避けている — と読むべきです。エラーバジェットは節約するものではなく、信頼性と開発速度のトレードオフを最適な位置で運転するためのハンドルなのです。
試問
「30日間でリクエストの99.9%が成功」を約束したサービスの、30日のタイムラインです。上の3つの障害（全面障害・小さな揺れ・じわじわ劣化）をつかんでタイムラインへ置くと、予算の燃える速さ（バーンレート: 許容の何倍の速さで失敗しているか）、3つの警報の窓（1時間窓は14.4倍・6時間窓は6倍・3日窓は1倍を超えると鳴る）、予算の残りが描き変わります。置いた障害はつかんで動かせ、外へ出すと消えます。
上の障害を1つつかんで、30日のタイムラインへドラッグしてください。
SLO 99.9%・30日の窓（予算は約43分ぶんの失敗）。帯の高さはバーンレート（対数軸）、1倍はちょうど30日で予算を使い切るペース。窓の閾値は『SRE ワークブック』の例（1時間で予算の2%・6時間で5%・3日で10%）にならっています。