Memanto Paper Summary

2026-05-19

2026-06-23

これは何の論文か

Memanto の問題意識は、長期エージェントの記憶アーキテクチャが複雑になりすぎているのではないか、というところにある。エージェントが複数セッションをまたいで動くには記憶が必要だが、保存のたびにLLMで実体抽出を行い、グラフを更新し、検索時にも複数の問い合わせを走らせる構成は、遅延、費用、保守負荷を積み上げる。

著者らはこの追加負荷を記憶 Tax と呼ぶ。Mem0、Zep、A-MEM、Hindsight のような記憶システムはそれぞれ有効な工夫を持つ一方、本番運用では、取り込み遅延、グラフ同期、複数回検索、スキーマ管理が重くなる。Memantoは、その前提に対して、複雑な知識グラフが本当に必要なのかと問い直す。

提案の中心は、13種類の記憶型、矛盾解決、時間つき履歴、そして Moorcheh の情報理論的検索である。記憶を型で分け、必要なら決定、指示、状況、学び、エラーのような種類で絞り、古い情報と新しい情報がぶつかる場合は置き換えや併存を扱う。検索は単一クエリで広めに取り出し、強いLLMに読ませる。

評価では LongMemEvalで 89.8%、LoCoMoで 87.1% を達成する。特に重要なのは、検索件数を10から40へ増やすだけで LongMemEval が大きく伸びた点である。長期記憶では、余計な情報を少し渡す害より、必要な断片を取り逃がす害の方が大きい、という設計思想が見えてくる。

ただし、論文の主張は Moorcheh の検索エンジンに強く依存している。また、評価は会話記憶中心で、最終段階では推論モデル変更の影響もある。読むときは、Memanto を万能な解というより、記憶システムを単純に保つための強い設計仮説として見るのがよい。

Memantoは、長期エージェントのための汎用記憶層を提案する論文である。正式な主張は、知識グラフや多段検索に頼らなくても、型つき意味記憶と高再現率の検索を組み合わせれば高品質なエージェント記憶を作れる、というもの。

システムとしては、エージェント、CLI、IDE、Web ダッシュボードなどから呼ばれる記憶ゲートウェイとして設計される。入口は remember、再現率、answer のように分かれ、保存、検索、回答生成の流れを担う。

Memantoは、記憶を単なる会話ログではなく、型、時間、優先度、矛盾状態を持つ意味記憶として扱う。ここが、ただのベクトル検索との違いである。

何が問題だったのか

既存の長期記憶システムは、記憶を高品質に扱うために複雑になりやすい。保存時に LLM で実体抽出を行い、グラフを更新し、検索時にも複数段の問い合わせを走らせる。こうした構成は強力だが、遅延、費用、デバッグ負荷、保守負荷を増やす。

一方で、単純に会話ログを保存して近いものを検索するだけでは、記憶として弱い。事実、好み、約束、指示、過去の出来事を同じ粒度で扱うと、今も有効な情報と古くなった情報が混ざる。矛盾や時間の変化も扱いにくい。

Memanto が扱う問題は、「記憶を持つかどうか」ではなく、役に立つ長期記憶をどれだけ軽い仕組みで実現できるかである。記憶の型、矛盾、時間、検索の再現率を整えれば、重いグラフ構築や多段検索に頼りすぎなくても戦えるのではないか、という問いである。

提案手法の中身

記憶を書き込む時は、内容を型つきの意味記憶として保存する。記憶型により、後から『決定だけ』『指示だけ』『今の状況だけ』のように絞り込める。

13種類の型は、事実、好み、判断、約束、目標、出来事、指示、関係、文脈、学び、観察、エラー、成果物である。論文上は、認知科学の記憶分類と ENGRAM の型分離の知見を踏まえた事前定義スキーマとして提示されており、データから自動発見した13分類ではない。

新しい記憶が既存記憶と意味的にぶつかる場合は、矛盾として扱う。古い記憶を置き換える、古い記憶を残す、両方を矛盾つきで保持する、といった選択肢を持つ。

検索には Moorcheh の情報理論的検索を使う。通常の近似最近傍索引に強く依存するのではなく、クエリの不確実性をどれだけ減らすかという観点で、関連する記憶を取り出すと説明されている。

Moorchehは、論文中では MIB、EDM、ITS の3要素で説明される。MIB は埋め込みを情報を保ったまま二値表現へ圧縮し、EDMは cosine 類似度ではなく不確実性低減を基準に距離を見る。ITS は検索結果の価値を 0から 1 のスコアとして出し、しきい値ベースの決定的検索を可能にする。

検索方針は再現率寄りである。狭く高精度に取るより、少しノイズが混じっても広めに取り出し、LLM が必要な情報を読む設計にする。

通常のベクトル検索で足りないとされる点は、近い文が必ずしも必要な記憶ではないこと、index 更新の遅延が write-読み取りループと噛み合わないこと、近似検索の揺れがエージェントの再現性とデバッグを難しくすることである。

回答時は、取り出した記憶を根拠としてモデルに読ませる。関係グラフを事前に作り込むより、型、時間、矛盾、広めの検索を整えたうえで、推論モデルに整理させる立場である。

どうやって確かめたのか

評価では、LongMemEval と LoCoMo を使い、長期記憶が質問に必要な情報を取り出せるかを見る。単一の最終構成だけでなく、構成を段階的に変えて、どの設計が効いたかを切り分ける。

比較対象は、初期の単純な検索設定、検索件数やしきい値を変えた設定、Hindsight 由来のプロンプトを入れた設定、さらに取得件数を増やした設定である。

測る指標は、各ベンチマークでの正解率、検索件数を増やした時の伸び、余計な記憶を渡す害と必要な記憶を取り逃がす害のどちらが大きいかである。

結果はどうだったのか

段階的改善

最初の単純な設定では LongMemEval 56.6%、LoCoMo 76.2%。検索件数を10から40へ増やし、しきい値を緩めると LongMemEval 77.0%、LoCoMo 82.8% へ伸びる。この段階が最大の改善である。

プロンプトと検索上限

Hindsight 由来のプロンプトに変えると LongMemEval 79.2%、LoCoMo 82.9%。さらに最大100件まで広げると LongMemEval 85.0%、LoCoMo 86.3% になる。

最終結果

推論モデルを Gemini 3 に変えた最終設定では LongMemEval 89.8%、LoCoMo 87.1% を達成する。著者らは、ベクトル中心システムとして最先端水準だと位置づける。

複雑さとの比較

Hindsightは LongMemEval 91.4%、LoCoMo 89.6% とさらに高いが、複数回検索と反省処理を使う。Memanto は少し低いが、単一検索で、保存時のLLM呼び出しなし、低い複雑さを売りにする。

運用コスト

論文では、1日に1万回の記憶操作を行う想定で、Memanto の日次コストを $0.50、Mem0-Graphを $2.32、Zepを $1.70 と見積もる。数字自体より、設計の複雑さが継続コストになるという見方が重要である。

限界・注意点

Moorcheh 依存が強い。Memanto の設計が強いのか、Moorcheh の情報理論的検索が強いのかは、この論文だけでは切り分けにくい。
Moorchehは APIや SDK として使うだけなら比較的試しやすいが、Moorcheh 相当の検索エンジンを自前実装するのは別問題である。MIB、情報理論的距離、決定的スコアリング、no-index 検索を再現するには、研究・インフラ寄りの実装が必要になる。
評価は LongMemEvalと LoCoMo が中心で、どちらも会話記憶に寄っている。研究エージェント、コード生成エージェント、複数エージェント協調などでは追加検証が必要である。
最終段階で推論モデルを Gemini 3 に変更しているため、記憶アーキテクチャの改善とモデルの読解力の改善が混ざる。切り分け実験では寄与が示されているが、慎重に読む必要がある。
13種類の記憶型は汎用的だが、個人 wiki、投資判断、論文ウォッチ、作業ログのような運用には、そのままでは粗い可能性がある。論文の Appendix では、現状の型割り当ては書き込み時にユーザーが選び、自動分類は将来のルールベース判断 tree とされている。

おい丸のようなエージェントにどう使えるか

おい丸のような作業支援エージェントでは、記憶は「たくさん保存すればよい」ものではない。事実、好み、決定、約束、目標、出来事、指示、関係、状況、学び、観察、エラー、成果物参照のように型を分けることで、後から使う時の判断がしやすくなる。

この論文を使うなら、記憶を保存箱ではなく、検索、鮮度、信頼境界、更新、削除まで含む状態管理として設計する。どの記憶をいつ使うか、古い記憶をどう扱うか、検索結果をそのまま文脈に入れてよいかを分けて考える。

注意点もある。つまり、個人向けエージェントに持ち込む時は、記憶の量よりも、使える条件、使ってはいけない条件、検証できる形を一緒に持たせることが重要になる。

Q&A

この論文の中心問いは？

高品質なエージェント記憶を作るために、知識グラフや多段検索のような複雑な構成は本当に必要なのか、という問いである。

Memanto は何を提案している？

13種類の型つき意味記憶、矛盾解決、時間履歴、情報理論的検索を組み合わせた、長期エージェント向けの記憶層である。

記憶 Tax とは？

記憶の取り込みや検索のために、LLM 実体抽出、グラフ更新、索引作成、複数回検索などが積み上がり、遅延、費用、保守負荷が増えること。

13種類の記憶型はなぜ重要？

記憶をただのテキストとして保存するのではなく、決定、指示、状況、学び、エラーのように分けることで、検索時の絞り込みや優先度づけ、矛盾解決がしやすくなる。

13種類の型は具体的に何？

事実、好み、判断、約束、目標、出来事、指示、関係、文脈、学び、観察、エラー、成果物の13種類である。決定事項、利用者の好み、失敗回避、文書やコード参照を分ける。

13という数はどう決めた？

論文では、認知科学の記憶分類と ENGRAM の型分離の知見に基づく事前定義スキーマとして説明されている。データから自動発見した分類ではなく、現状の型割り当ても書き込み時にユーザーが選ぶ設計である。

Moorcheh はどんな手法？

論文中では、埋め込みを二値圧縮する MIB、cosine 類似度ではなく不確実性低減を見る EDM、検索結果の価値を 0から 1 で出す ITS を組み合わせた情報理論的検索として説明されている。

なぜ Moorcheh を選んだ？

保存してすぐ検索できること、近似最近傍ではなく決定的な意味検索を狙えること、クエリに効く情報量で関連度を見られること、検索と取り込みの運用コストを下げられることを重視したためである。

通常のベクトル検索では何が足りない？

長期記憶では、埋め込み空間で近い文が必要な記憶とは限らない。さらに index 更新遅延、近似検索の揺れ、top-k で重要断片を取り逃がす問題が、エージェントの write-読み取りループやデバッグを難しくする。

Moorcheh は簡単に組める？

APIや SDK として使うだけなら比較的試しやすい。一方で、MIB、情報理論的距離、決定的スコアリング、no-index 検索を備えた Moorcheh 相当の検索エンジンを自作するのはかなり重い。

一番効いた改善は？

検索件数を10から40へ増やし、検索を広めにしたこと。LongMemEval ではこの変更が最大の改善を生んでいる。

なぜ広めの検索が効く？

長期記憶では、余計な情報が少し混じる害より、必要な記憶を取り逃がす害の方が大きいから。強いLLMは、広めに渡された候補から必要な断片を選べる可能性がある。

グラフはいらないと言っている？

少なくとも LongMemEvalや LoCoMo のような会話記憶評価では、グラフの追加負荷に見合う改善が見えにくい、という主張に近い。すべての領域でグラフが不要だと証明したわけではない。

怪しい点は？

Moorcheh への依存が強いこと、評価が会話記憶中心であること、最終結果に推論モデル変更の影響が混ざることである。

個人アシスタント運用に持ち込むなら？

まず記憶型を作る。次に、古い好みや状態と新しい情報がぶつかった時に、黙って上書きせず衝突として扱う。さらに検索件数を絞りすぎていないかを評価する。

一言でいうと？

記憶は、複雑なグラフを足す前に、型、時間、矛盾、再現率をちゃんと設計するだけでかなり強くなるかもしれない。