9月5日、AWSが「Designing lifecycle policies for AgentCore memory」と題した記事を公開した。この記事では、Amazon Bedrock AgentCoreのメモリライフサイクルポリシーを設計・運用するための実践的なアーキテクチャについて詳しく紹介されている。

エージェントのメモリは放置すると腐る

AIエージェントはすべての会話からメモリを生成し続ける。これを管理しなければ、古いコンテキストが蓄積し、応答品質の低下やコンプライアンスリスクを招く。AWSが実際に観測した事例として、4ヶ月前に解決済みのサポート案件をアクティブな問題として扱い続けたカスタマーサポートエージェントや、古くなった運用手順書（runbook）をそのまま参照し続けたエージェントが挙げられている。

こうした問題に対処するため、本記事ではAmazon Bedrock AgentCoreのメモリを「管理されたリソース」として扱うためのライフサイクル管理フレームワークを紹介する。なお、AgentCore自体は2025年に発表された比較的新しいサービスであり、AIエージェントの構築・実行・管理を統合的に担うプラットフォームとして位置づけられている（※編集部の考察）。本フレームワークはAWS Step Functions、AWS Lambda、Amazon Bedrockを組み合わせた夜間バッチワークフローとして実装されており、完全なコードはGitHubリポジトリで公開されている。

まずメモリを3種類に分類する

ライフサイクルポリシーを設計する前提として、記事はエージェントのメモリを以下の3種類に分類している。

• エピソードメモリ（Episodic）：過去の会話記録。タイムスタンプ付きでセッションに紐づく。量が多く、時間経過とともに価値が下がる。有効期限（TTL）の優先対象。
• セマンティックメモリ（Semantic）：会話から抽出された事実や好み。特定のセッションから切り離された永続的な知識として保持される。エピソードより長く保持する。
• 手続きメモリ（Procedural）：エージェントが学習したワークフローやツール利用パターン（「コスト関連の質問にはCost Explorer APIをまず呼ぶ」等）。量は少ないが最も価値が高い。削除の基準は最も厳しくする。

3つのライフサイクルポリシー

Policy 1：TTLによる自動削除

最もシンプルなポリシー。設定したTTLを超えたメモリを自動削除する。デフォルトはエピソードメモリで90日。AgentCore memoryにはビルトインのTTL機能がないため、システムが生成するタイムスタンプフィールド x-amz-agentcore-memory-createdAt に BEFORE フィルターを使って古いレコードを取得・削除する。

cutoff = (now - timedelta(days=ttl_days)).isoformat()

response = client.list_memory_records(
    memoryId=memory_id,
    namespace=agent_id,
    metadataFilters=[{
        "left": {"metadataKey": "x-amz-agentcore-memory-createdAt"},
        "operator": "BEFORE",
        "right": {"metadataValue": {"dateTimeValue": cutoff}},
    }],
)

メモリタイプ別の推奨TTLは、サマリーメモリで30〜60日、セマンティックメモリで6〜12ヶ月、手続きメモリはTTLなし（無期限）。TTL削除はスコアリングや統合の前に実行し、不要なコンピューティングコストを避ける。

Policy 2：関連度スコアによる減衰

記事の核心部分。すべてのメモリが同じ速度で劣化するわけではない。作成からの経過日数・最終アクセスからの経過日数・アクセス頻度の3項目を組み合わせた重み付きスコアリング式を使う。

score = W_RECENCY * exp(-decay_rate * days_since_creation)
      + W_ACCESS  * exp(-decay_rate * days_since_last_access)
      + W_FREQUENCY * min(access_count / MAX_ACCESS_BASELINE, 1.0)

直接的な減衰定数の代わりに、**pruneDays**（アクセスされないメモリがスコア閾値を下回るまでの日数）という直感的なパラメーターを公開している点が実用的だ。デフォルト（pruneDays=45、threshold=0.3）では減衰率は約0.02676となる。

エージェントの種類別の推奨 pruneDays は以下の通り：

また、AgentCore memory APIには lastAccessedAt フィールドが存在しない。そのためAWS CloudTrailで GetMemoryRecord のデータイベントをキャプチャし、S3に保存したアクセス台帳と統合することで、累積アクセス履歴を管理する設計になっている。

Policy 3：LLMによるメモリ統合（Consolidation）

スコアが低いメモリをすぐに削除するのではなく、Amazon Bedrockを使って関連するメモリを1件の簡潔なセマンティックエントリに統合する。「デプロイ設定に関する5件のエピソードメモリ」→「1件の権威ある事実」に変換するイメージだ。

統合プロンプトはLLMに対して要点の保持・重複の除去・信頼スコア（0.0〜1.0）の出力を指示する。信頼スコアが低い統合結果は人間によるレビューのフラグとして使える。Amazon Bedrockの呼び出しに失敗した場合は元のメモリを保持し、削除失敗は手動レビュー用にログ記録される。

記事では「統合は本質的に非可逆（lossy）」と明記しており、ハイリスクなドメインでは元データをコールドストレージにアーカイブすることを推奨している。

夜間バッチのアーキテクチャ

Amazon EventBridgeが夜間にStep Functionsのステートマシンをトリガーし、5つのLambda関数を順番に実行する：

1. Memory Pruner：TTL期限切れのレコードを削除
2. Memory Scorer：CloudTrailログからアクセスデータを取得しスコアを計算
3. Memory Consolidator：低スコアメモリをAmazon Bedrockで統合
4. Metrics Emitter：CloudWatchにワークフローのメトリクスを送信
5. Run Output Writer：実行結果をS3に保存

失敗時はAmazon SNSトピックにアラートが飛ぶ。インフラはAWS CDKスタックとして提供されており、全パラメーター（TTL日数、重みの各係数、バッチサイズ等）は設定値として調整可能だ。

詳細はDesigning lifecycle policies for AgentCore memoryを参照していただきたい。