記録は溜めるだけでは資産にならない。AIに「記憶」を持たせる仕組みの話
「あれ、この判断、前にも一度考えた気がする」
AIに判断や失敗を記録させているのに、同じ確認を何度もさせてしまっている人に、今日は向けて書きます。記録は増えているはずなのに、かえって使いにくくなっていく。そう感じたことがあるなら、なおさら読んでほしいと思っています。
以前、AIに複数の役割を渡して動かし始めたときに踏んだ3つの失敗を記事に書きました。その中で、こう書いています。
判断や失敗を記録として残しても、溜まったメモは放っておくだけでは、ただ増えていくばかりです。
この続きを、ここから書いていきます。溜めた記録を、AIが自分で整理して、必要なときに自分から思い出せるようにする。「記憶」と呼んでいる仕組みの中身です。
覚えておいてほしいのに、AIは毎回ゼロから起きてくる
まず、客観的な事実から確認します。ハーネス(AIを安全に動かすための環境)の部品表に、以前「メモリ」を挙げました。実はこの「メモリ」、標準の機能としてすでに用意されています。会話の中でAIが気づいたことをファイルに書き留めておくと、次のセッションで索引として自動的に目に入る仕組みです。もうひとつ、CLAUDE.mdという指示書も記憶に近い役割を持ちますが、こちらはAIが書き足すものではなく、人がルールを書いておくためのものです。
この二つの器にできるのは、書き留めることと、それを毎回自動で目に入れることまでです。増えた記録から今の話に関係あるものだけを意味で探し出すこと、記録同士を関連づけること、頼まなくても向こうから差し出してくれること。ここまでは面倒を見てくれません。
使っているうちに、それぞれ別の壁にぶつかります。CLAUDE.mdは増えるほどファイルが膨らみ、毎回まるごと読み込むという前提そのものが崩れていきます。標準メモリのほうは、一覧に並ぶのが見出しだけなので、今の話題と関係あるかをAIが端から確かめるしかなく、件数が増えるほどこの確認作業自体が重くなっていきます。形は違っても、行き当たる壁は同じです。
その壁の正体は、AIが一度に読み込める分量には限りがある、という一点に尽きます(コンテキストウィンドウと呼ばれる、作業机の広さのようなものです)。溜め続けた記録を全部その机に広げようとすると、いずれ広げきれなくなります。これは記憶力の問題ではなく、設計の問題です。
正直に言うと、私もこの壁にぶつかった一人でした。判断や失敗を、ひとつのファイルにひたすら追記していた時期があります。700行を超えたあたりで、確認したはずの判断が記録から数件、消えていることに気づきました。ファイルが大きくなりすぎ、AIが書き込む途中で止まっていたのです。この壊れ方は、冒頭の「同じ判断を何度も考え直す」感覚と地続きでした。読み切れない部分は静かに無視され、いちばん必要な判断がそこに眠っていることに、気づかないままになるのです。
判断や失敗を、小さな箱に入れておくだけにする
壊れた経験から作り直したのが、今の仕組みです。発想はシンプルで、書くときの作業を、できるだけ軽くすることに寄せました。
判断・失敗・セッションの記録は、それぞれ種類ごとに決めたID(判断ならDEC、失敗ならFAILといった接頭辞に連番をつけたもの)を持つ、小さなテキストファイルにします。1つの判断が1つのファイルに。1つの失敗が1つのファイルに。書いたら、それを未整理の箱にあたるフォルダにひとつ置くだけです。整理も分類も、書く瞬間にはしません。
加えて、会話の終わりには、自動でその回のやり取りを短くまとめたメモが1件生成される仕掛けも仕込んであります。手を動かさなくても、セッションの記録がひとつ、勝手に箱の中に増えている状態です。
ファイル名そのものを住所にしたのも工夫です。あとから別のメモの本文中にこの名前を書いておくだけで、「この判断はあの失敗を踏まえている」という関係が機械的に読み取れます。
実際のフォルダ構成はこうなっています。
memory/
├── inbox/ ← 未整理の箱。書いたらここに置くだけ
│ └── SESS-2026-08-01-e3c5a33d.md ← 会話の終わりに自動生成されたメモ
├── archive/2026/05/ ← 整理済みの棚(年/月)
│ ├── DEC-018.md
│ └── DEC-017.md ほか
└── .dream-db.sqlite ← 意味検索用のデータベース(1ファイル)判断のメモは、たとえばこんな中身になります。サムネの背景色をどの色に揃えるか、というくらい小さな判断でも、こうして1枚にしておきます(実際のメモの一部を省いています)。
---
id: DEC-018
type: decision
date: 2026-05-03
title: サムネイル背景色 #F5F2ED に統一
tags: [発信]
status: 採用
---
### Goal
サムネイルのシリーズ別カラー管理を見直す
### Options
- A: シリーズ別に異なる背景色
- B: 全シリーズ共通の背景色
### Decision
B：#F5F2ED に統一。
### Why
シリーズ間のトーン統一。管理が単純化される。冒頭の---で挟んだ部分(frontmatterと呼ばれるメタ情報)にID・種類・日付・タイトルを入れておくと、後で機械的に読み書きするときの足がかりになります。本文は「何を決めたかったか(Goal)」「選択肢(Options)」「決めたこと(Decision)」「理由(Why)」という見出しで書くようにしています。型を決めておくだけで、書く側も迷いませんし、後でAIが読むときも構造をあてにできます。
気づいた瞬間に、AIが裏側で記憶を整理する
箱にはどんどんメモが増えていきます。でも、増えるだけでは、覚えていることにはなりません。ここから、整理する仕組みの話に入ります。
溜まったメモを、AIが読みに行きます。まず短く要約します。次に、そのつながりを見つけるための準備として、文章を数値の並びに変換します。ここは少し分かりにくいところなので、一度立ち止まって説明します。
これはembedding(エンベディング)と呼ばれる仕組みです。文章をAIに読ませると、その意味を768個の数値の並びに変換してくれます。ポイントは、意味が近い文章ほど、数値の並びも近くなることです。たとえば「サムネの背景色をどうするか」という文章と、「画像の下地の色をどう揃えるか」という文章は、使っている言葉こそ違いますが、意味はほとんど同じです。この二つをembeddingに変換すると、その並びも近い場所に落ち着きます。逆に、話題自体が違う文章、たとえば「今日の夕食に何を作るか」であれば、数値の並びも遠くなります。だから、言葉が一致していなくても、意味で探し出せるのです。私はmultilingual-e5-baseという、無料で公開されている多言語モデルを手元のパソコンで動かしていて、この変換にお金はかかっていません。
数値の並びができたら、メモ同士につながりの線を引きます。本文中に別のメモの名前が書かれていれば機械的に張る確実な線と、意味が近い候補をAIに確認させてから張る線の二種類です。最後に、整理が終わったメモを、未整理の箱から整理済みの棚(アーカイブ)へ移します。
このバッチ処理にdreamという名前をつけました。人間が眠っている間に脳が記憶を整理する仕組みに、似せているからです。ただ、正直に書いておくと、実際に夜中に動いているわけではありません。セッションを開始した瞬間、未整理の箱に3件以上メモが溜まっていることに気づくと、裏側で整理のバッチが始まる作りにしています。書く作業はこちらの手が動いているときにやり、整理は気づかないあいだにAIが引き受ける形です。
一つ、断っておきたいことがあります。似た名前の機能が、最近Anthropic公式のほうにも登場しました。複数のセッションをまたいで記憶を統合整理する、ホスト側のベータ機能で、名前も同じく「Dreams」といいます。とはいえ名前も発想も似ているだけで、こちらは自分の手元で動かしている自作のバッチであり、公式機能とは別物です。眠りという比喩から名付けると、誰が考えても自然と同じ名前にたどり着くのだと思っています。偶然の一致で、真似たわけではありません。
整理済みの棚も、ひとつの形には寄せませんでした。元のテキストファイルはアーカイブとしてそのまま残し、それとは別に、要約や意味の指紋をまとめたデータベースも持たせています。ここも、順を追って説明します。
データベースといっても、大掛かりなものではありません。使っているのはSQLiteという道具で、サーバーを立てる必要がなく、1個のファイルだけで完結します。スマホのアプリの中でも普通に使われている、身近なものです。中身のテーブルは実質2つだけにしました。notesテーブルには、ID・種類・日付・タイトル・AIが書いた要約・本文・タグ・embedding(768個の数値をバイト列にして保存)が入っています。edgesテーブルには、どのメモからどのメモへ、線の種類(本文中のID参照か、意味の近さか)、線の強さ(重み)が入っています。
このデータベースをあとで探しものに使うときの検索も、素朴なやり方を選びました。質問文と、溜まっている全部のメモの近さを、1件ずつ順番に計算していくだけ。総当たりと呼ばれる方法です。凝った検索の仕組みを組む必要はなく、数百件くらいの規模なら、これで一瞬で終わります。
データベースだけに寄せると、壊れたときにすべての記録を失ってしまいます。それを避けるため、テキストファイルさえ残っていればデータベースは作り直せる、という二重構えにしています。
思い出す、を機械の中に作る
整理された記録は、まだ「思い出せる」わけではありません。ここが、いちばん時間をかけた部分です。
最初に考えたのは、今の話題に意味が近いメモを、スコアが高い順に何件か持ってくる、という単純な検索でした。ある程度は機能します。ただ、意味の近さだけを追いかけると、言葉の上ではそれほど似ていないのに話の筋としてつながっている判断を、拾いそこねてしまいます。
今のやり方は、知り合いを辿るように作り直しました。段階を追って説明します。
①まず、今の話題を書いた質問文も、さっきのembeddingで数値の並びに変換します。そのうえで、いちばん意味が近いメモ(コサイン類似度が0.75以上のもの。なければいちばん近い1件だけ)を、話の「入口」にします。
②そこから、その入口の知り合い、つまり線でつながっている別のメモへと、1本ずつ辿って範囲を広げていきます。知り合いの、そのまた知り合いへと、輪が少しずつ広がっていくイメージです。
③ただし、1本辿るごとに、関連の強さ(活性度)に0.7という重みを掛けます。知り合いの知り合いは、本人ほど親しくない、というのに近い感覚です。だから、遠くまで辿るほど、関連は弱まっていきます。
④弱くなりすぎた枝は、そこで止めます。親の活性度の6割を下回った枝は、その先を辿りません。全員を律儀に訪ね歩くのではなく、薄くなった縁はそこで打ち切る形です。持ち帰る総量そのものにも、トークン予算で上限を設けています。
⑤持ち帰るときも、全員を同じ扱いにはしません。活性度が0.7を超えるメモは全文をそのまま渡し、0.4〜0.7のメモは要約だけ、それ以下は題名だけを渡します。近い知り合いほど詳しく、遠い知り合いほど名前だけ、という濃淡です。
さらに、こちらから聞かなくても、会話のたびに関連しそうな記録が自動で差し出される仕掛けも仕込んであります。フックという仕組みで、発話のたびに裏側で今の話題と意味が近いメモを照会し、見つかれば横から差し出します。この照会をそのつど新しく立ち上げると、AIのモデルを読み込むだけで10秒近くかかってしまうので、モデルを読み込んだ状態のまま裏側に常駐させ、瞬時に答えを返す形にしています。
たとえば「サムネの背景色はどの色に揃えるか」と話しかけると、3ヶ月ほど前のこの判断が横から差し出されます。actは活性度、simは意味の近さの点数で、活性度が高かったので中身まで添えられています(出力は一部省略しています)。
🟢 入口
├─ [DEC-018] act:0.87 (sim:0.87)
│ ### Goal サムネイルのシリーズ別カラー管...記録は、整理されて初めて記憶になる。思い出せて初めて、記憶は資産になる。
完璧じゃない。それでも、ここから始められる
ここまでの話を、都合よく仕上がった話として書きたくはありません。要約が実態とずれることは今もありますし、関連が薄いメモ同士に線が引かれてしまうこともあります。枝を打ち切る設計にしている以上、本当はもう少し先まで辿れば見つかったはずの記録を、途中で見失う場合もあります。それでも、記録をひとつのファイルに溜め続けて壊れ、必要なときに何も出てこなかった頃と比べれば、記録は判断の材料としてちゃんと戻ってくるようになりました。
あなたが今すぐ同じものを丸ごと作る必要はないと思います。むしろ、階段を一段ずつ上るくらいでちょうどいいはずです。
最初の一段は、記録を1件1ファイルで残すことです。次の一段は、ファイル名と見出しをあらかじめ決めておくこと。「何の記録か」「いつのものか」がひと目でわかるだけで、後から探しやすくなります。最後の一段は、AIに「関連しそうな過去のメモを探して」と一度頼んでみることです。この三段は、どれも今日中に終えられます。
必要なのは、決まった形のテキストファイルと、SQLiteのような単純なデータベースと、無料の埋め込みモデルと、一定のタイミングで整理を走らせる仕掛け(フックでも、手動実行でもいい)の4つだけです。どれも特別な道具ではありません。
以前の記事で、判断を記録に残すルールを入れてから、AIの自走のペースはむしろ上がったと書きました。記録がただ増えるだけでは、その効果は出なかったはずです。増えた記録を、AIが整理して、必要なときに自分から差し出してくれるようになって初めて、記録は資産に変わりました。
あなたが今書き留めている記録は、必要なときにちゃんと戻ってきているでしょうか。もしまだなら、今日の一段目から、一緒に始めてみませんか。
AIに複数の役割を渡して動かし、3つの失敗から今の運用ルールができるまでの話は、こちらに書きました。
ハーネス設計そのものの定義と、部品表を並べた記事はこちらです。
