これなら分かる「LLM Wiki」 メモや資料をAIで整理し、使える知識に育てる新しい発想：Deep Insider Brief ― 技術の“今”にひと言コメント
AI業界で有名なカルパシー氏が提案し、5千超のスターを集めた「LLM Wiki」。話題の新概念をやさしく整理しながら、その仕組みやRAGとの違い、試してみるためのツールやコミュニティーの動きまで紹介する。
元テスラのAI責任者で、OpenAIの共同創業者でもあるアンドレイ・カルパシー（Andrej Karpathy）氏が、2026年4月上旬に「LLM Wiki」という興味深いアイデアを示した。これが今、大きな話題になっている。しかし、この概念はやや分かりづらく、一部で余計な論争も招いているように見える。そこで本稿では、この新しい概念を筆者なりにかみ砕いて説明したい。
LLM Wikiとは、AIがメモや資料を整理し、その内容を更新しながら、“使える知識”へと育てていくための新しい仕組みだ。現在主流のRAG（検索拡張生成）では、AIは“知識”を主に「参照／検索する」対象として扱う。これに対しLLM Wikiでは、AIは“知識”を「管理／運用する」対象として扱う。そこが両者の根本的な違いなのである。
図の左側にあるのは、バラバラにたまったメモやPDF、記事などの「元資料」だ。これまでの一般的なAI活用では、AIは質問のたびにこの山から関連する情報を探し出していた。しかしLLM Wikiでは、図の中央にあるようにAIが「整理役」となり、バラバラな資料を読み解いて、右側にあるような整理された「百科事典（Wiki）」へと編さん（内容を整理してまとめること）していく。
この仕組みを支えるのが、カルパシー氏が提唱する「3つの構成要素」だ。具体的には、
- 読み込み専用の「元資料（Raw sources）」 …… 図の左側
- AIに整理の仕方を教える「運用ルール（The schema）」 …… 図の中央右上
- AIが執筆したり更新したりする「Wikiページの集まり（The wiki）」 …… 図の右側
の3つである（詳細後述）。AIは新しい資料を追加するたびに、既存のWikiページを書き換え、関連するページをリンクで結ぶ。これにより、バラバラだった情報は、相互につながった1つの構造体へと育っていく。この構造体、つまりWiki全体こそが、図の右側にある“使える知識”で、いわゆる知識ベース（ナレッジベース：Knowledge Base）となる。
最も重要なのは、Wikiページの“メンテナンス”をAIが継続的に行う点だ。これまで人間がWikiを作っても挫折しがちだったのは、継続的な情報の更新やリンクの張り直しが面倒だからである。LLM Wikiなら、AIが飽きることなく裏側で“メンテナンス”を続けてくれる。その結果、使い込むほどに知識が積み重なり、価値が増していく「資産」としての知識ベースが出来上がるのだ。
――ここからは『Deep Insider Brief』恒例の“ひと言コメント”として、前述した論争についても簡単に私見を述べる。その後で、カルパシー氏が提唱する各構成要素の詳細や、実際に使うファイルについてコンパクトにまとめる。また、LLM Wikiを試すためのツールやコミュニティーの動きも紹介する。
Deep Insider編集長の一色です。こんにちは。
ここまで読んで「面白い」と感じた方も多いと思いますが、実はこのLLM Wiki、英語圏のHacker NewsやReddit、Xなどで賛否両論となり、日本語圏でもXを中心に議論が広がっていました。冒頭でも触れた通り、私から見ると、すれ違いによる無用な論争が少なからず起きていたように思います。
原因の一つは、カルパシー氏自身がLLM WikiをRAGとの対比で説明したことにあるのではないでしょうか。これにより、「LLM Wikiも、質問に答える際にはAIが関連ページを探して読んでいるのだから、本質的にはRAGと変わらないのではないか。ファイルが増えれば、やはりベクトル検索も必要になる」と受け取る人たちが現れました。
しかし、私はこの批判は少し軸がずれていると感じています。LLM Wikiの目的は検索そのものではなく、メンテナンスされ続ける“自分だけの百科事典”を作ることにあります。一方で、RAGの目的は百科事典を作ることではなく、関連情報を取り出すことです。そもそも、その百科事典の中をベクトル検索やキーワード検索で探すことは、もちろん可能ですし、何も禁じられていません。
つまり、RAGとLLM Wikiを対立軸で語ること自体に無理があると私は考えています。LLM Wikiは検索手法の新旧として捉えるより、「AIに自分だけの百科事典を作らせ、維持させる仕組み」として受け取った方が、このLLM Wikiの「面白さ」はずっとストレートに伝わるはずです。
それでは、カルパシー氏が公開した内容に基づき、LLM Wikiを構成する要素と運用の流れを確認しよう。
3つの構成要素
LLM Wikiは、役割の異なる3つの要素で構成される。
- 元資料（Raw sources）： Web記事、PDF、論文、メモ、画像などの一次情報の置き場。AIはここを読み取るが、中身を書き換えることはない。いわば「原本」であり、情報の正確性を保つための基準点となる
- 運用ルール（The schema）： Wikiの構造や整理の仕方、リンクの貼り方などのルールを記述したファイル。AIコーディングツールを用いる場合はCLAUDE.md（Claude Code用）やAGENTS.md（OpenAI Codex用）がこれに当たる。これがあることで、AIは単なるチャット相手ではなく、規律ある整理役として振る舞えるようになる
- Wikiページの集まり（The wiki）： AIが作成し更新するMarkdown（マークダウン：簡単な記号を用いるテキスト形式）ファイル群。人物、概念、プロジェクトごとのページが作られ、要約や比較、全体像のまとめなども含まれる。ページ間には相互リンクが張られ、整理された状態が維持される
運用の基本ループ
Wikiを健全に育てるために、以下の3つの操作を繰り返す。
1. 取り込み（Ingest）
新しい資料を元資料に追加すると、AIがそれを読み込み、要約ページを作成し、目次を更新し、関連する既存ページも修正する。カルパシー氏によると、1つの資料の追加で10〜15ページに影響することもあるという。
2. 質問（Query）
Wikiに対して質問すると、AIがまず目次（index.mdファイル）を読み、関連ページをたどって回答を組み立てる。ここで重要なのは、良い回答はWikiの新しいページとして保存できる点だ。普通のチャットでは、良い分析が生まれても会話の中に埋もれてしまう。LLM Wikiでは、その分析自体をページ化して蓄積できる。
3. 点検（Lint）
定期的にAIにWiki全体の健全性をチェックさせる操作だ。具体的には以下のような問題を検出する。
- ページ間の矛盾（新しい資料と古い記述の食い違いなど）
- 古くなった記述
- どこからもリンクされていない孤立ページ
- 欠けている相互参照
- 追加で調べるべきテーマの提案
Wikiの道しるべとなる2つのファイル
Wikiが大きくなっても、AIと人間が迷わないために、2つの特別なファイルが用意されている。
- index.md（目次）： Wiki内の全ページへのリンクと1行の説明をまとめたカタログ。AIが質問に答えるとき、まずこのファイルを読んで関連ページを探す。カルパシー氏は、中規模（元資料約100件、Wikiページ数百件程度）ならこの目次だけで十分に機能するとしている
- log.md（作業記録）： いつ何を取り込んだか、どんな質問をしたか、いつ点検したかを時系列で記録する日誌。Wikiの成長過程を振り返り、AIが最近の作業状況を把握するために役立つ
どんな場面で使えるのか
カルパシー氏は、以下のような活用例を挙げている。
- 個人の知識管理： 目標、健康記録、自己啓発メモ、ポッドキャストのノートなどを整理し、自分自身の「構造化された記録」を育てる
- 研究： 論文や記事を数週間〜数カ月かけて読み込み、テーマごとのまとめを段階的に充実させていく
- 読書ノート： 章ごとに登場人物、テーマ、伏線などのページを作り、読了後には豊かな「読書コンパニオンWiki」ができる
- ビジネス／チーム運用： Slackのスレッド、会議の議事録、プロジェクト文書、顧客対応の記録などからAIがWikiを自動構築し更新する
- その他： 競合分析、旅行計画、趣味の深掘り、資格試験の勉強など、知識を時間とともに蓄積したいあらゆる場面
カルパシー氏自身は、Obsidian（オブシディアン：Markdownエディタ）を横に開き、反対側にAIエージェント（Claude Codeなど）を配置して使っている。AIがWikiを編集すると、Obsidianのグラフビュー（ページ間のリンクを視覚化する機能）でリアルタイムに変化を確認できるという。
LLM Wikiを試すためのツールとコミュニティーの動き
LLM Wikiはまだコンセプト先行の段階であり、誰もが使える決定版ツールは存在しない。ただし、カルパシー氏の公開からわずか数日で複数のオープンソース実装が登場しており、動きは速い。
推奨ツール
カルパシー氏自身がGist（ギスト：GitHub上でコードや文書を手軽に共有できるサービス）の中で挙げている主なツールは以下の通りだ。
- Obsidian： 大量のMarkdownファイルをリンク付きで閲覧＆管理できるエディタ。グラフビューでWikiの全体像やページ間のつながりを視覚的に確認できる。カルパシー氏はこれを「IDE（統合開発環境）」に例えているが、「LLM Wikiに最適な閲覧ツール」という表現がピッタリ。閲覧だけでなく、資料作成でも活躍する
- Obsidian Web Clipper： ブラウザChrome拡張機能。Web記事をMarkdown形式に変換して、元資料として素早く取り込める
- qmd： Markdownファイル用のローカル検索エンジン。キーワード検索と意味検索の両方に対応しており、Wikiが大きくなったときにindex.mdファイルを補完する役割を果たす
- Marp（オプション）： Markdownからスライド資料を作成できるツール。Obsidian用プラグインもあり、Wikiの内容からプレゼンテーションを直接生成できる
- Dataview（オプション）： Obsidianプラグイン。WikiページのYAMLフロントマター（ページ先頭に書くメタデータ）に対してクエリ（問い合わせ）を実行し、動的なテーブルやリストを自動生成できる。タグや日付でページを絞り込みたい場合に便利
コミュニティーでの実装例
カルパシー氏のGistは5千以上のスターを集め、コメント欄には多数の実装報告が寄せられている。代表的なものを紹介するが、複数の流儀が並立している段階であり、まだ「これ」とお薦めできるものはない。
- ekadetov/llm-wiki： カルパシー氏の設計に沿い、raw/、wiki/、CLAUDE.md、index.mdなどの基本構成を備えたClaude Codeプラグイン
- AgriciDaniel/claude-obsidian： ObsidianのVault（保管庫）をLLM Wiki的な知識ベースとして使う実装。グラフビューによる可視化まで含まれており、現時点でGitHub上のスター数が比較的多い
- nashsu/llm_wiki： デスクトップアプリ（Tauri製）として実装されたLLM Wiki。英語・中国語に対応し、会話履歴の保存やWikiへの自動取り込みなどの独自機能を備えている
知っておくべき懸念点
最後に、LLM Wikiに対する主な懸念も押さえておこう。コミュニティーでは以下のような指摘があった。
- AIの誤りが知識として定着するリスク： AIの要約や再編集を重ねると、不正確な情報（ハルシネーション）がWikiに永続化する恐れがある。カルパシー氏の設計では、元資料を不変に保ち、定期的な点検と人間の確認で対処する想定だが、万能ではない
- 品質管理の負担はゼロにはならない： AIエージェントによって維持管理の手間は大幅に減るものの、AIが作った内容を全くチェックしなくてよいわけではない。特に業務や研究など重要な領域では、人間による確認が引き続き必要になる
情報元
Copyright© Digital Advantage Corp. All Rights Reserved.