MemoriLabs/Memori: エージェントの実行ログを記憶に変える層をどう評価するか
Memori is agent-native memory infrastructure. A LLM-agnostic layer that turns agent execution and conversation into structured, persistent state for production systems. Built for enterprise, Memori works with the data infrastructure you already run, no rip-and-replace, and deploys across managed cloud, single-tenant cloud, VPC, and on-premises.
ひと目でわかる
- これは何？
- Memoriは、LLMやデータストアを問わずエージェントの会話と実行を構造化して永続化するPython/TypeScript向けのメモリ層である。READMEの主張とベンチマーク記述を読み、導入判断に必要な仕組み、制約、代替手段を整理する。
- 誰に向いている？
- 既存のOpenAI互換クライアントとデータベースを維持したままエージェントに長期記憶を持たせたいチーム、特にOpenClawやHermesをすでに運用しているチームには検討の価値がある。一方、記憶の抽出ロジックを自前で監査したい場合や、外部サービスへのデータ送信を避けたい場合は、SDKが既定でMemori CloudのAPIキーを要求する点が障害になる。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 12 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Memoriが埋めようとしている穴は「発話」ではなく「実行」の記録
多くのメモリ実装は会話テキストを対象にする。MemoriのREADMEは冒頭で「Memory from what agents do, not just what they say」と掲げ、会話だけでなくエージェントの実行そのものを記憶の対象に据えている。OpenClaw向けプラグインの説明では、各ターン後にツール呼び出し、意思決定、結果を含む構造化メモリを自動で取り込むとされている。対象読者は、セッションをまたぐと文脈を失うエージェントを本番運用している開発者だ。会話履歴をそのままプロンプトに詰め戻す方式では、ターンが増えるほどコストとノイズが膨らむ。Memoriはそこを構造化された永続状態に置き換えることを狙っている。
登録は既存クライアントのラップ、記憶の書き込みはバックグラウンド
Python SDKの例では、OpenAIクライアントを生成し、Memori().llm.register(client)でラップし、attribution(entity_id="user_123", process_id="support_agent")で記憶の帰属先を指定する。以降は通常のchat.completions.createを呼ぶだけで、READMEのコメントによれば会話は自動的に永続化され、次の呼び出しで想起される。TypeScript SDKも同じ形で、new Memori().llm.register(client).attribution('user_123', 'support_agent')とチェーンする。ここで重要なのは、記憶の抽出と保存が呼び出しの応答を待たせる形ではなくバックグラウンドで行われると記述されている点だ。アプリケーションコードの変更はクライアントのラップと帰属指定に限定され、プロンプトの書き換えは不要とされている。entity_idはエンドユーザー、process_idはエージェントや用途の単位という役割分担で、記憶のスコープをこの2軸で切る設計だと読み取れる。
LLM非依存とデータストア非依存は、BYODBの記述で初めて具体化する
READMEはLLM、データストア、フレームワークに依存しないと繰り返し述べるが、抽象的な主張だけでは導入判断ができない。具体が出てくるのはBYODBの節で、独自データベースを使いたい場合のドキュメントとしてmemorilabs.ai/docs/memori-byodb/が案内され、使い捨ての開発用データベース向けにTiDB Zeroのプロビジョニング手順がdocs/memori-byodb/databases/tidb.mdxに置かれている。つまり「既存のデータ基盤をそのまま使う」という売り文句は、少なくともTiDBを対象とした手順としてリポジトリ内に実体を持っている。ただし提供された資料からは、TiDB以外にどのデータストアが同梱の手順で扱えるのかは分からない。BYODBを前提に選定するなら、自分のデータストアに対応する手順がdocs配下に存在するかを先に確認する必要がある。
導入コマンドはSDKとプラグインで経路が分かれる
Pythonはpip install memori、TypeScriptはnpm install @memorilabs/memoriで入る。動作にはMEMORI_API_KEYとLLM側のキー（例としてOPENAI_API_KEY）を環境変数に置く必要があり、READMEはapp.memorilabs.aiでサインアップしてAPIキーを取得する手順を示している。既存エージェントへの組み込みはフレームワーク側のプラグイン経由でも行える。OpenClawではopenclaw plugins install @memorilabs/openclaw-memori、openclaw plugins enable openclaw-memoriの後、openclaw memori initに--api-key、--entity-id、--project-idを渡し、openclaw gateway restartで反映する。Hermesではpip install hermes-memori、hermes-memori installを実行し、hermes config set memory.provider memoriでプロバイダを切り替え、$HERMES_HOME/.envにMEMORI_API_KEYとMEMORI_ENTITY_IDを追記する。MEMORI_PROJECT_IDは任意で、省略時はHermesのアクティブなプロジェクト文脈が使われると説明されている。
LoCoMoの数値は自社公開の測定であり、条件を確認してから信じる
READMEはLoCoMoベンチマークで全体精度87%、1クエリあたり平均721トークン、フルコンテキストの2.8%と主張する。比較対象としてZep、LangMem、Mem0を挙げ、Zep比でプロンプトサイズを約67%削減、フルコンテキスト比でコンテキストコストを36倍以上下げたとしている。ここで注意すべきは、これらがリポジトリ内のdocs/memori-cloud/benchmark/配下とarXiv論文として自社が公開した測定だという点だ。第三者の追試結果は提供資料には含まれていない。また87%という数値がMemori Cloud、BYODB、単一テナントのどの構成で得られたのかはREADMEからは判別できない。記憶の抽出にLLM呼び出しが介在する設計である以上、使用モデルと抽出設定が数値に影響するはずで、自環境で同じ精度が出る保証はない。ベンチマークを導入根拠にするなら、docs/memori-cloud/benchmark/results.mdxで条件を確認する作業が先に来る。
ライセンス表記の不一致は導入前に解消すべき論点
リポジトリのメタデータではライセンスがNOASSERTIONとなっている。一方、READMEのバッジはApache 2.0を指し、opensource.org/license/apache-2-0へのリンクが張られている。この2つは一致していない。GitHubがライセンスを認識できていないだけなのか、追加条件や別ライセンスが混在しているのかは、提供された資料からは判断できない。法的助言はできないが、社内の法務確認に回すなら、READMEのバッジではなくリポジトリ直下のLICENSEファイルの実物を読む必要がある。エンタープライズ向けを掲げるプロジェクトでこの不一致が残っているのは、導入検討の初期段階で確認コストを発生させる要因であり、看過できない。
向かないケースと、比較対象としての自前RAG
Memoriが適さないのは、記憶の抽出ロジックを自分で制御し監査したい場合だ。SDKの利用経路はMEMORI_API_KEYを前提としており、クイックスタートの構成では記憶の生成と保存がMemori側の処理に委ねられる。どの発話がどう構造化され、何が捨てられるかを自前で決めたいチームにとって、この抽象度は逆に障害になる。代替は、ベクトルストアと自前の抽出パイプラインを組み合わせたRAGだ。違いは明確で、RAGは検索対象を開発者が設計し、何を埋め込むかを自分で決める。Memoriはエージェントの実行から構造化状態を自動生成する側に倒しており、設計の自由度と引き換えに組み込みの手間を減らす。すでにRAG基盤を運用していて取り込み対象を細かく調整しているチームが、この自動化をそのまま受け入れられるかは別問題である。
更新頻度と、判断を保留すべき条件
提供されたリリース情報ではv3.3.4からv3.3.6までが2026年5月20日から5月28日の間に並んでおり、パッチ更新が短い間隔で続いている。最終pushは2026年9月3日でアーカイブはされておらず、保守は継続していると読める。ただしパッチ番号の刻みが速いことは、逆にAPIや設定キーの変更が入りやすいことを意味する。本番に組み込むなら、MEMORI_API_KEYやMEMORI_ENTITY_IDといった環境変数と、openclaw memori initの引数、hermes config set memory.providerの値が、どのバージョンから有効なのかをリリースノートで追う必要がある。判断を保留すべきなのは、ライセンスの不一致が解消されていない段階で社内の調達プロセスに載せる場合だ。まずLICENSEファイルを読み、次にBYODBのdocsで自分のデータストアが対象か確認し、そのうえでLoCoMoの測定条件をresults.mdxで突き合わせる。この3点が揃うまで、構成の確定は早い。
編集部の結論
既存のOpenAI互換クライアントとデータベースを維持したままエージェントに長期記憶を持たせたいチーム、特にOpenClawやHermesをすでに運用しているチームには検討の価値がある。一方、記憶の抽出ロジックを自前で監査したい場合や、外部サービスへのデータ送信を避けたい場合は、SDKが既定でMemori CloudのAPIキーを要求する点が障害になる。導入前に確認すべきは、リポジトリのライセンス表記がNOASSERTIONである一方READMEはApache 2.0を掲げている不一致の実態、BYODBでどのデータがローカルに留まるか、そしてLoCoMoの87%という数値がどの構成で測定されたかである。
コミュニティノート