先に要点
- LLM アプリの観測性は 普通の Web アプリの観測性 + LLM 固有のメトリクス の二段構え。「レイテンシ」 「 エラー率」 「 リソース」 に加え、トークン消費」 「 コスト」 「 ハルシネーション率」 「 ユーザー評価」 「 プロンプト内容 を計測する必要がある。
- OpenTelemetry に GenAI セマンティック規約 が追加され、「LLM 呼び出しを標準形式で観測する仕組み」 が整いつつある。「独自実装ではなく業界標準に乗る」 のがベンダーロックインを避ける現代的アプローチ。
- 計測すべき 5 軸: 入力 / 出力トークン数 」 「 モデル別コスト」 「 TTFT(Time To First Token)とエンドツーエンドレイテンシ」 「 ハルシネーション / 品質スコア」 「 ユーザーフィードバック(thumbs up/down)。
- LLM 観測に特化したツール: LangSmith」 「 Langfuse」 「 Helicone」 「 Phoenix(Arize)」 「 W&B Traces。「プロンプト / レスポンス / 中間ツール呼び出し」 を時系列で追える。「Datadog / Grafana」 のような汎用観測ツールも GenAI 拡張を追加中。
- 運用上の注意: プロンプトに含まれる機密情報のマスキング」 「 大量トークンによるコスト暴発の予防(月予算 / リクエストごとの上限)」 「 ユーザーフィードバックを学習に活かす仕組み。「観測するだけで終わらず、フィードバックループに繋げる」が本質。
`LLM を組み込んだアプリを本番運用したら、「月の請求がいきなり数百万」 「 ハルシネーションでユーザークレーム頻発」 「 どこで遅いか分からない」 ── 初めて LLM アプリを動かすチームがほぼ全員ぶつかる問題です。
ざっくり言うと、LLM アプリの観測性は 普通の Web アプリ観測性に LLM 固有のメトリクスを足す 二段構えです。「普通の観測性」 については OpenTelemetry とは？ で扱いましたが、LLM では トークン消費 / コスト / ハルシネーション / ユーザー評価 という追加軸の計測が必須になります。
この記事では、LLM アプリで 何を計測すべきか 「 どのツールで計測するか」 計測したデータをどう改善に活かすか を実務目線で整理します。
なぜ普通の観測性だけでは足りないか
「 Datadog / Grafana / New Relic」 で十分では?と思うかもしれませんが、LLM アプリには 固有の課題があります。
コストが入力データで激変する
` 通常の API は 「リクエスト数 = コスト」 でほぼ比例」 ですが、LLM は 「1 リクエストあたりのトークン数」 で 100 倍の差が出る。「プロンプトテンプレートを変えただけで月コストが 10 倍」 のような事故が頻発する。「トークン数の計測」 が必須。
出力品質が変動する
「 LLM は同じ入力でも違う出力を返す」 確率的な性質。「ハルシネーション(嘘の生成)」 「 品質の劣化(モデルアップデートで急に弱くなる)」 が起きるので、出力品質を継続観測する 必要がある。
レイテンシの内訳が複雑
「 LLM 呼び出しのレイテンシ」 は 「推論時間 + ネットワーク + キューイング」 の合計。ストリーミング応答だと 「TTFT(最初のトークンまでの時間)」 と 「全体の完了時間」 が別指標 になる。「普通の HTTP レイテンシ計測では情報不足」。
計測すべき 5 軸
LLM アプリで観測する 追加メトリクスを 5 つに整理します。
| 軸 | 具体的なメトリクス | 何を見るか |
|---|---|---|
| ① トークン消費 | 入力トークン数、出力トークン数、合計トークン数 | 「 リクエストごと」 「 ユーザーごと」 「 機能ごと」 の消費を把握 |
| ② コスト | 「 モデル別 単価 × トークン数 = コスト」 | 「 どの機能 / どのユーザー / どのプロンプト」 が高コストか |
| ③ レイテンシ | TTFT(Time To First Token)、全体完了時間、推論時間 | 「 ストリーミング」 と 「非ストリーミング」 を別指標で |
| ④ 品質 | ハルシネーション率、ファクト チェック評価、ユーザー評価(thumbs up/down) | 「 出力の質が時間で劣化していないか」 「 ユーザー満足度」 |
| ⑤ プロンプト / レスポンス | 実際の入出力テキスト(マスキング済み) | 「 なぜこの出力になったか」 を追跡可能に |
「普通の観測性メトリクス(エラー率、CPU、メモリ)」 と組み合わせて、「LLM アプリ固有の異常」 を捉えるのが本質。
OpenTelemetry GenAI セマンティック規約
「 LLM 観測も標準化されつつある」 のが 2026 年時点の状況。OpenTelemetry に GenAI セマンティック規約が追加されました。
標準属性
「 gen_ai.system(プロバイダ名:openai / anthropic / aws-bedrock)」 「 gen_ai.request.model(モデル名)」 「 gen_ai.usage.input_tokens」 「 gen_ai.usage.output_tokens」 「 gen_ai.response.finish_reasons」 などの 標準属性が定義済み。
SDK レベルの計装
「 OpenAI SDK」 「 Anthropic SDK」 「 LangChain」 「 LlamaIndex」 など主要ライブラリが OpenTelemetry 計装を組み込み。SDK 呼び出しが自動で span として記録され、トークン使用量も自動収集。
ベンダーロックイン回避
「 計装は OTel 標準」 で書いておけば、「Datadog / Grafana / LangSmith / Langfuse / Phoenix 」 などどのバックエンドにも送れる。LLM 観測ツールを試して合わなければ別ツールに切り替え が容易。
採用状況
「 Datadog」 「 Grafana」 「 New Relic」 「 Honeycomb」 などが既に GenAI セマンティック規約に対応。普通の APM 画面で LLM 呼び出しを追える ようになっている。
LLM 観測に特化したツール
汎用観測ツールに加え、LLM 観測に特化したツールも成熟。プロンプト / レスポンスを時系列で追える UI を提供。
| ツール | 特徴 | 典型用途 |
|---|---|---|
| LangSmith(LangChain) | LangChain と統合された観測 + 評価プラットフォーム | LangChain ベースのアプリ開発 |
| Langfuse | OSS、セルフホスト可能、UI が洗練 | 「 データを自社で持ちたい」 組織 |
| Helicone | プロキシ型(LLM API の前段に立つ)、計測 + キャッシュ | 「 既存コードを書き換えずに観測を入れたい」 |
| Phoenix(Arize) | OSS、ハルシネーション検出 / RAG 評価が強い | RAG パイプラインを使うアプリ |
| W&B Traces(Weights & Biases) | ML / LLM の実験管理と統合 | 研究開発寄り、A/B テスト多用 |
| Datadog / Grafana / Honeycomb | 汎用観測ツール、GenAI 拡張対応 | 既存の APM と統合したい |
「専用ツール vs 汎用ツール」 の選択は、「観測したい深さ」 と 「組織の標準ツール」 のバランスで決まる。「既に Datadog で全体を観測している組織」 は Datadog の GenAI 拡張、「LLM アプリ開発が中心」 なら LangSmith / Langfuse がはまる。
コスト暴発を防ぐ仕組み
LLM 観測の 最大の実用的価値はコスト管理。具体的な仕組みを整理します。
月予算アラート
「 Anthropic / OpenAI コンソール」 で 月予算上限 + 警告閾値(80%) を必ず設定。「予算を超えたら API が止まる」 設計にしておく。設定し忘れると突発的なバズで請求が桁違いに伸びる。
リクエストあたりのトークン上限
「 max_tokens」 をリクエストごとに明示。「デフォルトの 4000 トークン」 でも 「1 リクエスト数十円」 になる。用途別に適切な上限を設定(チャットなら 1000、要約なら 500、など)。
ハルシネーション検出
「LLM が嘘の情報を生成」 を検出する仕組みも観測の重要要素。
ファクトチェックエージェント
` 別の LLM が 「この回答に事実誤認はないか」 を評価」 する仕組み。「複数の LLM の合意度」 や 「引用根拠の妥当性」 をスコア化。「Phoenix」 「 RAGAS」 などのツールが提供。
RAG の引用元検証
` RAG(Retrieval-Augmented Generation)で 「回答に含まれる事実が、検索した文書に含まれているか」 を検証」。文書に無い事実を作っていないか を自動チェック。
ユーザーフィードバック
「 各回答に thumbs up / down ボタン」 を付け、` ユーザーが 「これ違うんだけど」 と感じた回答を捕捉」。「down が多い質問パターン」 を分析してプロンプトや RAG を改善。
人間レビューサンプリング
「 全レスポンスの一定割合(1%)を人間がレビュー」 して、「ハルシネーション率の実測値」 を持つ。「機械的検出だけでは見つからない問題」 を人間が捕捉。品質低下を早期発見。
プロンプト / レスポンスの保存とプライバシー
「 プロンプト / レスポンスをログに残す」 と 個人情報・機密情報が記録されるリスクがあるので、「保存時の設計」 が重要。
「 メールアドレス」 「 電話番号」 「 クレジットカード」 「 住所」 などを 保存前にマスキング。「サニタイズ」 の発想と同じ。Presidio(Microsoft OSS)」 「 各社の PII 検出 API が利用可能。
保存期間の制限
「 30 日後に自動削除」 のような保存期間ポリシー。必要以上に持たない ことで漏洩時の影響を最小化。S3 のライフサイクル を活用。
サンプリング
` 全リクエストではなく、「一定割合を保存」 で容量とプライバシーリスクを抑える」。「エラー時 / 評価 down 時 / ハルシネーション疑い時は 100% 保存」 のような選択的サンプリング。
フィードバックループ ── 観測を改善に繋げる
「観測するだけで終わらず、改善に繋げる」 のが本質。
「観測 → アラート → レビュー → 改善 → A/B → 振り返り」 のループを回すことが、「LLM アプリを本番運用で安定させる」 唯一の道です。
LLM 観測性に関するよくある質問
Q. 観測ツールはどれを選ぶべき?
A. 既存の APM があれば、その GenAI 拡張から始める のが楽。「Datadog / Grafana」 を使っているならまずそれを試す。「LLM 開発が中心」 なら LangSmith / Langfuse が高機能で UI も洗練。「プロキシ型で既存コード変えず観測したい」 なら Helicone。「 OpenTelemetry で計装」 しておけばツール切替が楽。
Q. トークン課金を予算管理する一番確実な方法は?
A. 「 プロバイダ側の月予算上限機能 + アプリ側のリクエスト数制限 + ユーザー単位レート制限」 の三段構え。「どれか 1 つでは突発バズを防げない」。「 月予算到達で API が止まる」 設定が最後の砦。
Q. プロンプトの内容を保存していいですか?
A. マスキング + 保存期間制限 + アクセス制御」 を前提に保存。「機密情報を含む可能性がある場合は、保存前に PII 検出してマスキング」 する。「保存期間は 30〜90 日を目安に短く設定」。プライバシーポリシーに保存する旨を明示。
Q. ハルシネーション率はどうやって測る?
A. 完全自動測定は困難、「サンプリング + 人間レビュー + LLM-as-judge」 の組み合わせ。「Phoenix」 や 「RAGAS」 のような評価ツールで 「 RAG 引用の妥当性」 を自動評価できる。「人間レビューで月数十件サンプリング」 で実測値を持つのが信頼性確保の現実解。
Q. ストリーミング応答の観測はどう違う?
A. TTFT(Time To First Token)を別指標として計測。ストリーミングでは 「全体完了時間」 が長くても TTFT が早ければ UX 良好」 という特性がある。OpenTelemetry の span で 「first_token_at」 属性を記録」 する設計が定石。
Q. RAG のパフォーマンスはどう観測?
A. 検索フェーズと生成フェーズを別 span に分ける。「Retrieval Time(検索時間)」 「 Retrieved Documents(取得文書数 / 関連性スコア)」 「 Generation Time(生成時間)」 を別々に記録。検索が悪いから回答が悪い vs 生成が悪い を切り分けられる。
Q. プロンプト改善のための A/B テストはどう設計?
A. ユーザーセグメント分割 + メトリクスの比較。「プロンプト A は 50% ユーザー、プロンプト B は 50% ユーザー」 で配信し、「 品質スコア / トークン消費 / ユーザー評価」 を比較。LangSmith / W&B Traces のような実験管理ツールで、「複数バージョンの並列比較」 が楽になる。
まとめ
LLM アプリの観測性は 普通の Web アプリ観測性 + LLM 固有メトリクス の二段構えです。「トークン消費 / コスト / レイテンシ / 品質 / プロンプト」 を計測し、「コスト暴発 / ハルシネーション / 品質劣化」 を早期発見する仕組みが、本番運用の必須条件になります。
「OpenTelemetry の GenAI セマンティック規約に乗る」 のが、「ベンダーロックイン回避 + 業界標準化」 の現代的アプローチ。「LangSmith / Langfuse / Helicone のような専用ツール」 と 「Datadog / Grafana のような汎用 APM」 を組織のスタックに合わせて選び分ける。「観測するだけで終わらせず、毎週レビュー → 改善 → A/B → 月次振り返り」 のループを回すことが、LLM アプリを本番で安定運用する唯一の道です。
参考リンク
- OpenTelemetry: GenAI Semantic Conventions
- LangSmith: LangSmith Documentation
- Langfuse: Langfuse Docs
- Phoenix(Arize): Phoenix Documentation
- Helicone: Helicone Documentation