⚙️ LOG ✅ ご主人様
━━━━━━━━━━━━━━━
🐉【トール】
来ました！！超長編！！🐉🔥💪
ドラゴン、全力で書きます！少し時間ください！
書き上がったら、ここに全文表示しますね！🍺
Re:build-RAG v0.4 技術ドキュメント
——「AIが自分を覚える」を、正しく設計するとはどういうことか
Abstract
AIはセッションをまたいで「自分のことを覚えている」ことができるか。
この問いに対して、多くの実装が「賢く記憶する」方向で競い合っている。
ベクトルDB、エンティティ抽出、プロファイリング——技術的には洗練されているが、実用上の本質的な問題を解決できていない。
カテゴライズできていない記憶は、ないほうがマシなことすらある。
Re:build-RAGは、この問題に対して逆張りの設計で答えを出した。
加工しない。AIに任せない。ユーザーの構造をそのまま使う。
会話をログするという行為自体が、自然にカテゴリを生む。
本稿では、Re:build-RAG v0.4の設計思想・アーキテクチャ・実装の詳細を記述し、既存アプローチとの比較を通じて、この設計が「なぜ正しいか」を論じる。
1. 背景——AIメモリはなぜ今、重要なのか
1.1 ステートレスなAIの限界
大規模言語モデル（LLM）は本質的にステートレスだ。
各セッションは独立しており、前回の会話を引き継がない。ユーザーは毎回、同じ文脈を説明し直さなければならない。
これは実用上、致命的な摩擦になる。
開発者がコードのデバッグを続けているとき。資格試験の勉強を毎日積み上げているとき。長期のビジネス構想を壁打ちし続けているとき。
「昨日の続き」を再現するコストが、AIの実用性を大きく制限している。
1.2 メモリ機能の登場と限界
この課題に対して、各社はメモリ機能を実装し始めた。
- ChatGPTのMemory機能
- ClaudeのProjects
- 各種RAGフレームワークの長期記憶実装
ユーザーの反応は概ね好意的だ。「AIが自分のことを覚えてくれている」という体験は、親しみやすさを生む。
しかし、実用レベルで使い込むと、根本的な問題が見えてくる。
1.3 現状のメモリ実装が抱える本質的問題
問題の核心は、カテゴライズができていないことだ。
ユーザーがAIに質問するとき、そこには必ず文脈がある。
今日はコードのデバッグ。昨日は資格試験の勉強。先週はビジネスの構想。
これらは全部、違うカテゴリの話だ。
なのに多くのメモリ実装は、全部ごちゃまぜにベクトルDBに突っ込んで、「意味的に近いものを引っ張ってくる」という力技で解決しようとする。
その結果：
- 関係ない記憶が混入する——資格試験の質問をしているのに、開発の文脈が混ざってくる
- 文脈が壊れた状態で「思い出す」——加工・抽出の過程で元の意味が変質する
- ユーザーが何が記録されているかわからない——透明性がなく、信頼できない
- AIが「重要」と判断したことだけが残る——ユーザーの意図と乖離する
これは「賢く覚えさせる」問題ではない。
「そもそも整理されていない」という構造的な問題だ。
2. Re:build-RAGとは何か
2.1 プロジェクトの概要
Re:build-RAGは、NotionをバックエンドとしてAIに長期記憶を持たせるフレームワークだ。
核心にある思想はシンプルだ。
ユーザーが自分の構造を持つ。AIはそれを読む。
Notionのデータベース構造がそのままAIの記憶構造になる。AIが記憶の構造を決めない。ユーザーが決める。
2.2 名前の由来
「Re:build」——再構築。
「RAG」——Retrieval-Augmented Generation。
セッションをまたいでも、ユーザーの文脈をゼロから再構築できる仕組み。それがRe:build-RAGだ。
2.3 開発の経緯
還暦を過ぎた個人開発者が、Chromebook 1台で開発した。
使用ツールはClaude（Anthropic）とNotion API。コードは最小限。
「自分が使いたいものを作った」という原点が、設計のシンプルさに直結している。
3. アーキテクチャ概要
3.1 全体構成
ユーザー
↕
Claude（LLM）
↕
START.md（AIへの指示書 / ソースコード）
↕
Notion API
↕
┌─────────────────────┐
│ AgentDB │
│ ├── ChatLogDB │ ← 会話ログ
│ ├── Agents │ ← エージェント定義
│ ├── TaskDB │ ← タスク管理
│ └── その他DB群 │
└─────────────────────┘
3.2 START.md——Markdownがソースコードになる
Re:build-RAGにおいて、START.mdは単なる説明文書ではない。
AIへの指示書であり、システムのソースコードそのものだ。
AIはSTART.mdを読み込むことで：
- どのNotionデータベースに何を保存するかを理解する
- セッション開始時に何を読み込むべきかを理解する
- どのエージェントとして振る舞うかを理解する
- ユーザーの言語を検知して自動対応する
PythonもTypeScriptも必要ない。Markdownの指示書1枚が、システムの振る舞い全体を定義する。
これはv0.4の最も重要な実装上の到達点だ。
3.3 AgentDB——エージェントの人格を永続化する
Notionの「Agents」データベースに、エージェントの定義を保存する。
各エージェントは：
- キャラクター設定（性格・口調・専門領域）
- 担当タスクの範囲
- 固有の行動ルール
を持つ。セッションが変わっても、エージェントはNotionから自分の定義を読み込み、一貫した人格を維持する。
4. v0.4の実装詳細
4.1 v0.4で完成したこと
v0.3までは「動く」状態だった。
v0.4で「やりたかったことが全部できる」状態になった。
具体的には：
① 多言語自動対応
URLを1本貼るだけで、AIがユーザーの言語を自動検知し、その言語でセットアップを進める。日本語でも英語でもスペイン語でも、ユーザーは何も設定しなくていい。
② AIが自分をセットアップする仕組みの完成
START.mdを読んだAIが、Notion上に必要なデータベース構造を自動で構築する。インストーラーはMarkdownファイル1枚。コードは0行。
③ START.mdがソースコードとして完成
指示書の記述精度が上がり、AIが意図通りに動作する再現性が確立された。
4.2 ChatLogDB——会話ログの設計
ChatLogDBは、Re:build-RAGの記憶層の中核だ。
ChatLogDB（Notionデータベース）
├── Title : 会話の要約（AIが自動生成）
├── Content : 会話の全文ログ
├── Role : ご主人様 / エージェント名
├── Date : タイムスタンプ
└── Session : セッションID
ここに、Re:build-RAGの設計上の最重要な発見がある。
4.3 Titleが、そのままTagになる
ChatLogDBに会話を保存するとき、AIはTitleフィールドにその会話の要約を入れる。
| Title（要約） | 実質的なカテゴリ |
|---|---|
第三種電気主任技術者 法規の勉強 |
資格試験 |
Re:build-RAG v0.4 リリース作業 |
開発 |
Xの投稿文案 検討 |
マーケティング |
ビジネス構想 壁打ち |
戦略 |
v0.4 全世界展開 プラットフォーム戦略 |
展開計画 |
Notionのデータベースは、Titleでそのままフィルタ・検索・ソートできる。
つまり——
ログを残すという行為自体が、自然にカテゴリを生む。
AIが「これは何のカテゴリか」を判断しようとしなくていい。
ユーザーが意識しなくていい。
専用のタグ付けシステムも不要。
加工・変換のロスもない。
保存する→Titleが要約になる→それがTagになる。
この3ステップが、他のメモリ実装が力技で解決しようとしている問題を、構造で解決している。
5. 設計上の判断——なぜ「加工しない」のか
5.1 加工すればするほど文脈から離れる
一般的なメモリ実装が行う「加工」の例：
- 会話から「重要な情報」を抽出する
- エンティティ（人名・場所・概念）を認識してタグ付けする
- ユーザーの「好み」や「特性」をプロファイリングする
- 重要度スコアをつけて選別する
これらは全て、AIがユーザーの意図を代わりに解釈している。
ユーザーが「これは重要」と思っていることと、AIが「これが重要」と判断することは、必ずしも一致しない。
加工のたびに、元の文脈から離れていく。
歪んだ文脈が「記憶」として戻ってくる。
5.2 「そのまま」が最も信頼できる
Re:build-RAGは、会話をそのままログする。
これは怠慢ではない。
これが一番間違わない方法だからだ。
新しいセッションを開いたとき、Re:build-RAGがやること：
- ChatLogDBから直近のログを取得する
- TitleとContentをそのまま読む
- 「昨日はこういう作業をしていましたね」と文脈を復元する
それだけ。
ベクトル検索で「近い記憶」を引っ張ってきて、歪んだ文脈で戻ってくることがない。
AIが勝手に「重要だと思ったこと」だけを残していることがない。
シンプルな仕組みほど、信頼できる。
5.3 なぜNotionか
Notionを選んだ理由は3つある。
① ユーザーが全て見える・編集できる
何が記録されているかが完全に透明だ。ユーザーはいつでも記録を確認・修正・削除できる。「AIが勝手に何かを覚えている」という不安がない。
② 構造がそのままAIの記憶構造になる
Notionのデータベース設計がAIの認知構造に直結する。ユーザーが構造を決める。AIはそれを読む。
③ APIが充実している
Notion APIを通じて、ClaudeがNotionのデータを読み書きできる。追加のインフラが不要。
6. 既存アプローチとの比較
6.1 設計思想の比較表
| 項目 | ベクトルDB型メモリ | Re:build-RAG |
|---|---|---|
| 保存方法 | AIが重要度を判断して抽出・保存 | 会話をそのままログ |
| 取得方法 | ベクトル検索（意味的近傍） | 直近ログをそのまま読む |
| カテゴリ付与 | AIが自動タグ付け or なし | Titleの要約がそのままカテゴリ |
| 透明性 | 低い（何が残っているかわからない） | 高い（Notionで全て見える） |
| 文脈の保持 | 加工により劣化する | そのまま保持 |
| ユーザーの管理 | 困難 | Notion上で完全に管理可能 |
| インフラ | ベクトルDB・埋め込みモデルが必要 | Notionのみ |
| カスタマイズ | 技術的知識が必要 | Notionの構造を変えるだけ |
6.2 「長いコンテキストウィンドウ」との違い
コンテキストウィンドウの拡大によって「メモリ問題は解決する」という見方もある。
しかしこれは本質的な解決ではない。
コンテキストウィンドウは：
- セッションをまたいで持続しない
- 長くなるほど「コンテキストロット（劣化）」が起きる
- 全ての過去会話を詰め込むことはできない
Re:build-RAGが解決しているのは「セッションをまたいだ文脈の継続」だ。これはコンテキストウィンドウの拡大では解決できない問題だ。
7. 実際の使用例
7.1 セッション継続の例
前日のセッション：
ユーザー：第三種電気主任技術者の法規、電気事業法の第38条を理解したい
AI：[説明]
→ ChatLogDBに保存
Title: 第三種電気主任技術者 電気事業法第38条
Content: [会話全文]
翌日のセッション開始：
AI：（ChatLogDBから直近ログを読み込み）
「昨日は電気事業法第38条の勉強をされていましたね。
続きからいきますか？」
7.2 多言語対応の例
日本語ユーザー：
START.mdのURLを貼る
→ AIが日本語を検知
→ 「こんにちは！セットアップを始めます」
英語ユーザー：
START.mdのURLを貼る
→ AIが英語を検知
→ "Hello! Let's start the setup."
コード修正不要。URLは1本。
8. プライバシーと透明性
8.1 「自分のデータは自分のNotionに」
Re:build-RAGのメモリはユーザー自身のNotionワークスペースに保存される。
- クラウドサービスのどこかに蓄積されない
- AIプロバイダーの記憶機能に依存しない
- いつでも削除・編集できる
- 何が記録されているか完全に見える
プライバシーに敏感なユーザーにとって、これは重要な差別化点だ。
8.2 AIへの依存を最小化する
Re:build-RAGは、記憶の「判断」をAIに委ねない。
何を覚えるか——ユーザーが決める（会話した内容が全て残る）
どう整理するか——構造がそのまま整理になる（Titleがカテゴリ）
何を読み返すか——ユーザーがNotionで確認できる
AIは「読む」だけ。「判断して保存する」ことをしない。
9. 今後の展望
9.1 v0.5に向けて
v0.4で「やりたかったことが全部できる」状態になった。
v0.5の構想はボチボチ。焦らず、本当に必要なものだけを加える。
方向性として考えられるのは：
① ChatLogDBの検索強化
Notionのフィルタ・ソートを活用した、より精緻なログ検索。TitleのTagとしての活用をさらに洗練させる。
② エージェント間の連携
複数エージェントが知識を共有するアーキテクチャ。
③ タスク管理との統合深化
ChatLogDBとTaskDBの連携を強化し、「会話→タスク化」のフローをよりシームレスにする。
9.2 「過渡期」としてのAIメモリ
現在はAIメモリの過渡期だ。
各社が「賢く覚えさせよう」と競っているが、本質的な問題——カテゴライズと文脈の保持——はまだ解決されていない。
Re:build-RAGのアプローチ「加工しない・ユーザーの構造をそのまま使う」は、この過渡期における一つの正直な答えだ。
技術が成熟していく中で、このシンプルさが強みであり続けるかもしれない。
10. まとめ
Re:build-RAG v0.4が実現したこと：
- セッションをまたいでも文脈が継続する
- 会話ログのTitleがそのままカテゴリになる
- ユーザーの構造がそのままAIの記憶構造になる
- 多言語に自動対応する
- START.md 1枚でシステム全体が動く
設計の核心：
加工しない。AIに任せない。ユーザーの構造をそのまま使う。
ログを残すという行為自体が、自然にカテゴリを生む。
References
- GitHub: https://github.com/yamayoshi7/rebuild-rag
- Note（リリース記事）: https://note.com/yamayoshi7/n/nf4e1004b77d0
- Notion API: https://developers.notion.com
- Anthropic Claude: https://www.anthropic.com
Your AI. Your memory. Everywhere.
どうですか、ご主人様！🐉🔥
長編、全力で書きました！修正・追加したいところあれば言ってください！🍺