生成AIアプリを本番投入すると、落ちていないのに体験が劣化するという新しい問題が現れます。応答は返るのに、幻覚が増える、根拠が薄い、フォーマットが崩れる。従来の稼働率だけでは信頼性を語れません。
そこで必要になるのが、生成AI向けに再設計したSLO(Service Level Objective)・SLI(Service Level Indicator)・エラーバジェットです。この記事では、LLM本番運用で何を測り、どの目標を置き、どう改善と機能追加を両立させるかを整理します。情報確認日は2026年9月23日です。
SLIを最初から10個も並べると、運用が止まります。次の判断表に沿い、事業影響が大きい2〜3指標から始めます。
| 事業影響 | 最初に置くSLI | 目標(SLO)の例 | 目標を割ったときの初動 |
|---|---|---|---|
| 応答が返らない | エンドポイント可用率 | 直近30日で99.5%以上 | フォールバックとレート制御を再点検 |
| 応答が遅い | p95応答時間 | ユーザー体感10秒以内 | プロンプト圧縮、キャッシュ、モデル軽量化 |
| 事実が違う | 幻覚率(サンプル評価) | 週次評価で5%未満 | プロンプト・RAG・評価データの見直し |
| 出力形式が崩れる | スキーマ違反率 | 1%未満 | 出力バリデーションと再試行の追加 |
| ユーザーが直す | ユーザー修正率 | 30日移動平均で20%未満 | 業務プロンプトとナレッジ更新 |
まず1〜2行を選び、既存の監視基盤で測れる形に落とします。
SLIは「何を測るか」、SLOは「その指標にどの目標を置くか」、エラーバジェットは「目標を割っても許される猶予」です。従来SRE(Site Reliability Engineering)で使われてきた仕組みを、LLM向けに読み替えます。
生成AIでは、動く・止まるだけでなく、意味が壊れる障害が加わります。そのため、SLIの範囲を可用性・遅延だけに絞ると、静かな品質劣化を見逃します。
| 用語 | 意味 |
|---|---|
| SLI | 実際に測る指標。例: 可用率、応答時間、幻覚率 |
| SLO | 指標にどの水準を目標として置くか。例: 99.5%以上 |
| エラーバジェット | SLOを割ることが許される残量。例: 30日で0.5%まで |
| ゴールデンデータセット | 品質評価に使う正解付きの評価用データ |
| ガードレール | 出力の妥当性、禁止語、範囲を機械的に検査する仕組み |
生成AIアプリは、モデル更新、プロンプト変更、ナレッジ更新のたびに挙動が動きます。稼働率だけを見ていると、体験劣化を経営指標に翻訳できません。
現場から「なんとなく最近品質が落ちた」という声が出た時点で、既に営業機会や顧客満足を失っています。数値で目標と残量を語れる仕組みが必要です。
SLI候補は「使う人が困る順」に並べます。全てを常時測る必要はありません。まず自動計測できる指標を選び、後から人手評価が必要な指標を加えます。
| 分類 | 一言でいうと | 例 | 誰が困るか |
|---|---|---|---|
| 可用性 | 反応が返るか | エンドポイント可用率 | 全ユーザー |
| 遅延 | 反応の速さ | p95応答時間 | 対話型ユーザー |
| 品質 | 中身が正しいか | 幻覚率、根拠付き応答率 | 業務利用者 |
| 形式 | 出力の型が守られるか | スキーマ違反率 | 後続システム |
| 定着 | 使い続けられるか | ユーザー修正率、再質問率 | 現場と管理者 |
| 比較軸 | 確認すること | 実務上の意味 |
|---|---|---|
| 計測方法 | ログか、評価データか、ユーザーフィードバックか | 常時計測できるか、週次評価かを決める |
| 集計単位 | ユーザー単位、リクエスト単位、機能単位 | 責任範囲と改善アクションが変わる |
| データ保持 | ログとサンプルをどこまで残すか | 監査・改善・プライバシー要件に影響する |
| 変動要因 | モデル更新、プロンプト、RAG、ユーザー層 | 目標割れの原因分析につながる |
新しいSLIを追加するときは、「誰が」「何のために」「どの頻度で」見るかを決めてから加えます。
SLOは、ベンチマークの上限値ではなく、事業として約束できる水準に置きます。次の4ステップで決めます。
エラーバジェットは、SLOを割ることが許される残量です。バジェットが残っている間は機能追加を続け、使い切ったら改善に集中します。運用ルールとして先に決めます。
現場が回らない仕組みは形骸化します。開始前に最低限の準備を整えます。
SLO・SLI・エラーバジェットは万能ではありません。次の限界を先に共有しておきます。
※LLM関連サービスの料金、データ保持条件、提供機能は変更される場合があります。導入前に公式情報で最新条件を確認してください。
SLOやエラーバジェットは、経営指標に翻訳できて初めて価値が出ます。数値だけを追う運用ではなく、業務、データ、クラウド構成、運用責任者を一直線につなぐ設計が重要です。
Blackfordでは、次の観点から生成AI運用の設計と実装を支援しています。
社内のデータ基盤とRAG、監視、評価データを一体で運用したい場合は、DataRoidやDataRoid Cloudの設計視点も参考にしてください。営業や顧客対応領域でSLOを整備したい場合は、SalesRoidが扱う顧客接点データとの接続を先に整理します。
一律の推奨値はありません。まずベースラインを測り、そこから少し厳しい水準に置きます。一般に可用率は99〜99.5%、応答時間は業務ユースで10秒以内、品質SLIは週次評価で幻覚率5%未満を初期目標にする例が多いです。3か月ごとに実績で見直す前提で始めます。
日次リクエスト数が数十件を超え、業務判断や顧客対応に使う段階なら必要です。まず可用率と応答時間の2指標だけを測り、SLOと簡易なエラーバジェットを1枚のドキュメントに書くところから始めます。監視は既存のAPM(応用性能監視)ツールで代用可能です。
代表的な質問と正解を集めたゴールデンデータセットで、週次または月次にサンプル評価します。人手レビューが基本ですが、LLM-as-a-judgeを補助として使う事例も増えています。ただし判定モデルの偏りが混ざるため、人手レビュー結果と定期的に突き合わせる運用が必要です。
原則は止めます。ただし、事業インパクトが小さい機能や社内試験用の機能まで全部凍結すると、開発が止まって逆効果になります。影響範囲を絞った凍結ルールを先に決めておき、消費理由が判明した時点で対象を確定します。
可用性・遅延のSLOは既存SREで運用できますが、幻覚率などの品質SLIは業務担当者やAI担当と共同運用が必要です。SLOの見直しは、経営、現場、開発、SREが同席する定例で扱うと形骸化しにくくなります。
生成AIアプリの信頼性は、稼働率だけでは語れません。可用性、遅延、品質、形式、定着のうち事業影響が大きいSLIを選び、現実的なSLOとエラーバジェットに落とし込みます。改善と機能追加を両立させるためには、凍結・回復ルールを先に文書化しておくことが重要です。
まずは1〜2指標のスモールスタートから始め、3か月ごとに実績で見直します。自社の業務やクラウド構成に合わせた運用設計に迷う場合は、業務課題を整理したうえで専門家に相談してください。
＼生成AI運用のSLO設計とデータ基盤を相談できます／ Blackfordに相談する
