383件の散在ファイルと100件の議事録を、コンパクトなwikiにまとめたところ、Claudeのトークン使用量が95%減った——こうした報告がAIエンジニア向けの投稿で話題になっています。毎回すべての生ドキュメントを読み込む設計は、構造把握のコストを何度も払うことになり、知識検索や社内ドキュメント整理の現場では大きな無駄になります。

この記事では、Andrej Karpathyが公開したLLM Wikiパターンを軸に、トークン削減が起きる理由と、実務で再現するためのフォルダ構成を解説します。

  • LLM WikiパターンがRAGと何が違うか
  • raw・wiki・indexの3層構成の役割
  • 初回コンパイル後にトークンが減る仕組み
  • 30分程度で始められるセットアップ手順

毎回「構造を読み直す」設計がコストを積み上げる

RAG（Retrieval-Augmented Generation）は、質問のたびに関連チャンクを検索してLLMに渡す仕組みです。NotebookLMやChatGPTのファイルアップロードも、大枠では同じ発想に近いです。都度、散在した生文書から必要な断片を探し直すため、知識は蓄積されません。

AIエンジニアのNeilXbt氏は、典型的なクエリでトークンの約75%が「回答生成」ではなく「構造理解」に使われると指摘しています（参考）。フォルダ階層、ファイル名、議事録の文脈——これらを毎回読み直すと、同じ質問でも同じ前処理コストが発生します。383件のファイルと100件の議事録を抱える環境では、この積み上げが顕著になります。

KarpathyのLLM Wikiが示す別ルート

2026年4月、元OpenAI共同創業者のAndrej Karpathy氏がGitHub Gistで「LLM Wiki」パターンを公開しました。X上の投稿は約1600万ビューを記録し、翌日に公開されたGistは数日で数千のスターを獲得しています（参考）。

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Karpathy氏の設計思想は明快です。生文書を毎回検索するのではなく、LLMが維持する構造化wikiを中間層に置き、知識を「コンパイル済みの状態」で保持します。矛盾の整理やページ間リンクは取り込み時に済ませ、質問時はindexから必要ページだけを辿ります。Karpathy氏自身は約100ソース・数十万語規模で運用しており、ベクトルDBなしでもindex.mdだけで十分に機能すると報告しています。

2フォルダ＋indexでトークンが減る理由

LLM Wikiの核は、フォルダ2つと軽量な目次ファイルです。NeilXbt氏の整理では次のように役割が分かれます。

rawフォルダ — 論文、記事、議事録などの不変ソースを置く場所です。LLMは読み取りますが、原本は書き換えません。383件の散在ファイルはここに集約します。

wikiフォルダ — LLMが生成・更新するMarkdownページ群です。概念ページ、エンティティページ、要約、相互リンクをここで管理します。100件の議事録は個別の生テキストではなく、テーマ別に統合されたページへ落とし込まれます。

indexファイル — 全ページの1行要約とカテゴリを載せた目次です。クエリ時はまずここだけを読み、関連ページを特定してから深掘りします。全文検索で全ファイルを毎回走査する必要がなくなります。

この流れで、構造理解のコストは初回の取り込み（Ingest）時に一度だけ発生します。2回目以降の質問では、indexと数ページ分の読み込みで済むため、NeilXbt氏が紹介した95%削減という数字が説明可能になります。技術的な難易度より、「毎回生文書を処理するか、コンパイル済みwikiを引くか」の設計差が本質です。

セットアップ手順：30分で始める最小構成

Karpathy氏のGistは「アイデアファイル」として書かれており、実装の細部は利用するエージェントと相談しながら決める前提です。最小構成は次の4ステップです。

  1. フォルダを作る — プロジェクト直下にraw/とwiki/を用意します。ObsidianのVaultとして管理する方法がKarpathy氏の運用例として紹介されています。
  2. スキーマを置く — CLAUDE.md（Claude Code向け）やAGENTS.md（Codex向け）に、ページ形式、取り込み手順、更新ルールを書きます。これがLLMを「雑談相手」から「wiki司書」に変える設定ファイルです。
  3. indexとlogを用意する — wiki/index.mdに全ページの目次を、wiki/log.mdに取り込み・更新履歴を追記します。logは時系列の監査ログとしても機能します。
  4. 取り込みを回す — raw/に新しい議事録や資料を入れ、「Ingestして」とエージェントに指示します。1ソースあたり10〜15ページの更新が典型例とされています。

質問時は「indexを読んで関連ページから答えて」と指示すれば、生のraw/を毎回総なめする動きを避けられます。定期的にLint（矛盾、孤立ページ、古い記述の検出）を走らせると、wikiの品質を保ったまま拡張できます。

向いている場面と限界

このパターンが力を発揮するのは、テキストが週単位・月単位で増え続ける場面です。競合調査、社内ナレッジ、研究テーマの深掘り、書籍読了ノートなど、「読み続けるほど構造化の価値が上がる」用途に向きます。383ファイルと100議事録のように、人間が手作業で整理しきれない規模こそ、LLMによる維持コストの低さが効きます。

一方、顧客マスタのようなリレーショナルデータや、数千ページを超える大規模コーパスでは、index単体では足りなくなる可能性があります。Karpathy氏もGist内で、規模が大きくなったらqmdのようなローカル検索ツールの併用を示唆しています。まずは中規模の個人・チーム知識ベースで試し、indexの行数や応答速度を見ながら拡張するのが現実的です。

設計を変えるだけでコスト構造が変わる

AI知識ツールの多くは、クエリのたびに生ドキュメントの構造を再解釈します。LLM Wikiは、その理解をwiki層に事前コンパイルし、質問時は目次から必要部分だけを引く設計に切り替えます。フォルダ2つ、スキーマ1枚、30分の初期設定——ハードルは低く、トークン削減のインパクトは大きいです。散在ファイルと議事録に悩んでいるなら、まずraw/に資料を集め、1件だけ取り込んでindexがどう育つか確認するのが近道です。