先に結論
AgentCoreのメモリ運用で重要なのは、すべてを長く残すことではありません。記憶の種類ごとに保持期間と削除基準を分けることが必要です。そのうえで夜間ワークフローにより「期限判定→有用性評価→重複統合→削除→品質確認」を回します。ただしAgentCore Memoryには最終アクセス日時がなく、TTLの自動削除も組み込みではないため、CloudTrailや外部台帳を組み合わせる必要があります。
GLOBAL AI BRIEF ・ PROCESS
長期メモリを安全に減らす順序は？
- STEP 01期限候補を抽出記憶タイプ別のTTL
- STEP 02有用性を評価新しさ・アクセス・頻度
- STEP 03重複を統合失敗時は原文を保持
- STEP 04削除後を検証回帰評価と監査ログ
長期メモリは「量」より古さと矛盾が問題になる
AWSが挙げた例では、数か月運用したサポートエージェントが、4か月前に解決済みの請求問題を現在も未解決として扱いました。別のエージェントは、すでに置き換えられた古い手順書を繰り返し参照しました。
これは保存容量だけの問題ではありません。古い事実が新しい事実と競合し、検索結果に混ざると、回答の一貫性と信頼性が下がります。長期メモリは「何件保存したか」ではなく、現在の判断に使ってよい状態かを管理する必要があります。
AWSの参照実装は、Amazon Bedrock AgentCore Memoryの外側にライフサイクル処理を置きます。EventBridgeで夜間に起動し、Step Functionsが複数のLambdaを順番に実行する構成です。
三種類の記憶で保持期間を分ける
エピソード記憶は、会話やセッションに結びつく高頻度の履歴です。量が増えやすく、古い文脈が現在の判断を汚すため、最初に期限切れの対象になります。
意味記憶は、ユーザーの好み、組織情報、蒸留された事実です。エピソードより長く保ちますが、同じ対象の新旧情報が競合しやすいため、統合と更新日の管理が必要です。
手順記憶は、ワークフローやツール利用のパターンです。件数は少なくても業務影響が大きいため、最も長い保持期間と高い削除基準を設定します。三種類を同じTTLで削除すると、重要な手順と一時的な会話を同列に扱うことになります。
夜間ワークフローは六つの処理を順番に行う
参照構成は、EventBridgeからStep Functionsを起動し、TTLプルーナー、有用性スコアラー、統合処理、メトリクス出力を実行します。結果はS3へ残し、失敗はSNSで通知します。AWS CDKとPython 3.12で展開する例が示されています。
最初に作成日時で期限候補を抽出し、次にアクセス状況や頻度を加味して有用性を判定します。似た記憶はBedrockで一つへ統合し、基準を下回る記憶を削除します。最後に品質評価と監査記録を残します。
処理順が重要です。いきなり削除すると、後から「なぜ消えたか」を説明できません。候補抽出・評価・統合・削除・検証を分けることで、各段階に停止条件を置けます。
TTLは自動削除ではなく候補抽出の基準
AWSはエピソード記憶の初期値として90日を例示しています。一方で、要約は30〜60日、意味記憶は6〜12か月、手順記憶はTTLなしも選択肢です。これは推奨の固定値ではなく、記憶の用途ごとに変える出発点です。
AgentCore MemoryにはTTLによる組み込み自動削除がありません。参照実装では、作成日時を示すx-amz-agentcore-memory-createdAtへBEFORE条件を適用して候補を探し、Lambdaが削除処理を行います。
| 記憶タイプ | AWS記事の開始例 | 運用上の注意 |
|---|---|---|
| エピソード | 90日、用途により短縮 | 会話の再現に必要な期間を確認 |
| 要約 | 30〜60日 | 元会話との追跡性を残す |
| 意味記憶 | 6〜12か月 | 新旧事実の競合を検知 |
| 手順記憶 | TTLなしも選択肢 | 承認済み手順の版管理が必要 |
有用性スコアは「新しさ」だけで決めない
参照実装の既定重みは、recency 0.4、access 0.35、frequency 0.25です。基準スコアは50、初期のpruneDaysは45日、削除閾値は0.3、減衰係数は約0.02676とされています。
用途別のpruneDays開始例は、サポート7日、営業・オンボーディング21日、一般アシスタント45日、ITヘルプデスク90日、法務・コンプライアンス180日です。短いほど良いのではなく、誤った古い記憶の損失と、必要な履歴を失う損失のどちらが大きいかで決めます。
スコアは削除の自動許可ではなく、候補順位です。法務、契約、本人同意、重大インシデントに関する記憶は、閾値を下回っても人の確認や別アーカイブへ回す方が安全です。
最終アクセス日時がないためCloudTrail台帳が必要
AgentCore Memory APIはlastAccessedAtを返しません。そのためAWSの例では、CloudTrailのGetMemoryRecordデータイベントから参照履歴を取り込みます。直近25時間のログと、S3に蓄積した累積アクセス台帳を組み合わせます。
この補助台帳がないと、最近よく使われた古い記憶と、長期間使われていない古い記憶を区別できません。作成日だけで削除すると、業務上重要な長期記憶を落とす可能性があります。
一方、CloudTrailの収集漏れや遅延も考慮が必要です。アクセス証跡が欠けている場合は「未使用」と断定せず、削除を止める側へ倒す設計が適切です。
統合は可逆性を残し、失敗時は原文を保持する
似た意味記憶はBedrockで要約・統合します。たとえば好みの更新が複数の会話に分散している場合、現在有効な内容へまとめることで検索ノイズを減らせます。
統合は情報を失う処理です。AWSの実装ではBedrock呼び出しが失敗した場合、元の記憶を保持します。削除失敗もログへ残します。高リスク業務では統合前の原文を別アーカイブへ残し、統合結果から戻せるようにすべきです。
本番利用ではBedrock Guardrailsやグラウンディング確認の併用が推奨されています。統合文が元記憶にない内容を足していないか、低信頼時に人へ回せるかが品質境界になります。
費用は件数より統合対象の割合で増える
AWSの例では、1,000件の記憶のうち20%が閾値未満の場合、夜間のBedrock呼び出しは約20回、費用は約0.01〜0.02ドルと試算されています。これはモデル、リージョン、プロンプト長で変わる例示値です。
10万件規模では月50〜100ドルになる可能性が示されています。全件を毎晩LLMへ送らず、作成日やスコアで候補を絞り、似た記憶をバッチ化することが費用管理につながります。
| 規模 | AWS記事の例 | 確認すべき点 |
|---|---|---|
| 1,000件、20%候補 | 約20回、0.01〜0.02ドル/夜 | 少量運用の試算 |
| 100,000件 | 月50〜100ドルの可能性 | モデル・バッチ・地域で変動 |
| 共通 | Step Functions、Lambda、S3等も利用 | LLM費用だけで判断しない |
削除後の品質は回帰評価で確認する
参照実装は、処理前後の回答品質をAgentCore Evaluationsで比較します。AWSのサンプルでは一つの評価が0.82から0.85、別の評価が0.74から0.71へ変化しました。後者は低下していますが、設定した閾値0.6を上回るため合格扱いです。
平均点だけでなく最低品質と重要シナリオを見る必要があります。古い請求履歴、本人情報、承認済み手順など、消えると困る質問を回帰セットへ入れます。閾値を下回ったら、その夜の削除を確定せず、前の状態へ戻せる必要があります。
個人情報削除は別経路で扱います。AWSの例にはGDPR削除ハンドラー、構造化CloudWatch Logs、ファイル検証付きCloudTrail監査が含まれます。通常の有用性スコアより、法的削除要求を優先させます。
日本企業が導入前に決めるべき五つの境界
第一に、記憶タイプの分類責任者です。第二に、タイプ別の保持期間です。第三に、自動削除できない高リスク記憶です。第四に、統合前原文の保存と復旧期限です。第五に、品質回帰で停止する閾値です。
最初からすべてを自動削除せず、候補一覧を出すシャドーモードから始めます。2〜4週間、削除候補と実際の参照状況を比べ、誤削除率と古い記憶による誤回答率を測ります。
その後、低リスクのエピソード記憶だけを自動化し、意味記憶、手順記憶へ段階的に広げます。停止条件は「削除件数」ではなく、回帰評価低下、監査ログ欠損、アクセス台帳遅延、統合失敗率で設定します。
まだ分からないこと・適用しない条件
公開内容はAWSの参照実装です。例示された保持日数、重み、費用、品質スコアが、すべての業務や日本企業の個人情報運用に適することは確認されていません。
医療、金融、法務、人事などでは、業法や社内規程により削除・保存条件が異なります。重要記憶をLLMだけで統合・削除せず、専門部署の承認、原文保存、監査証跡を追加すべきです。
FAQ：よくある質問
Q. 90日で一律削除すればよいですか？
A. いいえ。90日はエピソード記憶の開始例です。意味記憶や手順記憶は別の保持期間と削除基準が必要です。
Q. AgentCoreだけで最終アクセスを判断できますか？
A. 現在のAPIにはlastAccessedAtがないため、AWSの例ではCloudTrailとS3のアクセス台帳を使います。
Q. 統合すれば元の記憶は不要ですか？
A. 高リスク用途では残すべきです。統合は損失を伴うため、原文アーカイブと復旧手順を用意します。
まとめ
AIエージェントの長期メモリは、保存機能ではなく運用品質の問題です。記憶タイプ別のTTL、有用性スコア、アクセス台帳、統合、削除、回帰評価、監査を一つのライフサイクルとして設計する必要があります。
導入はシャドーモードから始め、低リスク記憶だけを自動化してください。AWSの参照値を初期仮説にしつつ、自社の誤回答、誤削除、監査要件を測って調整するのが安全です。
出典と検証範囲
一次情報：AWS Machine Learning Blog「Designing lifecycle policies for AgentCore Memory」（2026年9月6日再確認）。構成、保持期間、スコア、費用、評価値はAWS公開記事に帰属します。第三者環境での費用対効果、法令適合性、各業界での最適値は未検証です。