本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第11弾として、SLO・SLI・SLAについて解説する記事です。
100%稼働は追求すべき目標ではない──エラー予算で開発速度を買うのがSLOの本質です。本記事ではSLI（実測値）／SLO（目標値）／SLA（契約値）の関係、エラーバジェットの運用、ユーザー視点SLIの選び方、サービス種別×目標値の数値Gateまで解説します。
本記事のテーマについてさらに詳しく知りたい方は『ITアーキテクチャのセオリー』も参考にしてみてください。
この記事の結論
- 100%を求めない。SLIはユーザー影響で選ぶ
- SLOはSLAより厳しく設定して余裕を持たせる
- エラー予算でリリース判断を機械化する
この記事を読む前に
本記事は開発・テスト・リリース・監視といった、サービスを作って動かし続ける工程の話が中心です。IT用語にあまり馴染みがない方は、基礎編の「開発から運用までの流れ」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもSLO・SLIとは何か
電車の定時運行率を思い浮かべてください。日本の鉄道は「定時率99.x%」という数値目標を持ち、遅延が何分以内なら許容範囲、超えたら改善対象と明確に線を引いています。100%を目指すと過剰投資になるため、現実的な目標値を決めて運用するのが鉄道の知恵です。
SLOはWebサービス版の定時率目標です。「稼働率99.9%以上」「応答時間200ms以下」のように、サービスの品質目標を数値で定義します。SLIはその実測値、SLAは顧客との契約値です。
もしSLOがなければ、「もっと安定しろ」「もっと速くしろ」の声に終わりがなく、過剰品質に投資し続けるか、逆に品質を放置して大事故を起こすかの二択になります。
なぜSLO・SLIが必要か
第一に、「十分良い」を定義できるからです。数値で合意すれば、過剰品質で開発が止まる事態を避け、投資判断が合理化されます。第二に、ビジネスと技術の共通言語になるからです。「99.9%稼働＝月43分ダウン」と数値で示せば、ビジネス側も技術的な妥協を理解できます。第三に、改善の優先順位が明確になるからです。SLO違反が頻発する領域は投資優先、守れている領域は新機能優先──とリソース配分が論理化されます。
SLI／SLO／SLAの違い
| 意味 | 使い方 | |
|---|---|---|
| SLI | 実測値 | 今の稼働率・レイテンシ |
| SLO | 内部目標 | 99.9%・200ms 以下 |
| SLA（Service Level Agreement） | 契約上の約束 | 外部顧客との契約・違反で罰金 |
SLO < SLAにするのが鉄則です。内部目標を契約値より厳しくしないと、顧客と交わした約束を破ることになります。SLOはSLAの余裕を持った内部ガードレールです。
SLIはユーザー体験を測る指標で、可用性（成功リクエスト数÷全リクエスト数）・レイテンシ（P95で200ms以下等）・エラー率・正確性・データ鮮度が定番です。「CPU使用率」「メモリ消費」はSLIではありません（ユーザー影響の間接指標にすぎない）。ユーザーから見て壊れている／遅い／間違っていると感じる軸を選ぶのが正解です。
可用性の目安表
「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%」は月26秒しかダウンできない極めて厳しい水準で、ほとんどのサービスには過剰です。
エラー予算（Error Budget）とSLOベースの運用
エラー予算はSLOに対する「許容できる失敗の量」です。「99.9%を目指す」＝「0.1%は失敗してOK」という発想で、この0.1%がエラー予算になります。
SLO: 99.9% 可用性（月43分ダウン許容）
└─ 月初は43分の予算がある
├─ リリースで10分ダウン → 残り33分
├─ 障害で30分ダウン → 残り3分
└─ 予算枯渇 → リリース停止・安定化優先SLOが定まれば運用判断が数値化されます。エラー予算の残量が50%超なら新機能リリースを加速、10〜50%なら通常運用、10%未満ならリリース凍結して安定化、枯渇したらリリース停止・原因究明──「リリースすべきか」を感覚ではなく数字で決められます。これがSRE運用の本質です。
可用性SLOを明文化した瞬間、開発チームの空気が変わる、というのはSRE導入の定番の逸話です。99.9%と数値で合意した現場では、「今月はあと32分、事故ってもいい」という会話ができるようになり、新機能の投入速度が倍に増えた、という事例も語られています。SLOは縛る数字ではなく、自信を持って踏み込むための数字です。
なおSLOの設定は、①クリティカルパス（ユーザーが必ず通る機能）を特定→②「壊れた」の測定軸を決める→③既存の実測値を知る→④現実的な目標値を提案→⑤業務・経営と合意→⑥四半期ごとに見直し、というプロセスで進めます。最初は緩く設定し、徐々に厳しくするのが安全です。
SLOアラート（バーンレート）
SLO違反を早期検知するアラートにはバーンレート（予算消費速度）を使います。1x が正常消費、5x で早期警告として調査、10x で緊急対応、50x で即座のロールバック──予算消費の傾斜で判断します。閾値ベースアラート（CPU 80%超過等）と違い、バーンレートはユーザー影響を直接反映します。
さらに、短い時間窓（1時間・6時間）で急激な障害を、長い時間窓（1日〜30日）で持続的・慢性的な品質低下を検知するマルチウィンドウ・マルチバーンレートが、Google SRE Workbookが示す現代SREの標準的なアラート設計です。具体的な発報基準は、1時間で予算の2%消費（burn rate > 14.4×）でCritical、6時間で5%消費（6×）でHigh、3日で10%消費（1×）でWarningです。
3つのシナリオで考える
個人開発・社内ツールの場合
可用性99%とレイテンシだけ見ておけば十分です。エラー予算の運用は不要で、メトリクス基盤だけ整えておきましょう。ダウンタイム月7時間の許容は現実的な水準ですし、過剰投資を避けられます。そもそも計測できない状態でSLOを決めても無意味ですので、まずは監視基盤が先です。
中小SaaS企業の場合
可用性99.9%にP95レイテンシ、エラー率という3本柱で運用する段階です。DatadogやGrafana CloudのSLO機能で始めて、四半期ごとに実測を見ながら目標値を調整していきます。エラー予算が枯渇したらリリース凍結、というルールもこの段階で運用に乗せたいところです。B2B契約が増えてきたら、99.95%への引き上げを検討することになります。
大企業・金融の場合
可用性99.99%とマルチバーンレートアラートの世界になります。SLA違反が罰金に直結するため、SLOをSLAより厳しくする余裕設計が必須です。障害通知が即座に経営層まで上がる体制も作っておく必要があります。
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分 |
| AIエージェント（LLM） | 正確性95%／応答遅延3s | 応答速度 + 正確性 | ハルシネーション率 <5% | 独自設計 |
SLOはサービス種別で数値を切り分ける。全サービス同じ基準は過剰か過小になります。
AI判断軸 ― AI機能には4軸SLOが必要
AI機能に対するSLOの新しい4軸
AIをプロダクトに組み込む場合、従来のSLO（可用性・レイテンシ）だけでは品質を測れません。AI機能特有の指標として以下の4軸を追加で定義する必要があります。
- 正確性 ― AIの回答が正しい割合（ハルシネーション率の逆数）。DeepEval・Ragas等で測定
- 遅延 ― レスポンスまでの時間（LLMはストリーミング開始までのTTFBで測る）
- コスト ― 1リクエストあたりのLLM API費用（上限を超えたら縮退する設計）
- 安全性 ― 有害・不適切な出力の発生率
これらをSLOとして数値化し、エラー予算の管理に組み込むことで、AI機能の品質劣化を客観的に検知できます。
エラー予算をAIが自動監視しリリース判断に使う
エラー予算の残量をリアルタイムで計算し、「残量30%以下で新機能リリースを自動ブロック」「残量60%以上でリリース加速」のようなルールをCIパイプラインに組み込む運用が広がっています。この判断ロジック自体はシンプルな閾値比較ですが、AIがエラー予算の消費傾向を分析し「このペースだと来週中に予算が枯渇する」という予測を出せるようになりつつあります。
やってはいけないこと
SLO運用で事故る典型を、特に危険な6つに絞ります。どれも数値が機能していない状態を生みます。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 100%稼働を目標に掲げる | コスト無限大・開発停止 → エラー予算前提のSLO＜100%で合意する |
| SLO＝SLAに設定 | 内部ガードレールなし、違反＝契約違反で制裁金 → SLOはSLAより厳しく |
| CPU使用率をSLIにする | ユーザー影響と直結しない → エラー率・レイテンシ・正確性で測る |
| 平均値でSLIを測る | 1%の遅いユーザーが見えない → P95 / P99で測る |
| エラー予算が枯渇してもリリース継続 | 信頼性崩壊・顧客離反 → 予算枯渇＝リリース凍結を組織ルールにする |
| SLOを一度決めたら固定 | ビジネスも技術も変化する → 四半期ごとに見直す |
逆に、エラー予算が残っているのにリリースを抑制するのも過剰安定化による開発速度の損失です。予算は使うためにあります。
筆者メモ — 「100%を追求した結果、開発が止まった」事例
ある中堅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について、SLI/SLO/SLAの違い・典型SLI・可用性目安・エラー予算・バーンレートアラート・サービス種別ごとの数値Gate・AI時代の4軸SLOまで含めて解説しました。如何だったでしょうか。
SLIはユーザー影響で選び、SLO<SLAで余裕設計、エラー予算でリリース判断、AI時代は4軸SLOで品質担保する。これが2026年のSLO/SLI設計の現実解です。
次回はインシデント対応（オンコール・ポストモーテム）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Google SRE Books も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（70/95）