LLMプロンプトロギング（エルエルエムプロンプトロギング）
LLMへ送信されたプロンプトとモデルからの応答を構造化して記録・保存する仕組み。デバッグ、品質評価、監査対応、プロンプト改善のために入出力ペアを完全に再現可能な形で保持し、個人情報保護とのバランスを管理する。
LLMプロンプトロギングとは
LLMプロンプトロギングは、大規模言語モデルに送信されるプロンプト（system/user/assistant メッセージ）と、モデルから返却されるレスポンスを構造化された形式で記録・保存するプラクティスである。非決定的な出力を生成するLLMにおいて、問題の再現・品質のトラッキング・規制コンプライアンスを実現するための基盤技術となる。
記録すべきデータ項目
プロンプトログには以下の情報を含めることが推奨される。
| 項目 | データ型 | 用途 |
|---|---|---|
| request_id | UUID | リクエストの一意識別 |
| timestamp | ISO 8601 | 時系列分析・監査 |
| model | string | 使用モデルの特定 |
| messages | JSON array | system/user/assistantの完全なメッセージ列 |
| parameters | JSON object | temperature, max_tokens, top_p等 |
| response | string/JSON | モデルの完全な出力 |
| usage | object | input/output トークン数 |
| latency_ms | integer | E2Eレスポンス時間 |
| user_id | string (hashed) | ユーザー追跡（匿名化） |
| tags | string array | 機能タグ・実験タグ |
ロギングアーキテクチャのパターン
パターン1: インラインロギング
アプリケーションコード内でLLMコールの前後にログ出力を挿入する。最もシンプルだがコードへの侵襲性が高い。
パターン2: プロキシ型ロギング
HeliconeやLiteLLMをLLMプロバイダの手前に配置し、全リクエスト/レスポンスを透過的に記録する。アプリケーションコードの変更は接続先URLの変更のみ。
パターン3: SDK計装型ロギング
LangSmithやLangfuseのSDKをインポートし、コールバック/デコレータで自動記録する。LangChainやLlamaIndex等のフレームワークとの統合が容易。
個人情報保護（PII対応）
プロンプトログにはユーザーが入力した個人情報が含まれる可能性がある。以下の対策が必須である。
- 送信前マスキング: 氏名・メールアドレス・電話番号を正規表現で検出し、
[REDACTED]に置換してからログ保存 - 暗号化保存: ログストレージはAES-256で暗号化し、アクセス制御をRBACで管理
- 保持期間設定: GDPR/個人情報保護法に基づき、90日以内の自動削除ポリシーを設定
- アクセスログ: ログ閲覧自体を監査ログに記録する二重ロギング
- サンプリング: 全件記録ではなく一定割合（例: 10%）のみ記録するオプション
品質評価への活用
記録されたプロンプトログは以下の品質改善活動に活用できる。
- A/Bテスト: 2種類のプロンプトテンプレートを並行実行し、ログから品質スコアを比較
- 回帰テスト: モデルバージョンアップ前後で同一プロンプトの出力差分を検証
- ファインチューニングデータ: 高品質な入出力ペアを選別してSFTデータセットを構築
- エラー分析: ハルシネーションやフォーマット違反のパターンを特定して系統的に修正
- プロンプト最適化: 長いプロンプトの冗長部分を特定し、トークン消費を削減
主要プラットフォームのログ機能比較
| プラットフォーム | 全文ログ | PIIマスキング | エクスポート | 保持期間 |
|---|---|---|---|---|
| LangSmith | ○ | SDK側で実装 | JSON/CSV | 無制限（有料） |
| Langfuse | ○ | クライアントサイド | JSON | セルフホスト: 無制限 |
| Helicone | ○ | プロキシ層で対応 | JSON/CSV | 90日（Free） |
| Arize Phoenix | ○ | 手動設定 | Parquet | ローカル: 無制限 |
FAQ
Q1: 全プロンプトを記録するとストレージコストが問題にならない？
1リクエストあたり平均2〜5KBとして、日間100万リクエストで2〜5GB/日、月間60〜150GBとなる。S3やGCSの標準ストレージで月額$1.5〜$4程度のため、LLM APIコストに比べれば無視できる水準である。サンプリングで10%に絞ればさらに1/10になる。
Q2: ストリーミングレスポンスのログはどう記録する？
各SSEチャンクを結合して完全なレスポンスを再構築してからログに書き込む。LangfuseやLangSmithのSDKはストリーミング対応のコールバックを提供しており、チャンク結合を自動で行う。
Q3: プロンプトログからプロンプトインジェクション攻撃を検出できる？
検出できる。ログに対してパターンマッチング（「ignore previous instructions」等の既知パターン）やLLMベースの分類器を適用することで、プロンプトインジェクション試行を事後的に特定し、攻撃パターンのデータベースを構築できる。