Karpathyの「LLMに第二の脳を育てさせる」をClaudeとObsidianで実装する

前の記事では、ノートに手がかりを持たせてClaudeが引けるVaultを作った。 そこでは、書くのも整えるのも人間で、Claudeは引き出す側にいた。 本稿で扱うのは、その一段先にある考え方だ。

Andrej Karpathyが2026年4月3日に投稿した内容が、その起点になっている¹。 LLMの個人的な使い方を、「コードを生成させる」から「知識構造を生成させる」へ移したという話だった。 具体的には、生の素材をフォルダに入れておくと、LLMがそれを読んで構造化されたページを書き、相互にリンクを張り、索引を維持する。 人間が知識ベースを保守してたまにAIへ質問するのではなく、AIが知識ベースそのものを育てる。

この発想をObsidianに持ち込み、リサーチ用のエージェントに仕立てた例がX上で紹介された²³。 本稿では、その仕組みをClaudeとObsidianで組む手順に置き換えて解説する。 あわせて、こうした紹介につきものの誇張を、どこまで割り引いて読むべきかも添える。

先に断っておくと、これはシリーズのなかでいちばん触れ込みが派手で、実際の手応えがそれに届きにくいテーマだ。 デモは「放っておくと育つ」ように見えるが、実運用では人間が事実確認に手を入れ続ける必要がある。 この記事は、仕組みを紹介したうえで、その「放っておける」がどこまで本当かを切り分けることに半分を割く。 なお、そもそも自分でVaultを育てる気がなく資料を調べたいだけなら、この仕組みは要らない⁴。

引き出すVaultと、育つVaultの違い

前の記事のVaultは、人間が書いたノートを、Claudeが正確に引ける状態に保つものだった。 入力も判断も人間がやり、AIは検索の精度を担う。 ここでのAIは、よくできた司書に近い。

Karpathyの発想は、AIの役割を一段ずらす。 人間は生の素材を放り込むだけにして、ノートを書き、つなぎ、整える作業をAIに渡す。 ここでのAIは、司書ではなく、素材から記事を書き起こす編集者に近い。

二つは対立しない。 育てる仕組みが書いたノートも、結局は引き出せる形でVaultに残らなければ意味がない。 育つVaultは、前の記事の「引き出せるVault」を土台にして、その上に書き手としてのAIを乗せたものだと考えるとよい。

仕組みの骨格

この仕組みは、三つの場所と一つの繰り返しでできている。

• raw/（生の素材置き場）：記事の切り抜き、論文、打ち合わせの文字起こし、断片的なメモを、整形せずそのまま入れる
• wiki/（AIが書く構造化ページ）：Claudeが素材を読んで書き起こす、主題ごとのノート
• 索引ノート：wiki全体の入口になる目次。どの主題のページがあるかを一覧する

繰り返しはこうだ。 raw/ に素材が増える。 Claudeが新しい素材を読み、関係する wiki/ のページを新規に書くか、既存のページに追記する。 ページ同士に [[リンク]] を張り、索引を更新する。 人間はできあがったページを読み、直したいところを直し、また raw/ に素材を足す。

メモを書いて放置していても、AIがVaultを育ててくれる。 紹介記事のこの一文は、この繰り返しを指している⁵。

ClaudeとObsidianで組む

このパターンはClaudeと相性がよい。 Obsidian Vaultは素のMarkdownファイルの集まりなので、Claudeにフォルダを渡せば、読むのも書くのもそのままできる。 実際、Karpathyのパターンを実装した公開リポジトリには、Claudeのアカウントを接続してwikiを書かせるものがある⁶。

最小構成は、新しいツールをほとんど足さずに作れる。 Vaultに raw/ と wiki/ のフォルダを用意する。 Claude Codeをそのフォルダで動かすか、Filesystem MCPでVaultを指す⁷。 あとは、Claudeに渡す指示書（役割の定義）を一枚置く。

指示書には、たとえばこう書く。

# このVaultでのあなたの役割

- raw/ にある素材を読み、wiki/ に主題ごとのページを書く
- 既に同じ主題のページがあれば、新規に作らず追記する
- ページ同士は関係があれば [[ページ名]] でリンクする
- 各ページの冒頭にフロントマター（type, date, topic, status, sources）を付ける
- sources には、その内容の出どころになった raw/ のファイル名を必ず書く
- 出典の取れない数値や固有名は、断定せず「要確認」と記す
- wiki/00-index.md に、ページ一覧と一行要約を維持する

この指示書が、前の記事で作った命名やフロントマターの規約と、そのままつながる。 育てる仕組みが書くページも、最初から「引き出せる形」で生まれることになる。

自動化はするが、無人化はしない

この仕組みは、放っておいても育つように見える。 だが、人間が手を離してよい部分と、離してはいけない部分は分けて考えたほうがよい。

任せてよいのは、素材を読んで下書きを起こす、似たページに追記する、リンクと索引を更新する、といった機械的に積み上がる作業だ。 ここは繰り返しが多く、AIに渡すと手離れが進む。

任せきってはいけないのは、書かれた内容が事実かどうかの確認だ。 LLMは、出典のない数値や固有名を、それらしく書いてしまうことがある。 だから指示書では、各ページに出どころ（sources）を必ず残させ、裏の取れない記述には「要確認」を付けさせる。 人間は、できたページの「要確認」を順に潰していく。

引き出すVaultでも書き手のVaultでも、原則は同じだ。 積み上げる作業はAIが、正しいかどうかの判断は人間が受け持つ。

「$0＋$0＋$20で一万五千ドル相当」をどう読むか

この仕組みの紹介には、しばしば威勢のいい数字が添えられる。 紹介元の投稿は、無料のリポジトリと無料のプラグイン、それにモデルへの二十ドルの課金だけで、「エージェンシーが一万五千ドルで売るものと同等」を作れると述べている⁸。 別の投稿者は、自分の七千枚のノートが月一万五千ドルのリサーチ業務に化けた、と書いている。

これらの数字は、発信者本人の主張であって、第三者が検証した実績ではない。 「一万五千ドル相当」が何と同等なのかの基準は示されていないし、月の収益額は個人の事例にすぎない。 仕組みの値打ちを判断する材料としては、そのまま受け取らず、発信者がそう言っている、という重さで読むのが妥当だ。

割り引いたうえで残るものはある。 素のMarkdownと汎用のLLMだけで、専用のサービスを使わずに知識ベースを育てる仕組みが組める、という骨子は確かだ。 使うモデルはKimiでもClaudeでも置き換えがきき、Vaultの中身はモデルが変わっても残る。 派手な金額ではなく、この「自前で組めて、持ち運べる」という点が、この仕組みの実利になる。

RAGはいらなくなるのか

Karpathyの投稿のあと、「これで個人用途のRAGパイプラインは不要になるのか」という議論が起きた。 ここは整理しておきたい。

RAGは、問いを受けるたびに、生の文書群から関連箇所を検索して回答に使う方式だ。 Karpathyのパターンは、問いを受ける前に、生の素材をあらかじめ構造化されたページへ書き換えておく。 前者は都度の検索にコストをかけ、後者は事前の整形にコストをかける。

個人のVaultでは、後者が効きやすい場面が多い。 素材は少しずつ増えるので、増えた分だけ整形すればよく、毎回ゼロから検索し直す必要がない。 できあがるのが人間にも読めるMarkdownのページなので、AIの回答を待たずに自分の目で確かめられる。

とはいえ、これは「RAGが不要になる」という話ではない。 扱う文書が大量で、内容が頻繁に入れ替わる用途では、事前整形が追いつかず、都度検索のほうが向く。 個人の知識ベースという限られた範囲で、事前整形が都度検索より割に合いやすい、というのが正確なところだ。

まとめ

• Karpathyの発想は、AIの役割を「引き出す司書」から「素材を記事に起こす編集者」へ広げる
• raw/ に素材を入れ、Claudeが wiki/ に構造化ページを書き、リンクと索引を維持する繰り返しで、Vaultが育つ
• ObsidianのVaultは素のMarkdownなので、Claudeに渡せば読み書きでき、指示書一枚で運用できる
• 自動化はするが無人化はしない。積み上げはAI、事実確認は人間。出典と「要確認」を必ず残させる
• 「一万五千ドル相当」のような数字は発信者の主張として割り引く。残る実利は「自前で組めて持ち運べる」こと
• 個人用途では事前整形が都度検索より割に合いやすいが、RAGが一律に不要になるわけではない