なぜ「作って終わり」にできないのか
LLMアプリの周囲では、リリース後も環境が動き続けます。プロバイダのモデルは更新・非推奨化され、挙動が静かに変わります。RAG(検索拡張生成)の参照文書は日々増減し、古い規程が回答に混ざり始めます。ジェイルブレイクや間接プロンプトインジェクションといった攻撃手法も更新され続けます。そして肝心のアプリは非決定的で、同じ入力にも出力が揺らぎます。
つまり、リリース前のテストに合格したことは、本番で正しく動き続けることを保証しません。静的な検証は必要条件であって十分条件ではなく、本番を継続的に測り、直し、安全に反映する「運用のループ」が一級の仕組みとして必要になる ― これがLLMOpsの出発点です。
土台は「評価(Evals)」― 良くなったと言えるものさしを持つ
「直したら良くなった気がする」では、目隠しで配線を替えるのと同じです。改善の前提は、出力の良し悪しを繰り返し測れる評価データセット(ゴールデンセット)を持つことです。代表的な質問と合格基準の組を30〜100件程度、小さく作って始めれば十分です。正常系だけでなく「答えるべきでない質問」や敵対的な入力も必ず含めます。
採点は、形式や禁止語を判定するルールベースで足切りし、意味的な品質はLLM自身に採点させる LLM-as-judge でスケールさせ、際どい一部だけを人手で確認するのが定石です。エンジニアがいなくても、業務の専門家が「良い回答/悪い回答」をラベル付けできれば評価は回せます。
評価の最大の価値は「変更を安全にすること」にあります。プロンプトやモデルを変えるたびにゴールデンセットで前後比較し、基準スコアを下回ったら反映しない「回帰ゲート」をCIに組み込む。さらに本番トラフィックの一部(例えば5〜20%程度)をサンプリングして採点すれば、実ユーザー入力での劣化も捉えられます。
監視は「意味・品質・安全」を追う専用の層を重ねる
従来のインフラ監視には「意味的に間違っている」という概念がありません。そこで、1リクエストをLLM呼び出し・検索・ツール実行までステップ単位で追うトレースを軸に、専用の可観測性の層を重ねます。障害の原因は最終出力ではなく途中のステップにあることがほとんどだからです。監視指標は次の4カテゴリに整理できます。
| カテゴリ | 代表的な指標の例 |
|---|---|
| 品質 | 忠実性・関連性スコア、ハルシネーション率、ユーザーフィードバック |
| 性能 | レイテンシ(p50/p95)、最初のトークンまでの時間(TTFT) |
| コスト | リクエスト単価、トークン数、キャッシュヒット率、チーム別配賦 |
| 安全 | フィルタ発火率、PII検出、プロンプトインジェクション検知 |
ツールは Langfuse・LangSmith・Arize Phoenix・Helicone など選択肢が豊富ですが(いずれも2026年6月時点)、乗り換えコストを下げるため、OpenTelemetry 準拠で計装しておくのが定石です。
コストは「可視化してから」最適化する ― 最初の一手はプロンプトキャッシュ
可視化なしの最適化は当て推量です。機能・チーム単位でコストを配賦できる状態を作ったうえで、効果と労力のバランスが最も良いプロンプトキャッシュから着手します。毎回同じシステムプロンプトなどの固定部分をプロバイダ側にキャッシュさせる仕組みで、実装が軽く品質を落としません。例えば2026年6月時点のAnthropic公表の価格体系では、キャッシュ書き込みは基本入力価格に約25%の上乗せ、読み出しは約90%割引とされており、繰り返しヒットするほど得になる構造です。静的な内容を前に、動的な内容を後ろに置くのが鉄則で、割引が効くのは入力トークンのみという点にも注意が必要です。
あわせて、冗長な例示やRAG文脈を絞り込むプロンプト圧縮、簡単なタスクを小型モデルに振り分けるモデルルーティングも有効です。そして忘れてはならないのが暴走防止です。ユーザー・アプリ単位のコスト上限と予算アラート、エージェント型には強制停止(kill switch)を必須とし、ループによるコスト爆発は「起きる前提」で設計します。
継続改善 ― 本番の失敗を「次のテスト」に変える
仕上げは、集めた事実を改善に還流するループです。フィードバックと本番トレースから失敗例を拾い、原因をプロンプト/モデル/RAG/アプリロジックに切り分けて直す。失敗例はゴールデンセットに追加し、次のテストに変える。反映は、評価ゲートの通過 → カナリアリリース(一部トラフィックへの限定投入) → オンライン評価で旧版と比較 → 全開放、の順で行い、即時に切り戻せるロールバック経路を常備します。プロンプトやモデル設定もコードと同様にバージョン管理し、「いつから劣化したか」を差分で追える状態を保ちます。
まとめ ― まず確認したい4つ
- ゴールデンセットがあるか。なければ想定質問30件からでも今週作る。本番の失敗例を毎週還流して育てる。
- 意味・品質・安全を監視できているか。トレースを取り、4カテゴリの指標に閾値アラートを置く。「請求書で気づく」を避ける。
- プロンプトキャッシュとコスト上限を有効にしているか。低労力で効果が大きく、事故も防ぐ。
- 変更を安全に反映する経路があるか。評価ゲート→カナリア→全開放の順を飛ばさず、ロールバックを常備する。
目標は、担当者の気合いではなく仕組みで運用が回っている状態です。これが揃えば、AIアプリは「作って終わり」ではなく、使われながら良くなり続ける資産になります。