AI SLO／Error Budget運用

AI/Agentの信頼性運用では、単一の「成功率」やprovider uptimeをSLOと同一視せず、利用者が経験するcritical journeyごとにSLI、SLO target、budgeting method、window、error-budget policyを固定します。error budgetは観測された失敗を許容する枠であり、品質保証や免責ではありません。

最低限、service/user journey、SLI numerator/denominatorまたはthreshold、target、budgeting method、time window、in-scope/out-of-scope traffic、data source/query、owner、policy actionをversion管理します。

OpenSLOのような仕様ではOccurrences、Timeslices、RatioTimeslicesでbudget calculationが異なります。同じtarget値でもbudgeting methodやwindowが違えば同じSLOではありません。

Agentではinfrastructure availabilityだけでなく、task-level outcomeを別SLIとして設計します。候補にはtask completion、tool correctness、policy violation、grounded answer acceptance、latency、handoff成功、side-effect correctnessを含めます。

LLM-as-judgeやhuman reviewをSLIへ使う場合は、judge/model/version、rubric、sampling、abstention、disagreementを記録し、provider uptimeとend-to-end task successを混同しません。

error budgetは原則としてSLO targetと観測結果から算出する運用制御量です。100% reliabilityを無条件な目標にせず、product/user riskに応じてtargetを決めます。

budget消費時のrelease freeze、rollback、capacity/reliability work優先等はorganization policyとして明示します。Google SREの例示policyをそのまま全組織へ移植しません。

残budgetだけでなくburn rateを監視します。burn rate 1xは、同じ消費速度がwindow全体で続けばbudgetをちょうど使い切る速度です。

短いwindowだけではspikeへ過敏、長いwindowだけでは検知が遅れるため、multiwindow/multi-burn-rate alertを候補にします。Google SREの14.4x/1h+5m、6x/6h+30m等は例示値であり、organizationのSLO/window/page policyへ再計算します。

「budgetが減らない」を健全性の証拠にしません。SLI queryがfailureを捕捉していない、no-data、aggregation、scope misclassification、sampling driftでも見かけ上burnしない場合があります。

SLI definition変更はSLO revisionとして扱い、query/config hash、data freshness、missing-data semanticsをreadbackします。

pageは即時人間対応が必要なbudget threatへ、ticketは遅いburnや改善課題へ分けます。alert発火、budget exhaustion、release freeze、incident severityは別状態です。

policy actionは自動化可能ですが、data-quality異常やscope errorで誤freezeしないよう、source freshness/readbackとbreak-glass/approvalを設計します。

wrong SLI、proxy metric、denominator drift、no-dataをgood扱い、sampling bias、judge drift、model alias drift、traffic mix変化、rolling-window recoveryの誤読、low-traffic volatility、aggregation mismatch、dependency scope漏れ、retryによる二重計上、tool partial success、policy action誤発火、budget reset境界、dashboard zoom/aggregation差、provider SLAとの混同を想定します。

本項は2026-10-06時点のGoogle SRE、OpenSLO、Nobl9公開資料に基づくprovider-neutral運用境界です。organization telemetry/SLO backendへのlive mutationは未実施です。

AI/AgentのSLOは、利用者が経験するcritical journeyについてSLI、target、budgeting method、window、scopeを固定し、error budgetとburn rateで運用します。provider uptimeや単一のLLM評価値だけをend-to-end SLOにせず、data qualityとmissing-data semanticsを監視し、budget消費時のrelease・rollback・reliability-work方針を組織policyとして明示します。

organization critical journeys、SLI source/query、target/window、budgeting method、LLM judge/human-review設計、missing-data policy、traffic scope、dependency map、burn alert thresholds、release-freeze/rollback policy、owner/escalation、low-traffic strategy、tenant realized stateは未確認です。