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と併用したハイブリッドなので、氏の提案そのものではありません。
- そして今回いちばんの学びは、**「プロンプトを磨いても越えられない壁は、設計を変えて回避する」**ということでした。指示やガードをどれだけ工夫しても、モデルの能力が足りない領域は越えられません。できないことは正直にあきらめ、確実にできることに置き換える方が、道具として強くなります。
概念だけの記事が多い分野なので、**「実装して動かした一次情報」**として、どなたかの参考になれば幸いです。
注：セキュリティに関わる防御の詳細（検知ルールや自宅環境の弱点）は、攻撃の手がかりになり得るため、この記事では意図的に伏せています。考え方の骨子だけ共有しています。