# Agentic 時代の SLI/SLO 運用 Navigation: [[サービスレベル目標]] | [[エラーバジェット]] | [[SLI-SLO教科書]] | [[agentic SRE]] > [!abstract] 概要 > 「Agentic 時代の SLI/SLO」という一語のもとには、**対象としての AI**(AI ワークロードを測る)・**道具としての AI**(SLI/SLO の策定を AI が助ける)・**統治対象としての AI**(SLO でエージェントの権限を律する)という性質の異なる 3 つの問いが混在している。この wiki の蓄積は 3 者で極端に不均等であり、第 3 の問いがほぼ空白である。本ページはその不均等を可視化し、空白の輪郭を定義することを目的とする。 --- ## 0. 三つの問いの分離 | 問い | 内容 | 本 wiki の蓄積 | |---|---|---| | **A. 対象としての AI** | AI ワークロード自体をどう測るか | 厚い(指標体系・実運用例あり) | | **B. 道具としての AI** | SLI/SLO の策定・運用を AI が助ける | 中程度(実例あり・効果は限定的) | | **C. 統治対象としての AI** | SLO/エラーバジェットでエージェントの権限を律する | **ほぼ空白** | この分離が有用なのは、3 者で必要な知識体系がまったく異なるからである。A は指標設計の問題、B は組織的導入の律速段階の問題、C は安全仕様と契約の問題であり、A の成熟が C の成熟をもたらすわけではない。実際、本 wiki では A が最も厚く C が最も薄い。 古典的体系の側から見ると、この不均等はより明瞭になる。[[SLI-SLO教科書]] は 0〜9 章 + 付録で SLI 設計・SLO 設定・エラーバジェット・バーンレートアラート・可用性指標の進化・組織的導入までを網羅するが、拡充前の時点で **AI に触れるのは 8.8(AI サービスの SLI/SLO)と 8.10(セルフクラフト)の実質 5 行程度**にとどまり、未解決の問いに挙がる AI 関連項目も「ハルシネーション率をどのユーザー幸福フレーバーに分類するか」の 1 件のみだった (Source: [[SLI-SLO教科書]])。 --- ## 1. A — 対象としての AI: 測る次元が増える ### 1.1 性能指標は既に体系化されている LLM 推論では TTFT(Time To First Token)・TPOT(Time Per Output Token)・ITL(Inter-Token Latency)・E2EL・RPS・TPS・Goodput が SLI 候補として整理されている。Goodput は「SLO を満たすスループット」と定義され、生の TPS/RPS が SLO を無視した指標であることを補正する。秒間 10 RPS のシステムが TTFT 200ms 以下・ITL 50ms 以下の制約下では Goodput が **3 RPS まで低下**する (Source: [[LLM推論]], [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]])。 学習側には ML Productivity Goodput = **Scheduling Goodput × Runtime Goodput × Program Goodput** という三層分解がある。見かけ上 100% 利用率のクラスタでも、プリエンプション・リソース断片化・ネットワーク輻輳・障害復旧により **70〜75% の計算が実質的に失われうる** (Source: [[ML Productivity Goodput]], [[Goodput]])。 > [!warning] 指標名の一致は実装の一致を意味しない > ITL は GenAI-Perf では TTFT を含まないが LLMPerf では含む。TPS の分母定義もツールで異なるため、直接比較には正規化が要る (Source: [[LLM推論]])。SRE Workbook の「SLI 仕様と SLI 実装を分ける」という原則が、この領域では最初から破綻の危険とともに現れる (Source: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]])。 ### 1.2 従来の SLI が原理的に取り逃す次元 - **コスト起因劣化(cost-induced degradation)**: 短いコンテキストウィンドウ、小型モデルへの切り替え、低サンプリング、積極的なキャッシュ利用といったコスト制約が、**サービスエラーを一切出さずに**推論品質を劣化させる。可用性・レイテンシ SLI では検知できない (Source: [[LLMアプリケーション信頼性]], [[LLM推論]])。 - **検知困難性の定量**: 生成 AI サービスでは人手検知率 38.3%、監視メトリクス種類 25.9 対 74.4、収束時間 1.83 倍 (Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]])。 - **レイテンシ指標の死角**: 投機的 LLM 呼び出しは TTFT 中央値を 2 秒短縮する一方、最終的に使われない対話でも発火し、**レイテンシ指標には一切現れない無駄なコスト**を生む。「呼び出しが起きたか」でなく「呼び出しが使われたか」まで追跡しないとコスト異常が完全に不可視になる (Source: [[GenAI オブザーバビリティ]])。 - **同一症状・別層の原因**: ルーティングエラー・TPU 誤設定・XLA コンパイラの混合精度バグという全く異なる層が、同一の「出力品質低下」症状を生む (Source: [[LLMアプリケーション信頼性]], [[LLM推論]])。 ### 1.3 非決定的なものに SLO を張る — 三つの実務解 本 wiki に「非決定的出力への SLO 目標値を統計的にどう定式化するか」の理論はない。あるのは実務上機能している 3 系統である。 1. **成功率型 SLI へ落とす**: Honeycomb の MCP サーバーは**クエリ成功率 90% の SLO** を実運用し、モデルのフィールド名誤認や時間範囲解釈の失敗パターン発見に使った (Source: [[GenAI オブザーバビリティ]])。 2. **三値評価を許容する**: 単一の正解を持たない task evals は本番テレメトリで LLM-as-a-Judge 採点し、**pass・fail・maybe の三値**を許す。あわせて本番テレメトリから golden dataset を継続更新する (Source: [[LLM評価]])。 3. **決定論的ハーネスで囲う**: 構造誤りを再訓練や再プロンプトでなく後処理で機械的に除去し、エラー率を 25% → 14% → 1% 未満まで低減した (Source: [[LLMアプリケーション信頼性]])。 ### 1.4 コストの SLO 化 最も直接的な実例は Intercom の Fin である。**対話あたりコストを分散トレースの独自属性として載せ、それに SLO を設定**した。OpenTelemetry GenAI セマンティック規約にコストの標準キーが存在しないため規約外の方式だが、財務データウェアハウス経由で数分〜数時間かかっていたコスト劣化検知がほぼリアルタイムになった (Source: [[GenAI オブザーバビリティ]])。 一方で「GPU 費用そのものを SLO の目標値として定式化し、エラーバジェットと同様に消費管理する」枠組みは、この 1 例以外に本 wiki に記載がない。 --- ## 2. B — 道具としての AI: 起草は加速するが権威にはならない *Observability Engineering* 第 2 版第 11 章は、LLM が SLI/SLO の**最初の仮値**の起草を高速化できることを実例で示す。EC チェックアウトの信頼性目標をコストへの疑問で追い込むと、gpt-oss 20b・Claude Opus 4.6 の両モデルとも five-nines から 99.95〜99.99% へ妥当な理由づけとともに自己修正した。 一方で、OpenTelemetry セマンティック規約に基づく SLI 式生成では、**内部スパン除外フィルタのような重要な条件を両モデルとも初期応答で省略**しており、「LLM はドラフト生成器であり権威ではない」という注意が付される (Source: [[サービスレベル目標]], [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]])。 これは組織論の側と噛み合う。SLO 導入の成功パターンは一貫して「完璧な値を追い求めず、仮値から始めてフィードバックで洗練する」であり、LLM はその律速段階の一方(起草)を短縮する。もう一方の律速段階であるテレメトリ標準化への先行投資は依然として人間の仕事である (Source: [[サービスレベル目標]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 Yoshikawa の資料も、SLI/SLO 候補提案・PRC 観点レビュー・障害対応中の状況要約・ポストモーテム下書きという「書き込み権限より手前の判断支援」を実務導入の入口に置く (Source: [[agentic SRE]], [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]])。B の領域は、C に踏み込まないという条件のもとで既に実用段階にある。 --- ## 3. C — 統治対象としての AI: 最大の空白 ### 3.1 空白の所在 エージェント側の安全設計には既に精緻な語彙が存在する。 - **assurance contract(保証契約)** `Ck = (Tk, Rk, Gk, Uk, Bk)` — 許可ツール面・必須証拠・迂回不能ゲート・ロールアウトプロトコル・予算。契約充足は `τ ⊨ Ck` という測定可能な主張へ落とされる (Source: [[エージェント運用安全性]], [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]])。 - **verification wall(検証の壁)** — すべての書き込み行動が健全なゲートを通る場合にのみ、実行された書き込み列がポリシー `Π` と不変条件 `I` を満たす。設計パターンとしては「提案とコミットの間の迂回不能な界面」 (Source: [[エージェント運用安全性]])。 - **[[Transactional No-Regression]]** — Checkpoint → Execute → Commit/Abort。「試行が現状の信頼性指標を後退させない」ことを Alpern–Schneider の安全性として形式化する (Source: [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]])。 ところが、**この語彙と SLO/エラーバジェットが接続している箇所は wiki 全体で 2 点しかない**。 1. verification wall のゲートが参照する不変条件 `I` の候補として SLO・エラーバジェット・blast radius が挙がるが、「NetOps の到達可能性/隔離ほど明確に**チェッカ化できない**ため、サービス層の verification wall はどこまで健全たりうるか」と留保される (Source: [[エージェント運用安全性]])。 2. TNR の重大度関数 `µ(s) = w1·|A| + w2·|V| + w3·|L|`(`A` はアラート、`V` は SLA 違反、`L` は容量損失)の第 2 項が **SLA 違反数**である。SLO 体系ではなく、SLA 違反件数が行動可否判定の目的関数の一項として現れるにとどまる (Source: [[Transactional No-Regression]])。 対称的に、**エージェント自身に SLO を設定する(成功率を SLI とし、エラーバジェットを割り当てる)という設計は、関連 concept のいずれにも記載がない**。 ### 3.2 空白を埋めかけている唯一の議論 例外が 1 件ある。Yoshikawa は、**エラーバジェットが残っている間は AI 補助による自動承認を許容し、消費されれば人間承認へ戻す**という運用を示した。これはエラーバジェットを「リリース停止/許可」だけでなく **「AI に任せる権限レベル」の制御信号**として使う拡張である (Source: [[エラーバジェット]], [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]])。 この一点が重要なのは、[[SRE AI Autonomy Levels]] が抱える最大の欠落と正確に噛み合うからである。Google の L0〜L4 は Monitor / Investigate / Mitigate / Actuate / Self-Direct の 5 軸を人間から自動へ移す度合いでレベルを定め、L1 は緩和の判断と実行の両方を人間が保持し、L2 は判断のみを人間が保持する。昇格基準は L0→L1 がツールの可用性と採用、L1→L2 が信頼できる識別と安全な経路、L2→L3 が実証された精度・信頼・堅牢な安全制御、L3→L4 が多段の解決と end-to-end の管理能力と定性的に置かれるが、ページ自身が「**昇格を判定する定量基準は本ソースでは未明示**」と認めている (Source: [[SRE AI Autonomy Levels]], [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]])。 エラーバジェットのバーンレートは、その定量基準の最有力候補でありながら、まだ誰もそう定式化していない。バンバン制御からプロポーショナル制御へという [[エラーバジェット]] の設計思想は、二値の「AI に任せる/任せない」でなく連続的な自律度調整と構造が同型である。 さらに [[エラーバジェット]] 自身が未解決の問いとしてこう書いている。 > エラーバジェットは人間の開発チームと SRE の協調を前提とする。[[agentic SRE]] でエージェントが自律的に緩和する場合、エラーバジェットの**消費判断と凍結判断は誰が/何が行うか**。 ### 3.3 空白を埋める設計が直面する三つの壁 **壁 1 — 能力天井とゲート強度のトレードオフ** エージェントの能力天井は 6 割前後である。契約 `(Rk, Gk, Bk)` を厳しくすれば refusal storm(過剰な拒否)、緩めれば over-permissive execution(過剰な許可)となる。「能力が低いまま安全な契約は成立するか」が未解決の問いとして立っている (Source: [[エージェント運用安全性]], [[agentic SRE]])。 **壁 2 — 人間側のゲートが形骸化する** 「AI 出力を検証せず承認するだけ」という**ゴム印問題**が AI 関連侵害の 97% の原因として報告された。ジュニアが手動スキルを学ばず、シニアが過剰依存でスキル退化するという二重のスキル劣化を伴う。verification wall は技術的には迂回不能だが、**組織慣行としては形骸化しうる** (Source: [[エージェント運用安全性]], [[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]])。二値の凍結判断を人間の承認に依存させる設計はここで破れる。 **壁 3 — エージェントの失敗が沈黙する** AgentChaos の障害注入では、警告なしの誤出力である **Silent 失敗が AutoGen で 65.71%、Mini-SE で 61.09%** に達した。頑健性はモデル能力でなくシステム実装に依存し、パイプラインパターンが最も脆く反復パターンが最も頑健である (Source: [[エージェントシステム運用]], [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]])。SLI の分母に載らない失敗が過半を占める状況では、成功率型 SLI そのものが機能しない。 加えて **過剰介入(over-control)** という失敗モードがある。Hurt ケースは平均 29.3 回、Helped ケースは 11.3 回の介入で、同じガードが必須行動の周りで繰り返し発火するとエージェントが行動を確定できず再計画を続ける (Source: [[エージェント修復]])。ゲートを増やせば安全になるという単純な関係は成り立たない。 ### 3.4 エージェント自身を測る指標の現状 SLO の語彙ではないが、エージェントの信頼性を測る指標群は既にある。 - **安全性指標**: PolicyViolations・UnnecessaryActions・RollbackRate。目的は「安全な成功と単なるタスク完了を区別する」 (Source: [[エージェント運用安全性]])。 - **停止判断の採点**: `StopScore = Pr(stop|証拠不十分) − Pr(stop|証拠十分)`。早すぎる結論を罰する (Source: [[エージェント運用安全性]])。 - **診断と回復の乖離**: PROBE は Top-1 診断精度 65.37% に対し回復率 21.79%。「正しい診断は実行可能な回復の必要条件だが十分条件ではない」 (Source: [[エージェント修復]])。 - **産業実装の効果**: Bian Que は KuaiShou の 6 ヶ月本番デプロイでアラート量 75% 削減・RCA 精度 80% (Source: [[エージェントシステム運用]])。 これらを SLI として束ね、SLO とエラーバジェットを載せる作業は未着手である。 --- ## 4. 長期構想 — SLO の主体が移る [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]] は、2040 年代の個別化アプリケーションでは信頼性・コスト・変更速度の均衡点を**利用者と AI が対話的かつ体験的に決める**と描く。人間が AI に「適切な信頼性」を事前に宣言することが難しいため、利用者が「できるだけ落ちない」「軽い」「高すぎない」といった希望を出し、AI が信頼性目標を下げる案や短時間の劣化体験を提示して均衡点を探る。SLO の主体が事業者から利用者 + AI へ移る (Source: [[セルフクラフト]])。 [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]] はこれを一段進める。利用者・情報システム・開発運用者の間にエージェントネットワークを張り、「利用者の未表現の主観や感情」「テレメトリ信号の変化の意味」「運用者の経験に由来する直観」を流通させる。**変更 → 外乱 → 不満**という因果をコンテキストとして扱い、深層学習の自動微分のように **SLI/SLO をフィードバック循環から自動的に調整し続ける**。工学への要求は要素還元から創発性へ、客観性から主観性へ、標準化志向から個別化志向へ、そして**事前性から事後性へ**転換する。 > [!warning] 自動化のアイロニーが待ち構えている > Bainbridge の**監視のアイロニー** — 自動制御系はオペレータより良い判断ができるから導入されたのに、そのオペレータに自動制御系の正しさを監視させるのは不可能な課題である。[[自動化のアイロニー]] はこれを SLO 文脈へこう翻訳する。「利用者が AI の提案した信頼性・コスト均衡点を評価できるか。専門オペレータでない利用者が、**短時間の体験だけで長期的な信頼性リスクを判断できるか**」。 > > 同型の警告が [[自律コンピューティング]] の原典にもある。自律システムは人間の誤りを大幅に減らす一方、**目標指定における人間の誤りの帰結を大きく増幅する**。ポリシーの誤りは構成と振る舞いへの間接的な効果を通じて現れるため、追跡と是正が非常に困難になる (Source: [[@2003__Computer__The Vision of Autonomic Computing]])。SLO を自動調整ループに委ねるとき、誤った SLO は誤ったまま増幅される。 坪内自身も、現行 AI の延長線上では自動化の皮肉から免れられない可能性を指摘する。根拠は METR の「人間が 31 分要するタスクを 80% の精度で実行可能」という現状評価と、運用が数年単位の一貫したコンテキスト維持を必要とする複雑なタスク集合であるという判断である (Source: [[自動化の皮肉]], [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]])。 そして Brush の指摘が全体を締める。**エージェント導入は緩和対象を減らすだけでなく複雑性を足す** — 非決定的に振る舞う別システムを既存システムに加えるため、系全体は元より複雑になる (Source: [[agentic SRE]])。DORA 2024 の「AI 採用 +25% とデリバリー安定性 −7.2%・スループット −1.5%」、DORA 2025 の「スループットが反転しても不安定さの悪化は継続」という数値は、この警告の経験的裏づけとして読める (Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]])。 --- ## 5. 空白の定義 — 次に埋めるべき五つ 以下の 5 点は互いに独立ではなく、**「SLO を人間同士の社会契約から、人間と機械の権限契約へ拡張する」という単一の未解決課題**の 5 つの側面である。 1. **エラーバジェットをエージェント自律度のゲートに使う設計**。Yoshikawa の 1 件を除き前例がない。[[SRE AI Autonomy Levels]] の昇格定量基準の空白と正確に対応する。 2. **SLO/エラーバジェットを機械判定可能な不変条件へ変換する方法**。[[エージェント運用安全性]] が問いとしてのみ提起している。到達可能性や隔離のようなチェッカ化しやすい性質と、SLO のような集約的・時間依存の性質の差をどう埋めるか。 3. **エージェント自身への SLO 設定**。Silent 失敗率が 6 割を超えうるという前提で成功率型 SLI をどう設計するか。§3.4 の指標群を SLI として束ねる作業は未着手である。 4. **エージェントが自律緩和したときのバジェット消費判断・凍結判断の主体**。[[エラーバジェット]] の未解決の問い。エージェントが自らのバジェット消費を判定する場合の利益相反をどう扱うか。 5. **ハルシネーション率をユーザー幸福の 6 フレーバーのどこへ置くか**。[[SLI-SLO教科書]] の未解決課題。Accuracy に含めるのか、7 番目のフレーバーが要るのか。 有望な足がかりは [[サービスレベル目標]] が既に記録している観察である。Mogul+Wilkes の SLE(サービスレベル期待)/CBE(顧客挙動期待)による「法律家的思考から統計家的思考へ」の転換は、agentic SRE の assurance contract と「契約 = 期待 + 帰結」という点で同型である。SLE/CBE がプロバイダと顧客の双方向期待管理を定式化したのと同じ構造で、人間とエージェントの双方向期待管理を定式化できる可能性がある (Source: [[サービスレベル目標]], [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]])。 --- ## 関連 - 概念: [[サービスレベル目標]] / [[エラーバジェット]] / [[agentic SRE]] / [[SRE AI Autonomy Levels]] / [[エージェント運用安全性]] / [[Transactional No-Regression]] / [[エージェントシステム運用]] / [[エージェント修復]] / [[LLMアプリケーション信頼性]] / [[GenAI オブザーバビリティ]] / [[LLM評価]] / [[LLM推論]] / [[Goodput]] / [[ML Productivity Goodput]] / [[自動化のアイロニー]] / [[自動化の皮肉]] / [[自律コンピューティング]] / [[セルフクラフト]] / [[AIOps]] - 質問: [[SLI-SLO教科書]] / [[インシデント対応の教科書]] - 関連 MOC: [[structures/SRE - MOC]] / [[structures/LLM4SRE - MOC]] ## 出典 - [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]](AI サービスの SLI 拡張、エラーバジェットによる AI 承認権限の制御、DORA 数値) - [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]](TTFT/ITL/Goodput、SLO ベース最適化ループ) - [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]](LLM による SLI/SLO 草稿生成とその限界) - [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]](SRE AI Autonomy Levels L0–L4) - [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]](assurance contract、verification wall) - [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]](Transactional No-Regression、重大度関数) - [[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]](ゴム印問題、trust-for/verify 二分法) - [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]](Silent 失敗率) - [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]](セルフクラフト、SLO 主体の移行) - [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]](なめらかなシステム、SLI/SLO の事後的自動調整) - [[@2003__Computer__The Vision of Autonomic Computing]](目標指定の脆弱性) - [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]](SLE/CBE)