AIエージェントメモリと長期コンテキスト 2026 — Mem0 / Zep / Letta / Cognee / Graphiti / Anthropic Memory 詳細ガイド

プロローグ — 1Mウィンドウでもメモリは解決しなかった

2024年、我々は「コンテキストウィンドウが1Mになればメモリ問題は消える」と信じていた。2026年、それは嘘だったと知っている。

1Mトークンを毎ターン送ればレイテンシが爆発し、コストが爆発し、needle-in-haystack 性能が崩壊する。
コンテキストはセッション終了とともに蒸発する。昨日の会話は今日また最初からだ。
モデルがコンテキストを受け取ったからといって、それを活用する保証はない。「lost in the middle」問題は今も健在だ。

だから2026年のAIエンジニアリングで最も熱いインフラカテゴリの一つがエージェントメモリだ。Mem0がYCから登場し、ZepがSeries Aを調達し、Letta（旧MemGPT）は「エージェントOS」を掲げて地位を確立した。Anthropicは2025年にMemory APIをプレビュー公開し、OpenAIはChatGPTにMemory機能をデフォルト搭載した。

この記事はその地形全体を見る。メモリ階層を分解し、主要なライブラリとAPIを一つずつ見て、ストレージバックエンドを比較し、韓国と日本の動きを扱い、最後に誰が何を選ぶべきかを推奨する。

第1章 · 2026年AIエージェントメモリ地図 — Vector / Graph / Episodic 3モデル

エージェントメモリは2026年時点で大きく3つのモデルに収束した。

┌─────────────────────────────────────────────────────────────────┐
│                  エージェントメモリ 3モデル                       │
│                                                                 │
│  ┌──────────────┐   ┌──────────────┐   ┌──────────────────┐    │
│  │ Vector       │   │ Graph        │   │ Episodic         │    │
│  │ Memory       │   │ Memory       │   │ Memory           │    │
│  │              │   │              │   │                  │    │
│  │ 埋め込み+検索 │   │ エンティティ  │   │ 出来事の系列     │    │
│  │ 類似度ベース  │   │ + 関係+推論   │   │ 時間 + 因果      │    │
│  │              │   │              │   │                  │    │
│  │ 代表:        │   │ 代表:        │   │ 代表:            │    │
│  │ - Mem0       │   │ - Cognee     │   │ - Letta          │    │
│  │ - Verba      │   │ - Graphiti   │   │ - Generative     │    │
│  │ - OpenAI Mem │   │ - Zep(graph) │   │   Agents         │    │
│  │              │   │              │   │ - MemoryBank     │    │
│  └──────────────┘   └──────────────┘   └──────────────────┘    │
│                                                                 │
│         （実際の製品はほぼ全てハイブリッド）                       │
└─────────────────────────────────────────────────────────────────┘

各モデルの強みと弱みは明確だ。

モデル	強み	弱み	向くワークロード
Vector	高速検索、シンプルな心象、豊富なインフラ	関係推論が弱い、「なぜ」が分からない	チャットボットFAQ、文書RAG、ユーザー嗜好
Graph	多段階推論、明示的な事実、更新可能	抽出コスト、スキーマ設計の負担	CRM、コードベース、組織図
Episodic	時間 + 因果、出来事の流れ	重い、想起アルゴリズムが複雑	キャラクターエージェント、長期コンパニオン、シミュレーション

実際の製品ではほぼ全てが2つ以上を混ぜている。Zepはベクトル + グラフ + 時間軸、LettaはOSのようにepisodic + semantic + proceduralを束ね、Mem0はベクトル中心にグラフモードをオプションで載せる。

第2章 · メモリ分類 — Short-term / Working / Long-term

ライブラリを比較する前に用語を整理しよう。2026年時点でほぼ全てのメモリシステムが同意する階層は次の通りだ。

┌────────────────────────────────────────────────────┐
│                                                    │
│  Short-term Memory（短期）                         │
│   = LLMコンテキストウィンドウそのもの              │
│   = 現在のターンで見える全メッセージ               │
│   = セッションが終われば消える                     │
│                                                    │
├────────────────────────────────────────────────────┤
│                                                    │
│  Working Memory（作業）                            │
│   = エージェントの「スクラッチパッド」              │
│   = 現タスクに関連する抽出/要約/計画               │
│   = コンテキスト + 外部ストアのアクティブページ    │
│                                                    │
├────────────────────────────────────────────────────┤
│                                                    │
│  Long-term Memory（長期） — 3種類                  │
│                                                    │
│   ┌──────────────────────────────────────────┐    │
│   │ Semantic   — 「知識」。事実、嗜好、定義   │    │
│   │   例:「ユーザーは韓国に住んでいる」       │    │
│   │   例:「プロジェクトXはRustで書かれている」│    │
│   └──────────────────────────────────────────┘    │
│                                                    │
│   ┌──────────────────────────────────────────┐    │
│   │ Episodic   — 「出来事」。時間+因果の流れ  │    │
│   │   例:「先週火曜にAを試して失敗した」      │    │
│   │   例:「Bをリファクタ後にテスト通過」      │    │
│   └──────────────────────────────────────────┘    │
│                                                    │
│   ┌──────────────────────────────────────────┐    │
│   │ Procedural — 「方法」。手順、スキル       │    │
│   │   例:「このcodebaseでPRを開く流儀」       │    │
│   │   例:「このユーザーのデバッグスタイル」   │    │
│   └──────────────────────────────────────────┘    │
│                                                    │
└────────────────────────────────────────────────────┘

この分類は認知科学から借りたものだ（Tulving 1972、Squire 1992）。2023年にStanfordのGenerative Agents論文がこのモデルをLLMエージェントに適用したことで、業界標準となった。

なぜこの階層が重要か？

メモリの種類ごとに保存・想起・忘却の戦略が異なる。
Semanticは更新/上書きが自然で、Episodicは追加のみ。
Proceduralは使用頻度で重み付け、Semanticは信頼度で重み付け。
コンテキストに注入する際の優先順位も違う — 冒頭にprocedural、中盤にsemantic、最後にepisodic。

この分類を頭に入れてライブラリを見ると、それぞれがどこに強いかが見えてくる。

第3章 · Mem0（YC） — 2026年最も人気のメモリライブラリ

Mem0 は2024年にYCを卒業し、急速にデファクト標準となった。シンプルなSDK、よいデフォルト、そして「5分でメモリを追加」というマーケティングが、市場の真ん中を正確に撃ち抜いた。

中核モデル

Mem0の心象モデルはシンプルだ。

会話の中で、LLMが抽出する価値のある事実を取り出す。
事実を埋め込んでベクトルストアに入れる（重複はLLMが統合する）。
新しいメッセージに対して類似度検索で関連事実を想起する。
コンテキストに差し込んでモデルを呼ぶ。

from mem0 import Memory

m = Memory()

# ユーザーメッセージから事実を自動抽出
m.add("私の名前はヨンジュで、Postgresを使っています", user_id="user-42")

# 次のターンで想起
results = m.search("DBは何を使ってる?", user_id="user-42")
# -> [{"memory": "ユーザーはPostgresを使う", "score": 0.91, ...}]

内部的にMem0は2回のLLM呼び出しを行う:

抽出呼び出し — メッセージから事実を取り出し、既存の事実と衝突すれば更新/削除を判断
検索パスはLLMではなく埋め込み類似度

この「抽出呼び出し」のコストがMem0の最大の弱点であり、最大の強みでもある。コストはかかるが、ノイズの少ないメモリが積み上がる。

グラフモードとマルチエージェント

2025年中頃にMem0はGraph Memory機能をGAした。Neo4jをバックエンドにエンティティと関係を併せて保存する。ユーザー - プロジェクト - ツールの関係を推論する必要があるシナリオで有利だ。

またmulti-actorメモリ — user_idの他にagent_id、run_idでメモリを分離する。マルチエージェントシステムで各エージェントが自分の記憶を持てる。

Mem0のポジション

最も向く: チャットボット、アシスタント、ユーザー嗜好ベースのレコメンデーション
最も向かない: 複雑なコードベース推論、長期シミュレーション、学術研究
一言: 「2026年に初めてメモリを追加するなら、90%はMem0から始める」

第4章 · Zep — グラフ + ベクトルハイブリッド（Series A）

Zep は2024年にSeries Aを調達し、エンタープライズメモリカテゴリで地位を確立した。差別化点はグラフ + ベクトル + 時間軸のハイブリッドだ。

中核コンポーネント — Graphiti

ZepのエンジンはGraphitiというオープンソースKG（Knowledge Graph）フレームワークだ。Graphitiの仕事:

会話/文書からエンティティと関係を抽出する。
抽出した事実を双時間KGに入れる。つまり事実ごとにvalid_from / valid_toの時間がある。
同じエンティティの矛盾する事実が入ると、新しい事実をvalidにし、古い事実をinvalid処理（完全削除ではない）。
想起時にグラフ走査 + ベクトル類似度 + 時間フィルタを組み合わせる。

from zep_python.client import Zep
from zep_python.types import Message

client = Zep(api_key="...")
client.user.add(user_id="user-42", first_name="ヨンジュ")

# メッセージ追加 — Zepが自動でKGに統合
client.memory.add(
    session_id="sess-1",
    messages=[Message(role="user", content="会社をAcmeからBravoに移った")],
)

# 想起 — グラフ事実 + 関連メッセージ
mem = client.memory.get(session_id="sess-1")
# -> facts: ["ユーザーはBravoに勤務する（以前: Acme）"]

なぜ時間推論が重要か

伝統的なベクトルメモリの弱点: 新しい事実が入っても古い事実が生き残る。「ユーザーはAcmeに勤務」と「ユーザーはBravoに勤務」の両方が想起されてモデルを混乱させる。

Zep/Graphitiはこれをbi-temporalモデルで解く。事実がいつ起きたか + いつDBに入ったかの両方を記録する。だから想起時に「今の時点でvalidな事実だけ」を自然にフィルタできる。

Zepのポジション

最も向く: CRM、営業アシスタント、長期運用エージェント、規制産業
最も向かない: 単純チャットボット、速いプロトタイプ
一言: 「エンタープライズで『事実の一貫性』が大事ならZep」

第5章 · Letta（旧MemGPT） — エージェントOSアプローチ

Letta（旧MemGPT）はUC Berkeleyで始まったプロジェクトで、2024年にLettaへ社名を変更し会社化された。他のライブラリと毛色が違う — メモリライブラリではなくメモリ中心のエージェントランタイムだ。

中核アイデア — Memory as OS

Lettaの発想はOSの仮想メモリだ。

LLMコンテキストウィンドウ = RAM
外部メモリ（ベクトル + KVストア） = ディスク
LLM自身がツール呼び出しで自分のメモリをページイン/アウトする。

具体的にLettaエージェントは常に次のコンテキストを持つ:

Core memory — ユーザーのペルソナ + 自身のペルソナ（固定、毎ターン見える）
Conversation buffer — 最近のメッセージ（ローリング）
Archival memory — 外部ベクトルストア（検索でアクセス）
Recall memory — 全ての過去メッセージ（検索でアクセス）

エージェントはツールを通じて自分のメモリを編集する。

from letta_client import Letta

client = Letta(base_url="http://localhost:8283")
agent = client.agents.create(
    name="my-agent",
    memory_blocks=[
        {"label": "human", "value": "ユーザーは韓国在住のMLエンジニア"},
        {"label": "persona", "value": "役立つAI同僚"},
    ],
)

# 会話。エージェントは自分の判断でcore memoryを更新する
client.agents.messages.create(
    agent_id=agent.id,
    messages=[{"role": "user", "content": "さっきBravoに転職した"}],
)
# -> エージェントはcore_memory_replaceを呼び出して "human" ブロックを更新

Lettaの差別化点

状態はサーバーに住む。 Lettaエージェントはstateless呼び出しではない — Lettaサーバーに永続状態として存在する。
エージェント間メッセージ — エージェント同士が互いにメッセージを送れる。マルチエージェントが自然。
自己編集メモリ — エージェントが自分のペルソナ/ユーザープロフィールを直接編集する。良くも悪くも。

Lettaのポジション

最も向く: 常時稼働アシスタント、マルチエージェント協調、キャラクター/コンパニオンエージェント
最も向かない: 瞬間的なRAG、stateless APIサービス
一言: 「メモリを一級市民とするエージェントOSが必要ならLetta」

第6章 · Cognee — 知識グラフ自動生成

Cognee は2024年に登場したオープンソースプロジェクトで、「データ → KGの自動変換」に集中する。メモリというよりはエージェント用KGビルダーに近い。

パイプライン — ECL（Extract, Cognify, Load）

ETLを真似たECL:

Extract — 文書/会話/コードを取り込む。
Cognify — LLMがエンティティ/関係/オントロジーを抽出する。DataPointという抽象を置く。
Load — グラフDB（Neo4j、Kuzu、NetworkX）とベクトルDB（LanceDB、Qdrant、...）に保存する。

import cognee

await cognee.add("プロジェクトXはRustで書かれ、Yに依存している")
await cognee.cognify()

results = await cognee.search(
    query_type="GRAPH_COMPLETION",
    query_text="プロジェクトXはどの言語で書かれている?",
)
# -> "Rust"

他のライブラリとの違い

Mem0は事実1行を想起する。
Zepは事実 + 関連メッセージを想起する。
Cogneeはグラフパターンを想起する — 「Xノードに接続したYタイプのノード」のように。

Cogneeのポジション

最も向く: 文書KG、コードベースKG、ドメイン知識グラフ
最も向かない: 速いチャットメモリ、ユーザー嗜好
一言: 「KGがメモリの形ならCognee」

第7章 · Anthropic Memory API（2025プレビュー）

Anthropicは2025年にMemory APIプレビューを公開した。中核の立場: メモリはサーバーサイド状態であるべき。

モデル

Anthropic Memoryのモデルは次の通り。

Conversation state はAnthropicがホストする。クライアントはconversation_idだけを送る。
コンテキストウィンドウ圧迫が高まると、Claudeが自動圧縮を実行する（Claude Codeのcompactが API に入ったもの）。
それ以外に明示的なメモリツールが提供される — memory_save、memory_recall、memory_listなど — Claudeが自分の判断でメモリを書ける。

import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-sonnet-4-7",
    conversation_id="conv-42",   # サーバーサイド状態の識別子
    memory={"enabled": True, "scope": "user-42"},
    messages=[{"role": "user", "content": "昨日言ったあの本をもう一度教えて"}],
)
# Anthropicがconv-42の過去を参照して返答を作る

なぜこれが大きな変化か

これまで全てのメモリはクライアントの責任だった。コンテキストを集め、圧縮し、再送するのも全て。
サーバーサイドメモリはその負担をモデル提供者に渡す。そしてモデルが自分のメモリを最もよく知る — モデルの内部表現と整合した圧縮が可能になる。
欠点: ベンダーロックイン。メモリがAnthropicサーバーに入ればモデルを変えられない。

Anthropic Memoryのポジション

最も向く: Claudeを深く使う製品、速いリリース、クライアント単純化
最も向かない: マルチモデルルーティング、セルフホスト要求、メモリデータ所有権
一言: 「Claudeだけ使うなら、速く出すならAnthropic Memory」

第8章 · OpenAI Memory — コンシューマーChatGPT機能

OpenAI Memoryは毛色が違う。開発者用SDKではなくコンシューマーChatGPTの機能だ。

動作

ユーザーがChatGPTと会話すると、GPTが価値ある事実を自動保存（2024年初頭GA）。
「Memory updated」のインジケータが出てユーザーが認知する。
Settingsでメモリ一覧を見て削除できる。
2025年の「Improved Memory」アップデートで、全ての過去会話を参照可能に拡張。

開発者にとっての意味

OpenAI MemoryはAPIには存在しない。つまり:

ChatGPTのユーザー体験がメモリをデフォルトとして受け入れさせた。これがユーザーの期待値を作った — 「私のAIは私を覚えているべき」。
APIで同じものを作りたければ自分で書くかMem0/Zepを使う必要がある。
ただし2025年からOpenAI Assistants APIは thread + ファイル + vector store の形で同様のものを提供する。

このカテゴリでOpenAIの位置は市場教育者だ。一般ユーザーに「AIメモリ」とは何かを知らしめ、それが次のカテゴリ（Mem0、Zep、Letta）の成長燃料となった。

第9章 · Graphiti — Zepのオープンソース KG フレームワーク

Graphiti はZepが2024年にオープンソース化したKGフレームワークだ。Zep製品のエンジンだが、単独でも使える。

中核設計

Graphitiのスローガン: 「Temporal Knowledge Graphs for AI Agents」。

全てのノード/エッジに valid_from / valid_to 時間属性。
新情報が入ると、LLMが既存エッジとの矛盾を判断してinvalid処理。
想起時に時間 + グラフ + ベクトルを組み合わせたハイブリッド検索。

from graphiti_core import Graphiti
from datetime import datetime

g = Graphiti("neo4j://localhost:7687", "neo4j", "password")
await g.build_indices_and_constraints()

await g.add_episode(
    name="meeting-2026-05-15",
    episode_body="ヨンジュがBravoに転職した。役職はStaff Engineer。",
    source_description="会議メモ",
    reference_time=datetime.now(),
)

results = await g.search("ヨンジュはどこに勤務?")
# -> [{"fact": "ヨンジュはBravoに勤務", "valid_at": "2026-05-15"}]

他のKGフレームワークとの違い

LangChainのKGメモリ — 時間なし、矛盾処理が弱い。
Neo4j LLM Graph Builder — 抽出はできるが想起の抽象がない。
LlamaIndex KG Index — 静的、更新/矛盾解決が困難。

Graphitiの差別化点は、時間 + 矛盾処理が一級市民であることだ。

Graphitiのポジション

最も向く: Zepバックエンド、自前KGメモリ構築、時間推論が核となるドメイン
最も向かない: KGを使わない単純RAG
一言: 「Zepクラウドを使わずKGメモリだけ欲しいならGraphiti」

第10章 · Verba（Weaviate）/ Cody Memories（Sourcegraph）/ MemPress

この3つは狭いドメインに特化したメモリシステムだ。

Verba（Weaviate）

Weaviateが作ったオープンソースRAGチャットボットフレームワーク。
ベクトルメモリに集中し、Weaviateをバックエンドに深く統合。
メモリ自体より「RAG + チャット + メモリ」のフルスタックデモという性格。
向く場面: 社内文書チャットボットをWeaviateの上に素早く立てたい時。

Cody Memories（Sourcegraph）

Sourcegraphのコードアシスタント Cody に入ったメモリ機能。
コードベースコンテキスト + ユーザーのコーディング嗜好 + プロジェクト慣習を保存。
汎用メモリSDKではなく、コードドメイン専用。「このユーザーはtabs派、snake_caseを好む」のような事実。
向く場面: コードアシスタントが「このコードベースでの私」を覚えるべき時。

MemPress

2025年に登場したエージェントメモリ圧縮ライブラリ。
中核アイデア: メモリが積み上がると、LLMで階層的要約を作って検索を速くする。
ツリー構造: 原メッセージ → 日次要約 → 週次要約 → 月次要約。
想起時に上から下へ降りながら徐々に詳細を取り出す。
向く場面: メモリが数万件以上積み上がる長期運用エージェント。

第11章 · Generative Agents（Stanford 2023） — 学術的源流

商用メモリシステムのほぼ全ての設計は、2023年Stanfordの論文 「Generative Agents: Interactive Simulacra of Human Behavior」 に負っている。

実験

25人のAIキャラクターが小さな町（Smallville）で暮らす。
各々がペルソナ、職業、関係、スケジュールを持つ。
ユーザー入力なしにキャラクター同士で相互作用し1日を過ごす。
結果: 自発的な社会的振る舞いが現れる — バレンタインパーティが自発的に組織され、市長選挙キャンペーンが起こる。

メモリアーキテクチャ

論文が提案する3コンポーネント:

Memory Stream — 全ての観測を自然言語で記録（エピソード）。
Reflection — 周期的にLLMがメモリを読んで高次推論を生成（「私には友人が多くない」）。これがメモリに戻る。
Planning — メモリ + 反映をもとに1日の計画を立てる。

想起は importance + recency + relevance の3スコアの加重和だ:

score = a*importance + b*recency + g*similarity

この式は今もほぼ全てのメモリシステムの想起アルゴリズムの基本型だ。

Generative Agentsの遺産

Reflection 概念 — Mem0の抽出、Zepの事実一貫性、Lettaのself-editは全てここから派生。
Importanceスコア — 全ての事実が同等ではないという発想が標準化。
Episodic-first — 意味メモリはエピソードから派生するというモデル。

学術論文1本がカテゴリ全体の設計言語を作った稀な事例だ。

第12章 · ストレージバックエンド — pgvector / Qdrant / Neo4j / Memgraph / Kuzu

メモリライブラリは結局どこかにデータを積まねばならない。2026年でよく使われるバックエンド。

ベクトルバックエンド

バックエンド	特徴	向く状況
Postgres + pgvector	運用負担小、SQL自由度、トランザクション	既にPostgresがあるチーム、メモリ + メタデータ結合
Qdrant	Rustで高速、強力なフィルタリング、セルフホスト寄り	1億+ベクトル、複雑なペイロードフィルタ
Pinecone	マネージド、速い導入、よいSLA	インフラをやりたくない時
Weaviate	マルチモーダル、GraphQL、モジュラー	テキスト以外のモダリティ、自前変換パイプライン
LanceDB	組み込み、Arrowベース、ローカル寄り	ノートブック/エッジエージェント
Chroma	ローカル寄り、シンプルDX	プロトタイプ、デモ

グラフバックエンド

バックエンド	特徴	向く状況
Neo4j	KG標準、豊富なCypher	エンタープライズ、大型KG
Memgraph	C++で高速、Neo4j互換	リアルタイムKG、ストリーミング
Kuzu	組み込み、OLAPカラムナーグラフ	分析型KG、ノートブック
NetworkX	Pythonインメモリ	プロトタイプ、小規模
AWS Neptune	マネージド、Gremlin	AWSエコシステム

2026年の実戦ガイド

始まりはPostgres + pgvector単一DB。メモリ + アプリデータを同居させると運用がシンプル。
グラフが必要になったらKuzu（組み込み）から見る。Neo4jは運用負担が大きい。
ベクトル + グラフを両方永続的に使うなら、Postgres + pgvector + AGE（Apache AGEのグラフ拡張）も1 DBの候補。
想起レイテンシが問題になればQdrant/Pineconeに切り出す。

第13章 · 韓国 / 日本 — Upstage、NAVER HCX、Sakana、PFN

韓国

Upstage — 自社モデルSolarにRAG/メモリレイヤーを統合。韓国語意味検索の品質に強み。エンタープライズアシスタントシナリオ。
NAVER HyperCLOVA X — HCXにメモリ機能を内蔵。NAVERエコシステム（ブログ、カフェ、ショッピング）データと接続したコンシューマーメモリが差別化点。
Kakao — KakaoTalk内のAIアシスタントがユーザーメモリを運用。メッセンジャーコンテキストが豊富で、メモリの自動抽出に有利。
一般傾向: 韓国チームはMem0/Zepをそのまま使うより、韓国語埋め込みモデル（Upstage、Cohere multilingual）と直接結合して自社メモリレイヤーを書くケースが多い。

日本

Sakana AI — 「進化的モデル統合」で有名だが、2025年からエージェントメモリ研究も発表。モデル自体にメモリを統合するアプローチに関心。
Preferred Networks（PFN） — PLaMoモデルシリーズに長期コンテキスト + 外部メモリの結合研究。
Rinna / ELYZA — 日本語特化モデルを作る所。メモリは自前というよりMem0/Zepを日本語埋め込みと結合して使う雰囲気。
一般傾向: 日本はキャラクター/コンパニオンエージェント市場が大きく、Letta型の永続ペルソナメモリ需要が強い。ゲーム/エンターテインメント結合事例が米国より多い。

第14章 · 誰が何を選ぶべきか

シナリオ別の推奨を1枚に圧縮。

シナリオ	第1候補	第2候補	避けるべき
速いユーザー嗜好メモリ（チャットボット、FAQ）	Mem0	OpenAI Assistants threads	KG構築
エンタープライズ、事実一貫性（CRM、営業）	Zep	Graphiti直接 + Neo4j	純ベクトル + 自動忘却
マルチエージェント、永続ペルソナ	Letta	Mem0 multi-actor モード	stateless API + クライアント単純メモリ
コードアシスタントメモリ	Cody Memories（SaaS）または自前 + Mem0	Cognee（コードベースKG用）	汎用チャットメモリそのまま使用
ドメインKG構築（製薬、法務）	Cognee	Graphiti	ベクトルだけで解こうとする
社内文書RAG + メモリ	Verba	Mem0 + 自前RAG	メモリなしRAGだけ
Claude中心の製品、速いリリース	Anthropic Memory API	Mem0 + Claude	自前コンテキストマネジメント
長期シミュレーション、キャラクターエージェント	Letta + Generative Agentsのアイデア	MemPress（圧縮）	ウィンドウだけ拡大
研究、実験	Generative Agentsコードベース + 自前	LlamaIndex Memory + 自前KG	SaaSメモリ（ブラックボックス）
メモリが大きくなりすぎて遅い	MemPress（要約ツリー）	Zep（自前要約）	単純TTL期限

決定木

スタート
  │
  ├─ メモリに「なぜ / いつ / 何が変わったか」が重要か?
  │     YES -> グラフ/時間メモリ必要 -> Zep または Cognee+Graphiti
  │     NO  -> 次へ
  │
  ├─ エージェントが常時稼働で、自分のペルソナを持つべきか?
  │     YES -> Letta
  │     NO  -> 次へ
  │
  ├─ Claudeだけ使い、シンプルさが最優先か?
  │     YES -> Anthropic Memory API
  │     NO  -> 次へ
  │
  ├─ ただ「ユーザー嗜好 + 事実」を覚えて想起できればよいか?
  │     YES -> Mem0
  │     NO  -> 上に戻って再定義
  │
  └─ メモリが数十万件以上に積み上がる予定か?
        YES -> 上の選択 + MemPressで圧縮レイヤー

エピローグ — メモリは2026年AIインフラの次の決定点

2023〜2024年のインフラ議論はベクトルDBだった。2025年はエージェントフレームワークだった。2026年の議論はメモリアーキテクチャだ。

3つの大きな流れを覚えよう。

純ベクトルメモリは第一段階に過ぎない。 時間/矛盾/関係が入ればグラフやエピソードが必要になる。
メモリはモデルより長生きする。 モデルは6ヶ月ごとに変わるが、ユーザーメモリは何年も続く必要がある。だからデータポータビリティが決定的 — メモリをSaaSに閉じ込めるな。
メモリは評価が難しい。 ベンチマーク標準が未成熟。自社の想起評価セット（質問 → 期待事実）を作るのが最も安全。

「エージェントの知能はモデルで決まるが、エージェントの有用性はメモリで決まる」

同じモデルでもメモリシステムが違えば完全に別のアシスタントになる。だからメモリ選択をインフラ決定として扱うべきだ — モデル選択と同じくらい重く。