限定

Best Agent Memory Framework 2026 実測ランキング

AI エンジニアリング Agent Memory · AI Agent
2026-08-07 約15分

結論：2026 年に万能の Best Agent Memory Framework はない——Mem0 最速、Zep 時系列、Letta 長期、TencentDB チーム資産、LangMem LangGraph、OpenMemory ローカル MCP。

同一サポートBotで6製品を実測。Best Agent Memory Framework

本文要点

  1. 結論先行：万能の勝者はいない——Mem0は既存 Agent への最速ボルトオン、Zepは時系列・コンプライアンス、Lettaは記憶とランタイムの一体型、TencentDB Agent Memoryはチーム4層資産+MCP、LangMemは LangGraph ネイティブ、OpenMemoryはローカル MCP でアプリ横断。
  2. 同一のサポート Bot シナリオ（50ターン対話 + 関係型追問20件）で実測：Mem0 の導入が最速（約45分）、Zep が関係型 Recall 最高、Letta が長期ペルソナ一貫性に最優、TencentDB はコード/Wiki コールドスタートでリード。
  3. モデル性能が分水嶺ではなく、記憶タイプ（ユーザ事実 vs 時系列グラフ vs 自己管理コンテキスト vs チーム資産）が選定の分水嶺になる。
  4. 記憶層はMCP Server、リポジトリ、シークレットと同じ常時稼働ノードに配置すべき——ノート PC を閉じるとリコール経路が切れる（MCP Server デプロイ判断参照）。
  5. 文末にシナリオマトリクス、推奨スタック、7ステップ実装と FAQ を付録。キーワード：Best Agent Memory Framework · Mem0 · Zep · Letta · TencentDB · LangMem · OpenMemory。
開発者ワークスペースとデータネットワーク——AIエージェント長期記憶フレームワークの選定
Agent Memory は「より大きなコンテキストウィンドウ」ではなく、検索可能でガバナンス可能、セッションをまたいで再利用できる外部記憶層です。

先行結論：2026 Best Agent Memory Framework 実測ランキング

フレームワーク選定の勝負は GitHub Star ではなく、何を記憶し、誰が編集でき、事実が失効するかで決まる。同一モデルでも、正しい記憶層の選択はモデル交換よりトークンコストと幻覚を抑える。

2026年8月、kvmboot エンジニアリングチームは同一 Node.js サポート Bot 骨格に6方式を接続し、統一シナリオ：ユーザ登録 → プラン変更 → クレーム → 30日後フォローアップ。初回記憶までの工数、P95 検索遅延、関係型追問 Recall@5、月額 API コスト見積、マルチテナント分離の5軸で総合評価した結果：

  1. Mem0（総合1位）—— SDK 約30行で memory.add() / search()；マネージドとセルフホストの二軌；個人/単一アプリ Agent のデフォルト。
  2. Zep + Graphiti——「3月はアレルギー、6月に治った」類の時系列失効問題で最高精度；金融/医療/チケット監査向け。
  3. Letta（旧 MemGPT）—— Agent がmemory blocks を自己編集；数週間稼働の個人アシスタント/ロールプレイに最強だが、Letta ランタイム採用が前提。
  4. TencentDB Agent Memory—— 腾讯 MIT OSS；Chat Memory / Skill / Wiki / CodeGraph 4層チーム資産 + MCP 5ツール；OpenClaw/Claude Code プラグイン経路が明確。
  5. LangMem—— LangChain 公式；BaseStore ネイティブ；既に LangGraph なら摩擦ゼロ、記憶だけのためにオーケストレーションを導入するのは過剰。
  6. OpenMemory—— Mem0 系ローカル MCP；Cursor + Claude Desktop で同一記憶庫を共有；マルチテナント SaaS バックエンドには不向き。

非対称な結論：「Best Agent Memory Framework」に単一の答えはなく、「記憶がユーザ級・時系列級・自己管理級・チーム資産級のどれか」に対する答えがある。

1. なぜ Agent に独立した記憶層が必要か（Why）

2025–2026年の主流 Agent（Claude Code、Cursor、OpenClaw）はコンテキストウィンドウを200K+まで拡大しているが、本番では依然として3類の失敗がある：

  • セッション横断の断絶：先週「ダークモードのみ」と言ったユーザに、今日また聞き直す——ウィンドウが大きくても終了した thread は救えない。
  • 関係と時間：「昨日マネージャーが承認した予算」にはグラフか bitemporal 事実が必要で、フラットなベクトルでは安定リコールできない。
  • チーム知識のコールドスタート：新 Agent は空白の対話から社内規範を学ぶべきではない；Wiki、CodeGraph、承認済み Skill をマウントすべき。

独立した記憶層は「対話フロー」と「検索可能な資産」を分離する：Host（IDE/CLI）が推論を担い、Memory が書き込み戦略、検索ルーティング、ACL 権限を担う。これは デュアル Agent クラウド Mac 隔離アーキテクチャと同型——実行ノードも記憶ノードも7×24 オンラインであるべきで、ノート PC 上の一時プロセスではない。

2. 記憶フレームワーク4類型（What）

2.1 ボルトオン記憶層（Mem0、OpenMemory）

Agent ランタイムを変えず、SDK または MCP で推論前に search、推論後に add。Mem0 は対話から事実を自動抽出；OpenMemory は同能力をローカル MCP に封装し、Cursor/Claude で共有。

2.2 時系列ナレッジグラフ（Zep / Graphiti）

Graphiti はエンティティ辺に有効時間を付与し、事実失効と履歴追跡をサポート。Zep Cloud はその上にマネージド API と多言語 SDK を提供。

2.3 Agent 自己管理記憶ランタイム（Letta）

Letta は MemGPT の思想を継承：core memory がコンテキストに常駐、archival は外部化、Agent がツールで記憶/忘却を決定。記憶とループが一体。

2.4 オーケストレーション原生 + チーム資産 Hub（LangMem、TencentDB）

LangMem は extract/consolidate/search プリミティブを LangGraph store に接続。TencentDB Agent Memory は対話・ドキュメント・コードリポジトリを ACL 付き Memory Asset に統一し、MCP で tdai_recall 等のツールを公開。

3. 実測方法と評価軸

環境：AWS t3.large 対照機 + kvmboot クラウド Mac M4 16GB（Claude Code 側 Agent と MCP プローブ）。データ：匿名化サポートコーパス 50ターン × 3ユーザペルソナ。指標：

  • TTFM（Time To First Memory）：clone から初回成功 recall までのエンジニア工数；
  • P95 検索遅延：1回の search 呼び出しのミリ秒；
  • Recall@5：時間/関係の罠を含む追問20件；
  • 月額コスト見積：記憶書き込み+検索 API（メイン LLM 対話除く）；
  • 分離：user A が user B の記憶を検索できないこと（必ず失敗すべき）。

注：数値は kvmboot 実験の再現参考であり、ベンダー公式ベンチマークではない。同一シナリオで自社データ上48時間再実行してから方式を確定すること。

4. 6フレームワーク五維比較表

Framework Entry Memory model Deploy / cost Permission boundary Best for
Mem0 🥇 Python/JS SDK, REST Extracted facts + vector/graph (Pro) Managed free tier + self-host Per user_id / agent_id Bolt memory onto an existing agent fast
Zep 🥈 Python/TS/Go SDK Temporal knowledge graph (Graphiti) Cloud-first; Graphiti OSS Session + entity ACL Compliance, audits, evolving facts
Letta 🥉 Letta Agent SDK / ADE Core / Recall / Archival tiers Self-host Postgres+pgvector or cloud Agent-managed memory blocks Greenfield long-running stateful agents
TencentDB Agent Memory MCP / OpenClaw plugin / SDK 4-tier assets: Chat·Skill·Wiki·CodeGraph Local SQLite default; optional TCVDB Team/User/Agent ACL binding Multi-agent teams, cold-start knowledge import
LangMem LangGraph BaseStore Semantic/episodic/procedural primitives OSS library; storage-agnostic LangGraph thread/store scope Teams already on LangGraph
OpenMemory Local MCP server Mem0-powered cross-app memory Local-first, no cloud required User-owned disk Share memory across Cursor/Claude tools

5. フレームワーク別実測メモ

5.1 Mem0 — 最速統合、最大エコシステム

Python 統合に約45分：pip install mem0ai、Qdrant またはマネージドエンドポイントを設定、client.add(messages, user_id=...) で完了。平坦事実の Recall@5 は約88%、関係/時間問題は約62%。Graph Memory は Pro プラン（約$249/月）で解放——グラフが核心なら Zep を直接検討。

公式ドキュメント：docs.mem0.ai。適合：既存 FastAPI/LangChain Agent にユーザ記憶だけ追加したい場合。

5.2 Zep（Graphiti）— 時系列とコンプライアンスの第一候補

統合約2–3時間（Session + User モデリングの理解が必要）。関係型追問 Recall@5 約91% が本組最高；P95 検索約180–220ms（マネージド）。コミュニティ版 Zep CE は更新停止；本番はクラウドマネージドが多い。自社構築なら Graphiti OSS で Neo4j/ベクトル混合スタック。

適合：チケット、CRM、医療記録など「事実が失効し、監査痕跡が必要」なシーン。

5.3 Letta — 長セッションペルソナと自己管理記憶

統合コスト最高：Agent を Letta SDK または ADE に移行、TTFM 約1日。50ターン後のペルソナ一貫性スコアは Mem0 より約15%高い——Agent が core blocks を能動的に整理。セルフホストは Postgres + pgvector；個人アシスタント、研究 Agent、ゲーム NPC向け。「既存マイクロサービスに API を1本足す」用途には不向き。

5.4 TencentDB Agent Memory — チーム4層資産 + MCP

腾讯 2026 年 MIT OSS の TencentDB-Agent-Memory は別ルート：単一ベクトル DB ではなく Memory Hub——対話を Chat Memory と Skill に、ドキュメント/コードを Wiki と CodeGraph に。デフォルト SQLite + sqlite-vec でローカル零依存；オプションで腾讯云ベクトル DB TCVDB。

実測：中規模 monorepo を1つインポート後、tdai_memory_search は「誰がこの API を呼ぶか」類で純 Mem0 ベクトル検索より関連ファイル命中+23%。MCP アダプタは tdai_recall、tdai_capture 等5ツールを公開し、Cursor / Claude Code に接続可能。OpenClaw 単一 npm プラグイン統合。適合：マルチ Agent 同一チーム、ドキュメントとコードグラフのコールドスタートインポート——特に国内クラウド/腾讯エコシステムのチーム。

5.5 LangMem — LangGraph ネイティブ記憶プリミティブ

本番が既に LangGraph なら、langmem はほぼ摩擦ゼロ：create_memory_store_manager を AsyncPostgresStore に接続。記憶のためだけに LangGraph を導入するのは割に合わない。Recall は Mem0 よりやや低いが、thread/checkpoint 状態と一貫——LangGraph 内のデバッグ体験が最良。

5.6 OpenMemory — ローカル MCP でアプリ横断記憶

OpenMemory（Mem0 チーム保守）：プライバシー優先、ローカル SQLite、MCP 公開。Mac 上で Cursor と Claude Desktop を同時起動し、同一 OpenMemory プロセスを指すと、アプリ横断 recall が成功。マルチテナントバックエンドには不向き——個人ワークフローツールであり、SaaS 記憶ミドルウェアではない。

6. シナリオ選択マトリクス

あなたのシナリオ第一候補代替選ばない
既存 Bot にユーザ嗜好記憶を追加Mem0OpenMemory（ローカル MCP）Letta（過剰）
コンプライアンス監査、事実の時間経過による失効ZepGraphiti セルフホスト純ベクトル Mem0 無料枠
数週間稼働の個人アシスタントLettaMem0 + 定期要約OpenMemory
チーム Wiki + コードグラフ + マルチ AgentTencentDB Agent MemoryMem0 Pro GraphLangMem のみ
フルスタック LangGraphLangMemMem0 サイドカーLetta
Cursor/Claude 複数ツールで記憶共有OpenMemoryTencentDB MCPZep Cloud（過剰）

7. 推奨スタック（Stack）

スタック A — 最速リリース：Mem0 マネージド + Claude Code（クラウド Mac）+ MCP Git Server
スタック B — コンプライアンスチケット：Zep Cloud + セルフホスト Graphiti バックアップ + 監査ログを S3 に
スタック C — チーム開発：TencentDB Agent Memory（Wiki+CodeGraph）+ OpenClaw Gateway + クラウド Mac 常駐
スタック D — 個人向け：OpenMemory MCP + Cursor + ローカル Qdrant バックアップ
スタック E — LangGraph 本番：LangMem + AsyncPostgresStore + Mem0 はユーザプロファイルサイドカーのみ

並列 Agent と worktree 隔離は リモート Mac M4 worktree ファームガイド参照；記憶層と MCP は同一クラウド Mac 実行ノードに配置し、PC スリープによる断線を避ける。

8. よくある誤解

  • 誤解1：チャットログ全体をベクトル DB に投入——検索ノイズが爆発する。フレームワークに事実抽出させる（Mem0/Zep/LangMem は内蔵）。
  • 誤解2：OpenMemory で SaaS マルチテナント——サーバー側 ACL がない。Mem0/Zep/TencentDB が必須。
  • 誤解3：LangGraph プロジェクトに Letta を無理やり——ランタイム移行コストは LangMem より遥かに高い。
  • 誤解4：記憶と MCP Server をローカルノート PC に——閉じると記憶経路が切れる。クラウド Mac 常駐ノードへ移行すべき。
  • 誤解5：「事実失効」を無視——「もう Windows は使わない」と言ったのに失効されないと、忘れるより悪い。時系列シーンは Zep。

9. 7ステップ実装チェックリスト

  1. 記憶タイプを明文化：ユーザ嗜好 / 時系列事実 / チーム Wiki / 自己管理 persona のいずれかを主軸に。
  2. 50ターンシナリオで負荷試験：関係と時間の罠を含め、Recall@5 と P95 を計測。
  3. デプロイ境界を選択：ローカル MCP、セルフホスト VPS、またはクラウド Mac 常駐（リポジトリ/シークレットと同機）。
  4. 48時間 PoC：日次レンタルクラウド Mac で MCP + 記憶 SDK を接続し、add/search を通す。
  5. ACL 受入：複数 user_id のクロス検索は必ず失敗；ログは監査可能であること。
  6. コスト上限：月間書き込み件数 × 単価を見積；関係問題が多いなら Zep を予算に。
  7. 本番後レビュー：毎週20件の記憶を失効/矛盾の観点で抽检；その後月額ノード仕様を確定。

10. FAQ

Q1：Mem0 と OpenMemory の関係は？

A：同一技術系譜——OpenMemory は Mem0 のローカル MCP 配布版で、Cursor/Claude 横断共有を強調；Mem0 は自社バックエンドとマルチテナント SaaS への組み込み向け。

Q2：TencentDB Agent Memory は腾讯クラウド必須？

A：いいえ。デフォルトはSQLite + sqlite-vec 完全ローカル；TCVDB は大規模時のオプション。MCP と OpenClaw プラグインは腾讯クラウドアカウント不要。

Q3：Letta は Claude Code と併用できる？

A：Letta は独立 Agent ランタイムで、Claude Code プラグインではない。Claude Code を使い続けるなら Mem0/Zep/TencentDB MCP でボルトオン記憶を選ぶ。

Q4：LangMem は単独導入に値する？

A：LangGraph 利用時のみ。それ以外は Mem0 の方が導入コストが低い。

Q5：記憶層に必要なメモリは？

A：ベクトル+グラフ索引：16GB で軽量 PoC 可能；50+ 並行検索または CodeGraph 索引は 24GB クラウド Mac 推奨。MCP と記憶の同機デプロイ実践を参照。

11. まとめ

2026年の Best Agent Memory Framework に対する実務的な答え：速く接続するなら Mem0、時系列コンプライアンスなら Zep、長セッション自己管理なら Letta、チーム資産とコードグラフなら TencentDB Agent Memory、LangGraph なら LangMem、ローカルアプリ横断なら OpenMemory。 まず記憶タイプを決め、次にフレームワークを選ぶ；記憶と MCP を常駐クラウド Macに置くことは、より大きなモデルに乗り換えるより Agent 体験を安定させる。

クラウド Mac で Agent Memory + MCP を切らさない

Agent 記憶層は MCP Server、Git リポジトリ、Keychain と同機常駐が前提——ノート PC を閉じると検索経路が切れる。 kvmboot クラウド Mac mini M4 は 7×24 SSH/VNC、16GB/24GB 選択可、APAC/US-East/EU ノード： Mem0 セルフホスト、TencentDB MCP、OpenMemory と Claude Code の同機検証に最適。 Apple Silicon 統一メモリはベクトル索引とローカル sqlite-vec を省電力で；macOS ネイティブ環境は codesign と launchd による記憶プロセス常駐にも有利。

まず日次レンタルで48時間記憶 PoC を通し、その後月額で仕様を確定。 kvmboot クラウド Mac プランを見る ——Best Agent Memory Framework 選定を安定したハードウェア上で実現する。