LLM アプリに「いつもの APM」は通用しない
LLM アプリケーションを本番運用するエンジニアが最初に気付くのは、Datadog APM や New Relic のような既存 APM では LLM 特有の情報（プロンプト、トークン数、ツール呼び出し、幻覚の有無、cache hit／miss）がほぼ可視化されないことだ。HTTP リクエストのレイテンシは取れても、「このリクエストはなぜ 8 秒かかったのか？」に答えられない。
- 年の解は「OpenTelemetry の拡張として LLM 用セマンティック規約を統一する」方向に収束した。OpenLLMetry（Traceloop）と OpenInference（Arize）という 2 つの規約が並立していたが、2025 年後半に両者が属性名の互換レイヤーを提供し、どちらを採用しても後からバックエンドを差し替えられるようになった。本稿ではこの前提で、具体的な配線と運用 Tips を記す。
OpenLLMetry / OpenInference の違いと共通点
共通点: どちらも OpenTelemetry のスパン属性として gen_ai.* 名前空間（OpenLLMetry）または llm.* 名前空間（OpenInference）を使い、以下を最低限トレースする。
- 入力プロンプト（system/user/assistant の各メッセージ）
- 出力応答
- トークン数（入力／出力／キャッシュ読取／キャッシュ書込）
- モデル名、温度、top_p 等ハイパラ
- ツール呼び出し（関数名、引数、結果）
- ベクトル検索（クエリ、上位 k、結果 ID 列）
違い: OpenLLMetry は「OTel の正統」寄りで、属性名が冗長だが OTel Collector に素通しできる。OpenInference は「ML 寄り」でプロンプト／レスポンスを構造化 JSON に正規化する傾向が強く、eval 系ツール（Phoenix）への取り込みが自然。
KGA の推奨は「新規案件は OpenInference、既存の OTel パイプラインに統合する案件は OpenLLMetry」。どちらを選んでも gen_ai.request.model のような属性で串刺しクエリ可能なバックエンドを選べば移行で痛まない。
最低限トレースすべきスパン属性
プロダクション運用で必須と考えている属性セットは次の通り。
リクエスト基本情報 - gen_ai.system: "anthropic", "openai", "bedrock", "vertex", "self-hosted-vllm" - gen_ai.request.model: "claude-opus-4-7", "gpt-4.1", "llama-3.3-70b-fp8" - gen_ai.request.temperature, gen_ai.request.top_p, gen_ai.request.max_tokens - gen_ai.conversation.id: 対話 ID（マルチターン追跡用） - app.feature: "summarize", "chat", "code-review"（機能別コスト按分の鍵） - app.tenant_id, app.user_id（マルチテナント分離用、PII ポリシー注意）
トークン会計 - gen_ai.usage.input_tokens - gen_ai.usage.output_tokens - gen_ai.usage.cache_read_input_tokens（Claude／OpenAI の prompt cache） - gen_ai.usage.cache_creation_input_tokens - gen_ai.cost.usd（各プロバイダの単価表から計算、後述）
レイテンシ分解 - gen_ai.server.time_to_first_token_ms - gen_ai.server.inter_token_latency_ms - gen_ai.server.total_duration_ms
ツール・検索 - gen_ai.tool.name, gen_ai.tool.call_id, gen_ai.tool.arguments, gen_ai.tool.result - retrieval.query, retrieval.documents (JSON 配列), retrieval.score.top1
これらを OTel スパンの子スパンとして階層化すると、「このユーザーのこの会話のこのターンで、どのツール呼び出しが何秒かかり、いくらだったか」が一画面で見える。
Langfuse, Helicone, Phoenix, Weave の使い分け
Langfuse: OSS 版が充実しており、セルフホスト運用がしやすい。プロンプト管理、eval、コスト分析、ユーザースコアリングまで 1 ツールで完結する。日本のスタートアップで最も普及。ClickHouse をバックエンドに持つため、数億スパンでもサブ秒クエリが可能。
Helicone: プロキシ型が特徴で、OpenAI/Anthropic API をラップする形で導入できる。アプリコード改修がほぼ不要で、PoC 段階に圧倒的に早い。ただしセルフホスト版は機能制限があり、本格運用は SaaS 前提。
Arize Phoenix: eval 特化で、特に RAG の品質監視、埋め込みのドリフト検知に強い。Production monitoring としての OpenInference 規約の本家で、LLM の「精度低下」を早期発見したいケースに最適。
W&B Weave: Weights & Biases の LLM 版。学習実験管理（W&B 本体）とのシームレス連携が強みで、「モデル更新前後の挙動比較」がやりやすい。モデルベンダー側の運用チームに刺さる。
実運用では 1 つに絞らず組み合わせるケースも多い。KGA の顧客では「Langfuse を中央のトレースバックエンド、Phoenix を RAG eval サブシステム、W&B Weave を A/B テスト時のモデル比較」という三者併用が成立している。OpenInference 規約を共通に使えば、トレースデータをそのまま 3 ツールに fan-out できる。
機能別コスト按分の実装
CFO から「この機能はいくらかかっているのか？」と問われた時、回答できる体制が 2026 年の AI プロダクト運用の最低ラインだ。実装のコツは 3 つ。
1. 属性への feature 付与を標準化する: OTel SDK のラッパで `with tracer.start_as_current_span("llm.call", attributes={"app.feature": feature})` を強制する関数を提供し、feature 未指定時は静的解析 CI でリジェクトする。
2. コスト計算を中央化する: プロバイダごとの単価テーブル（モデル別、入力／出力／cache read／cache write）を 1 ファイルで管理し、トレース挿入時に gen_ai.cost.usd を埋める。Anthropic の prompt caching は入力単価の 10%、cache write は 125% など、プロバイダごとの微妙な乗算を忘れずに。
3. 集計は ClickHouse で: Langfuse のバックエンドがそのまま使える。Grafana ダッシュボードで `SELECT feature, SUM(cost_usd) FROM observations WHERE date >= today() - 30 GROUP BY feature` のような日次ロールアップを作る。
この 3 点を押さえると、「要約機能が先月 3,800 ドル、コードレビュー機能が 12,000 ドル、社内Q&A が 540 ドル」のような粒度でコスト按分が出せる。マルチテナント SaaS なら tenant_id × feature の 2 軸集計で、テナント別マージン計算まで自動化できる。
レイテンシ SLI の定義
「LLM リクエストの p99 が 3 秒」という SLI は、実は 2 つの異なる指標を混ぜている。ストリーミング応答では TTFT（最初のトークンまでの時間）と総応答時間は意味が違う。KGA が使う標準 SLI は以下。
- TTFT p95: ユーザーが「反応が遅い」と感じる最大の要因。対話 UI なら 800ms 以下が目標。
- ITL (inter-token latency) p95: ストリーミング中の各トークン間レイテンシ。30～50ms が読みやすい範囲。
- 総応答時間 p95: バッチ処理では唯一重要な指標。
SLO としては「TTFT p95 < 1.0s を過去 28 日で 99%」「ITL p95 < 60ms を同期間で 99%」のような二重構造を推奨する。Burn rate アラートは OTel メトリクス + Prometheus Alertmanager の標準構成でカバーできる。
幻覚検知のパイプライン
完全な幻覚検知は不可能だが、「確度低いターンを抽出してサンプリングレビューする」仕組みは作れる。実戦的な手順は次の通り。
Step 1: セルフコンシステンシーチェック: 同一プロンプトを temperature 変えて 3 回呼び、応答間の意味的一致度（埋め込みコサイン）を測る。0.85 以下なら「不安定応答」としてフラグ。
Step 2: グラウンディング検証: RAG パスでは、応答から抽出した事実クレームを、検索結果との ROUGE／BERTScore で照合。閾値以下なら「根拠希薄」フラグ。
Step 3: LLM-as-Judge: Claude Haiku／GPT-4.1-mini をジャッジとして、出力が入力と整合しているかを自動評価。コストは元推論の 5% 程度。
Step 4: ユーザーフィードバック回収: 👍/👎 ボタンの結果を span に書き戻し、特に 👎 の履歴を eval データセットとして蓄積。
これらをトレース属性（eval.consistency_score, eval.grounding_score, eval.judge_score, user.feedback）として記録すると、後から「どの機能で幻覚率が上がったか」をダッシュボードで追える。Arize Phoenix はこのユースケースに特化したビューを提供する。
Grafana Tempo + ClickHouse 配線の具体
KGA で顧客に推奨しているリファレンス構成は以下。
``` [App] --OTel SDK--> [OTel Collector] | |-- traces --> [Tempo] --> [Grafana (Explore)] |-- spans_json --> [ClickHouse] --> [Grafana (SQL Dashboards)] |-- llm_spans --> [Langfuse]（OpenInference 変換経由） ```
OTel Collector のパイプラインで「全スパンは Tempo、LLM スパンは ClickHouse と Langfuse にも複製」とする設計がキモ。ClickHouse 側には LowCardinality(String) で feature／tenant_id／model を定義し、30 日ロールアップのマテリアライズドビューを作ると、数百万スパンでもダッシュボードが 1 秒以内に返る。
Tempo は分散トレースのドリルダウン用、ClickHouse は集計／コスト分析用、Langfuse はプロンプト管理と eval 用、と役割を分ける。1 ツールに押し込まず役割分担する方が運用が持続する。
PII とプロンプトログの取り扱い
プロンプト内容には個人情報や機密情報が含まれうる。そのままトレースに記録すると GDPR／APPI 違反の素になる。実践的な対策は以下。
- 属性値のマスキング: OTel Collector の attributes processor で、正規表現ベースに電話番号／メールアドレス／クレカ番号を [REDACTED] に置換。
- 保存期間の層別化: 直近 7 日は原文保存、8～30 日は統計属性のみ、31 日以降は削除。
- テナント別の opt-in: 規制業界テナントはプロンプト本文を記録しない設定を選べるようにする。
- 暗号化ストレージ: ClickHouse、Tempo ともに保存時暗号化を有効化。S3 バックエンドなら SSE-KMS。
情報セキュリティ部門とは「何を記録し、何を記録しないか」の ADR（Architecture Decision Record）を必ず残す。後から監査対応で再現が必要になる。
導入ロードマップ
完全な LLM オブザーバビリティを一晩で作るのは難しい。段階導入の推奨は以下。
- 週 1: Helicone または Langfuse の SaaS 版を 1 リクエストだけラップ。最小のダッシュボードを見る。
- 週 2～3: OpenInference SDK を本番投入。feature／tenant_id／cost 属性を埋める。
- 週 4: Grafana + ClickHouse を立ち上げ、コスト／レイテンシダッシュボードを作る。
- 週 5～6: 幻覚検知 Step 1-2 を実装。毎日 100 件のサンプルレビュー。
- 週 7～8: SLO 定義と Burn rate アラート。SRE にオンコール移管。
- 週間あればプロダクション品質に乗る。逆に、2026 年の LLM プロダクトをオブザーバビリティなしで運用するのは、APM なしで Web サービスを運用するのと同じで、本質的に不可能に近い。計測できないものは改善できない。