LLM Wikiとは｜RAGとの違いと、専用ツールを買わずに作る方法【Markdown 1,042本で運用中】

AIに自社の資料を読ませ始めると、たいてい同じ壁に当たります。資料を渡すほど答えが遅くなり、精度も落ちる。毎回同じ前提を説明し直している。知識が積み上がらない。

結論から書きます。この壁は、渡し方ではなく置き方を変えると抜けられます。資料をそのまま渡すのをやめ、AIが読むための知識ベースをMarkdownで作って育て続ける。これが「LLM Wiki」と呼ばれている設計です。専用のツールを買う必要はありません。

LLM Wikiとは AIが読んで使うための知識ベースを、Markdownファイルの集まりとして作り、AI自身に更新させ続ける設計です。元の資料を毎回検索し直すのではなく、あらかじめ要約・整理した成果物を蓄積して、以後はそこに問い合わせます。ファイルを読み書きできるAIエージェントとテキストエディタがあれば成立します。

LLM Wikiの原典は論文ではなく、1ページのgistです

出所は、AI研究者のアンドレイ・カルパシー（Andrej Karpathy）氏が2026年4月4日に公開したGitHub gist「llm-wiki」です。

ここは誤解が広がっているので、はっきり書いておきます。これは査読論文ではありません。 本人が “idea file”（アイデアファイル）と位置づけた、1ページのパターン記述です。解説記事やSNSで「4月にアメリカで論文が出た」という説明を見かけますが、実体はgist1枚です。公開から5か月弱の2026年8月30日時点で、GitHubのスターもフォークも表示上限の「5,000+」に達しています（GitHubは5,000を超えると正確な数を出しません）。この型を再実装したオープンソースの実装も登場しています。

カルパシー氏本人が使っている比喩が分かりやすいので引きます。「Obsidianは統合開発環境（IDE）、LLMはプログラマー、wikiはコードベース」。つまり、人が書くのではなく、AIが書いて育てる対象としてwikiを置くという発想です。原典はwikiを “a persistent, compounding artifact”（永続し、複利で積み上がっていく成果物）と表現しています。

RAGとの違いは「毎回引き直す」か「一度作って積み上げる」か

いま多くのAI導入で使われているのは、質問のたびに資料を検索して、関係しそうな箇所を拾って答えさせる方式です（RAGと呼ばれます）。

LLM Wikiはここが構造的に違います。RAGがクエリごとに生データを引き直すのに対し、LLM Wikiは事前に知識をまとめて永続化し、以後はまとめ済みの成果物を引きます。要約という重い処理を毎回やり直すのではなく、1回まとめて、あとはそれを最新に保ち続ける考え方です。原典は、およそ100ソース・数百ページの規模までなら、この索引方式が「驚くほどうまく動き、embeddingベースのRAG基盤を不要にする」と書いています。

ただし、いいことばかりではありません。取り込みの段階で誤った要約が入ると、それがwikiに固定され、以後のすべての答えを汚染します。RAGは毎回原典に戻るので、この種の固定汚染は起きません。ここがLLM Wikiの弱点であり、後述するlint（点検）と出典リンクの運用が回っているかどうかが、効果の分かれ目になります。

置き場所を3つの層に分ける

構造はシンプルで、3層です。

1. raw（生データ） — 人が厳選した、書き換えない元資料。原典が挙げているのは記事・論文・画像・データファイルで、社内で使うなら打ち合わせの書き起こしなども入ります
2. wiki — AIが生成・維持するMarkdown群。要約ページ、人物や取引先などのページ、概念のページ
3. スキーマ — ページの構造・命名規約・更新の手順を決めたルールファイル

補助として、全ページの1行要約を並べた索引ファイルと、操作の履歴を追記だけしていく記録ファイルを置きます。

カルパシー氏のgistは、スキーマの例として CLAUDE.md（Claude Code）と AGENTS.md（Codex）の両方を挙げています。最初からエージェント中立の設計なので、ファイルを読み書きできるAIエージェントなら何で作っても成立します。スキーマの書き方そのものはCLAUDE.mdをSSOTにする記事で詳しく扱っています。生データと整理済みを分ける物理的なフォルダの切り方はフォルダ構成の記事、wikiの中に何を書くかはナレッジ管理の記事へ譲ります。

動かすのは3つの操作だけ

日々の運用でやることは3つに整理されています。

• ingest（取り込み） — 新しい資料を読ませ、要点を対話で詰めたうえで要約ページを書かせる。索引の更新から、wiki全体の関連するページ（人物・取引先・概念）の更新、履歴への追記までを一度にやらせます。原典によれば、1つの資料が10〜15ページに及ぶこともあります
• query（問い合わせ） — 生データではなくwikiに対して質問し、出典付きで答えさせる。よい答えが返ったら、それを新しいページとして保存する
• lint（点検） — 定期的な健康診断。原典が挙げている点検項目は6つで、ページ間の矛盾・新しい資料に取って代わられた古い記述・どこからもリンクされていない孤立ページ・言及されているのに専用ページが無い重要概念・張られていない相互参照・Web検索で埋められるデータの穴を検出させます

日本語の解説記事で最も抜け落ちているのがlintです。ここが無いと、wikiは半年で「昔の正しさ」が残ったまま誰も信じないファイル置き場になります。逆にlintを回していると、放っておくと腐るはずの知識が、使うほど整っていく側に転びます。

Markdown 1,042本を約8か月運用してわかったこと

みやっち🧑‍💻の会社では、経営・事業・マーケティングの母艦にしているリポジトリが、このgistを読むより前から同じ形で動いていました。2026年8月30日時点の実測値です。

いずれもgit管理下（tracked）の数え方で取っています。対応関係はこうなっています。スキーマはリポジトリ直下の CLAUDE.md で、フォルダの規約・命名規則・禁止事項・「同じ情報を二重に書かない」というSSOT原則を書いています。索引は各フォルダに置いた <フォルダ名>_README.md で、そのフォルダの原典がどこにあるかを宣言します。wikiにあたるのがガイド・テンプレート・業務ごとの判断基準をまとめたページで、rawにあたるのが打ち合わせの書き起こしや素材のアーカイブです。lintにあたるのが「同じ情報を二重に書かない」「原典には今の正しい情報だけを書く」という規約で、古い記述が放置されるのをルールで防いでいます。ただし孤立ページや張られていない相互参照の機械的な検出まではまだ自動化できておらず、ここは手で見ています。

このブログ自体も同じ仕組みの上に乗っていて、公開済み記事はこの記事を含めて146本になりました。記事のネタは knowledge/ にファイルとして貯まり、そこから記事が作られ、公開したらステータスが書き戻されます。やっているのは「AIに読ませる場所を決めて、そこを更新させ続ける」だけで、LLM Wiki用の専用ツールは1つも使っていません。

原典が自分で挙げている限界

誇張しないために、gistが自ら書いている限界も並べておきます。

• 文書そのものが意図的に抽象的で、フォルダ構成・スキーマの規約・ページ形式・使う道具は、自分のドメイン・好み・使うAIエージェントに合わせて決める必要がある
• 索引だけで回るのは、およそ100ソース・数百ページの規模まで。原典はこれを「その規模なら驚くほどうまく動く」と書いており、超えたら全文検索とベクトル検索を組み合わせ、AIで並べ替える検索の仕組みを足すことになる

原典が限界として明示しているのは、主にこの2つです。これとは別に、実装した人たちの解説記事（二次情報）では、規模が育つにつれて精度が落ちるという報告も出ています（200ファイル前後からという言及です）。

つまり「置けば勝手に賢くなる魔法」ではありません。育てる人がいる前提の設計です。

契約する前に、手元で作れる4つの理由

「LLM Wiki対応」をうたうサービスも出てきましたが、契約する前に手元で作れます。理由は4つです。

1. 代替が無料 — 「ファイルを読み書きできるAIエージェント＋Markdown＋git」で成立します。Claude CodeやCodexをすでに使っているなら、今日から始められます
2. 履歴管理はgitで解決済み — 「バージョンの履歴が残る」は新機能ではありません。原典も「wikiはMarkdownファイルのgitリポジトリにすぎない。履歴・ブランチ・共同作業がタダで手に入る」と書いています。gitでのファイル管理に載せて、コミットメッセージに理由を書いておけば、いつ・なぜ変えたかまで残ります
3. 本体は維持コスト — スキーマ（概念の定義）は、作るより維持するほうが重い仕事です。更新する人がいない仕組みは半年で腐ります。ここは道具では解決しません
4. 標準機能に取り込まれる位置にある — gistがGitHubの表示上限に達するほど支持を集めたのは需要の証明であると同時に、各社が標準機能として実装していく合図でもあります。実際、スキーマファイル・スキル・メモリ機能はその方向に進んでいます

人に頼んでも、汎用のSaaSを契約しても、この形にはなりません。自社の言葉づかいと判断基準を覚えた知識ベースは、自社の資料でしか育たないからです。だからこそ、外から買うのではなく、自分の手元で育てる対象になります。AIへの情報の渡し方の原則そのものはコンテキストエンジニアリングの記事にまとめています。

最小構成で作る手順——3層・ファイル2つ・頼み方3つ

ここからは、原典のgistと自社の運用から逆算した、最小構成の作り方です（2026年10月時点の原典の記述にもとづきます）。専用ツールは使わず、Claude Code・Codexのようにファイルを読み書きできるAIエージェントとgitだけで組みます。

1. 置き場所を3層に分ける — フォルダ raw/（元資料。AIは読むだけで書き換えない）、フォルダ wiki/（AIが書く要約・人物・取引先・概念のページ）、そしてリポジトリ直下のスキーマファイル（Claude Codeなら CLAUDE.md、Codexなら AGENTS.md）。原典が名指ししているのはこの3層です
2. 索引と記録を2つ置く — wiki/index.md はカテゴリ別に全ページを1行要約で並べた目次で、取り込みのたびにAIが更新します。wiki/log.md は「いつ何を取り込んだ・問い合わせた・点検した」を追記だけしていく時系列の記録です
3. スキーマに最小限のルールを書く — 3層の役割、ページの命名規約、取り込み時に更新する順番（要約ページ→索引→関連ページ→記録）、出典の付け方、点検で見る項目。長く書く必要はなく、CLAUDE.mdをSSOTにする記事の型で十分です
4. 最初の取り込みを頼む — 元資料を1つ raw/ に置き、「この資料を読んで要点を私と確認してから、wikiに要約ページを作り、index・関連ページ・logも更新して」と頼みます。要点の確認を先に挟むのが原典が例として示す流れで、ここで誤読を止めます
5. 問い合わせと点検を習慣にする — 質問は「rawではなくwikiを根拠に、出典付きで答えて」と頼み、よい答えはページとして保存します。定期的に（たとえば月に1回）「矛盾・古くなった記述・孤立ページ・専用ページが無い概念・張られていない相互参照・Web検索で埋められるデータの穴」を点検させます

全体をgitで管理すれば、原典の言うとおり履歴・ブランチ・共同作業が追加費用なしで付いてきます。最初の1フォルダは、いちばんよく相談するテーマを1つ選ぶのがおすすめです。

よくある質問

Obsidianなどのツールは必要ですか

必須ではありません。中身はただのMarkdownファイルなので、テキストエディタがあれば足ります。Obsidianはページ同士のつながりを見やすく表示する道具として便利ですが、AIが読み書きする分にはファイルがあれば十分です。

何本くらいから効果が出ますか

数十本の段階から、同じ説明を繰り返さなくて済む効果は出ます。原典は100ソース・数百ページの規模までなら索引だけで「驚くほどうまく動く」と書いているので、それを超えるあたりで検索の仕組み（原典はqmdを挙げています。全文検索とベクトル検索を組み合わせ、AIで並べ替える仕組みです）を足すか、フォルダを分ける判断が必要になります。

社内の機密情報を入れても大丈夫ですか

AIに渡す範囲は自社の契約・利用しているサービスの規約・社内規定によって判断が変わります。まず公開しても困らない資料から始め、機密性の高いものを入れるかどうかは、契約内容を確認したうえで決めてください。判断に迷う場合は専門家に相談することをおすすめします。なお本記事は法的・技術的な助言ではありません。

RAGとどちらを選ぶべきですか

両方使えます。頻繁に更新される数値データや、原典に必ず戻りたい用途はRAGが向きます。一方、判断基準・用語の定義・過去の経緯のように「一度まとめたら安定して使い回すもの」はLLM Wikiが向きます。

まず1フォルダから始める

いきなり全社の資料を対象にする必要はありません。1つのテーマのフォルダを決めて、そこに元資料を置き、AIに要約ページと索引を作らせる。これだけで、次に同じテーマを相談したときの前提説明が消えます。

AI Crewでは、こうした知識ベースの設計から日々の更新の回し方までを、実際に画面を一緒に触りながらお伝えしています。気になる方は、まず無料セミナーでお会いしましょう。