LLMトレーシング（分散トレース）（エルエルエムトレーシング（ブンサントレース））
LLMトレーシングとは、LLMアプリケーションの各処理ステップをトレースとスパンの階層構造で記録・可視化する技術である。OpenTelemetryの分散トレーシング概念をLLM固有のセマンティクスで拡張し、パイプラインのボトルネック特定とデバッグを可能にする。
LLMトレーシングとは
LLMトレーシングは、LLMアプリケーションの内部処理フローを記録・可視化する技術である。RAG、マルチエージェント、ツール呼び出し等の複雑なパイプライン全体を1つのトレースとして記録し、各ステップをスパンとして階層化する。
スパンタイプ
| タイプ | 記録内容 | 主な属性 |
|---|---|---|
| LLM | API呼び出し | モデル名、temperature、トークン数、コスト |
| Embedding | ベクトル生成 | モデル名、次元数、トークン数 |
| Retrieval | 検索 | クエリ、結果件数、類似度スコア |
| Tool | ツール実行 | ツール名、引数、戻り値 |
| Agent | エージェント実行 | 思考プロセス、選択ツール、反復回数 |
OpenTelemetry統合
OpenLLMetry（Traceloop社）がOpenAI/Anthropic/Cohere/Bedrock等のSDKを自動計装しOTelスパンとして出力。traceloop.init(app_name='my-app')の1行で有効化。gen_ai.system、gen_ai.request.model等のセマンティック属性が標準化進行中。
RAGパイプラインのトレース例
ルートスパン（2.3秒）内にクエリ埋め込み（85ms）、ベクトル検索（120ms）、リランキング（95ms）、コンテキスト構築（12ms）、LLM生成（1,850ms、input 2,340/output 580トークン、$0.0094）、後処理（25ms）が記録される。LLM生成が全体の80%を占めることが一目で分かる。
レイテンシ分析
P50/P90/P99をスパンタイプごとに算出。トークン消費量との相関分析で「入力3,000トークン超でレイテンシ急増」等の最適化ポイントを発見。
エラー検出
| エラー | 検出方法 | 原因 |
|---|---|---|
| レート制限 | HTTP 429 | 同時リクエスト過多 |
| コンテキスト長超過 | HTTP 400 | RAG結果過剰注入 |
| タイムアウト | 実行時間 > 閾値 | 大規模コンテキスト |
| ハルシネーション | 評価スコア低下 | コンテキスト不足 |
trace_idをログに出力し、問い合わせ時に即座にデバッグ可能。
よくある質問（FAQ）
Q1: パフォーマンスへの影響は？
非同期バッチ送信でレイテンシ影響は1ms未満。高スループット環境ではサンプリングレートを設定。送信先ダウンでもアプリ可用性に影響なし。
Q2: プロンプト全文をトレースに含めるべきか？
開発環境は全文記録推奨。本番はPIIマスキング/オプトアウト設定が必要。数値メタデータのみでも監視は維持可能。
Q3: OTel標準と独自SDKのどちらを使うべきか？
既存OTel基盤があればOpenLLMetryが統合的。新規導入なら独自SDKが機能豊富。OTel Gen AI拡張は2026年時点でExperimental。