ネットで「Karpathy RAG」という言葉を見かけて、何のことだろうと思った人向けにまず整理しておく。
元ネタは、かつてTeslaのAI部門を率い、OpenAIの共同創業者でもある Andrej Karpathy が、2026年4月の頭にXへ投稿した「LLM Knowledge Bases」という話。1,300万回以上読まれ、その翌日には考え方を詳しく書いたメモ（gist）が公開された。
ここがややこしいところなのだが、Karpathy本人はむしろ「凝ったRAGは要らなかった」と言っている。「ご大層なRAGを組まないといけないと思っていたが、このくらいの規模なら、LLMが目次や要約を自分で勝手に整理してくれて、関係する資料もちゃんと読んでくれた」という趣旨だ。
つまり「Karpathy RAG」というのは世間が後から付けた通り名にすぎず、中身としてはRAGの代わりになる別のやり方、どちらかといえば「RAGに頼らない」発想と理解したほうが正確。本記事では以降「LLM Wiki」と呼ぶことにする。
図書館の司書を思い浮かべると分かりやすい。
肝心なのは、知識が「積み上がる」かどうかだ。RAGは毎回かき集めて使い捨てるので、知識そのものは貯まらない。一方のLLM Wikiは、Karpathyの言葉を借りれば「使うほど中身が増え、消えずに残り続ける成果物」になる。
LLM Wikiは、役割の違う3つの層に分かれている。
| 層 | 誰が書くか | 中身 |
|---|---|---|
| 素材（Raw sources） | 人間が足す。LLMは読むだけ | 論文PDFやWeb記事の切り抜きなど、手を加えない一次資料 |
| wiki | LLMが管理。人間は基本書かない | 要約・概念ごとのまとめ・相互リンクからなるMarkdown群 |
| ルール（Schema） | 人間が決める。LLMが従う | CLAUDE.md や AGENTS.md など。フォルダ構成や進め方の取り決め |
中心になるのは真ん中の wiki層。ここには次のようなページが並ぶ。
普段の運用は、3つの操作を繰り返すだけ。
人間が自分の手で動くのは「素材を素材フォルダに入れて取り込ませる」「wikiに質問する」の2つだけ。要約を書く、リンクを張り直す、目次や履歴を更新する、矛盾を見つける——こうした地味な作業はすべてLLMに任せる。
Karpathyのメモの「Why this works（なぜ機能するか）」が要点だ。
知識ベースを維持するうえで本当にしんどいのは、読むことでも考えることでもなく、帳簿付けのような地道な管理作業だという。あちこちの相互参照を直す、要約を最新の状態に保つ、新しい資料が前の主張と食い違ったら記録する、何十ページにもわたって辻褄を合わせ続ける——こうした作業だ。
人間がこの手のノートをいずれ放り出すのは、続けるほど維持の手間が増え、それが得られる価値の伸びを追い越してしまうから。3本目くらいまでは続いても、50本ともなると更新を諦める。
ところがLLMは飽きないし、リンクの直し忘れもしないし、一度の指示で15ファイルをまとめて書き換えられる。維持の手間がほぼゼロまで下がるので、ノートが捨てられずに残り続ける。1945年に Vannevar Bush が構想した「Memex」（資料同士のつながりをたどる装置）が、80年越しにMarkdownの中で形になりつつある、という見方もできる。
「考え方は分かった、とにかく動かしてみたい」という人向けの最小プラン。Claude Code を前提に書くが、Codexなどを使う場合も CLAUDE.md を AGENTS.md に読み替えれば同じ。所要30分ほど。
mkdir karpathy-wiki-hello && cd karpathy-wiki-hello
mkdir -p raw/articles raw/papers
mkdir -p wiki/articles wiki/papers wiki/concepts wiki/queriesClaude Code を起動し、Karpathy が公開しているメモ（gist）
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94fを読ませたうえで、こう頼む。
このメモのやり方にならって、自分用のLLM Wikiの初期設定を作って。
・CLAUDE.md（フォルダの取り決め、命名ルール、取り込み/質問/点検の進め方の定義）
・.claude/skills/ の下に ingest-article / ingest-paper / query / lint のスキル
raw/ と wiki/ のフォルダはもう作ってある。最初は単純な内容でよい。Karpathyのメモ自体が「これは考え方を伝えるためのもの。具体的なところは自分のAIエージェントと一緒に作り込んでほしい」という建て付けなので、最初から完璧なひな型を狙わなくていい。Step 4で育てていく前提でよい。
ハローワールドにちょうどいいのは、この「Karpathy RAG」について書かれた記事そのものを素材にすること。少し入れ子っぽい話だが、複数の記事が勝手に1枚のまとめへ束ねられていく様子が、一度で体感できる。
raw/articles/ に記事の切り抜き（Obsidian Web ClipperなどでMarkdownにしたもの。なければURLのメモ書きでも可）を置き、Claude Codeにこう頼む。
raw/articles/ の記事を1本ずつ取り込んで。
wiki/articles/ に要約、wiki/concepts/ に概念ページを作り、index.md と log.md を更新して。3〜5本入れると、wiki/concepts/ に「RAGとLLM Wikiの違い」「3つの層」といった、複数の記事を横断してまとめ直した概念ページがLLMの手で勝手に組み上がる。これがこのやり方のいちばんの見どころだ。
整理されたwikiに質問してみる。
wikiに質問：「従来のRAGとLLM Wikiは、結局どう使い分ければいい？」
答えは wiki/queries/ に綴じておいて。ふつうにLLMへ聞くのと違い、自分が取り込んだ素材だけを根拠に、範囲は狭いが踏み込んだ答えが返る。答えがwikiに残るので、次の質問や取り込みからその答えを参照できる。
続けて点検もかけてみる。
点検を実行して。リンク切れ・孤立ページ・表記ゆれ・矛盾・「次に調べるべき問い」を洗い出して。5本も回すと「この項目は要らない」「逆にこの項目が欲しい」という感覚が出てくる。それを取り込みスキルに反映していく。この調整も、自分で書かずLLMにやらせるのがコツ。
取り込みスキルを読んで、今の概念ページのひな型に足りない項目を提案して。エンジニアなら概念ページに「実装パターン」「ハマりどころ」、研究者なら「未解決の問い」を必ず入れる、といった具合に。ルール層もスキルも、いったん決めて固定する設定ではなく、運用しながら育てていくものと考える。
夢を見すぎないために、実際に運用した人たちが挙げている弱点も書いておく。
Karpathyの知識ベースは約100記事・約40万語と、比較的こぢんまりした規模だ。今どきのモデルなら全文をまるごと読ませられる。だが資料が数千件・数百万語ともなると全文を読ませるのは物理的に無理で、そこではRAGが「選択肢のひとつ」ではなく「必須」になる、という反論がある。
LLMが自動でまとめたwikiには、どうしても細かい誤りが紛れ込む。その誤りを含んだwikiを、さらにLLMが読んで新しいwikiを書くと、間違いが累積していく。素材（原文）までいつでもたどれる仕組み（出典リンク）を必ず残しておく必要がある。
LLMが概念ページをきれいに繋いでくれても、それを人間が読んで自分の頭に落とし込む作業までは肩代わりできない。研究のアイデアを出す、論文を書く、議論で人を説得する——最後に頼りになるのは自分の中にある理解だ。LLM Wikiは「覚えておく・整理する」負担は引き受けてくれるが、「読み解く」仕事は人間に残る。だから取り込む素材は自分の手で選び、wikiをむやみに溢れさせないほうがいい。
「RAGかwikiか」は二者択一ではない。実際に両方を使うと、その場限りの細かい質問にはRAG的な検索、全体像をつかんだり分野をまたいで理解したいときにはwiki、というすみ分けに落ち着くという声が多い。Karpathyの投稿も、どちらかを否定するものではなく、「RAGに飛びつく前にシンプルなwikiでどこまでいけるか試したら、思いのほかいけた」という体験談として受け取るのが妥当だ。
Karpathyの投稿の核心は、「LLMをコンパイラ（自動でまとめ上げる役）として使う」という発想の切り替えにある。コードを書かせるだけでなく、知識を整理し・構造化し・保守する仕事まで任せる。人間は退屈な管理作業から解放され、何を集めるか・どこへ向かうかを考えることに集中できる。
このやり方が優れているのは、特定のフォルダ構成でも特定のスクリプトでもなく、「LLMと人間の役割分担を、実際に作れる粒度まで具体化した」点だ。素材・wiki・ルールの3層と、取り込み・質問・点検の3操作。この最小限の骨組みだけ決めておけば、あとは各自の用途に合わせてLLMと一緒に肉付けしていける。
まずはハローワールドとして3〜5本取り込んでみて、概念ページが勝手に組み上がる感触を確かめるところから。「ああ、これでいいのか」という感覚は、手を動かさないと得られない。
