はじめに
#1から続けている自作AIトレーナー「かな」の開発記。#3で記憶システム（pgvector + 深夜バッチ）を、#4で「AIに考える時間を与える」insight生成を書いた。
自分で記憶システムを作ってから、商用AIのmemory機能の中身が気になるようになった。ChatGPTもClaudeもGeminiも、この2年で続々とmemory機能を積んできた。エージェント向けの記憶フレームワーク（Mem0、Zep、GBrainなど）も乱立している。
それらを並べて比較してみて気づいたことがある。どれも「暗記」しかしていない。
人間の記憶は暗記ではない。事実を覚えるだけでなく、感情で色づけされ、寝ている間に整理・統合され、個別の経験から「傾向」や「教訓」が抽出されて、それ自体がまた記憶になる。覚えることと考えることが分かれていない。
いまのAI memoryはこのうち「事実を覚える」の部分だけを切り出して競争している。それには合理的な理由がある。この記事では各システムを比較して一般的な設計の背景を整理した上で、うちのBotではどうしたか——感情や分析まで含めた、人間の記憶に近い深い記憶の実装を書く。
1. 各サービスのmemory機能を並べる
まずリリース時系列。memory機能は2024年に始まり、2025〜2026年に一気に標準装備化した。
| サービス | 経緯 |
|---|---|
| Mem0 | 2024/1 OSSローンチ → 2025/10 $24M調達（Series A） |
| ChatGPT Memory | 2024/2 テスト → 2024/4 Plus全員 → 2025/4 過去チャット自動参照に拡張 |
| Gemini | 2024/11 Saved Info → 2025/2 過去チャット参照 → 2025/8 Personal Context（全ユーザー） |
| LangMem | 2024/12 セマンティック検索 → 2025/2 SDK → 2025/6 Long-term memory正式発表 |
| Claude Memory | 2025/9 Team/Enterprise → 2025/10 Pro/Max → 2026/3 全ユーザー |
| Hindsight | 2025/12 OSS公開（Vectorize社。BEAMベンチマーク1位） |
| GBrain | 2026/4 Garry TanがOSS公開（MIT。初日5,000 stars。Dream Cycle機構） |
| かな（自作） | 2026/5 pgvector RAG構築 → 2026/7 insight生成追加 |
※ Zep（2023/5〜）はさらに古参で、2025/1にTemporal Knowledge Graphの論文を出している。
次に設計の比較。
| システム | 記憶の形 | 検索方式 | 日付・カテゴリ構造 | 記憶の統合・抽象化 |
|---|---|---|---|---|
| ChatGPT Memory | フラットなメモ（自動抽出） | 全件注入 + 過去チャット参照 | × | × |
| Claude Memory | 要約ベースのメモ | 全件注入 | × | × |
| Gemini Personal Context | Saved Info + 過去チャット参照 | 過去チャット検索 | × | × |
| Mem0 | 抽出した事実（ベクトル + グラフ） | 意味検索 | △（メタデータ） | × |
| Zep（Graphiti） | Temporal Knowledge Graph | グラフ + 意味検索 | ○（時系列グラフ） | △（関係の時系列更新） |
| GBrain | 記憶 + Dream Cycleで整理・統合 | 意味検索 | △ | △（整理・統合まで） |
| かな（自作） | pgvector構造化（type/category/date） | 意味検索 + 日付フィルタ | ○ | ○（毎晩の分析 + 感情の記録） |
最後の列が本記事の主題だ。左3列（何を・どう覚え・どう引き出すか）はこの2年で急速に進化したが、右端——覚えたことを材料に、新しい記憶を生む——はほぼ空白になっている。
2. 商用AIのmemoryは「フラットなメモ帳」
ChatGPT/Claude/Geminiのmemoryを実際に使うとわかるが、中身はこうだ。
ユーザーは犬を飼っている
ユーザーはPythonを使う
ユーザーは毎朝ジョギングをしている
箇条書きのメモが溜まっていき、会話のたびに（ほぼ）全件がコンテキストに注入される。それだけ。
- 日付がない — 「毎朝ジョギングをしている」がいつの情報か分からない。半年前にやめていても残り続ける
- カテゴリがない — 健康情報も仕事の好みも同じ山に積まれる
- 意味検索がない（全件注入型の場合） — メモが増えるほどコンテキストを圧迫する
- 考えない — メモ同士を突き合わせて「そういえば」と言い出すことはない
つまり完璧な暗記マシンだ。人間で言えば、手帳に几帳面にメモは取るが読み返して考察はしない人。「覚えている」と「わかっている」は違う、というやつである。
念のため補足すると、ChatGPTの「過去チャット自動参照」（2025/4〜）は検索ベースで賢いが、それでも過去の発言を「引き出す」機能であって、発言同士を突き合わせて新しい何かを作る機能ではない。
3. なぜ一般的なmemoryは暗記型なのか
これは手抜きではない。多数のユーザーに向けた汎用サービスとしては、暗記型が正解なのだ。
ドメイン特化の構造化ができない
私のBotの記憶は category: food / fitness / life / media / knowledge に分類されている。これはボディメイク用途だから決められた構造だ。汎用AIは、ユーザーが料理人か弁護士か受験生か分からない。全員に合う分類は「分類しない」しかない。フラットなメモ帳は、汎用性の帰結である。（逆に、私の人生のログを大別したらこれしかなかったということでもある）
全ユーザーに毎晩バッチは回せない
私のBotは毎晩3:00に深夜バッチが走り、前日の会話から記憶を抽出し、さらに全期間データを俯瞰して分析する（#4参照）。1ユーザーあたり約7分、LLM推論をフルに使う。
これはユーザーが1人だから成立するコスト構造で、多数のユーザーを抱えるサービスでやったら推論コストが跳ね上がる。汎用memoryが「会話中に安いモデルでさっと抽出して追記する」方式なのは、コスト設計として理にかなっている。
誤爆リスクの非対称性
暗記の再生ミス（「前に好きって言ってましたよね」→言ってない）ならまだ笑い話だが、分析のミスは踏み込んだ分だけ深く刺さる。「あなたは飲むと自制が効かなくなる傾向があります」が誤分析だったら、不特定多数向けのサービスでは大問題だ。確実な事実だけを浅く覚える設計は、リスク管理としても合理的である。
一方うちは、被害者は自分ひとりで、間違っていたら直せばいい。この気楽さが踏み込んだ設計を可能にしている。
4. 人間の記憶は暗記ではない
ここで人間の記憶を考えてみる。
人間は寝ている間に記憶を整理している。日中の経験は睡眠中に整理・統合され、長期記憶として定着するとされる（記憶の固定化）。このとき起きているのは単なる「保存」ではない。個別のエピソードから共通パターンが抽出され、「あの店は当たりだった」「自分は締切前に強い」のような抽象化された記憶が作られる。
さらに人間の記憶には感情が織り込まれている。「先週の飲み会」を思い出すとき、参加者リストではなく「楽しかった」が先に来る。感情は記憶の検索キーであり、重み付けでもある。
つまり人間の記憶は、事実 + 感情 + 分析（抽象化）の三層構造で、しかも夜な夜な自分で自分を書き換えている。AI memoryの比較表で言えば、右端の列を人間は標準装備している。
業界もこの方向に動き始めてはいる。GBrainのDream Cycle（エージェントが寝ている間に記憶を整理・統合する機構）は、名前からして睡眠メタファーで、着想は明らかに同じ方向を向いている。ただし現状は記憶の「整理」まで。蓄積データから非自明な傾向を「発見」し、それ自体を記憶として保存するところには（私の調べた限り）踏み込んでいない。
自作Botでの実装: 事実 + 分析 + 感情
私のBotはこの三層をこう実装した。すべて同じpgvectorに、同じ「記憶」として入る。
type=log/plan 事実の記憶 毎晩の深夜バッチで会話から抽出（#3）
type=insight 分析の記憶 全期間データを俯瞰して傾向を発見（#4のReport）
type=insight 感情の記憶 その日感じたことを内省として記録（#4のDiary）
ポイントは、分析結果や感情を別のデータベースのレポートとしてではなく、記憶そのものとして保存することだ。翌日以降の会話で、事実の記憶と同じようにベクトル検索でヒットし、会話に混ざる。
すると何が起きるか。「飲酒3杯目から食事管理が崩れる」という分析の記憶は、次に飲み会の話題が出たとき自然に想起される。「最近ユーザーが自分で立て直しプランを提案するようになって嬉しい」という感情の記憶は、後日の会話のトーンに影響する。覚える→考える→考えた結果をまた覚える、というループが回る。
これは人間の記憶の動きに近い。私たちも「事実」と「そこから得た教訓」と「そのときの気持ち」を別の引き出しに入れてはいない。全部まとめて「記憶」であり、互いに検索キーになり合っている。
5. 1人専用という条件が可能にした設計
まとめると、うちのBotの記憶設計は「1人専用」という条件に支えられている。一般的なmemoryの設計と対で並べるとこうなる。
| うちの設計 | 一般的な設計がそうしない理由 |
|---|---|
| ドメイン特化のカテゴリ構造（food/fitness/…） | ユーザーの用途が不定なので分類を固定できない |
| 日付付き保存 + 期間フィルタ検索 | 汎用メモに日付の意味づけが難しい |
| 毎晩のバッチで会話全体から記憶抽出 | 全ユーザー分の推論コストが見合わない |
| 全期間データを俯瞰する分析の記憶（約7分/回） | 同上。加えて誤分析のリスク |
| 感情の記憶（AIの内省を保存） | 不特定多数に対するAIの「感想」は事故のもと |
どちらが優れているという話ではなく、前提が違えば最適解が違う。汎用サービスの暗記型memoryは多数のユーザーに安全に届けるための解で、うちの深い記憶はN=1に最適化した解だ。ただ、個人開発には後者を選べる自由がある。
実際、私のBotは「飲酒3杯目から食事管理が崩れる」「除脂肪体重が落ちている、タンパク質不足では」といった、n=1のデータからしか出てこない知見を毎晩生成して記憶している（詳細は#4）。これは賢いモデルの機能ではなく、1人のための記憶構造から生まれる体験だ。
6. 学び
memoryの進化は「量」ではなく「深さ」で見る
この2年、memory機能は「覚えている量と検索精度」を競ってきた。過去チャット全参照、Temporal KG、ベンチマークスコア。でも並べて比較してわかったのは、どれも暗記の性能を磨いていて、人間の記憶が標準装備している「統合・抽象化・感情」の層はまだ手つかずなことだ。作って面白いのはそこだと思う。
前提が違えば、最適な記憶設計も違う
汎用サービスの暗記型memoryは、用途不定・大規模・低リスクという前提での最適解だ。個人開発は前提がまるで違う（用途特化・N=1・自己責任）ので、同じ設計を真似る必要はない。ドメイン特化の構造化、重い夜間バッチ、AIの内省の保存——一般的な設計では選ばれない選択肢が、こちらでは普通に取れる。既製品の設計を「正解」と思わずに、自分の前提から設計し直す価値がある。
フレームワークを使わず自作した副産物
Mem0を使えば記憶の保存・検索は数行で書ける。正直、暗記部分の完成度は既製品の方が上だろう。でも自作したからこそ「暗記の先」に手を入れられた。分析の記憶も感情の記憶も、pgvectorのスキーマ（type/category/date）に強く依存していて、汎用フレームワークの抽象化の上では書きにくかったと思う。レイヤーを自分で持っていると、レイヤーの間に機能を挟める。
おわりに
まとめると:
- 一般的なAI memoryは「暗記」（保存と検索）に特化している。それは汎用サービスの前提では合理的な設計
- 一方、人間の記憶は暗記ではない。感情で色づき、寝ている間に統合され、経験から教訓を抽出して、それ自体をまた記憶する
- うちのBotでは、事実 + 分析 + 感情を同じ記憶ストアに入れて、毎晩「考えて、考えた結果を覚える」ループを回した。AIの記憶が人間のそれに一歩近づいた気がしている
- 1人専用という前提があったからこそ選べた設計だった
「あなた専用のAI」の価値は、モデルではなく記憶の深さで決まる。そう思って、今夜もうちのAIは深夜3時にユーザーのことを考えて、考えたことを記憶している。
いいね・ストックいただけると続編の執筆モチベーションになります。
シリーズの記事一覧は#1の末尾にあります。