AIメモリシステムの選び方：Mem0、Letta、Zep、Cognee、Memobase比較

AI アプリケーションが一回限りの Q&A から長期利用へ進むと、同じ問題にぶつかります。人、プロジェクト、好み、履歴、変化する状態をどう記憶するのか、という問題です。

現在のメモリソリューションはいくつかの路線に分かれています。アプリとデータベースの間に挟まる「外付けメモリ」のようなものもあれば、Agent 自体をメモリ管理機能付きのシステムに作り替えるものもあります。時間や失効状態を重視するもの、ユーザープロファイル、複数文書推論、コーディング支援に特化するものもあります。

プロジェクト名だけを見ると、すぐに混乱します。より実用的なのは、AI に何を記憶させたいのか、その記憶のためにどれだけアーキテクチャの複雑さを受け入れられるのかを考えることです。

まず結論

Mem0：最も汎用的な外部メモリ層

Mem0 は、AI メモリシステムを理解する最初の基準として適しています。目的は Agent アーキテクチャを書き換えることではなく、アプリケーション、モデル、データベースの間に入り、会話、ユーザーの好み、プロジェクト上の事実などを再利用可能なメモリとして抽出することです。

強みは、汎用性、広いエコシステム、比較的低い導入ハードルです。すでにチャットアプリ、アシスタントアプリ、ワークフローシステムがあり、「この AI は私を覚えている」を追加したいなら、この種のミドルウェアが最初の候補になります。

Mem0 にはローカル版の OpenMemory という方向もあります。魅力は、メモリを自分のコンピューターに保存し、複数のツール間で共有できることです。プライバシーを重視し、ツールごとに文脈を最初から蓄積したくないユーザーにとって重要です。

ただし Mem0 は魔法のスイッチではありません。実運用では次の三点を見ます。

• メモリ抽出が過剰で、無関係な情報が増え続けないか。
• 検索されたメモリが現在のタスクに安定して合うか。
• 長期的なモデル呼び出しと保存コストを制御できるか。

要するに、既存プロジェクトへ素早くメモリを足したいなら Mem0 から見るべきです。一方で、メモリシステム自体に Agent の動き方を定義させたいなら、これは最も重いタイプの方案ではありません。

Letta：メモリを Agent 本体に入れる

Letta の前身は MemGPT で、Mem0 とは別種のものです。

Mem0 が外付けメモリに近いのに対し、Letta はメモリ管理能力を持つ Agent ランタイムに近いものです。大規模モデルを OS に似た枠組みに置き、Agent がどの情報を作業コンテキストに残すか、どれをアーカイブするか、どれを後で取り出すかを判断します。

この路線の利点は、メモリと Agent の行動がより深く結びつくことです。通常のアプリの外側にメモリ層を付けるのではなく、最初から「自分の記憶を管理する Agent」を設計します。

代償も明確です。より重くなります。プロジェクトを Letta の世界に入れ、そのランタイムモデル、状態管理、開発習慣を受け入れる必要があります。

Letta が向くのは、長期稼働する個人 Agent、研究アシスタント、業務アシスタントをゼロから作り、使うほどユーザーを理解するようにしたい場合です。そのフレームワークを中心にシステムを組む意思があるなら候補になります。

Zep / Graphiti：時間を第一級の要素として扱う

多くのメモリシステムの問題は「覚えられない」ことではなく、「古い答えを覚えているが、それが期限切れだと分からない」ことです。

Zep / Graphiti 系の方案の要点は時間です。好みや事実を保存するだけでなく、それがいつ成立し、いつ失効したかも記録します。ユーザーが言い換えたとき、古い記憶は必ずしも削除されず、履歴状態になります。

そのため、変化する関係や事実を扱う場面に向きます。

• 顧客情報とフォロー段階。
• 契約条項とステータス更新。
• 時間とともに変わるユーザーの好み。
• 「今は何が好きか」と「3月には何が好きだったか」の両方を聞く場面。

この路線は多くの場合グラフ構造へ向かいます。状態変化、人物関係、イベントチェーン、タイムラインは自然にネットワークになるからです。利点は証拠の流れが明確になること。欠点はアーキテクチャが重くなり、デプロイと保守のコストが上がることです。

記憶の中心が「現在の好み」だけなら、ここまで重いものは不要かもしれません。バージョン、時間、失効、追跡が頻繁に必要なら、Zep / Graphiti 系の価値は高くなります。

Cognee：文書を推論可能な知識ネットワークにする

従来の RAG は「類似度で断片を拾う」ものに近いです。似た文章は見つけられますが、文書間の関係まで理解するとは限りません。

Cognee の方向は、多くの資料をグラフとベクトルを組み合わせたメモリシステムへ加工することです。断片を保存するだけでなく、エンティティ、関係、構造を抽出し、関係ネットワークに沿って推論できるようにします。

これは大量文書の場面に向きます。

• 社内ナレッジベース。
• 技術文書とプロジェクト資料。
• 法務、契約、製品仕様など複数ファイルにまたがる材料。
• 複数の文書から結論を組み立てる研究タスク。

代償も明確です。データ加工の経路は長く、システム部品も増えます。更新、クレンジング、重複排除、関係抽出も設計が必要です。これは「チャットボットに少し記憶を足す」軽量路線ではなく、「資料庫を推論可能な知識ネットワークに変える」方向です。

Memobase：「ユーザーがどんな人か」を記憶する

Memobase の重点は、すべての出来事を記録することではなく、ユーザープロファイルを整理することです。

他の方案が「何が起きたか」に注目するのに対し、Memobase は「このユーザーはどんな人か」に注目します。興味、習慣、属性、好み、長期的特徴を、読みやすく、編集しやすく、製品で使いやすいフィールドに整理します。

C 向け製品では特に有用です。

• AI コンパニオンはユーザーの性格と関係の境界を理解する必要がある。
• 教育製品は学習段階、弱点、目標を覚える必要がある。
• 推薦システムは安定し、編集可能な好みプロファイルを必要とする。
• 健康、効率、生活系アシスタントは長期的な習慣を追う必要がある。

Memobase の境界もここにあります。汎用イベント追跡や複雑な文書推論には最適ではありません。むしろ「人物カード型のメモリ層」として、ユーザーが誰で、何を好み、どんな習慣を持つかを整理するものです。

AgentMemory：コーディング助手向けの会話横断メモリ

AgentMemory はより垂直な方案です。主に AI コーディング助手の古典的な問題を解決します。新しい会話を開くたびに、プロジェクト背景をもう一度説明しなければならない問題です。

開発者が本当に保存したいのは雑談の記憶ではなく、次のような情報です。

• プロジェクトの技術スタックとディレクトリ構造。
• 既に共有されているコードスタイル。
• 触るべきでないファイル。
• よく使うコマンドとテスト方法。
• 前回どこまで調査したか。

これらを会話横断で複数のコーディング助手に共有できれば、繰り返しのプロンプトを大きく減らせます。AgentMemory は純粋な開発場面、特にチームや個人が同じプロジェクト群を長期保守する場合に向きます。

ただし汎用メモリ基盤ではありません。カスタマーサポート、コンパニオン、推薦、知識ベースでは、通常は前述の方案を先に見ます。

Text2Mem：メモリシステムに操作命令セットを定義する

Text2Mem は、メモリ操作プロトコルに近いものです。関心は、メモリシステムが追加、更新、マージ、削除、検証、構造化出力をどう行うべきかです。

発想は三点に要約できます。

• モデルに自由に書かせるのではなく、原子的な操作でメモリ変更を記述する。
• 固定の JSON 契約でメモリ操作を運び、制御不能な出力を減らす。
• 検証層で結果をチェックし、誤った記憶を直接システムに書き込まない。

この種の方案は、メモリシステムの「制御面」に向いています。すでに Mem0、Zep、Graphiti、または自作メモリ層があるなら、Text2Mem の価値はそれらを置き換えることではなく、メモリ書き込み動作を制約することにあります。

ReMe：ファイル即メモリ、ユーザーが直接見られる

ReMe は Alibaba AgentScope エコシステム由来で、キーワードは「ファイル即メモリ」です。

多くのメモリシステムはブラックボックスです。ユーザーはシステムが何を覚えたのか分からず、直接修正するのも難しい。ReMe はより透明な方向で、記憶をユーザーが見て、編集し、管理できるファイルにします。

これは信頼性に関わります。特に個人アシスタント、企業アシスタント、長期 Agent では、ユーザーは記憶がすべて隠れたシステム内で管理されることを望まないかもしれません。直接編集できることは、ユーザーが誤りを直し、自分で文脈を整理できることを意味します。

説明可能性、制御性、移行性を重視する場面に向きます。代償は製品設計が必要になることです。ファイル構造、権限、同期、競合処理を丁寧に設計しなければなりません。

memU：メモリ自体をバックグラウンド Agent にする

memU のパラダイムはより攻めています。メモリは受動的な保存先ではなく、継続的に動くバックグラウンド Agent になります。

通常のメモリシステムは、会話が起きたときに抽出、検索、更新します。memU の構想は、メモリ層を 24/7 働かせ、能動的に整理、アーカイブ、圧縮、更新、コンテキスト準備を行わせるものに近いです。

この方向は想像力があります。真に長期稼働する Agent は、ユーザーが話したときだけ記憶について考えるべきではないからです。ただし、より多くのエンジニアリング課題も生まれます。

• バックグラウンド整理が重要な記憶を誤って変更しないか。
• 能動更新のトリガー条件をどう定義するか。
• コストをどう制御するか。
• ユーザーはそれが何をしたかをどう監査するか。

実験的 Agent や個人向け長期アシスタントを作っているなら、この方向は注目に値します。生産システムでは、まず制御性と観測可能性を確認する必要があります。

選定の目安

既存アプリに長期記憶を追加したいだけなら、まず Mem0 を見ます。十分に汎用的で、導入コストも受け入れやすいです。

ゼロから長期 Agent を作り、Agent ランタイムを中心にプロジェクトを再構成する意思があるなら Letta を見ます。通常のプラグインではなく、「メモリを持つ AI 本体」に近いものです。

ビジネスが時間、状態変化、履歴追跡に強く依存するなら、Zep / Graphiti を優先します。顧客、契約、好み、関係ネットワークでは、「いつ成立し、いつ失効したか」を知る必要があります。

大量の資料を処理し、複数文書を横断して推論したいなら Cognee を見ます。単なる類似度検索より、文書を知識ネットワークに変える場面に向きます。

製品の中心がユーザー本人の理解なら Memobase を見ます。AI コンパニオン、教育、推薦、生活アシスタントには、読めて編集できるユーザープロファイル層が必要です。

関心が AI コーディング助手の会話横断メモリなら AgentMemory を見ます。場面は狭いですが、問題は非常に現実的です。

自作メモリシステムを作っているなら、Text2Mem、ReMe、memU は三つの補助方向として見られます。操作仕様、透明な編集可能性、そしてメモリを能動的なバックグラウンド過程にする方向です。

簡単な判断フレーム

四つの質問で絞り込めます。

1. 記憶対象は何か。

   ユーザープロファイル、プロジェクト背景、会話上の事実、文書知識、または時間とともに変化する業務状態でしょうか。

2. メモリにタイムラインは必要か。

   古い状態にも価値があるなら、上書き更新だけにしない方がよいです。

3. どれだけアーキテクチャを変えられるか。

   Mem0 は外付けに向きます。Letta は Agent の動き方を作り直す場合に向きます。Cognee と Zep/Graphiti は、より重いデータ層を伴うことが多いです。

4. ユーザーは記憶を直接編集する必要があるか。

   透明性と制御が必要なら、ReMe や Memobase のような考え方が参考になります。

まとめ

AI メモリシステムに単一の正解はありません。軽量導入なら Mem0、メモリ内蔵 Agent なら Letta、時間状態なら Zep / Graphiti、複数文書推論なら Cognee、ユーザープロファイルなら Memobase、コーディング助手なら AgentMemory です。

重要なのは、「どれが最強か」ではなく、「何を記憶したいのか」を先に問うことです。記憶対象が変われば、最適な技術ルートも変わります。