2026年における SLO 運用の到達点
Google SRE 本初版から10年以上が経ち、SLO（Service Level Objective）は「実装した方が良いプラクティス」から「実装されていなければ監査で指摘される組織統制」へと位置付けが変わった。2026年の現場で SLO が機能している組織に共通するのは、三つの階層が揃っていることだ。第一に UX に直結した SLI（Service Level Indicator）、第二に multi-window multi-burn-rate アラート、第三に Error Budget Policy として文書化され経営が署名した「予算超過時の行動規範」である。
逆に言えば、この三つのどれか一つでも欠けていると SLO は形骸化する。ダッシュボードにゲージが並んでいるだけ、赤くなってもリリース速度は変わらない、深夜にページが鳴るが原因調査が朝まで遅延する——こうした「SLO ごっこ」から脱却するための設計判断を本稿で整理する。
UX-based SLI: 合成指標から実ユーザ体験へ
SLI は「ユーザが体感する品質」を数値化したものでなければならない。10年前は「HTTP 5xx レート」や「p99 レイテンシ」で十分だったが、現代のフロントエンド分散構成ではこれらが UX と乖離する。あるページで 5xx が出ても、クライアント側のリトライで成功していればユーザは何も気付かない。逆に 2xx が返っていても、クライアント JS が重くて Interaction to Next Paint（INP）が 500ms を超えていれば体感は劣悪である。
- 年の SLI 設計では、Real User Monitoring（RUM）と合成監視を組み合わせ、「Good events / Valid events」比率を UX 視点で定義する。具体的には、「ログイン後ホーム表示までの INP が 200ms 未満」「チェックアウト API の client-side 成功率（リトライ含む）が 99.5% 以上」のように、ユーザアクション単位で SLI を作る。バックエンドの技術的指標（CPU、メモリ、GC 時間）は SLI ではなく root cause 分析用の副次指標として位置付ける。
Multi-Window Multi-Burn-Rate アラートの定石
単純な「エラー率が 1% を超えたらページ」というアラートは、2026年の基準では不合格である。ノイズが多すぎる（瞬間的スパイクで起きる誤報）か、検知が遅すぎる（月次 99.9% SLO の違反を数時間後に気付く）かのどちらかになる。Google が提唱し業界標準となった multi-window multi-burn-rate（MWMBR）アラートは、この両立を解く。
基本形は二つのウィンドウを同時に評価する。短いウィンドウ（例: 5分間）で high burn rate（例: 14.4倍＝2% の予算を1時間で燃焼）を検知し、同時に長いウィンドウ（例: 1時間）で sustained burn（例: 6倍＝5% を1日で燃焼）を確認する。両方が閾値を超えたときだけページする。これにより、瞬間的ノイズには反応せず、かつ深刻な事象は数分で検知できる。
実装は Prometheus の recording rule で `slo:error_budget_burn_rate:5m` と `slo:error_budget_burn_rate:1h` を先計算し、Alertmanager ルールで AND 結合する。Sloth、OpenSLO、Nobl9 といった SLO 定義ツールはこのパターンをテンプレートから自動生成してくれる。2026年時点では OpenSLO 仕様が de facto になりつつあり、SLI・SLO・アラートを YAML で一元管理する流れが定着した。
Error Budget Policy: 経営合意形成の技術
SLO の真の価値は「予算超過時に何をするか」があらかじめ合意されていることだ。これが Error Budget Policy（EBP）である。EBP は技術文書ではなく経営文書として扱うべきで、以下の四項目を最低限含む。第一に対象サービスと SLO 値、第二に「予算 50% 消費で何が起きるか」「80% で何が起きるか」「100% 超過で何が起きるか」の階段状の対応、第三に「凍結」の定義——機能リリース停止、インフラ変更のみ許可、災害復旧訓練の優先化など、第四に解除条件と最終決裁者の明記である。
最も重要なのは「100% 超過で翌スプリントの新機能開発を停止し、信頼性改善に全振りする」という条項を経営が署名することだ。これを事前に合意しておかないと、超過のたびに「今回は特例で」が繰り返され、EBP は死ぬ。日本企業の現場では「停止」という言葉への抵抗が強いが、「凍結」「信頼性スプリント」などの穏当な表現に変えても実効性は維持できる。肝心なのは「開発と信頼性のトレードオフを、個別判断ではなくルールベースで処理する」という合意である。
LLM サービス固有の SLO 設計
- 年に最も議論が進んでいるのが LLM サービスの SLO 設計だ。従来の Web サービスと決定的に違うのは、(1) レスポンスがストリーミングで段階的に返る、(2) 応答時間がトークン長に依存する、(3) モデル切替（フォールバック）で品質が変動する、の三点である。これに対応する SLI として、現場で定着しつつあるのが次の三つだ。
第一に TTFT（Time To First Token）。ユーザが送信ボタンを押してから最初のトークンが画面に現れるまでの時間で、体感速度の主要因子である。SLO 例としては「TTFT < 800ms を 99% で達成」。第二に ITL（Inter-Token Latency）、連続するトークン間の平均間隔で、スムーズさを示す。「ITL < 50ms を 95% で達成」が典型値。第三に completion latency、最終トークンまでの総所要時間で、短文/長文を別 SLI に分けるのが定石。
加えて品質系 SLI として、guardrail 違反率、hallucination スコア（LLM-as-Judge ベース）、ツール呼び出し成功率を並置する。これらは確率的指標のため、絶対閾値ではなく「ベースラインからの回帰率」で監視する実装が現実的だ。Langfuse、Arize AX、Datadog LLM Observability はいずれも 2026年版で TTFT/ITL をネイティブ計測できる。
SLO を壊さないための三つの運用規律
最後に、SLO を導入しても数ヶ月で形骸化する典型的失敗と、それを防ぐ運用規律を述べる。第一は「SLI が多すぎて誰も見ない」問題。サービスあたり最重要 SLI は3～5個までに絞り、四半期ごとにレビューで削減する。第二は「Error Budget を計算していない」問題。Burn Rate の可視化だけでなく、残り予算（分単位）をダッシュボードと週次レポートに必ず出す。第三は「postmortem と EBP が連動していない」問題。インシデント報告には必ず「本件で消費した error budget」欄を設け、四半期 SLO レビューで原因別に積み上げる。
この三つが回っている組織は、SLO を単なる指標ではなく意思決定の共通言語として使えている。KGA IT ではクライアントの SRE 成熟度診断で、まずこの三点の実装有無を確認することをルーチン化している。