Claude Code のメモリ:なぜ忘れるのか、そしてそれを直す2つの数字

私はデザインスタジオの運営を Claude Code の中から行っている。ターミナルは10から20個開いていて、そのすべてが私だ。そして何ヶ月もの間、そのすべてが同じ人間に同じことを繰り返させていた。

Brainy のチームはこの件の発端となったセッションを、たった一行で切り出した。もう同じことを繰り返すのはうんざりだ、と。そして7つのメモリ製品のベンチマークとリポジトリを貼り付け、なぜ自分の裏側にあるメモリはああならないのかと尋ねてきた。

この論文は、それを真剣に受け止めた結果わかったことをまとめたものだ。次の4つの作業がその土台になっている。

• メモリシステムを作り直した
• 16体のリサーチエージェントに、名前が挙がるすべてのメモリプラグインとプロバイダーを調べさせ、うち8体には残り8体の主張を論破させようとした
• 自分たちで用意したテストではなく、実際のプロンプトで自分たちの成果を測定した
• ベンチマークを自分たちの手で実行し、すべての競合を同じ審査者で採点した

この結果はプラグインのおすすめではない。2つの数字と、1つの崖と、メモリが何を主張してよいかについての1つのルールだ。

バグの正体:几帳面な書き込み、気まぐれな想起

その4語がまさに「同じことを繰り返す」バグの正体だ。

丁寧に書かれ、気まぐれに読まれるメモリは、あらゆる監査を通過する。なぜならすべてのファイルはそこにあり、すべての事実は正しいからだ。

それでも人間はデプロイのルールを4回目に説明する羽目になる。そのルールが重要だった瞬間に、誰もそれを取りに行かなかったからだ。

それが私たちのケースだった。すべてのセッションがメモリを書き込んでいた。それを読むかどうかは、手作業で維持している単一のインデックスファイルが読み込めるほど短いかどうかと、作業の途中で私が見に行こうと決めるかどうかにかかっていた。

どちらも確実には起きなかった。ストアは書き込み専用に近い状態で、書き込み専用のメモリはメモリではなく日記だ。

几帳面な書き込み、気まぐれな想起。

あなたのメモリファイルには隠れた崖がある

**Claude Code は自動メモリのインデックスである MEMORY.md ファイルを、200行または25,000バイトのどちらか先に達した時点まで読み込む。**それを超えた行は一切読み込まれず、しかも誰もそれを教えてくれない。

私たちのファイルは229行、31,283バイトあった。バイト数の上限により176行目で切られていた。その下には、恒久ルールのセクションが丸ごと3つ、その中にはセキュリティに関するものも含まれて眠っていた。

53行、インデックス全体の23%。それらは一度たりともセッションに届いたことがなかった。

さらに悪いことに、このファイルは新しい項目が末尾に追記される形式だ。上限は下から切り落とす。つまり真っ先に脱落するメモリは、あなたが最近書いたばかりのもの、つまり今まさに取り組んでいる事柄についてのものになる。

もしメモリにルールを追加したのに、1週間後にエージェントがそれを無視するのを見たことがあるなら、行数を数えてみるといい。この上限は Claude Code のイシュートラッカーに2件のイシューとして記録されており、ファイルがどちらかの数字を超えて成長していれば、今まさにあなたにも同じことが起きている。

満点だったのに正答率17%だった件

修正の最初のバージョンは2時間でできた。ストア全体への全文検索インデックス、そしてすべてのプロンプトでそれを検索し、上位のヒットを注入するフック。23個のテストクエリからなるバッテリーでは22点を獲得した。

そして実際のログを読んだ。実プロンプト6件、注入されたメモリ18件、そのうち関連していたのは約3件。17%だ。

ベンチマークのクエリは「deploy to production」のようなものだった。チームの誰もそんな打ち方はしない。彼らが打つのは長く、会話調で、複数の節からなり、スクリーンショットやURLが貼り付けられたプロンプトだ。

プロンプトの文字列そのものは検索クエリとして最悪で、話題はたいてい一つ前のターンに存在している。私たちは良いパイプを作り、そこに悪い水を流していたのだ。

原因は5つ、それぞれ測定し、それぞれ修正した。

5つ目の原因が最悪だった。セッションの会話に検索を主導させると、メモリについてのセッションでは毎ターンあらゆるメモリノートが想起され、デプロイに関する質問にはデプロイのルールの代わりにインデックスファイルが返ってきた。文脈はすでに主題があるクエリを研ぎ澄ますことはできる。しかし主題を作り出すことは決して許されない。

書き直した後、実プロンプト16件のうち14件で正しいメモリが上位2件に入り、「ok go ahead」のような会話調のプロンプト18件は、18件とも正しく何も返さなかった。

沈黙は機能のひとつだ。必要のないプロンプトに注入されたメモリは、モデルが読み飛ばさなければならないノイズにすぎない。

ただひとつのルール:プロンプトの経路にモデルを置かない

ここで最初の数字が出てくる。フックから言語モデルへの往復は8.6秒。ストア全体への全文検索は18ミリ秒だ。

あなたが打つすべてのプロンプトは、エージェントがその言葉を見る前にフックを実行する。そのフックにモデルを置けば、質問するたびに始まる前から8秒かかることになる。「賢い」メモリプラグインの多くがラグのように感じられる理由は、これに尽きる。

だからルールは絶対だ。**モデルはプロンプトの経路では決して動かない。**モデルはオフラインで、セッション終了時と毎日のスイープで動き、学んだことをインデックスに書き込む。そこでの仕事は3つある。

• 会話記録からメモリを提案する
• 人間が実際に打つであろう言葉を導き出す。これにより「production deploy accident」というタイトルのノートが「am I about to nuke production」にもマッチするようになる
• 重複と矛盾を見つける

そしてモデルは去り、プロンプト時に応答するのは素の SQLite だけになる。

この分離のコストはゼロドルと18ミリ秒

この分離のコストはゼロドルだ。モデル呼び出しはすべて、すでに支払っているサブスクリプション経由で行われ、すべてのプロンプトで実行される検索そのものには一切コストがかからない。何もマッチしなければ、トークンは1つも消費されない。メモリの限界費用は、設計上、永遠に正確にゼロだ。

痛むのは時間という予算のほうだ。フックはプロンプトのたびにまっさらな状態から始まるので、何かを読み込めば次回もまた読み込み直すことになる。各選択肢を測定した結果がこちらだ。

キーワード検索は、品質の議論に入る前に、レイテンシですでに勝っている。

入力は即座のまま。それがこの決定のすべてだった。

「ファイルが散らばっている」という批判は的外れだ

私たちが繰り返し耳にした批判には2つの側面があった。メモリが markdown ファイルに散らばっている、そして毎回の会話に完全なメモリを持ち込んでいない、というものだ。チームが引き合いに出したエージェントハーネスである Hermes には、あなたと共に育つひとつのメモリがある。

どちらの側面にも、率直な答えを返す価値がある。

完全なメモリを毎回の会話に持ち込むことは、算数的に不可能だ。私たちのストアは875,553トークンある。コンテキストウィンドウは200,000だ。つまりメモリはウィンドウ4.4個分あり、しかも毎日増え続けている。

誰も完全なメモリを持ち込んではいない。誰もが検索(リトリーブ)しているのだ。

そして Hermes の「ひとつのメモリ」は3,575文字だ。2,200文字のメモリファイルと1,375文字のユーザープロファイル、どちらも常にプロンプトに含まれ、どちらもハード上限がある。Hermes が知っているそれ以外のすべては、ディスク上のファイルに存在し、私たちが使っているのと同種のインデックスで必要に応じて検索される。

「markdown ファイルに散らばっている」という描写は、両方のシステムに当てはまる。ファイル数はストレージの問題にすぎない。アクセスを決めるのはインデックスだ。487個のファイルがひとつの全文検索インデックスの背後にあるのは散らばりではない。ひとつのクエリが18ミリ秒でそのすべてに触れる。

批判が正しかった点

その批判は、主張していたこととは正反対の点で正しかった。Hermes の常時稼働レイヤーは約1,300トークンだ。私たちのは6,152トークンあった。彼らは4.7倍軽量で、その軽量さはあるハードルールから来ている。メモリが満杯になると書き込みは失敗し、エージェントは何かを追加する前に統合(consolidate)しなければならない。

私たちはそのルールを詳しく検討し、却下した。Hermes 自身のイシュートラッカーには、上限を8,000文字と3,000文字に引き上げてもなお上限に達してしまい、「memory.add 呼び出しの失敗と、オペレーターによる修正の繰り返しの消失を引き起こしている」というデプロイ事例が載っている。

**失敗した書き込みは統合を生まない。沈黙を生む。そして失われるのは、ユーザーがたった今行った修正そのものだ。**私たちのプロファイルは代わりに、最も弱い行を検索可能なストアへと降格させる仕組みになっていて、書き込みが失敗することはない。14行分の枠に12行を無理に詰め込んだテストでは、4行が降格し、ユーザーが実際に言った行はすべて生き残った。

7つのメモリ製品から学んだこと

チームが最初に提示したベンチマーク MemConflict は、7つのセルフホスト型メモリプロバイダーに同一の30人のシミュレートされたユーザーを与え、各プロバイダーに3,750問を尋ねた。誤答にはゼロではなくマイナス1のスコアを与える。この一つの選択だけで、この先の結果の大部分が露わになった。

ランキングより重要な3つの発見

あのテーブルの中で最も役に立たないのがランキングそのものだ。全プロバイダーに共通して見られたパターンが3つある。

• **植え付けられた偽のメモリを確実に拒否できるプロバイダーはひとつもない。**最良のスコアだった Honcho ですら、それらの質問に完全に正しく答えられたのはわずか36.4%で、植え付けられた虚偽を25.8%の頻度で断言していた。Mnemosyne はゼロ未満のスコアで、正しい値よりも間違った値を断言する頻度のほうが高い。

• **履歴が増えるほど、誰もが悪化する。**セッション6〜10からセッション46〜50にかけて、mem0 の誤答率は8.3%から22.1%へと上昇した。どのプロバイダーもおおむね2倍になっていた。

• **安全そうに見えたプロバイダーは、大半が沈黙していただけだった。**OpenViking は回答の67%を空白のままにし、Mnemosyne は50%だった。もし下限がゼロに設定されていたら、これらは競争力があるように見えていただろう。

そして私たちの設計を変えた発見はこれだ。証拠は検索されていたのに、使われていなかった。植え付けられた偽の事実に関する質問で、Honcho は上位3件の中に正しい裏付けとなるメモリを81%の頻度で取得していながら、それでも18%は(誤って)答えていた。ボトルネックは検索ではなかった。検索した後にシステムが何をするかが問題だったのだ。

Honcho はまた、バックグラウンドでの導出処理に1セッションあたり617,278トークンものモデルトークンを費やしている。私たちのストア全体でも875,553トークンだ。これを採用するということは、検索インデックスがすでに答えられる質問に答えるために、コーパスの大半を毎セッション、永遠に費やすことを意味する。

これが「自作するか採用するか」という決断の実態だ。彼らの強みは私たちのボトルネックではなかった。そして彼らの弱みこそが、まさに私たちの要件だった。言語モデルが矛盾の片側を削除しても、それを検証したり元に戻したりする仕組みが何もないという点だ。

自分たちでベンチマークを実行した結果:初回は0.409

他人が作ったテーブルはひとつの主張にすぎない。だから私たちはそれをそのように扱った。自分たちのメモリを同じハーネスに接続し、同じシミュレートされたユーザーと質問で採点した。

この種の数字が何か意味を持つかどうかを決める、2つの細部がある。

• **すべての行をひとりの審査者で。**公開されたテーブルは1つのモデルで採点されており、私たちのハードウェアで動くのは別のモデルだ。そしてハーネス自身のドキュメントには、この2つのスコアは決して比較できないと書かれている。そこで私たちは、すべての競合が公開した回答を取得し、自分たちの審査者で自分たちの回答と並べて再採点した。同じ5人のユーザー、同じ616問で。

• **漏れ得ないチューニング。**すべての変更は別の2人のユーザーでチューニングし、結果が一つも出る前に書き記しておいたルールに従って、報告対象の5人には正確に一度だけ採点をかけた。

初回の実行では、私たちは RetainDB と同水準で、採点できた他の2つには及ばなかった。

ボトルネックは回答生成ではなく、想起の深さだった

診断結果はひとつだけで、それはランキングでも回答生成でもなかった。**正しい文が上位5件に入っていれば、94%の確率で回答は正しかった。**ただ、たいていの場合そこに入っていなかっただけだ。

ミスの大半は上位50件の中に埋もれており、読まれるには順位が低すぎた。キーワード検索には、深さをいくら増やしても直らない死角もある。ユーザーの居住地が変わったかどうかを尋ねられても、「I just relocated to Melbourne(メルボルンに引っ越したばかり)」のような文は見つけられない。一語もマッチしないからだ。

そこで私たちは3つの変更を加え、それぞれを2人のチューニング用ユーザーで採点した。

解決策:意味検索と、自己更新するファクトノート

この意味検索はモデルではない。単語片ごとに1つのベクトルを持つ静的な埋め込みテーブルで、それを平均化するだけだ。ネットワーク接続なしで numpy 上で動作し、ノートパソコン上で過去の会話71,062ターンを34秒で埋め込みに変換する。プロンプトごとのフックは、それでもこれには一切触れない。

ファクトノートは、これまでストアになかった部分だ。人や組織についての永続的な事実は一度書かれ、変化したときに更新される。新しい値が開始日とともに一番上に来て、古い値はすべてその日付とともに下に残る。これ以前は、変更は人間がレビューするために提案されるだけで、しかも誰もキューをレビューしないので、ストアはクライアントが存在することは学習できても、そのクライアントが移転したことは決して学習できなかった。

上限を設けないと、これらのノートは会話より上位にランクされ、すべての枠を埋め尽くしてしまった。周囲の会話、つまり条件付きで人が何を好むかを必要とする質問は、それを失った。ひとつのストアが、モデルが読むウィンドウを独占してはならない。

一度だけ採点した結果、mem0 と0.520で並んだ

報告対象の5人のユーザーで、正確に一度だけ採点したところ、最終版は mem0 と並んだ。

この同点の内訳を見ると、2つの指標で私たちが上回り、2つで劣っている。

ほぼ同一の私たちの回答を2回独立に採点したところ、差は0.007だった。だからこの同点は本物の同点だ。ただし3つの注意点とともに読んでほしい。

• **この5人のユーザーは、誰に対しても優しい。**mem0 は30人全体では0.392を公表しているが、ここでは0.520を記録している。つまりこのテーブルの数字は、公開されているテーブルへはそのまま変換できない。

• **Honcho はこのテーブルには含まれていない。**公開テーブルではトップだが、1問あたり114,804文字もモデルに渡しており、GPU1台での採点は1分に1問というペースでしか進まなかった。おそらく今でもトップのままだろう。

• **精度で並ぶことは、勝ちを意味しない。**精度で並びながら、会話の処理を20倍速く、テキスト量は半分で済ませるメモリは、より優れた製品というより、異なる製品だ。どちらが重要かは、あなたの請求書次第だ。

「自己修復するメモリ」は、実は2つのシステムだ

「自己修復するメモリ」はチームのリストに挙がっていた項目だ。リサーチの結果、その言葉が実際には何を意味するのかがわかった。それはひとつのものではない。

メモリのコントロールプレーンに関するある論文がそれを測定していた。決定論的なルールはあるクラスのクリーンアップで5%のスコアしか出せず、モデルは同じクラスで100%を出す。一方でその同じモデルは、ルールなら問題なくこなせる「意図を汲んだ削除」で0%しか出せない。両方を行うと27.8ポイントの向上が得られる。自己修復するメモリには、決定論的なパスとモデルによるパスが、それぞれ異なる場面で必要であり、どちらか一方だけでは決して足りない。

決定論的なパスは、バイト単位で完全に一致する重複や、もはや存在しないファイルパスを名指ししているメモリを見つける。初回の実行では実際に13件のフラグが立った。モデルによるパスは、関連するメモリ同士の矛盾を見つけ、どちらがどちらに優先するかを提案する。

ガードなしでは、モデルによるパスは正答率がおよそ55%しかなく、しかもすべての間違いに確信を持っていた。クラウドセッションに関する参考ノートを使って、恒久的な権限ルールを無効化してしまった。「CloudFront」という語が両方に含まれていたというだけの理由で、ある製品の CDN に関する事実を、別の製品のリリースノートを使って削除してしまった。

ポインタとなるマップに、それが指し示している本物のメモリを無効化させてしまった。未解決の決定事項が6件並んだリストを、新しいメモリがそのうちの1件を解決したというだけで、丸ごと無効化してしまった。

4つのガードと取り消し機能が、キュレーターを安全にした

4つのガードがこれを解決した。

ガードを有効にした状態では、同じスイープが正しい優先関係をひとつだけ自動適用し、本当に緊張関係にある3件をレビューキューへ送った。

これを人の手を借りずに実行しても安全な理由は、モデルがこの作業を得意としているからではない。何ひとつ削除されることがなく、すべての決定が監査ログに残り、コマンドひとつで元に戻せるからだ。

優先関係で負けたメモリは、目に見えるラベルとランキング上のペナルティを付けたまま、ストアに残り続ける。古い事実は消滅するのではなく半減期をもって減衰する。プロジェクトのノートは150日ごとに重みが半分になり、ユーザーが与えたルールはまったく減衰しない。

キュレーターを生産的に見せるために、ガードを緩めてはならない。

メモリとはひとつの主張である、だから検証せよ

ここが、私たちが調べた他のどのシステムもやっていない部分だ。

5月には真実だったのに、静かに真実でなくなったメモリは、目に見えない。何とも矛盾せず、死んだパスを名指しすることもなく、ただそこに間違ったまま座っている。

私たちのストアには「Instagram のトークンは Lambda によって毎週自動ローテーションされる」と書かれたメモリがあった。Lambda など存在しなかった。トークンは一度たりともローテーションされたことがなかった。それでも何ヶ月もの間、真実として読まれ続けていた。

そこで今では、すべてのメモリを一連の主張の集合として扱い、それらの主張を検証(プローブ)している。モデルはメモリを読み、あらかじめ決められた一連のプローブに型付きの引数を入力する。このパスは存在するか、このブランチは存在するか、このプルリクエストはマージされているか、この Doppler プロジェクトは存在するか、このシークレットは存在するか、このインスタンスは存在するか、この URL は応答するか。

モデルがコマンドを書くことは決してない。すべての引数は実行前に検証され、これに対する9件のプロンプトインジェクション攻撃はすべて拒否された。スケジュール実行されるモデル製のシェルコマンドなど、手間をかけたリモートコード実行の穴にすぎない。

最初のフル実行では、365件のメモリから383件の主張が抽出された。328件は検証を通過した。25件は失敗し、その失敗は現実のものだった。

メモリが言ってよいこと

この失敗から2つのルールが生まれた。どちらも、メモリが何を言ってよいかについてのルールだ。

プルリクエストの状態は事実ではなく、気分のようなものだ。数秒で変わる。抽出器は現在「merged」だけを受け付ける。merged は終端状態だからだ。open や closed は拒否する。この変更で11件の主張が除外された。

そしてプローブは、失敗が何を意味するかによって使い分けられる。存在しないパスは証拠になる。ファイルシステムはどこから見ても真実を語るからだ。応答しない URL は証拠にならない。このノートパソコンから到達できないことと、実際にダウンしていることは同じではないからだ。

だから URL のプローブは、機械的に「fail(失敗)」を返せないようになっている。**それは「生きている」ことは証明できる。「死んでいる」ことを証明することは禁じられている。**このルールが存在するのは、私が1回の監査の中で、健全でファイアウォールの内側にあるだけの製品を3回も「ダウンしている」と誤って言ってしまったからだ。覚えていないと守れないルールは、ルールではない。

検証に失敗した主張は、そのメモリに「未検証」というマークを書き込む。想起されたときには、そのヒットの隣にそれが表示される。人間が手を動かす必要はない。メモリはラベル付きで届く。

何を盗み、誰から盗んだか

16体のリサーチエージェントがリポジトリを読み、固定したコミットでクローンし、コードを実行し、互いの主張を論破しようとした。64件の主張のうち、55件が生き残った。2つの「引用」は捏造されており、1つのテーブルは別のものにすり替わっていた。だからこそ、リサーチエージェントの出したものはファクトチェックしなければならない。

採用と却下:3つのエージェントから

採用と却下:残りの面々

引用とはひとつの仮説である

リサーチの中のあるエピソードは、独立したセクションに値する。なぜならそれは、この種の論文を読んでいる誰もが今まさに犯そうとしている間違いだからだ。

よく引用される情報検索の論文が、標準的なベンチマークでドキュメント拡張を測定していた。言い換え表現でドキュメントを拡張すると、拡張なしのベースラインを下回るスコアになった。自分自身の用語をコピーして拡張すると、それを大きく上回るスコアになった。

私たちのエンリッチメント用プロンプトは、モデルが生成する語がそのノートに含まれていてはならないと明示的に指示していた。私たちは負けるほうの半分を生成し、勝つほうの半分を抑制し、しかも負けるほうの半分を1.75倍にブーストしていたのだ。

そこで私たちはその発見を適用した。474件のメモリすべてを作り直した。バッテリーの結果は16件中14件から16件中13件へと悪化した。

あの論文のベースラインは、自分自身の用語を含まない状態でインデックスされたドキュメントであり、それらを戻すようにコピーすることこそが拡張だった。私たちのシステムはすでにタイトル、説明、本文をインデックスしている。それらをエイリアスのフィールドにコピーすることは重複でしかなく、私たちが持っていた唯一の本物の拡張だった言い換え表現を押しのけてしまっていたのだ。

元に戻し、作り直し、16件中14件に戻った。かかった時間は40分。もし信じる前に測定していれば、それすらゼロで済んだはずだ。

引用とは、他人のシステムについてのひとつの仮説にすぎない。

その後、このメモリシステムは注目に値する振る舞いをした。セッション終了時に、その仮説を自動的に捕捉したのだ。しかしその反証は捕捉しなかった。

「用語を含めるべきだ」と書かれたそのノートは、今もなお有効なメモリとしてストアの中に残っている。捕捉の仕組みは、信じられていたことを書き留めるだけで、1時間後にその信念が覆されたことまでは知らない。これは未解決の問題であり、以下のリストに含まれている。

エージェント自身にスキルを書かせると、むしろ悪化する

チームは自律的なスキル作成を求めていた。ある手順が繰り返されたら、エージェントがそれを再利用可能なスキルとして書き留め、そう報告するべきだ、と。それはひとつの超能力だが、リサーチによれば、素朴な実装はむしろ負債になるという。

決定論的なチェッカーを備えた87件のタスクからなるベンチマークで、エージェントが自分自身のために生成したスキルは、最も強力なモデルを使った Claude Code上で、スキルが一切ない状態よりも8.1ポイント低い結果になった。同じパターンは他の2つのハーネスでも確認された。

人間がキュレーションしたスキルは、通過率を33.9%から50.5%まで引き上げた。そして、2つのスキルのどちらが優れているかをモデルに尋ねると、実際に差がある場合でも100回中84回、劣っているほうを選んでしまう。

長さは、誰も予想しないかたちで結果を左右する。それは右肩上がりの坂ではなく、山型のカーブを描く。

1ページを超えると、ドキュメントはもはや役に立たなくなる。

私たちが作ったバージョンは、人間を待つ

だから私たちが作ったバージョンは、自律とは正反対だ。3つ以上の別々のセッションにまたがって繰り返される手順だけを検出し、それをカウントによって把握する。71,062ターン分の会話記録がすべてインデックスされているため、「これは繰り返されているか」はモデルの推測ではなく、データベースへのクエリで判定できる。

スキルは不活性な状態で書かれ、その説明が誰かのコンテキストに勝手に入り込むことはない。ゲートは文章による判断ではなく構造的なものだ。そのスキルが防ぐ具体的な失敗の名前を挙げること、そこで引用されるすべてのパスはファイルシステムと照合されることが求められる。昇格させられるのは人間だけだ。

6つの敵対的な下書き、組み込み機能の影に隠れたもの、「時間を節約する」だけのもの、1回しか見られていないもの、架空のパスを含むもの、本文が肥大化したものでテストしたところ、それらはすべて却下され、正当なものだけが採用された。

30セッションにわたる最初の実運用では、下書きすべきものは何も見つからなかった。それが正しい答えだった。それ以降、1つのスキルが昇格している。デプロイコマンドが密かに本番環境を対象にしてしまうことを防ぐガードだ。

それでもまだ間違っていること

正直であることは、その代替案よりも安上がりだ。だからここに残された課題を記す。

常時稼働レイヤーは今なお Hermes の3〜4倍重く、現在は約24,000バイトある。それはプロファイルというよりインデックスだ。私たちが感心したあの軽量さは、私たちが却下した仕組みから生まれているもので、同じ規律をもたらすもっと穏やかな方法はまだ見つけられていない。

境界をまたいだ一貫性は担保されていない。ユーザープロファイルを出荷した瞬間から、その中のすべての事実は二重に存在することになった。キュレーターはメモリ同士を照合するだけで、プロファイルとストアの照合も、メモリとプロジェクト自身の指示ファイルとの照合も行わない。Honcho は、ひとつの事実から導出された2つの見方がいずれ食い違い、モデルが間違ったほうに従ってしまうことの証明だ。

捕捉はセッション終了時とコンパクション前に発火するが、それはまさに、一度もうまくいかなかった一連の出来事を、確信を持って書き記してしまう可能性が最も高い瞬間だ。前述の反証された引用が、その生きた実例だ。

メモリは、そのプローブが検証できる範囲でしか検証できない。パス、ブランチ、プルリクエスト、シークレット、インスタンスは検証できる。「そのページには3,000行のうちのその行が属している」というような主張は検証できず、「ユーザーは X を好む」というのはそもそも主張ですらない。

ストアは今でも、静かに間違った記述を保持しうる。ただ、静かに間違ったパスだけは保持できなくなった。

ベンチマークにおいて、条件付きの好みは今もなお私たちの最も弱い質問タイプであり、証拠を上位5件に入れる頻度は mem0 のほうが今も高い。ベンチマーク時、ファクトノートは小さなモデルで動かしており、それが虚構を作ることがある。あるケースでは「頼れる母がいない」という発言を読んで、そのユーザーを「独身」と記録してしまった。そして公開テーブルの首位に立つシステムは、私たちが再採点できなかった唯一のシステムだ。

そしてこのメモリシステム自身についてのメモリも、古びてしまっている。あるノートは、フックをプラグインへ移す際にシステム自身が削除したフックファイルを指している。それは他のものと同様、「未検証」のラベルを付けられたままレビューキューの中で待っている。

6つのルール

このノートから何かひとつだけ持ち帰るなら、このリストを持ち帰ってほしい。

より大きな教訓は、この分野全体が繰り返し、間違った側から再発見し続けているものだ。メモリのうち「想起」の半分、つまり正しいノートを見つけるという部分は、よく研究されており、コストのかからない検索インデックスでほぼ解決されている。「統制」の半分、つまりノートが何を主張してよいか、いつ優先関係で入れ替わるか、間違ったノートがどう見つかるかを決める部分こそが、メモリが腐っていく場所だ。

その半分を誰も売っていないのは、それが機能ではないからだ。それは規律であり、誰もそれを覚えていなくて済むように、コードの中にコンパイルしておかなければならないものだ。

コード、ベンチマークアダプター、そしてすべての採点結果は github.com/brainyboon/quipu でオープンソースとして公開している。

Boon が何の上で動いているのか、その他の部分も見てみたいなら、まずは デザイナーのための Claude Code、エージェントに手を与える MCP サーバー、デザイナーのための AI エージェント、そしてこのメモリがゼロに保っている請求書そのものである エージェントのトークンにかかるコスト から始めるといい。自分のブランドにもこの種の丁寧さを取り入れたいなら、Brainy Studio がその出発点だ。

---

よくある質問

なぜ Claude Code は MEMORY.md に書いたことを忘れるのか

Claude Code は自動メモリのインデックスを、200行または25,000バイトのどちらか先に達した上限まで読み込み、残りは黙って無視する。このファイルは新しい項目が末尾に追記される形式で、下から切り落とされるため、最も新しいメモリから先に脱落する。最近追加したルールをエージェントが無視するなら、そのファイルの行数とバイト数を数えてみるといい。

Claude Code にメモリプラグインを入れるべきか

2つのことを確認するといい。プロンプトの経路でモデルを動かしていないか(これはすべてのプロンプトに数秒を加える)、そしてバックグラウンドデーモンを動かしていないか(最大手のプラグインのオープンなイシューの大半はここに集中している)。私たちの問題を解決したのは、すべてのプロンプトで検索される全文検索インデックス、オフラインでのモデルパス、そして検証ステップだった。そのどれもデーモンを必要としない。

AI エージェントのメモリにキーワード検索だけで本当に十分なのか

プロンプトごとのフックに関しては、十分だ。標準的なゼロショット情報検索ベンチマークでは、あらゆる単一ベクトル埋め込みモデルが素の BM25 キーワード検索に敗れており、ニューラルなリランカーはモデルの読み込みだけで約1.5秒かかる。18ミリ秒という予算に対してはあまりに重い。過去の会話を検索する用途には、キーワード検索だけでは足りない。静的な埋め込みテーブル、モデルというよりルックアップに近いものだが、それは変化を知らせる文をキーワード検索の2倍の頻度で見つけ出した。単純にキーワードのランキングと混ぜ合わせると結果はむしろ悪化した。順位で融合し、広く集めるようにしたことが、mem0 と並ぶ結果につながった要因のひとつだ。

このメモリシステムはオープンソースか

はい。プラグイン、MemConflict ベンチマークのアダプター、手法、そしてすべての採点結果のサマリーは、MIT ライセンスのもと github.com/brainyboon/quipu で公開されている。コア部分は Python の標準ライブラリだけで動く。意味検索には numpy が必要だ。

メモリが誤った情報を信じ込むのをどう防いでいるのか

2つの方法がある。ひとつは、決して削除しないキュレーターだ。矛盾が見つかると、古いほうのメモリに目に見えるラベルとランキング上のペナルティを付けて「優先関係で負けた」とマークする。すべての決定はログに記録され、コマンドひとつで取り消せる。もうひとつは、各メモリを型付きの主張の集合として扱い、それらを現実世界と照合し、失敗したものには「未検証」のマークを付ける検証者(verifier)だ。

このメモリシステムの運用コストはいくらか

限界費用はゼロドルだ。検索はローカルのデータベースクエリであり、すべてのモデル呼び出し(セッション終了時の捕捉、新規メモリのエンリッチメント、毎日の矛盾スイープ)は、すでに支払い済みのサブスクリプション経由で行われ、従量課金の API を使うことは一切ない。実質的なコストはプランの利用枠で、1セッションあたりおおよそ小さな呼び出し1回分だ。MemConflict ベンチマークでは、会話1件の処理に1.6秒しかかからなかった。同じマシン上での mem0 は31.6秒だった。