問い合わせ窓口やサポート業務でAIエージェントを活用する際、過去のやり取りや顧客の個別事情を長期記憶として蓄積すると、文脈を踏まえた柔軟な応対が可能になります。一方で、不要になった情報がいつまでも参照され続けたり、顧客管理側で削除された情報がAI側に残り続けたりすることは避けなければなりません。
AWSは2026年10月13日、Amazon Bedrock AgentCore Memoryの長期記憶レコードに対し、保持期間を指定して自動削除を行えるTTL（Time-to-Live）機能の提供を開始したと発表しました。詳細はAWSによるAgentCore MemoryのTTL対応発表で公開されています。長期記憶レコードは既定では期限切れにならず、TTLの設定は任意です。今回のアップデートにより、必要に応じて保持期間を設定してデータの肥大化防止や古くなった知見の段階的な破棄を行えるようになりましたが、TTLを設定しないレコードは従来どおり期限切れにならず保持され続けます。
TTLの最小期間と「削除待ち」の挙動
設定を追加するにあたっては、自動削除のタイミングと読み出しの仕様を把握しておく必要があります。AWSの公式ドキュメントであるAgentCore開発者ガイドの長期記憶TTL設定解説によると、保持期間として指定する日数（recordExpiryDurationDays）の最小値は31日と定められています。数日単位の短いサイクルで揮発させたい用途には対応していません。
また、指定した保持期間が経過しても、データが即座に消滅するわけではありません。期限切れレコードの削除はバックグラウンド処理として行われ、削除が完了するまでに通常数日かかる場合があります。その間も、レコードの取得処理（RetrieveMemoryRecordsやGetMemoryRecord、ListMemoryRecordsなど）を実行すると期限切れのデータが返される可能性があります。そのため、退会手続きや契約終了などに伴い「特定の日時以降は絶対に参照されてはならない情報」を扱う場合は、TTLによる自動消去を待つのではなく、DeleteMemoryRecordやBatchDeleteMemoryRecordsといった削除APIを呼び出して明示的に消去する処理の組み込みが必要です。
戦略側の変更とバッチ更新における適用ルールの違い
運用中に保持期間を変更する場合も、反映のされ方に注意が必要です。記憶を生成する戦略（Strategy）側でTTLの期間を変更したり解除したりしても、過去に作成された既存レコードの期限が一括で更新されることはありません。設定変更後に新しく生成されるレコードから新設定が適用され、保存済みのレコードは元の期限を保持します。
一方で、バッチAPI（BatchUpdateMemoryRecords）を用いて既存レコードの内容を更新する場合は、リクエスト内容によって期限の扱いが変化します。リクエスト内で保持期間を明示すればその指定で上書きされ、新たにTTLを付与することも可能です。ただし、保持期間の指定を省略して更新を行った場合でも、そのレコードに既存のTTLが設定されていれば、最後に適用されていた期間を使って期限が再計算（リセット）されます。内容を微修正しただけのつもりでも保持期間が実質的に延長されるため、更新頻度が高い業務データでは意図しない長期保持にならないか検証が欠かせません。なお、バッチAPI経由の書き込みには戦略側のTTL設定が引き継がれないため、保持期間を変えるにはリクエスト側で明示する必要があります。
運用管理の面では、権限設計も分離されています。TTLの設定や解除には、通常の書き込み権限に加えてbedrock-agentcore:UpdateMemoryRecordExpirySpecificationという専用のIAMアクションが必要です。日常的な会話ログの書き込みを行うシステムと、データ保持ポリシーを管理する管理者の権限を分けて運用できる構成になっています。
国内の保守受付業務を想定したデータ連携の考え方
この仕組みを国内の業務へ取り入れる場面として、たとえば保守サポートの受付窓口を仮定してみます。顧客管理システム（CRM）に登録されている「連絡方法の希望（メール優先、担当者不在時の連絡先など）」をAIエージェントの長期記憶に渡し、日常の問い合わせ対応でスムーズに参照させるケースです。
この構成では、まずAIに記憶させる情報がどのような業務要件で不要になるのかを整理します。一般的な過去履歴の整理であれば、31日以上のTTLを設定して段階的に破棄させる運用で十分な場合があります。しかし、顧客から連絡先変更の申し出があったり、保守契約の解約に伴って顧客情報を抹消したりする場面では、AI側の記憶も同期して更新・削除しなければなりません。
AgentCore側で仕様として確認できるのは、TTLの日数指定やAPI呼び出し時のパラメータ設定までです。元システム側で顧客情報が変更・削除された際に、対応するAI記憶のレコードIDを特定し、更新APIや明示削除APIを発行するイベント連携については、利用している顧客管理システムの標準機能や既存の連携基盤で実現できる範囲を確認したうえで、個別開発が必要かを判断する必要があります。また、更新時にTTL指定を省略すると期限がリセットされる挙動や、削除待ちの期間に参照されるリスクを踏まえ、検証環境で実際のデータの動きを確かめながら設計を進めることが大切です。
デノフに相談できること
デノフのサービス案内では、Webサイトや社内業務システムの設計・開発・運用保守とともに、業務の整理からAIを活用する業務の選定、ツール選定、現場業務に合わせた自動化の仕組みづくりまでを一貫して支援しています。
AIエージェントに社内データや顧客の文脈を持たせる際、どのような項目をどの期間保持すべきか、元となる業務システムの変更・削除処理とどう結び付けるかは、ツールの機能設定だけで解決しない業務設計の課題です。デノフでは、AIへ渡す業務情報の選定から、既存の顧客管理や問い合わせ管理との連携要件の整理、保持期間の変更や明示削除を含めた試作検証、導入後の運用保守の切り分けまで、お客様の業務実態に合わせてご相談を承っています。自社の業務データを安全かつ実践的にAIとつなぎたい場合は、デノフへの相談窓口よりお気軽にお問い合わせください。
