Andrej Karpathy が GitHub に「ファイル1つ」をアップロードし、10時間で星1,700超・フォーク300超を記録した。コードでもアプリでもない、マークダウン文書1枚だ。名前は llm-wiki.md。この文書が提案するのは、LLM エージェントに個人ナレッジベース（Wiki）を継続的に構築・保守させるというパターンだ。
RAG の限界 — 毎回ゼロから読み直す問題
現在、多くの人が AI に対してやっていることは「ファイルを渡して要約させる」「質問のたびにドキュメントを検索させる」の繰り返しだ。これは RAG（Retrieval-Augmented Generation: 検索で補強した文章生成）と呼ばれる手法で、技術的には問題ない。
しかし Karpathy はこの方式を「毎日同じ本を初めて読む人に質問を投げるようなもの」と表現する。AI は昨日読んだ内容を今日忘れる。蓄積がない。5つの文書を横断して初めてわかる微妙な問いには、毎回断片をかき集めて一からつなぎ合わせる必要がある。
LLM Wiki のアイデア — 知識を「積み上げる」
Karpathy が提案するのは、AI にドキュメントを読ませるたびにWiki を更新させるというアプローチだ。
新しい資料を投入するたびに、AI は：
- 要約ページを作成する
- 既存のエンティティページ・概念ページを更新する
- 相互参照リンクを張る
- 矛盾があればフラグを立てる
- インデックスとログを更新する
つまり、知識は一度コンパイルされて保持され、クエリのたびに再導出されるのではない。Wiki は永続的で複利的に成長するアーティファクトになる。
三層構造
LLM Wiki のアーキテクチャはシンプルな三層構造だ。
1. Raw Sources（原本資料）
論文、記事、メモなど、ユーザーがキュレーションした元資料。AI はこれを読むだけで、絶対に変更しない。これが信頼できる唯一の情報源（source of truth）となる。
2. Wiki（知識ベース）
AI が生成・保守するマークダウンファイル群。要約ページ、エンティティページ、概念ページ、比較ページ、概要、統合的な考察など。ユーザーが読み、AI が書く。
3. Schema（設定）
AI に「この Wiki をどう管理するか」を伝える設定ファイル。Karpathy は AI エージェントの設定ファイル（CLAUDE.md や AGENTS.md）に置くことを推奨している。Wiki の構造、命名規則、取り込みワークフロー、回答フォーマットなどを定義する。
三つの基本操作
| 操作 | 内容 |
|---|---|
| Ingest（取り込み） | 新しい資料を投入し、AI に読ませて Wiki を更新させる。1つの資料で10〜15ページが更新されることもある |
| Query（質問） | Wiki に対して質問する。AI はインデックスから関連ページを探し、統合的に回答する。良い回答は新しい Wiki ページとして保存できる |
| Lint（保守） | 定期的に Wiki の健全性をチェックする。矛盾、古い記述、孤立ページ、欠落リンクなどを検出・修正する |
「アイデアファイル」という新しい共有形態
この llm-wiki.md が爆発的に広まった理由について、Karpathy 自身がこう述べている：
これは「アイデアファイル」だ。コードはない。インストールするものもない。このアイデアをあなたのエージェントにそのまま貼り付ければ、エージェントがあなたの状況に合わせて直接実装してくれる。
つまり、時代はアプリを共有するのではなくアイデアを共有する方向に動いている。受け取った人が実行するのではなく、受け取った人のエージェントが実行する。
オープンソースソフトウェアはコードを共有する。しかしコードは依然としてインストール・設定・保守が必要だ。アイデアファイルは違う。エージェントが環境・ワークフロー・好みに合わせて自律的に実装する。
実践的なツール構成
Karpathy の実際のワークフローは以下の通り：
- 左画面: AI エージェント（Claude Code など）
- 右画面: Obsidian（マークダウンエディタ）
- AI が Wiki を編集すると、Obsidian でリアルタイムに更新が反映される
Karpathy の表現が的確だ：「Obsidian は IDE、AI はプログラマー、Wiki はコードベースだ」
推奨ツール
- Obsidian Web Clipper: ブラウザの記事をマークダウンに変換して取り込む
- Obsidian Graph View: Wiki の構造と接続関係を可視化する
- Marp: Wiki コンテンツからスライドデッキを生成する
- Dataview: ページのフロントマターに対してクエリを実行する
- qmd: マークダウンファイル向けのローカル検索エンジン（BM25 + ベクトル検索）
なぜこのパターンが機能するのか
ナレッジベースの保守で面倒なのは、読むことでも考えることでもない。記帳作業だ。相互参照の更新、要約の最新化、新旧データの矛盾チェック、数十ページの一貫性維持。人間は保守コストが価値の成長を上回った時点で Wiki を放棄する。
LLM は飽きない。相互参照の更新を忘れない。1回のパスで15ファイルを更新できる。保守コストがほぼゼロになるから Wiki が維持される。
人間の仕事は、資料のキュレーション、分析の方向づけ、良い質問を投げること、そしてそれが何を意味するかを考えること。残りはすべてエージェントがやる。
まとめ
Karpathy の LLM Wiki は、技術的に新しいものは何もない。マークダウンファイルと AI エージェントがあればいい。しかしその「知識は積み上げるもので、毎回読み直すものではない」という発想の転換が、世界中の開発者の共感を呼んだ。
元ツイートの筆者はこの本質を的確に言い表している：
私たちはずっと「情報が多すぎて問題だ」と言ってきた。でも実は情報が多いことが問題ではなかった。情報がつながっていないことが問題だった。LLM Wiki はそのつなぐ作業を AI に任せるということだ。