結論：SLA・SLO・SLIは、システムの「信頼性」を管理するための3点セットです。これらは階層構造になっており、測定値（SLI）→ 内部目標（SLO）→ 対外契約（SLA）という順に積み上がっています。
【結論】SLA・SLO・SLIの役割比較まとめ
ITインフラやWebサービスの現場において、これら3つの用語はセットで登場しますが、その役割と「誰に対する約束か」は明確に異なります。
混同を防ぐため、まずは以下の比較表で全体像を頭に入れてしまいましょう。最も重要な違いは「罰則（ペナルティ）があるかどうか」です。
| 用語 | フルスペル | 日本語訳 | 約束する相手 | 罰則 | 役割・本質 |
|---|---|---|---|---|---|
| SLI | Service Level Indicator | サービスレベル指標 | 監視システム (事実データ) | なし | 「測定」 現状の健康状態を示す数値。 |
| SLO | Service Level Objective | サービスレベル目標 | 開発・運用チーム (社内) | なし | 「目標」 SLAを割らないための安全圏ライン。 未達なら改善活動を優先する。 |
| SLA | Service Level Agreement | サービスレベル合意 | 顧客・ユーザー (社外) | あり | 「契約」 品質の最低保証。 割ると返金や補償が発生する。 |
実務における関係性は SLA < SLO < 100%（理想） となります。
顧客と約束する「SLA」よりも、自分たちに課す「SLO」を厳しく設定することで、万が一のトラブル時にも契約違反（SLA違反）になる前に社内で検知・対応できるようにするわけです。
Mikotoなるほど、全部似たような言葉だと思ってましたけど、「罰則があるかどうか」が決定的違いなんですね。
Yachiそうです。特にSLAはお金（返金）が絡むので、法務部門も関わってくる「契約書」レベルの話になります。一方でSLOとSLIは、現場のエンジニアが日々向き合う「運用ルール」や「メーター」に近いですね。
鉄道運行に例える3者の関係性
この3つの概念は、鉄道会社の運行管理システムに置き換えると非常に直感的に理解できます。Webサービスを「電車」、私たちエンジニアを「鉄道会社」と考えてみてください。
1. SLI（事実）：今の運行状況は？
「今朝の8時発の電車は、実際には8時3分に到着した（3分遅れ）」
「昨日は全ての電車が定刻通りだった」
これらは単なる事実（実績データ）です。良いも悪いもなく、計測された数値そのものを指します。これが SLI です。
2. SLO（社内目標）：運行管理室のプライド
「全列車の98%を定刻通り（遅延1分以内）に運行しよう」
これは鉄道会社が内部で掲げる努力目標です。この目標を守るために、日々の車両整備やダイヤ調整を行います。もしこの目標を下回ったら、「最近遅れが多いから、車両点検を強化しよう」と社内で対策を打ちます。これが SLO です。
3. SLA（乗客との約款）：最低保証ライン
「事故などで2時間以上遅延した場合は、特急料金を払い戻します」
これは乗客（ユーザー）に対する公約であり、法的な拘束力を持ちます。目標（SLO）は「定刻」を目指しますが、契約（SLA）のラインは「2時間遅れ」というかなり低い位置に引かれています。
なぜなら、SLAを破ると「払い戻し（金銭的損失）」が発生するからです。絶対に破ってはいけない防衛ライン、それが SLA です。
このように、「高い目標（SLO）」を持ちつつ、「最低限の保証（SLA）」を顧客と握る。このバッファ（余裕）を確保することが、健全なサービス運営の肝となります。
Mikoto確かに電車だとイメージ湧きます！「2時間遅れで払い戻し」がSLAなら、普段目指してる「定刻運行」がSLOってことですね。
Yachiその通りです。もし「1分でも遅れたら全員に全額返金（SLA）」なんて契約を結んでしまったら、鉄道会社はすぐに破産してしまいますよね。だから、SLAは「これ以上は勘弁して」というギリギリのラインに設定するのが鉄則なんです。
SLA (Agreement)：対外的な「契約」とペナルティ
ここからは、実務で重要となる各用語の詳細を掘り下げます。
SLA（Service Level Agreement）は、サービス提供者と利用者の間で結ばれる「ここまで品質を保証しますよ」という合意書です。
「ペナルティ」のリアル：サービスクレジット
SLA最大の特徴は、違反時にペナルティが発生することです。ただし、「現金で返金される」ことは稀です。
AWS、Google Cloud、Azureなどの主要なクラウドサービスでは、SLA違反時の補償として「サービスクレジット」が提供されます。
- サービスクレジットとは: 将来の利用料から割り引く権利（クーポン券のようなもの）。
- 仕組み: 例えば「稼働率が99.0%を下回ったら、月額利用料の10%相当をクレジットとして返還する」といった規定になります。
落とし穴：多くの場合は「申請主義」
ここが初心者が見落としがちなポイントですが、SLA違反が発生しても自動的に補償されるわけではありません。
Yachiここは本当に注意が必要です。僕の経験上、「黙っていても返金される」と思っている現場が多すぎます。実際は、ユーザー側から「この時間に障害がありましたよね？」と証拠を突きつけて申請しないと、1円も戻ってこないケースがほとんどです。
多くのサービスでは、ユーザー自身が「〇月〇日の〇時から〇時まで障害がおきていた。SLA違反なので補償してほしい」とログを添えて申請（Claim）する必要があります。しかも、「発生から30日以内」といった期限付きであることがほとんどです。
SLAは「結んで終わり」ではなく、障害時には権利を行使するアクションが必要になることを覚えておきましょう。
Mikotoええっ、自動じゃないんですか？ 知らないと損しちゃいますね…。
Yachiそうなんです。だからこそ、システム障害が起きたときは、復旧作業と並行して「SLA違反に該当するか」「申請期限はいつまでか」を確認するフローを組んでおく必要があります。
稼働率とダウンタイムの目安
SLAでよく見る「99.9%（スリーナイン）」という数字。これが具体的にどれくらいの停止時間を許容するものなのか、計算表を作成しました。
| 稼働率 (SLA/SLO) | 月間許容停止時間 (30日換算) | 難易度・用途の目安 |
|---|---|---|
| 99.0% (2 nines) | 約 7時間12分 | 一般的なWebサイト、個人ブログなど |
| 99.9% (3 nines) | 約 43分12秒 | 企業の業務システム、標準的な商用SaaS |
| 99.99% (4 nines) | 約 4分19秒 | 金融システム、決済インフラ、基幹DB |
| 99.999% (5 nines) | 約 26秒 | 人命に関わる医療システム、通信キャリアのコア設備 |
Webエンジニアの実務としては、99.9%（月間43分停止までOK）か99.99%（月間4分停止までOK）のあたりが、SLA設計の主戦場となります。
Yachiちなみに、安易に「99.99%（フォーナイン）」を約束するのは危険です。月間で4分しか止まれないということは、深夜メンテナンスすら許されないレベルです。コストも跳ね上がるので、個人的には通常のWebサービスなら「99.9%」または「99.5%」あたりから始めるのを推奨します。
SLO (Objective)：チームを守る「内部目標」
SLO（Service Level Objective）は、SLA違反という「事故」を起こさないために設定する、チーム内部の警報ラインです。SLAよりも厳しい値を設定します。
エラーバジェット：失敗しても良い予算
SLOを理解する上で欠かせない概念が「エラーバジェット（Error Budget）」です。
これは、「100% – SLO」で算出される「失敗できる余裕」のことです。
- 例: SLOを99.9%に設定した場合
- 100% – 99.9% = 0.1% がエラーバジェット。
- 時間換算で月間約43分までは、システムが止まったりエラーを出したりしても「許容範囲」とみなします。
Mikoto「失敗できる予算」って面白い考え方ですね。普通は「エラーゼロ」を目指すものじゃないんですか？
Yachiそこが従来の運用とSRE（Site Reliability Engineering）の最大の違いです。「エラーゼロ」を目指すと、怖くて何も変更できなくなりますよね。でもWebサービスは新機能をどんどん出したい。だから「この範囲内なら失敗してもいいよ」という枠を決めるんです。
バジェットは「イノベーションの燃料」
なぜエラーを許容するのでしょうか？ それは開発速度を落とさないためです。
- 予算がある（残っている）状態:
- 多少のリスクをとっても、新機能をガンガンリリースする。
- 実験的な変更を行う。
- 予算を使い切った状態:
- 新機能の開発・リリースを凍結する。
- チーム全員でシステムの安定性向上（バグ修正、インフラ改善）に取り組む。
このように、SLOとエラーバジェットは、開発チーム（Dev）と運用チーム（Ops）が「今は攻める時か？守る時か？」を客観的に判断するための共通言語として機能します。
Yachi個人的には、この「予算切れ＝リリース凍結」というルールを徹底できるかが、SLO運用の成否を分けると感じています。多くの現場では、予算が尽きても「ビジネス都合で」無理やりリリースを続け、結果的に大障害を引き起こします。SLOは飾りではなく、ブレーキを踏むための判断基準なんです。
なぜ100%を目指さないのか
「信頼性は高ければ高いほど良いのでは？」と思うかもしれません。しかし、信頼性を100%に近づけるには、指数関数的なコスト（サーバー代、人件費）がかかります。また、100%を維持しようとすると「変更＝リスク」となるため、コードの修正が一切できなくなります。
ユーザーが気づかないレベルの微細なエラーは許容し、その分を機能開発のスピードに転換する。これが現代的なWeb開発（SRE）の考え方です。
SLI (Indicator)：計測すべき「事実」
SLI（Service Level Indicator）は、SLOやSLAの判定基準となる具体的な指標です。
「サーバーのCPU使用率」のようなインフラ視点の数値よりも、「ユーザーが快適に使えているか」というユーザー体験（UX）視点の指標を選ぶのが鉄則です。
Googleが提唱する「Four Golden Signals」
何を測るべきか迷ったら、以下の4つの指標（ゴールデンシグナル）から検討するのが定石です。
- Latency（レイテンシ）:
- 処理にかかる時間。「平均値」ではなく、遅い方を含めた「95パーセンタイル（P95）」や「99パーセンタイル（P99）」を見ます。
- Traffic（トラフィック）:
- システムへの要求量。Webなら「秒間リクエスト数（RPS）」などが該当します。
- Errors（エラー）:
- リクエストの失敗率。「HTTP 500」などのステータスコードの発生割合を見ます。
- Saturation（サチュレーション）:
- システムの飽和度。「これ以上負荷が増えると危ない」という限界までの余裕。メモリ使用量やキューの詰まり具合など。
Yachiいきなり4つ全てを完璧に計測するのは難しいかもしれません。僕のおすすめは、まずは「Latency（遅くないか）」と「Errors（壊れてないか）」の2つから始めることです。ユーザーにとって最もストレスなのは「待たされること」と「画面が出ないこと」ですからね。
「定義が決まって初めて計測ができる」という点を忘れないでください。なんとなくログを眺めるのではなく、「成功とは何か（例：200 OKが0.5秒以内に返ること）」を定義することからSLIは始まります。
間違いやすい用語との境界線 (KPI / RFP)
SLA/SLOと似た文脈で使われるものの、役割が全く異なる用語についても整理しておきましょう。
vs KPI (Key Performance Indicator)
- KPI: 売上、会員登録数、解約率（Churn Rate）などのビジネス成果を測る指標。
- SLA/SLO: 稼働率、応答速度などのシステム品質を測る指標。
関係性としては、システム品質（SLO達成）は、ビジネス成果（KPI達成）のための土台です。サイトがダウンしていては（SLA違反）、商品は売れません（KPI未達）。しかし、目的の次元が異なります。
vs RFP (Request For Proposal)
- RFP: システム導入前に、発注側がベンダーに渡す「提案依頼書」。
- SLA: システム導入後（契約時）に結び、運用中に監視し続ける合意。
MikotoRFPとSLAって、出るタイミングが違うんですね。
Yachiそうです。RFPの中に「SLAとして稼働率99.9%を希望します」と書くことはよくあります。RFPは「要望」、SLAは「合意（契約）」という時系列になります。
実務における設定・運用ステップ
実際に現場でSLA/SLOを導入する場合、いきなり全ての機能に数値を設定しようとすると失敗します。以下のステップで小さく始めるのが成功のコツです。
- 重要な機能の特定（CUJ: Critical User Journey）
- サイト内の全ページを監視するのではなく、ユーザーにとって「これが使えないと終わる」機能に絞ります。
- 例：ECサイトなら「商品検索」「カート追加」「決済完了」。
- SLIの選定
- その機能が「健康」である状態を定義します。
- 例：「決済ボタンを押してから、3秒以内に完了画面が表示されること」。
- SLOの設定
- 過去の実績値（ベースライン）やビジネス上の要求から目標値を仮決めします。
- ポイント：SLA（契約ライン）よりも厳しく設定してバッファを持たせること。
- 運用と見直し
- 運用を開始し、エラーバジェットの消費状況をモニタリングします。
- バジェットが毎月大量に余るなら、目標が緩すぎるか、もっと攻めた開発ができるサインです。逆にすぐ枯渇するなら、目標が高すぎるか、システムの根本的な改修が必要です。
Yachi張り切って「全ページの全リクエスト」を監視対象にしがちですが、それは悪手です。個人的には、まずは「トップページ」と「コンバージョン（購入・登録）に関わる動線」だけに絞ってSLOを設定することを強く推奨します。守るべきものが多すぎると、アラートが鳴りすぎて誰も見なくなりますから。
よくある質問 (FAQ)
- SLA違反時の返金は自動的に行われますか？
-
A: ほとんどの場合、自動ではありません。
多くのクラウドサービスやSaaSでは、ユーザー自身が障害日時やログを特定し、規定の期間内（例：30日以内）に申請フォームから申し込む必要があります（申告制）。「勝手に値引きされる」と思って放置していると、権利が失効してしまうので注意が必要です。 - 個人開発アプリでもSLAを設定すべきですか？
-
A: 対外的な「SLA（契約）」は不要ですが、自分用の「SLO（目標）」はおすすめです。
個人開発で返金契約を結ぶ必要はありません。しかし、「SLO：応答速度1秒以内」といった目標を自分で設定しておくと、パフォーマンス改善の目安になりますし、開発のモチベーション維持にもつながります。 - エラーバジェットを使い切ったらどうすればいいですか？
-
A: 痛みを伴いますが、「新機能のリリース（コード変更）」を凍結します。
本来のSRE（Site Reliability Engineering）の考え方では、予算枯渇は「信頼性が危険水域にある」というサインです。開発リソースを機能追加ではなく、システムの安定性向上（技術的負債の解消、テスト強化など）に全振りし、信頼性が回復する（予算が補充される）まで待ちます。これを徹底できるかが、SLO運用の本質です。
まとめ
SLA・SLO・SLIは、一見すると似たような3文字略語ですが、それぞれ明確な役割分担があります。
- SLI (Indicator): 健康状態を示す事実・メーター。
- SLO (Objective): チームが目指す内部目標。アラートの基準。
- SLA (Agreement): 顧客と約束する最低保証・契約。破ると罰則。
エンジニアとして働く上で、これらを意識することは「ただコードを書く」段階から、「サービスの信頼性と価値をコントロールする」段階へのステップアップを意味します。
まずは自分の担当しているシステムで、「ユーザーにとっての『当たり前の品質』とは何か（SLI）」を定義するところから始めてみてください。
Yachi最初は難しく考えず、「このシステムが止まったら、誰にどれだけ迷惑がかかるのか？」を想像することからスタートしましょう。そこから、適切な目標値（SLO）も、約束すべきライン（SLA）も自然と見えてくるはずです。
