MemMachine: エージェントの記憶をグラフDBとSQLに分けて永続化するPythonレイヤー
Universal memory layer for AI Agents. It provides scalable, extensible, and interoperable memory storage and retrieval to streamline AI agent state management for next-generation autonomous systems.
ひと目でわかる
- これは何？
- MemMachineは、会話の文脈を episodic memory、ユーザー属性を profile memory として別々のストアに永続化するメモリ層だ。クライアントSDKは薄く、記憶の実体は自前で立てるサーバー側にある。採用判断で最初に見るべきは、このサーバー運用を引き受けられるかどうかである。
- 誰に向いている？
- 自前でNeo4jとSQLを運用できるチーム、あるいはクラウド版を使えるチームには検討の価値がある。記憶ストアの運用を引き受けたくない場合や、会話履歴を単純なベクトル検索で足りると考えている場合は、この構成は過剰になる。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
MemMachineが埋めようとしている穴は「セッションをまたぐと人格が消える」こと
LLMアプリの多くは、セッションが切れるとユーザーに関する知識を失う。プロンプトに履歴を詰め込む方式はコンテキスト長の上限に当たり、要約して持ち回る方式は何を残して何を捨てたかの制御が効かない。MemMachineはこの部分をアプリの外に出す。READMEは「Stop building stateless agents」という言い回しで、ステートレスなエージェントを前提にした開発スタイル自体を対象にしている。
想定読者は3種類に分けて書かれている。エージェントや自律ワークフローを作る開発者、エージェントアーキテクチャを試す研究者、そしてLLMアプリにセッションをまたぐ記憶を持たせたいチームだ。個人が週末に触るチャットボットより、ユーザーごとの文脈を長期間保持する必要がある業務向けエージェントのほうが、この構成の効果は出やすい。
記憶を3種類に分け、保存先も分ける設計
READMEのアーキテクチャ節は、記憶を役割ごとに3つへ分割している。working memoryは現在のセッション内の短期コンテキスト、episodic memoryはセッションをまたぐ会話の文脈、profile memoryはユーザーの事実や嗜好の長期保存だ。
重要なのは保存先も分かれている点で、episodic memoryはグラフデータベース（Neo4j）、profile memoryはSQLに置かれる。会話の流れをグラフとして持つのは、発話同士の関係や時系列のつながりを辿らせるためだと読める。一方で「このユーザーは通路側の席を好む」といった単独で意味が完結する事実は、グラフのノードとして持つより行として持つほうが検索も更新も素直だ。この分割自体は妥当だが、代償としてバックエンドが2系統になる。バックアップ、スキーマ変更、障害時の復旧手順をそれぞれ別に用意する必要がある。
データの流れはREADMEの図の説明に沿うとこうなる。エージェントはRESTful API、Python SDK、MCPサーバーのいずれかでMemMachineに接続し、MemMachineが受け取ったやり取りをepisodicとprofileに振り分けて永続化する。アプリ側は記憶のスキーマを知らないままでいられる。
5行で書けるのはクライアント側だけ
READMEのクイックスタートは、先に前提を明示している。動かすにはMemMachine Serverが起動している必要があり、ローカルで立てるか、コンソールからクラウドアカウントを作るかの二択になる。この一文が導入コストの実質的な全てだ。
クライアントはpip install memmachine-clientで入る。コードはMemMachineClientにbase_urlを渡して初期化し、get_or_create_projectでorg_idとproject_idの組を確保する。次にproject.memory()へgroup_id、agent_id、user_id、session_idを渡して記憶のインスタンスを作る。この4つのIDの組み合わせが記憶のスコープを決めるので、ID設計を後から変えると既存データの引っ越しが発生する。ここは最初に決めておきたい。
書き込みはmemory.add()で、metadataに任意の辞書を付けられる。READMEの例ではcategoryにtravelを入れている。検索はmemory.search()で、戻り値はネストが深い。例ではresults.content.episodic_memory.long_term_memory.episodes[0].contentまで辿って本文を取り出している。記憶の種類ごとに結果の構造が変わるということで、呼び出し側はどの種類を読むかを意識させられる。全種類を横断して平坦なリストが欲しいだけの用途には、この戻り値は煩雑に感じられるはずだ。
サーバー側の起動方法はREADME本文には書かれておらず、ドキュメントのQuick Start Guideへのリンクに委ねられている。Docker、セルフホスト、クラウドの選択肢があるという記述までが確認できる範囲だ。
MCPサーバーを同梱している点が、SDK統合との差になる
MemMachineはMCPサーバーを自前で持つ。memmachine-mcp-stdioはClaude Desktopのようなstdioクライアント向け、memmachine-mcp-httpはWebクライアント向けだ。設定手順はMCPドキュメントに分離されている。
これは単なる接続口の追加ではない。アプリ側にSDKを組み込んでコードを書く統合と、MCPクライアントの設定ファイルにコマンドを1行書く統合では、導入の重さが別物になる。既存のエージェントコードに手を入れたくない場合、MCP経由のほうが変更範囲は小さい。逆に、記憶の書き込みタイミングをアプリのロジックで細かく制御したいなら、SDKで明示的にaddとsearchを呼ぶほうが向いている。MCPはモデル側の判断でツール呼び出しが起きるため、いつ記憶が書かれるかをアプリが完全には決められない。
フレームワーク統合はintegrations/配下にディレクトリとして並んでいる。LangChain、LangGraph、CrewAI、LlamaIndex、AWS Strands Agent SDK、n8n、Dify、FastGPTの8つだ。それぞれの統合がどの程度の成熟度なのかは、READMEからは判断できない。採用時は自分の使うフレームワークのディレクトリを直接開いて、コード量と最終更新を確認するほうが確実だ。
向かないケース: 記憶ストアを増やしたくないとき
この構成の最大の制約は、動かすのにサーバーが要るという点だ。pip installしたクライアントだけでは何も動かない。ライブラリを1つ入れて終わりという使い方は想定されていない。
次に効いてくるのがバックエンドの数だ。episodicにグラフDB、profileにSQLを使う以上、ローカルで試すだけでも複数のミドルウェアを用意することになる。単一プロセスのアプリに記憶を持たせたいだけなら、SQLiteに会話ログを追記して直近N件をプロンプトに戻す実装のほうが、依存も運用も小さい。MemMachineの分割設計は、記憶の種類ごとに検索の性質が違うという前提に立っている。その前提が自分の用途に当てはまらないなら、分割はただの負担になる。
もう1つ、READMEからは確認できない領域がある。記憶の削除や保持期間の扱い、ユーザーからの削除要求への対応、グラフDBが落ちたときの書き込みの挙動といった運用上の論点は、この本文には記述がない。個人情報を扱う用途では、これらをドキュメントで確認してからでないと判断できない。バージョンはv0.3.9で、0.x系が続いている点も、APIの戻り値の構造が今後変わりうることを示している。
比較対象としてのLangGraphのチェックポインタ
同じ「セッションをまたぐ状態」を扱う道具として、LangGraphのチェックポインタがある。アプローチが明確に違う。
LangGraphのチェックポインタは、グラフの実行状態そのものをスレッド単位でスナップショットとして保存する。状態はアプリが定義したスキーマに従い、グラフのノードとエッジがそのまま保存単位になる。復元すると、実行途中の状態から再開できる。記憶はアプリの構造に従属する。
MemMachineは逆で、記憶がアプリの外に独立して存在する。エージェントを別のフレームワークに載せ替えても、user_idとsession_idを引き継げば同じ記憶を参照できる。READMEがinteroperableという語を使っているのはこの意味だ。ただしその代わり、記憶の構造はMemMachine側が決めた3種類に従う。アプリ固有の状態をそのまま保存する用途には向かない。
どちらを選ぶかは、記憶をアプリの一部と見るか、アプリから独立した資産と見るかで決まる。前者ならLangGraphのチェックポインタ、後者ならMemMachineだ。両方を併用する構成も考えられるが、その場合どこまでをどちらに書くかの線引きを先に決めておかないと、同じ情報が二重に保存される。
Apache-2.0と、0.x系を運用に載せるコスト
ライセンスはApache-2.0で、OSI承認の寛容型ライセンスだ。改変、再配布、商用利用が許され、派生物のソース公開義務はない。特許条項が含まれる点がMITとの違いになる。ここから先は法務判断なので、自社のポリシーは別途確認してほしい。
保守コストとして実際に効くのは、バックエンドのバージョン追随だ。Neo4jとSQLの2系統があり、どちらかのメジャーアップデートが来るたびに、MemMachine側の対応を待つか自分で追随するかの判断が生じる。READMEにはrequirementsの内容もDockerイメージのタグ運用も書かれていないため、どのバージョンを固定すべきかはリポジトリのファイルを直接見る必要がある。
リリースの間隔はv0.3.7からv0.3.9までが約1か月で、活発に動いている。裏を返せば、0.x系の間は破壊的変更が入りうる。クライアントの戻り値のネスト構造に依存したコードを書くと、更新のたびに追随が必要になる。バージョンを固定して、更新は自分のタイミングで行う運用のほうが安全だ。記憶のスキーマはアプリのデータモデルに直結するので、ここは他の依存ライブラリより慎重に扱うべき部分になる。
編集部の結論
自前でNeo4jとSQLを運用できるチーム、あるいはクラウド版を使えるチームには検討の価値がある。記憶ストアの運用を引き受けたくない場合や、会話履歴を単純なベクトル検索で足りると考えている場合は、この構成は過剰になる。導入前に確認すべきは、requirements に含まれるNeo4jドライバのバージョンと、docker compose up で起動するコンテナのうちどれが必須かを自分の環境で確かめることだ。
コミュニティノート