SLOとは？SLA・SLIとの違いと設定方法をわかりやすく解説

SLO（Service Level Objective：サービスレベル目標）とは、システムやサービスの品質を「どの水準まで満たすか」を数値で定めた目標です。たとえば「月間の稼働率を99.9%以上に保つ」「リクエストの95%を1秒以内に応答する」のように、計測可能な形で設定します。読み方は「エスエルオー」。SRE（Site Reliability Engineering）やDevOpsの現場で、信頼性を客観的に管理するための中核的な指標として使われています。

この記事では、混同されやすいSLA・SLO・SLIの違いを比較表で整理したうえで、可用性の具体例（99.9%だと月にどれくらい止まるのか）、エラーバジェットの考え方、SLOを設定・運用する手順までを実務目線でまとめます。

まとめ

SLOは、サービス品質を数値で管理し、信頼性をチーム全体の共通言語にするための目標です。SLA（契約）・SLO（社内目標）・SLI（実測）の関係を押さえ、可用性などの指標を実測データに基づいて設定し、エラーバジェットで開発と運用のバランスを取りながらPDCAを回す——これが効果的なSLO運用の基本です。まずは最重要のSLIを1つ選び、現実的な目標値から小さく始めるのが失敗しないコツです。以降では、この全体像を一つずつ掘り下げ、SLA・SLO・SLIの違いから具体的な設定手順までを順に解説していきます。

SLOとは何か（サービスレベル目標の意味）

SLOは、サービス提供者が社内で設定する品質目標です。顧客との契約のように法的拘束力を持つものではなく、「自分たちのサービスはこの水準を維持する」という運用上の約束として機能します。重要なのは、理想を掲げるのではなく、実測データに基づいて「達成可能かつ意味のある」値を選ぶことです。

SLOを定めると、運用チームは何を優先すべきかが明確になり、障害時にも「どこまで許容されるか」という判断基準を持てます。さらに、達成状況を継続的に計測することで、感覚ではなくデータに基づいた改善サイクルを回せるようになります。SLOは単なる数値ではなく、サービスの信頼性を組織全体で共有するための「共通言語」だと言えます。

SLOという概念が広く使われるようになった背景には、クラウドやマイクロサービスの普及でシステムが複雑化し、信頼性を定量的に管理する必要性が高まったことがあります。SLOは、Googleが提唱したSRE（Site Reliability Engineering）の中心概念であり、DevOpsで開発と運用が協調するための土台でもあります。「どこまで安定していれば十分か」を数値で合意することで、過剰な完璧主義に陥らず、限られたリソースを適切に配分できるようになります。

SLA・SLO・SLIの違い【比較表】

SLOを理解するうえで欠かせないのが、SLA・SLOと並んで使われるSLIとの関係です。三者は次の順序で積み上がります。

• SLI（Service Level Indicator：サービスレベル指標）＝実際に計測した値。例：稼働率、応答時間、エラー率。
• SLO（Service Level Objective：サービスレベル目標）＝SLIが満たすべき目標値。例：稼働率99.9%以上。
• SLA（Service Level Agreement：サービスレベル合意）＝顧客と交わす契約。未達時にはペナルティ（返金・サービスクレジット等）が発生し得る。

つまり「実測（SLI）→社内目標（SLO）→対外契約（SLA）」という関係で、SLIなしにSLOは測れず、安定して達成できるSLOがあって初めて現実的なSLAを結べます。実務では、SLAより少し厳しめのSLOを社内に置き、契約違反を未然に防ぐのが定石です。

SLOでよく使う指標と可用性の具体例

SLOに用いる代表的な指標は次の4つです。サービスの性質に合わせて、ユーザー体験に直結するものを選びます。

• 可用性（稼働率）：サービスが正常に使えた時間の割合。SaaSやインフラで最重要。
• レイテンシ（応答時間）：操作から応答までの速さ。「95%が1秒以内」のように分位点で定める。
• エラー率：全リクエストのうち失敗（HTTP 500など）した割合。
• スループット：単位時間あたりに処理できるリクエスト数やデータ量。

SLIは多くの場合、「良いイベント ÷ 有効な全イベント × 100」という割合で表します。たとえば可用性なら「成功した応答数 ÷ 全リクエスト数」、エラー率なら「失敗した応答数 ÷ 全リクエスト数」です。この形にしておくと、サービスの規模が変わっても同じ基準で比較でき、SLOの達成判定が一貫します。

レイテンシのSLOで注意したいのは、平均値ではなく分位点（パーセンタイル）で測ることです。平均が速くても、一部のユーザーだけが極端に遅い「ロングテール」を見逃すためです。実務では「95%のリクエストが300ミリ秒以内（p95）」「99%が1秒以内（p99）」のように、上位の遅いリクエストまで含めて目標化します。

可用性は「ナイン（9の数）」で語られることが多く、数字が1桁増えるだけで許容ダウンタイムは大きく変わります。下表は、月間（30日＝43,200分）・年間（365日＝525,600分）あたりの許容停止時間の目安です。

「99.99%」と「99.999%」は一見わずかな差ですが、月間の許容停止は約4分と約26秒で、必要な冗長構成や運用コストはまったく異なります。高すぎる目標は過剰投資を招くため、ビジネス上の必要性とコストのバランスで決めることが重要です。

SLOの設定例（APIサービスのケース）

抽象論だけではイメージしにくいので、一般的なWeb APIサービスを想定したSLOのセット例を示します。1つの指標に偏らず、可用性・レイテンシ・エラー率を組み合わせて多面的に品質を捉えるのが実務的なやり方です。

はじめから多くの指標を追うと運用が破綻しがちです。まずはユーザー影響が最も大きい1〜2個（多くの場合は可用性とレイテンシ）に絞り、運用に慣れてから対象を広げるのが現実的です。

エラーバジェットとは（SLOを運用に活かす考え方）

エラーバジェット（誤差予算）とは、「1 − SLO」で表される、許容される失敗の量です。たとえばSLOが99.9%なら、残り0.1%がエラーバジェットになります。100%の完璧を求めるのではなく、「ここまでは失敗してよい」という余地を明示するのがポイントです。

この考え方の利点は、開発スピードと安定性のバランスを数値で判断できることにあります。エラーバジェットに余裕があれば、新機能を積極的にリリースしてよい。逆に使い切ってしまったら、機能追加を止めて安定化にリソースを振り向ける、といった意思決定が可能になります。SLOとエラーバジェットは、開発チームと運用チームが対立せずに同じ基準で動くための仕組みでもあります。

具体的に計算してみましょう。月間のSLOを可用性99.9%とした場合、エラーバジェットは0.1%＝月間で約43分です。月の途中で障害により30分停止したなら、残りの予算は約13分。この時点で「今月はこれ以上のリスクは取れない」と判断し、リリースを慎重にする、といった運用に落とし込めます。予算を使い切る前にアラートを出す設計にしておくと、障害を未然に抑えやすくなります。

SLOの設定・運用手順（5ステップ）

SLOは一度決めて終わりではなく、計測と見直しを前提に運用します。基本の流れは次の5ステップです。

• ① SLIを選ぶ：ユーザー体験に効く指標（可用性・レイテンシ等）を、シンプルで計測しやすいものに絞る。
• ② 目標値を決める：過去の実測データをベースラインに、現実的かつ挑戦的な水準を設定する。
• ③ 計測・可視化する：監視ツールでSLIを継続取得し、ダッシュボードで関係者と共有する。
• ④ レビューする：月次・四半期でSLO達成状況とエラーバジェットを確認する。
• ⑤ 改善する：未達なら原因分析と対策、過剰なら目標の見直しを行い、PDCAを回す。

③の計測では、SLIの自動収集とアラート設計が要になります。たとえばユーザー視点で可用性や応答を測る外形監視（CloudWatch Synthetics）や、メトリクス・ログを一元的に可視化するDatadogなどが代表的です。監視設定そのものをTerraformでコード管理すれば、環境間で一貫したSLO監視を再現できます。PrometheusやGoogle Cloud Monitoringのように、SLOとエラーバジェットを定義してダッシュボードで追跡できる仕組みを備えたツールもあり、目的や既存環境に合わせて選ぶとよいでしょう。

具体的な設定イメージも押さえておきましょう。たとえばGoogle Cloud MonitoringやDatadogには「SLO」を扱う専用機能があり、SLI（成功応答の割合など）を選び、目標値（例：99.9%）とコンプライアンス期間（例：直近30日のローリング）を指定するだけで、エラーバジェットを「(1−SLO目標)×期間内の対象イベント数」として自動計算し、残量をグラフで可視化してくれます。残量がマイナスになれば、その期間はSLO未達という直感的な見方ができます。Prometheus単体で運用する場合は、SLIの比率を集計するレコーディングルールと、後述のバーンレートを判定するアラートルールを書いて同等の仕組みを構成します。

アラート設計の要になるのがバーンレート（burn rate）という考え方です。これはエラーバジェットを消費する速さを目標期間の長さで正規化した値で、バーンレートが1なら「その速度が続くと期間のちょうど終わりに予算を使い切る」ことを意味します。たとえば30日のSLOで1時間あたりに予算の何%を消費したかを監視し、バーンレートが高い（＝短時間で予算を大きく削っている）ときだけ即時アラートを出す設計にすると、軽微な揺らぎでの誤報を避けつつ、重大な障害を予算枯渇の前に検知できます。SLO未達になってから気づくのではなく、「このままだと危ない」段階で手を打てるのがバーンレート監視の利点です。

SLO運用でよくある失敗と回避策

SLOが形骸化する典型パターンと対策を押さえておきましょう。

• 非現実的な目標：「可用性100%」は事実上不可能で、現場の不信を招く。実績ベースで段階的に引き上げる。
• 計測データの不備：監視漏れがあると「稼働率100%」と誤評価される。データ収集の冗長性を確保する。
• 部門間の認識差：開発はスピード、運用は安定を重視しがち。共通のダッシュボードで同じ数字を見る。
• 変更頻度が高すぎる：目標がころころ変わると運用が混乱する。見直しは四半期など計画的に行う。

大規模なクラウド障害は、こうした想定の前提を揺るがします。実例として2025年10月のAWS大規模障害では、リージョン規模の影響範囲が改めて注目されました。SLOを設計する際は、AZ単位だけでなくリージョン障害まで含めたシナリオを意識することが大切です。

よくある質問（FAQ）

Q. SLOとSLAの違いは？
A. SLOは社内で定める品質目標で法的拘束力はありません。SLAは顧客との契約で、未達時にはペナルティが発生し得ます。一般にSLAより厳しめのSLOを社内に置きます。

Q. SLOは何％に設定すべき？
A. 一律の正解はありません。過去の実測値を基準に、ユーザー満足とコストのバランスで決めます。多くのSaaSでは可用性99.9%前後が出発点として使われます。

Q. SLIとSLOはどう違う？
A. SLIは「実際に計測した値」、SLOは「その値が満たすべき目標」です。SLI（実測）があって初めてSLO（目標）の達成可否を判断できます。

Q. エラーバジェットとは？
A.「1 − SLO」で表される許容失敗量です。SLO99.9%なら0.1%が予算となり、新機能リリースと安定化の判断材料になります。

Q. 可用性99.9%だとどれくらい止まる？
A. 月間で約43分、年間で約8.76時間の停止が許容範囲です。99.99%なら月間約4.32分まで縮みます。

関連記事

• Datadogとは何か？機能やメリット、導入の背景を詳しく解説
• CloudWatch Syntheticsのサービス概要と外形監視の特徴
• TerraformでDatadogを管理するメリット：コードによる監視効率化
• 2025年10月20日に発生したAWS大規模障害の概要と影響範囲