AWS、AgentCore のメモリ廃棄フローをオープンソース化——スケジュール型ワークフローで組み込み TTL の不足を補完

長期稼働するエージェントは、会話の要約、ユーザーの好み、操作経験を継続的に蓄積する。すべての記録を永久に保持すると、検索によって解決済みの事象や期限切れの手順がコンテキストへ再注入される可能性がある。そこで AWS は、[AgentCore Memory のライフサイクルに関するリファレンスアーキテクチャ](https://aws.amazon.com/blogs/machine-learning/designing-lifecycle-policies-for-agentcore-memory/)を公開し、メモリを、アクセス頻度が高く比較的早く失効する episodic memory、より長く保持される semantic memory、慎重に廃棄すべき procedural memory に分類した。

このソリューションは、AgentCore に新たに追加された組み込みの自動 TTL ではない。`ListMemoryRecords` を使用してシステム作成時刻に `BEFORE` フィルターを適用し、EventBridge が毎晩 Step Functions を起動する。ワークフローは複数の Lambda を連携させ、期限切れデータの削除、関連性の評価、バッチ統合、メトリクス出力、監査ログの記録を順番に実行する。episodic memory のデフォルトのハード保持期間は 90 日である。一方、スコアの低い記録は Bedrock モデルによって、信頼度スコアとソース ID を含むセマンティックな要約へ統合され、正常に書き戻された後にのみ元データが削除される。処理に失敗した場合は元のメモリを保持し、SNS を通じてアラートを送信する。

エンジニアリング上の価値は、「忘却」を可観測かつ回帰テスト可能なデータパイプラインへ変える点にある。このサンプルでは、AgentCore Evaluations を使用して整理前後の回答スコアを比較するほか、特定ユーザーのメモリを個別に削除するハンドラー、CloudTrail による API 監査、CloudWatch ダッシュボードも提供している。ただし、[GitHub リポジトリ](https://github.com/aws-samples/sample-memory-lifecycle-policies-for-bedrock-agentcore)には、本番環境向けではないことが明記されている。LLM による統合は本質的に非可逆であり、信頼度スコアも忠実性を証明するものではない。高リスクなデプロイでは、引き続きコールドバックアップを保持し、人による検証または grounding 検証を追加すべきである。

さらに、現在の公開資料にはバージョン間の差異がある。AWS の記事では、作成時刻、最終アクセス、アクセス頻度の 3 要素から成る評価について説明しているが、リポジトリの README では、2 要素を同じ重みで扱う減衰式が示されている。また、記事のフロー図には 5 つの Lambda ステージが記載されている一方、README のリソース一覧には 4 つの関数と書かれている。デプロイ担当者は、サンプルのしきい値をそのまま採用するのではなく、実際の commit と synthesize 後の CloudFormation を基準とし、CloudTrail のクエリコスト、削除処理の冪等性、テナントごとの namespace 分離、データ保持に関する法規制を確認すべきである。