LLM（大規模言語モデル）の推論品質・レイテンシ・コスト・異常検知をリアルタイムに監視し、本番環境での信頼性を維持する運用プラクティス。
LLMモニタリングとは、本番環境で稼働する大規模言語モデル（LLM）の動作状況をリアルタイムに観測・分析する運用手法です。従来のソフトウェア監視が応答時間やエラー率を追跡するのと同様に、LLMモニタリングではモデル出力の品質・推論レイテンシ・トークン消費量・コスト・安全性違反を継続的に計測します。
LLMは確率的な出力を返すため、同じプロンプトでも異なる応答が生成されます。この非決定性が従来のユニットテストだけでは品質保証を困難にします。さらに、モデルプロバイダ側のアップデートやAPI仕様変更により、昨日まで正常だった出力が突然劣化する「サイレントリグレッション」が発生するリスクがあります。
| 監視対象 | 主な指標 | 異常時の影響 |
|---|---|---|
| 出力品質 | 一貫性スコア、幻覚率、フォーマット準拠率 | ユーザー体験の劣化 |
| レイテンシ | P50/P95/P99応答時間、TTFT（Time To First Token） | タイムアウト・UX悪化 |
| コスト | トークン消費量/リクエスト、日次・月次コスト | 予算超過 |
| 安全性 | PII検出率、有害出力率、ガードレール発火率 | コンプライアンス違反 |
| 可用性 | エラー率、レート制限発生頻度、フォールバック発動率 | サービス停止 |
出力品質の定量評価には複数のアプローチがあります。LLM-as-a-Judge（別のLLMで出力を評価）は人間評価との相関が高く、自動化しやすい手法として普及しています。BLEU・ROUGEなどのn-gramベース指標は翻訳・要約タスクで補助的に使用されますが、自由形式の生成タスクでは限界があります。
独自の評価関数（カスタムメトリクス）として、JSON形式準拠率・回答拒否率・引用正確率などをタスク固有に定義することが実用的です。
推論レイテンシはユーザー体験に直結するため、パーセンタイル分布（P50/P95/P99）で監視します。ストリーミング応答ではTTFT（最初のトークンが返るまでの時間）が体感速度を決定します。バッチ推論ではスループット（トークン/秒）が重要です。
トークン課金モデルでは入力・出力トークン数の追跡が必須です。プロンプトキャッシュのヒット率、不要な再試行によるコスト増、モデル選択の最適化（高コストモデルへの不要なルーティング）も監視対象になります。
| ツール | 特徴 | 対応LLM |
|---|---|---|
| LangSmith | LangChain統合、トレース可視化、評価パイプライン | OpenAI、Anthropic、ローカルLLM等 |
| Langfuse | OSS、自己ホスト可、コスト追跡 | プロバイダ非依存 |
| Arize Phoenix | OSS、トレース+評価、埋め込み可視化 | プロバイダ非依存 |
| Helicone | プロキシ型、ゼロコード統合、キャッシュ機能 | OpenAI中心 |
| Weights & Biases Weave | 実験管理統合、モデル比較 | プロバイダ非依存 |
基本的なモニタリング実装は「ミドルウェアパターン」で行います。LLM呼び出しの前後にフックを挿入し、入力プロンプト・出力テキスト・メタデータ（レイテンシ・トークン数・モデル名）を記録します。OpenTelemetryのSpan/Traceモデルと組み合わせることで、RAGパイプライン全体のエンドツーエンド可視化が可能になります。
アラート設計では、品質スコアの移動平均が閾値を下回った場合やコストが予算上限に接近した場合に通知を発火させます。誤報（False Positive）を減らすため、単発の異常値ではなく一定期間の傾向で判定するのがベストプラクティスです。
A1: 従来のAPM（Application Performance Monitoring）はリクエスト/レスポンスの構造化データを対象としますが、LLMモニタリングでは非構造化テキスト出力の「意味的品質」を評価する必要があります。幻覚検知やトーン一貫性など、テキスト固有のメトリクスが加わります。
A2: はい。最低限、レイテンシ・エラー率・トークン消費量の3指標は本番投入前から計測すべきです。OSSツール（Langfuse・Arize Phoenix）なら自己ホストで無料運用が可能です。
A3: GPT-4クラスのモデルをジャッジに使った場合、人間評価との一致率は80-85%程度とされています。コスト効率のため、軽量モデルで一次スクリーニングし、低スコア出力のみ高精度モデルで再評価する二段階方式が有効です。