エラーバジェットとは？SLO運用で許容する障害時間の決め方

「二度とシステムを止めるな」。本番障害の報告を上げた直後に、経営層からそう言われた経験はないでしょうか。一方で、可用性を高めるための冗長化や監視強化には追加の費用がかかり、予算の承認は簡単には下りません。障害はゼロにしろ、しかし投資は増やすな。この板挟みのなかで、運用の判断だけが現場に丸投げされている状態は珍しくありません。

この状況が苦しいのは、「どこまでの停止なら許されるのか」という基準が誰とも合意されていないためです。基準がないので、障害が起きるたびにその場の空気で対策の要否が決まります。ある月は「今回は軽微だから様子見」、別の月は「大事になったから全面的に見直せ」となり、判断が属人的になっていきます。開発を委託しているベンダーとの会話も、「頑張って安定させます」という精神論から抜け出せません。

この問題に対して、Google の SRE（Site Reliability Engineering）が示した答えがエラーバジェットです。発想はシンプルで、「障害をゼロにする」のではなく「止めていい時間を先に決めておく」というものです。あらかじめ許容できる障害時間を数値で決めておけば、その範囲内なら開発を進めてよく、使い切ったら信頼性の改善に手を回す、という判断が自動的に決まります。判断の根拠が数値になるため、経営層にもベンダーにも同じ言葉で説明できます。

本記事では、エラーバジェットとは何かという定義から、SLA・SLO・SLI との違い、具体的な計算方法と稼働率別の許容ダウンタイム早見表、SLO の決め方、そして「使い切ったときに何をするか」を定めるエラーバジェットポリシーの作り方までを順に解説します。あわせて、開発・保守を外部ベンダーに委託している発注者側が押さえるべき責任分界の整理と、保守契約・月次定例への落とし込み方も扱います。社内に SRE 専任者がいない組織でも、次の契約更新や定例会からそのまま使える形にまとめました。

—Free Download / 資料ダウンロード

業務委託エンジニアのマネジメント実践ガイド

この資料でわかること

こんな方におすすめです

• 業務委託エンジニアのオンボーディングを効率化したい
• 正社員と業務委託が混在するチームのマネジメントを改善したい
• 業務委託エンジニアとの長期的な関係を構築したい

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

エラーバジェットとは？SLOから逆算する「許容できる障害時間」

エラーバジェットは、SLO（Service Level Objective / サービスレベル目標）を達成しながら「使ってよい」失敗の量を表した数値です。理念や心構えではなく、分・時間・リクエスト件数といった具体的な単位に換算できる、文字どおりの「予算」として扱います。

エラーバジェットの定義と「予算」という比喩の意味

エラーバジェットの定義は非常に単純で、100% から SLO を引いた残りです。

たとえばあるサービスの SLO を「月間可用性 99.9%」と定めたとします。このとき許容される不可用の割合は 0.1% です。30 日の月に換算すると、43,200 分 × 0.1% = 約 43 分。つまり「この月は 43 分までなら止まってよい」という予算が与えられている状態になります。

「予算」という比喩が重要なのは、使い切るまでは自由に使ってよいという含意があるからです。経費予算が余っているのに一切使わない部署が評価されないのと同じで、エラーバジェットが毎月まったく消費されていない状態は「目標が緩すぎる」か「必要以上に慎重になって変更を止めている」かのどちらかを示唆します。逆に、月の半ばで使い切ってしまったなら、その先は新しいリスクを取る余裕がありません。

この「残高」という考え方によって、これまで感覚で語られていた運用品質が、経費予算と同じように管理・報告・合意ができる対象に変わります。「今月は安定していました」ではなく「今月はエラーバジェットを 62% 消費し、残り 38% です」と報告できるようになる、というのがエラーバジェット導入の実務的な効果です。

信頼性100%を目標にしない3つの理由

「そもそも障害をゼロにすればいいのでは」という疑問に対して、SRE の考え方は明確に「100% は正しい目標ではない」と答えます。Google の SRE book では、100% は達成不可能であるだけでなく、そもそもユーザーが望む以上の信頼性である、と説明されています（Google SRE book: Embracing Risk）。理由は大きく 3 つです。

1. コストが指数的に増える

可用性を 99.9% から 99.99% に引き上げるには、単に「もう少し頑張る」では届きません。冗長構成の追加、自動フェイルオーバーの実装、24 時間の監視・オンコール体制、復旧手順の自動化といった投資が段階的に必要になります。1 桁の 9 を増やすたびに、必要な設備費・人件費は数倍規模で膨らんでいきます。

2. ユーザーは 100% と 99.99% の差を体感できない

ユーザーの端末からサービスに届くまでには、スマートフォンの電波状況、家庭用ルータ、ISP、DNS、CDN など多くの経路が介在します。これらの経路自体が持つ不安定さのほうが大きいため、サービス側が 99.99% を 100% に近づけても、その差はユーザーから見ればノイズに埋もれます。投じたコストが体験の改善として返ってこない領域がある、ということです。

3. 変更を止めると事業が停滞する

障害の主要な原因は変更です。Google SRE の資料でも、障害のおよそ 70% は何らかの変更に起因するとされています（Google SRE Workbook: Example Error Budget Policy）。裏を返せば、リリースを完全に止めれば障害は大幅に減ります。しかしそれは、機能改善も法令対応もセキュリティパッチの適用も止まることを意味します。信頼性を極限まで追求することは、事業の成長を止めることとトレードオフの関係にあります。

エラーバジェットは、この 3 つのトレードオフを「感覚」ではなく「数値」で裁定するための道具です。

SREにおけるエラーバジェットの役割（開発と運用の裁定基準）

SRE の文脈でエラーバジェットが生まれた背景には、開発チームと運用チームの構造的な対立があります。開発側は新機能を早く出したい、運用側はシステムを安定させたい。両者の主張はどちらも正しく、議論だけでは決着がつきません。

エラーバジェットは、この対立を先に決めたルールに委ねることで解消します。

重要なのは、これが罰則ではないという点です。Google が公開しているエラーバジェットポリシーの例でも、非目標（Non-goals）として「懲罰的に使うものではない」ことが明記され、むしろ「データが示すときにチームが信頼性へ集中する許可を与えるもの」と位置づけられています（Google SRE Workbook: Example Error Budget Policy）。

発注者側の立場に置き換えると、エラーバジェットは「ベンダーを責めるための指標」ではなく、自社とベンダーが同じ数値を見て、次に何に投資するかを一緒に決めるための共通言語になります。この位置づけを最初に社内で共有しておかないと、導入した瞬間に減点評価の道具として使われ、機能しなくなります。

エラーバジェットとSLA・SLO・SLIの違いを整理する

エラーバジェットの話をベンダーとすると、しばしば SLA・SLO・SLI の用語が入り混じって会話が噛み合わなくなります。この 3 つは対立する概念ではなく、測る → 目標を置く → 契約するという層の違いです。ここを整理しておくと、その後の合意形成が一気に楽になります。

SLI・SLO・SLAの違いと関係性を一覧で押さえる

4 つの用語の関係は、次の表のように整理できます。

順序としては、まず SLI（何を測るか） を決めなければ SLO は置けません。そして SLO が決まって初めてエラーバジェットが計算できます。SLA はさらにその外側にある、法的拘束力を持った約束です。

発注者側で最初につまずくのは、SLI が定義されていないまま「稼働率 99.9% でお願いします」と数値だけを口にしてしまうケースです。何をもって「稼働している」と判定するのかが決まっていなければ、その数値は計測できず、達成も未達も判断できません。

なお、SLA そのものの中身（発注者が確認すべき項目や交渉のポイント）については、システム開発・保守契約のSLAガイドで詳しく整理しています。本記事では SLA と SLO の「立場の違い」に絞って扱います。

SLAとSLOを同じ数値にしてはいけない理由

実務でよく見られる失敗が、契約書の SLA に書かれた数値をそのまま社内の SLO に採用してしまうことです。たとえば SLA が「月間稼働率 99.9%」だからといって、SLO も 99.9% に置くと、次の問題が起きます。

SLO を下回った瞬間、それは同時に SLA 違反です。つまり、エラーバジェットを 1 分でも超過した時点でペナルティが発生する状態になります。エラーバジェットは本来「使い切る前に気づいて手を打つ」ための予算ですが、SLA と同値にしてしまうと予備の余白がゼロになり、常に緊張状態のまま運用することになります。バジェットの残量が減ってきた段階でリリースペースを落とすといった、本来意図された段階的な対応ができません。

そのため、SLO は SLA よりも厳しい側に置くのが原則です。

この構造にしておくと、SLO を割ってエラーバジェットが枯渇した段階でも、SLA 違反にはまだ余裕があります。この余裕の区間が、対策を打つための時間になります。逆に SLA を SLO より厳しく設定してしまうと、契約上の約束を守れないことが構造的に確定するため、絶対に避けなければなりません。

発注者とベンダーで「稼働率」の定義がずれる典型パターン

同じ「稼働率 99.9%」という言葉を使っていても、発注者とベンダーで想定している中身が違うことは頻繁に起こります。月次報告では「99.95% を達成」と報告されているのに、現場のユーザーからは「先週何度も使えなかった」という声が上がる、という食い違いはここから生まれます。

ずれが生じやすいのは次の 3 点です。

1. 対象範囲のずれ

ベンダーが「サーバが起動していること」を稼働と定義している一方、発注者は「業務が回ること」を稼働と考えている場合です。サーバは動いていても、外部の決済 API が落ちていて注文が完了できなければ、ユーザーにとっては障害です。どこからどこまでを稼働率の対象に含めるのか（自社アプリのみか、外部連携先を含むか、社内ネットワークを含むか）を明文化する必要があります。

2. 計測点のずれ

サーバ側のログで測るのか、外部の監視サービスからの疎通で測るのか、実際のユーザーのブラウザから測るのかで、数値は変わります。サーバ側のログだけを見ていると、CDN や DNS の障害でユーザーが到達できていない時間帯が「正常」としてカウントされてしまいます。

3. 計画停止の扱いのずれ

定期メンテナンスによる計画停止を稼働率の分母から除外するか否かは、契約上の大きな論点です。除外する運用は一般的ですが、「事前に何日前までに通知した停止を除外対象とするか」「緊急のセキュリティパッチ適用は計画停止に含めるか」まで決めておかないと、後から解釈が割れます。

エラーバジェットの議論を始める前に、この 3 点をベンダーと突き合わせておくことをおすすめします。定義が揃っていない状態で数値の話をしても、双方が別のものを見たまま合意した気になるだけです。

エラーバジェットの計算方法と稼働率別の許容ダウンタイム

定義が揃ったら、次は実際の計算です。エラーバジェットの計算自体は掛け算と引き算だけで、表計算ソフトがあれば十分に扱えます。

計算式と計算手順

時間ベースで考える場合の基本式は次のとおりです。

許容ダウンタイム = 対象期間の総時間 × (1 − SLO)

手順に分解すると次のようになります。

1. 対象期間を決める（例: 直近 30 日間、または暦月）
2. 対象期間の総時間を分に換算する（30 日 = 43,200 分）
3. 1 から SLO を引く（SLO 99.9% → 1 − 0.999 = 0.001）
4. 2 と 3 を掛ける（43,200 分 × 0.001 = 43.2 分）
5. 実際のダウンタイムを差し引く（当月すでに 18 分停止 → 残り 25.2 分）

5 で求めた残りが「エラーバジェット残高」です。消費率で表すなら 18 ÷ 43.2 = 約 42% を消費した、という言い方になります。

月次定例で報告する場合は、この「消費率」と「残り時間」の 2 つを併記すると、経営層にも直感的に伝わります。「今月は予算の 42% を使い、残り 25 分です」という表現は、稼働率 99.95% という数字よりもはるかに判断しやすい形です。

稼働率99.9%・99.95%・99.99%の月間／年間ダウンタイム早見表

主要な稼働率と、それに対応する許容ダウンタイムをまとめます。月間は 30 日、年間は 365 日で計算しています。

この表で注目していただきたいのは、数値の差そのものではなく、その水準を満たすために必要な運用体制の差です。

99%（月 7 時間強）: 社内向けの業務システムなど、一時的に停止しても業務を後ろ倒しできるシステムが対象になる水準です。営業時間内の有人対応と、夜間はベストエフォートという体制でも到達し得ます。

99.9%（月 43 分）: 一般的な Web サービス・業務システムで採用されることが多い水準です。43 分という時間は、「障害に気づいてから復旧するまで」を含んだ時間である点に注意が必要です。人が異常に気づくまで 20 分かかる運用では、月に 1 回の障害でほぼ使い切ります。監視によるアラート通知の自動化と、営業時間外の一次受け体制が事実上の前提になります。

99.95%（月 21 分）: 復旧作業を始めるまでの時間がほとんど残りません。手動での切り替え手順では間に合わないため、冗長構成と自動フェイルオーバーが必要になります。24 時間のオンコール体制も現実的な要件になります。

99.99%（月 4 分）: 人間が状況を確認して判断する時間はありません。マルチ AZ・マルチリージョン構成、自動復旧、カナリアリリースなど、アーキテクチャレベルでの設計が求められます。保守費用の見積もりは 99.9% の水準から大きく跳ね上がります。

つまり、99.9% と 99.99% の違いは「0.09 ポイントの差」ではなく、「人が対応する運用」と「システムが自動で復旧する運用」という体制の断絶です。経営層に投資の必要性を説明する際は、この体制差を提示するほうが数値の桁を並べるより伝わります。

時間ベースとリクエストベース、どちらで数えるか

エラーバジェットの数え方には、大きく 2 つの流儀があります。

時間ベース（ダウンタイム換算）

「合計何分止まったか」で数える方式です。契約書の稼働率条項と相性がよく、直感的に理解しやすいという利点があります。一方で、「完全には止まっていないが、一部の機能が遅くて使い物にならない」という部分的な劣化を表現しづらいという弱点があります。

リクエストベース（エラー率換算）

「全リクエストのうち、正常に処理できたリクエストの割合」で数える方式です。たとえば月間 1,000 万リクエストで SLO 99.9% なら、エラーバジェットは 1 万リクエスト分になります。

リクエストベースの利点は、ユーザーへの影響の大きさを反映できる点です。深夜 3 時に 10 分止まった場合と、平日の昼に 10 分止まった場合では、影響を受けるユーザー数がまったく違います。時間ベースでは同じ 10 分としてカウントされますが、リクエストベースなら実際の影響量の差がそのまま消費量の差になります。Google SRE の実装ガイドでも、SLI は「有効なイベントのうち良好なイベントの割合」として定義することが推奨されています（Google SRE Workbook: Implementing SLOs）。

どちらを選ぶかの実務的な指針は次のとおりです。

• 対外的な報告・契約と整合させたい、まず簡単に始めたい → 時間ベース
• ユーザー影響を正確に反映させたい、利用が時間帯で偏る → リクエストベース

社内に SRE 専任者がいない状況では、まず時間ベースで運用を始め、監視基盤が整った段階でリクエストベースに移行する、という順序が現実的です。最初から精緻な指標を目指して着手が遅れるより、粗くても月次で数値を見る習慣を作るほうが効果があります。

エラーバジェットの前提となるSLOの決め方

ここまで見てきたとおり、エラーバジェットは SLO が決まらなければ計算できません。そして実務で最も難しいのが、この SLO をいくつに置くかという判断です。ここでは「決められない」という手詰まりを抜けるための 3 つの原則を示します。

測る対象をユーザーの重要操作から決める

SLO を決める前に、まず 何を測るか（SLI） を決めます。ここでよくある間違いが、監視ツールが出せる指標を片端から SLI にしてしまうことです。CPU 使用率もメモリ使用量もディスク I/O も重要な運用指標ですが、これらは SLI には向きません。CPU 使用率が高くてもユーザーが問題なく使えているなら、それは SLO の未達ではないからです。

SLI として選ぶべきなのは、ユーザーが本当に困る操作です。SRE ではこれをクリティカルユーザージャーニー（CUJ）と呼びます。

• EC サイトなら: 商品検索 → カート投入 → 決済完了
• 業務システムなら: ログイン → 申請作成 → 承認処理
• 顧客向けポータルなら: ログイン → 帳票ダウンロード

これらのうち、止まると業務や売上が直接止まるものを 1〜2 個に絞り込みます。すべての機能に SLO を置こうとすると設計が終わらないため、最初は「これが止まったら経営層に報告が必要になる操作」を 1 つ選ぶところから始めるのが実務的です。

なお、SLI を測るには対象の操作の成否をログやメトリクスとして取得できる状態が前提になります。現状の監視がサーバの死活監視だけであれば、まずアプリケーション側の応答結果を記録する仕組みの整備が先になります。

理想値ではなく実績値からSLOを置く

SLO の数値は、理想から決めるのではなく、直近の実績から決めます。

「99.99% を目指したい」という願望から入ると、実績が 99.5% しかない組織では初月から達成不可能な目標になり、エラーバジェットは常にマイナスのまま誰も見なくなります。逆に「99% にしておけば安全だ」と緩く置きすぎると、ユーザーが不満を感じている水準を「達成」と評価してしまいます。

推奨される手順は次のとおりです。

1. 直近 3〜6 か月の実績を測る（過去のログや監視データから、選んだ SLI の達成率を算出する）
2. 実績値をそのまま、または少しだけ厳しい水準に置く（実績 99.85% なら SLO は 99.9%）
3. ユーザーからの苦情の発生状況と突き合わせる（実績を満たしていても苦情が多いなら、SLI の選び方かしきい値が実態と合っていない）

「今より少しだけ厳しい」水準にすることで、達成可能でありながら改善の圧力も働く目標になります。実績が測れない場合は、まず 1〜2 か月測ることから始め、その間は SLO を仮置きにしておいて構いません。SLO は一度決めたら変えられないものではなく、定期的に見直す前提のものです。

厳しすぎるSLOが運用コストを押し上げる仕組み

SLO を高く設定することには、目に見えにくいコストが伴います。発注者側は「高いほうが安心」と考えがちですが、その要求はそのまま保守費用の見積もりに跳ね返ります。

厳しい SLO が引き起こす費用構造は次のとおりです。

見落とされやすいのが最後の行です。厳しい SLO はリリースを慎重にさせるため、機能改善のスピードが落ちます。これは請求書には現れませんが、事業にとっては確実なコストです。

したがって SLO の設定は、技術的な議論であると同時に事業判断です。「この機能が月に 43 分止まることによる business impact はどれくらいか」「それを 21 分に半減させるために年間いくら払えるか」という問いを、事業部門と経営層を交えて議論する必要があります。この議論を経ずに情報システム部門だけで数値を決めると、後から「なぜそんなに費用がかかるのか」と説明を求められることになります。

—Free Download / 資料ダウンロード

業務委託エンジニアのマネジメント実践ガイド

この資料でわかること

こんな方におすすめです

• 業務委託エンジニアのオンボーディングを効率化したい
• 正社員と業務委託が混在するチームのマネジメントを改善したい
• 業務委託エンジニアとの長期的な関係を構築したい

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

エラーバジェットポリシーの作り方と枯渇時のアクション

SLO を決め、エラーバジェットを計算できるようになっただけでは、運用は変わりません。「使い切ったときに何をするか」が決まっていなければ、数値は月次報告の飾りになります。これを事前に文書化したものがエラーバジェットポリシーです。

エラーバジェットポリシーに書くべき項目

Google が公開しているエラーバジェットポリシーの例（Google SRE Workbook: Example Error Budget Policy）を参考にすると、盛り込むべき項目は次のように整理できます。

特に重要なのが「目的と非目的」の明記です。Google の例でも、このポリシーは罰を与えるためのものではなく、データが示すときに信頼性へ集中する許可を与えるためのものである、と明示されています。この一文がないと、運用開始後に「バジェットを使い切ったのは誰の責任か」という犯人探しが始まり、障害の過少報告を招きます。

なお、「エスカレーション先」も軽視できません。エラーバジェットの計算方法や、ある事象を消費に含めるかどうかで意見が割れることは必ず起きます。Google の例では、この種の不一致は CTO に判断を仰ぐと定められています。社内の誰が最終判断するかを先に決めておくことで、判断待ちで運用が止まる事態を避けられます。

エラーバジェットが枯渇したときのアクションと例外の決め方

エラーバジェットを使い切った場合の典型的なアクションは「新機能のリリースを凍結し、信頼性の改善作業を優先する」というものです。ただし、これを全面停止として運用すると、現場ではすぐに破綻します。

現実には、凍結中でも進めなければならない変更があります。ポリシーには、次のような例外を事前に定義しておきます。

• 緊急のセキュリティ対応（脆弱性のパッチ適用など、放置するほうがリスクが高い変更）
• 信頼性を改善する変更（そもそも凍結の目的がこれなので、当然許可される）
• 障害の復旧・再発防止のための修正
• 法令・制度改正への対応など、期限が外部で決まっている変更
• 対外的に日程を約束済みで、延期による損害が明確な変更（承認者を定めた上で例外扱い）

逆に、凍結対象として明示すべきなのは「新機能の追加」「大規模なリファクタリング」「緊急性のない仕様変更」といった、延期しても実害が小さい変更です。

この「許容する変更の種類」を事前に文書化しておくことが、ポリシーを形骸化させないための鍵になります。事前定義がないと、枯渇のたびに「これは例外か否か」の交渉が発生し、結果として声の大きい人の意見が通る運用に戻ってしまいます。

バーンレートで枯渇前に気づくアラート設計

月末になって初めて「エラーバジェットを使い切っていました」と分かるのでは、打てる手がありません。そこで使われるのがバーンレート（burn rate / 消費速度）という考え方です。

バーンレートは「エラーバジェットを、想定より何倍の速さで消費しているか」を表す倍率です。バーンレート 1 なら、期間の終わりにちょうど使い切るペース。バーンレート 10 なら、想定の 10 倍の速さで消費しており、期間の 10 分の 1 の時間で枯渇する計算になります。

バーンレートでアラートを組む利点は 2 つあります。

1. 枯渇する前に検知できる（残量ではなく速度を見るため、先回りできる）
2. 通知の重要度を段階分けできる（急激な消費は即時対応、緩やかな消費は翌営業日対応、といった振り分けが可能）

Google SRE では、複数の時間窓と複数のバーンレートしきい値を組み合わせるマルチウィンドウ・マルチバーンレート方式が推奨されています（Google SRE Workbook: Alerting on SLOs）。長い時間窓（数時間〜数十時間）で持続的な劣化を捉えつつ、短い時間窓を併用することで、一時的なスパイクによる誤検知を減らし、復旧後のアラート解除も速くなる、という設計です。

社内に SRE 専任者がいない組織でいきなりこの構成を組むのは負荷が高いため、まずは**「残量 50% で通知」「残量 25% で警告」「残量 0% でポリシー発動」の 3 段階**から始めるだけでも十分に効果があります。重要なのは、月末を待たずに残量が見える状態を作ることです。

凍結解除基準とポリシーの見直しサイクル

見落とされやすいのが、凍結をいつ解除するかの基準です。

エラーバジェットの計測に「直近 4 週間」のようなローリングウィンドウを使っている場合、大きな障害を 1 回起こすと、その障害が計測窓から外れるまで残量がマイナスのまま推移します。つまり、原因を修正し再発防止策を打ち終わっていても、カレンダー上で 4 週間が経過するまで凍結が続くという事態が起こります。これは現場の納得感を大きく損ないます。

そのため、解除基準は「バジェットが回復したら」だけでなく、次のような条件を併記しておくのが現実的です。

• 障害の根本原因が特定され、恒久対応または明確な暫定対応が完了していること
• 振り返り（ポストモーテム）が実施され、再発防止のアクションアイテムが登録されていること
• 上記を運用責任者が確認し、承認していること

これらを満たした場合は、残量が回復していなくても凍結を解除できる、という設計にしておくと、ポリシーが「消化試合の待ち時間」になるのを防げます。

また、ポリシー自体にも見直しのサイクルを設定します。半年〜1 年ごとに、次を点検します。

• SLO の水準は実態と合っているか（毎月余りすぎ／不足しすぎていないか）
• SLI がユーザーの体感と乖離していないか
• 例外規定が使われすぎていないか（使われすぎているなら凍結範囲の設計が過剰）
• 凍結が実際に発動され、機能したか

一度決めたポリシーを固定するのではなく、運用しながら調整していく前提で作ることが、長期的に機能させるための条件です。

開発・保守を外部委託している場合のエラーバジェット合意

ここまでの内容は、社内に開発チームと運用チームがある前提で語られることが多いテーマです。しかし、開発・保守を外部ベンダーに委託している発注者の立場では、さらに整理しなければならない論点があります。「エラーバジェットを消費するのは誰か」「超過したら誰が何をするのか」という責任分界の問題です。

エラーバジェットを消費するのは誰か（責任分界の整理）

エラーバジェットを消費する原因は、責任の所在で分けると概ね次の 4 種類になります。

この分類なしにエラーバジェットだけを導入すると、枯渇したときに「これは誰のせいか」という議論が始まり、運用が止まります。実務上は、責任主体を特定すること自体が目的ではなく、消費要因の内訳を可視化して次の投資判断につなげることが目的である、という前提を先に共有しておくことが重要です。

そのうえで、次の 2 点は事前に決めておく価値があります。

1. 不可抗力の扱い

クラウド事業者のリージョン障害のような、どちらにも制御できない事象をエラーバジェットの消費に含めるかどうか。含めない運用は説明しやすい一方、「実際にユーザーは使えなかった」という事実が数値から消えるため、冗長化投資の必要性が見えにくくなります。消費としてはカウントするが、ベンダーの評価には反映しないという分離が、実態と評価の両方を満たす折衷案になります。

2. 発注者起因の変更の扱い

「急ぎで入れてほしい」と発注者が押し込んだ変更が障害を招いた場合も、消費としてはカウントします。これを可視化することで、「急ぎの依頼を通すたびにエラーバジェットを消費している」という構造が数値で見えるようになり、発注者側の依頼の出し方にもフィードバックが働きます。

保守契約・SLAへの落とし込み方（ペナルティにしない設計）

エラーバジェットを保守契約に書き込む際、最も重要な判断が「ペナルティ条項にしない」ことです。

エラーバジェット超過に対して減額や違約金を紐づけると、次の副作用が起こります。

• 障害の過少報告: 軽微な事象を報告しない、影響時間を短く申告するインセンティブが生まれる
• 見積もりの過剰化: リスクを織り込んだ結果、保守費用が不必要に膨らむ
• 改善提案の停止: 変更そのものがリスクになるため、ベンダーが積極的な改善提案をしなくなる

エラーバジェットは本来、開発速度と信頼性のバランスを取るための道具です。罰則と結びつけると、「速度を落として安全側に倒す」という一方向の圧力しか生まれません。

推奨されるのは、優先順位変更のトリガーとして契約に書く方法です。具体的には次のような条項の形になります。

• エラーバジェットの残量が一定水準を下回った場合、当該期間の作業優先度を信頼性改善に振り替えることを双方が合意する
• 優先度を振り替えた場合、遅延する開発項目とその影響を書面で共有する
• 消費要因の内訳（発注者起因／ベンダー起因／外部要因）を月次で報告する
• 単一障害でバジェットの一定割合以上を消費した場合、原因分析と再発防止策の提出を必須とする

つまり、お金のペナルティではなく、作業の中身を切り替える約束として書く、ということです。この形であれば、ベンダーにとっても「品質改善に工数を割く正当な根拠」になり、双方にとって機能します。

なお、稼働率・RTO・RPO といった具体的な数値を契約条項としてどう表現するかについては、保守契約にSLAを盛り込む方法で条項サンプルとあわせて解説しています。エラーバジェットの数値を契約文言に変換する際の参考になります。

月次定例で確認するエラーバジェット報告項目

契約に書いただけでは運用されません。エラーバジェットを実際に機能させるには、月次定例の議題として固定するのが最も確実です。次の 5 項目をチェックリストとして持っておくと、毎月同じ粒度で確認できます。

1. 当月のエラーバジェット消費量と残量

「消費率 ◯%」「残り ◯ 分」の 2 表記で確認します。SLO の達成／未達だけでなく、消費のペースを見ることが目的です。

2. 主な消費要因の内訳

どの事象が何分消費したかを一覧で確認します。1 件の大きな障害で消費したのか、小さな事象が積み重なったのかで、次の打ち手がまったく変わります。

3. 消費要因の責任区分

発注者起因／ベンダー起因／外部要因の内訳を確認します。犯人探しではなく、投資すべき箇所を特定するための情報として扱います。外部要因の比率が高いなら冗長化、ベンダー起因が高いならテスト・レビュー体制、発注者起因が高いなら依頼プロセスの見直しが論点になります。

4. バジェット超過時に実施した対応

超過が発生した月は、ポリシーどおりの対応（凍結・優先度の振り替え）が実際に行われたかを確認します。ここが「対応なし」で通り続けるなら、ポリシーは形骸化しています。

5. 翌月の改善アクションと期日

再発防止策の実施状況と、翌月に取り組む改善項目を確認します。担当（自社／ベンダー）と期日をセットで記録します。

あわせて、障害発生時の一次対応時間・連絡フローが保守契約の内容と整合しているかも定期的に点検しておくと、いざというときの動きが速くなります。障害発生時のベンダーへの連絡や社内報告の判断基準については、本番障害の対応フローで整理しています。

エラーバジェット運用でつまずきやすい点と対策

エラーバジェットは導入すること自体は難しくありませんが、数か月後に誰も見なくなるケースが少なくありません。典型的な失敗パターンを、対策とセットで押さえておきましょう。

SLIがユーザー体験を反映していない

最も多い失敗が、指標の選び方です。サーバの死活監視だけを SLI にしていると、「サーバは全台正常に応答しており SLO は達成、ただしユーザーはログインできなかった」という状態が起こります。数値上は健全なのに現場からは不満が上がるため、指標そのものへの信頼が失われます。

対策: SLI をユーザーの重要操作（ログイン、注文確定、帳票出力など）の成否で定義し直します。すべてを一度に変えるのではなく、まず 1 つの操作について、成功／失敗をログから集計できる状態を作ります。あわせて、実際に上がってきた苦情と SLI の数値を毎月突き合わせ、乖離があれば SLI 側を修正します。

事業・経営側の合意がなく意思決定に使われない

情報システム部門だけでエラーバジェットを決めた場合、枯渇しても開発は止まりません。事業部門が「このリリースは今月中に必要だ」と主張すれば、その場の力関係で押し切られます。これが 2〜3 回続くと、ポリシーは存在するだけの文書になります。

対策: SLO の決定を情報システム部門の技術判断ではなく、事業判断として合意形成するプロセスに変えます。SLO を決める会議に事業部門の責任者を参加させ、「この水準を守るためにリリースを止めることがある」という結論まで含めて承認を取ります。そのうえで、エラーバジェットの状況を事業部門にも毎月共有します。決定に関与した人は、その結果にも従いやすくなります。

計測が手作業で判断に間に合わない

エラーバジェットの計算を月末に手作業で行っている場合、結果が分かるのは翌月です。「先月は使い切っていました」と言われても、打てる手はもうありません。集計自体も担当者の負担になり、忙しい月には後回しになって計測が途切れます。

対策: 計測と可視化を自動化します。監視ツール（Datadog、Mackerel、Grafana など）の多くは SLO・エラーバジェットの表示機能を持っており、ダッシュボードで残量を常時確認できます。ツールの導入が難しい場合でも、ログから週次で集計するバッチを組むだけで、判断の遅れは大きく改善します。少なくとも「月末まで分からない」状態は避けてください。

最初から完璧を目指して運用が止まる

「全サービスに SLO を設定してから始めよう」「SLI の定義を精緻にしてから運用しよう」と考えると、設計だけで数か月が過ぎ、結局始まりません。また、初回設定で SLO を厳しく置きすぎると、初月から残量がマイナスになり、「うちには無理だった」という結論になりがちです。

対策: 1 サービス・1 指標・1 か月から始めます。最も重要なサービスを 1 つ選び、最も重要な操作を 1 つ選び、直近実績から SLO を仮置きして、1 か月分だけ試算してみる。この規模なら表計算ソフトでも十分に回せます。1 か月やってみると、SLI の定義の粗さも、SLO の妥当性も、実データをもとに議論できるようになります。

エラーバジェットは、正確さより継続して見ることに価値がある指標です。粗い数値でも毎月見ていれば傾向が分かり、傾向が分かれば判断ができます。

まとめ｜エラーバジェットは「止めていい時間」を先に決める道具

エラーバジェットとは、SLO（サービスレベル目標）から逆算して「許容できる障害時間」を数値化し、開発を進めるか信頼性の改善に振るかを判断するための予算です。障害をゼロにすることを目指すのではなく、止めていい時間を先に決めておくことで、その場の空気や声の大きさに左右されない意思決定ができるようになります。

導入の手順を、そのまま社内説明に使える順序で整理します。

1. 測る対象を決める: ユーザーが本当に困る操作（ログイン、注文確定など）を 1 つ選び、成否を測れる状態にする
2. 実績値から SLO を置く: 理想値ではなく直近 3〜6 か月の実績を起点に、少しだけ厳しい水準を仮置きする
3. エラーバジェットを時間に換算する: 対象期間 ×（1 − SLO）で許容ダウンタイムを算出し、「月間 ◯ 分」の形にする
4. 枯渇時のアクションを合意する: 残量別の対応、例外として通す変更、解除基準、エスカレーション先をポリシーとして文書化する
5. 委託先との責任分界と報告項目を組み込む: 消費要因の区分を整理し、保守契約にはペナルティではなく優先順位変更のトリガーとして記載し、月次定例の議題に固定する

最初の一歩としておすすめしたいのは、1 サービス・1 指標で 1 か月分だけ試算してみることです。過去の障害記録から停止時間を拾い、SLO を仮に 99.9% と置いて、「先月はエラーバジェットの何 % を消費していたか」を計算してみてください。この 1 つの数字があるだけで、次の障害報告の場での会話が変わります。「安定していました／していませんでした」ではなく、「予算の何 % を使い、何に消費したか」という共通の土俵ができるからです。

「二度と止めるな」という要求に真正面から答えることはできません。しかし、「月 43 分までの停止を許容し、それを超えたら開発を止めて信頼性に投資します」という提案なら、根拠つきで経営層にもベンダーにも提示できます。エラーバジェットは、その提案を可能にするための道具です。

関連情報

システムの保守・運用体制を外部ベンダーと整理するうえでの確認項目をまとめた資料として、失敗しないためのシステム保守の引継ぎチェックリストをご用意しています。運用の引き継ぎ・体制見直しを検討されている方はご活用ください。

SLO の設定や保守契約の設計についてご相談がある場合は、お問い合わせフォームからご連絡ください。現状の運用体制の整理段階からご相談いただけます。

—Free Download / 資料ダウンロード

業務委託エンジニアのマネジメント実践ガイド

この資料でわかること

こんな方におすすめです

• 業務委託エンジニアのオンボーディングを効率化したい
• 正社員と業務委託が混在するチームのマネジメントを改善したい
• 業務委託エンジニアとの長期的な関係を構築したい

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。