2026年4月3日、Andrej KarpathyがXに投稿した一本のポストが、数日のうちにHacker Newsの上位に上った。主要な技術メディアやコミュニティから分析記事が相次ぎ、「LLMが知識をどう管理するか」が4月第1週の開発者コミュニティで最も熱いトピックになった。LLMのトークン消費がコードから知識へと移りつつある。
“Something I’m finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge.”
最近とても有用だと感じていること:LLMを使って関心のある研究テーマごとに個人の知識ベースを構築することだ。こうすることで、最近の自分のトークン消費の大部分が、コードを操作することから知識を操作することへと移っている。
#raw → wiki → output:3層アーキテクチャ
Karpathyのシステムはraw、wiki、outputの3つのディレクトリに分かれている。ソースコードからバイナリを取り出すように、LLMが原資料から構造化された知識を取り出す構造だ。
#原資料 — raw/
修正されていないオリジナルの文書を集める場所。Web記事、PDF、画像、データセット、論文をそのまま保管する。一度入れたら編集も削除もしない。すべてのコンパイルの基盤なので、原本を失えば再生成は不可能になる。
#コンパイル済みの知識 — wiki/
概念ページ、エンティティのプロフィール、要約、相互参照で構成された構造化された知識が積み上がる場所。raw/をコンパイルした成果物であり、実行可能な形をした知識だ。
Karpathyはwiki/の構造をGistで公開している。核となるのはスキーマだ。CLAUDE.md(またはAGENTS.md)がLLMにウィキの構造とワークフローを指示する。このスキーマを書くことは、結局「自分のドメインをどう構造化するか」を決めることそのものだ。
ウィキの中心には2つのファイルがある。
index.md:すべてのページのカタログ。1行要約とメタデータからなるルーティングテーブル。LLMがウィキ全体をナビゲートするための入口。log.md:追記専用(append-only)の年代記。いつ何をインジェストし、どんなクエリを実行したかを記録する。
#クエリ結果 — output/
LLMに質問すると、回答、スライド、チャートがoutput/に積み上がる。多くは使い捨てだが、価値あるものはwiki/に戻される(filing back)。すべてのクエリがウィキに貢献する。
#検索ではなくコンパイルだ
LLMに自分の知識を扱わせる標準的な解は、この2年間RAGひとつだった。文書をベクトルDBに入れ、質問が来たら類似チャンクを探してLLMのコンテキストに詰め込む方式だ。Karpathyが反直観的な主張をしたのは、この標準解に根本的な限界があると見たからだ。
RAGは質問が来るたびに新しく検索して組み立てる。ベクトルDBが見ているのはセマンティックな類似度だけだ。チャンク#4271とチャンク#8903が互いに矛盾していることも、両方が#112の特殊事例であることも、もっと新しい研究がすでに#8903を覆していることも分からない。チャンクに切った瞬間に文脈が断たれ、文書間の関係は消える。
コンパイルはこの関係を前もって書き留めておくアプローチだ。質問が来たときに探すのではなく、新しい資料が入ったときにLLMが既存のウィキを読んで関係を明示的に更新する。ベクトルDBが「知らない」ことがウィキには書いてある。矛盾は矛盾として、特殊事例は特殊事例として、置き換えられた研究は置き換えられたものとして。検索結果は毎回新たに組み立てられるが、コンパイルされた知識は積み重なり進化する。
| 項目 | RAG | コンパイル |
|---|---|---|
| 処理タイミング | クエリ時 | インジェスト時 |
| 保存形式 | ベクトル埋め込み(チャンク) | マークダウン(ページ) |
| 関係表現 | セマンティック類似度 | 明示的な相互参照 |
| 矛盾/置き換え追跡 | 不可能 | 明示的 |
| 累積効果 | なし | 積み重なり進化 |
| インフラ | ベクトルDB必須 | ファイルシステムのみ |
“I thought I had to reach for fancy RAG, but the LLM has been pretty good about auto-maintaining index files and brief summaries of all the documents.”
凝ったRAGに頼るしかないと思っていたが、LLMがインデックスファイルと文書の要約を自動で維持してくれるだけで十分だった。
実際の規模も小さくはない。Karpathyのウィキは1テーマあたり約100記事、40万語。主要モデルのコンテキストウィンドウに丸ごと収まる大きさで、index.md一つで全体をなめられる。ベクトルDBが本当に必要になる閾値は、思っているよりずっと遠い。
#ウィキを進化させる3つの動作
ウィキが一度作られて終わりの文書集だったら、ただの静的なアーカイブだろう。Karpathyのシステムが面白いのは、3つの動作が繰り返されてウィキが進化し続けるからだ。
- インジェスト(Ingest):新しい資料を
raw/に追加すると、LLMがそれを読んで要約し、既存のウィキの関連ページを更新する。1つの資料が10〜15ページに波及することもある。WebはObsidian Web Clipperで、PDFはDoclingやMarkerでマークダウンに変換して入れる。 - クエリ(Query):ウィキに対して複雑な質問を投げる。LLMが
index.mdから関連ページを見つけ、読み、相互参照しながら答えを合成する。結果はoutput/に積まれ、価値あるものはwiki/に戻る。 - リント(Lint):LLMがウィキ全体に対して健康診断を行う。ページ間の矛盾、欠落した相互参照、古くなった情報、新しい記事の候補を見つけ出す。コードにリンターがあるように、知識にもリンターがある。
インジェストが知識を入れ、クエリが検証し、リントが修正する。この循環が繰り返されるほど、ウィキは静的なアーカイブから生きたシステムへと進化する。
#異なる出発点、同じ結論
この方向に動いているのはKarpathyだけではない。
Shopify CEOのTobi Lütkeはqmdを公開した。ローカルで動くマークダウン検索エンジンだ。BM25の全文検索、ベクトルセマンティック検索、LLMのリランキングを組み合わせ、完全にローカルで実行される。Claude CodeのMCPサーバーとして統合され、AIエージェントのメモリバックエンドとしても使われる。
qmdとKarpathyのコンパイルは正反対に見える。一方は検索エンジンで、もう一方は「検索ではなくコンパイル」と宣言している。だが2つのアプローチは規模が違うだけで、同じ問題を解いている。ウィキがコンテキストウィンドウに収まる規模ならコンパイルで十分で、それを超えれば検索が必要になる。
『Building a Second Brain』の著者Tiago Forteも2026年にAI-firstへピボットした。元のBASBは「個人の知識管理」だったが、AI版は「個人のコンテキスト管理」と再定義した。核心はAIに適切な情報を適切なタイミングで渡すことだ。Karpathyのraw → wiki → outputがまさにこの構造だ。
#構造を支える技術
raw → wiki → outputという構造そのものに目新しさはない。新しいのは、LLM技術でこの構造を維持できるようになった点だ。3つの前提が2026年に揃った。
コンテキストウィンドウが拡張され、個人のウィキ規模(数十万語)をLLMが丸ごと読めるようになった。マークダウンがLLMのネイティブフォーマットになり、変換コストなしに直接読み書きできるようになった。そしてClaude CodeやCodexのようなエージェントがファイルを直接操作し始め、LLMが自ら読み、編集し、保存できるようになった。読むこと、読み書きすること、読み書きして維持すること。3つの前提が順に積み重なったのだ。
このうち本当の変曲点はコンテキストウィンドウではない。Gemini 1.5 Proは2024年2月の時点ですでに2Mトークンを提供していたが、それだけでは変化は始まらなかった。決定打になったのは、エージェントがファイルを直接操作できるようになったことだ。Claude CodeとCodex以前、LLMはコピー&ペーストでしかアクセスできず、メンテナンスは常に人間の仕事だった。ファイルシステムAPIが開いて初めて、ウィキはLLMの管轄に移った。
「検索ではなくコンパイル」というフレーミングを裏返せば、コンパイルはLLM自身がファイルを読み、書き、維持することを前提とする。ベクトルDBも独自APIも要らない。エンジニア(Karpathy)、経営者(Lütke)、理論家(Forte)がそれぞれの文脈から同じ結論にたどり着いたのはそのためだ。
LLMにはファイルシステムだけで十分だ。
実際に試してみたければ、KarpathyのGistをコピーして自分のLLMエージェントに貼り付けるところから始められる。
#参考資料
- Andrej Karpathy — LLM Knowledge Bases (X) — 元のツイート
- Karpathy — llm-wiki Gist (GitHub) — CLAUDE.mdパターン、index.md、log.mdの構造
- Hacker News — LLM Wiki, example of an “idea file” — コミュニティの反応
- VentureBeat — Karpathy shares LLM Knowledge Base architecture — RAGを回避するマークダウンライブラリの分析
- Tiago Forte — Introducing The AI Second Brain — BASBのAI-firstピボット
- qmd by Tobi Lütke (GitHub) — ローカルマークダウンのセマンティック検索エンジン
- Steph Ango — File over App — アプリは消えるがファイルは残る