プロンプトトレーシング（プロンプトトレーシング）

プロンプトトレーシングとは

プロンプトトレーシング（Prompt Tracing）とは、LLMアプリケーションでプロンプトがどのように構築・送信・処理されたかをリクエスト単位で追跡する手法です。分散システムにおけるリクエストトレーシング（Jaeger・Zipkin等）の概念をLLMパイプラインに適用したものです。

単純なLLM呼び出しでは入力と出力の記録だけで十分ですが、RAG（検索拡張生成）・エージェント・マルチステップ推論を含む複雑なパイプラインでは、プロンプトが複数のコンポーネントを経由して動的に構築されます。各ステップの入出力と所要時間を可視化するのがプロンプトトレーシングの役割です。

トレースの構造

Span（スパン）

トレースの最小単位です。各Spanは1つの処理ステップ（埋め込み生成、ベクトル検索、プロンプト構築、LLM呼び出し等）を表し、開始時刻・終了時刻・入出力データ・メタデータを保持します。

Trace（トレース）

1つのユーザーリクエストに対応するSpanの木構造です。ルートSpan（リクエスト受信）から子Span（各処理ステップ）が枝分かれし、リクエスト全体の処理フローを表現します。

なぜトレーシングが重要か

ボトルネック特定

RAGパイプラインで応答が遅い場合、原因は埋め込み生成・ベクトル検索・LLM推論のいずれかにあります。トレースのSpan別レイテンシを見れば、どのステップがP95レイテンシを押し上げているか一目瞭然です。

プロンプト構築のデバッグ

動的に構築されるプロンプトは、テンプレート・検索結果・ユーザー履歴・システムプロンプトなど複数の要素が合成されます。最終的にLLMに送信されたプロンプト全文をトレースに記録することで、期待と異なるコンテキストが挿入されていないかを検証できます。

エージェントループの可視化

LLMエージェントがツール呼び出しを繰り返すループでは、各イテレーションのプロンプト・ツール選択・ツール出力・次のプロンプトをSpanチェーンで追跡します。無限ループや不適切なツール選択の原因特定に不可欠です。

実装方法

OpenTelemetry統合

OpenTelemetryの標準トレーシングAPIを利用し、LLMパイプラインの各ステップをSpanとして記録します。GenAI Semantic Conventions（OpenTelemetryのLLM向け規約）に準拠することで、異なるモデルプロバイダ間でも一貫したトレースフォーマットが得られます。

LLMオブザーバビリティSDK

LangSmith・Langfuse・Arize PhoenixなどのSDKは、LangChain・LlamaIndex等のフレームワークと統合済みのトレーシング機能を提供します。デコレータやコールバックを数行追加するだけでフルトレースが取得できます。

カスタム実装

軽量な要件では、リクエストIDを伝播させながら各ステップのログをJSON出力する自前実装も実用的です。重要なのはリクエストIDによる相関付けと、タイムスタンプの精度（ミリ秒以上）です。

ベストプラクティス

プロンプトトレーシングでは、記録粒度とストレージコストのバランスが重要です。開発・ステージング環境ではフルトレース（全Span・全テキスト記録）、本番環境ではサンプリングトレース（10-50%）+ エラー時フルトレースの切り替えが推奨されます。

トレースデータは個人情報を含む可能性があるため、PIIスクラビング（個人情報の自動除去）をトレース送信前に適用します。

FAQ

Q1: トレーシングの導入にパフォーマンス影響はありますか？

A1: 適切に実装すれば影響は軽微です。非同期バッファリングでトレースデータを送信し、LLM呼び出しのクリティカルパスに同期I/Oを挿入しないことが重要です。一般的にはレイテンシ増加1%未満に収まります。

Q2: エージェントの長いツール呼び出しチェーンでもトレースできますか？

A2: はい。OpenTelemetryのSpan親子関係を利用して、エージェントの各イテレーション（推論→ツール選択→ツール実行→結果統合）を階層的に記録できます。LangSmithやLangfuseはこのパターンをネイティブサポートしています。

Q3: トレースデータの保持期間は？

A3: 開発・デバッグ用のフルトレースは7-30日、集計メトリクス（Span別レイテンシ分布等）は6-12ヶ月が目安です。コンプライアンス要件がある場合は監査用のサマリトレースを長期保管します。