Skip to Content
Docs05. 運用AI 品質の SLO 設計
上級reliabilitysloobservability更新: 2026-07-08この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

AI 品質の SLO 設計

この記事の目的

「品質はなんとなく監視している」から「目標を宣言し、予算で管理する」へ進めるようになります。非決定的な AI システムに対して、SLI(測る指標)と SLO(その目標)を設計し、エラーバジェットで「いつ改善を優先し、いつ機能追加を止めるか」を判断できる状態がゴールです。

対象読者

前提知識

本文

概要: 分担と「目標と予算の運用」

対象正本本記事
計測基盤(何をどう記録するか)可観測性とトレーシング—
本番の品質シグナル・ガードレールモデルの判断の外側でコードとして強制される制御。入力・出力・アクションの 3 層に配置し、プロンプトでの指示(お願い)と区別される。メトリクスオンライン評価と A/B テスト—
judge による採点の設計・検証LLM-as-a-Judge—
発火後の対応インシデント対応—
品質・信頼性を目標として宣言・予算運用する本記事SLI 候補・SLO 水準・エラーバジェット・SLA 昇格

SLI(測る指標)を計測する基盤は 可観測性とトレーシング が、その品質シグナル自体は オンライン評価と A/B テスト が正本です。本記事は、それらを目標(SLO)として宣言し、エラーバジェットで運用する方法論を扱います。SRE の SLO/SLI の一般論は既存の確立した文献に譲り、AI 固有の面に絞ります。

AI の SLI 候補と測定の信頼性

SLI(Service Level Indicator: サービスの良し悪しを表す指標)は、AI では「レイテンシ・エラー率」だけでは足りません。品質そのものを指標にする必要があります。

SLI 候補測り方注意
タスク成功率状態検証・完了率(代理指標)タスクに合った成功定義が要る
回答品質の合格率本番出力をサンプリングし judge で採点した合格割合judge の較正モデルの言う確信度と実際の正解率が一致している性質。「確信 80% のケースが実際に 8 割正解する」なら較正が良い。LLM は過信に寄りやすく、較正はモデル更新でずれるため再測定が要る。が前提(後述)
幻覚モデルが事実でない内容をもっともらしく生成する現象。「もっともらしい続きを生成する」という学習目的の自然な帰結であり、対策は指示の強化ではなく、根拠の外部供給(RAG)・出典要求・検証という構造側にある。率・逸脱率根拠のない回答・制約違反の割合検出手段の網羅性が課題
エスカレーション率人へ回った割合低すぎ(抱え込み)も高すぎ(役立たず)も問題
レイテンシ・コストの複合p95 レイテンシ、リクエスト単価品質 SLI と併せて見る

判定の信頼性が SLI の信頼性を決めます。 judge ベースの SLI(サンプリング採点の合格率)は、その judge が較正されていなければ数字が信用できません(LLM-as-a-Judge の judge 検証、信頼度と較正(calibration))。「品質 SLI が 95%」の前に「その 95% は正しく測れているか」を確かめます。

SLO の水準設定: 100% を狙わない

SLO(Service Level Objective: SLI の目標値)は、現実的な水準に設定します。

  • ベースラインから始める: まず現状の SLI を測り、それを起点に「維持すべき/引き上げるべき」水準を決めます。目標を先に決めて現実と乖離させないことです
  • 100% を目標にしない: 非決定的な AI で「品質 100%」は不可能で、そこに近づけるコストは急激に増えます。「必要十分な水準」を関係者で合意します。過剰品質はコストの無駄です
  • タスクの影響度で変える: 誤答が重大なタスク(医療・金融)は高い SLO を、影響の小さいタスク(下書き)は緩い SLO を、と使い分けます
  • 複数 SLI を組み合わせる: 品質 SLO とレイテンシ・コストの SLO を併記します。片方だけ追うと、品質のためにコストが暴走する、が起きます

エラーバジェットの運用

SLO の裏返しがエラーバジェット(error budget) — 「許容できる失敗の量」です。SLO が 99% なら、1% が予算です。

  • 予算で優先順位を決める: エラーバジェットが残っているなら、多少のリスクを取って機能追加・変更を進めてよい。使い切ったなら、新規変更を凍結し、品質改善に人を回す — という判断の型を作ります
  • AI 特有の消費源: モデル更新・プロンプト変更・知識源の劣化で、品質バジェットは静かに消費されます。これらの変更を「バジェットを消費する行為」として扱います(バージョニングとモデル更新追従)
  • 予算超過は非難でなく判断のトリガー: バジェットを使い切ったら「誰が悪いか」ではなく「何を止め、何を直すか」を決めます。SLO・エラーバジェットは、感情論を数字の判断に置き換える道具です

対外 SLA への昇格

SLO(内部目標)と SLA(Service Level Agreement: 顧客との契約)は別物です。内部 SLO を対外約束に昇格させるときは慎重にします。

  • 約束できることとできないこと: レイテンシ・可用性は約束しやすい一方、「回答が正しい」を SLA で約束するのは危険です(非決定的で、外部要因に左右される)。何を契約に載せるかは、測定の信頼性と統制可能性で判断します
  • SLA は SLO より緩く: 対外約束は、内部目標より余裕を持たせます(内部で 99% を目指し、対外は 95% を約束する、など)。バジェットの緩衝を持たせないと、内部の小さな劣化が契約違反になります
  • API 契約との接続: 機械間の契約でメータリング・ステータスを約束する設計は エージェントの API 設計 が扱います。SLA はその品質面です

モデル更新・プロンプト変更と SLO

AI の SLO は、変更のたびに揺れます。

  • モデル更新・プロンプト変更は SLI を動かします。変更前後で SLO を割っていないかを回帰評価で確認し(回帰テストと CI 組み込み)、SLO を割る変更は出さない・段階リリースで確かめる、を関門にします
  • SLO・エラーバジェットを、変更の可否判断(バージョニングとモデル更新追従)に組み込みます。「バジェットがあるから出す/ないから止める」を機械的に回せると、リリース判断が属人的でなくなります

実務での注意点

アンチパターン

  • レイテンシ・エラー率だけを SLI にする → 品質の劣化(幻覚・逸脱)が SLO に現れず見逃す → 品質 SLI(サンプリング採点の合格率など)を含める
  • 未較正の judge の合格率を SLI にする → 数字が実態を表さず、間違った安心を与える → judge を検証・較正してから SLI に使う
  • SLO を 100% に設定する → 到達不能な目標で常に「違反」になり、判断に使えない → ベースラインから現実的な水準を合意する
  • エラーバジェットを判断に使わない → 品質が落ちても機能追加を続け、劣化が蓄積する → バジェット枯渇で変更を凍結し改善に回す型を作る
  • 内部 SLO をそのまま対外 SLA にする → 小さな内部劣化が契約違反になる → SLA は SLO より緩く、約束できる指標に絞る

チェックリスト

  • 品質を表す SLI(タスク成功率・採点合格率など)を、レイテンシ・コストと併せて定義した
  • judge ベースの SLI について、judge の較正・検証を確認している
  • SLO をベースラインから現実的な水準で設定した(100% を狙っていない)
  • タスクの影響度で SLO の水準を変えている
  • エラーバジェットを定義し、枯渇時に変更を凍結する判断の型がある
  • モデル更新・プロンプト変更をバジェット消費として扱い、リリース判断に組み込んでいる
  • 対外 SLA は内部 SLO より緩く、約束できる指標に絞っている

関連トピック

参考資料

TODO・未確認事項

AI のためのデータガバナンスAI システムのカオスエンジニアリング