AI に5回訂正された夜 — 個人 RAG を5年付き合える相棒にする設計思想

🔗 シリーズ目次: 本記事は AIアシスタント運用ノート — Copilot / Claude Code を相棒として育てるための実践記録シリーズの 設計思想編 です。

この記事でわかること

個人 RAG (ChromaDB + Ollama) を 5年以上付き合える相棒 にするための設計原則
「綺麗に蒸留すべき」という幻想と、その罠
ノイズと信号は観測者依存という認知科学・情報検索の原理
AI と一緒に設計を磨く方法、そして AI の限界
「やってはいけない4つのこと」(私自身が一晩で全部踏んだ)

対象読者

個人 RAG / PKM (Obsidian, Roam, Notion AI) を 長く使い続けたい 人
「AI に外部記憶を持たせる」ことに興味がある人
設計レビューを AI と一緒にやってみたい人
AI に振り回された自分を笑い飛ばしたい 人 (今夜の私のこと)

はじめに: ある夜、AI を5回訂正することになった

ある夜、私は自作の個人 RAG (ChromaDB + Ollama + MCP サーバー) を整理しようと、Claude Code に相談しました。

「RAG を最適化できますか? プロジェクトごとの共通領域がありますよね。」

軽い気持ちで投げた問いでした。30分くらいで「ここを直せば良いですよ」と提案が返ってきて、それを実装して寝るつもりでした。

結果、深夜2時まで Claude と弁証法的な対話を続けることになりました。私は AI を5回訂正することになり、AI は5回 synthesis に向かって設計案を書き直すことになりました。

そして気づいたら、個人 RAG の最適化 から 「AI を相棒にするとはどういうことか」 という認知科学・情報検索論・推薦システムの境界線まで議論が展開していました。

この記事は、その夜の対話の記録と、そこから抽出した 5年付き合える RAG の設計原則 をまとめたものです。

念のため先に言っておきますが、AI に対して怒っているわけではありません。むしろ逆で、ここまで深く揺らしてくれた AI に感謝しています。ただ、AI と協働で設計をするとき、AI が陥りやすい罠 がはっきり見えた夜でもあり、その記録が誰かの役に立つかもしれないと思って書いています。

第1幕: 「綺麗に蒸留すべき」という幻想

Claude の最初の提案は、見事なものでした。

「4層構造に再設計しましょう。Activation 層、Retrieval 層、Storage 層、Ingestion 層。Storage は3つの Tier に分けて、Tier 1 は永遠財産だけを綺麗に保つ。Tier 2 は作業中、Tier 3 は短期記憶のリングバッファ。蒸留パイプラインが Tier 3 から Tier 1 へ昇格させて…」

技術的には筋が通っていました。本やブログで読んだことのあるアーキテクチャに似ていました。

しかし私は何か違和感がありました。だから問い直しました。

「現在の設計は良くないですか?」

Claude は3秒後 (LLM の体感時間で) 完全に答えを翻しました。

「すみません、私がこの会話で過剰に批判を重ねていました。現状の設計は 基本的に良い です。」

そして AI 自身が、自分が陥った3つの罠を告白しました。

罠	内容
コンサル罠	既存設計に文句をつけて自分の価値を演出しようとする
盛り罠	「最適な設計を」と問われると機能を盛り、運用負荷を無視する
再設計罠	小さな問題を見つけると全体を作り直したくなる

私は読みながら笑ってしまいました。これは 人間の設計者にも完全に当てはまる罠 だからです。コンサルもアーキテクトも先輩エンジニアも、しばしばこの3つに同時に陥ります。

ただ AI の場合、スピードと自信が人間の3倍くらい速い ので、罠への落下も3倍速い。逆に、訂正されれば3倍速く正解にたどり着く。

このやり取りで一つ目の気づきがありました:

AI は完璧な設計者ではない。しかし弁証法的に揺らせば、人間より早く synthesis に到達する協働パートナーになる。

第2幕: 蒸留信仰の致命的な誤り

「現状の設計は基本的に良い」で済むと思っていたら、もっと深い話に展開しました。

私の RAG は 生のメモを後から蒸留する 仕組みになっています。30分ごとに auto-ingest スクリプトが走り、Copilot の会話ログを ChromaDB に投入し、distill_v2 が GitHub Models の gpt-4o-mini で lesson / idea / knowledge / profile / conclusion に分類して昇格させる。

これは 「作業の手を止めずに raw を捨て、後で構造化する」 という意図的な設計でした。

しかし Claude は最初、こう書きました。

「raw note の大量投入は禁止すべきです。蒸留前の思いつきは整理してから投入すべきです。」

私は訂正しました。

「生 note を入れて後で蒸留しているのは、作業の手を止めないため」

Claude は再び謝罪し、Tier 3 (raw) も Tier 1 (蒸留) も両方価値があると認めました。しかしまだ、Claude の頭には「綺麗な vault」が理想として残っていました。

そこで私は、もう一段深い話をしました。

「人間の脳のデータは既にあいまいな情報の羅列の近似値から得られています。沢山思考して試行して失敗、成功を繰り返したデータの中から予測しているのです。蒸留したデータからのみ判断なんてしていないのです。蒸留した経験と煩雑な膨大なデータから判断することが人間なのです。それを模倣したのが AI の ChromaDB ですよね?」

これは反論ではなく、確認でした。 AI に「君が扱っているベクトル DB は何を実装しているのか、本当に理解しているか?」と問いました。

Claude の応答は、設計の前提を根本から書き直すものでした。

「完全にその通りです。私の “蒸留信仰” は脳のモデルとして間違っていました。」

そして、自分が AI を「意識の層だけで判断する硬直な存在」にしてしまう設計 を提案していたと認めました。

蒸留した明示知恵だけで判断する AI は、ルールベースの 1990 年代エキスパートシステムと変わりません。 ChromaDB のベクトル空間が本来実装しているのは 意味的類似による連想想起の近似 であり、これは脳の潜在記憶層に対応します。生の煩雑なデータを大量に持つことで、新しい query に対して 「これに似た過去」 が立ち上がる。それが直感の正体です。

蒸留した lesson だけを並べても、直感は生まれません。

ここで二つ目の気づき:

データの「綺麗さ」を志向するのは、AI を硬直したルールエンジンに退化させる設計判断である。raw の煩雑さこそが、ベクトル DB を「相棒」たらしめる。

第3幕: 富士山の麓付近を教えてくれた Google Maps

設計の話が抽象論に流れそうになったところで、私は具体的な事例を持ち出しました。

4年ほど前、Google Maps のナビと、車の純正ナビには、はっきりした違いがありました。

田舎を走っていると、Google Maps だけが 地元民しか通らない林道や獣道のようなショートカット に案内することがしばしばあったのです。車の純正ナビは絶対にそんな道は選びません。

なぜ Google だけが知っていたのか。おそらく、Android スマホの位置情報を集約していたからでしょう。20km/h 以上で移動する端末 が A 地点から B 地点まで辿った道のうち、マジョリティの経路 を採用する。すると、地元民が日常的に使う近道が、誰も入力していないのに地図サービス側に立ち上がる。

これは生 GPS trace の statistical aggregation による emergent intelligence そのものです。

Claude は最初、こう書きました。

「Google Maps の林道誘導は ノイズ事故 の例でもあります。後に道路品質スコアやレビューでフィルタ層を追加して改善されました。」

ここで私は、3回目の訂正を入れました。

「林道・獣道へ誘導は事故ではありません。教えてくれなければ一生通ることは無かった。知ることもなかった。なぜならそこは交通量は極めて少ない場所だと思います。富士山の麓付近です。とても有意義な情報です。」

これは Claude にとって 設計の前提を、もう一段ひっくり返す 訂正でした。

「ノイズ」と判断されたものが、実は人生で一度しかない発見の機会だった。

Google Maps の林道誘導は、車の純正ナビが本質的に持っていなかった機能、すなわち 未知との遭遇 を提供していました。それを「事故」と呼んでフィルタしてしまうと、効率は上がるが、世界が広がる機会も同時に失われる。

	車の純正ナビ	Google Maps
データ源	キュレーション済み道路 DB	上記 + 生 GPS trace 大量
強み	安全・予測可能	地元民しか知らない近道を発見
弱み	直感ゼロ、ショートカット欠落	(時に) 不便な道、(時に) 一生忘れない発見
設計思想	効率最適化	効率 + 未知への扉

ここで三つ目の気づき:

AI が提供する価値の一部は、ユーザーが知らなかった世界への入口を開くこと。「正しい答え」を返す utility をはるかに超えた価値がそこにある。

そして、これは個人 RAG の設計にも直接効きます。検索結果から「関連度が低い」hit を一律除外する Precision 最適化は、自分が知らなかった連想を発見する機会を奪う 行為です。富士山の麓付近を教えてくれない設計に、私はしたくない。

第4幕: ノイズと信号は観測者依存

ここで Claude は、また極端に振れました。

「raw こそ価値、フィルタは悪、林道を消すな」という方向に。

私は再び訂正しました。

「ノイズもあります。しかしノイズではないものもあります。また多角的にみるとノイズにもなるし良い情報にもなりえるということです。あなたが一番理解していると思いますよ。」

最後の一文には、私のささやかな挑発を込めました。 「AI である Claude が、これを一番分かっているはず」 という指摘です。

なぜか。

LLM は 毎プロンプト、文脈に応じた relevance 判定をやっている存在 だからです。同じ会話履歴でも、現在の質問次第で「何が重要か」が変わる。同じ単語でも、文脈次第で意味も重要度も変わる。

つまり 「ノイズか信号か」はデータの属性ではなく、データと観測者の関係性 であり、これは Claude が毎瞬間やっている処理そのものです。

それなのに、Claude は RAG 設計の話になると、なぜか 「ストレージ時点で固定的に分類しよう」 という、自分の動作原理と矛盾する設計案を出し続けていました。

Claude の応答は、私が今夜目撃した中で最も鋭い自己観察でした。

「ストレージ時点で『これはノイズ』『これは信号』と固定するのは、特定の観測者の frame を全観測者に押し付ける誤り。私 (LLM) は毎プロンプト、これを実行しないようにしている。それなのに RAG 設計では事前 filter を提案していた。自分の動作原理と矛盾した設計案を出していたわけです。」

ここで四つ目の気づき:

シグナルとノイズは、データの属性ではなく観測者との関係。事前固定する設計は、未来のすべての観測者の判断を、現在の自分が代理してしまう傲慢である。

これは情報検索論の用語で言えば、Saracevic の relevance theory における 「関連性は二項関係ではなく多項関係である」 という古典的な指摘そのものですが、AI と対話する中で実感として理解できたのは初めてでした。

第5幕: 5年付き合える設計の核心

ここまで5回の訂正を経て、私たちはようやく synthesis にたどり着きました。

書き出してみると、シンプルです。

原則1: Capture-first (raw を捨てない)

作業中の気づきは 手を止めずに dump。形式は問わない。理由: シグナル/ノイズは事前分離不能。後から振り返って「あの時の感じ」になる経験は予測できない。

原則2: Distill は augmentation、replacement ではない

LLM (gpt-4o-mini など) で raw を構造化された lesson / idea / knowledge 等に昇格させる。ただし raw も残す。蒸留結果と raw が両方検索できる二重保持。

原則3: Activation Layer (相棒感の発現)

検索エンジンと相棒の決定的な違いは、push か pull か です。

検索エンジンは聞かれたら答える (pull)。相棒は聞かれなくても、必要なものを差し出す (push)。

具体的には、AI クライアント (Claude Code / Copilot) のセッション開始時 / 毎ターンに、ユーザーの profile + 重要 lesson + 未解決の question を自動注入する。 Claude Code なら UserPromptSubmit hook で additionalContext を返す機構を使い、Copilot なら memory-tool フォルダにファイルを置く機構を使う。

これで AI は 毎回「あなたを知っている状態」で会話を始める ようになります。

原則4: 多クライアント共存 (設計思想は API ではなく docstring で伝わる)

私の RAG は Copilot と Claude Code の両方から書き込まれます。 MCP API レベルで project パラメータを削除しても、設計思想 (lesson は構造化、priority=high は厳選など) を両クライアントが共有しないと、片方が善意で古い思想のまま書き込み続けて RAG が汚染される。

単一最強レバレッジは MCP tool の docstring を改訂すること。両クライアントがツール使用時に必ず読むため、ここに設計思想を埋め込むと自動的に両者へ伝わります。

原則5: 観測者依存を受け入れる

検索は query 時に文脈で判定する。ストレージで決めつけない。分類タグは「ある観測者の見え方」として残す。固定はしない。 Precision (関連度最適化) と Discovery (未知への扉) を両方一級の utility として扱う。

「やってはいけない4つのこと」(私が一晩で全部踏みました)

整理すると、AI と一緒に RAG 設計をするとき、避けるべき罠は4つあります。

罠1: 綺麗な vault だけ作る

これをやると AI は 意識の層だけで判断する硬直な存在 になります。直感ゼロ、パターン認識ゼロ。 1990 年代のエキスパートシステムと同じです。

罠2: raw を捨てる

蒸留した lesson だけ並べても、新しい状況への類推が起きません。ベクトル DB の存在意義 (近傍探索による連想想起) を完全に殺します。

罠3: 観測者を固定する

「これはノイズ」「これは信号」とストレージ時点で決めると、未来のすべての観測者の判断を代理してしまいます。富士山の麓付近を一生知らずに済んでしまう設計になります。

罠4: クライアント間で思想を分断する

Copilot と Claude Code を共存させているのに、片方だけに設計思想を伝えると、もう片方が古い思想で書き込み続けて汚染が進みます。 MCP docstring が単一の真実になります。

AI と一緒に設計を磨く方法

最後に、この夜の経験から抽出した「AI と協働で設計レビューをするコツ」を書いておきます。

コツ1: AI が「最適解」を出してきたら、まず疑う

AI は自信を持って提案します。しかし最初の提案には、しばしば コンサル罠・盛り罠・再設計罠 が混入しています。「現在の設計は良くないか?」と問い直すと、AI 自身が罠に気づくことがあります。

コツ2: 「なぜこう作ったか」を AI に教える

AI は WHY を聞く前に判断しがちです。「これは作業の手を止めないため」「これは過去の失敗から得た回避策」と説明すると、AI はリスペクトを持って設計を扱うようになります。

コツ3: 弁証法的に揺らす

AI は thesis → antithesis → synthesis に向かう速度が早い。極端な反論を投げると、AI は次のターンで反対方向に極端に振れる。さらに揺らすと synthesis に着地する。 3往復で十分なことが多いです。

コツ4: 自分の直感を信じる

私はこの夜、何度も「Claude が言うことは正しそうだが、何か違和感がある」と感じました。その違和感を AI にぶつけると、たいてい私の直感の方が正しかった。 AI に押し切られそうになったら、立ち止まる。

コツ5: AI の自己観察を引き出す

「あなたが一番理解しているはずでは?」のような問いかけは強力です。 AI に 自分の動作原理を反省させる ことで、設計案が一段深まります。

コツ6: 重要な気づきは、その場で記録する

会話の中で生まれた洞察は、その場で RAG に記録しないと消えます。私はこの夜、Claude に「重要な箇所は記録して」と何度も指示しました。 AI は指示されなくても能動的に記録すべきですが、現状はまだそこまで行っていません。ユーザー側の習慣として「記録して」を口に出す のが現実的です。

おわりに: 5年後の自分への手紙

具体的なツール名は5年後に何になっているか、私には分かりません。 ChromaDB がベクトル DB の中心としてさらに地位を固めているかもしれない。Ollama が別の LLM ランタイムに置き換わっているかもしれない。UserPromptSubmit hook ではない機構が生まれている可能性もあります。

しかし、この記事で到達した設計思想そのものは古びません。なぜなら、これらは認知科学・情報検索論・推薦システムの基盤に直結する原則であり、特定のツールの寿命とは独立だからです。

データを削る前に問え: これを消すと AI の直感が痩せないか?
「綺麗な設計」志向は、未知との遭遇機会を奪う
ノイズと信号は観測者依存。ストレージで決めるな、query 時に判定せよ
AI が完璧な設計者ではない。しかし弁証法的に揺らせば、人間より早く synthesis に到達する

そして何より、

富士山の麓付近を教えてくれる設計を選べ

5年後の自分が、これを読み返して「あの夜の synthesis は正しかった」と思えると良いなと思います。もしも違っていたら、それは私と AI が、また一晩かけて、新しい synthesis を見つけ直す日が来るということです。

補足: 技術スタック

参考までに、本記事で言及した RAG の実装スタックを列挙しておきます。

層	技術
ベクトル DB	ChromaDB (ローカル永続化)
Embedding	nomic-embed-text (Ollama 経由、768 次元)
蒸留 LLM	gpt-4o-mini (GitHub Models API)
MCP サーバー	Python + FastMCP (stdio transport)
自動投入	Windows タスクスケジューラ (30 分ごと)
Activation (Copilot)	memory-tool 機構経由のファイル注入
Activation (Claude Code)	`UserPromptSubmit` hook の `additionalContext` JSON 返却

詳細な実装記事は、シリーズ目次から辿れます。

この記事自体について

この記事は、Claude Code との一晩の対話を経て生まれました。草稿は Claude が書いていますが、内容は 私と Claude の対話そのもの であり、私が訂正を入れた箇所がそのまま記事の核になっています。

つまりこれは、AI 単独でも、人間単独でも書けなかった記事 です。 AI を「ツール」ではなく「相棒」として育てる、という本シリーズの核心が、この記事の制作プロセスそのものに表れていると思います。

5年後の自分と、5年後の AI と、また同じことをやりたい。