Andrej Karpathy が2026年4月に公開した GitHub gist「LLM Wiki」が、公開から48時間以内に5000スターを超えた。コード一行も含まない、純粋にアイデアだけを記述したドキュメントがここまで反響を呼んだ理由はシンプルだ。「RAGの次」を具体的かつ実践的に示していたからである。

RAGとの決定的な違い

多くの人がLLMとドキュメントを組み合わせるとき、最初に試みるのが RAG（Retrieval-Augmented Generation） だ。ChatGPTのファイルアップロード、NotebookLM、LangChainで構築するベクトルDB検索 — これらはすべて「質問が来たときにドキュメントから関連部分を取ってきて回答する」という設計思想に基づいている。

この方式には根本的な問題がある。知識が蓄積されない。5つのドキュメントを横断する微妙な問いに対しても、LLMは毎回ゼロから関連箇所を探し出し、推論し直す。「矛盾」も「文脈」も「先週気づいた発見」も、次の質問では消えてしまう。

LLM Wiki が提案するのは根本的に異なるアプローチだ。

LLM が incrementally に永続的な wiki を構築・維持する。新しいソースを追加するたびに、LLM はそれを読み込んで既存 wiki に統合し、エンティティページを更新し、矛盾を記録し、進化する合成の全体を強化する。知識は毎回再導出されるのではなく、一度コンパイルされてから最新に保たれる。

この「コンパイルされた知識ベース」こそが LLM Wiki の本質である。

3層アーキテクチャ

LLM Wiki は3つの層で構成される。

1. Raw Sources（生ソース）

記事、論文、画像、データファイルなど自分がキュレートしたソースドキュメントの置き場。不変（immutable） — LLMはここから読むだけで決して書き換えない。これが「真実の源泉」となる。

2. The Wiki（wiki本体）

LLM が生成・維持するマークダウンファイルの集合。概要、エンティティページ、概念ページ、比較、合成。この層は LLM が完全に所有 する。あなたは読む側で、LLM が書く側だ。

3. The Schema（スキーマ）

CLAUDE.md（Claude Code用）や AGENTS.md（Codex用）など、LLMに wiki の構造・規約・ワークフローを伝えるドキュメント。これが LLM を「汎用チャットボット」から「規律あるwikiメンテナ」に変える鍵だ。このファイルはあなたと LLM が協力しながら進化させていく。

3つの操作

Ingest（取り込み）

新しいソースを生コレクションに追加して、LLMに処理を依頼する。LLMはソースを読み込み、重要な情報を抽出し、wikiに統合する。一つのソースが10〜15のwikiページを更新することもある。一度に大量のソースをバッチ処理することも可能だが、Karpathy 自身は「一つずつ取り込み、要約を確認しながら進める」スタイルを好むと述べている。

Query（クエリ）

wikiに対して質問する。LLMは関連ページを検索・読み込み、引用付きで回答を合成する。回答の形式は問いによって変わる — マークダウンページ、比較表、Marpスライド、matplotlibグラフなど。

重要な洞察: 良い回答はwikiに新しいページとして追記できる。「あの比較をお願いした結果」「見つけた新しい接続」— これらをチャット履歴に埋もれさせるのではなく、wikiに蓄積させることで探求が複利的に積み重なる。

Lint（健全性チェック）

定期的に LLM に wiki の健全性チェックを依頼する。

  • ページ間の矛盾
  • 新しいソースで更新が必要な古い主張
  • 内部リンクを持たないオーファンページ
  • 言及されているが独自ページのない重要概念
  • データギャップ（ウェブ検索で埋められる可能性のあるもの）

2つの特殊ファイル

これらの操作を支えるのが、以下の2つの特殊ファイルだ。wikiが成長するにつれて、LLMとあなたが全体をナビゲートするために機能する。

index.md（コンテンツ指向）
wiki内のすべてのコンテンツカタログ。各ページがリンク、一行サマリ、メタデータ（日付、ソース数など）付きで列挙される。LLMは毎回のingestで更新する。クエリ応答時はまず index.md を読んで関連ページを特定してからドリルダウンする。このアプローチは100ソース・数百ページ規模まで埋め込みベースのRAGインフラなしに機能する。

log.md（時系列記録）
append-only の操作ログ。ingest、クエリ、lintの記録が追記される。

1
2

# 最後の5エントリを確認
grep "^## \[" log.md | tail -5

Obsidian との組み合わせ

Karpathy は実際の運用スタイルとして、LLMエージェントを片側に、Obsidianをもう片側に開いている構成を紹介している。

LLMが会話に基づいて編集を加え、私はリアルタイムで結果をブラウズする — リンクを辿り、グラフビューを確認し、更新されたページを読む。Obsidianがthe IDE、LLMがthe programmer、wikiがthe codebaseだ。

Obsidianを活用するためのツール群:

  • Obsidian Web Clipper: Webページをマークダウンに変換するブラウザ拡張
  • Graph View: ページ間の接続を可視化し、ハブとオーファンを把握
  • Dataview: フロントマターのYAMLに対してクエリを実行する動的テーブル
  • Marp: マークダウンからスライドデッキを生成

なぜうまくいくのか

知識ベースの維持を困難にするのは、読んだり考えたりする部分ではなく「帳簿仕事（bookkeeping）」だ。相互参照の更新、サマリの最新化、新しいデータが古い主張に矛盾するときの記録、数十ページにわたる一貫性の維持。人間はwikiを放棄する。なぜなら「メンテナンスの負担が、得られる価値よりも速く成長する」からだ。

LLMはこれが苦にならない。一度に15ファイルを更新でき、相互参照の更新を忘れず、飽きない。

Karpathy はこのアイデアを1945年にVannevar Bushが提唱した Memex と関連づけている。Memexは「連想的な経路（associative trails）」でつながれた個人的・キュレートされた知識ストア — Webがなったものではなく、Bushが本当に描いていたビジョンに近い。Bushが解決できなかったのが「誰がメンテナンスするのか」という問題だった。LLMがその答えになる。

コミュニティの反応と新しい AI カテゴリ

このgistのコメント欄では、開発者たちが続々と独自の実装を共有し始めている。

  • 自分で更新し続ける知識ベース
  • 矛盾を自動検出するエンジン
  • 進化する「第二の脳」
  • 記憶を蓄積するエージェント

「LLM Wiki」という名前が示すのは、単なるデータ管理システムではなく、LLMがメンテナとして機能する新しいカテゴリのパーソナルナレッジツールだ。RAGがLLMとドキュメントの統合の「第一形態」だとすれば、LLM Wiki はその「第二形態」と言えるかもしれない。

実践のヒント

Karpathyが提示するいくつかの実践的なヒント:

  1. git repoとして管理: wikiはただのマークダウンファイルのgitリポジトリ。バージョン履歴、ブランチ、コラボレーションが無料でついてくる。
  2. 画像はローカルに保存: Obsidianでアタッチメントフォルダを設定し、Web Clipper後にショートカットで全画像をダウンロード
  3. ローカル検索: wikiが大きくなったら qmd（BM25/ベクトルハイブリッド検索、MCP対応）の導入を検討
  4. スキーマを育てる: CLAUDE.md は最初から完成している必要はない。LLMと協力しながら、ドメインに合った規約を徐々に進化させていく

おわりに

コード一行もなく、フレームワークも、リポジトリもない。ただのアイデアファイル。それが1ヶ月で5000スターを集めた。

LLM Wiki が示すのは「LLMを使って何かを検索する」から「LLMに知識を育てさせる」へのパラダイムシフトだ。RAGがLLMを図書館員として使うなら、LLM Wiki は図書館そのものをLLMに建てさせる。

gistのURLは https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f。「あなたのLLMエージェントにコピペして、一緒に具体的な実装を作っていく」という使い方を前提に書かれている。まさに、LLMとの協働作業のエントリポイントとして設計されたドキュメントだ。