LLMアプリケーションは、従来のソフトウェアとは異なる壊れ方をします。通常のバグならスタックトレースが出ますが、LLMの「バグ」は、ユーザーから苦情が寄せられて初めて気づく品質ドリフトです。通常のレイテンシー問題なら遅いエンドポイントですが、LLMのレイテンシー問題では、ユーザーがスピナーを見つめる間に30秒間の推論トレースが進みます。
従来の可観測性ツール（Datadog、New Relic、Sentry）は、API呼び出しが8.4秒で成功し、入力トークンを12,847個使用したことを教えてくれます。しかし、回答が良かったか、モデルがハルシネーションを起こしたか、誤ったツールを呼び出したか、先週から品質がドリフトしたかは分かりません。
本番LLMシステムには、異なる可観測性スタックが必要です。少なくとも、従来のスタックの上に追加のレイヤーが必要です。この記事では、何が異なるのか、何を計装するのか、どのようなパターンが有効なのかを解説します。
LLMの可観測性は何が違うのか
従来の可観測性では対処できない、LLMシステム特有の性質がいくつかあります。
単位処理レベルでの非決定性。 同じ入力でも、呼び出すたびに異なる出力が生成されます。ステータスコードを確認するだけでは、「これは正しく動作したか」という問いに答えられません。
主要メトリクスとしての品質。 レイテンシーとコストも重要ですが、最も重要なのは品質であり、測定が最も難しいものでもあります。
複数ステップのトレース。 一つのユーザークエリが、5～50回のLLM呼び出しを発生させる場合があります（エージェントループ、RAG検索、構造化抽出、リフレクション）。各呼び出しは、より大きなトレースの一部です。
トークン単位のコスト変動。 プロンプトのサイズ、出力の長さ、モデルによって、1回の呼び出しは€0.001から€1.00まで変動します。総コストを把握するには、呼び出し単位の帰属が必要です。
時間経過に伴うドリフト。 モデルは更新され、プロンプトは進化し、入力分布は変化します。品質は変動するため、その動きを可視化する必要があります。
機密性の高いペイロード。 入出力は、最も価値の高い診断データである一方、最も機密性の高いデータでもあります。ログ記録には規律が必要です。
長時間の非同期フロー。 数分かかるエージェントの実行、バックグラウンドのバッチジョブ、ストリーミング応答があります。従来のリクエスト／レスポンス型の可観測性は適合しません。
これらは理論上の懸念ではありません。LLMシステムを本番運用するすべてのチームが直面します。
可観測性スタック
完全なLLM可観測性スタックには、次のレイヤーがあります。
1. 呼び出しレベルの計装。 すべてのLLM呼び出しについて、入力、出力、レイテンシー、コスト、モデル、ステータスを記録します。
2. トレースレベルの計装。 複数の呼び出しからなるワークフローをトレースとして結合します。ユーザーリクエストに対する呼び出しチェーン全体を確認できます。
3. アプリケーションレベルのメトリクス。 機能別、ユーザー別、テナント別に集計します。
4. 品質監視。 サンプリングまたは全件を対象に、品質を自動評価します。
5. ユーザーフィードバックの取得。 明示的なシグナル（高評価／低評価）と暗黙的なシグナル（再生成、離脱）を取得します。
6. アラート。 コストの急増、レイテンシーの悪化、品質低下、エラー率上昇についてリアルタイムで通知します。
7. デバッグツール。 問題が起きたとき、トレースを特定し、入出力を確認して、何が起きたかを理解できます。
それぞれを詳しく見ていきます。
呼び出しレベルの計装
すべてのLLM呼び出しで、次のようなログレコードを生成します。
{
"call_id": "uuid",
"timestamp": "2026-05-15T14:23:45Z",
"trace_id": "uuid", // トレースとしてグループ化するために使用
"span_id": "uuid", // 親子関係を表すために使用
"feature": "summarize_document",
"prompt_version": "v3.2",
"model": "claude-4-sonnet",
"provider": "anthropic",
"input_messages": [...],
"output_message": "...",
"input_tokens": 1842,
"output_tokens": 384,
"total_tokens": 2226,
"cost_usd": 0.0084,
"latency_ms": 2340,
"first_token_ms": 1240, // ストリーミング
"status": "success",
"error": null,
"user_id": "user_123",
"tenant_id": "tenant_45",
"metadata": {
"session_id": "...",
"experiment_arm": "v3_test"
}
}
これが最低限です。すべて取得してください。
実装上の重要な選択肢は次のとおりです。
どこに記録するか。 選択肢は次のとおりです。
- 専用の可観測性ツール（Helicone、LangSmith、Phoenix、Braintrust、Arize）。
- LLM拡張を備えた汎用可観測性プラットフォーム（Datadog LLM Observability、Sentry）。
- 独自のログ／データベース。
大半のチームには、専用ツールを選ぶことを勧めます。LLM呼び出しの調査に特化したUIを備えており、独自構築と比べて学習負担も軽微です。
大規模なチームでは、併用が適しています。LLM専用UIには専用ツールを使いながら、システムをまたぐ相関分析のため、中央の可観測性プラットフォームにもデータを送ります。
どのように計装するか。 選択肢は次のとおりです。
- アプリとLLMプロバイダーの間に置くプロキシ（Heliconeの方式）。
- アプリケーションコードに組み込むラッパーSDK。
- LLMの呼び出しごとに手動で使用するラッパークラス。
プロキシは最も簡単ですが、レイテンシーが増えます。SDKはきれいに統合できますが、組み込み作業が必要です。手動ラッピングは最も柔軟ですが、適用漏れが最も起きやすい方法です。
実践的な方法は、アプリからLLMを呼び出す境界でSDKによってラップすることです。一か所を計装すれば、ほかはすべてそこを通ります。
何を記録するか。 実践上の考慮事項は次のとおりです。
- 非常に長い入出力は切り詰めます（切り詰めた事実は記録します）。
- PIIはハッシュ化または編集除去します（必要に応じて、安全な検索手段で原文を取得できるようにします）。
- エラー経路であっても、認証情報を記録しないでください。
- ストリーミングでは、最初のトークンまでのレイテンシーと総レイテンシーの両方を記録します。
トレースレベルの計装
一つのユーザー操作には、多数のLLM呼び出しが伴うことがよくあります。トレースレベルの計装がなければ、何千件もの呼び出しログがあっても、どの呼び出しがどのユーザー操作に属するのか分かりません。
実装方法は次のとおりです。
トレースIDの生成。 ユーザーリクエストの開始時に、一意のトレースIDを生成します。その後のすべての呼び出しに引き継ぎます。
親子関係を持つスパン。 トレース内の各呼び出しには、スパンIDと、必要に応じて親スパンIDを付けます。これにより、呼び出し階層を示すツリーが作られます。
操作の命名。 各スパンに名前を付けます（"summarize_document"、"extract_entities"、"tool_call:search"）。トレースには、操作チェーン全体が表示されます。
UI上のトレース表示は次のようになります。
トレースabc-123（合計12.3秒）
├─ classify_intent（450ms）[gpt-5-mini]
├─ retrieve_documents（1.2s）[embedding + search]
├─ generate_response（8.5s）[claude-4-sonnet]
│ ├─ tool_call: search_internal（320ms）
│ ├─ tool_call: lookup_customer（180ms）
│ └─ generate_final_text（7.5s）
└─ judge_response_quality（2.1s）[claude-4-haiku]
これで、このユーザーリクエストに対してシステムが実際に何をしたかを確認できます。遅い呼び出し、高額な呼び出し、失敗した呼び出しを、コンテキストの中で特定できます。
これを得意とするツールには、LangSmith、Phoenix（Arize）、カスタム統合を加えたHeliconeがあります。システムをまたぐトレーシングには、汎用可観測性ツール（Datadog、OpenTelemetry）も利用できます。
アプリケーションレベルのメトリクス
個々の呼び出しに加えて、次のメトリクスを集計します。
機能別。
- 呼び出し数。
- 平均レイテンシー。
- p50、p95、p99レイテンシー。
- リクエストあたりの平均コスト。
- エラー率。
- 品質スコア（測定している場合）。
ユーザー別／テナント別。
- ユーザーあたりの1日の呼び出し数。
- ユーザーあたりのコスト。
- ヘビーユーザー／不正利用のパターン。
モデル別。
- モデル別の利用量。
- モデル別のコスト比率。
- モデル別のエラー率。
- モデル別の品質（測定している箇所）。
機能別 × モデル別。
- どの機能がどのモデルを使用していますか。
- どこをより安価なモデルにルーティングできますか。
これらのダッシュボードが運用上の意思決定を支えます。どの機能が高額か、どれが遅いか、どこに最適化が必要かを把握できます。
品質監視
最も難しいレイヤーは、品質の自動評価です。
評価（別の記事で解説しています）は、定義済みのデータセットに対して実行します。オンライン品質監視では、本番トラフィックを評価します。
アプローチは次のとおりです。
サンプルに対するLLM-as-judge。 たとえば、本番トラフィックの1%をサンプリングします。それぞれについて、関連する次元で回答を採点するジャッジLLMを実行します。スコアを時系列で追跡し、低下時にアラートを出します。
暗黙的なシグナル。 再生成、離脱、エラー率、完了までの時間、フォローアップメッセージの頻度を追跡します。弱いシグナルですが、安価です。先行指標として利用します。
明示的なユーザーフィードバック。 高評価／低評価、「役に立ちましたか」ボタン、明示的な報告です。最も強いシグナルですが、量は最も少なくなります。
パターン検出。 特定の好ましくないパターン（「お手伝いできません」「私は単なるAIです」、拒否の繰り返し）を自動的にフラグ付けします。一部のリグレッションを即座に検出できます。
一般的な構成は次のとおりです。
- 本番呼び出しの1%をサンプリングします。
- 各呼び出しにLLMジャッジを実行し、複数の次元で採点します。
- 機能ごとの日次スコアに集計します。
- 前週比で10%を超えて低下した機能があればアラートを出します。
コストは実際に発生しますが、上限を設けられます（トラフィックの1% × 小型ジャッジモデルであれば、大半のチームにとって管理可能です）。
コストの可観測性
LLMのコストは際限なく膨らむ可能性があります。暴走する再試行ループや、想定の10倍のトークンを使用する機能など、たった一つのバグによって、気づく前に請求額が10倍になることがあります。
コストの可観測性を構成するレイヤーは次のとおりです。
呼び出し単位のコスト。 各呼び出しのコストをログ記録時に計算し、すぐに集計できるようにします。
予算アラート。 機能別／テナント別に日次、週次、月次の予算を設定します。しきい値（50%、75%、90%、100%）を超えたときに通知します。
異常検知。 日次コストが通常の5倍なら通知します。1回の呼び出しコストが通常の100倍でも通知します。
コストの帰属。 機能別、テナント別、ユーザー別のコストを把握し、大量消費者を特定します。
予測。 現在の推移に基づき、月末の請求額を予測します。
有用なダッシュボード表示の一例は、今日のコスト、今週の残りの予測、先週のコストを機能別に分けて一つのパネルに表示することです。
実践的なヒントとして、可能な箇所にはハードリミットを設定します。1日€Xのはずの機能は、10Xに達したら自動停止させます。コストの暴走は速いため、リミットで食い止めます。
レイテンシーの可観測性
LLMのレイテンシーは、一般的なAPIより複雑です。
総レイテンシー。 リクエストから最終応答までの時間です。
最初のトークンまでの時間（TTFT）。 ストリーミング時に、ユーザーが最初の文字を見るまでの時間です。チャットUXで知覚されるレイテンシーを大きく左右します。
最後のトークンまでの時間（TTLT）。 応答が完了するまでの時間です。
1秒あたりのトークン数。 出力速度です。一部のモデルは、ほかのモデルよりストリーミングが遅くなります。
ツール呼び出しのレイテンシー。 エージェントフローで、ツール呼び出しとLLM呼び出しにそれぞれ費やした時間です。
これらをすべて追跡します。最適化戦略は、対象とするメトリクスによって異なります。
ユーザー向けチャットでは、TTFTが重要です。最初のトークンが遅いと壊れているように感じますが、1秒あたりのトークン数が少ない場合は徐々に進んでいるように感じます。
バッチ処理では総レイテンシーが重要で、スループットはさらに重要です。
エージェントでは、ツール呼び出しのレイテンシーが支配的なことも少なくありません。ツールが遅い場合、LLMを最適化しても役に立ちません。
エラーの可観測性
LLM固有のエラーは次のとおりです。
APIエラー。 レート制限、認証失敗、サーバーエラーです。ほかのAPIと同様です。
検証エラー。 構造化出力がスキーマに適合しなかった場合です。機能別に頻度を追跡します。
コンテンツフィルターエラー。 プロバイダーがリクエストをブロックした場合です。プロンプトの問題を検出するために追跡します。
ツールエラー。 特定のツールが失敗した場合です。ツールごとに追跡します。
品質エラー。 ジャッジLLMが出力を低品質と判定した場合です。時系列で追跡します。
ハルシネーションのシグナル。 ハルシネーションの可能性を検出した場合です（モデルがソースにないことを主張した場合など）。自動検出は困難ですが、近似は可能です。
コストエラー。 想定を大きく超えるコストがかかった呼び出しです。多くの場合、バグを示しています。
それぞれに専用のダッシュボードを用意し、必要に応じてアラートを発火できるようにします。
デバッグツール
問題が起きたときは、それを特定して理解する必要があります。デバッグ機能には次のものがあります。
トレース検索。 トレースID、ユーザーID、タイムスタンプから、特定のユーザーリクエストを検索します。
呼び出しインスペクター。 任意の呼び出しについて、リクエスト、レスポンス、パラメーター、レイテンシー、コストをすべて確認します。
トレースタイムライン。 複雑なフローについて、呼び出しチェーンを視覚的に確認します。
リプレイ機能。 過去の呼び出しを、異なるプロンプトやモデルで再実行し、何が起きたはずかを確認できるようにします。修正のテストに不可欠です。
差分表示。 同じプロンプトの異なるバージョンや異なるモデルによる二つの呼び出しを、横に並べて比較します。
内容による検索。 過去の呼び出し群から特定のパターンを検索します（「モデルが『お手伝いできません』と述べた呼び出しを表示」など）。
これらは、LLM専用の可観測性ツールが提供する機能です。独自構築には相当な作業が必要であり、通常はツールを使用する方が安価です。
プライバシーとPII
LLMの可観測性ログには機密情報が含まれます。入力にPIIが含まれ、出力がPIIを引用する場合もあります。デバッグに必要なため、記録を避けられないこともあります。
実践すべき対策は次のとおりです。
トークン化／ハッシュ化。 識別子をトークンに置き換えます。原文は別の安全な検索手段で取得できるようにします。ログの大半からPIIを排除できます。
ログ記録時の編集除去。 可観測性ストレージに保存される前に、PIIを検出して除去します。メールアドレス、電話番号、社会保障番号（SSN）などの特定パターンをプレースホルダーに置き換えます。
テナントの分離。 マルチテナントの可観測性データをテナントごとに分離します。あるテナントのデータを別のテナントから見えないようにします。
アクセス制御。 生の入出力を閲覧できる人を制御し、そのアクセスを記録します。
保持方針。 X日を超えたログは削除するか、コールドストレージへ移します。多くの法域では、PIIの保持期間に法的な制限があります。
忘れられる権利。 ユーザーから削除要求（GDPR）があった場合、そのユーザーのログを特定して削除できなければなりません。
PIIを扱うシステムでは、これらは任意ではありません。早期に正しく設計してください。後付けは困難です。
アラート
アラートを出すべきしきい値とシグナルは次のとおりです。
コスト。
- 日次コストが通常の2倍を超える。
- 1回の呼び出しコストが€5を超える。
- 1時間のコストが5倍を超えて急増する。
レイテンシー。
- p95レイテンシーがベースラインの2倍を超える。
- チャットUXでTTFTが5秒を超える。
- ツール呼び出しのタイムアウトが増加する。
エラー率。
- エラー率が1%を超える（一般的なベースラインは0.1～0.5%）。
- 特定のエラー種別（検証エラー、レート制限）が急増する。
品質。
- いずれかの機能で、品質スコアが前週比10%を超えて低下する。
- ユーザーフィードバックの否定的評価率がベースラインを超える。
- 再生成率がベースラインを超える。
パターン。
- 特定の好ましくない表現の出現頻度が増える。
- 入力分布が突然変化する。
各アラートは具体的で、対処可能でなければなりません。「コストが高い」では役に立ちません。「過去30分で機能Xのコストが予算の10倍に達しました。顧客Yのセッションで暴走している可能性があります」であれば対処できます。
マルチテナントでの考慮事項
B2B SaaSアプリでは、次の機能が必要です。
テナント別のメトリクス。 各顧客が自分の使用量、コスト、品質を確認できます。
テナント別のアラート。 顧客ごとのしきい値に基づいて通知します。
テナント別のデバッグ。 適切なアクセス制御のもとで、サポート担当者が顧客のトレースを確認できます。
テナント別の設定。 顧客ごとにモデル、プロンプト、方針が異なる場合があります。可観測性レイヤーにもそれを反映します。
複雑さは増しますが、大規模なB2Bでは不可欠です。テナント別のトレースにアクセスできなければ、カスタマーサポートは「自分の環境ではAIが動かない」という問題をデバッグできません。
ツールのエコシステム（2026年）
執筆時点におけるLLM可観測性ツールの全体像は次のとおりです。
LLM専用の可観測性：
- Helicone。 プロキシベースで、統合が簡単です。強力なダッシュボードを備えています。
- LangSmith。 LangChainのエコシステムと密接に統合され、詳細なトレーシングを提供します。
- Phoenix（Arize）。 オープンソースとの親和性が高く、品質監視に強みがあります。
- Braintrust。 評価と可観測性の組み合わせに強みがあります。
- PromptLayer。 プロンプトに重点を置き、バージョン追跡に強みがあります。
- Weights & Biases Weave。 MLチームに適しており、W&Bの幅広い製品群と統合できます。
LLM拡張を備えた汎用APM：
- Datadog LLM Observability。 エンタープライズ品質ですが、高額です。
- New Relic LLM Observability。 同様の特徴があります。
- OpenTelemetry + 任意のAPM。 OTelにはGenAIセマンティック規約があります。一度計装すれば、多数のツールで表示できます。
独自構築：
- 呼び出しごとに1行を保存するPostgresテーブルだけでも、大半のチームはかなり先まで進めます。
- 検索と表示のためのシンプルなUIを追加します。
- 既存のログ基盤と統合します。
適切な選択肢は、チーム規模、システム規模、予算、既存ツールによって異なります。大半のチームは専用ツールから始め、規模の拡大に伴って、より包括的な構成へ移行します。
実践的な導入構成
ゼロから始める一般的な中規模チームでは、次のように進めます。
第1週： ツールを選びます（Heliconeは、導入しやすい一般的な選択肢です）。主なLLM呼び出し経路に統合し、呼び出しが記録されていることを確認します。
第2週： 基本的なダッシュボードを設定します。機能別のコスト、レイテンシー、エラー率を表示します。
第3週： コストの急増とエラー率の上昇に対するアラートを設定します。
第4週： トレースレベルの計装を追加します。複数呼び出しのフロー全体でスパンを接続します。
第2か月： 品質サンプリングを実装します。いくつかの機能を選び、トラフィックの1%に対するLLM-as-judgeのスコアリングを設定します。
第3か月： ユーザーフィードバックの取得を追加します。高評価／低評価などの機能を接続します。
第4か月： マルチテナント対応、きめ細かなアラート、デバッグツールを追加します。
これで実用的な可観測性スタックになります。各レイヤーが機能を追加し、どれも構築する価値があります。一つでも省けば、死角が生じます。
可観測性がなければ何が起きるか
適切なLLM可観測性を備えていないチームで繰り返し発生するインシデントのパターンを簡潔に紹介します。
-
バグによって、ある機能が間隔を空けずに呼び出しを再試行しました。週末の間に、予期しない5桁の請求が積み上がりました。月次請求書が届いて初めて発覚しました。（この種の事例には多数の変種があり、具体的な金額よりパターンそのものが重要です。）
-
モデルの更新によって、挙動が通知なく変わりました。主要機能の品質が低下しました。ユーザーから苦情が寄せられても、エンジニアリングチームは「たまに起きる奇妙な挙動」だと考えました。モデル変更との相関に気づくまで2か月かかりました。
-
新しいプロンプトバージョンをデプロイしたところ、重要なユーザーフローに誤ってリグレッションが生じました。フロー単位のメトリクスがなかったため、数週間にわたって誰も気づきませんでした。
-
エージェントシステムがループを始めました。一部のユーザーセッションでは、LLM呼び出しが200回を超えました。トレースレベルの計装がなかったため、ループの特定に何時間もの調査を要しました。
-
ツールの認証失敗が連鎖し、エージェントが混乱しました。エージェントは「さまざまな方法を試し」続け、コストを増やしました。アラートがなかったため、これが数時間続きました。
-
プロンプトインジェクションによって、AIがシステム指示を漏えいしました。PIIも開示されました。可観測性がなかったため、影響を受けたユーザーを容易に特定できませんでした。
これらは理論上の話ではなく、実際に起きています。可観測性があれば、その多くを予防するか、迅速に検出できます。
インシデントの前に計装する
LLMの可観測性は、それ自体が一つの専門分野です。従来のAPMは必要ですが、それだけでは不十分です。呼び出しレベル、トレースレベル、品質、コスト、レイテンシー、エラー、デバッグという固有のレイヤーがすべて必要です。
ツールはすでに存在します。一つ選び、早期に統合してください。ユーザーが気づく前に問題を検出するダッシュボード、アラート、プロセスに投資してください。
これを実践するチームは、次の成果を得られます。
- 数週間ではなく、数時間でバグを検出します。
- 予期しない請求を受けるのではなく、コストを予測可能な形で管理します。
- ドリフトを放置せず、長期にわたって品質を維持します。
- 推測ではなく、体系的にデバッグします。
実践しないチームも、いずれインシデントに直面し、導入せざるを得なくなります。インシデント後ではなく、その前に計装する方が賢明です。
