こんにちは。ガオ株式会社の黒澤です。本記事は「LLMOps：評価基盤の設計編 — Langfuse 活用 」の続編です。
設計編では評価軸の定義から Judge プロンプト設計・ゴールデンデータセット構築・メタ評価（Cohen’s Kappa・Confusion Matrix）まで解説しました。本記事ではその後の「誰が・いつ・どうやって評価を運用するか」を整理します。
想定読者#
- 評価基盤の設計（Judge プロンプト作成・メタ評価）まで完了し、運用設計を進めたい方
- 評価基盤は構築済みだが、改善サイクルが回っていない方
※ 本記事は Langfuse を評価基盤として採用中/検討中の方を対象としています
本記事でわかること#
- 役割分担（開発者 / ドメイン専門家 / PdM）と「誰が・いつ・どうやる」の運用設計
- スコア確認・Judge 改善・メタ評価の再実施をどう回すか
- スコア劣化時のアラート設計とコスト管理の勘所
本記事が扱う範囲は、設計編 で示した全体フローの G〜J（本番投入・運用・改善サイクル） です。
運用設計：誰が・いつ・どうやって#
ここからは、評価方法に関わらず共通する運用設計の話です。以下の 3 つの役割を前提に進めます。
役割分担#
| 役割 | 主な担当作業 |
|---|---|
| 開発者 | スクリプト作成、データセット登録、Judge プロンプト作成・改善、低スコアトレースの原因調査（Annotation Queues でのレビュー含む） |
| ドメイン専門家 | メタ評価時の人間評価、検証環境での動作確認、改善要望の提供、判断が難しい低スコアトレースのレビュー |
| PdM | スコア傾向の確認、リリース判断、評価軸の優先度決定、Annotation Queues への投入判断 |
設計編で挙げた課題 2 の 4 つの運用課題に対して、このセクションで以下のように対応します。
| 課題 | 対応する仕組み |
|---|---|
| スコアを誰も見ていない | スコア劣化時のアラート設計 + 週次レビューの定常化 |
| 次のアクションが決まっていない | 後述の定常運用表でスコア確認時のアクションを明示（Annotation Queues 投入等） |
| 評価の仕組みが追従していない | 機能追加時・モデル変更時のフロー |
| 過去のスコアと比較できない | Judge プロンプト変更時は本番トレースの連続比較を諦め、ゴールデンデータセット + Experiments での相対比較に切り替える |
定常運用の作業一覧#
定期実行
| 作業 | 誰が | いつ | やること |
|---|---|---|---|
| 本番トレースの自動評価 | Langfuse の Evaluator（または自前 Cron） | 毎日 / リアルタイム | サンプリングで自動採点 |
| スコア確認 | PdM / ドメイン専門家 | 週次 / スプリントレビュー | ダッシュボードでスコア傾向を確認し、低スコアのトレースを Annotation Queues に投入（詳細は下記の受け渡しフロー） |
| メタ評価の再確認 | 開発者 + ドメイン専門家 | 四半期 | ゴールデンデータセットから 10 件ほど抽出し、Pass・Fail それぞれの再現率を再測定する（Criteria Drift の検知） |
| データセット更新 | 開発者 + ドメイン専門家 | 四半期 | 古いデータの棚卸し、新パターンの追加 |
スコア確認の受け渡しフロー：
- PdM がダッシュボードで傾向を確認し、閾値を下回るトレースを Annotation Queues に投入
- ドメイン専門家が Annotation Queues の内容をレビュー（プロダクト要件に照らして問題ありか判断）
- 開発者が対象トレースを再現し、原因を調査
イベント駆動
| 作業 | 誰が | いつ | やること |
|---|---|---|---|
| Experiments（Dataset Run） | 開発者 | プロンプト・モデル変更時 | ゴールデンデータセットで変更前後を比較 |
| Judge プロンプト改善 | 開発者 | 誤評価を発見した時 | 失敗ケース分析 → プロンプト修正 → メタ評価の再実施 |
| データセット追加 | 開発者 + ドメイン専門家 | 機能追加時 / 新しい失敗パターン発見時 | 新パターンをデータセットに追加 |
ポイントは、「採点の自動化」と「判断の自動化」を混同しないことです。自動化されるのはあくまで採点までであり、そのスコアを受けて次のアクションを判断するのは人間の仕事です。典型的な判断例を示します。
| Fail が出た評価軸 | 次のアクションの第一候補 |
|---|---|
| トーン | アプリのシステムプロンプトでトーン指示を強化 |
| 事実性 | 参照しているナレッジベースの更新、または RAG の検索精度を見直す |
| ツール使用の正しさ | ツール選択のプロンプト、または Function Calling のツール説明文を見直す |
| どの評価軸でも合格なのに運用上の苦情が出ている | 評価軸の漏れを疑い、Judge プロンプト自体や評価軸一覧を見直す |
この判断の場を週次レビュー等のルーチンに組み込むことが、運用設計で最も大事な点です。
機能追加時のフロー#
新しいエージェントや機能が追加された場合は、以下のフローで評価を組み込みます。
- 受け入れ条件・テストシナリオからデータセットを作成
- 新機能用の Judge プロンプトを作成
- メタ評価を実施
- ドメイン専門家に検証環境で動作確認してもらう
- フィードバックを反映してデータセット・プロンプトを改善
- PdM がメタ評価結果と検証内容を踏まえてリリース可否を判断
- 本番投入後、自動評価に組み込む
モデル変更時のフロー#
アプリケーションが使う LLM モデル自体（アプリ本体の LLM）を変更する場合（例：GPT-4o → Claude Sonnet）は、プロンプト変更より影響範囲が広いため、全評価軸での再検証が必要です。なお、Judge 側のモデル変更については次の「Judge モデルの変更・廃止への備え」を参照してください。
- 変更前のモデルでゴールデンデータセットの Experiments を実行し、ベースラインを記録する
- 新モデルに切り替えて同じデータセットで Experiments を実行する
- 全評価軸のスコアを比較し、劣化した軸がないか確認する
- 劣化が見つかった場合は、低スコアのトレースを目視確認して原因を切り分ける
- アプリ本体の出力傾向が変わっているなら → アプリのプロンプトを調整
- 出力は妥当だが Judge の判定が新モデルに対して厳しすぎる／甘すぎる場合 → Judge プロンプトの再調整（メタ評価を再実施）
- PdM が Experiments の比較結果と追加調整内容を踏まえ、モデル切り替えの可否を判断
Judge モデルの変更・廃止への備え#
Judge に使っている LLM モデルがプロバイダ側で廃止・更新されることがあります。Judge モデルを変更すると評価基準のドリフト（同じ入出力に対するスコアのずれ）が起こりうるため、以下の手順で対応してください。
- 変更前の Judge と変更後の Judge を同一ゴールデンデータセットに対してそれぞれ実行し、スコアを並べて比較する
- Cohen’s Kappa・Confusion Matrix を確認し、旧 Judge と比べて著しくずれている評価軸があれば Judge プロンプトを調整する
- 問題がなければ本番の Evaluator を新 Judge に切り替える
スコア劣化時のアラート設計#
定常運用の「スコア確認」を週次の人力運用だけに頼ると、課題 2 で挙げた「スコアを誰も見ていない」という状態に逆戻りしやすくなります。閾値ベースのアラートを組み合わせることで早期検知が可能です。
本記事では設計方針に絞り、実装例は扱いません。本稿執筆時点（2026 年 4 月）では、Langfuse 標準機能でスコア劣化を直接検知するアラートは公式ドキュメント上確認できないため、Scores API と任意のスクリプトで実装するのが現実的です（最新の提供状況は Langfuse 公式ドキュメントで確認してください）。
設計方針の例として、事実性スコアの週次平均が一定値を下回ったら Slack に通知する構成が考えられます。
閾値は段階的に引き締めるのがおすすめです。
- 初期（本番データが少ない時期）：メタ評価時のベーススコアを初期値とし、誤報を避けるため閾値を低めに設定する（より低いスコアでのみアラートが発火するように。メタ評価は 10〜20 件の小サンプルで、そのまま本番に当てると誤報が多くなりがちなため）
- 本番データ蓄積後：数週間〜1 か月分の実績値が溜まったタイミングで、平均・分位点を踏まえて実績ベースの閾値に上書きする
これにより、ダッシュボードを見に行かなくても異常に気づける状態を作れます。
コスト管理#
LLM-as-a-Judge は LLM API を呼び出すため、コストが発生します。1 評価あたりのコストは、Judge に使うモデル・入力トークン数（評価対象のトレース長 + Judge プロンプト長）・出力トークン数（スコア + 推論）で決まります。
コスト見積もりの手順：
- Judge に使うモデルのトークン単価を確認する（各プロバイダの料金ページを参照）
- 評価対象トレースの平均トークン数を把握する（Langfuse のトレース画面で確認可能）
- 1 回の Judge 実行あたりのコストを算出する：
（入力トークン数 × 入力単価）+（出力トークン数 × 出力単価） - 1 トレースあたりの Judge 実行回数を把握する。トレース全体への評価なら 1 回だが、Observation 単位で評価する場合は 1 トレースで複数回実行される
- 月額コストを算出し、予算と照合する：
1 回の評価コスト × 1 トレースあたりの実行回数 × 1 日のサンプリング件数 × 30 日- 例：
- 1 日の本番トレースが 10,000 件、サンプリング率 10% → 評価対象 1 日 1,000 件
- 1 トレースを 3 評価軸で評価 → Judge 実行 3 回／トレース
- 月間 Judge 実行回数：3 × 1,000 × 30 = 90,000 回
- Claude Sonnet クラスのモデル・1 回約 $0.01（入力数千トークン程度）を仮定 → 月額約 $900
- ※ 実際の単価はモデル・入力長で変動するため、各プロバイダの料金ページで必ず再計算してください
- 例：
サンプリング率の考え方：
- トラフィックが少ない場合は全件評価でも十分安価に収まることが多い
- トラフィックが多い場合はサンプリング率を設定し、月額予算から逆算して件数を決める
- Langfuse の Evaluator ではサンプリング率を設定して評価対象を絞れます。さらに失敗パターンを優先的に拾いたい場合は、ユーザーの否定・訂正や罵倒などの不満シグナルを軽量 Judge（Haiku クラス等）で全件検知し、ヒットしたトレースのみを重めの Judge や Annotation Queues に回す方法も有効です（後述の「多層評価」と同じ考え方）（参考：The Rage Clicks of LLM apps — High-Signal Production Monitoring for AI Customer Support Agents ）
多層評価によるコスト削減：
多層評価とは、ルールベース判定（第 1 層）と LLM-as-a-Judge（第 2 層）を直列に組み合わせる構成です。すべてのトレースを LLM-as-a-Judge に渡すのではなく、手前に軽量なフィルタリング層を置くことで LLM API 呼び出し回数を減らせます。
- 第 1 層（ルールベース・プログラム判定）：全トレースを機械的にチェックし、明らかに NG のものは LLM に渡す前に失格させる（NG ワード含有、JSON スキーマ不正、必須要素の欠落、出力フォーマット違反など、正規表現や Python 関数で判定できるもの）
- 第 2 層（LLM-as-a-Judge）：第 1 層をパスしたトレースに対してのみ、LLM で質的な判定を行う（トーン・事実性など推論が必要な評価軸）
全件にいきなり LLM を当てるより、LLM API コストを大幅に削減できます。
評価軸ごとのモデル使い分け：
- トーン確認・形式チェックなど判断がシンプルな評価軸には軽量モデル（例：Haiku、GPT-4o mini）を使う
- 事実性の検証や複雑な推論が必要な評価軸には上位モデルを使う
- 同じアプリ内でも評価軸によってモデルを使い分けることで、精度を維持しながらコストを抑えられる
まとめ#
本記事（運用編）の内容をまとめます。
| フェーズ | やること |
|---|---|
| 設計フェーズ（設計編 ） | 出発点・評価軸の定義、Judge プロンプト作成、ゴールデンデータセット構築、メタ評価 |
| 運用設計・改善サイクル | 定常運用表に沿って採点・スコア確認・Judge プロンプト改善を実施 |
評価基盤を「作る」だけでなく、「誰が・いつ・どうやって」を設計し、改善サイクルを回し続けることで、LLM アプリケーションの品質は上がっていきます。特に 「スコアを受けた次のアクションを判断する場」を週次レビュー等のルーチンに組み込む ことが、運用設計で最も重要なポイントです。
評価基盤がまだない方は設計編 のプロンプトのルール分解とトレース 50 件の目視確認から、すでにある方はこの記事の役割分担と定常運用の作業一覧から始めると入りやすいです。
参考#
- The Rage Clicks of LLM apps — High-Signal Production Monitoring for AI Customer Support Agents - Langfuse Blog
- Systematic Evaluation of AI Agents - Langfuse Blog
- Langfuse で LLM 評価を効率化！活用方法徹底解説 - ガオ株式会社ブログ
- LangfuseのExperiments Compare ViewのBaseline機能を解説 - ガオ株式会社ブログ
Langfuse 公式ドキュメント#
- LLM-as-a-Judge - Langfuse Docs
- Annotation Queues - Langfuse Docs
- Experiments - Langfuse Docs