TL;DR

自分のノートをAIに意味で検索させる仕組み（RAG）を、外部にデータを一切出さずに作りました。
動かしているのはGPUなし・実質メモリ16GBのミニPC。追加費用は0円です。
Andrej Karpathy 氏の「LLM Wiki」（知識を百科事典として育てる考え方）も取り入れ、RAGと併用しています。
特別な部品は作っていません。実装はClaude Code、自分は方向の決定と間違いを止める判断だけです。
正直な限界として、小さなローカルモデルでは**「矛盾の自動検出」が機能せず**、別の形に置き換えました。

はじめに：なぜ書くか

最近、Obsidianと生成AIを組み合わせた知識管理の記事をよく見かけます。とても面白いのですが、その多くが 「こういう考え方があります」という概念の紹介で止まっていて、実際に動かした記録は意外と少ない、と感じました。

私は最先端の研究者でもエンジニアでもありません。「定型業務をAIに任せたい」いち利用者です。それでも、方向とゴールさえ決めれば、Claude Code に任せてここまで作れました。この記事は、その「実際に動いた記録」です。

前提となる私の環境（過去記事）：

今回はその続きで、**「AIに、自分の過去のノートを踏まえて答えてもらう」**部分の実装です。

何が問題だったか

私の環境では、これまでAIに過去の文脈を渡す方法が2つありました。

決まった内容を毎回そのまま渡す（直近のメモを機械的に貼るだけ）
私が「これ関係ありそう」と思ったノートを手で探して渡す

どちらも弱点があります。1は「質問に関係あるかどうか」を見ていません。2は私の記憶と、同じ言葉で書いてあるかどうかに依存します。たとえば「暴走を防ぐ仕組みは？」と聞いても、ノートに「fail-close」としか書いていなければ、言葉が一致せず見つけ損ねます。

やりたかったのは、言い回しが違っても"意味"で関連ノートを引いてくること。これがいわゆる RAGです。

全体像

作ったものを一枚にすると、こうなります。

　　　情報を入れる ──────→ AIが整理・リンク付け ──────→ 知識ベースが育つ
　　　　　↑                                                   │
　　　　　│  ・日々の会話（自動でノート化）                  　  │  ・ノートが増える
　　　　　│  ・記事メモ（ローカルLLMで要約）                 　　│  ・関連ノートを自動リンク
　　　　　│                                                   ↓
　　　　　└──── 質問したら関連ノートを自動注入 ←── 毎晩、増えた分を索引に取り込む
　　　　　　　　　　（意味検索）
　　　　　　　　　　　　※ すべて自宅PC内で完結。外部に送信なし

ポイントは、重い処理（ノートを"意味の数値"に変換する作業）は夜間にまとめてやっておき、普段の検索は軽い計算だけで済ませることです。非力なPCでも回るように、ここを分けました。

使っている道具はすべてローカルです。

役割	使ったもの
ノート置き場	Obsidian（Markdownファイル）
意味の数値化（埋め込み）	Ollama + `nomic-embed-text`（ローカル）
回答の生成	Ollama + 小型モデル（ローカル）
実装・自動化	Claude Code、スクリプト、簡単なスケジューラ

クラウドのAPIに、ノートの中身を送ることはありません。医療費の領収書や個人的なメモも扱うので、外に出さないことを最優先にしました。

作ったもの（4つの小さなスクリプト）

大げさな基盤は使っていません。小さなスクリプトの組み合わせです。

1. 貯める（索引づくり）

全ノートを一定の長さに区切り、ローカルの埋め込みモデルで「意味の数値（ベクトル）」に変換して保存します。一度作れば使い回せるので、毎晩「変わったノートだけ」を作り直します。ここが唯一の重い処理で、寝ている間に済ませます。

2. 探す（意味検索）

質問を同じように数値化し、保存済みのノートと近さを比べて、関連が強い順に返します。ここは掛け算と足し算だけなので一瞬です。キーワードが一致していなくても、意味が近ければ引けます。

3. 答える（生成）

探してきたノートを手がかりに、ローカルの小型モデルが回答を作ります。このとき**「渡した資料だけを根拠に答える／分からなければ分からないと言う／出典を示す」**と強く指示しています。ハルシネーションを抑えるためです。回答には必ず「どのノートを根拠にしたか」を添えます。

4. 自動で効かせる

ここが今回いちばんの工夫です。質問を送った瞬間に、その質問で自動的に関連ノートを検索して、AIへの入力にそっと足すようにしました。プラグインを入れなくても、「聞いたら関連が勝手に出てくる」状態になります。関係が薄いときは何も足さないので、邪魔にもなりません。

設計で悩んだところ（採用理由）

「なぜそれを選んだか」を正直に書きます。判断の記録は、たぶん一番参考になる部分です。

決めたこと	理由
専用のデータベースを使わず、素朴なファイル＋数値計算で済ませた	メモリが乏しいので、常駐して重くなるものを増やしたくなかった
埋め込みは「貯めるとき」だけ動かす	普段の検索で重いモデルを起動しっぱなしにしないため。ピークをずらす発想
クラウドの高性能モデルを使わず、あえてローカル小型モデル	外部にノートを出さないことを、性能より優先した

派手ではありませんが、「非力なハードで動かす」という制約が、そのまま設計判断になっています。

正直に、うまくいかなかったこと

ここが一番読んでほしい部分です。

小型モデルに「矛盾検出」は無理でした

育った知識ベースは、放っておくと古い記述と新しい記述が食い違ってきます。たとえば私のノートには、「電気代は約200円」と書いた古い記述と、あとから計算し直した**「約400円」という新しい記述**が両方残っていました。ほかにも「最終承認はAIがやる」と書いた昔のメモと、「最終承認は人間がやる」という現行の運用が同居していたりします。

こういう食い違いを放置すると、検索が古い方を引っ張ってきて、AIが平気で間違った答えを返します。そこで「ノート同士の矛盾を自動で見つける」機能を、ローカルの小型モデルで作ろうとしました。ノートを2つずつ組にして「この2つは矛盾していますか？」と聞く、という素朴な作戦です。

結果は 精度ゼロでした。検査した対のすべてを「矛盾あり」と判定してしまいます。中身を見ると、小型モデルは 「話題が似ている」と「事実が食い違っている」を区別できていません。たとえば「電気代は約400円」と「電気代は平均18Wから計算した」は、同じ話題ですが矛盾していません（片方はもう片方の根拠です）。それすら「どちらも電気代の話だから矛盾」と判定してしまう。「引用を実際のノートから抜き出せたときだけ採用する」というガードを足しても、**「実在するけれど矛盾ではない引用」**を並べるだけで、改善しませんでした。

**「プロンプトを磨いても越えられない壁がある」**とよく言われますが、今回はまさにそれでした。指示を厳しくしても、ガードを足しても、モデルの能力そのものが足りていないところは、プロンプトの工夫では越えられません。ここで粘り続けるのは、時間の使い方として間違いです。

そこで方針を変えました。「矛盾検出」はあきらめ、「意味がとても近いノート対を出す（＝重複・統合の候補）」に置き換えたのです。これは数値計算だけで確実に出せて、作り話も起きません。「このノートたちは内容が近いので、統合するか棲み分けるか、人間が判断してください」という形にしました。

つまり、プロンプトで粘るのをやめ、設計を変えて壁を回避したわけです。"できないことをできたフリで出す"より、"確実にできることに置き換える"方が、道具として誠実だと考えました。

そのほかの限界

1回の質問あたり数秒の待ち時間が乗ります（GPUなし・CPUだけで動かしている宿命です）。
回答文はやや冗長です（小型モデルのため）。将来もっと良いモデルを載せられれば改善します。
孤立ノートやリンク切れの検出はきれいに動きましたが、「掃除」の一部は人の目が前提です。

それでも、"育つループ"は回っています

弱点はありますが、**「情報を入れる→自動で整理・リンク→育つ→次の質問に自動で効く」**というループは、実際に回っています。

面白いのは、この記事を書いているやり取り自体が、そのループの中にあることです。今日の会話は自動でノート化され、今夜には索引に取り込まれ、明日以降の質問で「関連ノート」として自分自身に返ってきます。使うほどに、少しずつ賢くなっていく——概念で読んだこの感覚が、手元で動いているのは素直に楽しいです。

まとめ

方向とゴールを決めれば、Claude Code に任せて、非力な自宅PCでもローカルRAG＋育つWikiはここまで作れます。
ただし「任せれば誰でも」ではありません。AIは間違えるので、"どこを触るか決める判断"と"間違いを止める目"は人間が握る必要があります（過去、これを手放して環境を壊しかけたことがあります）。
私の構成は新しい理論の発明ではありません。ただ、世に出ている概念（RAG／Karpathy 氏の LLM Wiki）と照らしてみると、自分の環境はおおむねその考え方に沿って動いていました。概念だけの記事が多い中で、実際に1台のPCで動かした記録は、それ自体に価値があると思って公開します。
- ※ 念のため補足すると、Karpathy 氏は意図的に RAG を使わない立場です。私の構成はRAGと併用したハイブリッドなので、氏の提案そのものではありません。
そして今回いちばんの学びは、**「プロンプトを磨いても越えられない壁は、設計を変えて回避する」**ということでした。指示やガードをどれだけ工夫しても、モデルの能力が足りない領域は越えられません。できないことは正直にあきらめ、確実にできることに置き換える方が、道具として強くなります。

概念だけの記事が多い分野なので、**「実装して動かした一次情報」**として、どなたかの参考になれば幸いです。

注：セキュリティに関わる防御の詳細（検知ルールや自宅環境の弱点）は、攻撃の手がかりになり得るため、この記事では意図的に伏せています。考え方の骨子だけ共有しています。