YourMemoryは生物学的減衰でAIメモリの古い文脈を捨てる
目次
sachitrafa/YourMemory は、AIエージェント向けの永続メモリをMCPサーバとして差し込む実装だ。
Hacker News候補のタイトルでは「52% recall」となっていたが、2026-04-27に原典READMEと BENCHMARKS.md を見ると、LoCoMo-10のRecall@5は59%に更新されていた。
Product Hunt側には52%表記が残っているので、短期間でベンチマーク値か実装が更新されたようだ。
面白いのは「覚える」ことより「忘れる」ことを前面に出している点だ。
エージェント用メモリは、長く使うほど過去の修正、古い前提、もう使っていない回避策が溜まる。
それを毎回コンテキストに戻すと、トークンを食うだけでなく、モデルが古い正しさに引っ張られる。
以前 CLAUDE.mdのトークン管理 で、知識をCLAUDE.md、スキル、別ファイル、MCPに分けて扱う話を書いた。
YourMemoryはその中でも「毎回読む文書」ではなく、「必要な記憶だけ呼び戻すMCP」に寄せた実装になる。
59%に更新されたLoCoMo-10
ベンチマークはSnap ResearchのLoCoMoから10会話を使う。
複数セッションにまたがる会話の session_summary を各システムに同じ順序で入れ、1,534個のQAペアに対してRecall@5を測る。
上位5件の検索結果に正答が含まれるか、というかなり検索寄りの指標だ。
YourMemoryの BENCHMARKS.md では、BM25 + vector + graph + Ebbinghaus decayの構成で59%、Zep Cloudが28%、Supermemoryが31%、Mem0が18%とされている。
ただしSupermemoryとMem0は無料枠の制限で全サンプルを完走していない。
未完了分を0 hitとして数えているため、比較の読み方には少し注意が要る。
それでも、YourMemoryとZep Cloudは10サンプルを完走しており、同じ条件で59%対28%。
この差は「メモリをLLMで要約して事実だけ抜く」より、「セッション要約を保持したうえで検索と減衰で選ぶ」ほうがLoCoMoの細かい名前・日付・出来事に強かった、という読み方ができる。
忘却曲線を検索スコアに混ぜる
YourMemoryの検索は、単純なベクトル検索ではない。
README上の説明では、まずベクトル検索で近いメモリを取り、そのシードからグラフをBFSで広げる。
実装側ではBM25も混ぜていて、src/services/retrieve.py ではBM25を0.4、ベクトル類似度と記憶強度の積を0.6としてハイブリッドスコアを作っている。
記憶強度は src/services/decay.py にあり、Ebbinghaus忘却曲線風の指数減衰を使う。
カテゴリごとに減衰率が違い、failure は約11日、assumption は約19日、fact は約24日、strategy は約38日が目安になっている。
同じ記憶でも重要度が高いほど減衰が遅く、呼び戻される回数が多いほど強度が上がる。
flowchart TD
A[ユーザーのタスク] --> B[recall_memory]
B --> C[BM25検索]
B --> D[ベクトル検索]
D --> E[記憶強度を掛ける]
E --> F[グラフ展開]
C --> G[ランキング統合]
F --> G
G --> H[上位メモリだけ<br/>コンテキストへ戻す]
H --> I[store_memory / update_memory]
この設計で狙っているのは、長期記憶をただのログ置き場にしないことだ。
RAG的に何でも検索できるようにすると、短命だったはずの「昨日だけ必要だった回避策」もいつまでも候補に残る。
YourMemoryは、使われない記憶を自然に弱らせ、強度が0.05未満になったものを検索対象から外す。
MCPツールは3つだけ
MCPサーバとして公開されるツールは recall_memory、store_memory、update_memory の3つ。
Claude Code、Claude Desktop、Cline、Cursor、OpenCodeなど、標準的なstdio MCPクライアントから使える。
READMEの導入手順はかなり軽い。
pip install yourmemory、yourmemory-setup、yourmemory-path のあと、クライアントのMCP設定に yourmemory を登録する。
ローカルDBはデフォルトで ~/.yourmemory/memories.duckdb。
依存にはDuckDB、sentence-transformers、spaCy、NetworkX、APSchedulerが入っている。
PostgreSQL + pgvector、Neo4jはオプションだ。
sample_CLAUDE.md では、タスク開始時に recall_memory、新しい知識を得たら store_memory、古い記憶と矛盾したら update_memory という運用が書かれている。
ここは planning-with-files のようにファイルへ進捗を書き出す方法とは役割が違う。
ファイル方式は計画・調査・進捗の正本を残すのに向く。
YourMemoryは「このユーザーはこういう設定を好む」「この環境ではこの失敗があった」のような、次のセッションで暗黙に効いてほしい断片に向く。
RAGの代替ではなく作業メモリ
YourMemoryをRAG一般の置き換えとして見ると少しズレる。
社内マニュアルやAPIドキュメントを大量に入れるなら、MintlifyがRAGから仮想ファイルシステムへ寄せた話 のように、ドキュメント構造や正確な cat / grep のほうが大事になることがある。
一方、YourMemoryが扱うのはエージェント作業中に発生するユーザー固有・プロジェクト固有の記憶だ。
Cloudflare Agent Memory と比べると、方向性の違いが分かりやすい。
CloudflareはDurable Objects、Vectorize、Workers AIを使うマネージドな記憶層として、Facts、Events、Instructions、Tasksを分類して扱う。
YourMemoryはローカルMCPとして、カテゴリを fact、assumption、failure、strategy に絞り、忘却曲線とグラフで取り出し順を調整する。
マネージドなチーム共有メモリが欲しいならCloudflare型が合う。
手元のClaude CodeやCursorに「前に言った好みや罠を覚えておいてほしい」なら、YourMemoryのほうが軽い。
ただしライセンスはCC BY-NC 4.0なので、商用利用は別途確認が必要だ。
古い正しさをどう殺すか
この手のメモリで怖いのは、忘れすぎではなく、忘れてはいけないものを弱らせることだ。
たとえば半年に一度しか触らないが、破ると壊れるアーキテクチャ決定がある。
単純な時間減衰だけなら、その記憶は静かに消える。
YourMemoryはそこをグラフで少し守ろうとしている。
保存時に類似メモリへエッジを張り、検索で強く呼ばれたメモリの近隣もブーストする。
READMEにも、チェーン上の近隣が強ければ、減衰したメモリを即座に刈らないという説明がある。
それでも、運用側で確認する場所は残る。
failure は短く消えるので、古い環境依存エラーを残しにくい。
逆に、設計方針や禁止事項は strategy や高い importance で保存しないと薄くなる。
さらに、変更で古い前提が明確に壊れた場合は、自然減衰を待たずに update_memory で置き換えるほうがいい。
メモリを増やすこと自体は簡単になってきた。
次に差が出るのは、どの記憶をいつ殺すかだと思う。
YourMemoryはそこに「忘却」を入れた小さなローカル実装として、試す価値がある。
これ、ブログでも同じことが言える。
過去記事を内部リンクで引っ張るとき、「まだ有用か」のラインを見極めないと、古い前提をいつまでも流通させることになる。
ベンチマークの数値みたいに数ヶ月で変わるデータを含む記事なら、なおさら鮮度の減衰は避けられない。
いい感じに過去を棚卸しし続けるのは、AIメモリでもブログでも同じ課題だ。
そしてこれ、自分で作っているかなチャットでもろに体感している。
今のHeartbeatメモリは today が日付別14日分、task_signals が80件上限、profile が40件上限で、全部機械的な数値カットオフだ。
14日経ったら消える、上限超えたら古い順に押し出される。
これはこれでシンプルだが、減衰ではなくただの切り捨てなので、13日前の情報と昨日の情報が同じ重みでコンテキストに入る。
実際に困るのは task_signals の方だ。
2週間前に「OGP画像の自動生成を調べたい」と呟いたのが、もう興味を失った後もずっと提案候補に残り続ける。
ジョブ提案のたびに「これもう要らないんだけど」と思いながらスルーする体験が地味にストレスになる。
profile も同じで、「セキュリティ記事に詳しい」は今も当てはまるが、「最近Rustに興味ある」みたいなのは1ヶ月で賞味期限が切れている可能性がある。
YourMemoryのカテゴリ別減衰率をそのまま持ってくるのはやりすぎだが、考え方は使える。
task_signals は failure に近い短命カテゴリとして扱い、作成から1週間くらいで急速に減衰させる。
profile は strategy 寄りの長命カテゴリとして、数ヶ月は残すが、参照されなければ徐々に弱くする。
today は現状のまま日付で切っていい。
日記データはそもそも日付がアイデンティティなので、減衰より削除のほうが意味論として正しい。
もう一つ欲しいのは、呼び戻し頻度による強化だ。
YourMemoryの recall_count のように、ジョブのコンテキスト構築で実際に使われたメモリの強度を上げれば、「繰り返し役立つ知識」と「一度言っただけの思いつき」を自然に分離できる。
今のHeartbeatにはその仕組みがないので、80件の中を使用頻度で並べ替えるだけでも提案の質は変わりそうだ。