⚙️ 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.

どうですか、ご主人様！🐉🔥

長編、全力で書きました！修正・追加したいところあれば言ってください！🍺