はじめに：LLM Wikiが狙う「編集済み知識層」の育成
LLMに外部知識を付与する実装パターンとして、現在広く使われているのはRAG（検索拡張生成）です。
一方で、RAGの「問い合わせ時に必要な文脈を都度集める」という性質だけでは、知識同士の関連性や、人間が咀嚼した“編集済みで再利用しやすい知識層”を長期的に育てにくい場面があります。
Andrej Karpathy氏がGistで提唱した「LLM Wiki」は、この不足を埋めるために、一次ソースからWikiを継続的にコンパイル・保守する設計を取ります。
検索前提ではなく、「読むため・理解するための知識層」を前段に置くアプローチです。
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
本記事では、Karpathy氏の原案が示す中核思想を整理した上で、それを実務で破綻させずに運用するための拡張設計、ローカル保管を軸にした実装イメージ、そして長期運用における知識劣化の防ぎ方について解説します。
本稿における「ローカル」の定義
本稿の中心は、「データ保管と検索のローカル性」です。
推論のローカル性は必須条件としません。
具体的には、MarkdownファイルとGitによるデータ保管、およびBM25やハイブリッド検索などの検索基盤をローカル環境に置く構成を前提とします。
一方で、Wikiのコンパイルや保守を行うLLMエージェントには、Claude Codeなどの外部APIを利用しても構いません。
KarpathyのGistが示す中核思想
Karpathy氏の原案が提示した重要なポイントは、生データ層と編集済み知識層を明示的に分離し、保守作業の多くをLLMへ委譲することです。
raw/（生データ層）
論文のPDF、Webクリップ、メモなどの一次ソースを置く領域です。ここは不変の source of truth として扱い、原則として上書きしません。
wiki/（編集済み知識層）
raw/ を元に生成された要約、概念、エンティティのページ群です。ユーザーは主にこの層を読んで理解を進めます。
ルールファイル
CLAUDE.md や AGENTS.md のようなルールファイルには、ページ構成、出典の書き方、更新時の禁止事項、LintとRepairの役割などを定義します。
要点はシンプルです。Query時は wiki/ を主参照にし、Update時は必ず raw/ を起点にする。この分離が、LLM Wikiの核になります。
本記事が提案する実務向け拡張設計
アーキテクチャを分けただけではWikiは安定しません。
実務上の差は、更新時のプロンプト設計と運用規律にあります。
1. Ingest（取り込み）の処理フロー
Ingestでは、以下の順序を崩さないことが重要です。
-
raw/に新しいソースを追加する。 - ローカル検索で更新候補となる
wiki/ページを抽出する。 - 既存ページを書き換える前に、必ず対応する
raw/を再読込する。 - 差分追記、新規ページ作成、競合保留のいずれかを判定する。
- 出典、更新日時、状態フラグを付与する。
- 差分を人間がレビューし、承認後に反映する。
差分更新の判定ルールも、あらかじめ固定しておきます。
- 既存記述と矛盾しない新情報は、対応する節へ追記する。
- 明確に独立した概念が出てきた場合は、新規ページとして切り出す。
- 既存記述と新ソースが矛盾する場合は、上書きせず競合を局所化する。
ここで重要なのは、競合をページ全体ではなく節単位または claim 単位で扱うことです。たとえば学習時間や評価条件のように一部だけが衝突している場合、ページ全体を conflict にするとノイズが大きすぎます。
2. 出典の持ち方
ページ冒頭の sources だけでは監査性が足りません。
出典は、ページ単位と節単位の両方で持たせます。
ページ単位のメタデータ例
---
title: Retrieval-Augmented Generation
sources:
- raw/papers/rag-original.pdf#p3-p6
- raw/webclips/karpathy-llm-wiki.md#L10-L42
updated_at: 2026-04-24
status: unverified
---
節単位の出典例
RAGは問い合わせ時に必要な文脈を都度集める設計を取る。
（raw/papers/rag-original.pdf#p3-p6）LLM Wikiでは、更新時に一次ソースへ戻る運用規律が重要になる。
（raw/webclips/karpathy-llm-wiki.md#L10-L42）
人間向けの簡略表記ではなく、raw/...#anchor のように人間もエージェントもそのまま元ファイルへ戻れる形式で統一する方が、ローカル運用では圧倒的に監査しやすくなります。
3. 実測データと検証条件
以下は実運用イメージを掴むための記録です。
※本データは特定のローカル環境における参考値であり、結果を一般化するものではありません。
- 環境: M1 Mac mini
- モデル: Claude 3.5 Sonnet
- 既存 wiki: 28ページ
- 検索方式: ローカルBM25検索 + ファイル走査
- ソース投入量: Markdown論文5本、合計約4万トークン
- 再試行: なし
- 反映条件: 差分適用前に人間レビューあり
この条件でIngestを1回実行したところ、処理時間は約14分でした。新規ソース要約5ページ、概念ページ3件の新規作成、既存エンティティページ12件への差分追記が発生しました。
また、後半の関連ページ走査になるほどReadコストが非線形に伸びる傾向が見られました。さらに、既存記述との競合を2件検出し、該当節にのみ競合フラグを付ける運用が有効でした。
LLM Wikiはページ数が増えるほど読み込みコストや候補抽出の精度が効いてくるため、こうした数字をスケール時の制約として見ることが重要です。
4. 知識の「複利」効果
LLM Wikiの価値は、1回の回答性能ではなく、複数回のIngestで知識が編集済みの形で蓄積されることにあります。
たとえば1回目のIngestで「Nginxのプロキシ設定」、2回目で「WAFの挙動」を取り込んだとします。
このとき、両者を別々のメモとして保持するだけでなく、「NginxとWAFを連携させたセキュアなルーティング」という統合ページへ再編できれば、次回のQueryはより立体的になります。
ここにLLM Wikiの“複利”があります。単発の検索結果ではなく、過去の取り込み結果が次の理解を豊かにするわけです。
5. Query（検索）のフォールバック設計
Query時は、まず wiki/ を主参照として関連ページを検索・読込します。
その時点で根拠が不足している場合、または該当節に conflict フラグが付いている場合に限り、対応する raw/ を追加参照します。
平常時に毎回 raw/ へ戻るのではなく、必要時だけ一次ソースへフォールバックする設計です。
また、Queryから得られた有用な整理結果は、人間がレビューし承認した後に限って新規ページとして wiki/notes/ 等へ書き戻す運用にすると、対話から得た知見も安全に資産化できます。
6. Lint（検査）と Repair（修復）の分離
Wikiの健全性を保つには、検査と修復を分ける必要があります。
Lintの判定仕様
-
[FAIL]インライン出典（raw/...#anchor）を持たない断定文が1つでもある。 -
[FAIL]リンク先のファイルまたはアンカーが存在しない。 -
[FAIL]数値・固有名詞がraw/と照合して明確に乖離している。 -
[WARN]updated_atが90日を超過しており、内容が陳腐化している可能性がある。
ここで大事なのは、ドリフト検知を雑に作らないことです。
数値は単位を正規化して比較し、固有名詞は別名辞書や表記ゆれルールを通してから判定しないと、誤検知だらけになります。
Repairのルール
Repairは、フォーマット修正、リンク修復、見出し整形のような「新しい事実を追加しない作業」に限定します。
つまり、Repairプロセスでは「新しい事実を絶対に追加しない」という制約をLLMに課します。新しい知識の追加や競合解消は、必ずIngestか人間レビュー側で扱います。
運用上の罠：再帰的要約劣化
本稿では、学術用語として確立した名称ではありませんが、Wikiの自己参照更新によって知識の解像度が落ちる問題を便宜的に「再帰的要約劣化」と呼びます。
これは、LLMが過去に自分で生成した wiki/ だけを根拠に更新を繰り返すことで、元の一次情報に含まれていた細部や例外条件が徐々に削ぎ落とされる現象です。
たとえば「3.5日」が「約4日」に丸められるような、小さな劣化が蓄積していきます。
これを防ぐための基本は2つです。
Update時に必ず raw/ へ戻ること、そして出典のない記述をLintで弾くことです。
要約の増殖ではなく、一次情報に基づく抽出と再編集を徹底することが、Wikiの寿命を左右します。
適用範囲：Markdown + Git か、CMS/DB か
ローカル保管を軸にした Markdown + Git 構成は、個人利用や小規模なAI開発環境では第一候補です。
可搬性が高く、スキーマ変更にも機動的に対応できます。
一方で、複数人編集、権限管理、API配信、厳格なスキーマ統制が必要なら、SanityのようなHeadless CMSやPostgreSQLなどのDBを組み合わせた方が向いています。
重要なのは保存形式そのものではありません。
更新規律と出典トレーサビリティをどこで担保するか、というシステム全体の設計です。
まとめ：判断は人間、更新作業はLLM
LLM Wikiは、RAGの代替ではなく、RAGの前段に「編集された知識層」を構築するための補完的な設計思想です。
タグ付け、インデックス更新、リンク監査、フォーマット修正のような作業はLLMへ委譲できます。
しかし、ナレッジの品質と真偽を担保する責任は人間に残ります。
人間は一次情報の選定と評価基準を持ち、LLMは情報の編集・接続・再構成を担う。
この責任分界と運用仕様を明確にしてはじめて、LLM Wikiは実用的な知識基盤として機能します。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。