💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 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 │ │

│ └──────────────┘ └──────────────┘ └──────────────────┘ │

│ │

│ （実際の製品はほぼ全てハイブリッド） │

└─────────────────────────────────────────────────────────────────┘

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

| モデル | 強み | 弱み | 向くワークロード |

| --- | --- | --- | --- |

実際の製品ではほぼ全てが**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の心象モデルはシンプルだ。

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呼び出し**を行う:

- 抽出呼び出し — メッセージから事実を取り出し、既存の事実と衝突すれば更新/削除を判断

- 検索パスは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:

1. **Extract** — 文書/会話/コードを取り込む。

2. **Cognify** — LLMがエンティティ/関係/オントロジーを抽出する。**DataPoint**という抽象を置く。

3. **Load** — グラフDB（Neo4j、Kuzu、NetworkX）とベクトルDB（LanceDB、Qdrant、...）に保存する。

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が自分の判断でメモリを書ける。

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コンポーネント:

1. **Memory Stream** — 全ての観測を自然言語で記録（エピソード）。

2. **Reflection** — 周期的にLLMがメモリを読んで**高次推論**を生成（「私には友人が多くない」）。これがメモリに戻る。

3. **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候補 | 避けるべき |

| --- | --- | --- | --- |

決定木

スタート

│

├─ メモリに「なぜ / いつ / 何が変わったか」が重要か?

│ 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

- [Mem0 — GitHub mem0ai/mem0](https://github.com/mem0ai/mem0)

- [Mem0 Documentation](https://docs.mem0.ai/)

- [Zep — Long-Term Memory for AI Assistants](https://www.getzep.com/)

- [Zep GitHub — getzep/zep](https://github.com/getzep/zep)

- [Graphiti — GitHub getzep/graphiti](https://github.com/getzep/graphiti)

- [Graphiti Documentation](https://help.getzep.com/graphiti)

- [Letta — GitHub letta-ai/letta](https://github.com/letta-ai/letta)

- [Letta Documentation](https://docs.letta.com/)

- [MemGPT paper — Towards LLMs as Operating Systems](https://arxiv.org/abs/2310.08560)

- [Cognee — GitHub topoteretes/cognee](https://github.com/topoteretes/cognee)

- [Cognee Documentation](https://docs.cognee.ai/)

- [Anthropic Memory & Context Management](https://docs.anthropic.com/en/docs/build-with-claude/context-windows)

- [OpenAI — Memory and new controls for ChatGPT](https://openai.com/index/memory-and-new-controls-for-chatgpt/)

- [Generative Agents paper — Park et al., Stanford 2023](https://arxiv.org/abs/2304.03442)

- [Generative Agents code — joonspk-research/generative_agents](https://github.com/joonspk-research/generative_agents)

- [MemoryBank paper](https://arxiv.org/abs/2305.10250)

- [Verba — GitHub weaviate/Verba](https://github.com/weaviate/Verba)

- [Sourcegraph Cody Memory](https://sourcegraph.com/docs/cody)

- [Postgres pgvector — GitHub pgvector/pgvector](https://github.com/pgvector/pgvector)

- [Qdrant — GitHub qdrant/qdrant](https://github.com/qdrant/qdrant)

- [Weaviate](https://weaviate.io/)

- [Pinecone](https://www.pinecone.io/)

- [LanceDB — GitHub lancedb/lancedb](https://github.com/lancedb/lancedb)

- [Chroma — GitHub chroma-core/chroma](https://github.com/chroma-core/chroma)

- [Neo4j](https://neo4j.com/)

- [Memgraph](https://memgraph.com/)

- [Kuzu — GitHub kuzudb/kuzu](https://github.com/kuzudb/kuzu)

- [Apache AGE — Postgres graph extension](https://age.apache.org/)

- [LlamaIndex Memory module](https://docs.llamaindex.ai/en/stable/module_guides/deploying/agents/memory/)

- [LangChain Memory documentation](https://python.langchain.com/docs/how_to/chatbots_memory/)

- [Upstage Solar](https://www.upstage.ai/)

- [NAVER HyperCLOVA X](https://clova.ai/hyperclova)

- [Sakana AI Research](https://sakana.ai/)

- [Preferred Networks PLaMo](https://www.preferred.jp/en/projects/plamo/)

- [Tulving 1972 — Episodic and Semantic Memory](https://alicekim.ca/12.EpisodicSemantic72.pdf)