会話中は理解していたAIが、翌日になるとまた同じ質問をする。逆に、一度話した古い好みをいつまでも正しいものとして扱う。この二つはどちらも「記憶がない、または記憶の扱いが悪い」ことで起きます。履歴を全部保存すれば解決するほど単純ではありません。
先に結論を言うと、AIエージェントのメモリは会話ログそのものではなく、現在の仕事に必要な情報を保持し、後で関連するものだけを取り出し、訂正や削除まで管理する仕組みです。短期、作業状態、長期を分け、「何を忘れるか」から設計する必要があります。
最初に結論
AIエージェントのメモリは、同じ会話内の流れを保つ短期記憶、複数工程の進捗を持つ作業記憶、セッションをまたいで嗜好や重要事実を再利用する長期記憶に分けて考えると整理できます。すべての発言を永久保存するのではなく、目的に必要な情報だけを抽出し、利用者単位で分離し、出典・更新日時・削除方法を持たせるのが基本です。
この記事のポイント
- ・コンテキストウィンドウ、会話履歴、長期メモリは同じものではない
- ・長期記憶では保存より、抽出、統合、検索、訂正、忘却が難しい
- ・好みや過去判断には出典と更新日時を持たせ、古い情報を上書きできるようにする
- ・個人情報や機密情報を記憶する前に、目的、同意、保存期間、削除手段を決める
対象：会話型AIや業務エージェントを企画・運用する事業責任者、開発者、データ管理者
1. AIエージェントの記憶は3種類に分ける
短期記憶は、現在の会話で直前に何を話したかを保つものです。作業記憶は、調査中の仮説、未完了の手順、作成途中のファイルなど、仕事を終えるまで必要な状態です。長期記憶は、別の日にも使う利用者の好み、過去の決定、成功・失敗から得た知見を対象にします。
大きなコンテキストウィンドウがあっても、長期記憶の代わりにはなりません。全履歴を毎回入れると、費用と待ち時間が増え、関係ない情報が回答を乱す可能性があります。GoogleのMemory Bankも、履歴から重要情報を抽出し、更新・統合し、必要時に検索する流れを分けています。
| 種類 | 主な役割 | 保存期間の例 | 業務例 |
|---|---|---|---|
| 短期記憶 | 現在の会話をつなぐ | 一つのセッション | 「その商品」の指示対象を保つ |
| 作業記憶 | 途中状態と未完了作業を保つ | 仕事が完了するまで | 分析の仮説、調査済みURL、未処理項目 |
| 長期記憶 | 別セッションで重要情報を再利用 | 目的に応じて期限を設定 | 顧客の希望、承認済みルール、過去の学び |
| 外部知識 | 組織共通の事実を検索 | 文書の有効期間に従う | 就業規則、商品仕様、指標定義 |
2. 長期記憶は保存箱ではなく処理の流れ
長期メモリは、発言を丸ごと保存して終わりではありません。「出張では通路側を希望する」のような再利用価値のある事実を抽出し、既存の記憶と重複していないかを確認し、利用者へひも付けます。新しい発言と矛盾したら、最新情報を優先しつつ変更履歴を残します。
回答時には、質問に関係する記憶だけを検索してコンテキストへ入れます。関係の薄い記憶まで渡すと、モデルは重要度を判断しにくくなります。AWSのAgentCore Memoryも、短期イベントから長期情報を抽出・統合し、検索する段階を分けています。
- 候補を抽出する：会話から将来も必要な嗜好、事実、決定、学びだけを取り出します。
- 統合する：重複や矛盾を確認し、出典と更新日時を付けて整理します。
- 範囲を分ける：利用者、組織、案件ごとの名前空間へ保存し、混線を防ぎます。
- 必要時に検索する：現在の目的に関連する記憶だけを選んでモデルへ渡します。
- 訂正・削除する：本人や管理者が内容を確認し、変更または忘却できるようにします。
3. ECの接客エージェントで考える
美容商品の接客を例にすると、「敏感肌で香料を避けたい」は次回の提案にも役立つ可能性があります。一方、「今日は予算3,000円」は今回だけの条件かもしれません。「少し考えます」のような相づちは長期保存する必要がありません。情報の種類ごとに期限と再利用目的を分けます。
さらに、肌質やアレルギーに関する情報は慎重に扱う必要があります。記憶すると便利だから保存するのではなく、何の提案に使うのかを示し、本人が確認・訂正・削除できるようにします。商品カタログや在庫は個人メモリへ複製せず、更新元を持つ外部知識から都度取得します。
- 長期候補：本人が継続利用を望む好み、明示した制約、過去の確定選択
- 短期候補：今回の予算、現在比較している商品、未完了の質問
- 保存しない候補：相づち、推測だけの属性、目的のない機微情報
- 外部知識：価格、在庫、配送日、規約など更新頻度が高い共通情報
4. 何を覚えるかより、何を忘れるかを決める
メモリ設計では、保存条件、利用条件、失効条件を一組にします。たとえば顧客の好みなら「本人が明示した内容だけ」「提案時だけ利用」「一年後に再確認」と決めます。推測した属性を確定事実のように保存すると、誤りが将来の会話へ増幅されます。
利用者単位の分離も欠かせません。家族の共有端末、担当者の交代、法人と個人のアカウントなど、誰の記憶かが曖昧になる場面を先に洗い出します。メモリへのアクセス権は通常のデータベースと同様に管理し、モデルが必要な範囲だけ検索できるようにします。
| 設計項目 | 確認する質問 | 最低限残す情報 |
|---|---|---|
| 保存 | 将来どの業務で再利用するか | 目的、情報種別、本人または情報源 |
| 検索 | 誰がどの条件で読めるか | 利用者ID、案件ID、アクセス権 |
| 更新 | 矛盾した情報をどう扱うか | 更新日時、出典、旧値の扱い |
| 忘却 | いつ不要になり、誰が消せるか | 有効期限、削除手順、監査記録 |
5. メモリの品質は正答率だけでは測れない
評価では、覚えるべき情報を保存できたかだけでなく、保存してはいけない情報を除外できたか、必要な場面で正しい記憶を取り出せたか、古い記憶を優先しなかったかを分けて測ります。保存精度と検索精度を一つの点数にすると、原因を直せません。
本番では、メモリを使わない対照条件も残します。記憶を増やした結果、回答が自然になっても、誤った個人化や不要な費用が増えることがあります。苦情、訂正、削除要求、別利用者との混線を監視し、問題時にメモリ利用を止められる設計にしてください。
- 正解セットを作る：保存すべき発言、保存しない発言、更新すべき矛盾例を用意します。
- 工程別に測る：抽出、統合、検索、回答利用を個別に評価します。
- 安全性を確認する：利用者混線、機微情報、削除後の再出現をテストします。
- 期限を見直す：使われない記憶と古い記憶を定期的に失効させます。
次に読む記事
参考文献
本記事は以下の公式文書、標準、論文、公開記事・投稿を確認し、初心者向けに論点を再構成しています。 仕様や制度は更新されるため、導入時はリンク先の最新版も確認してください。
- Vertex AI Agent Engine Memory Bank available in preview — Google Cloud（2025-07-08）（最終確認：2026-08-07）：記憶の抽出、統合、検索とセッションをまたぐ利用を確認
- Building smarter AI agents: AgentCore long-term memory deep dive — AWS（2025-10-15）（最終確認：2026-08-07）
- Amazon Bedrock AgentCore、東京を含むAWSリージョンで一般提供開始 — AWS Japan（2025-10-15）（最終確認：2026-08-07）
- Effective context engineering for AI agents — Anthropic（2025-09-29）（最終確認：2026-08-07）：限られたコンテキストへ必要な情報を選んで渡す原則を参照
- Vertex AI Memory Bankに関する公式投稿 — Google Cloud India on X（2025-08-12）（最終確認：2026-08-07）：継続的な対話への関心を確認する補助資料。仕様は公式ブログで確認
よくある質問
会話履歴を保存すれば長期メモリになりますか？
履歴は材料ですが、それだけでは長期メモリになりません。再利用価値のある情報を抽出し、重複と矛盾を整理し、現在の質問に関係するものだけを検索する仕組みが必要です。
RAGとAIエージェントのメモリは同じですか？
重なる技術はありますが、役割は異なります。RAGは主に文書やデータから根拠を検索し、メモリは会話の状態、利用者の好み、過去の経験などを継続利用します。共通知識はRAG、個別の継続情報はメモリと分けると管理しやすくなります。
長期メモリには何を保存しない方がよいですか？
利用目的のない機微情報、モデルが推測しただけの属性、すぐ変わる価格や在庫、相づちなどは原則として保存しません。必要な場合も、本人への説明、期限、訂正・削除方法を先に決めます。
まとめと次の一歩
便利なメモリほど多く保存する、という考え方は危険です。誰の情報か、いつまで有効か、どの発言を根拠にしたかを持ち、忘却と訂正まで設計して初めて、継続利用に耐える記憶になります。