AgentCore memory lifecycle policiesが示すAIエージェント記憶管理｜忘れる設計をどう本番運用に入れるか

目次

---

1. AIエージェントは、覚えるより「忘れる」設計が難しい

AIエージェントを業務に入れるとき、多くの議論は「どれだけ賢く覚えられるか」に向かいます。顧客ごとの好みを覚える。過去の会話を踏まえる。前回の調査結果を再利用する。確かに、記憶がなければエージェントは毎回ゼロから説明を求める存在になり、業務効率化の効果は限定されます。

しかし本番運用で難しいのは、むしろ「何を、いつまで、どの粒度で残し、いつ消すか」です。古い顧客情報を残し続ければ誤った提案につながります。機密性の高い会話を長期記憶へ入れれば、アクセス権限や監査の問題が起きます。不要な履歴を抱え込めば、検索精度もコストも悪化します。

AWSが2026年9月4日に公開したAmazon Bedrock AgentCore memoryのライフサイクルポリシー解説は、この課題を正面から扱っています。この記事では、AWSの公式ブログをもとに、AIエージェントの記憶管理を企業がどう設計すべきかを整理します。ポイントは、記憶を単なる便利機能ではなく、保存期間、要約、関連度、削除、監査を含む運用資産として扱うことです。

2. AWSの発表で確認できること

AWSの公式発表によると、Amazon Bedrock AgentCore memoryは、AIエージェントが複数セッションにまたがってユーザーや業務の文脈を保持するための機能です。発表では、ライフサイクルポリシーを使うことで、短期メモリと長期メモリに保存期間を設定し、不要になった情報を自動的に期限切れにできると説明されています。

AgentCore memoryには、会話の流れを保持する短期メモリと、時間をまたいで再利用する長期メモリがあります。長期メモリはさらに、意味的な事実や知識を扱うsemantic memory、ユーザーの好みや設定を扱うuser preference memory、会話の要点を残すsummarization memoryとして整理されています。AWSは、それぞれの種類に異なる保持期間を設定できる点を強調しています。

具体例として、短期メモリの保存期間を30日、長期メモリの保存期間を90日にする構成が示されています。別の例では、意味的な記憶を30日、ユーザー設定を365日、会話要約を180日とするように、記憶の種類ごとに保持期間を変えています。重要なのは、すべての記憶を同じ期間で残すのではなく、業務上の価値とリスクに応じて分ける考え方です。

また、AWSは関連度スコアにも触れています。長期メモリから情報を検索するとき、関連度のしきい値を設定し、しきい値を下回る記憶を結果から除外できます。発表では、0.0から1.0までの範囲でしきい値を設定し、用途に応じて緩めにも厳しめにもできると説明されています。さらに、LangGraphとStrands Agentsとの統合例も示されており、記憶管理をエージェントフレームワーク側の会話フローに組み込む前提が見えます。

3. 企業にとっての焦点は、記憶を運用資産として扱えるか

AIエージェントの記憶は、業務価値を大きく左右します。たとえばカスタマーサポートでは、前回の問い合わせ、契約プラン、よく使う製品、過去の不満を踏まえて対応できれば、顧客体験は改善します。営業支援では、過去の商談で出た懸念、意思決定者、次回提案の宿題を覚えていれば、担当者が毎回情報を貼り直す必要が減ります。

一方で、記憶はリスクにもなります。退職者のアクセス権限が残ったまま会話履歴を参照できる。古い価格表を前提に見積案を作る。個人情報や契約情報を、本来不要なエージェントが長期記憶として保持する。こうした問題は、モデル性能だけでは解決できません。記憶をどの業務単位で分け、どの情報を残し、どの情報を忘れさせるかを、システム設計として決める必要があります。

ここでライフサイクルポリシーが効いてきます。従来のAIチャットでは、履歴を残すか消すかが大まかな設定になりがちでした。エージェント運用では、記憶の種類ごとに扱いを変える必要があります。問い合わせ対応の短期文脈は数日から数週間で十分かもしれません。顧客の明示的な設定や契約上の希望は長く残す価値があります。会議要約はプロジェクト終了後に消すべき場合もあります。

企業にとって重要なのは、AIの記憶を「気が利く機能」として現場任せにしないことです。データベース、ログ、ファイル保管、CRMと同じように、保存目的、保存期間、参照権限、削除手順、監査方法を定義する。AWSの発表が示しているのは、AIエージェントの記憶管理が、いよいよ本番運用の設計項目になったということです。

4. 短期・長期・要約を分けて設計する

エージェントの記憶設計では、最初に短期メモリと長期メモリを分けて考えるべきです。短期メモリは、現在進行中の会話やタスクを成立させるための文脈です。問い合わせ対応であれば、今のスレッド、直近のエラー内容、担当者の依頼が該当します。短期メモリは便利ですが、長く残すほど古い情報が混ざりやすくなります。

長期メモリは、次回以降も再利用する価値がある情報です。顧客が希望する納品形式、社内用語、プロジェクトの基本方針、過去の決定事項などが入ります。ただし、長期メモリに入れる情報は慎重に選ぶ必要があります。会話に出たすべてを長期化すると、検索結果に不要な文脈が増え、エージェントが古い判断を現在の前提として扱う可能性があるからです。

AWSが示すsemantic memory、user preference memory、summarization memoryの分類は、実務でも使いやすい考え方です。semantic memoryは「事実や知識」、user preference memoryは「ユーザーや顧客の希望」、summarization memoryは「会話の要約」と捉えられます。この3つを分ければ、保持期間や承認フローを変えやすくなります。

たとえば、ヘルプデスクAIなら、直近の障害対応履歴は短期メモリに置きます。部署ごとの標準環境やよくある設定はsemantic memoryに整理します。利用者が希望する連絡方法はuser preference memoryに残します。長い会話の結論だけをsummarization memoryとして保存し、詳細なログは別の監査基盤へ残す。こうした分離をしておくと、便利さと統制を両立しやすくなります。

5. 本番導入前に決めるべきライフサイクルポリシー

ライフサイクルポリシーは、エージェント導入後に慌てて決めるものではありません。業務要件、法務、セキュリティ、現場運用をつなぎ、最初の設計段階で決めておくべき項目です。特に、複数部門で使うAIエージェントでは、部門ごとに必要な記憶の寿命が違います。

最初に決めるべきなのは、記憶の分類です。業務上の事実、ユーザー設定、会話要約、一時的な作業メモ、監査ログを混ぜない。分類が曖昧だと、保持期間も削除条件も決められません。次に、記憶を作成するタイミングを決めます。AIが自動で長期記憶へ保存してよいのか、人間確認を挟むのか、特定のタグやフォーム入力だけを記憶対象にするのかで、リスクは大きく変わります。

保持期間も用途別に考えます。短期メモリは、会話やタスクの終了後に短い期間で期限切れにするのが基本です。顧客設定やプロジェクト方針のように長く使う情報は、明示的な根拠と更新責任者を持たせます。会議要約は、プロジェクトや契約の期間に合わせて保存期間を決めると運用しやすくなります。

関連度スコアのしきい値も、意外に重要です。しきい値を低くすると、多くの記憶を拾える一方で、無関係な情報が回答に混ざりやすくなります。しきい値を高くすると、精度は上がりやすい反面、必要な文脈を取り逃がす可能性があります。問い合わせ対応、社内検索、営業提案、開発支援のように用途が違えば、適切なしきい値も変わります。本番では、回答品質と差し戻し理由を見ながら調整するべきです。

実務では、次のチェックリストから始めると整理しやすくなります。

• 記憶を短期、意味記憶、ユーザー設定、要約、監査ログに分けている
• 長期記憶へ保存する条件と、保存しない情報を明文化している
• 部門、顧客、プロジェクトごとに参照できる記憶の範囲を分けている
• 保存期間を記憶の種類ごとに決め、期限切れ処理を自動化している
• 関連度スコアのしきい値を用途別にテストしている
• 古い記憶よりも、承認済みドキュメントや最新データを優先する
• 記憶の作成、参照、更新、削除を監査できる
• 利用者からの削除依頼や、契約終了時のデータ削除に対応できる

このチェックは、エージェントの自由度を下げるためのものではありません。AIが安全に文脈を使える範囲を明確にし、現場が安心して委任できる状態を作るためのものです。

6. 注意点：記憶の便利さは、説明責任と表裏一体になる

AIエージェントの記憶管理で最も危険なのは、「便利だから残す」という判断だけで進めることです。記憶は多いほど賢く見えますが、多すぎる記憶は回答の根拠を見えにくくします。なぜこの提案をしたのか。どの会話を参照したのか。古い情報を使っていないか。利用者が説明を求めたときに答えられなければ、本番業務には載せにくくなります。

個人情報や機密情報も注意が必要です。営業、採用、医療、金融、法務のような領域では、会話の中にセンシティブな情報が自然に混ざります。AIがそれを長期記憶として保持すると、後から利用目的やアクセス権限の説明が必要になります。記憶に入れてよい情報と、ログとしてだけ保管すべき情報と、そもそも保存しない情報を分けるべきです。

また、要約記憶には要約ミスのリスクがあります。長い会話を短くまとめると、決定事項と未決事項、仮説と合意、担当者の意見と会社の方針が混ざることがあります。要約を長期記憶として使う場合は、人間が確認した要約だけを正式な記憶にする、または重要な判断には原本ログを参照できるようにする設計が必要です。

最後に、削除は運用で確認する必要があります。TTLを設定していても、実際に期限切れになった情報がどのタイミングで検索対象から外れるのか、監査ログには何が残るのか、バックアップや外部連携先には残らないのかを確認しなければなりません。エージェントの記憶は、アプリ内部だけで完結しないことがあります。CRM、チケット管理、ベクトルDB、ログ基盤、データレイクとつながるほど、削除範囲を明確にする必要があります。

7. まとめ

AWSが公開したAgentCore memoryのライフサイクルポリシー解説は、AIエージェントの本番運用が「記憶をどう持つか」から「記憶をどう管理し、どう忘れるか」へ進んでいることを示しています。短期メモリ、長期メモリ、semantic memory、user preference memory、summarization memoryを分け、保存期間や関連度スコアを設計できることは、企業利用にとって重要な前進です。

ただし、機能があるだけでは十分ではありません。企業側には、どの記憶を作るか、誰が参照できるか、いつ消すか、何を監査するか、古い記憶をどう更新するかを決める責任があります。AIエージェントが業務の文脈を覚えるほど、説明責任、データ保護、権限管理、削除対応は避けて通れません。

OpenBridgeでは、AIエージェント開発、Amazon Bedrockを含む生成AI基盤設計、RAG、MCP連携、社内データ連携、監査ログ設計まで含めて、企業向けAIシステムの導入を支援しています。AIエージェントを本番業務に入れるなら、モデル選定だけでなく、記憶のライフサイクルを最初から設計することが、継続的に使えるAI活用の土台になります。