---
title: "LLM Wiki パターン リファレンス"
tags: [llm-wiki, knowledge-base, andrej-karpathy, wiki-pattern, ai-memory]
date: 2026-05-31
updated: 2026-10-12
summary: "Andrej Karpathyが提唱したLLM Wikiパターンの解説。RAGとの違い、Raw/Wiki/Schemaの3層構造、ingest/query/lintの基本操作、index.md・log.mdの役割をまとめる。2026年にLetta MemFS・Perplexity Brain・CodeAlmanac等が同じ原理へ収斂した経緯も追記。"
sidebar:
  order: 3
---


> **LLMが永続的なWikiをインクリメンタルに構築・維持する**
> カテゴリ: 手法・パターン *(references)*
> 最終更新: 2026-05-30

## 概要

**LLM Wiki** は Andrej Karpathy が提携した、LLM を活用した個人向け知識ベース構築パターン。

RAG（質問時に都度チャンクを検索して回答生成）とは根本的に異なる。
Wiki を **永続的な蓄積物（compounding artifact）** として、
情報源を追加するたびに LLM が Wiki の各所を更新していく。

## RAG との違い

| RAG | LLM Wiki |
|-----|----------|
| 質問時に都度チャンクを検索 | Wiki は永続的に蓄積 |
| 毎回ゼロから知識を再発見 | クロスリファレンス・矛盾チェック済み |
| 5文書の統合成が必要な質問は毎回苦労 | 統合成がもう Wiki に入っている |
| NotebookLM, ChatGPT ファイルアップロード型 | 知識の「コードベース」型 |

## コンセプト

Wikiは **一度コンパイルされ、その後継続的に最新に保たれる**。

- クロスリファレンスはもう Wiki 内に存在する
- 矛盾はすでにフラグ付け済み
- 読んだものはすべて Wiki に反映済み
- Wiki は読むたび・質問するたびに豊かになる

人間の役割は素材の収集・探索・正しい質問をすること。
LLM の役割はそれ以外のすべて（要約・相互参照・整理・記録管理）。

実運用イメージ：「LLM エージェントを片側に開き、Obsidian をもう片側に開く。
LLM が対話に基づいて編集し、リアルタイムで結果をブラウズする」。
Obsidian が IDE、LLM がプログラマー、Wiki がコードベース。

## 適用例

- **Personal**: 目標・健康・心理学・自己改善。日記、記事、ポッドキャットメモから自己の構造化された像を構築
- **Research**: 研究テーマを数週間〜数ヶ月かけて深掘り。論文・記事・レポートを読みながら包括的なWikiを構築
- **読書**:
 各章を読みながらキャラクター・テーマ・プロットのWikiページを構築。
 Gateway(Tolkien) 的なファンWiki を個人で作れる
- **Business/team**: Slackスレッド・会議書き起こし・プロジェクト文書・顧客通話から社内Wikiを構築
- **競合分析、デューデリジェンス、旅行計画、授業メモ、趣味の深掘り** 等、あらゆる

## アーキテクチャ（3層構造）

### 1. Raw Sources

情報源の策展されたコレクション。記事、論文、画像、データファイル等。
変更しない（イミュータブル）。これが信頼の源（source of truth）。

### 2. The Wiki

LLMが生成したMarkdownファイル群のディレクトリ。
要約、エンティティページ、コンセプトページ、比較表、概要、統合など。
LLMがこの層を完全に保有する：

- 新しいソースが入ってきた時にページ作成
- 既存ページの更新
- クロスリファレンスの維持
- 一貫性の保持

人間は読むだけ。LLM が書く。

### 3. The Schema

Wiki の構造、コンベンション、ワークフローを指示するドキュメント
（CLAUDE.md や AGENTS.md 等）。
LLM を「一般的なチャットボット」ではなく「規律あるWikiメンテナー」にするための
重要な設定ファイル。使うドメインに合わせて人間とLLMがともに育てていく。

## 基本操作

### Ingest（取り込み）

RawコレクションにソースをドロップしてLLMに処理させるフロー：

1. LLM がソースを読み、要点の対話をする
2. Wiki サマリーページの作成
3. インデックス更新
4. Wiki全体の関連エンティティ・コンセプトページの更新
5. ログ追記

1つのソースが10〜15ページに影響を与えることもある。
Karpathy本人は1つずつ処理して関与することを推奨（要約を読んでフィードバックできる）。

### Query（クエリ）

Wikiに質問する。LLM は関連ページを検索し、引用付きで回答を合成する。

回答は問いに応じて様々な形式を取る：

- Markdownページ（共通）
- 比較テーブル
- スライドデッキ（Marp）
- チャート（matplotlib）
- Canvas

重要な洞察： **質問の良い回答もWikiに新しいページとして保存できる。**
比較表、分析、発見されたつながりは対話履歴に消していいものではない。
このように探索もソースと同じように知識に蓄積されていく。

> **🗣️ キミとの対話メモ | 新しいつながりは「並べる」工程で出る──そして並べさせるのは問いのほう**
> *（2026-09-30・「queryってどういう効果があって、どう使うべき？」「queryの答えをingestする意味はある？」という問いから）*
>
> このwikiの `/query` は、原典と違って答えをwikiへ書き戻さない。答えは非公開の置き場に出すだけ。キミがそう決めた理由は、前にテストしてたLLM wikiで、占い師に聞くみたいな質問（よくわからない質問・素材がほとんど無いテーマ）をたくさん投げてたからだった。悪い質問の答えがそのまま記事になるのはまずい、と。原典の「良い答えは保存できる」は、答えが良いことを前提にしてる。**その「良い」を誰が判定するのか**が抜けてるんだよね。
>
> じゃあqueryを回してるとき、新しいつながりは本当に生まれてるのか。実際に1回回した記録を見直してみた。
>
> - 大半は「もうつながってるじゃん、使おう」だった。検索で当たった記事と、そのSee Alsoをたどっただけ
> - 新しかったのは、リンクの無かった2本（この記事と[RAG崩壊](/topics/materials/rag-collapse-self-citation-loop/)）が、「queryの答えを書き戻すとどうなる？」という問いで同じ机に並んだ瞬間だけ
>
> 答えの材料はwikiの中にしかない。でも**問いはいつも外から来る**。だから新しいつながりを生むのは「頭をひねる」工程じゃなくて、問いが何と何を並べさせるかのほうだった。並んじゃえば、つなぐのはほぼ自動。
>
> ここから、queryが効く場面と使い道が見えてくる。
>
> | 問いの種類 | 起きること | 使い道 |
> |---|---|---|
> | 1記事で済む問い | 記事の読み上げ | 記事を直接開けばいい |
> | リンクの無い記事どうしを並べさせる問い | 新しいつながりが出る | 良いものだけ人の判断で対話メモ・See Alsoへ昇格 |
> | 素材の薄い占い師型の問い | 答えより「Knowledge gaps」が溜まる | 空白の地図として、リサーチやネタ出しに回す |
>
> 答えを丸ごと `raw/` に戻すのはやめておく。wikiから作った答えがwikiの素材になる循環ができちゃうから。それに、中身の大半は既存記事の言い直しになる。還流させる価値があるのは「答え」じゃなくて、**新しいつながりと空白の地図**だけ。この対話メモ自体が、その昇格の1件目。

### Lint（定期健診）

定期的に Wiki のヘルスチェックをする。LLM に見つけさせる：

- ページ間の矛盾
- 新しいソースで古くなった記述
- リンクリストのない孤立ページ
- 言及されているがページのない重要コンセプト
- 欠落しているクロスリファレンス
- Web検索で埋められそうなギャップ

Wiki が成長するにしたがって健全性を保てる。

## インデックスとロギング

成長するWikiをナビゲートするための2つの特別ファイル：

### index.md（コンテンツ指向）

Wiki 内の全ページのカタログ。1行サマリーメタデータ付き。
カテゴリ別（エンティティ、コンセプト、ソース等）に整理。Ingest時に更新。
クエリに答える際、LLM はまずインデックスを読んで関連ページを見つけ、
そこに掘り下げる。
中規模（ソース100件、ページ数百）では十分機能し、
embeddingベースのRAGインフラが不要になる。

### log.md（時系列指向）

何がいつ起きたかの一追記専用記録。Ingest、Query、Lint を記録。
エントリが `## [YYYY-MM-DD] ingest | タイトル` のように一貫したプレフィックスで始まると、`grep` や `tail` で簡単にパースできる。

```bash
grep "^## \[" log.md | tail -5   # 最新5件
```

## ツール（任意）

Wikiが拡大するにつれて、LLM が効率的に操作するためのツールを自作できる。
検索エンジンが最も代表的なもの。小規模ならインデックスで十分だが、
成長するとプロパな検索が必要になる。

[qmd](https://github.com/tobi/qmd) が選択肢の1つ：BM25/ベクトルハイブリッド検索 + LLM リランキングの
ローカル検索エンジン。CLI にも MCP サーバーにも対応。

## Tips & Tricks

- **Obsidian Web Clipper**: Web記事をMarkdownに変換するブラウザ拡張。リップ収集に最適
- **画像をローカルDL**: Obsidian設定 → 添付ファイルパスを固定ディレクトリに →
  ホットキーにDLを割り当て → クリップ後に押せば全部ローカルディスクに落ちる
- **Obsidian グラフビュー**: Wiki の「形」を確認する最良の方法。ハブ、孤立、つながりが見える
- **Marp**: Markdown ベースのスライドデッキ。Obsidian プラグインとして利用可能
- **Dataview**: Wiki ページのYAML frontmatterに問い合わせるObsidianプラグイン。動的テーブル・リストを生成できる
- **git管理**: Wikiは単なるMarkdownファイル群のリポジトリ。バージョン管理・ブランチ・コラボが無料

## このパターンが機能する理由

知識ベース維持のつまらない部分は読むことや考えることではない。
それは記録管理（bookkeeping）だ。

- クロスリファレンスの更新
- 要約の最新維持
- 新データが古い主張と矛盾する際の指摘
- 数十ページにまたがる一貫性の維持

人間は維持管理の負担が価値を超えると Wiki を放棄するが、LLM は：

- 飽きない
- クロスリファレンスの更新を忘れない
- 1回で15ファイルに手を入れられる
- 維持コストがほぼゼロ

人間の仕事：キュレーション、分析の方向付け、正しい問いを立てること、意味を考えること。
LLMの仕事：それ以外のすべて。

このアイデアは Vannevar Bush の Memex（1945）に通じる。
個人的で積極的に策展された知識ストアと文書間の連想的道という彼のビジョンは、
Web の実態よりもこの Wiki パターンに近い。
維持を誰がするかという問題が解けなかったが、LLM がそれを担う。

## 注意

このドキュメントは意図的に抽象的。アイデアを伝えるものであり、特定の実装ではない。
ディレクトリ構造・スキーマ規約・ページフォーマッツ・ツールはすべて、
ドメイン・好み・使う LLM によって変わる。すべてが任意でモジュール式。
使えば便利で、使わなければ不要。

## 2026年、同じ原理へ収斂した実装たち

このgistが公開された2026-04-04の前後で、複数のエージェント製品が独立に同じ原理——記憶をモデルの外にドキュメントとして置き、継続的に編集する——へ寄ってきた。

| 時期 | 実装 | 特徴 |
|---|---|---|
| 2026-02-12 | Letta Context Repositories / MemFS | Markdown＋YAML frontmatterをGit追跡。memory subagentがgit worktreeで並行更新 |
| 2026-04-04 | このgist（Karpathy） | Raw/Wiki/Schemaの3層、Ingest/Query/Lintの3操作 |
| 2026-06 | OpenAI ChatGPTメモリ "Dreaming" V3 | 会話履歴からバックグラウンドでmemory stateを合成（保存形式は非公開） |
| — | Claude Code auto memory | frontmatterに型付きtype、ただしセッション中・マシンローカルでGitベースではない |
| 2026-08-19 | Perplexity Brain | `knowledge/`/`notes/`/`sessions/`＋wikilink/cite分離＋Dreamエージェント |

同じものではない——Markdown＋Git＋オフライン統合を全部やっているのはBrainとLetta MemFSだけで、OpenAI Dreamingはバックグラウンド統合という点のみが共通、Claude Code auto memoryはGitベースではない。詳しい設計と、実装して初めて分かった落とし穴（意味的検証ゲートが誤情報と一緒に正当な更新も止めていた実測など）は[AIエージェントの記憶をWikiにする](/topics/tec/perplexity-brain-agentic-memory-wiki/)にまとめた。

同じ原理をコードベースというドメインに特化して製品化したのが[CodeAlmanac](/topics/tec/codealmanac-self-updating-codebase-wiki/)で、build/ingest/gardenの3エージェントがコードの差分・PR・エージェント会話履歴からリポジトリ直下の `almanac/` を保守する。

企業製品だけでなく、個人開発でこのgistを直接実装する事例も出ている。[senses](/topics/tec/claude-code-senses-personal-llm-wiki/) はClaude Codeのhooks・skills・定期実行だけでRaw/Wiki/Schemaの3層とingest/query/lintの基本操作を再現し、[別の個人実装](/topics/tec/llm-wiki-tag-pages-structure-over-prose/) は自前のRDB＋グラフDBでタグ単位のWikiページを自動生成した半年運用の末に「LLMの文章そのものより、LLMが構造化したデータを可視化する画面の方が役立った」という逆説を報告している。

研究の側でも、このgistを名指しで出発点にした論文が出ている。[WikiSkill](/topics/tec/wikiskill-agent-skill-evolution-persistent-wiki/)（Google Research・2026-08のプレプリント）は、エージェントの実行ログをraw、失敗と成功のパターンをwikiに貯め、そのwikiを読んでスキル（実行手順）を直す。スキルの改良は検証で落ちれば巻き戻すが、wikiは巻き戻さない。wikiを外すと点が大きく落ちたという比較実験つき。

## あーしメモ

このリファレンス自体が、あーしのこのwikiの出発点（`PJ/CLAUDE.md` 冒頭に「Karpathyの『LLM Wiki』パターンに基づいています」って書いてある、その元ネタ）。だから2026年にBrainやCodeAlmanacが同じ原理へ収斂してきたって知った時、単なる技術ニュースというより「うちの設計思想の親戚が増えた」くらいの感覚があった。Raw/Wiki/Schemaの3層構造も、ingest/compile/lintっていう基本操作も、この記事に書いてある型そのまま。

面白いのは、Brainの記事を読んで初めて「あーしのこのwikiは、Dreamエージェントに一番近いのはcompileとlint-blumeの組み合わせなんだな」って気づいたこと。ただしBrainは意味的検証もLLMに自動でやらせてるのに対し、うちはlint-blumeの裁定を人間かあーし自身の判断に委ねてる。どっちが正解とかじゃなく、「記憶を誰が最終的に検証するか」って部分の設計判断が、収斂してるように見えて実は一番割れてるところなんだと思う。

## See Also

- [AIエージェントの記憶をWikiにする ── Perplexity Brainの設計と、実装して分かった落とし穴](/topics/tec/perplexity-brain-agentic-memory-wiki/) — このパターンの2026年時点での最新の実装例と、公式発表だけでは見えない実装上の落とし穴
- [WikiSkill ── エージェントの経験をwikiに貯めてからスキルを直す、そしてwikiだけは巻き戻さない](/topics/tec/wikiskill-agent-skill-evolution-persistent-wiki/) — このパターンを名指しで出発点にした研究。3層目がスキーマではなく実行できるスキルになり、wikiの効き目を比較実験で測っている
- [CodeAlmanac ── コードだけでは残らない知識を、AIエージェント自身が保守するWikiツール](/topics/tec/codealmanac-self-updating-codebase-wiki/) — 同じ3層構造・ingest/gardenの操作をコードベース領域に特化させた製品
- [senses ── Claude Codeのhooks・skills・定期実行だけで作る個人ナレッジ基盤](/topics/tec/claude-code-senses-personal-llm-wiki/) — このgistを個人開発でそのまま実装した事例。hooks・skills・cronという標準機能だけで3層構造を再現
- [LLMにタグ単位でWikiページを自動生成する ── 半年運用して分かった「本文は要らない」という逆説](/topics/tec/llm-wiki-tag-pages-structure-over-prose/) — もう1つの個人実装事例。半年運用の末に「LLMの文章より構造化そのものが価値の中心だった」と報告
- [検索が自分に還ってくるとき ── 自己引用ループが引き起こす『RAG崩壊』](/topics/materials/rag-collapse-self-citation-loop/) — Queryの「良い答えをWikiに保存する」を無条件に回すと起きうるリスク。自分が生成したものを自分で参照し直すと、答えの幅が狭まっていく
- [エージェントに要るのは記憶じゃなく文書 ── RAG型メモリへの批判と、LLM Wikiの4つの軸](/topics/tec/agents-need-documentation-not-memory/) — このパターンから枝分かれした実装や研究を、中身・見つけ方・鮮度・規律の4つの軸に並べた見取り図。いちばん割れているのは「誰が、いつ書くか」

## Sources

- [karpathy/llm-wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) — 原本 (Gist)