2026年Agent Memory OSS 4選比較

会話履歴を保存したのに、Agentが古い好みや誤った前提を再利用してしまうなら、問題は検索機能ではなく「何を記憶させるか」の定義にあります。

2026年のAgent Memory OSS選びでは、軽量な汎用記憶ならMem0、状態付きAgentの実行基盤ならLetta、時間関係グラフならZepのGraphiti、根拠・推論・監査を重視するならSemanticaを先に評価してください。最初に記憶の種類を分解し、同じ評価データで2候補を並行検証してから本番へ進めるのが安全です。

この比較を読むべきチーム

チャットAgentや業務Agentに長期記憶を追加したい開発者向けです。自前の環境でデータを管理したい企業チーム、知識グラフとAgentランタイムのどちらを採用するか迷っているアーキテクトにも役立ちます。

最終判断は、GitHub上の説明文やスター数ではなく、更新、削除、権限分離、出典追跡まで含めた運用試験で行ってください。この記事は2026年8月14日に更新し、各プロジェクトの公式リポジトリと公式ドキュメントを確認しています。

まず記憶の対象を5種類に分ける

「Agentに長期記憶を持たせたい」という要件だけでは、4候補を公平に比較できません。少なくとも次の5種類に分解してください。

• ユーザーの好み：文体、製品設定、利用履歴など。
• タスク状態：現在の作業、未完了の手順、次に必要な操作。
• イベントの時系列：いつ、誰が、何を変更したか。
• 知識と関係：顧客、契約、製品、担当者のつながり。
• 判断の根拠：どの文書や規則を参照して結論を出したか。

Mem0は、既存のAgentやアプリへ記憶層を追加する用途から始めやすい設計です。公式ドキュメントでは、ライブラリとして組み込む方法と、Dockerベースのセルフホストサーバーという運用形態が示されています。(Mem0公式概要)

Lettaは単なる外部検索層ではなく、記憶を使いながら動く状態付きAgentのプラットフォームです。旧称はMemGPTで、公式リポジトリでは現在の開発が新しいAgent関連リポジトリへ移行していることも明記されています。(Letta公式リポジトリ)

抽象層をそろえてから4候補を比べる

4つを同じ「ベクトルDB製品」として採点すると、選定を誤ります。

Mem0は、会話や事実から再利用しやすい記憶を抽出し、ユーザーやセッション単位で検索する記憶レイヤーです。標準構成ではLLM、埋め込み、ベクトルストア、履歴ストアを組み合わせますが、公式ドキュメント上は各コンポーネントを変更できます。(Mem0 OSSの構成)

Lettaは、Agentの人格、作業状態、メモリーブロック、ツール利用を含むランタイムです。公式ドキュメントでは、アプリへ組み込むSDK、ローカル実行、自前のApp Server、管理型のクラウドという選択肢が説明されています。(Letta公式ドキュメント)

Zepについては、製品本体とGraphitiを分けて考える必要があります。Graphitiはオープンソースのコンテキストグラフで、時間ロジック、ハイブリッド検索、グラフ走査を担います。一方、ZepのContext Lakeや独自エンジンは商用サービス側の機能です。(GraphitiとZepの境界)

Semanticaは、ベクトル検索だけでなく、コンテキストグラフ、因果推論、オントロジー、出典、監査ログを上位層で扱う設計です。公式説明では、既存のLLM、ベクトルストア、Agentフレームワークを置き換えず、意思決定記録やプロヴェナンスを追加する位置付けになっています。(Semantica公式リポジトリ)

書き込みと忘却を本番基準で確認する

記憶機能のデモでは「保存した内容を検索できるか」だけが示されがちですが、本番で問題になるのは誤った記憶の残留です。例えば、ユーザーが所属部署を変更したとき、以前の部署情報を削除または無効化できなければ、検索結果が正しくても回答は誤ります。

検証では、次の順に確認してください。

1. 匿名化した会話、業務イベント、参照文書を同じ評価データとして用意します。
2. 好み、タスク状態、時系列、関係、判断根拠にラベルを付けます。
3. 新しい事実が古い事実を上書きするケースを作ります。
4. 同じ内容を言い換えて複数回投入し、重複記憶を確認します。
5. 取り消し、ユーザー単位の削除、期間指定の削除を実行します。
6. Agentごと、顧客ごと、プロジェクトごとの参照境界を検査します。
7. 最後に、回答だけでなく採用した記憶ID、時刻、出典も記録します。

Semanticaの公式APIには保存、検索、更新、記憶の削除、状態保存と復元に相当する操作が用意されています。Graphitiは、時間による事実の変化や関係を扱う設計を前面に出しています。したがって、両者は「検索結果が似ているか」より、時間と根拠をどこまでモデル化するかで比べるべきです。(Semantica Context Module)

注意：オープンソースであることは、モデル、データベース、認証、監視まで無料で自前運用できることを意味しません。ライセンスだけでなく、依存サービスと運用責任の範囲を確認してください。

自前運用とデータ統制の境界を確認する

ローカル導入のしやすさだけなら、Mem0のライブラリ構成は有力です。公式の標準構成では、ローカルQdrantとSQLiteを使う方法が示されており、サーバー構成ではPostgresとpgvectorが使われます。ただし、既定のLLMや埋め込みモデルは外部モデルを前提にしているため、完全な閉域運用にはモデル部分の置き換えが必要です。

Graphitiは、公式ページでNeo4j、FalkorDB、Amazon Neptuneなど複数のグラフバックエンドに対応すると説明されています。つまり、Graphiti自体を動かせても、可用性、バックアップ、認証、監視は別途設計する必要があります。

Lettaは、状態付きAgentをそのまま動かしたい場合に検討しやすい一方、Agentの状態、ツール、ファイル、モデル接続を含むため、単純な記憶APIより運用範囲が広くなります。Semanticaも、グラフ、ベクトルストア、オントロジー、モデルの組み合わせを考える必要があり、軽量な会話記憶だけを求めるチームには過剰になる可能性があります。

本番前には、次のチェック項目を埋めてください。

• [ ] 記憶データを保存するDBとバックアップ先を決めた
• [ ] LLMと埋め込みモデルを外部利用するか、ローカル化するか決めた
• [ ] ユーザー、Agent、テナント単位のアクセス境界を定義した
• [ ] 記憶の更新、削除、期限切れの処理を確認した
• [ ] 監査ログに出典、時刻、変更者を残せるか確認した
• [ ] ライセンスと商用利用条件をリリース前に再確認した
• [ ] 障害時に記憶なしで安全に応答するフォールバックを用意した

なお、Zepの製品機能をGraphitiのオープンソース機能と同一視しないでください。自前運用の対象をGraphitiに限定するのか、商用のContext Lakeを利用するのかで、費用、認証、SLA、データ管理の責任分界が変わります。

公平な評価をするための指標を固定する

性能や費用について、環境の異なる公開ベンチマークをそのまま比較するのは危険です。モデル、埋め込み、DB、データ件数、キャッシュ状態が違えば、結果の意味が変わるためです。

最低限、同じデータで次の4項目を記録してください。

• 正しい記憶を呼び出せた割合
• 古い記憶を除外できた割合
• 関係や時系列を含む質問への回答根拠
• 削除後に対象データが再表示されないこと

クエリは、単純な好みの検索、複数エンティティの関係検索、過去時点の状態確認、削除済み情報の除外という4種類に分けます。速度や費用の数字を出すなら、同一マシン、同一モデル、同一データ量、同一同時実行数を固定し、測定スクリプトも保存してください。

4候補の向き不向きを一覧で整理する

チーム別に第一候補を決める

原型チームなら、まずMem0を選び、ユーザー嗜好と会話要約の保存・検索・削除を確認してください。導入後に、Agentが独自の状態を更新しながら作業を続ける要件が強くなった場合は、Lettaを並行候補にします。

状態化Agentを作るチームはLettaを第一候補にし、状態の復元、セッション分離、ツール実行後の更新、モデル変更時の挙動を評価します。ZepとLettaで迷う場合は、「関係データを複数Agentで共有したい」のか、「一つのAgentを継続的に成長させたい」のかで分けると判断しやすくなります。

知識グラフのチームはGraphitiを、根拠、因果推論、ポリシー、監査を重視するチームはSemanticaを先に確認してください。特に法務、金融、医療など、回答の理由を後から説明する必要がある場合は、ベクトル検索だけで採用を決めないことが重要です。

本番データをいきなり移行するのではなく、候補2つへ同じ匿名化データを投入し、1〜2週間程度の運用パイロットで差分を記録してください。期間はチームの更新頻度に合わせて決め、短い会話だけでなく、訂正、削除、担当者変更、権限変更を必ず含めます。

現在の構成から移行する前に確認すること

現在の構成が単純なベクトルDBとプロンプト追記だけなら、導入は簡単でも、古い情報の無効化、出典の追跡、テナント分離が弱くなりがちです。逆に、最初から大規模なグラフ基盤へ移ると、データモデルと運用監視の負担が先に膨らみます。

そのため、まずMem0またはLettaで小さな評価環境を作り、関係と時系列が本質的な要件ならGraphiti、根拠と統制が必須ならSemanticaへ進む段階設計が現実的です。継続的に候補を試す環境が必要なら、Mac miniレンタルの構成を確認し、実行時間やデータ保管場所に合う構成を選んでください。

Agent Memoryの検証では、環境を毎回作り直せること、ログを保持できること、複数の開発者が同じ条件を再現できることが重要です。接続や運用条件で迷う場合は、ZavCloudのヘルプセンターで利用条件を確認してから候補比較へ戻ると、ソフトウェア選定と実行環境の問題を切り分けやすくなります。

自前のWindowsやLinux、手元の開発機だけで長期間検証すると、環境差、電源管理、共有権限、バックアップ不足が評価結果へ混ざりやすくなります。短期の試作には既存環境で十分ですが、2候補を同じ条件で継続比較するなら、必要な期間だけMac環境をレンタルするほうが、検証環境の再現性と切り替えやすさを確保しやすいケースがあります。特に、重いAgent処理を常時回すのではなく、候補選定やCI連携のために一時的な開発環境が必要な場合に適しています。