チームが LLM アプリケーションをデモから本番環境に移行するときに最初に発見することは、彼らが盲目で飛行しているということです。モデルは答えを返します、その答えはときどき間違っていて、なぜなのか明らかな方法はありません。検索が悪かったのか? ツール呼び出しがサイレントに失敗し、エージェントが即興で演奏されたのか? 3 週間前のプロンプト変更が静かに品質を低下させたのか? 従来の Web サービスでは、ログ、メトリクス、トレースを求め、数分以内に答えを見つけるでしょう。2023 年の LLM アプリケーションでは、ほとんどのチームが print ステートメントと感覚を持っていました。2026 年までに、そのギャップは閉じられ、それを閉じた規律は LLM 監視です。言語モデル アプリケーションをインストルメント化、トレース、評価する実践で、その動作が表示可能、デバッグ可能、測定可能に改善できるようにします。
このガイドは 2026 年の LLM 監視が実際に意味することをカバーしており、なぜそれが通常のアプリケーション監視よりも難しいのか、そしてスタックがどのように適合するかについて説明しています。スルーラインは標準です — OpenTelemetry — これは、プロプライエタリ SDK の断片化されたフィールドを相互運用可能なものに変えました。3 つのツールはアプローチを例示しています: Arize Phoenix、Langfuse、および MLflow。目標は、何をインストルメント化するか、何を測定するか、ロックインしないツールを選択する方法について推論できるようにすることです。
LLM アプリが監視するのが難しい理由
従来の監視は 3 つの柱に基づいています: ログ (何が起きたか)、メトリクス (どの程度、どのくらい速いか)、トレース (リクエストがシステムを通った経路)。LLM アプリケーションはすべて 3 つが必要ですが、素朴な監視をほぼ役に立たなくするような方法で通常の仮定を打ち破ります。
最初の問題は 非決定性 です。同じ入力は異なる出力を生成できるため、「それは一度間違ったものを返しました」はデバッガーで再実行できる再現可能なバグではありません。特定の呼び出しで実際に何が起きたかをキャプチャする必要があります。正確なプロンプト、正確なコンテキスト、正確な応答です。再現する可能性がないため。2 番目の問題は 品質の不透明性 です。Web リクエストは成功するか、エラー コードを返します。LLM 呼び出しはほぼ常に「成功」します。テキストを返すという意味で、テキストが微妙または壊滅的に間違っている可能性があります。ステータス コードは何も教えてくれません。品質は、別々に評価する必要があるセマンティック プロパティです。3 番目の問題は 深さ です。最新のエージェントは 1 つのモデル呼び出しではありません。それはツリーです。モデルはツール呼び出しを決定し、ツールがデータを返し、モデルが文脈を取得し、中間結果に対して推論し、おそらく別のエージェントに渡し、その後に答えます。最終的な答えが間違っている場合、原因はそのツリーの任意のノードにある可能性があり、「モデルを呼び出した、応答を得た」のフラット ログはデバッグに必要な正確な構造を隠しています。
これら 3 つのプロパティ — 非決定性、不透明な品質、深い呼び出しツリー — は、LLM 監視が既存の APM へのペイント コートではなく、独自の規律である理由です。重要なツーリングはそれらの周りに構築されています。
トレーシング: 呼び出しツリーを表示
基盤は LLM アプリケーションに適応した分散トレーシング です。トレースはエンドツーエンド リクエストを 1 つのツリーとしてキャプチャします。各スパンは 1 つの操作です: LLM 呼び出し、ツール呼び出し、検索ステップ、ガードレール チェック。各スパンについて、入力、出力、タイミング、トークン数、コスト、エラーを記録します。結果は、答えが間違ったときに、トレースを開いてツリーを歩くことができるということです。検索が関連のないドキュメントを返したこと、またはツール呼び出しがタイムアウトしてエージェントが推測したこと、またはシステム プロンプトが予期されなかったことを確認します。
これは上記の深さの問題のためにまさに変革的です。トレーシングなしでは、エージェントはエージェントが間違った答えを出すブラック ボックスです。トレーシングで、それはインスペクト可能なステップのシーケンスであり、デバッグは推測ではなくツリーを読むことになります。最も豊かなトレーシング ツールは、セッション全体でマルチターン会話を再構築するため、コンテキストがセッション全体でどのように蓄積されたかを確認でき、スパンごとにトークン使用とコストを表示し、永遠の「なぜ OpenAI の請求書がこんなに高いのか」という質問をミステリーではなくクエリに変えます。
実際的な忠告は、任意の評価作業の前にトレーシングをインストルメント化することです。トレーシングはすべてを他に可能にするものだからです。キャプチャしなかった呼び出しを評価することはできず、見ることができないシステムをデバッグすることはできません。以下で説明するすべてのツールはこの理由でトレーシングをリードしています。
OpenTelemetry シフト
2024 年から 2026 年の LLM 監視における最も重要な構造的変化は、インストルメンテーション標準として OpenTelemetry (OTel) への収束です。初期の監視ツールはそれぞれが独自の SDK を提供しました: ベンダー X のライブラリに対してコードをインストルメント化し、トレースはベンダー X のプラットフォームにロックされました。ツールを切り替えるには、すべてを再度インストルメント化することを意味しました。OpenTelemetry — 従来のインフラストラクチャで既に勝利した同じベンダー中立の監視標準 — そのを変えました。アプリケーションは標準 OTLP 形式でトレースを出力し、OTel 互換のバックエンドがそれらを受け取ることができます。
LLM アプリケーション向けでは、OTel の上に層状化されたセマンティック規約は輸送と同じくらい重要です。OpenInference のような規約は、LLM スパンを表現する 方法 を定義します。プロンプトはどこに行くか、取得ドキュメントを記録する方法、ツール呼び出しをマークする方法。トレースが単に標準形式で輸送されるだけでなく、ツール全体で 意味的に解釈可能 であるようにします。Arize Phoenix はこれにネイティブに構築されています。標準 OTLP でトレースを受け入れ、OpenInference 規約を使用します。つまり、追加するインストルメンテーションは Phoenix 固有ではありません。後で同じトレースを他の場所に送信したい場合は、できます。Langfuse と MLflow も同様に OTel 互換性を受け入れました。
2026 年にツールを選択している誰にとっての戦略的含意は、OpenTelemetry ネイティブ インストルメンテーションを優先することです。これは標準への投資とベンダーへの投資の違いです。OTel に対して 1 回インストルメント化し、監視データはポータブルです。プロプライエタリ SDK に対してインストルメント化し、切り替えコストを購入しました。これはスペース内で最も重要なアーキテクチャ決定であり、OTLP を単に主張することで簡単に正しい方法です。
評価: 目玉焼きで測定できない品質
トレーシングは何が起きたかを示します。評価 は、何が起きたが良かったかどうかを示します。LLM 出力品質はセマンティックであるため、ステータス コードで主張することはできず、本番環境のボリュームのすべての応答を手動で読むことはできません。2026 年の回答はテクニックの組み合わせで、LLM as judge が中心です。
LLM as judge は、ルーブリックに対して出力をスコアリングするために有能なモデルを使用します。この答えは検索されたコンテキストに対して誠実です (つまり、幻覚ではない)、質問に関連しているか、参照に対して正しいか、有毒または安全でないか? DeepEval のようなツールはこれに研究に支持された大規模なメトリクス ライブラリを持ってきました。監視プラットフォームはますますトレース データにこれらの評価を直接折りています。スパンが入力と出力と共に「ハルシネーション: 検出」ラベルを持つことができます。この統合の力は、本番トラフィックをひどくスコアリングされた呼び出しにフィルター化し、トレースを開き、原因を確認できるということです。「品質がドロップ」から「ここは特定の壊れた検索」のループを閉じます。
評価は、異なる目的に供する 2 つのモードで実行されます。オフライン評価 はシップ前に選別されたデータセット上で実行されます。代表的な入力を組み立てる (多くの場合、実際のトレースから収集)、パイプラインを実行し、結果をスコア付けし、前のバージョンと比較します。これはあなたの回帰ゲートです。それはプロンプトまたはモデルの変更がユーザーが感じる前に役立つまたは傷つけたかどうかを示します。オンライン評価 はライブ本番トラフィックに対して実行され、リアル呼び出しをサンプリングし、継続的にスコアリングしているため、オフライン データセットが予想しなかったドリフトと新しい失敗モードをキャッチします。成熟したセットアップは両方を使用します: オフラインで変更をゲート化し、オンラインで現実を監視します。Phoenix、Langfuse、DeepEval ベースのプラットフォームはすべてこのデュアル モデルをサポートし、トレーシング バックエンドとペアリングしているのは、スコアが単なるダッシュボード上の数字ではなく、アクション可能なため。
プロンプト管理とフィードバック ループ
3 番目の機能がスタックを丸くします: プロンプトおよび バージョン管理。LLM 動作はプロンプトによって支配され、プロンプトは常に変わります。多くの場合、デプロイメントを所有するエンジニアではない人によって編集されます。バージョン管理がなければ、3 週間前の品質の後退は追跡不可能です。それを使用すると、評価スコアのドロップを、それを引き起こした正確なプロンプト改訂に相関させることができます。Langfuse はトレーシングと評価とともにプロンプト バージョン管理とビルトイン プレイグラウンドをファースト クラスの機能として扱うことで注目に値しており、そうでなければ開いたままのループを閉じます: トレースで問題を観察し、仮説を形成し、プレイグラウンドでプロンプトを編集し、データセットに対して変更を評価し、より良いスコアを取得するバージョンを提供します。すべて 1 つのシステム内で。
このループ — トレース、評価、調整、再評価 — は LLM 監視の実際のポイントです。個々の機能はそれへの手段です。アプリケーションが行ったことを見ることができるチーム、それが良かったかどうかを測定し、変更を特定の改訂に帰し、データに対して修正を検証し、LLM 開発をバイベース ベースの反復から工学規律に変換しました。その変換、単一機能よりも、2026 年のスタックが提供するものです。
コストおよび トークン監視
LLM 監視を通常の監視から分離する 1 つの次元は、独自の処理に値します: コスト。すべての LLM 呼び出しにはトークンで測定される価格がある。エージェント システムでは、単一のユーザー リクエストは、検索の言い換え、ツール使用推論、マルチエージェント ハンドオフ、再試行によって数十のモデル呼び出しに及ぶ可能性があります。インストルメンテーションなしでは見えない理由で、合計請求書は増加する可能性があります。「推論コストが今月 3 倍になった」という質問は、トレーシングが直接回答するものです。各スパンはトークン数とコストを記録するため、支出を単に機能だけでなく、特定のエージェントの推論の特定のステップに帰すことができます。チームは定期的に発見してのみ、単一の悪く境界が定められた検索ループまたは過度に熱心な再ランク ステップが不相応なシェアのトークン消費を占めていることを発見します。
これはコストを月刊サプライズから最適化できる工学メトリックに変えます。オフライン評価で品質スコアと共に 2 つのプロンプト バージョンのトークン コストを比較でき、品質とコストのトレードオフを推測ではなく明示的に作成できます。リクエストあたりのトークン予算に対してアラートを設定し、ランナウェイ エージェント請求書を請求する前にキャッチできます。低い価値のコール — 実際のお金がかかり、答えをめったに変えない — を識別して、その低い価値のコール — を特定して削除できます。2026 年では、コスト監視は LLM 経済が使用ベースで、使用がトレースなしで不透明であるため、監視スタックの最初のクラスの部分として扱われます。品質を最適化しながらトークン コストを無視する人は、問題の半分を最適化しています。
ツールの選択
3 つの参考ツールは異なるスタート ポイントにマップし、正しい選択はチームが既に配置されている場所に従います。Arize Phoenix は OpenTelemetry ネイティブ トレーシング、評価、特に検索デバッグでリードし、埋め込みおよび RAG 動作の検査に強いサポート。OTel ネイティブ ポータビリティと深い RAG/エージェント デバッグが優先事項の場合、ノートブックから自己ホスト型サーバーまで快適に実行されます。Langfuse は、トレーシングを最初のクラス プロンプト管理およびプロダクト分析センス パーリングし、1 つの自己ホスト型、MIT ライセンス パッケージで完全な監視編集評価ループを望むチームに強力です。MLflow は、LLM トレーシングおよび評価に最も広く採用されている ML プラットフォームを拡張し、ML ライフサイクルの残りの部分に既に標準化された組織の最小抵抗のパスです。トレースとトレース データの所有権のための 1 つのプラットフォームを望んでいます。
これら 3 つを超えて、ランドスケープには、評価ファースト エンド上の DeepEval と Confident AI、OpenTelemetry サポートを備えた Comet Opik、および他の人が含まれています。ただし、選択条件は一貫しています。OpenTelemetry ネイティブ インストルメンテーションに固執し、ロックインされていません。ツールがデータが機密の場合に自己ホストできることを確認します。トレーシング、評価、プロンプト管理がボルト操作されたサイロではなく一緒に機能することを確認します。価値がループにあるため、部分ではありません。そして、既存のスタックが与えられた摩擦を最小化し、実際にデプロイするLLM監視が理想的なものに従う機械で、セットアップするつもりだったもので、セットアップするつもりだったことで始まります。
ボトムライン
LLM 監視は 2026 年に本当の規律になったのは、本番 LLM アプリケーションが非決定的、意味的に不透明、構造的に深い — 通常の監視を破る 3 つのプロパティ。それらに答えるスタックは、エージェント呼び出しツリーを表示可能にするトレーシング、測定品質について目玉焼きで評価すること (LLM as judge、オフラインおよびオンライン)、および原因に変更を帰すためのプロンプト バージョン管理です。OpenTelemetry は、相互運用可能な全体を作成した接続組織です。Phoenix、Langfuse、または MLflow などの OTel ネイティブ ツールを選択するのは、ベンダーではなく標準を購入する方法です。トレーシング トレーシングをインストルメント化し、トップ評価をレイ化し、プロンプト管理でループを閉じます。それにより、LLM アプリはときどき不正なる黒いボックスから実際にエンジニアリングできるシステムに変わります。
参考資料およびリソース
ツール
- Arize Phoenix — GitHub および ドキュメント
- Langfuse — 監視概要
- MLflow およびその エージェント監視ガイド
- DeepEval および OpenTelemetry
背景および分析
関連 1337skills チートシート