LLM Wikiとは｜Karpathyの知識コンパイル手法・RAGとの違い・OSS実装の選び方を実測

2026年4月にAndrej Karpathyが公開した1枚のgistをきっかけに、日本語圏でも「llm wiki」という言葉の検索が跳ね上がった。LLM Wikiとは、知識を質問のたびに検索し直すのではなく、LLMに恒久的なMarkdownのWikiとしてコンパイルさせて残すという考え方だ。この記事では原典のgistが実際に何を言っているかを確認し、RAGとの違いを整理したうえで、実装候補として inkeep/open-knowledge を手元に入れて動かした結果まで載せる。

RAG側の全体像を先に押さえたい場合は、RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップを読んでから戻ってくると、この記事の比較が立体的になる。

LLM Wikiとは——Karpathyのgistが実際に書いていること

原典は gist.github.com/karpathy/llm-wiki。GitHub APIで確認したところ作成日は2026-04-04 16:25 UTCで、ファイルは llm-wiki.md 1枚だけだ。特定の製品でもライブラリでもなく、書き方のパターンを1ページにまとめた「アイデアファイル」である。

中核の主張はこうだ。生の文書とユーザーの間に、LLMが書いて維持する恒久的で積み上がる成果物（persistent, compounding artifact）としてのMarkdown Wikiを置く。質問のたびに文書を検索するのではなく、Wikiを少しずつ作り育てる。

・生ソース（raw sources）：記事・論文・画像など。書き換えない。原文のまま保存する
・Wiki：LLMが生成したMarkdown。要約・登場する固有名詞（エンティティ）・相互参照を持つ
・スキーマ：Wikiをどんな構造にし、どう運用するかを書いた設定文書

そして操作は3つ。

gistの中で最も引用されている一文は、知識ベース運用の本質を突いている——知識ベースを維持するうえで面倒なのは、読むことでも考えることでもなく、帳簿づけ（bookkeeping）の部分だ、と。そしてLLMはまさにその帳簿づけが得意なので、個人でも知識の継続的な整理が現実的になる、という論理構成になっている。

公開後の反応も大きく、gistは公開から2週間で5,000スター超・4,000以上のフォークに達したと各所で報じられた。日本語圏でも llm wiki の月間検索ボリュームは2026年3月の140から4月に12,100へ跳ね、以降1万前後で推移している（DataForSEO実測・日本／日本語）。gistの公開日と検索の立ち上がり月が一致しているため、この語の需要はKarpathyの投稿が起点だと言い切ってよい。

検索需要の推移も、この経緯と矛盾しない。DataForSEO（日本／日本語）で llm wiki の月別ボリュームを取ると次の通りで、gistが出た月に2桁から5桁へ跳ねている。

派生する llm wiki とは（90）・llm wiki 作り方（40）も計測されており、「言葉は知ったが、中身と作り方が分からない」層が実在することが数字にも出ている。以下ではその2つに順番に答えていく。

RAGとの違い——「毎回検索する」か「一度コンパイルして残す」か

LLM Wikiの説明でいちばん誤解されやすいのが、RAGの置き換えなのか、上位互換なのか、という点だ。gistの立場ははっきりしていて、違いは知識が残るかどうかにある。

RAGは質問時に検索するので、同じ論点を100回聞けば100回検索が走り、100回とも同じ整理をやり直す。LLM Wikiは取り込みの時点で要約と相互リンクを作ってしまうので、2回目以降の質問はすでに整理された成果物の上から始まる。ページ間の矛盾や陳腐化も、成果物があるからこそlintで検出できる。

一方で、この構造には代償もある。公平を期すために両方書いておく。

最後の行が実務上いちばん重い。RAGの失敗は「答えられない」で済むが、LLM Wikiの失敗は誤りが成果物として固定され、下流の全ページに伝播する。lintがオプション扱いでなく必須の運用工程として設計されているのはこのためだ。RAGの発展形との住み分けを整理したい場合は、RAGの進化｜Naive・Advanced・Graph・Agentic RAGの仕組みと選び方が比較の軸になる。

実装が同名で乱立している——star順に選ぶと目的が合わない

「じゃあ何で作るのか」で最初につまずく。gistがツールを指定していないため、同じ llm-wiki という名前のOSSが大量に生まれたからだ。GitHubのリポジトリ検索（star降順）で上位を並べると次のようになる（2026-09-01時点）。

カテゴリが全然違うものが同じ名前で並んでいる点に注意したい。デスクトップアプリ・Agent Skill・CLIコンパイラ・Obsidianプラグインが混在していて、star数の大小は「自分の用途に合うか」を何も教えてくれない。選ぶ軸は次のどれを重視するかで決まる。

・手元のエディタを変えたくない：Agent Skill型（karpathy-llm-wiki など）。既存のMarkdownフォルダにルールだけ足す
・Obsidianの金庫がすでにある：Obsidianプラグイン型。既存の資産を壊さない。当サイトではclaude-obsidianとは｜Obsidian金庫をAIが自己組織化する15スキルの中身で近い構成を扱っている
・GUIで書きたい・チームで共有したい：デスクトップ／Webアプリ型。以下で実測する inkeep/open-knowledge はここに入る
・バッチで一括生成したい：コンパイラ型（llm-wiki-compiler など）

なお、この記事で実測に使う inkeep/open-knowledge は名前に llm-wiki を含まないが、リポジトリのtopicsに llm-wiki-karpathy を掲げており、READMEも「For knowledge bases, LLM wikis, specs, and notes」と明記している。名前で検索していると見落とすタイプの候補だ。

実際に作る手順——OpenKnowledge v0.66.2 を入れて確かめた

ここからは実測。GPL-3.0・★3,789・TypeScript製で、デスクトップアプリ版とCLI＋Web UI版がある。今回はCLI版を使った。

まず最大の落とし穴から。READMEは Node.js 24+ が必要と書いているが、Node 22で公式手順を実行するとエラーも警告も出ないまま古い版が入る。

# Node 22.13.1 / npm 11.1.0 で実行した場合（NG）
npm install -g @inkeep/open-knowledge
#  → "added 239 packages" で正常終了する。EBADENGINE 警告も出ない
#  → 入るのは 0.2.0（2026-04公開）。bin は open-knowledge のみで `ok` が無い
ok --version   # → command not found

# Node 25.2.1 / npm 11.6.2 で実行した場合（OK）
npm install -g @inkeep/open-knowledge
ok --version   # → 0.66.2

npmの latest タグは 0.66.2（engines: >=24）を指しているのに、Node 22ではnpmがengines条件を満たす最も新しい版へ静かにフォールバックし、4か月前の 0.2.0 を選ぶ。engine-strict は false（既定）のままでこの挙動になる。READMEどおりに叩いて ok: command not found に遭ったら、まず node --version を疑うのが正しい。

Nodeの版がずれる問題は開発側でも認識されていて、GUI版に同梱される古いNodeがランタイム互換性チェックを素通りする不具合がIssue #1301として報告され、2026-08-20に修正されている（報告者はNode 24.13.0を入れていたのに内部エージェントが動かなかった、という内容）。「入っているNodeの版」と「実際に使われるNodeの版」が食い違いうるプロジェクトなので、ok --version が期待どおりかを毎回確かめる価値がある。

そのうえで、初期化はこうなる。

# 既存のMarkdownフォルダに対して実行する
cd your-notes
ok init --no-mcp --no-skills --content-dir .   # ← 下記の理由でフラグを付けている
ok preview                                     # 何が対象になるか読み取り専用で確認
ok start --port 8787                           # Web UIを 127.0.0.1 でだけ待ち受ける

--no-mcp --no-skills を推している理由は、素の ok init がホーム配下を書き換えるからだ。JSON出力で確認すると、MCP登録先として ~/.claude.json、~/Library/Application Support/Claude/claude_desktop_config.json、~/.cursor/mcp.json がuser スコープで挙がる。さらにスキル束が ~/.agents/skills/・~/.claude/skills/・~/.cursor/skills/ の3か所へインストールされる。プロジェクト単位の初期化コマンドが、マシン全体の設定に触る作りになっている。

なお ok init には --no-skills があるが、ok start には無い。実際、いったんスキルディレクトリを削除してから ok start を実行したところ、3か所とも再作成された（削除時刻より後のタイムスタンプで確認）。マシンを汚したくない場合は、この挙動を織り込んでおく必要がある。

サーバー自体は素直に立った。ok start --port 8787 から約20秒でHTTP 200を返し、既定では 127.0.0.1 のみにバインド、無操作30分でアイドルシャットダウンする設定だった。外部公開には別途 --external-url と明示的な同意が要る。

Karpathyの3層はUI上でどう表現されているか

ok start で開いたWeb UIには「スターターパック」があり、そこから初期構造を作れる。用意されていたのは Knowledge base / Software lifecycle / Codebase wiki / Plain notes / Open Knowledge Format / Writing pipeline / Personal CRM / Worldbuilding の8種類だった。

「LLM Wiki」という名前のパックは存在しない。READMEは「starter packs to create LLM Wikis, second brains」と書いているが、実際に該当するのは Knowledge base（Trusted articles from your sources）だ。名前で探すと見つからない。

このパックを実行すると、次のものが作られた（UIの表示は「3 folders・1 file・3 templates・3 skills」、完了トーストは「Knowledge base initialized (16 entries)」）。

各フォルダには .ok/templates/ 配下にテンプレート（clip.md / research-log.md / article.md）が置かれる。gistの3層に「research（途中段階）」を1つ足した4段構成になっているのが実装側の判断で、生ソースから確定記事へ一気に飛ばさず、暫定的な理解を置く場所を明示的に用意している。log.md の中身は「1ターンにつき1つの日付エントリを追記する監査証跡」と説明されており、gistのlintに相当する点検を人間が追える形にしたものだ。

パッケージ側の .ok/config.yml にも同じ思想がコメントとして書かれていて、この3段は「メンタルな足場であって、ファイルシステム上の強制ではない」と明記されている。既存の specs/ や docs/ がある場合はそちらを使ってよい、という立場だ。

コンテキスト常駐コストという見落としがちな代償

LLM WikiをAIエージェントから使うということは、MCPサーバーを接続しっぱなしにするということだ。ツールを1つも呼ばなくても、ツール定義はコンテキストに常駐し続ける。OpenKnowledgeのMCPサーバーを当サイトの共通プローブで測った。

# stdio で initialize → tools/list を投げ、応答のバイト数とトークン数を測る
printf '%s\n' \
 '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}' \
 '{"jsonrpc":"2.0","method":"notifications/initialized"}' \
 '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' \
 | ok mcp

結果は21ツール・153,900バイト・58,460トークン（Anthropic count_tokens。cl100k_base では39,710トークン）。当サイトが同じプローブ・同じトークナイザで測った8サーバーの中で最大だった。

ツール数と常駐コストは比例しない。ツール数62のBacklogが16,555トークンで済む一方、21ツールのOpenKnowledgeが58,460トークンを食う。内訳を見ると write ツール単体で6,782トークン、edit で4,754トークンあり、引数スキーマが大きいことが効いている。Markdownの編集を細かく制御するための設計上の帰結で、機能の裏返しでもある。

実務上は、LLM Wiki専用のセッションでだけ接続するか、他のMCPサーバーと同時接続しない運用が現実的だ。トークン数を書くときはトークナイザ名も併記しないと比較にならない点は付記しておく（cl100k_base と Anthropic count_tokens では同じ入力で1.35〜1.65倍ずれる）。

まとめ｜LLM Wikiを試すかどうかの判断軸

・LLM Wikiは製品ではなくパターン：原典はKarpathyのgist 1枚（2026-04-04）。生ソース／Wiki／スキーマの3層と ingest・query・lint の3操作
・RAGとは目的が違う：RAGは検索精度、LLM Wikiは知識の蓄積。取り込みが重く、元文書の更新への追随が弱い代わりに、質問が増えるほど成果物が育つ
・最大のリスクは誤りの定着：RAGは答えられないだけだが、LLM Wikiは嘘が成果物に固定され下流に伝播する。lintを運用に組み込めないなら手を出さない方がいい
・名前で探すと迷う：llm-wiki を冠したOSSはstar 17,160から700台まで並ぶが、デスクトップアプリ・Agent Skill・コンパイラ・Obsidianプラグインが混在している。star順でなく形態で選ぶ
・OpenKnowledgeを使うならNode 24+：Node 22だと警告なしで v0.2.0 が入る。ok init / ok start はホーム配下にスキルを書き込み、start には --no-skills が無い
・MCP常駐は58,460トークン：計測8サーバー中で最大。専用セッションで使う前提にする

まずは何もインストールせず、手元のMarkdownフォルダとAIエージェントだけで「生ソースを置く場所」「確定した記事を置く場所」「変更ログ」の3つを切って回してみるのが、いちばん安くパターンの当否を確かめられる。GUIやチーム共有が必要になった段階で、上の表から形態を選べばいい。

参照ソース

・karpathy/llm-wiki（原典のgist） — 2026-04-04公開・2026-09-01アクセス
・inkeep/open-knowledge — 公式リポジトリ・README（2026-09-01アクセス）
・OpenKnowledge Documentation — 公式ドキュメント（2026-09-01アクセス）
・@inkeep/open-knowledge (npm) — 版・engines・dist-tags の確認（2026-09-01アクセス）