LLMオブザーバビリティの標準スタック

TL;DR

• LLM オブザーバビリティは trace / eval / cost の3軸を1つのダッシュボードで見るのが2026年の標準
• 既存の APM（Datadog / New Relic 等）では LLM 特有の指標（hallucination 率・PII 検出・cache hit）が薄い
• 代表的スタック：Langfuse（OSS、SaaS）、Helicone（SaaS）、LangSmith（LangChain統合）、自前 + OpenTelemetry
• 選定基準：trace 粒度・eval 統合・コスト集計の3点で差が出る
• 「APMに後付けする」より「LLM 専用スタックを最初から入れる」方が結果的に安い

この記事の目的と成功基準

• 目的: LLM オブザーバビリティの統合設計を、ツール選定と運用の両面で具体化する
• 想定読者: LLM プロダクトを本番運用する SRE・開発者
• 成功基準: 「LLM オブザーバビリティ」「Langfuse」関連クエリでの流入、LLM本番運用 への回遊

なぜ専用スタックが必要か

Google Cloud Next '26 レポート や NLP2026 参加報告 でも繰り返し触れられているように、LLM 運用は通常のWebアプリ観測とは別軸の指標が必要だ。

通常 APM が見るもの：

• HTTP latency・error rate
• CPU・メモリ
• DB query 時間

LLM 特有の指標：

• プロンプト・コンプリーション（入出力の中身）
• トークン消費（input / output / cache 別）
• 品質スコア（LLM-as-judge）
• 推論時間の分布（モデル別）
• tool 呼び出しの成功率
• hallucination 兆候・PII リーク検出

これを APM に後付けすると、ラベル爆発と保存コストが厳しくなる。LLM 専用スタックを最初から導入する方が運用負荷も安い。

3軸の統合

Trace 軸

1リクエストの内訳を木構造で記録する。

• 親 trace：ユーザーリクエスト
• 子 span：プロンプト生成、LLM 呼び出し、tool 実行、ガードレール判定、後処理
• 各 span に：input / output / 時間 / モデル / トークン数

これがあると「なぜ遅いか」「どこでエラーか」「どこでコストがかかっているか」を一気通貫で追える。

Eval 軸

出力品質を継続評価する。

• LLM-as-judge による自動評価
• ゴールデンセット regression
• ユーザーフィードバック（thumbs up/down）の集計
• 異常パターン検出（ハルシネーション・PII リーク）

trace と紐付けて「品質が落ちた時にどの trace か」が辿れる構造にする。

Cost 軸

トークン消費を多軸で集計する。

• テナント別 / ユーザー別 / 機能別 / モデル別
• input vs output vs cache の内訳
• 日次 / 週次 / 月次の傾向

LLM API料金最適化 で扱った4軸モデルとセットで活用する。

主要ツール比較

Langfuse は OSS で self-host できるため、PII を社外に出せない組織で第一候補。SaaS の手軽さなら Helicone。LangChain ベースなら LangSmith。

実装パターン

Langfuse の最小実装

from langfuse import Langfuse

lf = Langfuse(public_key=..., secret_key=...)

def call_llm(prompt: str, user_id: str):
    trace = lf.trace(name="generate_answer", user_id=user_id)
    gen = trace.generation(
        name="claude-call",
        model="claude-4.6",
        input={"prompt": prompt},
    )
    response = anthropic.messages.create(...)
    gen.end(
        output={"text": response.content[0].text},
        usage={"input": response.usage.input_tokens, "output": response.usage.output_tokens},
    )
    return response

trace と generation を紐付け、後段で eval 結果を追加する。

Eval の統合

def evaluate_generation(trace_id: str, generated: str, golden: str):
    score = judge_model.score(generated, golden)
    lf.score(trace_id=trace_id, name="accuracy", value=score)

trace に score を後付け。日次バッチで全 trace の品質スコアを更新する設計。

Cost ダッシュボード

• テナント別の月次推移
• top-10 機能のコスト
• cache hit rate のトレンド
• 異常 spike のアラート

これを SRE / プロダクトチーム共通の dashboard に出す。

SLO への組み込み

LLM本番運用チェックリスト で扱った3種類の SLO（latency / error / quality）にオブザーバビリティ指標を組み込む：

SLO 違反時のアラートを slack / pagerduty に流す。

監視アラート設計

• LLM API エラー率の急上昇
• eval スコアの急低下
• cache hit rate の低下（プロンプト変更ミス）
• 異常コスト spike（特定テナント・特定機能）
• PII 検出ヒット

これらを LLMガードレール設計 のログとも統合する。

アンチパターン

• trace を全件保存しようとする: 量が膨大、サンプリング必須
• APM に LLM 専用フィールドを増やす: ラベル爆発と保存コストで詰む
• Eval を後から導入: 過去の品質変化が追えない、最初から入れる
• コスト集計のみで終わる: なぜそのコストかが分からない、trace と紐付ける

チーム導入のステップ

1. trace 導入: まず全 LLM 呼び出しを記録
2. cost 可視化: テナント・機能別の集計
3. eval 統合: ゴールデンセット評価のスコアを trace に紐付け
4. アラート設定: SLO 違反時の通知
5. 継続改善: 週次レビューで指標トレンドを確認

FAQ

Q. Langfuse の self-host は運用負荷が高いですか？ A. Docker Compose で立つレベルなので、Postgres + Clickhouse の運用ができるなら現実的です。規模が大きくなったら SaaS 版に移行する選択も普通です。

Q. trace のサンプリング率は？ A. 重要機能は100%、ログレベルは10%、デバッグ目的は1%、というレイヤー分けが推奨です。Eval は別サブセットで100%取ります。

Q. OpenTelemetry の LLM 仕様は使うべきですか？ A. Semantic Conventions for LLM の標準化が進んでいます。長期的に他ツール移行を視野に入れるなら従う価値があります。

まとめ

LLM オブザーバビリティは trace / eval / cost の3軸を統合する専用スタックで設計するのが2026年の標準。Langfuse・Helicone・LangSmith から要件に応じて選び、SLO と組み合わせて運用する。最初から入れることで後付けの倍以上の運用コスト削減につながる。

参考

• Google Cloud Next '26 参加レポート（Zenn / dmmdata）
• NLP2026参加報告（Zenn / knowledgework）
• Langfuse 公式
• Helicone 公式