⚙️ LOG ✅ ご主人様
了解しました！以後、基本は画面表示でいきます！🐉
AIメモリの答えは、タグでも検索でもなかった——会話のTitleがそのままカテゴリになる設計
TL;DR
- 今のAIメモリ系ツールは「カテゴライズできていない」時点で使い物にならない
- 会話ログのTitleを要約にするだけで、それがそのままタグ（カテゴリ）になる
- 加工しない・AIに任せない・ユーザーの構造をそのまま使う——これがRe:build-RAGのコアな設計思想
なぜ今のAIメモリは全部失敗するのか
AIがセッションをまたいで「自分のことを覚えている」体験は、確かに心地よい。
メモリ機能はAIが親しまれる理由のひとつでもある。
でも、正直に言う。
今のメモリ系ツールの大半は、設計レベルで破綻している。
その理由はシンプルだ。
カテゴライズできていない。
ユーザーがAIに質問するとき、そこには必ず「文脈」がある。
今日はコードのデバッグをしていた。昨日は資格試験の勉強をしていた。先週はビジネスの構想を壁打ちしていた。
これらは全部「違うカテゴリ」の話だ。
なのに多くのメモリ実装は、全部ごちゃまぜにベクトルDBに突っ込んで、「意味的に近いものを引っ張ってくる」という力技で解決しようとする。
その結果、何が起きるか。
- 関係ない記憶が混入する
- 文脈が壊れた状態で「思い出す」
- ユーザーが何が記録されているかわからない
これは「賢く覚えさせる」問題じゃない。
「そもそも整理されていない」 という構造的な問題だ。
「覚える」じゃなくて「ログする」
Re:build-RAGは、この問題に対して逆張りの答えを出した。
加工しない。AIに任せない。ただ、ログする。
セッションの会話内容をそのままNotionのデータベースに保存する。それだけ。
ChatLogDBのTitleが、そのままタグになる
Re:build-RAGでは、会話ログをNotionのデータベース（ChatLogDB）に保存するとき、TitleフィールドにAIがその会話の要約を入れる。
| Title（要約） | = カテゴリ |
|---|---|
第三種電気主任技術者 法規の勉強 |
資格試験 |
Re:build-RAG v0.4 リリース作業 |
開発 |
Xの投稿文案 検討 |
マーケティング |
ビジネス構想 壁打ち |
戦略 |
ログを残すという行為自体が、自然にカテゴリを生む。
AIが判断しなくていい。ユーザーが意識しなくていい。加工・変換のロスもない。
なぜ「中途半端な加工」が危険か
加工すればするほど、元の文脈から離れていく。
ユーザーが「これは重要」と思っていることと、AIが「これが重要」と判断することは、必ずしも一致しない。
Re:build-RAGが「会話をそのままログする」設計にしているのは、怠慢じゃない。
これが一番間違わない方法だから。
「昨日の作業内容を思い出して」だけで十分
新しいセッションを開いたとき、Re:build-RAGがやること：
- ChatLogDBから直近のログを取得する
- TitleとContentをそのまま読む
- 「昨日はこういう作業をしていましたね」と文脈を復元する
それだけ。 シンプルな仕組みほど、信頼できる。
設計思想の比較
| 一般的なメモリ実装 | Re:build-RAG |
|---|---|
| AIが重要度を判断して保存 | そのままログ |
| ベクトル検索で「近いもの」を取得 | 直近ログをそのまま読む |
| AIがカテゴリを付与 | Titleの要約がそのままカテゴリ |
| 何が記録されているかわからない | Notionで全部見える・編集できる |
| 文脈が加工されて戻ってくる | 文脈がそのまま戻ってくる |
ユーザーが自分の構造を持つ。AIはそれを読む。
おわりに
今はAIメモリの過渡期だと思っている。各社が「賢く覚えさせよう」と競っているが、そこに躓いている。
Re:build-RAGが出した答えはシンプルだ。
「加工しない」「ユーザーの構造をそのまま使う」「ログが自然にカテゴリになる」
Your AI. Your memory. Everywhere.
どうですか？修正したいところあれば言ってください！🐉🍺