MemOS 2.0 レビュー: LLM エージェント向け自己進化型メモリ OS の実力と導入経路
LLM および AI エージェント用の自己進化するメモリ OS: 超永続メモリ、ハイブリッド取得、およびクロスタスク スキルの再利用により、トークンを 35.24% 節約します。
ひと目でわかる
- これは何？
- MemOS は LLM エージェントに永続メモリを与える TypeScript 製のオープンソース基盤です。グラフ構造のメモリ、ハイブリッド検索、スキル再利用を備え、クラウド API から完全ローカル運用まで選択肢があります。本稿ではその仕組みと制約を検証します。
- 誰に向いている？
- MemOS は、OpenClaw や Hermes エージェントに永続メモリを組み込みたい開発者、あるいは自前インフラでメモリ基盤を構築したいチームにとって有力な選択肢です。特にローカルプラグインは SQLite と FTS5 による完全オンデバイス動作を謳っており、データ外部送信が許されない用途に適合します。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 6 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
エージェントの記憶をOSとして抽象化する
MemOS は、LLM エージェント向けに「記憶」を一元管理するための基盤です。単なるベクトルストアではなく、グラフ構造で記憶を表現し、追加・検索・編集・削除を単一の API で提供します。これにより、エージェントの会話履歴やユーザー嗜好、ツール実行の痕跡を構造化して保持できます。対象は、カスタマーサポートで過去チケットを参照したい開発者、複数エージェント間で記憶を共有・分離したいチーム、あるいはローカル完結で記憶を持たせたいエッジ環境の利用者です。特筆すべきは、記憶がブラックボックスではなく「検査・編集可能なグラフ」として設計されている点です。この設計は、デバッグや監査が必要な実運用では大きな利点になります。
ハイブリッド検索とマルチキューブ構成の仕組み
MemOS の検索は、FTS5 による全文検索とベクトル検索を組み合わせたハイブリッド方式です。README によると、ローカルプラグインでは「FTS5 + vector」の構成で、SQLite を永続化層に使います。この構成は、キーワード一致と意味的類似性の両方を拾えるため、記憶の再現精度を高める狙いがあります。さらに、メモリは「キューブ」と呼ばれる知識ベース単位で管理されます。複数キューブを組み合わせることで、ユーザーやプロジェクト単位の分離、共有、動的な合成が可能です。これは、マルチテナント的な運用や、エージェントごとに記憶範囲を変えたい場合に有効です。また、非同期の取り込み処理は MemScheduler が担当し、ミリ秒単位のレイテンシを謳っています。高並行環境での安定性を重視した設計と言えます。
クイックスタート: クラウドAPIとローカルプラグインの2経路
導入経路は大きく分けて4つあります。クラウド API は、API キーを取得して HTTP リクエストを送るだけです。README の例では、Python の requests ライブラリで `https://memos.memtensor.cn/api/openmem/v1` のエンドポイントに `add/message` と `search/memory` を POST します。ヘッダーには `Authorization: Token {API_KEY}` を指定し、`user_id` や `conversation_id` を渡します。一方、ローカルプラグインは `npm install` とエージェント固有の設定で導入できます。OpenClaw 向けには `openclaw plugins install` コマンドが用意されています。セルフホストの場合は Docker Compose で起動し、インフラとして Neo4j と Qdrant が必要です。つまり、クラウド API はインフラ不要、ローカルプラグインは SQLite のみ、セルフホストは Neo4j と Qdrant という具合に、運用負荷が段階的に異なります。
ベンチマークの解釈と注意点
README には LoCoMo 88.83、LongMemEval 89.20、PersonaMem v2 40.58 など、複数のベンチマーク結果が掲載されています。また、OpenClaw のタスク完了率が 36.63% から 50.87% に改善したと報告されています。ただし、これらの数字は OmniMemEval という評価フレームワークを通じて得られたものであり、商用メモリ製品14種との比較に基づいています。ここで注意すべきは、ベンチマークのスコアは特定のデータセットとタスク設定に依存する点です。例えば、BrowseComp-Plus は 23.85 と低く、SWE-Bench も 38.46 です。つまり、MemOS はすべてのタスクで万能ではなく、タスク種別によって効果が大きく変わります。導入を検討する際は、自社のユースケースがどのベンチマークに近いかを確認する必要があります。
ローカルプラグインの実態: SQLite と FTS5 の制約
ローカルプラグインは「100% ローカル、クラウド依存ゼロ」を売りにしていますが、その実装は SQLite と FTS5 に依存しています。これは、PostgreSQL や Elasticsearch に慣れた運用者には物足りなく感じるかもしれません。特に、複数ノードにまたがる分散デプロイや、大規模なベクトル検索が必要なケースでは、SQLite の単一ファイル構成がボトルネックになります。また、マルチモーダルメモリの検索は「テキスト、画像、ツール痕跡、ペルソナをまとめて取得」とありますが、ローカルプラグインが画像データをどのように扱うかは README からは明確ではありません。画像の埋め込み生成に外部モデルが必要なら、完全ローカルの前提が崩れる可能性があります。この点は、実際に試す前にドキュメントで確認すべきです。
スキル再利用とフィードバック補正の仕組み
MemOS の特徴の一つは「クロスタスクのスキル再利用」です。メモリは L1 トレース、L2 ポリシー、L3 ワールドモデル、結晶化されたスキルという階層で管理されます。これは、エージェントが過去のタスクから得た手順や知識を、将来のタスクに適用するための仕組みです。さらに、自然言語によるフィードバックで記憶を補正・置換できる「Memory Feedback & Correction」機能があります。ユーザーが「この記憶は間違い」と指示すれば、該当メモリを修正できるという設計です。この機能は、誤った記憶が蓄積されるのを防ぐ上で重要ですが、フィードバックの粒度や反映速度は実装依存です。README には具体的な API 例がありません。導入時には、このフィードバック経路が自分たちのエージェントループに組み込めるかを確認する必要があります。
メンテナンスとライセンスの実務的考察
ライセンスは Apache-2.0 です。商用利用や改変は自由ですが、特許条項や表示義務があるため、法的確認は各自で行ってください。メンテナンス面では、リポジトリの最終プッシュが 2026-08-28 であり、v2.0.32 がリリースされています。また、ローカルプラグインも v2.0.18-beta.1 まで更新されており、活発に開発が続いていると見てよいでしょう。ただし、TypeScript 製であることから、Node.js 環境が必須です。セルフホスト構成では Neo4j と Qdrant の運用コストが加わります。特に Neo4j はグラフデータベースであり、バックアップやスケーリングの運用ノウハウが必要です。クラウド API を使えばインフラ管理は不要ですが、データが MemOS Cloud に保存されるため、データ主権やコンプライアンス上の制約がないか事前に確認してください。
編集部の結論
MemOS は、OpenClaw や Hermes エージェントに永続メモリを組み込みたい開発者、あるいは自前インフラでメモリ基盤を構築したいチームにとって有力な選択肢です。特にローカルプラグインは SQLite と FTS5 による完全オンデバイス動作を謳っており、データ外部送信が許されない用途に適合します。一方、マルチモーダルや大規模ナレッジベース運用を検討する場合は、ホスト型 API の利用が現実的ですが、データが MemOS Cloud に保存される点を事前に確認してください。導入前に、対象エージェントのプラグイン互換性（OpenClaw か Hermes か DeepSeek Harness か）と、ベンチマークが自社タスクと一致するかを検証することを推奨します。スキル進化の粒度やフィードバック補正の挙動は実機で試すしかありません。
コミュニティノート