メモリ TTL / 保持量¶

このダイヤルは何か¶

メモリ TTL（Time To Live）/ 保持量は、エージェントが蓄積した記憶をどれくらいの期間・どれくらいの量まで保持するかを制御するパラメータです。ここでの「メモリ」は、会話履歴、ユーザープロファイル、学習した事実、中間的な推論結果など、エージェントがセッションを跨いで持ち越す情報全般を指します。

AI エージェントシステムでは、メモリは「あればあるほど良い」というものではありません。古い情報は陳腐化し、矛盾した記憶は回答品質を劣化させ、肥大化したメモリは検索精度を下げてコストを増加させます。一方で、メモリを短く保ちすぎるとエージェントが「何も覚えていない」状態に陥り、ユーザーは同じ情報を繰り返し伝える必要があります。

このダイヤルは、情報の種類ごとに異なる TTL と容量上限を設定するという考え方が基本です。すべてのメモリに一律の TTL を適用するのではなく、D1 Tiered Memory の階層構造に従って、作業記憶・短期記憶・長期記憶のそれぞれに適切なライフサイクルを定めます。

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

TTL が短すぎる / 保持量が少なすぎる場合（効かなすぎ）¶

メモリの保持を極端に制限すると、以下の問題が生じます。

文脈の断絶：ユーザーが前回のセッションで伝えた情報（好み、進行中のプロジェクト、過去の意思決定）をエージェントが忘れてしまいます。「先週の続きをお願いします」と言われても、何の続きか分かりません。
学習の喪失：エージェントがユーザーとの対話から学んだパターン（「このユーザーは技術的な詳細を好む」「この企業では Python を主に使っている」）が失われ、毎回初回対話と同じ品質からやり直しになります。
反復的な情報収集：エージェントが毎回同じ質問をユーザーに投げかけることになり、ユーザー体験が著しく悪化します。とくにカスタマーサポートでは「また同じことを聞かれた」という不満に直結します。
エスカレーション情報の欠落：長期タスクの途中経過が保持されず、人間への引継ぎ時に「今まで何をしていたか」の情報が失われます。

TTL が長すぎる / 保持量が多すぎる場合（効きすぎ）¶

メモリを無制限に蓄積すると、以下の害が発生します。

古い情報による誤判断：ユーザーの住所、役職、好み、プロジェクト状況などが変わっているのに、古い記憶に基づいて行動します。「去年引っ越した」のに旧住所を参照する、「もう使っていないツール」を前提にした提案をする、といった問題です。
矛盾する記憶の蓄積：同じ事実について異なる時点の情報が共存すると、検索時にどちらを優先すべきか不明になります。LLM が矛盾する記憶を同時にコンテキストに受け取ると、回答が不安定になります。
検索精度の低下：メモリストアのエントリ数が増えるほど、ベクトル検索のノイズが増加します。関連性の低い古い記憶が上位に来てしまい、本当に必要な情報が埋もれます。
ストレージとコストの肥大化：ベクトル DB のストレージコスト、埋め込み生成コスト、検索時の計算コストが継続的に増加します。
プライバシー・コンプライアンスのリスク：不要になった個人情報を保持し続けると、GDPR の最小化原則や忘れられる権利に抵触する可能性があります。

決め方¶

メモリ TTL は主に [failure_cost] と情報の種類によって決まります。

[failure_cost]：失敗コストが高い領域ほど、TTL の設計を慎重に行います。古い情報に基づく誤判断のコストが高い場合は TTL を短くし、逆に重要な情報が消失して判断根拠を失うコストが高い場合は TTL を長くします。この二面性があるため、情報の種類ごとに個別に判断する必要があります。
[accountability]：説明責任が高い場合、過去の意思決定の根拠として参照する必要があるメモリは長期保持します。ただし「保持」と「アクティブに利用」は区別し、アーカイブ層に移すことでアクティブなメモリの肥大化を防ぎます。
[cost_sensitivity]：コスト感度が高い場合、メモリストアのサイズを積極的に管理します。アクセス頻度の低いメモリを定期的にアーカイブまたは削除する仕組みが重要になります。

情報の種類ごとの TTL 設計は以下の原則に従います。

変化頻度が高い情報ほど TTL を短くする：在庫、価格、ステータスなどは分〜時間単位
変化頻度が低い情報ほど TTL を長くする：ユーザーの母語、専門分野などは月〜無期限
不変の事実は無期限だが、定期的に検証する：ユーザー名、企業情報などは変わりうるため、長期保持するが最終確認日を記録する

目安値（出発点）¶

情報の種類	TTL の目安	根拠
作業記憶（推論中間物、ツール出力）	リクエスト〜セッション	タスク完了で役割を終える。保持しても次のタスクでは無関係
会話履歴（直近ターン）	セッション〜1日	D2 Context Budget Allocator で圧縮しつつ保持
価格・在庫・ステータス	数分〜数時間	リアルタイム性が求められる。キャッシュとしても短命
プロジェクトの進捗・タスク状態	数日〜数週間	プロジェクト完了後にアーカイブへ
ユーザーの好み・設定	数ヶ月〜無期限	変化は緩やか。ただし定期的に「まだ有効か」を確認する仕組みが望ましい
不変の知識（ドメイン知識、手順書）	無期限（版管理付き）	内容は不変でも、知識の更新に備えてバージョンを管理する

容量上限については、ユーザー単位で概ね数百〜数千エントリが出発点です。これを超えたら、アクセス頻度と減衰スコアに基づいてアーカイブまたは削除します。

実践的なアドバイス¶

情報に「最終確認日」を付与してください。TTL だけでなく、情報がいつ最後に確認・使用されたかを記録します。長期間アクセスされていないメモリは、TTL 内であっても検索結果のランキングを下げることで、陳腐化した情報の影響を軽減できます。
TTL 切れ＝即削除ではなく、段階的な降格を設計してください。TTL を過ぎたメモリを即座に削除するのではなく、「アクティブ → 低優先 → アーカイブ → 削除」という段階を踏むことで、予期せぬ情報喪失を防ぎます。D1 Tiered Memory の階層構造がこの段階的管理を構造化します。
矛盾検出を定期的に実行してください。同じエンティティについて矛盾する記憶が存在しないか、バッチ処理で検査します。矛盾が検出されたら、新しい方を残すか、ユーザーに確認するかを [failure_cost] に基づいて判断します。
メモリの「鮮度」と「確度」を区別してください。1年前にユーザーが直接述べた事実（高確度・低鮮度）と、昨日 LLM が推測した情報（低確度・高鮮度）では、保持の優先度が異なります。確度が高い情報は TTL を長く、確度が低い情報は TTL を短く設定します。
規制要件を確認してください。GDPR、CCPA などのデータ保護規制がある場合、ユーザーデータの保持期間に上限が課されることがあります。「忘れられる権利」に対応するため、特定ユーザーのメモリを一括削除できる仕組みを設計段階で組み込んでおく必要があります。