LightMem を採用する前に読む: 記憶レイヤの構成と実験スクリプトの実際
[ICLR 2026] LightMem: Lightweight and Efficient Memory-Augmented Generation
ひと目でわかる
- これは何？
- LightMem は LLM エージェントに長期記憶を持たせるための軽量フレームワークで、記憶の保存・検索・更新を一つの層として切り出す。本稿はリポジトリの記述から、その構成、動かし方、そして向かない場面を整理する。
- 誰に向いている？
- 導入を検討すべきなのは、既存のエージェントに記憶層だけを後付けしたい開発者と、LoCoMo や LongMemEval 上で記憶方式を比較したい研究者である。逆に、記憶のスキーマを厳密に固定したい用途や、リリース済みバージョンの固定を前提に運用したいチームには向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 11 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
LightMem が埋めるのは会話履歴とプロンプトの間の隙間
LLM アプリケーションで長期記憶を扱おうとすると、多くの場合、会話ログをどこかに保存し、毎ターン関連部分を検索してプロンプトに詰め直すという処理を自前で書くことになる。保存形式、検索の単位、古い記憶の更新規則、そしてどのモデルに要約させるか。これらは互いに独立しておらず、片方を変えるともう片方の前提が崩れる。LightMem はこの部分を一つのフレームワークとしてまとめ、アプリケーション側からは記憶の保存・検索・更新という三つの操作だけを見せる。README は対象を Large Language Models と AI Agents とし、長期記憶を持つ知的アプリケーションを短期間で作るための土台だと位置づけている。想定読者は、チャットボットやパーソナライズされたエージェントを書いていて、記憶部分の設計に毎回時間を取られている開発者である。研究用途も明示されていて、LoCoMo と LongMemEval という二つのデータセットでの再現スクリプトが experiments ディレクトリに置かれている。
記憶マネージャを抽象化し、モデル提供元を差し替え可能にする層構造
リポジトリの構成から読み取れる設計の中心は、記憶マネージャを抽象化し、その背後にある推論バックエンドを交換可能にしている点にある。README のニュース欄によれば、クラウド API として OpenAI と DeepSeek、ローカル実行として Ollama、vLLM、Transformers に対応し、それぞれ src/lightmem/factory/memory_manager/ 配下に ollama.py、vllm_offline.py、transformers.py といったファイルが用意されている。つまり記憶のロジックそのものと、要約や埋め込みを計算するモデルの呼び出しが分離されており、開発中はローカルの Ollama で回し、本番ではクラウド API に切り替えるといった運用が想定されている。設定は src/lightmem/configs/memory_manager/base_config.py に集約されている。2026-04-24 の更新では DeepSeek の deepseek-v4-flash と deepseek-v4-pro に対応し、reasoning_effort と thinking モードの設定が加わったと記載されている。推論にどれだけ計算を割くかを記憶層の設定として持てるのは、コストと遅延の調整という意味で実用的な判断である。アーキテクチャ図が figs/architecture.jpg として置かれているが、図そのものの内容は本稿では確認できていない。
experiments 配下の再現スクリプトが示す評価の流れ
このリポジトリはライブラリであると同時に、ベンチマークの再現キットでもある。README の表には LongMemEval と LoCoMo の二つのデータセットについて、それぞれ experiments/longmemeval/readme.md と experiments/locomo/readme.md へのリンクが示され、結果へのリンクも同じ行に並んでいる。LongMemEval の説明には、評価だけでなく offline memory update が含まれると書かれている。これは、会話を流し込んで記憶を構築する段階と、その記憶を使って質問に答える段階が別の処理として用意されていることを意味する。記憶層の評価は、検索精度だけでなく、いつ記憶を書き込み、いつ更新するかという時間軸の設計に結果が左右される。オフライン更新の手順が独立したスクリプトとして提供されているのは、この時間軸を再現可能な形で固定しようという意図だと読める。2026-03-21 と 2026-01-17 の告知では、Mem0、A-MEM、EverMemOS、LangMem といった他の記憶層を同じデータセット上で比較するためのベースライン評価フレームワークが別リポジトリ zjunlp/MemBase として提供されている。比較の土台が本体と分離されている点は、評価の再現性という観点で素直な構成である。
セットアップで最初に触るファイルと実行の入り口
導入手順の全体像は README からは完全には復元できない。パッケージ名やインストールコマンドの記載は本稿で参照した範囲には見当たらず、Python パッケージとして公開されているのか、リポジトリを直接クローンして使うのかは確認できない。したがって、依存関係の解決方法について断定的なことは書けない。一方で、設定と実行の接点は具体的に示されている。記憶マネージャの既定値は src/lightmem/configs/memory_manager/base_config.py にあり、モデル提供元を切り替える場合はここを起点にする。ローカル実行のアダプタは src/lightmem/factory/memory_manager/ 配下の ollama.py、vllm_offline.py、transformers.py で、クラウド側は OpenAI と DeepSeek が README で言及されている。評価を回す場合は experiments/locomo/readme.md と experiments/longmemeval/readme.md の手順に従う。加えて 2025-11-30 の告知で MCP Server が mcp/server.py として提供されていると書かれており、エージェントからツール経由で記憶を呼び出す経路も用意されている。どの経路を選ぶにせよ、最初に開くのは base_config.py である。
バージョン番号を持たない配布形態という制約
このリポジトリにはリリースが一つも登録されていない。取得できた範囲ではタグ付きのバージョンもパッケージレジストリ上の公開も確認できず、更新は main ブランチへのコミットとして積み上がっている。これは記憶層を本番に組み込むチームにとって無視できない制約になる。記憶の保存形式や検索のスコアリングは、アプリケーションの応答品質に直結する。その部分が固定されたバージョンとして配布されていないなら、依存を固定するには特定のコミットハッシュを自前で記録し、更新は差分を読んでから取り込む運用になる。README のニュース欄を見る限り、更新の頻度は低くない。2025年10月の公開以降、モデル対応、MCP サーバ、デモ、評価フレームワーク、別系統の記憶方式と、ほぼ毎月のように項目が並ぶ。活発であることは事実だが、それは同時に、追従を怠ると設定キーやモジュール構成が変わりうるということでもある。MIT ライセンスである点は導入の障壁を下げるが、ライセンス表示の保持といった条件の解釈は利用形態によって変わるため、法務判断は各自で行う必要がある。
一つのリポジトリに複数の記憶方式が同居している
プロジェクトナビゲーションの表には、LightMem のほかに FluxMem、EM²Mem、StructMem の三つが並んでいる。FluxMem は記憶を異種グラフとして扱い、その接続が変化していく方式だと説明されている。StructMem はイベント単位の結び付きとイベント間の接続を保持する階層型の記憶で、ACL 2026 に採録されたと告知されている。EM²Mem は長時間の動画に対する質問応答を対象にしたイベント中心のマルチモーダル記憶で、こちらは EMNLP 2026 の採録告知が出ている。つまりこのリポジトリは単一のライブラリではなく、同じ研究グループによる複数の記憶方式のホストになっている。採用を検討する側から見ると、これは両刃である。記憶の設計を差し替えたいときに同じリポジトリ内で比較できる利点がある一方、README の記述がどの方式を指しているのかを常に意識しないと、設定ファイルの場所や前提を取り違える。実際、設定ディレクトリのパスは src/lightmem/ 配下にあり、方式ごとのドキュメントは StructMem.md、FluxMem.md、EM2Mem.md という別ファイルに分かれている。
Mem0 や LangMem と何が違うのか
比較対象として README 自身が名前を挙げているのは Mem0、A-MEM、EverMemOS、LangMem である。これらは zjunlp/MemBase のベースライン評価フレームワークで、LoCoMo や LongMemEval 上で LightMem と並べて測定される対象として提示されている。違いは設計思想の層にある。Mem0 や LangMem は記憶の抽出と検索をマネージドなサービスやライブラリの API として提供する方向に寄っており、利用者は保存形式の内部に立ち入らない。LightMem はむしろ、記憶マネージャを抽象クラスとして公開し、factory 配下のアダプタを差し替えることでバックエンドを選ばせる。ローカルの vLLM や Ollama で完結させたい場合、この差は大きい。外部サービスに会話データを送らずに記憶層を運用できるかどうかは、導入の可否を決める要因になりうる。ただし、抽象化されているということは、記憶のスキーマをアプリケーション側で厳密に固定したい場合には制御点が少ないということでもある。表形式のデータベースに記憶を正規化して格納し、SQL で検索したいという要求には、この構造は合わない。
採用の判断と、着手前に確かめるべきこと
向いているのは、既存のエージェントに記憶層だけを後付けしたい開発者、そして記憶方式の比較を研究として行いたい人である。モデル提供元を設定一つで切り替えられる構成は、開発中はローカル、評価はクラウドという進め方を素直に支える。逆に向かないのは、記憶のスキーマを厳密に定義して運用したい用途と、固定バージョンの依存を前提にしたリリース運用である。前者には抽象化の粒度が粗く、後者にはタグ付きリリースが存在しない。着手前に確認すべきことは三つある。第一に、src/lightmem/configs/memory_manager/base_config.py の既定プロバイダが自分の環境で動くか。第二に、experiments/locomo/readme.md と experiments/longmemeval/readme.md の手順が手元のモデル構成で再現できるか。第三に、プロジェクトナビゲーションの表で LightMem 以外の方式が並んでいる以上、自分の用途がどの方式の説明を読むべきなのかを先に決めておくこと。記憶層はアプリケーションの応答を左右する部分であり、README のニュース欄が示す更新頻度を踏まえると、導入時点のコミットを記録しておくことが事実上のバージョン管理になる。
編集部の結論
導入を検討すべきなのは、既存のエージェントに記憶層だけを後付けしたい開発者と、LoCoMo や LongMemEval 上で記憶方式を比較したい研究者である。逆に、記憶のスキーマを厳密に固定したい用途や、リリース済みバージョンの固定を前提に運用したいチームには向かない。着手前に確認すべきは、src/lightmem/configs/memory_manager/base_config.py の既定プロバイダと、experiments/locomo/readme.md の再現手順が手元のモデル構成で動くかどうかである。
コミュニティノート