# AI AgentのMemoryとは — 何を覚えて何を忘れるかの設計

> AI AgentのMemoryの定義、ContextやRAGとの違い、Short-termとLong-termの分離、事実と推測の区別、削除要件まで含む保持設計を整理します。

Canonical URL: https://labs.eastbraver.com/guides/memory
Published: 2026-07-14
Updated: 2026-07-15
Category: field-guide
Tags: ai-agent, software-engineering, agentic-infra

AI AgentのMemoryは、セッションや実行をまたいでAgentが参照する外部状態です。

前提を一つ確認しておきます。モデル自体は何も覚えません。Agentが「覚えている」ように見えるのは、アプリケーションが情報を外部へ保存し、次の推論の[Context](/guides/context)へ選んで戻しているからです。Memoryの設計とは、この保存と想起の設計を指します。

このGuideは、2026年7月14日時点の一次情報を基準にしています。Memory機能はProvider各社が活発に更新している領域のため、実装時には利用する基盤の最新仕様を確認してください。

## Context、RAG、ログと分ける

| 仕組み | 保持するもの | 寿命 |
| --- | --- | --- |
| Context | 一回の推論でモデルへ渡す情報 | その推論の間 |
| Memory | 利用者・Agentに固有の状態 | セッションを越える |
| [RAG](/guides/rag) | 共有される知識・文書 | データ更新まで |
| ログ・Trace | 監査と調査の記録 | Retention期間 |

MemoryとRAGの区別は「固有か共有か」で見ると分かりやすいと思います。全利用者に共通する製品マニュアルはRAGの対象で、この利用者が窓側の席を好むという情報はMemoryの対象です。

ログはどちらでもありません。監査のための記録をモデルの入力へ戻し始めると、保持期間もアクセス制御も設計できなくなります。

## Short-termとLong-termは別の仕組み

[Amazon Bedrock AgentCore Memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html)は、Memoryを二つに分けて提供しています。Session内のやり取りを保持するShort-term memoryと、会話から選好・事実・要約を抽出してSessionを越えて保持するLong-term memoryです。

この分離は実装が違うからです。Short-termは会話履歴の管理で、[Context](/guides/context)の設計とほぼ重なります。Long-termは抽出・保存・想起のパイプラインで、何を残すかの判断が入ります。

[ClaudeのMemory tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool)は別のアプローチで、モデルがfile操作を要求し、アプリケーション側が自分のStorageで実行するClient-side構成です。保存先と内容を完全にアプリケーションが制御できる代わりに、Path traversal対策のような実装責任も自分側に来ます。

研究の系譜としては[MemGPT](https://arxiv.org/abs/2310.08560)が、OSの階層メモリになぞらえて、限られたContext Windowと外部Storageの間で情報を出し入れする管理を提案しています。名前や実装は違っても、どの方式も「Contextに入り切らない状態を外に持ち、必要な分だけ戻す」という同じ問題を扱っている点は変わりません。

## 覚える設計より、忘れる設計が難しい

Memoryの設計で先に決めたいのは、何を覚えないかです。

- モデルの推測を、確認済みの事実と同じ場所へ保存しない
- Credential・秘密情報をMemoryへ入れない
- 個人情報は、保存する根拠・保持期間・削除手段を先に決める
- 古くなった選好や事実を上書き・失効できる形にする
- 利用者ごとにMemoryを分離し、アクセス制御を掛ける

特に推測と事実の混在は、後から分離できません。「利用者は返金を希望している (モデルの解釈)」と「利用者は7月10日に返金を申請した (記録された事実)」が同じ棚に並ぶと、次の推論はどちらも事実として扱います。[Context Engineering](/guides/context-engineering)で構造化した状態を分けるのと同じ理由です。

削除も設計対象です。利用者からの削除要求に応えられないMemoryは、便利な機能ではなく負債になります。

## よくある誤解

### モデルが会話を覚えている

Model APIはStatelessです。保存も想起もアプリケーションの実装で、製品にMemory機能がある場合も、保持範囲と削除条件の確認が必要です。

### 全部保存しておけば賢くなる

古い情報・矛盾・機微情報を抱え込み、想起の品質はむしろ下がります。覚える価値が繰り返し出る情報へ絞ります。

### MemoryはRAGと同じ仕組み

検索技術を共有することはあっても、対象が違います。固有の状態と共有の知識を同じ棚に入れると、権限と削除の設計が壊れます。

### Memoryへ保存すれば次の会話で使われる

保存と想起は別の処理です。次の推論で必要な情報を選んでContextへ戻す設計まで含めて、初めて「覚えている」振る舞いになります。

## EastBraver Labsの判断基準

EastBraver Labsでは、Memoryへ入れる情報を「覚える価値が繰り返し出るか」で選びます。一度しか使わない情報はContextで済み、毎回変わる情報はToolで取る方が正確です。

保存する場合は、項目を列挙して、出所 (事実か推測か)・更新条件・削除条件を先に決めます。この三つを答えられない項目は保存しません。

**削除できないMemoryは作らない。** 便利さより先に、この線を引いておく方が、後から楽になると思います。

## 関連記事

- [モデル運用の選択肢が広がる](/digest/ai-digest-20260707)
- [モデル選定とエージェント運用が接続](/digest/ai-digest-20260714)

## 検証範囲

- 一次情報: 公式ドキュメント / 研究論文 / 設計面からの分析
- ローカル検証: 手元で再現しています
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-14: 初版公開