LabHub

ブログ

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

2026-05-16 · 29 分で読めます · #ai-memory#agent-memory#mem0#zep#letta#memgpt#cognee#graphiti#anthropic-memory#openai-memory#generative-agents#verba#vector-memory#knowledge-graph#deep-dive#japanese

한국어English日本語

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

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

だから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エージェントに適用したことで、業界標準となった。

なぜこの階層が重要か？

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

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

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

中核モデル

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

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

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

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

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

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

Mem0のポジション

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

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

中核コンポーネント — Graphiti

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

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のポジション

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

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

中核アイデア — Memory as OS

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

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

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

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のポジション

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

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

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

ETLを真似たECL:

  1. Extract — 文書/会話/コードを取り込む。
  2. Cognify — LLMがエンティティ/関係/オントロジーを抽出する。DataPointという抽象を置く。
  3. 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"

他のライブラリとの違い

Cogneeのポジション

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

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

モデル

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

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 Memoryのポジション

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

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

動作

開発者にとっての意味

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

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

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

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

中核設計

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

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フレームワークとの違い

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

Graphitiのポジション

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

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

Verba（Weaviate）

Cody Memories（Sourcegraph）

MemPress

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

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

実験

メモリアーキテクチャ

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

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

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

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

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

Generative Agentsの遺産

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

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

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

ベクトルバックエンド

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

グラフバックエンド

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

2026年の実戦ガイド

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

韓国

日本

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

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

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

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

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

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

参考 / References

コメント

まだコメントはありません。

ログインするとコメントできます