LLM wikiとは？Karpathyが提唱したRAGと使い分ける新しいナレッジ管理パターンの実装手順まで解説

LLM wikiは、OpenAI共同創業メンバーで元Tesla AIディレクターのAndrej Karpathyが2026年4月4日にGistで公開した、LLMがマークダウンで書かれた永続的なナレッジベースを自律的にメンテナンスするパターンです。

「RAGは質問のたびに生ドキュメントから探し直す」という制約に対し、LLM wikiは取り込み時にLLMが要約・相互リンク・矛盾検出まで済ませ、質問時は完成済みwikiを読むだけで済む、という発想転換が特徴です。

Karpathyの原典Gistは公開から3ヶ月弱でStar・Fork合計1万超を集め、Claude Code向けプラグイン・OSSデスクトップアプリ・エージェント横断プラグイン／SaaS系と実装が続々登場しています（SaaS系は多くがローンチ前・料金体系未確定の段階です）。

本記事では、LLM wikiの定義・従来RAGとの構造的な違い・3層アーキテクチャと3つの操作・Claude CodeとObsidianでの実装ステップ・数値化された活用事例・実装で詰まる論点・RAGとの使い分け判断軸を、2026年7月時点の情報で体系的に解説します。

LLM wikiとは？Karpathyが提唱した「LLMがメンテするmarkdown wiki」パターン

LLM wiki（LLM Wiki）とは、LLMがmarkdownファイル群を永続的にメンテナンスするナレッジ管理パターンです。

OpenAI共同創業メンバーで元Tesla AIディレクターのAndrej Karpathyが2026年4月4日にGistで公開し、特定の製品ではなく任意のLLMエージェントに実装させる設計思想として提案されました。

2026年現在、LLM wikiは個人ナレッジ管理の実験段階から、AIエージェント時代における持続可能なナレッジ基盤の設計思想として再定義されつつあります。

原典Gistは公開3ヶ月弱でStar・Fork合計1万超を集め、Claude Codeプラグイン・OSSデスクトップアプリ（nashsu/llm_wiki 13.5k stars）・SaaS系実装が続々登場しています。

AIエージェント基盤としての現代的な役割

2020年代後半、LLMの性能向上によって「情報を貯めるインフラ」の意味が変わってきました。
人間が書いて人間が更新するwikiは、更新負荷が蓄積速度を上回った瞬間に破綻します。

• Karpathy
  Gist冒頭で「A pattern for building personal knowledge bases using LLMs」と定義し、生ソースをコード、wikiをビルド済みバイナリに見立てる設計思想を提示（原典Gist）
  
  

• 周辺実装
  nashsu/llm_wikiがGPL v3で13.5k stars、praneybehl/llm-wiki-pluginなどClaude Codeプラグインが公開から数ヶ月で相次いで登場

ここでのポイントは、LLMを常時稼働させる前提でナレッジ管理を設計し直す構造が浮上している、という点です。

LLM wikiは、取り込み・相互リンク維持・矛盾検出を含めた保守作業をLLMに任せる構造として設計されており、個人・小チームの持続的なナレッジ管理では、この新しい構造の方が実装ハードルが低いという評価も現れています。

LLM wikiとRAGの違い——質問時に探すか、取り込み時に整理しておくか

LLM wikiの位置づけを最も掴みやすい切り口は、RAGとの対比です。

両者は「LLMに大量の文書を扱わせる」という目的では共通しますが、知識をいつ整理するかが根本的に違います。

以下の表で、RAGとLLM wikiの構造的な違いを整理しました。

RAGは質問時のリアルタイム検索を強みとする代わりに、「5つの文書を統合しないと答えられない微妙な質問」が来るたびに、LLMが関連断片を集めて組み立て直す必要があります。同じ質問を100回受ければ、100回同じ合成を繰り返す構造です。NotebookLMやChatGPTのファイルアップロード機能、多くの社内RAG基盤はこの構造です。

一方LLM wikiは、新しいソースが来た時点でLLMがそれを読み、既存wikiの関連ページ10〜15枚を更新し、矛盾がある場合はフラグを立てます。

知識のコンパイルは一度きり、以降はコンパイル済みの成果物を読むだけ——Karpathy自身が「Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase（ObsidianがIDE、LLMはプログラマ、wikiがコードベース）」と表現している通り、生ソースをソースコード、wikiをビルド済みバイナリに見立てる発想です。

2026年のRAG進化系と併存する位置づけ

LLM wikiは「RAGを置き換える」わけではありません。2026年時点のRAGは、初期の naive RAG（ベクトル検索＋LLM）から大きく進化しており、以下のような系統が併存しています。

• GraphRAG — Microsoftが提唱。テキストからナレッジグラフを自動抽出し、コミュニティ階層でサマリ化。テーマレベルの質問に強い
• LightRAG — グラフ構造とベクトル表現を組み合わせ、low-level retrieval（特定エンティティと関係）＋high-level retrieval（広いトピック・テーマ）のdual-level構成で効率化するアプローチ
• LazyGraphRAG — Microsoftが公開したGraphRAGの派生。indexingコストを従来の約0.1%、global queryコストを約1/700に抑える構造で、大規模データでも導入ハードルが下がる
• Adaptive RAG — クエリ分類器がクエリごとに最適な検索戦略にルーティング
• Agentic RAG — LLMエージェントが複数の検索戦略を動的にオーケストレーション
  
  

これらは基本的に「質問時により賢く探す」方向の進化です。LLM wikiは「取り込み時により賢く整理しておく」方向の進化で、目的地が違います。

GraphRAGとLLM wikiは「知識を構造化して持つ」という点で近い発想ですが、GraphRAGはグラフDB＋アルゴリズミックな集約、LLM wikiはmarkdown＋LLMによる編集、と実装レイヤーが異なります。

実務では、大量高頻度検索が必要な社内基盤ならAgentic RAG＋GraphRAG、個人研究や中規模チームの持続的ナレッジ管理ならLLM wiki、という使い分けが自然です。詳細な判断軸は「LLM wikiとRAGの使い分け判断軸」で整理します。

LLM wikiの3層アーキテクチャ

Karpathyが原典Gistで示すLLM wikiは、Raw sources／Wiki／Schemaの3層構造で成り立ちます。この3層は「誰が編集するか」の権限がはっきり分かれており、LLM wikiが破綻しないための骨格になっています。

以下の表で、3層それぞれの役割と編集主体を整理しました。

この分業が徹底できるかどうかが、LLM wikiの実運用が続くかを左右します。特にRaw sourcesを「不変」に保つ規律が重要で、LLMに生ソースを書き換えさせると、後から出典を追跡できなくなります。

Raw sourcesが「不変」であることの意味

Raw sourcesは、Webから切り抜いた記事・購入したPDF・議事録・会議記録音の書き起こしなど、あなたが自分の意思で集めたソース群です。LLMはこれを読むだけで、絶対に書き換えません。

この不変性が担保されると、wiki上のどんな主張についても「元ソースはRaw sourcesのこのファイル」と追跡可能になります。

半年後にwikiのある記述に疑義が生じても、Raw sourcesを見直せば真偽を再検証できます。一方、生ソースをLLMに書き換えさせてしまうと、「wikiが正しいかどうかを検証する術がwiki自身にしかない」という循環参照が起きて、事実確認が不可能になります。

Wikiは「LLMが所有する成果物」

Wikiは、LLMがRaw sourcesを読んで生成したmarkdownファイル群です。人間はこれを読むだけで、直接編集することは推奨されません。人間が手を入れると、LLMが次回のingest時に「なぜこの記述があるのか」を追跡できなくなり、wikiの整合性が崩れます。

wikiには以下のようなページが含まれます。

• ソース1本ごとの要約ページ
• エンティティページ（人物・組織・製品などの固有名詞ごと）
• 概念ページ（技術用語・手法などの抽象概念ごと）
• 比較ページ（複数のエンティティや概念を並べて論じるページ）
• overviewページ（ドメイン全体の俯瞰）
  
  

これらのページは、Karpathy推奨の[[wikilink]]形式で相互接続されます。Wikipediaと同じ、二重角括弧でページ名を書くだけの記法で、[[Karpathy]] や [[LLM Wiki]] のように書けます。

リンクが未作成のページを指していても構いません——「後で書く」マーカーとして機能するので、LLMが次のingest時に埋めていくことができます。

Schemaは「LLMを規律あるwikiメンテナに仕立てる」設定

3層の中で最も見落とされやすいのがSchemaです。SchemaはCLAUDE.md（Claude Code向け）やAGENTS.md（Codex向け）といったファイルに書かれ、以下のような内容を含みます。

• wikiのディレクトリ構造
• ページ命名規則
• YAML frontmatterの規約
• 新ソースを取り込む時のワークフロー
• 質問に答える時のワークフロー
• Lint（健全性チェック）のワークフロー
  
  

Schemaがない状態でLLMにwikiを任せると、LLMは毎回違う流儀でファイルを作り、命名がバラバラで、リンクの張り方も統一されず、結局「散らかったmarkdownの山」ができます。

Schemaは、LLMを汎用チャットボットではなく、規律あるwikiメンテナに仕立てるためのルールブックです。詳細はCLAUDE.mdの解説記事も参照ください。

運用上のコツは、Schemaを最小構成から始めて育てることです。最初から網羅的なSchemaを書こうとすると、実運用で発生する例外や運用改善を反映しづらくなります。

1〜2ページで始めて、ドメインごと・プロジェクトごとに何が効くかを人間側で試行錯誤しながら追記していく——SchemaはLLMと一緒に育てていく生き物として扱うのが実運用のコツです。

LLM wikiの3つの操作とindex／log

LLM wikiの日常運用は、**Ingest（取り込み）／Query（質問）／Lint（健全性チェック）**の3操作をループで回すことで成り立ちます。加えて、index.mdとlog.mdという2つの特殊ファイルが、wikiの成長を支えます。

Ingest：新ソース1本で10〜15ページを更新する

Ingestは、新しいソースを取り込む操作です。あなたが記事・論文・議事録などをRaw sourcesに投入して、LLMに「これを取り込んで」と指示すると、LLMは以下のフローを実行します。

1. ソースを読む
2. あなたと重要ポイントを議論する
3. wikiにソースごとの要約ページを新規作成
4. index.mdを更新
5. 関連する既存のエンティティページ・概念ページを更新（1ソースで10〜15ページに触ることが多い）
6. log.mdに取り込み記録を追記
   
   

Karpathy自身は「1ソースずつ取り込んで自分で介入する」流儀を推奨しています。要約を読んで、更新内容をチェックし、LLMに「ここはこう強調してほしい」「この記述は削って」と指示しながら進めるスタイルです。

一方で、大量のソースを一括で機械的に取り込むバッチ運用も可能で、そちらは監視工数が減る代わりに品質のばらつきを許容する必要があります。この使い分けをSchemaに書き込むと、次回以降のセッションでも一貫した運用ができます。

Query：質問への回答を「新しいwikiページ」として蓄積する

Queryは、wikiに対して質問する操作です。LLMは以下を実行します。

1. index.mdを読んで関連ページを特定
2. 該当ページをwikiから読む
3. 引用付きで回答を合成
   
   

回答の形式は、質問の性質に応じてmarkdownページ・比較表・スライドデッキ（Marp）・グラフ（matplotlib）・キャンバスなど多様に取れます。

Queryで特に重要なのは、良質な回答をwikiの新しいページとして書き戻せる点です。

あなたが依頼した比較・分析・発見された関連性——こうしたexplorationの成果は、通常のチャットだと会話履歴に消えていきますが、LLM wikiではwikiに定着させることで、取り込んだソースと同じように今後の質問への回答の材料になります。質問への回答自体がナレッジベースを成長させる——これがLLM wikiの複利効果の源泉です。

Lint：矛盾・stale・orphanを定期的に検出

Lintは、wikiの健全性を定期的にチェックする操作です。LLMに以下を洗い出させます。

• ページ間の矛盾（新しいソースが古い記述を覆している場合など）
• stale claim（新しいソースで既に否定された記述が残っている）
• orphan page（どこからもリンクされていないページ）
• 概念名だけ出て個別ページがない項目
• 相互リンクの抜け
• Web検索で埋められそうなデータギャップ
  
  

Lintは、LLM wikiが数百ページ規模に成長しても健全な状態を保つための操作です。

LLMは「調べるべき新しい問い」「追加で読むべきソース」を提案してくるので、Lintの出力自体が次のIngestキューになります。人間が定期的にLintを回すか、cronで自動化するかはSchemaで規定します。

index.mdとlog.mdの役割分担

wikiが数十ページを超えると、LLM自身が「今どこに何があるか」を把握できなくなります。これを支えるのがindex.mdとlog.mdの2ファイルです。以下の表で、両者の役割を整理しました。

index.mdは、Karpathyによれば約100ソース・数百ページ規模までなら埋め込みベクトル検索を使わずに機能します。LLMがQuery時に真っ先にindex.mdを読み、そこから関連ページに深掘りする流れで、RAGインフラを立てずに済むのが実装コストの低さに直結しています。log.mdは「grep "^## [" log.md | tail -5」のようなunix標準ツールでパースできる形式に整えると、「直近5件の作業履歴」を秒で取り出せます。

規模が大きくなってきた場合は、tobi/qmd（Shopify CEO Tobias Lütke氏開発のローカル検索エンジン）を導入する手があります。

qmdはBM25＋ベクトル検索＋LLM再ランキングを全てオンデバイスで実行し、CLIとMCPサーバーの両方に対応しているため、LLMが自然にツールとして呼び出せます。

LLM wikiの実装ツール選定——Gist自作／プラグイン／デスクトップアプリ／SaaSの4系統

LLM wikiは概念であって特定製品ではないため、実装ツールは複数の系統があります。

以下の表で、代表的な4系統を整理しました。

「Karpathy Gistを直接コピー」は、実装コストが最も高い代わりに自分の運用ルールを細部まで設計できます。

Karpathyは「このGistの目的は特定の実装を示すことではなく、パターンを伝えることだ」と明言しており、細部はドメインごとに違っていて構わないという設計思想です。

Claude Codeプラグイン系はセットアップ最速

Claude Codeプラグインの代表格は、praneybehl/llm-wiki-pluginのようにスラッシュコマンド6本＋スキル＋マーケットプレイスマニフェストが同梱されて「/plugin marketplace add」と「/plugin install」の2コマンドでセットアップできる形態です。プラグインが提供する典型的なコマンドは以下です。

• 「/wiki:init」— wikiフォルダ・スキーマ・設定ファイルを初期生成
• 「/wiki:ingest」— Raw sourcesから新ソースを取り込む
• 「/wiki:query」— wikiに質問して回答を得る
• 「/wiki:lint」— 矛盾・stale・orphan等を検出
• 「/wiki:stats」— wikiの規模統計を表示
• 「/wiki:graph」— wikilinkのグラフビューを生成
  
  

dair-ai wiki-builderは、7種類の「フレーバー」（research／paper／domain／product／person／organization／project）を持ち、ドメイン別のwiki初期構造を選択できるのが特徴です。実際のデモでは「Agentic Engineering Wiki」を数時間で構築し、51件のtips（7カテゴリ）・9社の企業プロフィール・10本の論文要約・14件のOSSツール情報を生成しています。

デスクトップアプリ系は非エンジニアでも使える

デスクトップアプリの代表はnashsu/llm_wiki（GPL v3、13.5k stars、v0.5.4 2026年6月30日リリース時点）です。macOS（Apple Silicon＋Intel）／Windows／Linuxのクロスプラットフォームで、以下の機能を持ちます。

• 2段階の思考連鎖型インジェスト（分析→生成）
• マルチモーダル画像抽出
• ナレッジグラフと関連性モデル（4シグナル）
• ベクトル検索
• ディープリサーチ機能
• Chrome拡張機能（Webクリッパー）
• ローカルHTTP API＋MCPサーバー
  
  

対応LLMはOpenAI／Anthropic／Google／Ollama／カスタムエンドポイントと幅広く、ローカルLLM（Ollama）でも動作するためオフライン・オンプレ環境での利用が可能です。

GUIから使えるのでコマンドラインに慣れていない非エンジニアでも運用でき、業務チームでの導入で採用されやすい選択肢です。

料金の見方——「wikiツール自体」と「LLM側のAPIコスト」は別

LLM wikiの実装ツールは4系統いずれも本体は無料またはOSSですが、実際のコストはLLM側のAPI消費で決まります。以下の表で、コスト構造を整理しました。

ローカルLLM（Ollama）で運用すれば、APIコストはゼロに抑えられますが、モデル性能とのトレードオフになります。

実運用でよく採用されるのは、Ingestは高性能クラウドLLM（ClaudeやGPT-5系）、Queryは軽量モデル、という使い分けです。

Claude Code＋ObsidianでのLLM wiki実装ステップ

ここからは、Karpathyが原典Gistで示した「ObsidianをIDE frontendとして使う」考え方を、Claude Codeで実装する構成の具体的な手順を整理します。

Karpathy自身が「Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase」と表現している通り、Obsidianを閲覧・グラフビュー用のIDEに、LLMエージェントをwikiの執筆担当に据える発想です。

LLMエージェント側はClaude Code以外にOpenAI Codex・OpenCode／Piなども候補になりますが、本記事では最も普及しているClaude Codeを例に整理します。

Step 1：Obsidianでvaultを作成

まずObsidianをインストールし、新規vaultを作成します。ローケーションは「~/Documents/llm-wiki」のように後から探しやすい場所を選びます。

vault内に以下の3フォルダを作成します。

• 「raw/」— 生ソース（PDF・記事クリップ・議事録等）を投入する場所
• 「wiki/」— LLMがコンパイル済みmarkdownを書き込む場所
• 「raw/assets/」— ソースに付属する画像ファイルの保存先
  
  

Obsidian Web Clipperブラウザ拡張を入れると、Web記事を1クリックで「raw/」にmarkdownとして取り込めます。

あわせてObsidianのSettings→Files and linksで「Attachment folder path」を「raw/assets/」に固定すると、画像も一括ローカル保存できるようになり、Karpathy推奨のOff-lineファーストな運用ができます。

Step 2：CLAUDE.mdでSchemaを設計

vault直下にCLAUDE.mdを作成し、Schemaを書き込みます。最低限、以下の項目を含めます。

• wikiのディレクトリ構造とページ命名規則
• YAML frontmatterの規約（title・type・source・date・tags・confidence等）
• Ingest時のワークフロー（何を要約するか・何ページ更新するか・log.mdの書き方）
• Query時のワークフロー（index.mdをまず読む・引用付き回答・回答をwiki化するか判断）
• Lint時のワークフロー（何を検出するか・どのくらいの頻度で回すか）
  
  

実務上は、最初から網羅的なSchemaを書こうとせず、1〜2ページの最小構成で始めて、運用しながら足りない項目を追加していく育て方が推奨されます。

CLAUDE.mdの詳しい書き方はCLAUDE.md解説記事を参照ください。

Step 3：Claude Codeでvaultを開いてIngest→Query→Lintを回す

Obsidian vaultのフォルダをClaude Codeで開くと、Claude Codeがvault全体を認識します。あとは自然言語で以下のような指示を出すだけです。

• 「「raw/2026-07-03-article-on-llm-wiki.md」を取り込んで、関連するエンティティページ・概念ページを更新して」
• 「LLM wikiとRAGの実運用における違いをまとめて」
• 「wikiの健全性チェックを回して。矛盾・orphan・stale claimを検出して」
  
  

Claude Codeは、CLAUDE.mdに書かれたSchemaを読み、そのルールに従ってIngest／Query／Lintを実行します。

実行中は隣にObsidianを開いておくと、更新されるページをリアルタイムで確認しながら「ここはこう強調してほしい」と割り込みで指示できます。

Step 4：hookで自動化（SessionStart／post-commit）

Claude CodeのHooks機能を使うと、自動化を追加できます。よく使われるパターンは以下です。

• SessionStart hook
  Claude Codeセッション開始時と「/clear」実行後に、「wiki/index.md」の先頭60行と「wiki/log.md」の末尾15行を自動でコンテキストに投入する。これにより、セッション開始時点でClaude Codeが「wikiに何があるか・直近何をやったか」を把握した状態からスタートできる
  
  

• post-commit git hook
  コードやスキーマがcommitされたタイミングでClaude Codeを裏で起動し、影響を受けるwikiページを自動更新する。手動でingestを指示しなくてもwikiが常に最新になる
  
  

Claude Codeの「.claude/settings.json」にhooksを定義しておけば、後続のセッションでも自動的に発火します。

詳しいhook設定はClaude Code Hooks解説記事を参照ください。

Step 5：CLAUDE.mdに「wiki優先確認」の1行を必ず入れる

CLAUDE.mdに書くべき最重要の1行があります。

Always check wiki/ before answering questions about this project's architecture, patterns, or decisions.

このルールがないと、Claude Codeはコードを直接読み始めてしまい、せっかく整備したwikiを活用しません。

この1行があると、Claude Codeはまずindex.mdを開き、関連ページを読み、その上で回答するようになります。HackerNoonで6プロジェクト運用を実装した著者も「これこそがトリガー。他のすべてはこの1行の派生」と評価しています。

Step 6：規模が大きくなったらqmdで検索を強化

vaultが数百ページを超えると、index.mdだけでは目当てのページに辿り着けないケースが増えてきます。この段階でtobi/qmdを導入します。qmdは以下を提供します。

• ローカル動作のBM25＋ベクトル検索＋LLM再ランキング
• CLIとして呼び出せる（Claude Codeがshell out可能）
• MCPサーバーとしても動作（Claude Codeがネイティブツールとして利用可能）
  
  

qmdを組み込むことで、wikiが数千ページ規模になっても、質問に対する探索候補の絞り込みが効きやすくなります。

この段階まで来たら、Claude CodeのAgent Skillsとしてwiki操作をパッケージ化するのも有効です。プロジェクトごとに再利用できるスキルとして切り出せます。

LLM wikiの活用事例と数値効果

LLM wikiは提唱から3ヶ月弱の新しいパターンですが、既に定量的な効果が報告されている事例が積み上がってきています。

本セクションでは、代表的な3事例を数値ベースで整理します。

HackerNoon実践例：6プロジェクト運用で4並列25分（従来100分・75%短縮）

HackerNoonに公開された実装例（2026年4月21日公開）では、著者が6プロジェクトの日常運用にLLM wikiを組み込み、以下の数値効果を報告しています。

• 中規模プロジェクト（21モデル）で約25wikiページを10分で生成
• Claude Codeのサブエージェント機能で4プロジェクトを並列処理し25分で完了（従来100分・75%短縮）
• 519ファイルを処理してplans／technical-debt／roadmapを構造化。151タスクファイルを優先度付きtechnical debt registerに整理
• SessionStart hookで「wiki/index.md」の先頭60行と「wiki/log.md」の末尾15行を自動投入することで、セッション開始時から高品質な回答を得られる状態を実現
  
  

この著者が「これが最重要」と強調するのが、CLAUDE.mdに書く「Always check wiki/ before answering questions about this project's architecture, patterns, or decisions.」の1行です。

この1行の有無で、Claude Codeがwikiを活用するか、毎回コードを直接読み始めるかが分岐します。実務でLLM wikiを立ち上げるなら、まずこの1行を書くことが最短の第一歩です。

nashsu/llm_wiki：クロスプラットフォームOSSが13.5k stars

デスクトップアプリ実装のnashsu/llm_wikiは、公開後わずか数ヶ月で13.5k starsを集めています。GPL v3で公開されており、v0.5.4（2026年6月30日リリース時点）でmacOS／Windows／Linuxの3プラットフォームをカバー。ローカルHTTP APIとMCPサーバーを備え、既存のLLMエージェントから外部ツールとして呼び出せる設計です。

これはCLI操作に慣れていない層でもLLM wikiに参入できることを示しており、社内チームで実装する場合の有力候補になります。

特にローカルLLM（Ollama）対応があるため、機密度の高い社内情報を外部APIに送らずに扱えるのは、金融機関・製造業・自治体等の環境で決定的な選択理由になります。

Karpathyオリジナルgist：公開3ヶ月弱でStar・Fork合計1万超

Karpathyの原典Gistは、2026年4月4日公開から3ヶ月弱でStar 5,000+・Fork 5,000+（合計1万超）を集めています。加えて、Karpathyが先行してX（旧Twitter）に投稿したLLM wiki関連のポストは、複数の技術メディアで16M+ viewsに達したと報じられています。

この認知度の急拡大は、単なる話題性ではなく、「RAG基盤を作らずに個人・小チームでLLMをナレッジ管理に使いこなす」という実装コストの低さが刺さった結果です。

Gistのコメント欄には trip2g・mindmux.ai・projectbrain.md・equational-applicationsの「core-llm-wiki」・Qijuなど、公開直後から周辺OSS実装が続々と投入されており、エコシステムとして育っています。

想定される活用シーン

Karpathyが原典Gistで示した典型的な活用シーンは以下です。

• 個人：自己目標・健康・心理・自己改善のトラッキング。ジャーナル・記事・ポッドキャストメモを積み上げ、時間をかけて自分の全体像をwiki化
• 研究：特定テーマを数週間〜数ヶ月かけて深堀り。論文・記事・レポートを積み上げ、仮説（thesis）を進化させながら包括的wikiを構築
• 読書：本の章ごとにファイリング。キャラクター・テーマ・プロットの相互リンクをLLMがメンテナンス。読了時にはリッチな「コンパニオンwiki」が完成
• ビジネス／チーム：LLMが常時メンテナンスする社内wiki。Slackスレッド・議事録・プロジェクト文書・顧客通話がソース。人間はレビューだけ
• 競合分析・DD・旅行計画・講義ノート・趣味の深堀り：知識を時間をかけて蓄積し、散らかさずに整理したい任意のドメイン
  
  

このリストが示すのは、LLM wikiは「ドメイン固有の特殊ツール」ではなく、任意の長期蓄積型ナレッジ管理に汎用的に適用できるという点です。

企業導入の観点で言えば、製造業のナレッジマネジメントにおける暗黙知の形式知化や、営業チームでの案件履歴の蓄積など、既存のナレッジ管理課題への横展開が現実的な選択肢になります。

LLM wikiの限界と実装で詰まる論点

LLM wikiは強力なパターンですが、実装時に必ずぶつかる制約と落とし穴があります。本セクションでは、Gistのコメント欄・実装者ブログ・実運用検証で浮かび上がった主要な論点を整理します。

Taxonomy drift——「Company」「company」「Business」「Organization」の揺れ

Karpathy Gistのコメント欄で複数の実装者が指摘しているのが、**taxonomy drift（分類揺れ）**の問題です。LLMは同じ概念に対して、実行タイミングごとに「Company」「company」「Business」「Organization」「firm」など違うラベルを付けます。

これはwikiが小規模なうちは問題になりませんが、数百ページ規模で「企業一覧ダッシュボード」のようなUIを構築しようとした瞬間に、ラベルの不揃いが顕在化します。対策としては、以下のアプローチが提案されています。

• Seeded Ontology：Schemaに許容される関係性の初期リスト（例：「['client', 'employed_by']」）を明示し、LLMをその範囲に制約する（Strict Mode）
• Emergent Mode：LLMに関係性の命名を自由に任せつつ、生成された用語をontology_manifestに記録して人間が後追いレビュー
• Off：関係性の正規化を諦め、フラットなsemantic factだけ蓄積
  
  

Karpathy自身は「Schemaはあまり厳密にすると柔軟性を失う」というスタンスで、原典Gistでは意図的に抽象的に留めています。

実運用ではEmergentから始めて、規模が拡大したタイミングでStrictへ移行する段階的アプローチが現実的です。

画像扱いの制約——LLMはmarkdownとinline imagesを一度に読めない

Karpathyが原典Gistで明記している技術的制約が、LLMはmarkdownとinline imagesを1回のパスで読めないという点です。画像を含む記事を取り込む場合の回避策は以下です。

1. LLMがまずテキスト部分を読む
2. 参照されている画像を別途「画像を見せる」形で提示する
3. LLMが画像のコンテキストを追加して要約を更新する
   
   

このワークフローは若干手間ですが、実運用可能な範囲です。画像の多い技術記事や、図表主体のレポートを扱う場合は、この2段階プロセスをSchemaに明記しておくと運用が安定します。

トークン消費——頻繁なIngestは無視できないコスト

1ソースのIngestで10〜15ページを更新する構造上、大量ソースを日常的に取り込むとLLM APIコストが線形に増加します。

ソース1本あたりの実コストはモデル・ソース長・更新ページ数・為替で大きく変動するため、本運用に入る前に小規模パイロット（例：10ソースを実データで取り込んで実測）で見積もりを取ってから月次予算を組むのが安全です。

コスト削減の主な手は以下です。

• モデル分離：Ingestは高性能モデル（Claude Opus・GPT-5系）、Queryは軽量モデル（Claude Haiku・GPT-5 mini等）
• バッチingest：まとめて処理することでプロンプトのオーバーヘッド共有
• ローカルLLM併用：Ollamaで動作する中規模モデルを個人利用ではメイン、機密性の高い社内利用ではオンプレLLMをメイン
  
  

Claude Codeの利用料金プランについてはClaude Codeの料金ガイドで詳しく扱っています。

スケール限界——数百ページを超えたら検索エンジンが必要

Karpathy自身が「index.mdだけで運用できるのは約100ソース・数百ページまで」と明記しています。それを超える規模では、tobi/qmdのようなローカル検索エンジンの導入が必要です。

さらに大規模（数千ページ〜）になると、wikiそのものを複数の「サブwiki」に分割するアーキテクチャが浮上します。

ドメイン別・プロジェクト別に切り分け、共通のindex.mdを持たせて連邦（federation）する形です。Gistコメント欄でtrip2gが提案する「MCP経由の連邦wiki」もこの発想の実装例で、複数チームで別々のvaultを維持しつつ、Claude・Cursor・Codexなど各エージェントが1つのMCPエンドポイントから串刺しで検索できる構造です。

チーム利用時のガバナンス——誰が何を書けるかの権限設計

LLM wikiを個人利用ではなくチーム・組織で運用する場合、以下の論点が新たに発生します。

• Raw sourcesへの投入権限：誰でも自由に投入させると、確度の低い情報がwikiに混入
• Wiki上での人間介入の可否：Karpathyは「人間が編集しない」を推奨するが、チーム運用では誤情報の緊急削除などで人間の直接編集が必要になるケースが出る
• Schemaの更新権限：Schemaを気軽に変えるとwiki全体の整合性が崩れる
• 監査ログ：log.mdだけでなく、git履歴で追跡可能にする
• 機密情報の扱い：外部APIを使うと機密がベンダーに渡る。オンプレLLMやローカル運用が必要になるケース
  
  

これらは技術論というより組織設計の話で、LLM wikiを本格的にチーム導入する場合はSchema設計と並行してガバナンス設計を進める必要があります。

LLM wikiの導入検討は「技術検証」よりも「情報の権限設計」に時間がかかるケースが想定されます。

拒否挙動の揺らぎ——LLMのセーフガードは決定論的ではない

これはLLM wiki固有ではなく全LLMベースシステムの話ですが、LLMのIngest／Query／Lintの挙動は完全に決定論的ではないという点も押さえておくべきです。

同じソースを同じSchemaで取り込んでも、実行ごとに要約の焦点が微妙に違うことがあります。

これはwikiが「客観的な真実の保管庫」ではなく、「LLMが解釈した知識の合成物」であることを意味します。重要な意思決定に使う場合は、wikiの記述だけを根拠にせず、Raw sourcesを併読して検証するリテラシーが求められます。この点で、Raw sourcesを「不変」に保つ規律が長期的に効いてきます。

LLM wikiとRAGの使い分け判断軸

LLM wikiとRAGは競合ではなく、扱う情報の性質と業務要件によって使い分けるべき道具です。AI総研の支援現場では、以下のケース別判断軸で使い分けています。

以下の表で、状況別の推奨を整理しました。

この表の背景を、次の3つの観点で整理します。

①「情報が育つ性質か、都度検索する性質か」で分ける

LLM wikiが最大効果を発揮するのは、同じテーマに対して時間をかけて知識が積み上がる性質の情報です。研究プロジェクト・自己啓発・長期の競合分析・読書ノートなどは典型で、ソースが月ごと・週ごとに追加され、wikiが少しずつリッチになっていきます。

一方、都度検索が主目的の情報——たとえば大量の製品マスターやFAQデータベース——は、LLM wikiに向きません。

RAGのほうが構造化されたデータをそのまま扱えるためです。「情報が育つか、都度引くか」を最初に判定するのが第一歩です。

②「規模」と「クエリ頻度」で切り分ける

Karpathyが原典で示した目安は「約100ソース・数百ページまでならindex.mdだけで運用可能」でした。これを超えて数千ページ規模になり、かつ多数のユーザーが同時にクエリを投げる社内基盤では、Agentic RAG＋GraphRAGの組み合わせが優位になります。GraphRAGはコミュニティ検出でテーマレベルの質問に強く、Agentic RAGはクエリごとに検索戦略を動的に選択します。

一方、規模が中程度（数百ページ以内）で、クエリ頻度が低い〜中程度なら、LLM wikiの優位が変わりません。

RAG基盤を立てるコストと維持工数を考えると、LLM wikiの実装コストの低さが決定的な差になります。

③「機密度」で判断する

外部APIに情報を送れない業種（金融・医療・防衛・重要インフラ）では、LLM wikiのオンプレ・ローカルLLM運用のしやすさが優位に働きます。
nashsu/llm_wikiのようなデスクトップアプリはOllamaでローカルLLMに接続できるため、機密情報を外部に送らずに運用可能です。

RAGでも同じ運用は可能ですが、通常はベクトルDB＋LLMの2コンポーネントを両方オンプレで構築する必要があり、実装コストがLLM wikiより大きくなります。

「機密度が高い＋規模は中程度」という組み合わせは、LLM wikiの最も刺さる領域です。

AI総研としての推奨——「まずLLM wikiで始めて、必要になったらRAGを足す」

多くの企業で現実的な進め方は、LLM wikiから始めて、規模拡大や検索要件でRAGが必要になった段階で併用に移すアプローチです。理由は以下の3つです。

• LLM wikiは実装コストが低く、PoCの立ち上げが最速
• Ingestで整理されたwiki自体が、後でRAGを足す際の一次入力として再利用できる
• 「wikiでは何が足りないか」を実運用で把握してから、必要な機能だけをRAGで補える
  
  

逆に、いきなり大規模RAG基盤を構築してから「もっと構造化された整理が必要だった」と気づくと、RAG基盤の作り直しになり損失が大きくなります。

特に社内ナレッジ管理の再設計案件では、LLM wikiで運用ループを回して要件を明確化してから、必要ならGraphRAGやAgentic RAGを段階的に足す進め方が、失敗の少ないルートです。

LLM wikiだけで終わらせず、社内のナレッジ活用を業務に定着させる

PoCから全社展開までの設計を1冊で

LLM wikiで整理したナレッジを、実際の業務プロセスに組み込むには何をすべきか。AI業務自動化ガイド（220ページ）では、PoC段階から全社展開までの進め方、部門別ユースケース、AI運用における統制・セキュリティのチェックポイントまで整理しています。

▶ 無料でダウンロード

まとめ

本記事では、Andrej Karpathyが2026年4月に提唱したLLM wikiパターンについて、定義・RAGとの違い・3層アーキテクチャ・3操作・実装ツール・Claude Code＋Obsidianでの実装ステップ・活用事例・限界・使い分け判断軸を、2026年7月時点の情報で整理しました。要点を改めて整理します。

• LLM wikiは「RAGを置き換える」のではなく「取り込み時にLLMが整理しておく」パターンで、質問時に生ドキュメントを毎回探し直すRAGとは目的地が違う。両者は使い分け対象
  
  

• 3層アーキ（Raw sources／Wiki／Schema）と3操作（Ingest／Query／Lint）が骨格。CLAUDE.md／AGENTS.mdでSchemaを規律あるものにできるかが、LLM wikiが破綻せずに続くかを決める
  
  

• 実装は4系統から選択——Karpathy Gist自作／Claude Codeプラグイン／nashsu/llm_wikiのようなOSSデスクトップアプリ／エージェント横断プラグイン・SaaS系（多くはローンチ前）。KarpathyはObsidianをIDE frontendとして使う想定で、LLMエージェント側はClaude Code・Codex・OpenCode／Piなどが選択肢
  
  

• HackerNoon実践例で4プロジェクト並列25分（従来100分・75%短縮）、21モデルwiki化10分、nashsu/llm_wikiが13.5k starsなど、定量的な効果が既に積み上がっている
  
  

• AI総研の推奨は「LLM wikiから始めて、必要になったらRAGを足す」。PoCの立ち上げが最速で、規模拡大時の移行コストも最小に抑えられる
  
  

LLM wikiは、Vannevar Bushが80年前に構想したMemexが実現できなかった「保守作業を誰が引き受けるか」という問いに、LLMという保守エンジンで答えを出したパターンです。個人・チーム・組織の情報基盤を「貯めても腐る場所」から「時間とともに価値が複利で増える場所」に変えていく上で、まずは1プロジェクト・1ドメインで実運用ループを回してみることが、最も現実的な第一歩になります。