本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第11弾として、SLO・SLI・SLAについて解説する記事です。
100% 稼働は追求すべき目標ではない──エラー予算で開発速度を買うのが SLO の本質です。本記事では SLI（実測値）／SLO（目標値）／SLA（契約値）の関係、エラーバジェットの運用、ユーザー視点 SLI の選び方、サービス種別×目標値の数値Gateまで解説します。
このカテゴリの他の記事
なぜSLO・SLIが必要か
「十分良い」を定義できる
SLO がないと「もっと安定しろ」「もっと速くしろ」の声に終わりがなくなり、過剰品質で開発が止まります。数値で合意すれば投資判断が合理化されます。
ビジネスと技術の共通言語
「99.9%稼働＝月43分ダウン」と数値で示せば、ビジネス側も技術的な妥協を理解できます。言葉だけの議論は平行線になります。
改善の優先順位が明確になる
SLO 違反が頻発する領域は投資優先、守れている領域は新機能優先──とリソース配分が論理化されます。
SLI／SLO／SLAの違い
flowchart LR
USER([ユーザー体験]) --> SLI[SLI<br/>実測値<br/>例: 今月の稼働率99.95%]
SLI -->|目標と比較| SLO[SLO<br/>内部目標<br/>例: 99.9%以下にしない]
SLO -->|余裕| SLA[SLA<br/>契約値<br/>例: 99.5%下回ると罰金]
SLO -.|エラーバジェット| EB[残り0.1%<br/>= 月43分の予算]
EB -->|余裕あり| RELEASE[新機能リリース]
EB -->|使い切り| FREEZE[機能凍結 / 信頼性向上]
classDef user fill:#fef3c7,stroke:#d97706;
classDef sli fill:#dbeafe,stroke:#2563eb;
classDef slo fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
classDef sla fill:#fae8ff,stroke:#a21caf;
classDef budget fill:#f0f9ff,stroke:#0369a1;
classDef bad fill:#fee2e2,stroke:#dc2626;
class USER user;
class SLI sli;
class SLO slo;
class SLA sla;
class EB,RELEASE budget;
class FREEZE bad;| 意味 | 使い方 | |
|---|---|---|
| SLI（Service Level Indicator） | 実測値 | 今の稼働率・レイテンシ |
| SLO（Service Level Objective） | 内部目標 | 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 を測定し、ハルシネーション率を継続監視します。
よくある勘違い
100%稼働を目指す
コストが無限大。SLO < 100%が正しい。100%は達成不能で追うべきでありません。
CPU使用率をSLIにする
CPU はユーザー影響と直結しません。エラー率・レイテンシを SLI にすべきです。
SLOを一度決めたら固定
ビジネスも技術も変化します。四半期ごとに見直しが健全です。
SLAをSLOと同値にする
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運用の鬼門・禁じ手
SLO 運用で事故る典型パターン。どれも数値が動いていない状態を生みます。
| 禁じ手 | なぜダメか |
|---|---|
| 100%稼働を目標に掲げる | コスト無限大・開発停止。エラー予算0の運用は破綻 |
| SLO＝SLAに設定 | 内部ガードレールなし、違反＝契約違反で制裁金 |
| CPU使用率をSLIにする | ユーザー影響と直結しない。エラー率・レイテンシが正解 |
| 平均値(Average)でSLIを測る | 1%の遅いユーザーが見えない。P95／P99 で測る |
| SLOを一度決めたら固定 | ビジネスも技術も変化する。四半期ごとに見直し |
| エラー予算を枯渇してもリリース継続 | 信頼性崩壊、顧客離反。予算枯渇でリリース凍結 |
| エラー予算が残っているのにリリース抑制 | 過剰安定化、開発速度損失 |
| ステークホルダー合意なしでSRE単独でSLO設定 | 業務影響を無視した数値に |
| バーンレートアラートなしで従来閾値だけ運用 | 異常検知が遅れる。現代はburn rateが標準 |
| AIシステムに可用性SLOだけ適用 | 正確性・応答品質・コストの4軸が必要 |
金融系の逆パターン事例（SLA と SLO を同値にした結果、障害で SLA 超過 → 多額の違約金）は、内部ガードレールがないと契約違反に直結する典型例として語り草になっています。
SLO は縛る数字ではなく、踏み込むための数字。エラー予算で速度を買います。
AI時代の視点
AI 駆動開発（バイブコーディング）と AI 活用が前提になると、SLO はAIシステムの品質担保として新しい次元を持ちます。LLM API や AI エージェントは確率的動作をするため、従来の SLO に加えて「正確性 SLO」「レスポンス品質 SLO」が求められます。
| AI時代の新SLI | 内容 |
|---|---|
| 応答正確性 | ハルシネーション率 |
| 応答遅延 | LLM 推論時間 |
| コスト効率 | トークン単価・月額予算 |
| 安全性 | 有害コンテンツ生成率 |
LLM の出力は決定的ではないため、「99.9%正確」といった SLO は測定が難しく、新しい指標設計が必要です。Evaluation Framework（DeepEval・Ragas 等）と SLO を組み合わせた運用が始まっています。
AI 時代の SLO は品質・遅延・コスト・安全の4軸。確率的システムの信頼性を数値化します。
筆者メモ — 「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）
- エラー予算運用ルール（残量別の判断基準）
- バーンレートアラート（短期・中期・長期）
- 見直し頻度（四半期・半期）
最終的な判断の仕方
SLO と SLI の核心は100%を求めず、エラー予算で開発速度を買うという発想です。100% 稼働を目指すとコストは無限に増え、開発速度は失われます。SLO を数値で定義し、エラー予算が残っていれば積極的にリリース、枯渇したら信頼性改善に投資するという運用ルールが、SRE の本質です。サービスの性質で厳しさを変え、金融は99.99%、社内ツールは99% という具合に、ビジネスと技術で合意した数値が組織の共通言語として機能します。SLA より内部 SLO は厳しくするのが鉄則です。
もう一つの決定的な軸はAIシステムの品質SLOという新しい次元です。LLM API や AI エージェントは確率的動作をするため、可用性 SLO だけでは不十分で、正確性・応答遅延・コスト・安全性の4軸で品質を担保します。DeepEval／Ragas 等の Evaluation Framework と SLO を組み合わせ、ハルシネーション率を継続監視するのが、AI 時代の新しい運用形です。
選定の優先順位
- SLIはユーザー影響で選ぶ — CPU 使用率ではなく、エラー率・レイテンシ・正確性
- SLO < SLAで余裕設計 — 内部ガードレールを契約値より厳しく
- エラー予算でリリース判断 — 残量別にリリース加速／凍結を数値化
- AI時代は4軸SLO — 可用性に加えて正確性・コスト・安全性を数値化
「100%は求めず、エラー予算で速度を買う」SLO をビジネスと技術の共通言語にします。
まとめ
本記事はSLOとSLIについて、SLI/SLO/SLAの違い・典型SLI・可用性目安・エラー予算・バーンレートアラート・サービス種別ごとの数値Gate・AI時代の4軸SLOまで含めて解説しました。如何だったでしょうか。
SLIはユーザー影響で選び、SLO<SLAで余裕設計、エラー予算でリリース判断、AI時代は4軸SLOで品質担保する。これが2026年のSLO/SLI設計の現実解です。
次回はインシデント対応（オンコール・ポストモーテム）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（64/89）