LLMモニタリングとは？本番運用で追う指標・導入手順・選定チェックリスト
AI脆弱性診断
そのAIシステム、従来の診断だけで十分ですか？
外部・内部の弱点に加え、プロンプトインジェクションや過剰な権限などAI固有の攻撃面も診断します。
LLMモニタリングとは、LLMを組み込んだアプリケーションが本番環境で期待した品質・安全性・速度・費用で動いているかを継続的に観測し、異常時に原因を切り分けて改善する運用です。
見る対象は、最終回答だけではありません。モデル呼び出し、RAGの検索結果、外部ツールの実行、ユーザーのフィードバック、人による承認・差し戻しまでを、一つの処理経路として扱います。NIST AI RMFは、AIシステムを運用開始後も監視し、利用者などからの入力、異議申立て・上書き、インシデント対応、復旧、変更管理を含む計画を実装することを示しています。NIST AI RMF Core
結論：最初から全プロンプトを保存する大規模な監視基盤を作る必要はありません。まずは「どの失敗を早く見つけたいか」を決め、処理ID・バージョン・所要時間・トークン・結果・人の判定を最小単位として記録し、限定した本番トラフィックで評価とアラートを回すことが実務的です。
LLMモニタリングで判断できること
LLMアプリは、モデルの応答が返っていても、業務上は失敗していることがあります。たとえば、RAGで古い規程を引用した、エージェントが誤ったツールを選んだ、出力は正しいが待ち時間が長すぎる、トークン増加で採算が崩れた、といったケースです。
確認したい問い | 主な観測対象 | 判断例 |
|---|---|---|
利用者に届いているか | 成功・失敗、HTTPエラー、完了理由、再試行 | 障害か、特定のモデル／ツールの失敗かを分ける |
業務品質を満たすか | 正確性、根拠性、形式遵守、タスク完了、人の差し戻し | 公開・送信・登録の前に人へ渡すべき処理を決める |
遅くなっていないか | 全体時間、モデル応答時間、検索時間、ツール時間、再試行回数 | モデル、検索、外部API、ループのどこが遅いかを分ける |
費用が変わったか | 入力・出力トークン、モデル、キャッシュ、ツール回数、完了件数 | リクエスト単価ではなく「完了した業務1件あたり」で見る |
安全に動いているか | 拒否・ブロック、権限エラー、危険なツール操作、個人情報を含むログ | 停止・隔離・人の承認へ切り替える条件を決める |
OpenTelemetryのGenAI向け規約では、モデル名、入出力トークン数、応答終了理由などを共通的な属性として扱います。また、会話内容、システム指示、ツール引数・結果、検索クエリは機微情報を含み得るため、記録時には注意が必要とされています。OpenTelemetry GenAI attributes
LLMモニタリング・評価・オブザーバビリティの違い
これらは重なりますが、同じものではありません。以下はMojiによる実務上の整理です。
活動 | 主な目的 | 代表的な成果物 |
|---|---|---|
モニタリング | 本番で起きている変化・異常を継続検知する | ダッシュボード、アラート、日次・週次レポート |
評価 | 定義した基準で出力・経路が合格かを判定する | 評価データセット、採点基準、合否結果、比較表 |
オブザーバビリティ | 問題が起きた処理経路を追跡し、原因を説明できるようにする | トレース、ログ、メトリクス、バージョン情報 |
たとえば「回答品質スコアが低下した」という監視アラートだけでは、原因は分かりません。トレースで、入力の種類、プロンプト版、モデル版、検索候補、最終コンテキスト、ツール結果、再試行をたどれるようにして初めて、修正箇所を絞れます。Microsoft Foundryも、トレース、評価、監視を組み合わせ、運用中のトラフィックに対する継続評価やテストデータを使った定期評価で変化を検出する流れを案内しています。Microsoft Foundry: Observability in Generative AI
評価設計そのものは、AIの評価とは？評価指標や評価方法、その費用について、RAG向けの評価ケース作成はRAG評価データセットの作り方｜設計・作成・品質確認・更新を実務手順で解説も参照してください。
最初に追うべき5群の指標
「正確性」という1指標だけで運用を判断しないことが重要です。以下は、一般的な設計上の目安です。採用するモデル、入力品質、評価器、人の確認方法、業務ごとの許容誤差によって、合格水準と優先順位は変わります。
指標群 | 例 | 見るべき理由 | 注意点 |
|---|---|---|---|
可用性・信頼性 | 成功率、エラー率、タイムアウト率、再試行率 | 利用者に結果を返せているかを見る | 成功レスポンスでも業務失敗はあり得る |
品質 | タスク完了率、根拠性、形式遵守率、人の修正率 | 「使える出力」かを確認する | LLM採点だけで確定せず、人の標本確認を残す |
速度 | P50／P95所要時間、初回表示までの時間、ツール別時間 | 待ち時間の悪化を捉える | 平均値だけでは一部利用者の長時間待ちを見逃す |
費用 | 入出力トークン、モデル別費用、完了タスクあたり費用 | 利用増加やプロンプト肥大化を捉える | 単価ではなく、再試行・人手修正を含む総コストで見る |
安全・統制 | 拒否率、ポリシー違反、承認待ち、権限エラー、機密情報検知 | 影響の大きい失敗を早く隔離する | 検知ログ自体が機微情報の保管庫にならないようにする |
RAGやエージェントでは、最終回答に加えて「検索候補に正しい根拠が入ったか」「LLMへ渡した文脈に残ったか」「ツールを正しい順序・引数で呼べたか」を分けて測ります。最終回答だけを採点すると、検索・文脈構成・生成・ツール実行のどこを直すべきか判別しにくくなります。社内RAGが的外れな回答を返す原因と改善方法｜検索・チャンク・抽出・評価の切り分け
監視データの最小設計：保存するもの、原則保存しないもの
監視の導入で最初に決めるべきなのはダッシュボード製品ではなく、何を記録し、誰が見られ、いつ消すかです。トレースはデバッグに有用ですが、入力・出力・ツール結果に顧客情報や個人情報が含まれる可能性があります。Microsoft Foundryのトレース機能も、ユーザー入力、プロンプト、モデル入出力、ツール呼び出し、実行メタデータを記録し得ること、閲覧権限と収集内容を確認すべきことを明記しています。Microsoft Foundry: Tracing and data handling
最低限、構造化して残す項目
- 相関ID：リクエストID、会話ID、トレースID、親子処理ID
- 変更識別子：アプリ版、プロンプト版、モデルID、検索インデックス版、ツール定義版、ガードレール版
- 処理結果：成功・失敗・中断・人への引き継ぎ、エラー種別、終了理由
- 性能・費用：開始・終了時刻、区間別所要時間、入出力トークン、再試行回数、ツール呼び出し数
- 品質証跡：評価器の種類と版、スコア、合否、人のレビュー結果、フィードバック分類
- RAG・エージェント固有：検索対象ID、候補順位、採用した根拠ID、ツール名、実行結果の状態
原則としてそのまま保存しない項目
- 生の個人情報、認証情報、APIキー、決済情報、秘密情報
- 全文保存が不要な入力・出力・添付ファイル・ツール戻り値
- 目的、保管期間、閲覧者、削除方法が未決定の会話ログ
Mojiでは、まず内容を保存しないメタデータ中心の観測から始め、障害調査や品質レビューに必要な範囲だけをマスキング・短縮・サンプリング・権限分離したうえで追加する方法を提案します。プロンプトインジェクションや機微情報の開示はLLMアプリの代表的なリスクであり、システムプロンプトだけを対策の根拠にしないことが重要です。OWASP Top 10 for LLM Applications v2.0
LLMモニタリングの導入手順
- 業務上の失敗を定義する
「誤答」ではなく、「誤った金額を顧客に送る」「根拠なしの規程案内を公開する」「権限外の文書を表示する」のように、影響と復旧方法が分かる単位で書き出します。 - 処理経路と責任者を決める
入力、検索、モデル、ツール、人の承認、出力先を図にし、異常の一次確認者、停止判断者、復旧担当者を割り当てます。 - バージョンを固定して記録する
モデル名だけでなく、プロンプト、検索インデックス、ツール定義、アプリコード、評価器を変更単位として識別します。これがないと、スコア悪化と変更の関係を検証できません。 - オフライン評価の基準線を作る
実際の業務に近い質問、失敗例、境界例を集め、期待結果、許容誤差、確認者を定義します。自動採点と人手採点を併用する場合は、どちらが最終判定を持つかを明記します。 - 最小のトレースとメトリクスを実装する
リクエスト単位で、モデル呼び出し、検索、ツール実行、人への引き継ぎを関連付けます。OpenTelemetryのような共通規約を使うと、特定の監視製品へ依存しすぎず、モデル・トークン・終了理由などの比較を始めやすくなります。OpenTelemetry: GenAI Observability - 限定トラフィックで継続評価する
全件採点ではなく、リスクが高いケース、変更直後のケース、ランダム標本を優先します。品質・安全性の評価が基準を下回った場合に、担当者へ通知し、必要なら自動実行を人の承認へ戻します。 - アラートから改善までを運用化する
通知だけで終わらせず、トレース確認、影響範囲の特定、一時停止・ロールバック、評価ケース追加、再リリース判定までを手順化します。
出力の正確性、承認、改善の流れを設計する際は、生成AIの正確性課題とは？企業文書の誤情報を防ぐ評価・承認・改善フローも参考になります。
アラートは「数字の悪化」ではなく「行動」で設計する
しきい値は、一般論の数値をそのまま採用しても有効とは限りません。利用量、モデル、入力の長さ、業務の緊急度、許容できる失敗によって妥当な水準が変わるためです。Mojiでは、アラートごとに次の4点をセットで定義することを提案します。
定義項目 | 記入内容 |
|---|---|
検知条件 | 例：特定のプロンプト版で、一定件数以上の品質不合格が連続した |
対象範囲 | モデル、地域、顧客区分、業務フロー、アプリ版、ツール連携の範囲 |
一次対応 | トレース確認、対象経路の停止、人の承認への切替、前版への戻し |
復旧判定 | 追加した評価ケース、再評価条件、責任者、再開の承認条件 |
架空の例：「根拠のない回答が増えた」というアラートではなく、「プロンプト版P-12かつ検索インデックスI-07で、根拠IDなしの回答が評価標本で許容範囲を超えた場合、外部公開を停止し、引用必須モードへ切り替える」のように、条件と操作を対応付けます。
監視ツールを選ぶ6つの比較基準
LLMモニタリング製品を順位だけで選ぶことはおすすめしません。必要な機能は、単純なチャット、RAG、ツール実行を伴うエージェント、規制業務で異なります。また、モデル、入力品質、評価指標、許容誤差によって結論は変わります。
比較基準 | 確認する質問 | 適合しにくい例 |
|---|---|---|
計測の粒度 | モデル、検索、再ランキング、ツール、承認を同一トレースでたどれるか | 最終回答とAPI所要時間しか見えない |
データ制御 | 内容記録のオン・オフ、マスキング、保管場所、保持期間、削除、RBACを設定できるか | 会話全文を常時外部へ送る前提で変更できない |
評価の接続 | 本番標本、評価データセット、人のレビュー、独自評価器を関連付けられるか | 単一のLLM採点スコアのみで合否を決める |
変更管理 | プロンプト、モデル、検索、ツール、アプリの各版を比較できるか | 品質低下が起きても変更箇所を追えない |
可搬性 | OpenTelemetryなどの標準形式、API、エクスポートで他基盤へ移せるか | データ形式が独自で、移行・統合が困難 |
運用適合性 | アラート、監査、障害対応、費用上限、既存の監視・チケット管理とつながるか | 開発者だけが見ており、業務責任者が判断できない |
クラウド基盤の評価機能を使う場合も、事前評価、運用中の標本評価、定期的なテストデータ評価、人による評価の役割を分けて確認してください。たとえばAmazon Bedrockは、独自データセットによる評価、LLMを審査員とする評価、人による評価、RAGの検索・生成に対する評価を案内しています。Amazon Bedrock: Evaluate the performance of resources
導入前チェックリスト
- □ 監視対象の業務、利用者、出力先、失敗時の影響を定義した
- □ モデル・プロンプト・検索・ツール・アプリの変更識別子を記録できる
- □ 会話内容を保存しない場合でも、処理経路とエラーを追える
- □ 保存する入力・出力・ツール結果について、マスキング、保持期間、閲覧権限、削除方法を決めた
- □ 品質評価に使うケースと、人のレビュー対象を定義した
- □ 自動評価器のスコアを、重要な業務判断の唯一の根拠にしていない
- □ 品質、遅延、費用、安全性の各アラートに、対応者と停止・復旧手順がある
- □ 変更後に比較する基準線と、ロールバック条件がある
- □ 月次ではなく、変更直後・障害時・定期レビューで見る運用を決めた
まとめ：LLMモニタリングは「ログを集めること」ではない
LLMモニタリングの目的は、会話ログを大量に保管することではなく、業務に影響する異常を早く見つけ、原因を説明し、安全に戻すことです。
まずは、業務上の失敗を定義し、変更識別子と処理経路を記録し、品質・速度・費用・安全性を別々に観測してください。そのうえで、評価データセットと本番標本をつなぎ、アラートから停止・復旧までを運用に組み込みます。外部操作を伴うエージェントでは、特に権限・承認・停止条件を監視対象に含める必要があります。AIエージェントのガードレール設計｜暴走を防ぎながら自動化を進める権限・承認・停止・監視の実務ガイド