LLMオブザーバビリティ
LLMオブザーバビリティは、本番のLLMアプリケーションを計装し、チームがモデルの動作を把握し、失敗をデバッグし、コストとレイテンシを測定し、品質のドリフトを検出し、出力を経時的に評価できるようにする実践です。これは、ログ、トレース、メトリクスといった従来型のアプリのオブザーバビリティの、LLM時代の相当物であり、同じ入力が異なる出力を生みうる確率的なシステムに適応させたものです。
LLMオブザーバビリティは、本番のLLMアプリケーションを計装し、チームがモデルの動作を把握し、失敗をデバッグし、コストとレイテンシを測定し、品質のドリフトを検出し、出力を経時的に評価できるようにする実践です。これは、ログ、トレース、メトリクスといった従来型のアプリのオブザーバビリティの、LLM時代の相当物であり、同じ入力が異なる出力を生みうる確率的なシステムに適応させたものです。
なぜ重要なのか
従来型のウェブアプリは、動作するかエラーを投げるかのどちらかです。LLMアプリは「動作する」（整った形式の応答を返す）一方で、その回答が誤っていたり、本題から外れていたり、ハルシネーションを含んでいたり、偏っていたり、あるいは単に昨日より悪かったりすることがあります。オブザーバビリティがなければ、こうした失敗はユーザーが苦情を言うまで見えないままで、その頃には信頼はすでに損なわれています。2024〜2025年には、LLMオブザーバビリティが独立したカテゴリとなり、Langfuse、LangSmith、Helicone、Arize Phoenix、Weights & Biases Weave、Braintrustといったツールが、それぞれの領域を切り拓きました。本番でLLMを稼働させるあらゆるチームにとって、オブザーバビリティはいまや「あれば良いもの」ではなく必須条件です。
何を計装するか
トレース: 実行経路の全体、つまり1つのリクエスト内のすべてのプロンプト、検索呼び出し、ツールの呼び出し、応答です。エージェントが実際に何をしたのかを再生できるようにします。
入力/出力のペア: 送信された正確なプロンプトと、受信した正確な補完。プロンプトテンプレートごとにバージョン管理されます。
リクエストあたりのコスト: 入力と出力のトークン数 × 価格を、モデルごとに。機能、ユーザー、またはテナントごとに集計します。
レイテンシ: 最初のトークンまでの時間、補完の合計時間、各サブステップで費やされた時間。
エラーとリトライ: レート制限エラー、タイムアウト、ツール呼び出しの失敗、パースエラー。
品質シグナル: ユーザーの高評価/低評価、暗黙のシグナル（出力のコピー、コードの実行、メッセージの送信）、直近の出力に対するLLM-as-judgeのスコア。
ドリフト: 出力の分布、回答の品質、ツール呼び出しの率の経時的な変化。多くの場合、モデルの更新やプロンプトの変更が何かを壊した最初のシグナルです。
従来型のオブザーバビリティとどう異なるか
出力が決定論的でない: 同じ入力でも異なる出力。メトリクスはばらつきを第一級の概念として扱わなければなりません。
コストはリクエスト単位ではなくトークン単位: 従来型のAPMはトークンが何かを知りません。LLMオブザーバビリティは知っていなければなりません。
品質は主観的: 単純なテストで「出力は正しい」と断定することはできません。評価には、人間によるレビュー、LLMジャッジ、またはグラウンドトゥルースとの比較が必要です。
プロンプトはコードである: プロンプトの変更はデプロイです。プロンプトのバージョン管理がなければ、どのバージョンが昨日のバグを生んだのか分かりません。
複数ステップのチェーンが重要: ほとんどのLLMアプリはパイプラインです。フラットなログではなく、呼び出しグラフを反映したネストされたトレースが必要です。
ツールの状況（2026年）
Langfuse（オープンソース）: 評価、プロンプト管理、ユーザーフィードバックを備えた、トレース第一のオブザーバビリティ。セルフホストするチームに人気です。
LangSmith（LangChain）: LangChainと密に統合されています。すでにそのスタックを使っているチームに強いです。
Helicone: プロキシベースの軽量なオブザーバビリティ。1行で統合でき、導入が容易です。
Arize Phoenix / Arize AX: MLオブザーバビリティの世界から来ており、ドリフト、埋め込み、評価の科学に強いです。
Braintrust: 評価第一のプラットフォーム。LLM開発を実験のワークフローとして扱いたいチームに有用です。
Weave（Weights & Biases）: WandBのML実験トラッキングを、LLMの領域へと拡張します。
Datadog / New Relic LLMモニタリング: 従来型のAPMベンダーが、LLM固有のダッシュボードを追加したものです。
OpenTelemetry GenAIセマンティック規約: LLMトレースのためのベンダー横断の標準で、2025〜2026年に採用が広がっています。
何を注視するか
ユーザーセッションあたりのコスト: 突然の急増は、成長を意味する前に、しばしばバグ（リトライループ、暴走するエージェント）を意味します。
レイテンシのp95/p99: ロングテールはUXを台無しにします。平均よりも最悪のケースが重要です。
評価スコアのドリフト: 代表的なプロンプトに対する週次のLLM-as-judgeスコアは、プロンプトやモデルの変更後の、静かな回帰を捕捉します。
主要な失敗モード: エラーを分類します。拒否、ハルシネーション、本題外れ、不正な形式など。どこに投資すべきかが分かります。
プロンプトのバージョンごとのパフォーマンス: プロンプトのバージョン間で評価スコアを比較し、最新の変更が役立ったのか害になったのかを把握します。
トークンの分布: 長い応答はコストを押し上げます。予想外に長いテールは、しばしばプロンプトのドリフトや壊れたストップトークンを示します。
よくある間違い
エラーだけをログに記録する: LLMは静かに失敗します。成功も、品質を評価できるだけのメタデータとともにログに記録しましょう。
サンプリング戦略がない: 大規模にリクエストの100%をログに記録するのは高コストです。ユーザーセグメント、コストティア、直近の変更によって賢くサンプリングしましょう。
トレースをユーザーフィードバックに結びつけない: 低評価は、その出力を生んだ正確なトレースへとさかのぼってリンクされる必要があります。
チームごとにサイロ化する: プロダクト、ML、インフラがそれぞれ独自のダッシュボードを構築します。統合されたオブザーバビリティこそが勝ち筋です。
回帰テストを無視する: 「問題なさそう」では不十分です。回帰評価セットを構築し、プロンプトを変更するたびに走らせましょう。
ベンダーロックインを追い求める: OpenTelemetry GenAI規約により、一度計装すれば、後でオブザーバビリティのベンダーを差し替えられます。
Sources: