プロンプト/出力の保存先・粒度¶

このダイヤルは何か¶

プロンプト/出力の保存先・粒度は、エージェントが LLM に送信したプロンプト（入力）と LLM から受け取った出力をどこに・どの詳細度で保存するかを制御するパラメータです。保存の「先」はホット層（高速・短期・構造化データストア）とコールド層（低速・長期・オブジェクトストレージ）に分かれ、「粒度」はメタデータのみからプロンプト/出力の全文保存まで段階があります。

AI エージェントシステムでは、プロンプトと出力の保存がとくに重要です。LLM の出力は確率的であり、同じプロンプトを再度投入しても同じ結果が返るとは限りません。障害発生時に「何を入力して何が返ってきたか」を再構成できなければ、デバッグは不可能です。また、エージェントの品質評価や継続的改善には、過去のプロンプトと出力のペアをデータセットとして蓄積し、回帰テストや評価ハーネスに供給する必要があります。

一方で、プロンプト全文にはシステム指示、検索結果、会話履歴、ユーザーの個人情報が含まれることがあり、無差別に保存すると PII 拡散・ストレージ肥大・法的リスクを招きます。保存先と粒度を適切に分離し、目的に応じて使い分けることが、コスト効率と監査能力を両立させる鍵です。

効かなすぎる害 ⇔ 効きすぎる害¶

保存が不足している場合（効かなすぎ）¶

プロンプト/出力をほとんど保存しないと、以下の問題が起きます。

デバッグ不能：エージェントが不適切な回答を返したとき、「なぜそう答えたか」を調査する手がかりがありません。モデルに何を入力したか（プロンプト）が分からなければ、問題がプロンプト設計にあるのか、検索結果にあるのか、モデル自体の問題かを切り分けられません。
品質回帰の見逃し：モデルのバージョンアップやプロンプトの変更後に品質が低下しても、変更前の出力と比較する基準データがありません。「前はちゃんと動いていたのに」という報告に対して、定量的な検証ができません。
監査対応の失敗：規制当局や内部監査から「この判断に至った根拠を示してください」と求められたとき、プロンプトと出力の記録がなければ対応できません。金融・医療・法務の領域では致命的です。
評価ハーネスの構築不能：G4 Eval Harness で品質を継続的に評価するには、プロンプトと出力のペアが必要です。保存していなければ評価データセットを構築できません。

保存が過剰な場合（効きすぎ）¶

プロンプト全文と出力全文をすべてのリクエストで、高速なデータストアに保存すると、以下の害が生じます。

ストレージコストの爆発：エージェントの 1 リクエストが 5 回の LLM 呼び出しを含み、各呼び出しの入出力が平均 3,000 トークン（概ね 12 KB）だとすると、1 リクエストあたり 60 KB のトレースデータが発生します。月間 100 万リクエストなら 60 GB/月です。これをホット層の高速データストア（Elasticsearch、Datadog 等）に入れると、ストレージとクエリのコストが LLM 呼び出しコストに匹敵します。
PII の拡散：プロンプトにはユーザーの個人情報、会話履歴、外部ドキュメントの内容が含まれることがあります。これが観測基盤に広範囲に保存されると、アクセス制御の網の目から漏れるリスクが高まります。本番 DB とは別の場所に PII が複製されることになり、データ保護の観点で問題です。
検索・ダッシュボードの性能劣化：ホット層に大量のテキストデータが蓄積されると、ダッシュボードのクエリ速度が低下し、リアルタイムモニタリングの即応性が損なわれます。
法的リスク：データ保持に関する規制（「不要なデータは速やかに削除する」）に抵触する可能性があります。保持する必要のないデータを保持し続けること自体がリスクです。

決め方¶

保存先と粒度は [accountability] と [cost_sensitivity] のバランスで決まります。

[accountability]：説明責任が高いほど、保存の粒度を上げます。監査要件がある領域では、プロンプトと出力の全文をコールド層に保存し、一定期間後に暗号化アーカイブに移すことが求められます。
[cost_sensitivity]：コスト感度が高い場合、ホット層に保存するのはメタデータに限定し、全文はコールド層（オブジェクトストレージ）に非同期で書き出します。コールド層のストレージコストはホット層の概ね 1/10〜1/100 です。
[failure_cost]：失敗コストが高い経路では、成功リクエストも含めて全文保存し、品質の追跡と回帰検出に使います。

保存の階層設計は以下の 3 段階で考えます。

メタデータ（ホット層に常時保存）：trace ID、model 名、temperature、input/output トークン数、レイテンシ、ステータスコード、プロンプトの SHA-256 ハッシュ、出力の truncated 版（先頭 200 文字程度）
サマリー（ホット層にオプション保存）：プロンプトのセクション別トークン配分（システム指示何%、検索結果何%、履歴何%）、出力の構造的要約（生成されたツール呼び出しの一覧、判定結果等）
全文（コールド層にサンプルまたは全量保存）：プロンプト全文、出力全文、ツール入出力の全文。PII マスキングまたは暗号化を適用

目安値（出発点）¶

保存項目	保存先	保存条件	保持期間の目安
メタデータ（model, tokens, latency, status, hash）	ホット層	全リクエスト	7〜30 日
出力の truncated 版（先頭 200 文字）	ホット層	全リクエスト	7〜30 日
トークン配分サマリー	ホット層	全リクエストまたは標本	7〜30 日
プロンプト全文	コールド層	エラー/HITL は全量、成功は標本（1〜10%）	90 日〜数年
出力全文	コールド層	エラー/HITL は全量、成功は標本	90 日〜数年
ツール入出力の全文	コールド層	副作用ありは全量、読み取りのみは標本	90 日〜数年

コールド層にはオブジェクトストレージ（S3、GCS、Azure Blob 等）を使用し、ライフサイクルルールで自動的にアーカイブ・削除する設定を入れます。

実践的なアドバイス¶

ホット層とコールド層の分離を最初から設計してください。後からホット層のデータを間引くのは困難です。最初から「ホット層にはメタデータのみ、コールド層に全文」という設計にしておけば、ホット層のコストは安定的に管理できます。
プロンプトの SHA-256 ハッシュをホット層に保存してください。同一プロンプトの繰り返し（キャッシュミスの検出）、プロンプト変更のタイミング検出、全文が必要になったときのコールド層からの引き当てに使えます。ハッシュのコストは無視できるほど小さいです。
PII マスキングは保存前に行ってください。コールド層に保存する前に PII を検出・マスキングするパイプラインを挟みます。マスキング後のデータであれば、アクセス制御の要件が緩和されます。ただし、デバッグ用に原文が必要な場合は、別途暗号化して限定的なアクセス権で保存する仕組みを用意します。
評価ハーネスとの連携を設計してください。コールド層のプロンプト/出力ペアは G4 Eval Harness への入力データソースとなります。評価に使いやすい形式（JSONL 等）で保存しておくと、後工程の効率が大きく変わります。
保存粒度をリクエスト属性に応じて動的に変えてください。全リクエストで全文を保存するのではなく、トレース・サンプリング率と連動させます。サンプリングされたリクエストのみ全文をコールド層に送り、それ以外はメタデータのみにすることで、コストを管理しながら十分な監査能力を維持できます。