要点（30秒で）: 並列関数型ランタイムHVMで知られるVictor Taelinが、AIエージェントに永続記憶を足す最小ツール「OptMem」を公開した。中身は426トークンのプロンプトと依存ゼロのPython1枚で、記憶は追記だけのログに積み、古いものは消さずに「畳んで」薄れさせる。重厚な記憶フレームワークを入れる前に、まずこの軽さを一度触ってみる価値がある。

この記事の内容（約8分で読めます）

1. 「試した記憶ソリューションが全部ダメだった」
2. append-onlyのログと、5つの動詞
3. 「眠るな、昼寝しろ」——忘れ方の設計
4. 100万件でも0.03秒、という地味な自慢
5. 重厚なフレームワーク勢との距離
6. 作者はなぜ、これを売らなかったのか
7. 日本・個人開発の視点
8. 要点まとめ
9. 出典・リンク

AIエージェントに「記憶」を持たせる、というテーマはこの1年ずっと業界の宿題だった。セッションをまたいで文脈を覚えてほしい。でも実装しようとすると、ベクトルDBだの知識グラフだの、急に大掛かりな話になる。

そこへ、少し毛色の違うものが出てきた。名前はOptMem。作者は関数型の世界では有名なVictor Taelinで、彼の一言がこのツールの全部を言い当てている。

「試した記憶ソリューションが全部ダメだった」

Taelinはローンチ時にこう書いた。「試した記憶ソリューションが全部ダメだったから、自分で作った」。どれも過剰に設計されているか、特定フレームワークに縛られているように見えた、と。

だから彼が作ったのは、フレームワークではない。プロンプトだ。インストーラを走らせると、AGENTS.mdやCLAUDE.mdに貼り付けるための426トークンのブロックが生成される。エージェント本体には手を入れない。設定ファイルに数行足すだけで記憶が生える。

本体は~/.optmem/memoに置かれるPython3の1ファイルで、外部依存はゼロ。この「軽さ」そのものが主張になっている。

OptMemの「畳む」仕組み——nap で古い記憶を二分木状の要約へ折り込み、新しいほど高解像度で残す（仕組み図）

append-onlyのログと、5つの動詞

使い方はコマンド5〜6個で終わる。セッションの最初に必ずmemo wakeで記憶を読み込み、何か学んだらmemo noteで書き込む。noteは1件280文字まで、という短さの制約がついている。

思い出したいときはmemo recallに正規表現を渡して全ログを検索する。データベースの実体はLOG.txtという追記専用のログで、書いた記憶は原則として消えない。ここが設計の芯だ。

補助として、要約ツリーを掘り下げるmemo zoom、要約を捨てて作り直させるmemo forgetもある。ツリーはログから再生成できるキャッシュにすぎない、という割り切りが効いている。

最小の動詞と追記ログ——wake/note/recall/nap/zoom が LOG.txt をどう読み書きするか（処理フロー・データの流れ）

「眠るな、昼寝しろ」——忘れ方の設計

面白いのは忘れ方だ。Taelinの言葉を借りれば「その場で圧縮する。眠るのではなく昼寝する（nap, don’t sleep）」。

普通の記憶システムは、溜まった履歴をどこかでバッサリ切り落とすか、要約で置き換える。OptMemは違う。memo napが走ると、古い記憶を二分木のように上位の要約へ畳み込んでいく。何も削除しないのに、文脈に載る量は一定サイズに保たれ、古い記憶ほど解像度が下がる。

人間の記憶とよく似ている。昨日の会話は細部まで覚えているが、三年前の出張は「行った」という粒度でしか残っていない。それでも必要ならzoomで畳んだ節を開き、任意の精度まで昔を掘り返せる。消しているのではなく、畳んでいるだけだからだ。

本格派との距離——OptMem／mem0／Letta の立ち位置比較（精度で競わず、軽さと透明さで刺さる）（比較表）

100万件でも0.03秒、という地味な自慢

派手さはないが、実装の丁寧さがうかがえる数字もある。記録は固定長で書かれ、1回のシークで引ける。リポジトリの説明によれば、記憶が100万件（約608MB）に膨らんでもwakeは0.03秒で返る。

読み込む量はWAKE_LINESで調整でき、既定は96行、およそ8kトークン。memo config WAKE_LINES=300のように増やせる。$MEMORY_DIRを差し替えれば、記憶の置き場所を同期フォルダやgitリポジトリに移すこともできる。チームで記憶を共有する、といった発展も想像できる作りだ。

サブエージェント向けの注意書きも徹底していて、プロンプトには「あなたはサブエージェントだ。memoを実行するな」と明記されている。記憶に書き込むのは主エージェントだけ、という交通整理である。

重厚なフレームワーク勢との距離

この軽さは、いまの記憶市場を意識すると輪郭がはっきりする。最も普及しているmem0はGitHubで5.1万スター超、調達額は2400万ドル規模で、長期記憶ベンチLongMemEvalで93.4%を叩き出す本格派だ。MemGPT由来のLetta（1.3万スター超）は、メインコンテキストをRAM、アーカイブをディスクに見立てる「エージェント用OS」を標榜している。

対してOptMemは、公開直後で900弱のスター、コードは1ファイル。ベンチマークの数字で殴り合う土俵にはいない。ここは正直に書いておくべきで、大規模運用や厳密な検索精度が要る現場では、成熟したmem0やZep、Lettaのほうが妥当な選択になる場面は多い。

それでもOptMemが刺さるのは、「まず動かす」までの摩擦がほぼゼロだからだ。この発想は、モデルよりハーネス（周辺の設定や道具立て）で差がつくという最近の空気とも地続きにある。設定ファイルを束ねるagentsmithや、少ない行数を信じて全体を回す「93行だけ信じろ」の考え方と、根っこは同じ場所を向いている。

作者はなぜ、これを売らなかったのか

Taelinという名前で身構える読者もいるだろう。彼はブラジル・リオを拠点に、Higher Order Companyで並列ランタイムHVMや言語Bendを作ってきた人物で、Lafontの相互作用ネットを実務に持ち込む、理論寄りのハッカーだ。そんな彼が「新しいことは何もしていない」と自ら断りながら出したのがOptMemだった。

コミュニティの反応は割れた。「シンプルで正しい、これでいい」と歓迎する声の一方で、情報を捨てる・圧縮する挙動への懸念もあった。そしてもうひとつ多かったのが、「なぜ製品にしなかったのか」という声だ。月額課金なら払った、と。

その問いにこそ、このツールの性格が出ている。記憶という機能を、囲い込むSaaSではなく、コピペできる426トークンとして配ってしまう。エージェント時代の道具は、こういう手渡し方もあるのだと示した点が、機能そのものより効いているのかもしれない。

日本・個人開発の視点

日本の個人開発者にとって、OptMemの敷居の低さは大きい。ベクトルDBの契約もインフラも要らず、Pythonが動く手元なら今日から試せる。CLAUDE.mdに数行、記憶は手元のログに積む——この構成なら、外部サービスに顧客データを預けにくい受託や社内ツールでも採用の相談がしやすい。

しかも記憶の実体はただのテキストログだ。中身を自分の目で読めるし、gitで差分を追える。ブラックボックスのベクトル空間に何が入っているか分からない不安がない、という透明さは、小さく作って責任を持つ現場ほど価値になる。

要点まとめ

• OptMemはHVMで知られるVictor Taelinが公開した永続記憶ツールで、実体は426トークンのプロンプトと依存ゼロのPython1ファイル。
• 記憶は追記専用のログに積み、napで古いものを二分木状に畳む。何も消さないのに文脈は一定サイズに保たれ、古い記憶ほど粗くなる。
• wakeで読み、note（280字まで）で書き、recallで検索、zoomで過去を掘り下げる、という最小の動詞で完結する。
• 100万件でもwakeは0.03秒。読み込み量はWAKE_LINESで調整、置き場所はMEMORY_DIRで移動できる。
• mem0やLettaのような本格派とは精度で競わないが、「まず動かす」までの摩擦の低さと透明さが持ち味。

出典・リンク

• 出典: https://github.com/VictorTaelin/OptMem
• Victor Taelin本人の告知（X）: https://x.com/VictorTaelin/status/2081453432318132603
• OptMem紹介記事（Digg）: https://digg.com/tech/8d2l5808
• Mem0 vs Letta（MemGPT）比較: https://vectorize.io/articles/mem0-vs-letta
• 2026年のAIエージェント記憶フレームワーク比較: https://atlan.com/know/best-ai-agent-memory-frameworks-2026/
• Victor Taelin / Higher Order Company（HVM）: https://github.com/victortaelin