MemoryOS を採用する前に読む: 階層記憶アーキテクチャと MCP サーバの実際
[EMNLP 2025 Oral] MemoryOS is designed to provide a memory operating system for personalized AI agents.
ひと目でわかる
- これは何？
- MemoryOS は AI エージェント向けに短期・中期・長期の記憶を階層管理する仕組みを提供する。README とリリースノートから、構成・導入手順・制約を整理する。
- 誰に向いている？
- MemoryOS が向くのは、長期対話でユーザーごとのペルソナ記憶を保持したいエージェント開発者と、MCP 経由で既存クライアントに記憶を後付けしたいチームである。一方、単発の質問応答や、記憶の書き換え経路を完全に監査したい用途には合わない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 71 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
MemoryOS が埋めようとしている穴
LLM のコンテキストウィンドウは有限で、会話が長引くほど古い発話は押し出される。要約して詰め込む方法もあるが、要約はユーザーごとの細かな嗜好や過去の経緯を落としやすい。MemoryOS はここを、OS のメモリ管理に倣った階層構造で扱おうとする。README は短期・中期・長期のペルソナ記憶を持ち、ユーザープロファイルと知識を自動更新すると説明している。対象は、同じユーザーと何度もやり取りするパーソナル AI エージェントを作る開発者である。単発の検索や要約タスクには、この階層は過剰な仕掛けになる。
Storage・Updating・Retrieval・Generation の4モジュール
README によれば、MemoryOS は Storage、Updating、Retrieval、Generation の4つを中核モジュールとして持つ。記憶を保存し、更新し、必要時に取り出し、応答に組み込む、という流れである。階層は短期・中期・長期の3層で、論文の要旨では「short-term, mid-term, and long-term personal memory through hierarchical storage, dynamic updating, retrieval, and generation」と表現されている。設計上は、保存先エンジン、更新戦略、検索アルゴリズムを差し替え可能な部品として扱う。V1.2 で ChromaDB 対応が追加されたことは、この差し替え構造が実際に機能している証拠の一つと言える。ただし README からは、各層の境界が何を基準に決まるかまでは読み取れない。
セットアップで触る設定値
導入手順の全体は README の該当セクションと公式ドキュメントに委ねられているが、設定パラメータとして名前が確認できるのは similarity_threshold である。2025-07-08 のニュース項目に「New Config Parameter」として追加が記され、設定ファイルの場所はドキュメントページへの参照が示されている。この値は、検索時に記憶を引き出すかどうかのしきい値に関わると推測できるが、README はその既定値も推奨範囲も示していない。埋め込みモデルは BGE-M3 と Qwen3 が PyPI と MCP でサポートされたと 2025-07-14 の項目にある。推論モデル側は OpenAI、Deepseek、Qwen など複数が挙げられ、Deepseek-r1 や Qwen3 の構成にも触れている。
MCP サーバとして既存クライアントに差し込む
MemoryOS-MCP は、モジュール化されたツールを MCP サーバ経由で呼び出し、各種 AI アプリに長期記憶を付与する経路である。README のサポート表にはエージェントクライアントとして Claude Desktop が挙がっている。つまりエージェント側の実装を書き換えず、クライアントの設定に MCP サーバを追加する形で記憶を持たせられる。2025-07-14 には MCP の並列化による高速化が告知され、2025-07-07 には PyPI 実装が並列化最適化で5倍高速になったと記されている。ただしこの数値はプロジェクト側の告知であり、条件の詳細は README からは分からない。
LoCoMo の数値と、それが示さないもの
README は LoCoMo ベンチマークで F1 が平均 49.11%、BLEU-1 が 46.18% 改善したと主張している。これは記憶管理の品質を測る指標としては大きい。だが注意点がある。F1 と BLEU-1 は生成テキストの一致度を測る指標であり、記憶の更新が正しく行われたか、誤った記憶が混入しないかといった側面は別途確認が要る。README は再現手順を公開していると述べているので、数値をそのまま受け取るのではなく、自分のデータで再現する前提で読むのが妥当である。ベンチマークの改善幅は、実運用のレイテンシやコストを保証しない。
向かない場面と、代替との違い
MemoryOS は記憶の更新に LLM 呼び出しを伴う。V1.2 のリリースノートが ChromaDB 内の固定 LLM 呼び出しの不具合を修正したと記しているのは、その依存の現れである。記憶の書き込み経路を完全に決定的にしたい用途、たとえば監査要件が厳しいシステムでは、この設計は扱いにくい。代替として、検索拡張生成を単純なベクトル検索だけで組む方法がある。ユーザーごとのプロファイルを都度検索してプロンプトに詰める方式で、階層も自動更新も持たない。MemoryOS との違いは、記憶を「管理対象」として階層化し更新するか、単なる検索対象として扱うかにある。前者は長期の一貫性に向き、後者は実装と検証が単純である。
ライセンスと維持コストの見取り図
ライセンスは Apache-2.0 で、リポジトリのバッジもこれを示している。商用利用や改変の余地は比較的広いが、実際の条件は同ライセンスの原文で確認する必要がある。ここで法的助言はできない。維持の観点では、リリースが v1.0 から V1.2 まで約1週間で進んでおり、変更の速度は速い。設定キーや対応ベクトルDBが短期間で増えているため、導入時はバージョンを固定し、更新時に similarity_threshold の挙動と埋め込みモデルの対応状況を確認するのが現実的である。
編集部の結論
MemoryOS が向くのは、長期対話でユーザーごとのペルソナ記憶を保持したいエージェント開発者と、MCP 経由で既存クライアントに記憶を後付けしたいチームである。一方、単発の質問応答や、記憶の書き換え経路を完全に監査したい用途には合わない。導入前に確認すべきは similarity_threshold の既定値と、使用する LLM および埋め込みモデルが同一プロバイダに固定されていないかである。V1.2 のリリースノートに ChromaDB 内の固定 LLM 呼び出しの修正が挙がっている点は、記憶の更新経路が LLM 呼び出しに依存していることの裏返しでもある。
コミュニティノート