LLMアプリは、動くだけでは本番運用に乗りません。可用性・レイテンシ・コストの目標値を先に決めないと、運用後に「遅い」「高い」「止まる」のうちどれを優先して直すかが揺れます。
本記事では、LLMアプリのSLO（Service Level Objective、サービスレベル目標）設計を、本番運用前に決めるべき指標と判断軸、運用後の見直し手順として整理します。
LLMアプリのSLO設計｜可用性・レイテンシ・コスト目標を本番運用前に決める手順
画像: Generated by OpenAI via Codex
この記事でわかること
本番運用前に「何を、どのレベルで保証するか」を先に決めるための、次の論点を扱います。
- LLMアプリにおけるSLI/SLO/エラーバジェットの意味と通常Webサービスとの違い
- 可用性・レイテンシ・コスト目標を決める判断軸
- 本番運用前と運用開始後で見るべき指標
- SLOを守れない場合の優先順位と運用上の打ち手
- 中堅企業がSLO設計を始める際の最小構成
結論サマリー：本番前に決める3つの目標値
LLMアプリのSLOは、最低でも次の3軸で1つずつ目標値を持つのが起点になります。
| 観点 | 最初に決める目標 | 確認すること | 次の行動 |
|---|---|---|---|
| 可用性 | 月次成功率の下限（例: 99.0%） | 失敗の定義（タイムアウト、フィルタ、内容エラー）が揃っているか | 失敗パターン別ログを取る |
| レイテンシ | TTFTとE2Eの目標値 | ユーザーが許容できる体感時間に揃っているか | 計測点とパーセンタイルを決める |
| コスト | 1リクエスト平均コストと月次上限 | モデル選択・キャッシュ・出力長で動くか | コスト計算式と上限超過時の挙動を決める |
3軸すべてを同時に最高水準にはできません。守る順番と、許容できる劣化幅をあらかじめ決めることが、SLO設計の中心です。
SLI・SLO・エラーバジェットとは
SLO設計には、関連する3つの言葉が出てきます。先に意味を揃えます。これらの概念はGoogleのSRE Bookで定義され、その後Webサービス運用の共通言語として広く使われています（参考: Google SRE Book - Service Level Objectives）。
- SLI（Service Level Indicator、サービスレベル指標）は「何を測るか」を指す
- SLO（Service Level Objective、サービスレベル目標）は「どこまで守るか」を表す
- エラーバジェット（許容できる失敗量）は「どこまで失敗してよいか」を表す
| 用語 | 意味 | LLMアプリでの例 |
|---|---|---|
| SLI | 計測する指標 | 月次の成功応答率、TTFTの95パーセンタイル |
| SLO | 守る目標値 | 月次成功率99.0%以上、TTFT 95%が2秒以内 |
| エラーバジェット | 許容できる失敗量 | 月次1.0%まで失敗してよい |
SLOは「100%」を目指すための言葉ではありません。100%を狙うと、改善コストが過大になり、変更を入れにくくなります。
少しの失敗を許容することで、改善サイクルを保つのがSLOの本旨です。LLMアプリでは、SLOを「最低限維持する品質ライン」として扱い、その下回りを検知したらすぐ原因を切り分けます。
なぜ今LLMアプリのSLO設計が重要か
LLMアプリは、通常のWebサービスよりばらつきが大きく、コストが見えにくいのが特性です。SLOがないと、運用判断のたびに「直すべきか、許容するか」が属人化します。
特有の難しさは次の3つです。
- 応答品質が確率的で、同じ入力でも結果が変わる
- レイテンシがモデル提供側の混雑に影響される
- 1リクエストあたりのコストが入力長・出力長で動く
これらは、可用性・レイテンシ・コストの3軸のうち、どれかが想定外に悪化することを意味します。
先に目標値と優先順位を決めないと、運用後の対応が場当たり的になります。「重いモデルに戻す」「キャッシュを切る」が積み重なり、原因を追えなくなります。
可用性目標を決める判断軸
可用性は「成功したリクエストの比率」で測ります。LLMアプリでは、失敗の定義を先に決めることが起点です。
失敗に含めるかを判断する候補:
- タイムアウト
- モデル提供側のエラー応答（5xx、レート制限）
- 安全フィルタによる拒否
- 出力フォーマットが要件を満たさない
- ユーザーが「役に立たなかった」と明示したフィードバック
最初から全部を可用性指標に含める必要はありません。業務上「使えなかった」とみなす範囲に絞ります。
例えば、社内ナレッジ検索なら「タイムアウトと5xx」を可用性指標にします。出力品質はオンライン評価で別管理にする、というように分けます。
目標値は、業務影響と利用頻度で決めます。
| 用途 | 目標可用性の目安 | 月次ダウンタイム換算 |
|---|---|---|
| 社内ナレッジ検索、要約 | 月次99.0%前後 | 約7時間 |
| 営業支援、顧客対応のアシスト | 月次99.5%前後 | 約3.5時間 |
| 顧客向け公開機能 | 月次99.9%以上 | 約43分 |
ダウンタイム換算は意思決定者の体感共有に役立ちます。これらは目安です。社内合意の前に、「失敗時にどの業務が止まるか」を一度棚卸ししてから決めます。
レイテンシ目標を決める判断軸
レイテンシ目標は、TTFT（最初のトークンが返るまでの時間）とE2E（全応答が返るまでの時間）を分けて持ちます。
| 指標 | 何を測るか | 影響する体感 |
|---|---|---|
| TTFT | 最初のトークンが返るまでの時間 | 反応の速さ、ストリーミングの効果 |
| E2E | 応答が完了するまでの時間 | 次操作までの待ち時間 |
| キュー待ち | 内部キューでの滞留時間 | 集中時の体感劣化 |
目標値はパーセンタイル（値を小さい順に並べたとき◯%目に位置する値）で持ちます。平均値だけだと、外れ値が見えません。
- TTFT: 95%が◯秒以内
- E2E: 95%が◯秒以内、99%が△秒以内
- キュー待ち: 95%が◯ミリ秒以内
ストリーミング応答が前提の用途では、TTFTが体感を強く左右します。要約や検索など「完結したテキストが欲しい」用途では、E2Eが優先されます。
目安として、対話用途ではTTFT 1〜2秒、要約・検索ではE2E 3〜6秒あたりから議論を始め、利用シーンで調整します。具体値は実測と社内合意で決めます。
レイテンシ目標を決めた後、それを構造的に削る打ち手はLLMアプリのレイテンシー最適化で扱っています。
コスト目標を決める判断軸
LLMのコストは、入力トークン数、出力トークン数、選択モデル、キャッシュ利用率で動きます。SLOの一部として、コストも目標を持たせます。
最低限決める3点:
- 1リクエストあたり平均コストの上限
- 月次総コストの上限
- コストSLO違反時の対応（モデル降格、キャッシュ強化、機能制限）
コスト超過時の挙動は、可用性と品質のどちらを優先するかで分かれます。
| 優先 | コスト超過時の挙動 | 想定用途 |
|---|---|---|
| 可用性優先 | 軽量モデルに自動降格、応答長を制限 | 顧客向け公開機能、業務時間中の社内利用 |
| 品質優先 | 一部機能を一時停止、上長承認で再開 | 重要意思決定向け、監査が必要な処理 |
| バランス | 高負荷時のみ軽量モデルに切り替え | 一般的な社内利用 |
「どのモデルにいくら払うか」を運用に閉じ込めず、SLOの一部として表に出すことで、月次費用の議論を業務会話に乗せられます。
SLOを守れない場合の優先順位
3軸すべてを同時に守れない状況は、運用中に必ず起きます。先に優先順位を決めておきます。
優先順位の決め方:
- 業務影響が最も大きい指標を最優先にする
- 失敗時に代替手段がある指標は劣後にする
- ユーザーの離脱・誤判断を引き起こす指標を上位にする
具体例:
- 顧客向け公開機能では、可用性 > レイテンシ > コストになりやすい
- 社内ナレッジ検索では、コスト > レイテンシ > 可用性も成立する（失敗時は手作業に戻れる）
- 意思決定支援用途では、品質劣化＝可用性低下とみなし、コストより品質を優先する
優先順位は、半年ごとに見直します。利用シーンの定着とともに、許容できる劣化幅は変わります。
〖確認ポイント〗本番運用前に決めるチェックリスト
本番投入前に、次を文書として残します。
- 対象LLMアプリの業務目的と失敗時影響
- 可用性SLI/SLO、失敗の定義
- TTFT/E2EのSLI/SLO、計測点
- 1リクエスト平均コスト、月次上限
- SLO違反検知時の通知先、初動手順
- モデル降格や機能制限などのフォールバック条件
- 運用開始後の見直し頻度（推奨は四半期）
これらが揃わないと、運用開始後の改善が「印象」で進みます。SLOを文書として持つことが、議論を数字に揃える出発点です。
運用開始後に見る指標と見直しサイクル
SLOは設定して終わりではなく、運用後に継続して見ます。最低限、次の指標を月次で見ます。
| 指標 | 何のために見るか |
|---|---|
| 月次成功率 | 可用性SLOの達成度 |
| TTFT/E2Eのパーセンタイル | レイテンシSLOの達成度 |
| 1リクエスト平均コスト | コストSLOの達成度 |
| エラーバジェット消費率 | 改善か機能追加かの判断 |
| 失敗パターン別件数 | 原因の偏り |
| ユーザーフィードバック比率 | 体感品質の傾向 |
エラーバジェットを使い切りそうな月は、新機能投入より修正を優先します。逆に余裕がある月は、改善より新機能投入を優先できます。
SLOは、開発と運用の意思決定を共通言語で扱うための道具です。四半期に一度は、目標値そのものを見直します。利用シーン、ユーザー数、モデル提供条件は半年単位で動きます。
リスクと限界
SLO設計は便利ですが、過信は禁物です。次のリスクを抑えておきます。
- 計測点が偏ると、現実と乖離した指標になります。クライアント側とサーバー側の両方で計測する設計が望ましいです。
- LLMの出力品質は、SLOだけでは管理できません。オンライン評価、ユーザーフィードバック、人手レビューの併用が必要です。詳細はLLM評価・モニタリングの実践で扱っています。
- モデル提供側の混雑や仕様変更は、SLO違反の原因になります。原因切り分けの初動手順が必要です。
- コストSLOだけを厳しくすると、品質が落ちます。3軸の優先順位を守ります。
- 機密データを扱うアプリでは、可用性・レイテンシ・コストに加え、入力データ種別と監査ログの設計を別管理にします。SLOで管理する指標とセキュリティ要件は混ぜずに整理します。
SLO設計を本格適用しないほうがよい条件
次のいずれかに当てはまる場合は、簡易な計測から始め、SLO文書化は後回しでも構いません。
- PoCや実証段階で、本番稼働前である
- 月間利用回数が極小で、業務影響が限定的である
- 単発の社内検証用途で、継続運用予定がない
業務利用が定着して以降、SLO設計に切り替えるのが現実的です。
※本記事の整理は2026年6月時点の一般的なSRE・LLMOps知見に基づきます。LLM関連サービスの料金、データ保持条件、提供機能は変更される場合があります。導入前に公式情報で最新条件を確認してください。
BlackfordのLLMアプリ運用設計に対する見解
LLMアプリのSLO設計は、技術論ではなく業務設計と運用責任の話です。Blackford Technologiesは、AI戦略の整理からPoC設計、実装、本番運用までを一貫して支援します。
特に、次の論点をセットで整理することを推奨します。
- 対象業務と「使えなかった」と見なす範囲の定義
- 既存システム・既存クラウドとの接続点での計測
- ログ、指標、フィードバック、ガバナンスのデータ設計
- 運用責任者と、エラーバジェット消費時の意思決定権者
LLMアプリをデータ基盤や既存業務システムと切り離して設計すると、SLOを守ろうとしてもログがない、責任者が不明、という事態になりがちです。
社内ナレッジ検索やRAGの運用設計を扱う場合はDataRoidが選択肢になります。既存クラウドやVPC内で運用する場合はDataRoid Cloud、営業領域のLLM活用はSalesRoidが候補です。
LLMアプリの本番運用設計は、AI開発・実装サービスで支援しています。SLO設計のたたき台を一緒に作るところからご相談ください。
よくある質問
LLMアプリにもSLOは必要ですか？
業務で継続利用する場合は必要です。SLOは「100%を目指す」道具ではなく、許容できる失敗量を先に決めて改善サイクルを回すための仕組みです。社内利用でも、利用頻度と業務影響が一定以上あれば、最小構成のSLOから始めます。
SLI/SLOは何個から始めるべきですか？
最初は3〜5個に絞ります。月次成功率、TTFT、E2E、1リクエスト平均コストの4つから始めると、運用議論に必要な共通言語が揃います。指標を増やすのは、運用が安定してからで十分です。
LLMの出力品質はSLOで管理できますか？
完全には管理できません。可用性・レイテンシ・コストはSLOで扱い、出力品質はオンライン評価、ユーザーフィードバック、人手レビューを併用します。両者は補完関係です。
SLOを満たせない月はどう判断しますか？
エラーバジェットの残量で判断します。残量が少ない月は、新機能投入より修正を優先します。残量に余裕がある月は、改善より新機能投入を優先できます。判断権者を先に決めておくことが運用の前提です。
中堅企業がSLO設計を始める際の最小構成は何ですか？
可用性・TTFT・1リクエスト平均コストの3指標、失敗の定義、四半期見直しの4点があれば始められます。ツールは社内で使い慣れた監視基盤に乗せ、最初はスプレッドシートで月次レビューしても問題ありません。
まとめ
LLMアプリのSLO設計は、可用性・レイテンシ・コストの3軸で目標値と優先順位を先に決めることが起点です。100%を目指す道具ではなく、許容できる失敗量を文書化して、改善サイクルを保つための仕組みです。
ただし、SLOだけで出力品質は管理できません。オンライン評価、ユーザーフィードバック、人手レビューを併用し、四半期に一度は目標値そのものを見直します。
自社のLLMアプリで「何を保証するか」を整理したい場合は、業務影響、データ、運用責任者を棚卸しした上で、専門家に相談しましょう。
＼LLMアプリ本番運用のSLO設計を相談できます／
Blackfordに相談する
