メモリとコンテキスト ─ 4 種のメモリと Sleep-time

ch4 で集めたツール呼び出しの結果は、そのまま context window に積むと即座に破綻する。100 ターンの会話で web 検索を 30 回も叩けば、コストは指数的に膨らみ、精度は context rot で落ちる。これを解くのが Layer 3：メモリとコンテキスト管理だ。

本章では、業務投入できるメモリ層を組むための 5 つの軸を扱う。

軸 1：4 種のメモリを分離する

人間の記憶論を借りた整理が、エージェント設計でも標準化された。

メモリ種	役割	寿命	実装の典型
Working	現在進行中の context window	揮発（セッションで消える）	LLM の context window そのもの
Episodic	出来事ログ（誰が・いつ・何をしたか）	中長期	embedding + timestamp + importance score を vector DB に
Semantic	抽象化された事実（“user prefers DD/MM/YYYY”）	長期	SQL / Postgres の構造化テーブル
Procedural	エージェントが自分の system instruction を書き換える学習方式	永続	prompt store + 反復的 update

ここで重要なのは、4 種類を 1 つのストアにまとめてはいけないということだ。typical なミスは「Mem0 だけで全部やる」「Memory Tool で /memories ファイルだけに突っ込む」という設計で、これは中規模を超えた瞬間に破綻する。

graph TB
    W[Working Memory<br/>context window]
    E[Episodic<br/>vector DB + timestamp]
    S[Semantic<br/>SQL / Postgres]
    P[Procedural<br/>prompt store]
    G[Graph<br/>関係性 / 時系列]

    Agent --> W
    W -.write.-> E
    W -.write.-> S
    W -.read.-> E
    W -.read.-> S
    W -.read.-> P
    P -.update.-> Agent
    E -.relate.-> G
    S -.relate.-> G

LangChain の LangMem v1.0 や Mem0 の最新版は、この 4 分類を組み込みで提供している。

軸 2：長期メモリ専用基盤の選び方

2026-05 時点で本命は 3 つ + 1 つだ。

Mem0 / Mem0g

• 会話から salient information（重要情報）を選択的に抽出するパイプライン
• LOCOMO ベンチで full-context 比 精度 -6pt と引き換えに p95 レイテンシ 91% 削減（17.12s → 1.44s）、トークン 90% 削減
• Mem0g はベクトル + directed labeled graph のハイブリッド（精度差を 5pt 以内に縮小しつつ p95 2.59s）
• 強み：マネージドクラウドで最速の本番投入、user_id / agent_id / run_id / app_id のマルチスコープ
• 弱み：エンタープライズガバナンス（lineage、ポリシー）が薄い

Letta（旧 MemGPT）

• UC Berkeley Sky Computing Lab 発、virtual context management の OS 的階層（Core / Recall / Archival）
• Context Repositories（2026-02-12）：メモリをローカル FS + Git バックエンドでバージョニングし、各 sub-agent が git worktree で並行更新→マージ
• Memory reflection が “sleep-time” バックグラウンドで会話を整理
• 強み：プログラマブルで progressive disclosure が自然、長時間稼働に最適
• 弱み：対話レイテンシは未公開[要検証]

Zep / Graphiti

• Temporal knowledge graph：各事実に valid_at / invalid_at のウィンドウを持つ
• semantic + BM25 + graph traversal の検索、LLM 呼び出しなしで p95 300ms
• LongMemEval (GPT-4o) で 63.8%、Mem0 49.0% を 15pt 上回る
• 強み：「今真である事実」と「過去に真だった事実」を分離、conflict detection が一級市民
• 弱み：グラフ構築のインジェスト時にコスト

Anthropic Memory Tool（2025-09-29 Public Beta）

• クライアントサイドツール、/memories 仮想ディレクトリ上で view / create / str_replace / insert / delete / rename を発行
• 実体は開発者のインフラに保存（ZDR 対応）
• 公式パターン：Multi-session software development（initializer + 進捗ログ + checklist）
• clear_tool_uses_20250919 と組み合わせると 100 ターンで トークン -84% / 精度 +39%

選択軸を整理するとこうなる。

要件	おすすめ
マネージドで最速立ち上げ	Mem0 / Mem0g
Git バックエンドで永続化、コーディング系で sub-agent を分散実行	Letta
「過去の事実」と「今の事実」を区別したい、conflict detection が必要	Zep / Graphiti
Anthropic 純正で ZDR 必須、自前インフラに置きたい	Anthropic Memory Tool

ただし、業務投入で実用的な構成は「これらを単独で使う」ではなく「複数を合成する」。後述の軸 5 でその合成パターンを示す。

軸 3：Compaction と Just-in-time retrieval

Anthropic が 2025-09-29 に公開した Effective Context Engineering for AI Agents は、長時間エージェントの context 戦略を 4 つに整理した。

1. Compaction：会話履歴をサーバ側で要約・置換する。Opus 4.6 の Compaction API は閾値到達時に自動実行
2. Structured note-taking：エージェントが progress.md / NOTES.md などの外部ファイルにメモを書き出す
3. Sub-agents：1〜2K トークンの要約を返す sub-agent に context を分業させる（ch3 軸 3）
4. Just-in-time retrieval：必要な情報を必要なときだけ取りにいく（軸 5 の RAG）

これらを組み合わせることで、100 ターン以上の長セッションでもトークン消費を桁違いに抑えられる。

sequenceDiagram
    participant U as User
    participant A as Agent
    participant Ctx as Context Window
    participant File as progress.md
    participant Mem as Long-term Memory

    Note over Ctx: ターン 1-30 (普通に蓄積)
    U->>A: 質問 30
    A->>Ctx: 通常応答
    Note over Ctx: 80% に到達

    A->>A: Compaction 起動
    A->>Mem: 重要事実を書き出し
    A->>File: progress.md 更新
    A->>Ctx: 古い会話を要約に置換
    Note over Ctx: 30% まで圧縮

    U->>A: 質問 31
    A->>Mem: just-in-time retrieval
    Mem-->>A: 関連する 3 件
    A->>U: 応答

業務投入で重要な数字：100 ターン web search タスクで clear_tool_uses_20250919 + Memory Tool の組み合わせで トークン -84% / 精度 +39% を Anthropic 公式が報告している（出典: Effective context management on the Claude Developer Platform）。

軸 4：Sleep-time Compute と Dreaming

2026 年に入って急速に浮上した概念が Sleep-time Compute だ。Berkeley + Letta が arXiv:2504.13171 で示した枠組みで、エージェントが idle のときに、過去のセッションを review してメモリを再編成する計算を行う。これにより test-time の compute を 5× 削減 できると報告されている。

各社の対応：

• Anthropic Auto Dream：24h + 5 セッション以上で MEMORY.md と話題ファイルを統合・矛盾削除・相対日付を絶対日付化（research preview）
• Letta Memory Reflection：sleep-time バックグラウンドで会話を整理、Defragmentation で 15-25 ファイルに常時整頓
• Mastra Observer + Reflector：会話を 3-6× 圧縮、ツール出力なら 5-40× 圧縮、LongMemEval 84.23% vs RAG 80.05%[要検証]

業務投入の観点では、常時稼働エージェントの設計に「idle 時の再編成プロセス」を最初から組み込むべきだ。これがないと、長期運用するほどメモリが汚染し、conflict detection に依存しても追いつかなくなる。

軸 5：4 レイヤ合成パターン ── 業務投入の現実解

2026-05 時点で、本番運用に耐えるエージェントメモリは1 製品では完結しない。次の 4 レイヤを合成するのが事実上の標準になった。

graph TB
    L1[Layer A: 短期 / セッション内<br/>LangGraph Checkpointer or<br/>SQLite Durable Object]
    L2[Layer B: just-in-time / セマンティック<br/>Anthropic Memory Tool /memories]
    L3[Layer C: 中長期 / vector + graph<br/>Mem0 or Zep]
    L4[Layer D: 永続知識ベース<br/>Postgres + pgvector or<br/>Qdrant + 構造化 SQL]

    Agent --> L1
    L1 -.checkpoint.-> L2
    L2 -.write important.-> L3
    L3 -.consolidate.-> L4
    L4 -.retrieve.-> Agent

各レイヤの役割：

• Layer A：セッション内の state（会話履歴、ツール呼び出しのログ）。クラッシュからの復旧に使う
• Layer B：セッション間の just-in-time な「思い出すべき事実」。/memories/user_preferences.md のような形
• Layer C：中長期の episodic memory。「3 ヶ月前に user は X と言った」のような retrieval
• Layer D：永続的な知識ベース。社内 wiki、ドキュメント、過去のチケット履歴

製品マッピング例：

Layer	製品の組み合わせ
A	LangGraph Checkpointer / Cloudflare Durable Object SQLite / Vercel Workflow state
B	Anthropic Memory Tool（自前 storage）/ Letta Core memory
C	Mem0 マネージド / Zep Graphiti / Letta Recall + Archival
D	Postgres + pgvector / Qdrant + 構造化 SQL / Microsoft Agent Framework Neo4j memory

RAG とハイブリッド検索

メモリの読み出し側は RAG（Retrieval-Augmented Generation）として組み立てるのが一般解だ。2026-05 時点の標準パターン：

1. Ingest (ドキュメント取り込み)
   ↓
2. Embed (ベクトル化、必要なら graph 化)
   ↓
3. Hybrid Index (dense + sparse + 必要なら graph)
   ↓
4. Retrieve (top-20 を hybrid で取る)
   ↓
5. Rerank (Cohere Rerank v4.0 等で top-5 に絞る)
   ↓
6. Generate (LLM が回答)

重要な経験則：

• Hybrid search（dense + sparse + RRF）が 60-80% のケースで pure dense を上回る新デフォルト
• Recall@50 > 90% に到達してから reranker を入れる順が定石（reranker は再現率を上げない）
• Ragas などで faithfulness ≥ 0.9 / answer_relevancy ≥ 0.85 / context_precision ≥ 0.8 を SLA 化

GraphRAG（Microsoft）はエンタープライズベンチで vector RAG 32% に対し 86% / +54pt を出すが、インデキシングコストが 10-40 倍かかる。エンプラ KG が既にあるなら強いが、ad-hoc コーパスでは Mem0g / Graphiti のような 対話駆動でグラフを育てる型のほうが現実的。

❌ アンチパターン：Mem0（または Memory Tool）だけで済ませる

症状
─────────
- ユーザーが「先週言ったよね」と指摘した事実を覚えていない
- 過去の事実と現在の事実が混在し、矛盾する応答をする
- 中長期で運用するほどメモリが汚染し、応答品質が落ちる

根本原因
─────────
- 4 種のメモリを分離していない
- temporal validity（valid_at / invalid_at）の概念がない
- conflict detection を書き込み前に挟んでいない
- Sleep-time / Dreaming で再編成していない

脱出法
─────────
1. 4 レイヤ合成（A/B/C/D）に切り替える
2. Zep / Graphiti を Layer C に入れて temporal validity を一級市民化
3. 書き込み前に conflict detector を必ず通す（新事実 vs 既存グラフの矛盾検査）
4. 24h + N セッションで再編成（Auto Dream / Memory Reflection）

業務投入の観点で重要な 3 点

1. メモリは 4 レイヤ合成が事実上の標準：1 製品で済ませる設計は中規模を超えた瞬間に破綻する。Memory Tool + Mem0/Zep + Checkpointer + 永続 DB の組み合わせを最初から想定する
2. Compaction と外部メモリは対：会話を server-side で要約しつつ、要約で失われる事実を /memories ファイルに先行書き出し。100 ターンで トークン -84% / 精度 +39%
3. Sleep-time / Dreaming を idle 時に走らせる：常時稼働エージェントの設計に再編成プロセスを最初から組み込む。長期運用ではこれがないとメモリ汚染が追いつかない

次章への接続

ch6 では、**メモリの隣りに置く実行環境（sandbox / code interpreter / browser 環境）**を扱う。Firecracker microVM、E2B / Daytona / Modal / Vercel / Cloudflare の住み分け、永続 sandbox の二段構え、egress policy、Computer Use の本番運用設計を順に押さえる。

---

この章のまとめ

• 4 種のメモリ（Working / Episodic / Semantic / Procedural）を分離：1 ストアにまとめると中規模で破綻
• 長期メモリ専用基盤の選び方：マネージド最速 → Mem0、Git バックエンド → Letta、Temporal validity → Zep、ZDR → Anthropic Memory Tool
• Compaction + 外部ファイル + Just-in-time：100 ターンで トークン -84% / 精度 +39%
• Sleep-time Compute / Dreaming で idle 時に再編成、常時稼働では必須
• 業務投入は 4 レイヤ合成：Checkpointer + Memory Tool + Mem0/Zep + 永続 DB
• GraphRAG はインジェストコストでフィルタ：エンプラ KG が既にあるなら強い、ad-hoc では対話駆動型

＋ － ⟳ ✕