SRE for AI agents ─ SLO / SLI と error budget

2026/05/10

SRE for AI agents ─ SLO / SLI と error budget

ch1 で「6 つの運用の壁」を提示した。これらに統一的な視座を与えるのが、SRE（Site Reliability Engineering）の枠組みだ。本章では、Google SRE 本の古典概念（SLO / SLI / error budget）を AI エージェント文脈に翻訳する。

なぜ古典 SRE だけでは足りないか

古典の SRE は「サーバーが応答するか / しないか」を白黒で測る。代表的な SLI は：

Latency：応答時間
Availability：稼働率
Error rate：エラー率
Saturation：リソース飽和度
Throughput：スループット

これらはWeb サーバー / DB / APIには完全に通用する。だが AI エージェントには、「動いているのに間違っている」状態が日常的にある。

古典 SRE の白黒：
- Latency 200ms：✅ OK
- Availability 99.9%：✅ OK

AI エージェントの灰色：
- 応答時間 1.5s（OK）+ 応答内容が hallucination：⚠️ 動いているが壊れている
- 99.9% 稼働 + 評価指標が drift で 15% 落ちた：⚠️ 動いているが品質劣化

つまり AI エージェントは「動き続けながら壊れる（fail while continuing to work）」。これを捕捉するには、新しい SLI が必要だ。

エージェント特有の 4 つの SLI

業界で 2026 までに収束した、AI エージェント向けの SLI が 4 つある。

1. Task Completion Rate（TCR）

タスクが意図通りに完了した比率。

TCR = (意図通りに完了したタスク数) / (試行されたタスク数)

古典 Availability に近いが、「応答した」ではなく「正しく完了した」を測る
multi-step task では end-to-end と step-level の両方で測る

2. Tool Invocation Efficiency（TIE）

1 タスクあたりのツール呼び出し数 / 想定値。

TIE = (実際のツール呼び出し数) / (想定ツール呼び出し数)

1.0 が理想、2.0 を超えるとループや retry が起きている可能性
$47,000 暴走の検知に直結する SLI

3. Decision Quality Rate（DQR）

意思決定の質。LLM-as-judge や human review で評価。

DQR = (judge / human が「妥当」と評価した出力数) / (全出力数)

LLM-as-judge の閾値は通常 0.85-0.95
production traffic の 5-10% サンプリングが標準

4. Cost per Task（CpT）

1 タスクあたりのトークンコスト。

CpT = (トークン消費量 × 単価) / (タスク数)

「tokens per feature」（第1部 ch9 で言及）と同じ概念
Drift / runaway の早期警告として機能

SLI 一覧（古典 + agentic）

カテゴリ	SLI	目標例	検知できる症状
古典	Latency P95	< 5s	レスポンス遅延
古典	Availability	> 99.5%	サービス停止
古典	Error rate	< 1%	API エラー
agentic	Task Completion Rate	> 90%	タスクの未完了
agentic	Tool Invocation Efficiency	< 1.5×	暴走・retry ループ
agentic	Decision Quality Rate	> 0.85	drift / hallucination
agentic	Cost per Task	<$0.50（例）	Cost runaway

「動き続けながら壊れる」を中核概念に据える

エージェント運用の SLO は、古典 SRE と次の点で違う。

古典 SRE の故障：応答しない、エラー、タイムアウト → 二項対立で検知 エージェントの故障：応答するが質が落ちる、コストが膨れる、誤った判断を続ける → 連続値で検知

これに対応するには、SLI を二項ではなく連続値で設計する。「動いている / 止まっている」だけでなく「どれくらい正しく動いているか」を測る。

SLO 設計のベスプラ

1. 99% を狙うタスクと 90% でいいタスクを区別する

すべてのタスクを 99% で守ろうとすると、コストが破裂する。リスクで分ける。

タスクの性質	SLO 目標例
不可逆操作（決済、本番デプロイ）	TCR > 99.9%, DQR > 0.99
業務クリティカル（顧客向け回答）	TCR > 99%, DQR > 0.95
内部ツール（議事録要約）	TCR > 95%, DQR > 0.85
探索的（リサーチ）	TCR > 90%, DQR > 0.80

2. End-to-end SLO と step-level SLO の両方を持つ

multi-step task では、各 step の SLO を掛け合わせると end-to-end が劣化する。

例：5 step のタスク、各 step の TCR が 99% だとすると、
end-to-end の TCR は 0.99^5 = 95.1%

これを許容できないなら、各 step の TCR を 99.5% 以上に引き上げる必要がある。

3. HITL を含む SLO の組み立て方

HITL を組み込むと SLO の組み立てが複雑になる。

HITL ありタスクの SLO：
- TCR（end-to-end） = 95%
  内訳：
    - エージェントの初期 TCR = 80%
    - HITL 承認後の TCR = 99%
    - 二段で 95.2% になる

注意：
  HITL の SLA（承認まで何時間か）を別途設計する必要
  → ch7 で扱う

Error budget の運用

Error budget とは

99.9% の SLO で 30 日 = 43.2 分の error budgetを消費していい

エージェントの場合：

TCR 99.9% で月 100,000 タスクなら、100 タスクの失敗が許容される
error budget を使い切ったら、新機能 deploy を停止して修正に集中

LLM のハルシネーションを「failure」と数えるか

ここが論争点だ。3 つの立場：

立場 A：すべてのハルシネーションは failure

厳格な定義。DQR を SLI にする
production deploy が頻繁に止まる

立場 B：ユーザーが気づいた / クレームしたものだけ failure

実用的だが、検知が遅い
silent な品質劣化を見逃す

立場 C：online eval で 5-10% サンプリングして statistical な failure rate を出す

バランス型。本作の推奨
DQR の閾値設計で SLO を組み立てる

Production deploy の頻度との関係

error budget が残っている → deploy できる error budget を使い切った → deploy 止めて修正に集中

エージェント特有の難しさ：プロンプト変更も deploy に含む。「ちょっとプロンプトを直す」を毎日やると、それも budget を消費する。

✅ 良い運用：
- プロンプト変更も PR + canary + eval で扱う
- canary 段階で eval が baseline -3% を超えたら自動 rollback
- error budget を週次で見て、足りなければプロンプト変更を凍結

「Hard cap from Day 1」原則

SRE の伝統的な発想は「問題を観測して、徐々に SLO を下げる」だが、AI エージェントでは最初から hard capを入れる。

Hard cap	役割
Per-task cost cap	1 タスク $5 を超えたら kill
Step counter cap	50 step を超えたら停止
Token budget cap	セッション 100K tokens で停止
Round-trip count cap	同じ tool を 5 回連続呼んだら停止

これらは alert ではなく enforcement。$47,000 暴走を防ぐ最低ラインだ。

SLI の実装：観測層と分離する

SLI は 観測ツール（OpenTelemetry / Langfuse / Datadog）から計算する。第1部 ch9 で扱った「ingest / storage / eval」の 3 層分離が、ここで効いてくる。

graph TB
    A[Application]
    OTel[OpenLLMetry / OTel 計装]
    Storage[Langfuse / Datadog]
    Eval[Braintrust / Phoenix]
    SLI[SLI 計算]
    SLO[SLO ダッシュボード]

    A --> OTel
    OTel --> Storage
    OTel --> Eval
    Storage --> SLI
    Eval --> SLI
    SLI --> SLO

各 SLI の出処：

TCR：Eval 層から（成功 / 失敗の判定）
TIE：Storage 層から（ツール呼び出しのカウント）
DQR：Eval 層から（LLM-as-judge）
CpT：Storage 層から（cost breakdown）

❌ アンチパターン：古典 SLI だけで運用する

症状
─────────
- 「99.9% 稼働しているのに、ユーザーから品質クレームが急増」
- Latency も Availability も healthy だが、応答内容が hallucination
- 月末にコスト集計したら想定の 5×

根本原因
─────────
- 古典 SLI（Latency / Availability / Error rate）しか持っていない
- 「動き続けながら壊れる」現象を捕捉する仕組みがない
- DQR / TIE / CpT を測っていない

脱出法
─────────
1. agentic SLI 4 種（TCR / TIE / DQR / CpT）を追加
2. production traffic を 5-10% サンプリングして毎日 eval
3. Hard cap from Day 1（per-task cost / step counter / token budget / round-trip）
4. error budget を週次で見て、足りなければ deploy 凍結

業務投入の観点で重要な 3 点

「動き続けながら壊れる」を中核概念に据える：古典 SLI だけでは捕捉できない。Task Completion Rate / Tool Invocation Efficiency / Decision Quality / Cost per Task の 4 agentic SLI を必ず追加
Hard cap from Day 1：alert ではなく enforcement。$47,000 暴走の防止は最初の設計に組み込む
error budget の運用は週次：プロンプト変更も deploy に含める。budget を使い切ったら deploy 凍結

次章への接続

ch3 では、6 つの壁の最初である **Drift（モデル / プロンプト / データの 3 種）**を扱う。Sonnet 4 / Opus 4 の 2026-06-15 retire、prompt cache TTL silent regression、入力分布ドリフトの検知手法を実装の解像度で扱う。

この章のまとめ

古典 SRE は AI エージェントには不十分：「動き続けながら壊れる」を捕捉する SLI が必要
agentic SLI 4 種：Task Completion Rate / Tool Invocation Efficiency / Decision Quality Rate / Cost per Task
SLO はリスクティアで分ける：99.9% / 99% / 95% / 90% の階層
error budget の運用に「プロンプト変更」を含める：それも deploy
Hard cap from Day 1：per-task cost / step counter / token budget / round-trip。alert でなく enforcement
観測層は ingest / storage / eval の 3 層分離：第1部 ch9 で示した設計が SLI 計算で効く