本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第11弾として、SLO・SLI・SLAについて解説する記事です。
100% 稼働は追求すべき目標ではない──エラー予算で開発速度を買うのが SLO の本質です。本記事では SLI（実測値）／SLO（目標値）／SLA（契約値）の関係、エラーバジェットの運用、ユーザー視点 SLI の選び方、サービス種別×目標値の数値Gateまで解説します。
本記事のテーマについてさらに詳しく知りたい方は『ITアーキテクチャのセオリー』も参考にしてみてください。
そもそもSLO・SLIとは何か
電車の定時運行率を思い浮かべてください。日本の鉄道は「定時率99.x%」という数値目標を持ち、遅延が何分以内なら許容範囲、超えたら改善対象と明確に線を引いています。100%を目指すと過剰投資になるため、現実的な目標値を決めて運用するのが鉄道の知恵です。
SLOはWebサービス版の定時率目標です。「稼働率99.9%以上」「応答時間200ms以下」のように、サービスの品質目標を数値で定義します。SLIはその実測値、SLAは顧客との契約値です。
もしSLOがなければ、「もっと安定しろ」「もっと速くしろ」の声に終わりがなく、過剰品質に投資し続けるか、逆に品質を放置して大事故を起こすかの二択になります。
なぜSLO・SLIが必要か
「十分良い」を定義できる
SLO がないと「もっと安定しろ」「もっと速くしろ」の声に終わりがなくなり、過剰品質で開発が止まります。数値で合意すれば投資判断が合理化されます。
ビジネスと技術の共通言語
「99.9%稼働＝月43分ダウン」と数値で示せば、ビジネス側も技術的な妥協を理解できます。言葉だけの議論は平行線になります。
改善の優先順位が明確になる
SLO 違反が頻発する領域は投資優先、守れている領域は新機能優先──とリソース配分が論理化されます。
SLI／SLO／SLAの違い
| 意味 | 使い方 | |
|---|---|---|
| SLI | 実測値 | 今の稼働率・レイテンシ |
| SLO | 内部目標 | 99.9%・200ms 以下 |
| SLA(Service Level Agreement) | 契約上の約束 | 外部顧客との契約・違反で罰金 |
SLO < SLA にするのが鉄則です。内部目標を契約値より厳しくしないと、顧客と交わした約束を破ることになります。SLO は SLA の余裕を持った内部ガードレールです。
典型的なSLI
SLI はユーザー体験を測る指標で、以下のパターンが定番です。「CPU使用率」「メモリ消費」は SLI ではありません（ユーザー影響の間接指標）。
| 種類 | 定義 |
|---|---|
| 可用性 | 成功リクエスト数／全リクエスト数 |
| レイテンシ | 95パーセンタイルで200ms以下 |
| エラー率 | 5xxエラー／全リクエスト |
| スループット | 秒間処理数 |
| 正確性 | 正しい結果／全結果 |
| 鮮度 | データ更新からの経過時間 |
ユーザーから見て壊れている／遅い／間違っていると感じる軸を選ぶのが正解です。
可用性の目安表
「99.9%」と言っても実感が湧きにくいですが、ダウンタイムに換算すると判断しやすくなります。業務要件に応じて適切なレベルを選びます。
| 可用性 | 許容ダウン／月 | 許容ダウン／年 | 向くサービス |
|---|---|---|---|
| 99% | 約7時間 | 約3.6日 | 社内ツール |
| 99.9% | 約43分 | 約8.7時間 | 一般B2Cサービス |
| 99.95% | 約22分 | 約4.4時間 | B2B SaaS |
| 99.99% | 約4.3分 | 約52分 | 金融・決済 |
| 99.999% | 約26秒 | 約5.2分 | 通信・電力 |
「99.999%」は月20秒しかダウンできない極めて厳しい水準です。ほとんどのサービスには過剰です。
エラー予算（Error Budget）
SLO に対する「許容できる失敗の量」です。「99.9%を目指す」＝「0.1%は失敗してOK」という発想で、この0.1%がエラー予算になります。予算内なら積極的にリリース、予算超過ならリリース停止──という運用ルールに使います。
SLO: 99.9% 可用性（月43分ダウン許容）
└─ 月初は43分の予算がある
├─ リリースで10分ダウン → 残り33分
├─ 障害で30分ダウン → 残り3分
└─ 予算枯渇 → リリース停止・安定化優先エラー予算が残っているうちは開発を加速し、枯渇したら信頼性改善に投資するという、開発と運用のバランスを取る仕組みです。
SLOの選定プロセス
SLO は勝手に決めるのではなく、ビジネスと合意して設定します。ユーザー影響を無視した技術寄りの SLO は意味がないため、業務部門・営業・技術の合意が必要です。
| ステップ | 内容 |
|---|---|
| 1. クリティカルパス特定 | ユーザーが必ず通る機能 |
| 2. ユーザー体験の測定軸 | 何を持って「壊れた」とするか |
| 3. 既存値の測定 | 今の実測を知る |
| 4. 目標値の提案 | 現実的な目標 |
| 5. ステークホルダー合意 | 業務・経営と合意 |
| 6. 運用開始・見直し | 四半期ごとに見直し |
最初は緩く設定し、徐々に厳しくするのが安全です。いきなり99.99%を約束すると守れません。
SLOベースの運用
SLO が定まれば、運用判断が数値化されます。「リリースすべきか」「アラートを上げるべきか」を感覚ではなく数字で決められます。これが SRE 運用の本質です。
| シナリオ | 判断基準 |
|---|---|
| エラー予算残 >50% | 新機能リリース加速 |
| エラー予算残 10〜50% | 通常運用・注意深く |
| エラー予算残 <10% | リリース凍結・安定化 |
| エラー予算 枯渇 | リリース停止・原因究明 |
エラー予算が「0」になったら、新機能を止めて信頼性改善するのが SRE のルールです。守れないと信頼性と速度の両方を失います。
可用性 SLO を明文化した瞬間、開発チームの空気が変わる、というのは SRE 導入の定番の逸話です。99.9% と数値で合意した現場で、それまで「リリースは常に慎重に」という漠然とした緊張があった場所で、「今月はあと32分、事故ってもいい」という会話ができるようになり、新機能の投入速度が倍に増えた、という事例も語られています。SLO は縛る数字ではなく、自信を持って踏み込むための数字であることを示す典型例です。
SLOアラート（バーンレート）
SLO 違反を早期検知するアラートで、バーンレート（予算消費速度）を使います。1時間で月予算の10%を消費したら警告、50%を消費したら緊急──というように、予算消費の傾斜で判断します。
| バーンレート | 意味 | 対応 |
|---|---|---|
| 1x | 正常消費 | 無対応 |
| 5x | 早期警告 | 調査 |
| 10x | 急激な消費 | 緊急対応 |
| 50x | 危機的 | 即座のロールバック |
閾値ベースアラート（CPU 80%超過等）より、SLO バーンレートの方が有意義です。バーンレートはユーザー影響を反映します。
マルチウィンドウ・マルチバーンレート
短い時間窓で高速消費と長い時間窓で持続消費の両方を監視する手法です。「1時間で急激に予算を食う」「24時間かけて徐々に食う」両方を検知できます。
| 窓長 | 検知対象 |
|---|---|
| 短期（1時間・6時間） | 急激な障害 |
| 中期（1日・3日） | 持続的な問題 |
| 長期（7日・30日） | 慢性的な品質低下 |
Google SRE Workbook に詳細があり、現代 SRE の標準的なアラート設計です。
判断基準①：サービスの性質
SLO の厳しさはサービスの性質で決まります。死活に関わるサービスほど厳しく、実験的なサービスは緩く設定するのが現実的です。
| サービス種別 | 推奨SLO |
|---|---|
| 社内ツール | 99%（月7時間ダウン許容） |
| 一般B2Cサービス | 99.9%（月43分） |
| 重要B2C・決済 | 99.95%〜99.99% |
| 金融・医療 | 99.99%以上 |
| β版・実験機能 | 95%で十分 |
判断基準②：組織成熟度
SLO は組織がある程度成熟してから導入するのが現実的です。計測できない状態で SLO を決めても無意味で、まずメトリクス収集基盤が必要です。
| 成熟度 | 状態 |
|---|---|
| Lv1: 監視なし | メトリクス基盤構築が先 |
| Lv2: 監視あり | 実測値を見て SLI 候補選定 |
| Lv3: SLI 選定済 | SLO 設定・運用開始 |
| Lv4: SLO 運用中 | エラー予算で運用判断 |
| Lv5: SRE 成熟 | 自動判断・自律運用 |
ケース別の選び方
個人開発・社内ツール
可用性99% + レイテンシのみ。エラー予算運用は不要、メトリクス基盤だけ整える。ダウンタイム月7時間は現実的で、過剰投資を避けられます。
スタートアップ・一般B2C SaaS
可用性99.9% + P95（95パーセンタイル＝遅い方から5%を除いた応答時間）レイテンシ + エラー率の3本柱。Datadog や Grafana Cloud の SLO 機能で開始。四半期ごとに実測を見て目標値を調整、エラー予算枯渇でリリース凍結ルールを運用。
金融・決済・医療系
可用性99.99% + マルチバーンレートアラート。SLA 違反は罰金に直結するため、SLO < SLA の余裕設計が必須。障害通知は即座に経営層に上がる体制を作ります。
AIエージェント・LLMサービス
正確性・応答遅延・コスト・安全性の4軸 SLO。従来の可用性 SLO だけでは不十分。DeepEval・Ragas 等で正確性 SLI を測定し、ハルシネーション率を継続監視します。
SLOレベル×サービス種別の数値Gate
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
SLO は「99.9%」だけでは曖昧で、サービス種別ごとに複数軸で数値化するのが実務です。
| サービス種別 | 可用性SLO | レイテンシ（P95） | エラー率 | エラー予算／月 |
|---|---|---|---|---|
| 社内ツール | 99% | 1,000ms | 1% | 7時間 |
| 一般B2C Web | 99.9% | 300ms | 0.5% | 43分 |
| B2B SaaS | 99.95% | 200ms | 0.3% | 22分 |
| 金融・決済 | 99.99% | 100ms | 0.1% | 4.3分 |
| 通信・電力 | 99.999% | 50ms | 0.01% | 26秒 |
| AIエージェント（LLM） | 正確性95%／応答遅延3s | 応答速度 + 正確性 | ハルシネーション率 <5% | 独自設計 |
バーンレートアラートの数値Gateは、1時間で予算の2%消費（burn rate > 14.4×）で Critical、6時間で予算の5%消費（6×）で High、3日で予算の10%消費（1×）で Warning。これが Google SRE Workbook 標準の発報基準です。
SLO はサービス種別で数値を切り分ける。全サービス同じ基準は過剰 or 過小になります。
やってはいけないこと
SLO 運用で事故る典型パターン。どれも数値が動いていない状態を生みます。
| 禁じ手 | なぜダメか |
|---|---|
| 100%稼働を目標に掲げる | コスト無限大・開発停止。エラー予算0の運用は破綻 |
| SLO＝SLAに設定 | 内部ガードレールなし、違反＝契約違反で制裁金 |
| CPU使用率をSLIにする | ユーザー影響と直結しない。エラー率・レイテンシが正解 |
| 平均値(Average)でSLIを測る | 1%の遅いユーザーが見えない。P95／P99 で測る |
| SLOを一度決めたら固定 | ビジネスも技術も変化する。四半期ごとに見直し |
| エラー予算を枯渇してもリリース継続 | 信頼性崩壊、顧客離反。予算枯渇でリリース凍結 |
| エラー予算が残っているのにリリース抑制 | 過剰安定化、開発速度損失 |
| ステークホルダー合意なしでSRE単独でSLO設定 | 業務影響を無視した数値に |
| バーンレートアラートなしで従来閾値だけ運用 | 異常検知が遅れる。現代はburn rateが標準 |
| AIシステムに可用性SLOだけ適用 | 正確性・応答品質・コストの4軸が必要 |
| 「100%稼働を目指す」と完璧追求 | コスト無限大・開発停止、SLO＜100%が正しい |
| 「SLAをSLOと同値にする」と余裕なし | 内部ガードレールなし、違反＝契約違反で制裁金 |
金融系の逆パターン事例（SLA と SLO を同値にした結果、障害で SLA 超過 → 多額の違約金）は、内部ガードレールがないと契約違反に直結する典型例として語り草になっています。
SLO は縛る数字ではなく、踏み込むための数字。エラー予算で速度を買います。
AI判断軸
| AI有利 | AI不利 |
|---|---|
| AI専用4軸SLO（正確性・遅延・コスト・安全性） | 可用性SLOだけ |
| SLO＜SLAの余裕設計 | SLO＝SLAで内部ガードレールなし |
| エラー予算でリリース判断 | エラー予算を運用していない |
| バーンレートアラート | 静的閾値アラート |
- SLIはユーザー影響で選ぶ — CPU 使用率ではなく、エラー率・レイテンシ・正確性
- SLO < SLAで余裕設計 — 内部ガードレールを契約値より厳しく
- エラー予算でリリース判断 — 残量別にリリース加速／凍結を数値化
- AI時代は4軸SLO — 可用性に加えて正確性・コスト・安全性を数値化
AI機能に対するSLOの新しい4軸
AIをプロダクトに組み込む場合、従来のSLO（可用性・レイテンシ）だけでは品質を測れません。AI機能特有の指標として以下の4軸を追加で定義する必要があります。
- 正確性 ― AIの回答が正しい割合（ハルシネーション率の逆数）
- 遅延 ― レスポンスまでの時間（LLMはストリーミング開始までのTTFBで測る）
- コスト ― 1リクエストあたりのLLM API費用（上限を超えたら縮退する設計）
- 安全性 ― 有害・不適切な出力の発生率
これらをSLOとして数値化し、エラー予算の管理に組み込むことで、AI機能の品質劣化を客観的に検知できます。
エラー予算をAIが自動監視しリリース判断に使う
エラー予算の残量をリアルタイムで計算し、「残量30%以下で新機能リリースを自動ブロック」「残量60%以上でリリース加速」のようなルールをCIパイプラインに組み込む運用が広がっています。この判断ロジック自体はシンプルな閾値比較ですが、AIがエラー予算の消費傾向を分析し「このペースだと来週中に予算が枯渇する」という予測を出せるようになりつつあります。
筆者メモ — 「100%を追求した結果、開発が止まった」事例
完璧を追い求めた結果、肝心のリリース速度が止まってしまった、という事例は SRE の定番の語り草です。
ある中堅 SaaS で、SLOを定めずに「障害をゼロにする」を目標に掲げた結果、3か月間新機能がまったく出せず、競合に顧客を奪われた、という話がよく聞かれます。「全ての Warning を調査する」「全てのレイテンシ劣化を解消する」といった無限のタスクに開発リソースが吸われ、ビジネスが止まった典型例です。後に SLO（99.9%）を導入して予算内の障害は許容する運用に変えたところ、リリース速度が倍以上に戻った、というパターンは多く報告されています。
もう一つ、逆パターンとして、金融系システムで SLA（顧客契約）が99.9% なのに内部 SLO も同じ99.9% にしていた企業が、障害で SLA を超過 → 契約違反で多額の違約金に発展した事例もあります。SLO は SLA より厳しく設定する余裕設計が必須、という教訓の典型例として語られています。
どちらも「数値で合意していなかった」ことが根本原因で、SLO は縛る数字ではなく、速度と信頼性のバランスを工学的に扱うためのダイヤルであることを突きつけます。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- クリティカルパス（SLO対象の機能）
- SLI（何を測るか）
- SLO目標値（99.9%・99.95%等）
- SLAとの差（SLO < SLA）
- エラー予算運用ルール（残量別の判断基準）
- バーンレートアラート（短期・中期・長期）
- 見直し頻度（四半期・半期）
この記事に関連する記事
https://senkohome.com/arch-intro-devops-observability/ https://senkohome.com/arch-intro-devops-overview/ https://senkohome.com/arch-intro-devops-review/
まとめ
本記事はSLOとSLIについて、SLI/SLO/SLAの違い・典型SLI・可用性目安・エラー予算・バーンレートアラート・サービス種別ごとの数値Gate・AI時代の4軸SLOまで含めて解説しました。如何だったでしょうか。
SLIはユーザー影響で選び、SLO<SLAで余裕設計、エラー予算でリリース判断、AI時代は4軸SLOで品質担保する。これが2026年のSLO/SLI設計の現実解です。
次回はインシデント対応（オンコール・ポストモーテム）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Google SRE Books も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（64/89）