SLA・SLO・SLIの違いとは？サービス目標と測定、契約の考え方
SLAは顧客との合意、SLOは評価期間を定めたサービス目標、SLIはその状態を測る指標です。3つの関係、エラーバジェット、測定の落とし穴と、明確なSLAを書くための5つのポイントを解説します。
サービスの信頼性を話し合うときは、「何を測るか」「どの水準を目指すか」「顧客に何を約束するか」を分けると、SLA・SLO・SLIの関係が見えてきます。
- **SLA（サービスレベル合意）**は、提供者と顧客が交わす正式な合意です。たとえば「月間可用性99.99%以上」「営業日のサポート問い合わせに24時間以内に応答」といった約束を定めます。
- **SLO（サービスレベル目標）**は、サービスの指標に対して、目標値と評価期間を定めたものです。「月間可用性99.99%以上」がその一例です。社内の運用目標として設定でき、必ずしもSLAに記載する必要はありません。
- **SLI（サービスレベル指標）**は、サービスの状態を測る指標と測定方法です。たとえば「成功したリクエスト数 ÷ 評価対象のリクエスト総数」と定義します。ある期間で得られた99.90%という数字は、その指標の測定値です。同じ評価期間のSLOと比較して達成状況を判断します。SLA上の措置が発生するかどうかは、さらに契約の計算方法、対象範囲、除外条件によります。
数分間のエラー増加は調査すべき事象ですが、それだけで月間のSLO未達やSLA違反が確定するわけではありません。
SLA：サービスの約束と、守れなかった場合の取り決め
SLAは、提供者が約束するサービス水準を定めます。可用性は代表的な項目です。未達時には**サービスクレジット（Service Credit）**として、契約に従って以後のサービス料金を減額することがあります。減額の割合や申請条件は契約によって異なり、現金の返金や翌月の自動精算を意味するとは限りません。別途、補償やサービス期間の延長を定める場合もあります。
SLAでは、次の5点を明確にします。
- サービスの範囲：どのサービスや操作が対象になるか。
- 履行すべき水準：有効期間中に、どのSLOを満たす必要があるか。
- 測定方法：どのSLIを使い、どこで測定し、どの頻度・粒度で報告するか。
- 有効期間：いつから適用され、いつ見直しや再交渉を行うか。
- 未達時の措置：約束を守れなかった場合に、双方がどう対応するか。
SLAで起こりやすい2つの問題
一つは、「停止」の定義が曖昧なことです。ページが開かない場合は停止でも、読み込みが遅すぎて仕事にならない場合はどうでしょうか。定義を詰めておかないと、同じ障害を見ても提供者と顧客の判断が分かれます。
もう一つは、実際の利用者が議論から抜け落ちることです。SLAの作成には法務、営業、調達、技術などが関わります。それぞれの事情はあっても、最終的には顧客がサービスを使って何をできる必要があるのかを基準にしなければなりません。
SLO：評価期間を伴うサービスの目標
SLOは、サービスチームが運用を評価するための目標です。その一部をSLAに記載して対外的に約束することもできますが、SLAのないサービスにもSLOを設定できます。
リクエスト成功率のSLIで99.9%を目標とするなら、同じ評価期間中、対象リクエストの0.1%が失敗しても目標の範囲内です。この許容分をエラーバジェットと呼びます。ただし、リクエスト数を分母とする割合を、そのまま「許容できる停止時間」に換算することはできません。停止時間を求めるには、時間を基準とした可用性の定義と、それに合った評価期間が必要です。
パーセントより先に、計算の条件を決める
「月間可用性99.95%以上」と書くのは簡単です。難しいのは、何を可用とみなすかです。
仮に、ある契約が「HTTP 500を返すリクエストが10%を超える状態が10分以上続いた場合だけ、その期間を停止として数える」と定めていたとします。この定義なら、HTTP 502のエラー、エラー率8%の状態、9分間の中断は停止に含まれません。どれも利用者には支障が出ている可能性があります。
これは定義の影響を示す仮定の例であり、特定の提供者の現行SLAを引用したものではありません。目標値だけでなく、対象、しきい値、時間の数え方を、読み手が同じ意味で理解できる言葉にする必要があります。
SLI：結果を比べる前に、測り方を決める
SLIを使うには、成功の条件、分母に含めるリクエスト、データの収集地点、欠損データの扱いを定義します。そのうえで測定値を評価します。
短い時間帯で目標を下回っても、月間SLOが未達になったとは限りません。また、社内SLOの未達が、そのままSLA違反を意味するわけでもありません。それぞれに定めた評価期間と契約条件で判断します。
測定手段にも違いがあります。サーバー側のカウンター、クライアント側の観測、外部からの合成監視では、見える範囲が異なります。サンプリング、監視地点、テレメトリの欠損も結果に影響します。細かい桁まで表示された数字でも、測定範囲の限界がなくなるわけではありません。
すべてのサービスにSLAは必要か
SLAは、SLIやSLOを使うための必須条件ではありません。SLAを提供するかどうかには、取引上の判断も関わります。
提供者の立場では、顧客の調達要件が判断材料になります。大企業では正式なSLAが購買条件になることがありますが、少額のセルフサービス型の契約では、求められる手続きが異なる場合もあります。これは調達の傾向であって、小規模な顧客なら信頼性が不要という意味ではありません。
購入する側の立場では、未達時の補償だけに注目しないことが大切です。SLAを精査するには法務、財務、運用などの時間がかかり、調達手続きも増えます。条件のよいサービスクレジットがあっても、障害そのものを防げるわけではありません。
契約と併せて、ステータスページなどで過去の稼働状況も確認しましょう。ただし、公開された全体の稼働状況だけでは、自社の利用範囲でどう影響が出たかまでは分かりません。高額な契約、長期契約、新しい取引先では特に、約束の範囲と未達時の対応を明確にする意味があります。
明確なSLAを書くための5つのポイント
- 顧客が完了したい操作から考える。 開発チームには、サーバー応答や認証コード送信など複数の構成要素が見えます。顧客が知りたいのは、必要な操作を完了できるかどうかです。その結果を表す指標を選び、どの構成要素の障害を含むのかを明らかにします。
- 読みやすい言葉を使う。 何を、いつ、どう測るのか。未達になったらどうするのか。これらを具体的に書きます。厳密であることと、読みにくいことは同じではありません。
- 測れる指標をすべて盛り込まない。 監視システムが取得できる指標は、顧客との約束に必要な指標よりも多くあります。顧客の体験に関わるものを選び、重要な約束が埋もれないようにします。
- 対外的な目標には余裕を持たせる。 たとえば、同じ測定方法と評価期間で、社内目標を99.95%、対外的な約束を99.9%とすれば、両者の間に余裕を設けられます。数値は例です。実際の能力と顧客の要件を踏まえて、継続して支えられる目標を設定します。
- 除外条件を明記する。 サポート対応で顧客からの情報を待つ場合、その時間を応答時間や解決時間に含めるのか、いつ計時を止めるのかを決めます。障害が起きてから数え方を交渉する状態を避けましょう。
SLAの合意と運用を、測定データで支える
サービスの約束を評価するには、根拠となる測定を説明できることが重要です。Guanceの合成監視では、設定した監視地点と実行間隔で可用性を観測できます。モニターとイベントの時系列は、障害の発生や対応の経過を調べる手がかりになります。
これらは社内のSLO評価を支えるデータですが、自動的に契約上有効なSLA履行の証拠になるわけではありません。測定の対象、方法、保存期間を先に合意しておきます。設定方法はGuanceのSLO管理、外部からの計測については合成監視のドキュメントを参照してください。
よくある質問
SLOとSLAは、どちらを先に決めるべきですか？
SLIとSLOを定義し、実際に測定・評価できることを確かめてから、対外的な約束にする目標を選ぶと、過大な約束のリスクを減らせます。ただし、必ずこの順序でなければならないわけではありません。SLAがなくてもSLOは設定できます。
社内SLOと対外的なSLAの目標値は、同じでなければなりませんか？
同じでも、異なっていても構いません。たとえば、対外目標99.9%に対して社内目標を99.95%とし、余裕を確保する方法があります。ただし、パーセントを直接比較できるのは、測定方法と評価期間が同じ場合です。
どのツールで測れば、有効なSLIになりますか？
ツールの名称ではなく、測定方法が目的に合っているかが重要です。サーバー側の計数、クライアント側の観測、外部からの合成監視には、それぞれ適した用途と観測範囲があります。SLAで使う場合は、双方が認める方法を「測定方法」の項目に記載します。
SLAに記載していない補償を顧客から求められたら、どうすればよいですか？
主契約、その他の適用条項、SLAの対象範囲を確認したうえで、営業・法務と検討します。SLAに書かれていないという理由だけで、契約全体にも義務がないとは判断できません。
参考資料
技術的な定義と製品ドキュメントの確認日：2026年10月27日。本文の数値は説明用の例であり、実測結果や特定の提供者によるサービス保証ではありません。
