SLO（エスエルオー）
英語表記: Service Level Objective
概要
SLO（Service Level Objective：サービスレベル目標）とは、提供するITサービスやシステムの品質を、具体的な数値で測定できるように設定した内部的な目標値のことです。これは、システムがユーザーに期待されるパフォーマンスをどの程度満たすべきかを定義する、信頼性工学（SRE）の核となる要素です。
SLOは、顧客との契約であるSLA（Service Level Agreement：サービスレベル合意）よりも厳しく、あるいは柔軟に設定されることが多く、システムがハードウェアとソフトウェアの関係を通じて提供するサービスの「理想的な状態」を定量化する役割を果たします。
詳細解説
SLOは、ITサービスの信頼性を高め、開発・運用チームが共通の目標に向かって協力するための羅針盤となります。この概念は、信頼性工学という文脈で最も力を発揮します。
SLOの目的と位置づけ
私たちが提供するサービスは、サーバーやネットワークといったハードウェアと、その上で動作するアプリケーションというソフトウェアが複雑に連携して成り立っています。SLOの目的は、この複雑な連携によって生じる結果（例：ウェブページの読み込み速度、サービスの稼働時間）を曖昧にせず、具体的な数値（パーセンテージやミリ秒）で定義することです。
SLOを設定するプロセスは、まずSLI（Service Level Indicator：サービスレベル指標）を定めることから始まります。SLIは「何を測るか」であり、SLOは「その測定値がどの程度であれば合格か」という目標値そのものです。
例えば、SLIとして「リクエストの成功率」を選んだ場合、SLOは「リクエストの成功率は99.95%以上を維持する」といった具体的な数値になります。
可観測性との関係
SLOを有効に機能させるためには、システムの状態を常時把握できる「可観測性」が不可欠です。システム全体が透明でなければ、目標値（SLO）を達成しているかどうかを正確に判断できません。
このため、可観測性とライフサイクル管理という中カテゴリにおいて、SLOは非常に重要な役割を果たします。高性能なモニタリングツールを用いてSLIを継続的に収集し、そのデータがSLOを満たしているかをリアルタイムでチェックします。もしSLOを下回る傾向が見られた場合、それはシステムの改善（ライフサイクル管理）が必要であるという明確なサインとなるのです。
エラーバジェット（許容失敗回数）
SLOの運用において特徴的なのが、「エラーバジェット（Error Budget）」という考え方です。SLOは通常、100%の達成を求めません。なぜなら、100%の信頼性を追求すると、開発スピードが極端に落ち、コストが跳ね上がってしまうからです。
例えば、SLOを99.9%に設定した場合、残りの0.1%が「失敗しても許される範囲」となり、これがエラーバジェットとなります。このバジェットを使い切るまでは、チームは新しい機能のリリースやリスクのある変更を試みることができます。
もしエラーバジェットが尽きそうになったら、その期間は信頼性向上を最優先し、新しい機能開発を一時停止します。これにより、開発チームと運用チームは、サービスの信頼性を維持しつつ、イノベーションも追求するという絶妙なバランスを取ることができるのです。これは、信頼性工学ならではの、非常に実践的で面白いアプローチだと感じます。
具体例・活用シーン
SLOは、ユーザー体験に直結するあらゆるサービス品質に適用されます。
ウェブサービスにおける典型的なSLO
- レイテンシ（応答時間）: 「ユーザーリクエストの95%は、300ミリ秒以内に処理を完了すること。」
- これは、ハードウェアとソフトウェアの関係が生み出す最終的な性能、つまり「どれだけ速く動くか」を定義します。
- 可用性（稼働率）: 「サービスは、1ヶ月のうち99.99%の時間、アクセス可能であること。」
- この目標を達成するためには、可観測性を通じて継続的に稼働状況を監視し、計画外の停止を防ぐ必要があります。
具体的な比喩：バスの運行目標
SLOを理解するための身近な比喩として、「バスの運行目標」を考えてみましょう。
あるバス会社が、顧客満足度を高めるために「バスの到着時間が予定時刻から5分以上遅れないこと」を目標に設定したとします。これがSLOです。
- SLI（指標）: 実際の到着時間と予定時刻の差（遅延時間）。
- SLO（目標）: 遅延時間が5分以内である運行の割合を98%とする。
- エラーバジェット: 2%の運行は5分以上遅れても許容される失敗の枠です。
もし、運行データ（可観測性データ）を分析し、遅延が頻発してエラーバジェットを使い果たしそうになった場合、バス会社（運用チーム）は新しい路線や運転手の休憩時間の見直し（ライフサイクル管理）を優先的に行います。
この目標があることで、運転手や管理者は「ただバスを走らせる」のではなく、「98%の運行で5分以内の遅延に抑える」という明確な信頼性工学に基づいたミッションを持つことができるのです。SLOは、単なる数値目標ではなく、チームの行動指針となる点が非常に重要です。
資格試験向けチェックポイント
SLOは、特に応用情報技術者試験や、SRE（サイト信頼性エンジニアリング）の概念が問われる高度な試験で頻出します。ITパスポートや基本情報技術者試験でも、SLAやサービスマネジメントの文脈で関連知識が問われる可能性があります。
| 項目 | 試験対策のポイント |
| :— | :— |
| SLOとSLAの区別 | SLOは「内部目標」であり、SLAは「顧客との外部契約」です。SLOはSLAよりも厳しく設定されることが一般的です。信頼性工学では、まずSLOを定めることがスタート地点です。 |
| SLI, SLO, エラーバジェットの関係 | SLI（何を測るか）→ SLO（目標値）→ エラーバジェット（許容失敗範囲）という三位一体の関係を理解しておく必要があります。 |
| 可観測性との関連 | SLOの測定と達成には、ロギング、メトリクス、トレースといった可観測性の要素が不可欠であるという点を結びつけて覚えておきましょう。 |
| 文脈の理解 | SLOは、ハードウェアとソフトウェアの関係によって生じるサービスの品質を、継続的な改善（ライフサイクル管理）を通じて高めるためのツールとして機能します。この文脈を問う問題が出題されやすいです。 |
| 計算問題 | エラーバジェットが与えられた期間（例：30日間）で許容されるダウンタイム（停止時間）を計算させる問題が出題されることがあります。例えば、99.9%の可用性SLOの場合、30日間の許容ダウンタイムは約43分です。 |
関連用語
SLOを理解するためには、その周辺の概念も同時に把握しておく必要がありますが、ここでは特に重要な用語を挙げます。
- SLI (Service Level Indicator)
- サービスレベルを測定するための具体的な指標（例：リクエストのレイテンシ、成功率）。SLOの「元データ」となります。
- SLA (Service Level Agreement)
- サービス提供者と顧客の間で交わされる、サービスレベルに関する公式な合意。一般的に、SLOはSLAの達成を確実にするために、SLAよりも少し厳しめに設定されます。
- エラーバジェット (Error Budget)
- SLOで定められた目標値から逆算される、許容される失敗の総量。開発のスピードと信頼性のバランスを取るための「予算」です。
- SRE (Site Reliability Engineering)
- Googleが提唱した、ソフトウェアエンジニアリングの手法を運用業務に適用し、システムの信頼性向上を目指すアプローチ。SLO、SLI、エラーバジェットはSREの中心的な実践です。
- 可観測性 (Observability)
- システムの内部状態を外部から推測し、理解する能力。SLOの達成状況をリアルタイムで確認し、問題発生時に原因を特定するために必須です。
関連用語の情報不足：この分野は比較的新しいため、ITパスポートなどの初級試験ではSLAとSLOの区別に関する出題が中心となる傾向があります。応用情報技術者試験レベルではSRE全体が問われ始めていますが、日本語の公式教材や過去問における用語定義はまだ発展途上にあります。特に、SLOの具体的な設定基準や業界標準に関する詳細な情報（例：具体的なレイテンシの目標値など）については、公表されている情報が限定的であるため、学習者はSREの書籍やウェブ上の最新情報を参照する必要があります。
