TL;DR
- 2026年の SRE KPI は SLI（測定可能な信頼性）・SLO（目標値）・Error Budget（許容失敗）・Toil 率（手作業比率）の4軸で構成する
- Toil 率は 50% を超えると「SRE が SRE していない」状態。運用判定の最重要シグナル
- AI SRE ツール（PagerDuty AI / Datadog Watchdog / Sherlocks 等）が KPI の計測・解釈を自動化、人手判定の余地が縮小
- SLI/SLO を「全社統一」にすると形骸化、サービス単位でカスタム設計する
- KPI を運用に乗せるには observability stack（trace + log + metrics + eval）との接続が前提
この記事の目的と成功基準
- 目的: SRE 運用に乗る4軸 KPI を、実装粒度で言語化する
- 想定読者: SRE / Platform チームの IC・テックリード、SLO 文化を組織に入れる EM
- 成功基準: 「SRE KPI」「SLO 運用」関連クエリでの流入、LLM本番運用 への回遊
4軸 KPI フレーム
1. SLI（Service Level Indicator）
実測可能な信頼性指標。「何をもって正常稼働とするか」の定量定義。
代表例：
| サービス | SLI 例 |
|---|---|
| Web API | 成功応答率（200番台 / 全リクエスト）、p99 latency |
| バッチ処理 | 完了時刻の SLA 内達成率 |
| データパイプライン | freshness（最新データの遅延）、completeness |
| LLM アプリ | 出力品質スコア（LLM-as-judge）、cost predictability |
落とし穴: メトリクスを「集めれば SLI」と勘違いしてはいけない。SLI は ユーザー体感に直結する指標 だけを採用する。サーバー側 CPU 使用率は SLI ではない。
2. SLO（Service Level Objective）
SLI に対する目標値。「99.9% の API 成功率」のような閾値。
設計指針：
- エラー予算が回るレベルに設定: 99.99% は厳しすぎ、99% は緩すぎ
- ビジネス影響と整合: 決済 API と社内ツールでは目標が違って当然
- 下限と上限の両方: 「最低 99.9%、目標 99.95%」と幅を持たせる
Just After Midnight の SRE best practices 2026 では、SLO を「測れる、改善可能、ビジネス価値と紐付く」の3条件で評価することを推奨。
3. Error Budget（エラー予算）
「100% から SLO を引いた残り」=失敗してよい余地。
例：SLO=99.9% → Error Budget=月間 43分
運用ルール：
- 予算消化中はリリース凍結: 信頼性回復が優先
- 予算余剰時はリリース速度を上げる: 新機能投入の判断材料
- 四半期で繰り越し可否を決める: 健全な組織は使い切る、過剰に余らせない
Error Budget は「リスクを取ってよい量」を可視化する装置。これを設定しないと「いつも100%稼働を目指す→疲弊」または「信頼性を諦める→事故頻発」のどちらかに偏る。
4. Toil 率
"If SREs spend >50% of their time on tickets vs. engineering, the system is unsustainable."
Toil（手作業・反復・低価値）の SRE 工数比率。50% 超で警告。
測定方法：
- 週次タイムログで「Toil / engineering / 学習」を分類
- 個人別ではなくチーム平均で見る
- 4週移動平均で傾向を捉える
50% 超が3週続いたら緊急介入：
- 上位3つの Toil タスクを特定
- それぞれを自動化 or 廃止 or 委譲
- 介入後2週で再測定
IBM の SRE Observability 解説 でも、Toil の継続監視が「持続可能な SRE 文化」の柱と位置づけられている。
観測スタックとの紐付け
KPI を運用に乗せるには observability stack との接続が前提。
[Users] → [App] → [Logs / Metrics / Traces]
↓
[SLI 計算（query）]
↓
[SLO ダッシュボード] → [Error Budget アラート]
↓
[Incident → Toil 記録]
↓
[週次レビュー（4 KPI 一覧）]
KPI と観測の接続が無いと、ダッシュボードが「数字が並んでいるだけ」になる。週次レビューで4 KPI を一覧化し、Error Budget 状況と Toil 率を必ず見る運用が定着の鍵。
AI SRE ツール時代の指標設計
2026年 AI SRE ツール比較 では、PagerDuty AI、Datadog Watchdog、Sherlocks AI 等が KPI 計測・異常検知・自動修復を担うようになった。
人手判定が減る一方、新たな課題が生まれる：
- AI 誤検知率: 自動アラートのノイズ
- AI 自動修復の安全性: rollback できる範囲か
- AI に渡す権限スコープ: 最小権限の徹底
→ 結果として「AI による運用」を測る KPI が必要：
| AI 由来 KPI | 測定内容 |
|---|---|
| AI alert precision | 真陽性 / 全 AI alert |
| AI auto-remediation success rate | 自動修復の成功率 |
| Human escalation rate | AI で解決できず人手に渡った割合 |
| AI 関連 incident | AI 誤動作起因の障害 |
これは LLMガードレール設計 と同種の枠組みを SRE 運用に拡張したもの。
サービス単位カスタム設計
「全社統一 SLO」は形骸化しやすい。サービス特性に合わせる。
| サービス種別 | SLO 設定例 | Error Budget |
|---|---|---|
| Tier 1（決済・認証） | 99.95% / p99 < 200ms | 月間 22分 |
| Tier 2（コア機能） | 99.9% / p99 < 500ms | 月間 43分 |
| Tier 3（補助機能） | 99.5% / p99 < 1s | 月間 3.6時間 |
| バッチ・社内ツール | 99% / 完了時刻SLA | 1日 14分 |
Tier ごとに：
- on-call 対応の優先順位
- インシデント時の通知先
- リリース凍結判定基準
を変える。一律ルールは Tier 1 の負荷を Tier 3 に分散させてしまい逆効果。
アンチパターン
- SLO を経営報告のために作る: 形骸化、運用に紐付かない
- Error Budget を消費しても何もしない: 予算が単なる数字に
- Toil を個人責任にする: 個人ではなく仕組みの問題、チーム平均で見る
- AI SRE ツールに完全依存: 人間の判定軸を残す（precision / auto-remediation 結果は review する）
- KPI を増やしすぎる: 4軸＋AI軸の8つで十分、これ以上は ROI 逓減
週次レビューのテンプレート
毎週月曜 30分で実施：
- SLI 推移: 主要サービスの先週実績（5分）
- SLO 達成状況: 達成 / 未達 / borderline（5分）
- Error Budget 残量: Tier 1-3 別（5分）
- Toil 率: チーム平均、上位3項目（10分）
- AI 由来 KPI: 誤検知・自動修復成功率（5分）
このテンプレートを4-6週続けると、SLO 文化がチームに定着する。
FAQ
Q. 既存サービスに SLO を入れる時、目標値はどう決めますか？ A. まず4週間の実測値を観測（"informational SLO"）し、その実績を5%下回る値を初期 SLO に。その後3か月ごとに見直します。
Q. Toil 率の測定にコストをかけたくない、軽量手段は？ A. 週次 Slack 投稿で「今週の作業を toil / engineering / 学習に分類」を自己申告で5分。完璧でないが傾向は掴めます。
Q. 全社統一 SLO を経営から要請されたら？ A. Tier 1（決済等）を統一基準に、それ以外は「Tier 2 以下はサービス別 SLO で運用」と例外を明示します。一律目標は逆効果と説明できる準備が必要です。
まとめ
2026年の SRE KPI は SLI / SLO / Error Budget / Toil 率の4軸＋AI 由来 KPI で構成する。Toil 50% を超えた瞬間に介入する仕組み、Error Budget 消費中はリリース凍結する規律、サービス単位の Tier 設計、週次レビューでの一覧化、この組み合わせで SRE 文化が運用に定着する。AI SRE ツール時代でも人間の判定軸を残すことが鍵。
