モニタリング

モニタリングはループのどこに位置するか

トレーシング は、LLM アプリが行っていることの完全な記録を提供します。 すべてのリクエスト、すべてのモデル呼び出し、すべてのツール利用が記録されます。 モニタリングは、そのデータを読み解く手段です。 モニタリングは 2 つの役割を提供します。 時間経過に伴うシステムのパフォーマンスを継続的に見るビューと、調査すべきトレースを浮き上がらせる手段です。 エラー、ユーザー行動のパターン、予期しない失敗のケースなどです。 両者を合わせることで、データを持っている状態から、改善できるほどシステムを理解している状態へと移行できます。

メトリクスとシグナル

モニタリングを 2 つの異なる活動に分けて考えると役に立ちます。 両者は異なる問いに答えるからです。

集計メトリクスの追跡 は、時間とともに状況が良くなっているか悪くなっているかを教えてくれます。 コスト、レイテンシー、評価スコアなどは、議論の対象にできるトレンドになります。 先週の火曜日のプロンプト変更で何か改善したか? 利用が増えるにつれて品質はドリフトしているか?

シグナル検出 は、今どこを見るべきかを教えてくれます。 調査すべき個別のトレースを浮かび上がらせるものです。 エラー、リトライのクラスタ、ユーザーが会話の途中で離脱したケースなど。 そのシグナルが有用なのは、原因となった特定のトレースに結びついているからです。 そのトレースが、何が起きたかを理解する出発点になります。

メトリクスとシグナルはどこから来るか

集計メトリクスもシグナル検出も、オブザベーションに付与されたフィールドに依存します。 適切に計装しておけば、必要なものの多くは自動的に揃います。 レイテンシー、トークン由来のコスト、モデルや経路のメタデータ、ツールの結果、エラーなどは、クライアントやプロバイダの API から追加の設定なしで流れてくるのが普通です。

組み込みフィールドに加えて、評価を追加できます。 ユーザーフィードバック (明示的な評価や、セッション離脱のような暗黙的なシグナル)、人手アノテーション、LLM-as-a-Judge のスコアなどです。 これらは手動でトレースに注釈を付けたり、自動評価器を動かしたりして得られます。 このデータは、時系列トレンドを追う集計チャートにも、設定した閾値を超えたときに個別トレースを浮かび上がらせるシグナルルールにも流れ込みます。

明示的・暗黙的なユーザーフィードバック

ユーザーフィードバックは最も豊富なシグナル源の 1 つですが、2 つの形態があり、それぞれにトレードオフがあります。

明示的フィードバック は直接的なものです。 良い・悪いのボタン、星評価、ユーザーが残したコメントなど。 シグナルは曖昧さがありませんが、回答率は低く、偏りがちです。 満足したユーザーよりも、不満を持ったユーザーの方が回答しやすい傾向があります。

暗黙的フィードバック は行動から導かれます。 ユーザーがクエリをやり直したか、システムを訂正したか、応答をコピーしたか、提案を受け入れたか、会話を途中で放棄したか、といった情報です。 ユーザーに労力を求めず、大量のデータが得られますが、シグナルは間接的で解釈が必要です。 こうしたシグナルは自動評価器によって浮かび上がらせることができます。

具体例として、明示的・暗黙的フィードバックをどうバランスさせるかの 2 つのアプリケーション例を示します。

明示的: 会話終了時の高評価 / 低評価ボタン
暗黙的: 会話途中の有人対応への切り替えリクエスト

明示的: なし — ワークフロー内に評価が適する箇所がない
暗黙的: 承認前に抽出フィールドが手動で編集されたかどうか

どちらもスコアとして登録されるので、他の評価データと同じダッシュボード、トレンドチャート、シグナルルールに流れ込みます。 そもそもどのフィードバックシグナルを自動評価器に変えるべきかを見極めるには、エラー分析 の解説を参照してください。

どこから始めるか

小さく始め、「何が重要かもしれないか」という抽象論ではなく、実トレースからモニタリング構成を組み立てましょう。

1. まず手動でデータを見ます。 トレースを読み通し、繰り返し現れるものに気づきます。 何を探すべきかを知らずに、有用なモニタリングは設定できません。

2. エラー分析 で、追跡する価値のあるものを浮かび上がらせます。 エラー分析は、トレース全体のパターンを見つけ、継続的に動かす自動評価器に変えるべき再発的な問題を見つける体系的な方法です。

3. アプリケーション固有の失敗の現れ方を考えます。 アプリ固有の暗黙的シグナル (サポートチャットでのユーザーの訂正、プロセス自動化フローでの修正など) は、汎用スコアよりもアクション可能なことが多く、手動ラベリングなしで問題を浮かび上がらせます。

4. 反復的なプロセスとして扱います。 モニタリング構成は一度設定して放置するものではありません。 利用パターンが変わり、モデルが更新され、新しい失敗モードが現れます。 ノイズを切り抜けて、本当に重要なものに集中し続けられるよう、構成を磨き続けてください。

次のステップ

モニタリングで調査すべきものが浮かび上がったら、いくつかの選択肢があります。 原因が明らかなら直接修正する、パターンに見えればデータセットに取り込む、体系的な問題が疑われれば構造化された評価を実行する。 どの経路を取るかは、原因にどれだけ確信があるかに依存します。

• データセット: 評価のために本番トレースを取り込む
• 実験: 修正が実際に機能したかをテストする