別のチャットで調べたあの情報、複数の資料を横断して深く考えてほしいのに、表面的な答えしか返ってこない。そんなもどかしさを感じた経験がある人は多いはずです。
2026年4月、元Tesla AIディレクターでOpenAI共同創業者でもあるアンドレイ・カルパシー(Andrej Karpathy)が、そのもどかしさを根本から解決するアイデアをX(旧Twitter)に投稿しました。投稿はわずか1日でスター2,600超、フォーク500超という驚異的な反響を集め、世界中の開発者が即座に実装を始めるほどの話題になっています。
そのアイデアの名前がLLM Wikiです。
そもそもRAGって何? 既存の仕組みの限界から理解する
LLM Wikiを理解するためには、まず現在主流のRAG(ラグ)という技術を知っておく必要があります。
RAGとはRetrieval-Augmented Generationの略で、日本語では検索拡張生成と呼ばれます。わかりやすく言うと、AIに質問するとき、関連する資料をカンニングシートとして一緒に渡す仕組みです。ChatGPTのファイルアップロード機能やNotebookLMも、基本的にはこの考え方で動いています。
RAGは確かに便利です。しかし、構造的な弱点があります。それは毎回ゼロから調べ直すという点です。昨日同じテーマで調べた結果は引き継がれません。5つの資料をまとめて深く考える複雑な質問には弱く、知識が積み重なっていく感覚がありません。AIとの対話が毎回リセットされる会話になってしまうのです。
豆知識:RAGのカンニングシートの限界
LLMは一度に扱える情報量(トークン数)に上限があります。そのためRAGは質問に関連しそうな断片だけを切り取って渡す設計になっており、5つ以上の資料を横断して深く考える複雑な問いには対応しにくいという根本的な制約があります。
LLM Wikiの核心、知識を積み上げ続けるという発想の転換
カルパシーが提唱したLLM Wikiは、RAGとは根本的に異なる発想から生まれています。
RAGが質問のたびに資料を探して答えるのに対して、LLM WikiはAIが事前に資料を読み込んでウィキペディアのようなページを作り、それを常に更新・充実させ続けるというアプローチです。
カルパシー自身の言葉を要約すると、こうなります。新しいソースが来るたびに、LLMはそれをただ検索対象にするのではなく、読み込んで重要な情報を抽出し、既存のウィキに統合する。矛盾があれば指摘し、関連ページへの参照を追加し、知識の全体像を更新する。知識は一度コンパイルされ、その後も最新の状態に保たれ続ける。
つまり、LLM WikiとはAIが書いて維持する、あなただけの個人ウィキペディアのようなものです。あなたは資料を追加し、質問するだけでいい。整理・更新・相互参照という面倒な作業はすべてAIが担います。
3層アーキテクチャ、仕組みをもっと具体的に見てみよう
LLM Wikiは以下の3つの層で構成されます。それぞれの役割を理解すると、全体像がぐっとつかみやすくなります。
| 層の名前 | 内容 | 誰が操作するか |
|---|---|---|
| Raw Sources(生ソース) | 論文・記事・画像など一次資料。変更しない。 | 人間が追加・管理 |
| Wiki(ウィキ本体) | LLMが生成・更新するマークダウンファイル群。要約・概念ページ・相互参照などを含む。 | AIが書き、人間が読む |
| Schema(設計図) | AIがどう動くかを定義するルールファイル(CLAUDE.mdなど)。 | 人間とAIが共同で設計 |
カルパシーは自身のワークフローをこう説明しています。左にClaude Codeを開き、右にObsidian(マークダウンエディタ)を開く。AIが会話に基づいてファイルを編集し、私はリアルタイムで結果を見る。ObsidianがIDE(開発環境)で、AIがプログラマー、ウィキがコードベースだと。プログラマーでない人にとっては、秘書がノートに整理してくれて、自分はそれを見るだけというイメージが近いかもしれません。
3つの主要操作、Ingest・Query・Lint
LLM Wikiには3つの基本的な操作があります。これらを組み合わせることで、知識が雪だるま式に積み上がっていきます。
Ingest(取り込み)
新しい資料を追加したとき、AIはそれをただ保存するだけでなく、読み込んで要点を抽出し、既存のウィキ全体を更新します。1つの資料の追加が10〜15ページのウィキページに影響を与えることもあります。カルパシーは資料を1件ずつ取り込み、要約を確認しながら何を強調するかをAIに指示するというやり方を好んでいます。
Query(質問)
ウィキに対して質問すると、AIは関連ページを探して読み込み、出典付きの回答を生成します。重要なのは、良い回答はそのままウィキの新ページとして保存できる点です。比較分析、発見した関連性、まとめた考察は、チャット履歴に消えるのではなくウィキに蓄積されます。これにより、問いを立てること自体が知識ベースをさらに豊かにしていきます。
Lint(メンテナンス)
定期的にAIにウィキ全体の健全性チェックをさせます。矛盾するページ、古くなった情報、リンクのないページ、調べたほうがよさそうな新しい疑問などを検出・提案してくれます。人間が面倒でやらなくなりがちなメンテナンスを、AIが自動的に担ってくれるわけです。
こんな使い方ができる!シーン別の活用例
LLM Wikiは特定の人向けの技術ではなく、幅広いシーンで役立ちます。カルパシー自身が例として挙げていたものを、日本語でわかりやすく整理しました。
自己成長・健康管理
日々の日記、読んだ記事、聴いたポッドキャストのメモを蓄積することで、自分の思考パターンや健康状態の変化を構造化して把握できます。単なる日記帳ではなく、自分自身の取扱説明書が少しずつできあがっていくイメージです。
長期リサーチ・論文読み込み
数週間〜数ヶ月かけてあるテーマを深掘りするとき、読んだ論文や記事を追加するたびにウィキが充実し、やがて一貫した考察を持つ包括的なリサーチベースが完成します。
読書メモ(独自ファンウィキ)
小説を読みながら各章の内容をAIに取り込ませると、登場人物・テーマ・伏線・世界観がリンクした個人ファンウィキが自動的に構築されます。カルパシーはトールキンのファンウィキTolkien Gatewayを例に挙げ、あれだけのものを一人で作れるようになると表現しています。
チームの社内ウィキ自動メンテナンス
SlackのスレッドやMTGの議事録、プロジェクト資料を蓄積することで、誰も手を入れなくても最新の状態を保つ社内ウィキが実現します。誰もメンテしたくない問題をAIが解決するのです。
豆知識:Lex FridmanもLLM Wiki的な仕組みを実践中
テックポッドキャスターのLex Fridmanはランニング中にLLMと音声でやりとりするための、テーマ特化型ミニ知識ベースを生成していると語りました。ウォーキング中に音声メモを録り、それをウィキに統合するという使い方も現実的です。
なぜこれが機能するのか、人間とAIの分業という哲学
ウィキが続かない最大の理由は書くことや考えることではなく、メンテナンスのコストだとカルパシーは指摘します。相互参照の更新、要約の最新化、矛盾の解消、一貫性の維持。これらの作業は価値が増えるスピードより速く負担が積み重なるため、人間はウィキを諦めてしまいます。
LLMはこの問題を根本から解決します。AIは飽きず、相互参照の更新を忘れず、一度のターンで15ページを更新できます。メンテナンスのコストがほぼゼロになることで、ウィキは維持されつづけるのです。
カルパシーはこの発想を1945年のVannevar BushのMemexという概念とつなげています。Memexとは個人の知識を、連想的な参照とともに保存・探索できる装置として構想されたものです。Bushのビジョンに足りなかった誰がメンテするかという問いに、LLMが70年越しで答えを出したとも言えます。
人間の仕事は、ソースを選び、良い質問をし、何が重要かを考えること。AIの仕事は、それ以外のすべて。 この分業こそがLLM Wikiの本質です。
注意点と今後の可能性
コミュニティからはLLMがウィキを完全に自律管理すると、誤った合成や古い情報の生き残り、もっともらしいが信頼性の低いコンテンツが蓄積するリスクがあるという指摘も出ています。特に重要な主張には出典を紐付けること、矛盾・古い情報の定期チェック(Lint)を怠らないことが、実用上の重要なポイントになります。
一方で将来の可能性は非常に広がっています。カルパシーが示唆しているのは、ウィキが十分に成熟した段階でそのデータを使って小型のAIモデルをファインチューニングするというアイデアです。つまり、自分の読んだものや考えをすべて学習させた自分専用AIが生まれるかもしれません。個人の知識ベースが、やがて個人専用の知性へと変わっていく。そんな未来が、このアイデアの延長線上にあります。
知識を積み上がるものに変える第一歩
LLM Wikiは、AIとの関わり方をリセット型から蓄積型へと変えるアイデアです。ChatGPTやRAGが毎回ゼロから調べ直すのに対して、LLM Wikiは問うたびに賢くなるシステムを目指しています。
カルパシーはこのアイデアをコードではなくコンセプトとして共有したと述べています。特定のアプリやツールではなく、考え方のパターンとして提示したわけです。実際に世界中の開発者がObsidian、Claude Code、Go製ツールなど、様々な形で即座に実装を始めたことがその証明です。
技術的に実装するハードルは確かに存在しますが、考え方そのものはシンプルです。


コメント