ログ保持期間¶

このダイヤルは何か¶

ログ保持期間は、エージェントの実行に関するログ・トレース・メトリクスデータをどれくらいの期間保持するかを制御するパラメータです。ここでの「ログ」はアプリケーションログだけでなく、LLM 呼び出しのメタデータ、ツール実行記録、プロンプト/出力の全文、構造化メトリクス、監査証跡など、観測基盤が収集するすべてのデータを含みます。

AI エージェントシステムのログは、従来のシステムと比較して以下の点で特殊です。第一に、1 リクエストあたりのデータ量が大きいです。プロンプト全文や出力全文を含むと、1 リクエストのログが数十 KB〜数百 KB になります。第二に、LLM の確率的な性質上、障害の再現にはログ（とくにプロンプト/出力の全文）が唯一の手がかりです。第三に、エージェントの品質改善にはログデータが学習・評価のデータソースとなります。

これらの特性から、ログの保持期間は「いつまで保持するか」と「どの層（ホット/コールド）で保持するか」の 2 軸で設計する必要があります。短期間はホット層（高速クエリ可能）に、長期間はコールド層（低コスト）に段階的に移行させ、最終的には規制要件に応じて削除またはアーカイブします。

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

保持期間が短すぎる場合（効かなすぎ）¶

ログを数日〜1 週間で削除すると、以下の問題が起きます。

遡及的な障害調査の不能：障害や品質劣化が発覚するまでにタイムラグがあります。ユーザーから「先週から回答がおかしい」と報告されたときに、先週のログが削除済みでは調査できません。とくにエージェントの品質問題は、明示的なエラーではなく「回答の質が落ちた」という曖昧な報告になりがちで、発覚まで数日〜数週間かかることがあります。
監査要件の不達成：規制領域（金融、医療、法務）では、意思決定の記録を一定期間保持する義務があります。GDPR は最大保持期間を制限しますが、同時に MiFID II（金融）や HIPAA（医療）は最低保持期間を要求します。短すぎる保持はこれらの要件に違反します。
トレンド分析の断絶：週次・月次でのコスト推移、品質推移、利用パターンの分析にはある程度の期間のデータが必要です。保持期間が短いと、季節変動や長期トレンドを把握できません。
評価データセットの不足：G4 Eval Harness で使用する回帰テスト用のデータセットを構築するには、一定期間のプロンプト/出力ペアが必要です。保持期間が短いと、評価の品質が低下します。

保持期間が長すぎる場合（効きすぎ）¶

ログを無期限に保持すると、以下の害が生じます。

ストレージコストの継続的増加：エージェントのトラフィックが増えるにつれてログデータも増え続けます。ホット層のストレージコストは高額であり、コールド層でも長期的には無視できない金額になります。とくにプロンプト全文を含むログは、テキストデータとしてはかなり大きいです。
不要データの法的リスク：GDPR の「データ最小化原則」や「保存の制限原則」に基づき、目的を達成した個人データは速やかに削除する義務があります。業務上不要になったデータを保持し続けること自体が法的リスクとなります。データ漏洩が発生した場合、不必要に保持していたデータが漏洩範囲を広げます。
クエリ性能の劣化：ホット層のデータ量が増えると、ダッシュボードのクエリ応答時間が悪化します。障害発生時の初動調査が遅れる原因になります。
データ管理の複雑化：長期間保持するほど、データの分類・アクセス制御・暗号化状態の管理が複雑になります。古いフォーマットのログと新しいフォーマットのログが混在し、解析ツールの互換性問題が生じます。

決め方¶

ログ保持期間は主に [accountability] によって決まり、[cost_sensitivity] によって制約されます。

[accountability]：説明責任が高いほど保持期間を長くします。規制要件がある場合は、最低保持期間が法令で定められていることがあります（MiFID II: 5〜7 年、HIPAA: 6 年など）。規制がない場合でも、内部監査の慣行に従います。
[cost_sensitivity]：コスト感度が高い場合、ホット層の保持期間を短くし、コールド層への移行を早めます。コールド層のストレージコストは概ねホット層の 1/10〜1/100 であるため、早期にコールド層に移行することでコストを大幅に削減できます。
[failure_cost]：失敗コストが高い場合、品質問題の遡及調査に備えて保持期間を長めに設定します。品質劣化の発覚に 2〜4 週間かかると想定するなら、ホット層で最低 4 週間、コールド層でさらに数ヶ月の保持が必要です。

保持期間の設計は、ホット層とコールド層で独立に行います。

ホット層（メタデータ＋構造化メトリクス）：リアルタイムのダッシュボードとアラートに使用。保持期間は短め。
コールド層（プロンプト/出力全文＋詳細トレース）：監査・回帰テスト・障害の深掘り調査に使用。保持期間は長め。
アーカイブ層（規制対応用の暗号化アーカイブ）：法的要件で保持が義務付けられているデータのみ。

目安値（出発点）¶

データの種類	ホット層の保持	コールド層の保持	根拠
構造化メトリクス（トークン数、コスト、レイテンシ）	7〜30 日	90 日〜1 年	ダッシュボードは直近 1 ヶ月を参照。トレンド分析は四半期〜年単位
エラーログ	14〜30 日	90 日〜1 年	再発する障害パターンの長期追跡
プロンプト/出力の全文	保存しない（コールドのみ）	90 日〜数年	監査要件に依存。ホット層に全文を入れるとコスト増大
監査証跡（承認記録、ポリシー判定結果）	30 日	1 年〜数年	規制要件に従う。金融は 5〜7 年の場合あり
ダッシュボード用集約データ	30〜90 日	1〜3 年	月次レポートの生成に使用

保持期間の終了時には自動削除するライフサイクルポリシーを設定してください。手動削除に依存すると、削除漏れや削除忘れが発生し、法的リスクにつながります。

実践的なアドバイス¶

ホット層からコールド層への自動移行パイプラインを最初に構築してください。ホット層のデータが一定期間を経過したら自動的にコールド層に移行し、さらに一定期間後に自動削除するライフサイクルを設定します。S3 のライフサイクルルールや Elasticsearch の ILM（Index Lifecycle Management）がこの用途に適しています。
規制要件の調査を設計の初期段階で行ってください。規制が存在する場合、保持期間の最低値が外部から決まります。後から「実は 5 年間保持する義務があった」と判明すると、アーキテクチャの大幅な変更が必要になります。
ホット層の保持期間は「障害の平均発覚時間 + 調査時間」を基準にしてください。障害が発覚するまでに概ね 1 週間、調査に 1 週間かかるなら、ホット層は最低 2 週間の保持が必要です。これより短いと、発覚した時点でデータが削除されています。
コールド層のデータは圧縮してください。テキストデータ（プロンプト/出力の全文）は圧縮効率が高く、gzip で概ね 70〜80% のサイズ削減が可能です。長期保持のコストに大きく影響します。
削除ポリシーの例外規定を用意してください。進行中の調査に関連するデータは、通常の削除ポリシーの対象外として保持を延長できる仕組み（legal hold）を設計しておきます。裁判や監査の過程でデータが必要になった場合に対応するためです。