SLOとは？SLA・SLIとの違いと目標値の決め方、エラーバジェットの運用

SLO（Service Level Objective、サービスレベル目標）は、SLI（サービスレベル指標）で測った値に対して置く目標値です。「直近28日間で、成功したリクエストの割合を99.9%以上に保つ」のように、指標・目標値・計測期間の3つをセットで決めます。読み方は「エスエルオー」です。

この記事では、Google SRE本の定義をもとにSLA・SLI・KPIとの違いを整理したうえで、目標値の決め方、計測期間の選び方、エラーバジェットとバーンレートの計算、予算を使い切ったときに何を止めるかを決めるエラーバジェットポリシーまでを扱います。

まとめ：SLOの目標値・計測期間とエラーバジェットの運用合意

• SLOはSLIに対する目標値です。SLAは未達時の結果（返金やペナルティ）を伴う契約で、「SLOを外したら何が起きるか」に明示的な答えが無ければ、それはSLOです。
• 目標値は現在の性能をそのまま写さず、ユーザーが満足する水準から決めます。100%は狙いません。顧客向けSLAより厳しい社内SLOを置き、余裕を持たせます。
• 計測期間は、ユーザー体験に近い4週間（28日）のローリング期間が汎用的な出発点です。
• エラーバジェットは「(1 − SLO) × 期間内の対象イベント数」です。99.9%・100万リクエストなら、許される失敗は1,000件です。
• SLOを運用に効かせるのはエラーバジェットポリシーです。「4週間で予算を超えたら、最優先の不具合とセキュリティ修正以外のリリースを止める」のように、誰が何を止めるかを文書で合意します。

SLOの定義とSLI・SLAとの違い

SRE本によるSLO・SLI・SLAの定義

GoogleのSRE本 第4章「Service Level Objectives」は、3つの用語を次のように定義しています。

• SLI：提供しているサービスレベルのある側面を、注意深く定義して測る定量的な尺度（原文 a carefully defined quantitative measure of some aspect of the level of service）。
• SLO：SLIで測るサービスレベルの目標値、または目標範囲（原文 a target value or range of values for a service level that is measured by an SLI）。形は「SLI ≤ 目標値」か「下限 ≤ SLI ≤ 上限」になります。
• SLA：ユーザーとの明示的または暗黙の契約で、含まれるSLOを満たした（外した）ときの結果を伴うもの。結果は返金やペナルティなど金銭的なものが分かりやすい、とされています。

同じ章は、SLOとSLAの見分け方として「SLOを外したら何が起きるか」を問うよう勧めています。明示的な結果が無ければ、ほぼ確実にSLOです。Google検索は一般利用者とのSLAを持たないサービスの例として挙げられていますが、それでもSLIとSLOを定めて運用する価値はある、と書かれています。SLIの指標の型や測り方はSLIとは？SLOとの違いと指標の選び方・PromQLでの測り方、SLAの契約項目やサービスクレジットはSLA（サービスレベル合意）とは？要件に書く項目とSLOとの違い、未達時のサービスクレジットで詳しく扱っています。

SLI・SLO・SLAの比較表

SRE本は、SLAは事業や製品の判断と結びつくためSREは通常SLAの作成には深く関わらず、SLOを外して契約上の結果が発動するのを防ぐ側に回る、と書いています。実務では「SLA 99.5%・社内SLO 99.9%」のように、SLAより厳しいSLOを置くのが基本です。

SLOとKPIの違い

KPI（重要業績評価指標）は売上・解約率・申込数のように事業の成果を測る指標で、SLOはユーザーが受け取るサービスの質に置く目標です。両者は対象が違うだけで競合しません。たとえば「決済完了率」はKPIにもSLIにもなり得ますが、SLOとして扱うときは「決済APIへのリクエストのうち、2秒以内に成功した割合を28日で99.9%以上」のように、測り方・目標・期間まで決めます。KPIの悪化は事業判断のきっかけになり、SLOの未達は次章以降のエラーバジェットポリシーに沿った開発の優先度変更につながります。

SLOを構成する3要素：SLI・目標値・計測期間

Google CloudのSLOモニタリングのドキュメントは、SLOを「SLI」「パフォーマンス目標」「コンプライアンス期間」の3つで組み立てると説明しています。例として挙げられているのは「ローリング30日間で、300msを超えてよいのはリクエストの5%まで」「カレンダー週で99%の可用性」です。

リクエスト単位と時間枠単位のSLI

同じドキュメントは、SLIを2種類に分けています。リクエスト単位（成功したHTTPリクエストの数のように、処理の単位を数える）と、時間枠単位（レイテンシが閾値を下回っていた時間枠の数を数える）です。DatadogのService Level Objectivesも同じ考え方で、メトリクスベースは件数で、モニターベースとTime Sliceは時間で計算します。トラフィックが一日の中で大きく偏るサービスでは、件数ベースだと閑散時間の障害が薄まり、時間枠ベースだと少数の失敗で枠全体が「悪い」になる、という性格の違いがあります。

ローリング期間とカレンダー期間

SRE Workbook「Implementing SLOs」は、期間の選び方を次のように整理しています。

• ローリング期間：ユーザー体験に近い方式です。月末に大きな障害があっても、ユーザーは翌月1日に忘れるわけではありません。期間は週の整数倍にして、常に同じ数の週末を含めることが勧められています（30日だと週末の数が期間ごとに変わります）。
• カレンダー期間：四半期ごとの計画や人員配置と合わせやすい方式です。一方で期間の途中では残りのリクエスト数が分からず、予算の大きさが確定しません。

Workbookは、汎用の期間として4週間のローリング期間を挙げ、週次の要約で作業の優先度を、四半期の要約で計画を決める運用を紹介しています。ツール側の制約も確認しておきます。Datadogは目標と期間を「過去7日・30日・90日のローリング」から選びます。Google Cloud Monitoringは、概要ページでは目標値の上限を99.9%としていますが、APIリファレンスでは 0 < goal <= 0.9999（99.99%）と定義しており、資料間で値が食い違っています。99.9%を超える目標を置く場合は、設定画面かAPIで実際に通るか確かめてください。APIで作る場合のローリング期間は1日単位で30日まで、カレンダー期間は日・週・2週・月の4種類です（Cloud Monitoring API v3のServiceLevelObjective）。

SLOの目標値を決める5つの指針と許容停止時間

SRE本が挙げる目標値の決め方

SRE本 第4章の「Choosing Targets」は、目標値を決める際の教訓を5つ挙げています。

最初の指針は、実績値をそのまま目標にしないことです。現在の実績が99.98%だからといってSLOを99.98%にすると、それを守るために無理な対応が続き、大きな作り直しなしには改善できないシステムに縛られる、とSRE本は説明しています。「本数を絞る」の判断基準も具体的で、優先度の議論でそのSLOを引用して一度も勝てないなら、そのSLOは持つ価値がおそらく無い、とされています。

100%を狙わない理由について、SRE本の「Embracing Risk」の章は、信頼性はある点を超えると上げるほどサービスと利用者にとって悪くなると述べています。機能開発の速度が落ち、費用が大きく増えるためです。Workbookは、障害の最大の原因は変更（新機能、セキュリティパッチ、ハードウェアの追加、需要への増強）であり、100%を維持しようとすればサービスを一切更新できなくなる、と書いています。

同じ章はさらに2つの戦術を挙げています。1つは安全余裕を持つことで、利用者に公表するSLOより厳しい社内SLOを置けば、慢性的な問題が外から見える前に手を打てます。もう1つは出来すぎないことです。実際の性能がSLOを大きく上回り続けると、利用者はその性能を前提に作り込んでしまいます。Googleの分散ロックサービスChubbyは、可用性が高すぎたために計画停止を導入しました。

ナイン別の許容停止時間（30日・28日・365日）

可用性のSLOは「ナイン（9の数）」で表されることが多く、1桁違うだけで許される停止時間は10分の1になります。下の表は、時間ベースの可用性SLOで期間内に許容される全停止時間の合計で、30日＝43,200分、28日＝40,320分、365日＝525,600分で計算し、秒未満は四捨五入しています。

リクエスト単位のSLOでは、この時間はあくまで目安です。全停止ではなく一部のリクエストだけが失敗する障害なら、同じ予算でより長い時間を耐えられます。逆に、アクセスが集中する時間帯の全停止は、件数ベースのSLOでは時間の割合以上に予算を消費します。

Web APIのSLO設定例：可用性とレイテンシの目標値

一般的なWeb APIを想定し、28日ローリングで可用性に1本、レイテンシに2本のSLOを設定した例です。レイテンシは平均値ではなく分位点（「95%が300ms以内」）で決めます。平均だと、一部の利用者だけが極端に遅い状態を見落とすためです。

4xxを失敗に数えるかは、利用者の入力ミスによるものかどうかで決めます。ヘルスチェックや負荷試験のリクエストは対象から除外しておかないと、予算が実際の利用者と関係なく減ります。社内の監視・運用体制ごと見直す場合は、issohの保守運用・内製化支援でSLOの設計から監視の実装まで相談できます。

エラーバジェットとバーンレートの計算

エラーバジェットの計算式

Google Cloudのドキュメントは、コンプライアンス期間のエラーバジェットを「(1 − SLO目標) × 期間内の対象イベント数」と定義しています。SRE Workbookのエラーバジェットポリシー例にある例では、4週間で1,000,000リクエストを受けるサービスに99.9%の可用性SLOを置くと、その期間の予算は1,000件の失敗です。

バーンレートとマルチウィンドウのアラート

バーンレートは、SLOに対してエラーバジェットを消費する速さです。SRE Workbook「Alerting on SLOs」は、バーンレート1を「期間の終わりにちょうど予算がゼロになる消費速度」と説明しています。30日・99.9%のSLOで同書が推奨する初期値は次のとおりです。

短い窓は長い窓の12分の1が目安とされています。1時間の窓だけで判定すると、障害が収まっても過去の失敗が窓内に残り、通知の解除が最大で約1時間遅れることがあるためです。下のPythonコードは、予算の消費率とバーンレートを計算し、1時間と5分の両方が14.4倍を超えたときだけページを出す判定を再現します。

# SLOのエラーバジェット消費とバーンレートを計算する（Python 3.8以降・標準ライブラリのみ）
SLO = 0.999               # 目標 99.9%
WINDOW_HOURS = 30 * 24    # 30日の計測期間

def budget_used(total, bad, slo=SLO):
    """期間中の許容失敗数と、その何割を使ったか"""
    allowed = (1 - slo) * total
    return allowed, bad / allowed

def burn_rate(total, bad, slo=SLO):
    """観測した失敗率がエラーバジェットの何倍の速さか（1なら期間末にちょうど使い切る）"""
    return (bad / total) / (1 - slo)

# 30日間で 1,000,000 リクエスト中 400 件が失敗
allowed, used = budget_used(1_000_000, 400)
print(f"許容失敗数 {allowed:.0f} 件 / 消費 {used:.0%} / 残り {1 - used:.0%}")

# 直近1時間と直近5分の両方が14.4倍を超えたらページ（SRE Workbook の推奨値）
windows = {"1h": (1_400, 21), "5m": (115, 2)}
rates = {name: burn_rate(t, b) for name, (t, b) in windows.items()}
for name, r in rates.items():
    print(f"{name}: バーンレート {r:.1f}")
print("ページする" if all(r > 14.4 for r in rates.values()) else "ページしない")

# 14.4倍が続いたら何時間で予算が尽きるか／1時間で何%を使うか
print(f"枯渇まで {WINDOW_HOURS / 14.4:.0f} 時間、1時間で予算の {14.4 / WINDOW_HOURS:.0%}")

実行結果は次のとおりです。一定のリクエスト流量で予算が全量残っていると仮定すると、14.4倍の消費が続けば30日分の予算は50時間で尽き、1時間で予算の2%を使います。これが表の1行目の根拠です。

許容失敗数 1000 件 / 消費 40% / 残り 60%
1h: バーンレート 15.0
5m: バーンレート 17.4
ページする
枯渇まで 50 時間、1時間で予算の 2%

Prometheusの記録ルールとアラートルールでこの判定を組み、promtoolで検証する手順はSRE本 第2版の変更点：初版との違いと読む章、SLOアラートの実装例にまとめています。

トラフィックが少ないサービスでの注意

同じWorkbookは、1時間に10リクエストしか来ないシステムでは1件の失敗で1時間の失敗率が10%になり、99.9%のSLOではすぐにページされてしまう、と注意しています。失敗率10%を予算の0.1%で割ると、バーンレートは100倍です。対策として挙げられているのは、人工的なトラフィックの生成、小さなサービスを監視上ひとまとめにすること、1件の失敗だけで障害と見なさない製品側の変更などです。夜間にほぼアクセスが無い社内システムでは、バーンレートのアラートをそのまま入れる前に、1日あたりのリクエスト数を確認してください。アラートの数を減らす設計全般はアラート疲れとは｜原因と対策を監視の実装視点で解説【2026年時点】で扱っています。

エラーバジェットポリシー：予算超過時の変更停止と例外条件

SLOを決めただけでは、未達になっても誰も動きません。Workbookは、エラーバジェットを使うには「予算が尽きたときに何をするか」を書いたポリシーが必要だとし、その例をExample Error Budget Policyとして公開しています。

予算超過時の対応と例外の条件

ポリシー例の中心は次の1文です。直前の4週間でエラーバジェットを超えたら、P0（全員で対応する最優先の不具合）とセキュリティ修正以外のすべての変更とリリースを、SLO内に戻るまで止めます。ただし罰ではないことが明記されており、データが信頼性を優先すべきと示したときに、チームが信頼性の作業だけに集中する許可を与えるもの、と位置づけられています。

ポストモーテムを必須にする20%の線

同じポリシー例は、1件の障害が4週間で予算の20%超を消費したらポストモーテムを必須とし、根本原因に対するP0の対応項目を最低1つ含めるとしています。同じ種類の障害が四半期で予算の20%超を消費した場合は、翌四半期の計画にP0項目として載せます。ポリシーにこうした数字を入れておくと、障害のたびに振り返りをするかどうかを議論せずに済みます。

プロダクト・開発・SREの合意によるSLOの妥当性確認

Workbookは、プロダクトマネージャー・開発チーム・SREの3者がポリシーを承認できるかどうかを、SLOが妥当かどうかのテストとして使うよう勧めています。SREが「過大な手作業なしには守れない」と考えるならSLOを緩める根拠になり、プロダクトマネージャーが「ポリシーが動く前に多くの利用者が不快な体験をする」と考えるなら、SLOが緩すぎる兆候です。3者が合意できないときは、データ・人員・SLIやSLOの変更のどれが必要かを決めて作り直します。

SLO文書に書く項目とレビューの頻度

合意したSLOは、他チームが読める場所に文書として残します。Workbookが挙げる記載項目は次の6つです。

• 作成者・技術的な正しさを確認したレビュー担当・事業判断をした承認者
• 承認日と次回レビュー日
• 読み手に文脈を伝えるサービスの簡単な説明
• SLOの詳細（目標とSLIの実装）
• エラーバジェットの計算方法と消費のされ方
• 数値の根拠と、それが実験データか観測データか（場当たり的に決めた場合もその旨を書く）

数値の根拠を残しておけば、数年後の担当者も「なぜ99.9%なのか」を確認し、目標値を見直す際に参照できます。レビューの頻度について、Workbookは導入初期は毎月程度、SLOが定着したら四半期かそれ以下に減らしてよいとしています。

SLOを計測するツールの選び方

SLOの計測は、すでに使っている監視基盤に合わせて選ぶのが近道です。

Prometheusで運用する場合は、SlothやPyrraを使うとSLOの定義から記録ルールとアラートルールを生成でき、手書きを減らせます。OpenSLOはルールを生成するツールではなく、SLOを記述するための仕様です。導入判断はSLIの解説記事の後半で比べています。Datadogの機能全体はDatadogとは？何ができるか・仕組み・料金とCloudWatch/Zabbixとの違い、利用者側から可用性を測る外形監視はCloudWatch Syntheticsとは？Canaryの作り方・ランタイム選定・料金をAWS外形監視の実装目線で解説が参考になります。サーバー内部のメトリクスだけでSLIを取ると、ロードバランサーの手前で落ちたリクエストが数えられないため、外形監視との併用を勧めます。

SLO運用で失敗するパターン

• SLAと同じ値をSLOにする：同じ指標・期間・除外条件でSLAとSLOを設定すると、SLO未達時にはSLAの目標も未達になります。社内SLOを厳しくし、予算が尽きる前に通知する設計にします。
• 今の実績値をそのまま目標にする：実績99.98%をSLOにすると、少しの劣化でポリシーが発動し、変更が止まり続けます。
• 指標を増やしすぎる：可用性・レイテンシ・スループット・CPU使用率と並べると、どれを守るのかが曖昧になります。CPU使用率はユーザー体験ではないのでSLOにしません。
• ポリシーを書かずにSLOだけ決める：予算を使い切っても何も変わらず、SLOはダッシュボードの数字で終わります。
• 低トラフィックのサービスにそのままバーンレートアラートを入れる：1件の失敗でページが鳴り、アラート自体が無視されるようになります。

SLOの考え方の土台になっているSREそのものの原則や組織の作り方は、SREとは？サイト信頼性エンジニアリングの意味と原則、DevOpsとの違いをGoogleの原典で解説で整理しています。

よくある質問

SLOとSLAの違いは何ですか？

SLOはSLIに置く目標値で、SLAは目標を外したときの返金やペナルティを伴う顧客との契約です。SRE本は「SLOを外したら何が起きるか」に明示的な答えが無ければSLOだ、という見分け方を示しています。社内SLOはSLAより厳しく置きます。

SLOは何%に設定すべきですか？

一律の正解はありません。ユーザーが満足する水準を基準にし、現在の実績値をそのまま写さないことが原則です。100%は狙わず、緩い値から始めて締めていきます。ツールによって設定できる上限も違い、Google Cloud MonitoringはAPIリファレンスでは99.99%まで、概要ページでは99.9%までと記載が分かれています。

SLIとSLOの違いは何ですか？

SLIは測った値（成功したリクエストの割合など）で、SLOはそのSLIに置く目標値です。SLOを運用するにはSLIの定義と測る場所を明確にしますが、設計はユーザーが求める目標から始め、適切なSLIへ落とし込むこともできます。

SLOとKPIの違いは何ですか？

KPIは売上や解約率など事業の成果を測る指標で、SLOはユーザーが受け取るサービスの質に置く目標です。同じ数値を使う場合でも、SLOは測り方・目標・期間を固定し、未達時の開発の優先度をエラーバジェットポリシーで決める点が違います。

可用性99.9%だとどれくらい止まってよいのですか？

全停止の場合、30日で43分12秒、28日で40分19秒、1年で8時間45分36秒です。99.99%なら30日で4分19秒まで縮みます。リクエスト単位のSLOでは、一部だけが失敗する障害ならより長く耐えられます。

関連記事

• SLIとは？SLOとの違いと指標の選び方・PromQLでの測り方
• SLA（サービスレベル合意）とは？要件に書く項目とSLOとの違い、未達時のサービスクレジット
• SRE本 第2版の変更点：初版との違いと読む章、SLOアラートの実装例
• SREとは？サイト信頼性エンジニアリングの意味と原則、DevOpsとの違いをGoogleの原典で解説
• アラート疲れとは｜原因と対策を監視の実装視点で解説【2026年時点】