AI に判断や失敗を記録させていると、増えた記録をどう引くかが問題になる。私の環境では、1 ファイルへの追記が壊れ、記録を 1 件ずつのファイルにして関連をたどる仕組みを作り、それを数か月動かしたあと、止めて別の形で作り直した。最も作り込んだのは 3 回目の書き直し（v3）で、いまは動いていない。この記事では、何を作り、どこで壊れ、なぜ止めたかを、いまの形まで続けて書く。ハーネス全体の経緯は別の記事にある。
毎回ゼロから始まる
AI はセッションをまたいで覚えていない。標準の機能として、気づいたことをファイルに書いておくと次のセッションで索引が見える仕組みと、人が書く指示書の CLAUDE.md がある。ただし、どちらも書き留めることと毎回目に入れることまでで、増えた記録から今の話に関係するものだけを探すことは面倒を見てくれない。CLAUDE.md は増えるほど毎回の読み込みが膨らみ、標準のメモリは見出しだけの一覧なので、件数が増えるほど関係の有無を端から確かめる作業が重くなる。壁は一度に読み込める分量の限りという点で共通している。
1 ファイルへの追記が壊れた
最初は、判断を decisions.md という 1 ファイルに DEC-001、DEC-002 と連番で追記していた。数十件までは全体を見渡せて、grep で番号も拾えた。700 行を超えたあたりから、追記するエージェントが書き込み途中で止まるようになった。さらに、引き継ぎ用の handoff.md にも確定した判断を書いていたので、同じ情報が 2 か所にあり、片方を更新するともう片方が古くなった。手作業の同期は抜けた。ある日、DEC-035 から DEC-037 の 3 件が decisions.md から消え、handoff.md にだけ残っていた。
この設計を書いた記事を公開した翌日の出来事で、これが v0 だった。
3 回の書き直し
4 日後に v1 へ移した。原因は同じ情報の二重管理だったので、片方を廃止する形にし、BRIEF.md を 1 枚だけ置いた。セッション終了のたびに走るフックが軽量モデルで要約して BRIEF.md を上書きし、開始時はその中身をそのまま注入する。開始時の読み込みは約 4,750 トークンから約 300 トークンになり、94 パーセント減った。手作業の更新も二重管理もなくなり、4 日間は問題なく動いた。
限界は、複数のプロダクトの開発状況、発信の判断、監査の記録、アイデアのストックなど、扱う文脈が増えたときに来た。300 トークンの上限を守ろうとすると、どれかが削られ、削られた文脈はそのセッションで初期化される。1 枚に全部を集めること自体が問題だった。
v2 は、セッションごとに BRIEF.md を分ける案だった。複数のセッションが同じファイルを読み書きするとクラウドドライブ上で競合し、どれを読むかの選定も複雑になるので、ほぼ形にならないまま棄却した。続いて外部のライブラリを調べ、GitHub で 5,600 スターのものを見つけたが、全文検索の部分が日本語に対応しておらず、ドライブの汚染のおそれと常駐サーバーが要る点が個人の環境には重かったので、これも見送った。
このとき、v2 の検討でも外部ライブラリでも、暗黙に「ベクトル検索で上位 K 件を取って渡す」ことを前提にしていたと気づいた。検索エンジンの発想をそのまま記憶に持ち込んでいた。
上位 K 件で切ると、重要なものが落ちる
K を小さくすると、半年前に確定した判断が、その後に書かれた大量のメモに埋もれて上位に来なくなった。K を 10 から 20 に増やすと古い判断は拾えたが、関係の薄いものが混ざり、読ませる側の精度が下がった。どちらに振っても悪くなること自体が、前提の誤りを示していた。
ベクトルの類似度が示すのは、そのメモがクエリと意味的にどれだけ近いかである。記憶として必要だったのは、その判断を理解するために一緒に見るべき他の判断だった。たとえば X の告知文を書くとき、X の戦略のメモは類似度が高いが、note の書式を決めた判断は、告知文と埋め込みの上では近くない。告知は note 記事へのリンクを貼るので、その書式の方針も要る。強い関連と、重要な関連は別だった。
そこで検索ではなく、想起として設計し直した。起点になるメモを意味検索で見つけ、そこから参照関係の線を 1 本ずつたどって範囲を広げる。たどるたびに活性度が下がり、一定以下になったら止める。認知科学の活性化拡散の考え方と、Zettelkasten のネットワーク型ノート術を参考にした。
v3 の中身
1 メモ 1 ファイルを基本にした。判断は DEC、失敗は FAIL、セッションの経緯は SESS、アイデアは IDEA という接頭辞と連番を持つ。冒頭の frontmatter に ID、種類、日付、タイトルを書き、本文は DEC なら Goal、Options、Decision、Why の見出しで書く。書いたら未整理の箱である inbox/ に置くだけで、整理は書く時点ではしない。ファイル名を ID にしたので、他のメモの本文にその ID を書くだけで、参照関係が機械的に読み取れる。
整理はバッチが引き受けた。inbox/ に 3 件以上たまった状態でセッションを始めると、裏でバッチが走る。各メモを軽量モデルで 2、3 行に要約し、768 次元の埋め込み（無料公開の多言語モデルを手元で動かした）を作り、本文中の ID を参照線として記録し、意味の近い候補を推定して線を足し、archive/年/月/ へ移す。記録は SQLite の 1 ファイルに入れた。notes テーブルに要約と埋め込みを、edges テーブルに線の種類と重みを持たせ、検索は全件との総当たりにした。数百件までなら一瞬で終わる。
原本のテキストは残した。データベースだけにすると壊れたときにすべてを失うので、テキストさえあればデータベースは作り直せる二重の構えにした。バッチ自体も、失敗したら inbox/ に残して次回に回す設計で、100 パーセント成功することは求めなかった。リトライの分岐を書き始めると、失敗の処理が成功の処理より大きくなったからである。
想起は次のように動かした。
- 今の話題を埋め込みにし、コサイン類似度 0.75 以上のメモ（なければ最も近い 1 件）を入口にする。
- 入口から線を 1 本たどるごとに、活性度に 0.7 を掛ける。
- 親の活性度の 6 割を下回った枝は、その先をたどらない。持ち帰る総量にはトークン予算の上限も置いた。
- 活性度が 0.7 を超えたメモは全文、0.4 から 0.7 は要約、それ以下は題名だけを渡す。
発話のたびにフックが関連しそうなメモを探して横から差し出す仕掛けも作った。呼び出しのたびにモデルを読み込むと 10 秒近くかかるので、読み込んだ状態で常駐させた。最初に取り込んだのは 74 件のメモで、参照線が 28 本、推定した意味の線が 70 本、合わせて 98 本できた。「軽量メモリシステム」などの 3 つのクエリで試すと、上位 K 件では出なかった古い判断が、線をたどって出てきた。
途中で、自分の書いた記事が記憶に入っていないことにも気づいた。次に書くテーマを AI に考えさせたところ、すでに書いた記事と重なる案が返ってきたことがきっかけである。判断ログは入れていたが、最も多く作っている記事を入れていなかった。公開済みの記事を同じ仕組みに取り込み、執筆に着手する前に過去記事との重なりを問い合わせることにした。返すのは警告で、書くかどうかの判断は人に残した。
止めた理由と、いまの形
その後、バッチ、常駐の想起、発話ごとの差し込み、週次のデータベース控えをすべて止め、退避した。理由は、その時点のセッションで差し込まれた記憶に、話題に合っていたものが 1 回もなかったことである。調べると、公式の機能も Cursor、Windsurf、Codex も、自動差し込みから「短い索引を常に見せ、中身は必要なときに開く」形に向かっていた。研究側でも、外れた記憶が混ざることが主な失敗原因として報告されていた。想起の精度の問題というより、毎回差し込むという前提が、保守の費用に見合っていなかった。
いまの形は次のとおりである。
- 判断と失敗のメモは、最初から
archive/年/月/に直接書く。inbox/は止めてから使っていない。 - 常に読み込むのは、DEC と FAIL の frontmatter から自動生成する 2 枚の一覧だけである。一覧は手で直さない。
- 失敗の記録は専用の入口を通す。書く前に過去の失敗を読み、同じ型なら lesson の書き方を揃える。
- 検索は呼んだときだけ動く。全文検索（FTS5 の trigram）と埋め込みを組み合わせて順位をまとめ、目次を返して中身はファイルを開く。常駐はなく、索引はクラウドドライブの外に置く。
- セッションの要約は、終了時と圧縮前にフックが SESS として書く。
作り直した検索を 10 問で試すと、答えのあった 9 問がすべて上位 5 件に入った。1 回の検索は約 9 秒で、ほとんどがモデルの読み込みである。引いて当たったかどうかは、1 か月記録して判断する予定で、まだ結果は出ていない。記録は、この記事を書いた時点で DEC が 200 件近く、FAIL が 100 件あまり、SESS が 200 件あまりある。
書き直しについて
v0 から v3 までは 1 週間以内に書き直した。v3 は 4 か月あまり動いたあと、動かなくなったのではなく、費用に見合わなくなって止めた。作り直しは 2 回目になる。記憶の設計は、組織の複雑さと、それを使うモデルや公式機能の変化に合わせて変わっていくので、完成した版は一度も存在しなかった。ただ、1 メモ 1 ファイルと種類ごとの接頭辞、原本を残す方針は、v0 の失敗から v3、そして今の形まで変わっていない。
この記事は、note に書いた次の記事を土台に、旧 v3 の経緯と作り直しの内容を足して書き直したものである。