2026 年 4 月、Andrej Karpathy が GitHub Gist を公開しました。その中で彼は、ある手法について説明しています。彼はその手法を LLM Wiki と呼んでいます。
その後、4 つのチームが同じものを構築しました。Cognition は DeepWiki を構築しました。Factory は AutoWiki を構築しました。LangChain は OpenWiki をリリースしました。Garry Tan は GBrain をリリースしました。
4 つのシステムすべてで手法は同じです。LLM がソースドキュメントを一度だけ読み取ります。その情報をマークダウンページに書き出します。そして、ソースが変更されたときにページを最新の状態に保ちます。エージェントはこれらのページを読み取ります。質問のたびにソースドキュメントを再度読み取ることはありません。
人々はこれらのシステムをエージェント Wiki と呼んでいます。この記事では、その概要、各チームが構築したもの、手法の限界、そして多くの人が見逃している重要な違いの 1 つについて説明します。
アイデア：クエリ時ではなく、取り込み時にコンパイルする
モデルに大量のドキュメントセットを提供するための一般的な方法は、検索です。ドキュメントをデータベースに入れ、ドキュメントを部分に分割し、各部分の埋め込みを作成します。質問ごとに、システムは関連する部分を見つけ出します。
この方法は機能します。しかし、問題もあります。システムは結果を保持しません。生の部分から毎回回答を構築し直します。10 回目の回答は 1 回目の回答よりも優れているわけではありません。作業コストを 10 回支払うことになります。
エージェント Wiki はこのコストを移動させます。モデルは、ソースを読み取る際に、その作業を一度だけ行います。結果をページに書き出します。ページは残り続けます。
新しいソースが取り込まれると、モデルは以下の手順を実行します。ソースを読み取り、関連するページを変更し、要約を修正し、ページと矛盾する情報をマークします。
どちらの方法も正しいです。2 つの点で異なります。最初の違いは、コストをいつ支払うかです。2 つ目の違いは、質問の後に何が残るかです。
各システムには、同じ 3 つの層があります。
レイヤー 1 はソースドキュメントです。これらはあなたの記事、論文、リポジトリです。モデルはそれらを読み取ります。モデルはそれらを変更しません。
レイヤー 2 は Wiki です。Wiki はマークダウンです。モデルが Wiki のすべてを記述します。Wiki には、要約、各トピックのページ、およびページ間のリンクが含まれます。
レイヤー 3 はスキーマファイルです。このファイルは、Wiki の構造をモデルに伝えます。また、実行すべきタスクもモデルに伝えます。通常のファイルは CLAUDE.md または AGENTS.md です。このファイルにより、モデルは Wiki の適切なメンテナーとなります。
システムは 3 つの操作を実行します。
取り込み：モデルが新しいソースを読み取ります。次に、モデルはデータを関連する各ページに書き込みます。
クエリ：あなたは Wiki に質問します。良い回答を新しいページとして Wiki に書き戻すことができます。
リント：モデルが Wiki を検査します。矛盾する情報を見つけます。古すぎる情報を見つけます。リンクのないページを見つけます。
なぜ機能するのか：
人間の Wiki は時間の経過とともに不正確になります。その原因は特定できます。難しいのはソースを読むことではありません。難しいのはアイデアを持つことでもありません。難しいのはメンテナンスです。
メンテナンスには以下のタスクがあります。ページ間のリンクを修正する必要があります。要約を正確に保つ必要があります。新しいドキュメントを既存のページと比較する必要があります。
この作業は止まりません。この作業に報酬はありません。忙しいチームはまずこの作業を止めます。すると Wiki は不正確になります。そして、人々はそれを使わなくなります。
モデルはこの作業を問題なく実行します。モデルは飽きることがありません。モデルはリンクを忘れません。モデルは 1 回の操作で 15 個のファイルを変更できます。
このアイデアは古いものです。Vannevar Bush は 1945 年に Memex について説明しました。Memex は、ドキュメント間にリンクがある個人用のドキュメントストアです。Bush はメンテナンスに対する答えを持っていませんでした。モデルがその答えです。
名前の由来
Karpathy の Gist を直接読んでください。要約よりも正確です。
彼は一般的な方法について次のように書いています。"LLM は、すべての質問に対してゼロから知識を再発見しています。蓄積がありません。"
彼の方法は、情報を検索するのではなく、コンパイルすることです。そうすれば、"知識は一度コンパイルされ、その後最新の状態に保たれ、クエリのたびに再導出されることはありません。" 結果は、"永続的で、複合的な成果物" です。
あなたは Wiki を書きません。彼はこう書いています。"あなたは Wiki を自分で書くことは決して（またはめったに）ありません。LLM がすべてを書き、維持します。" 彼はエージェントと Obsidian を一緒に使います。彼はこう書いています。"Obsidian は IDE であり、LLM はプログラマーであり、Wiki はコードベースです。"
Gist はサイズの制限を示しています。多くの要約はこの制限を含んでいません。埋め込みを使用しない方法は、"適度な規模（約 100 のソース、約数百のページ）で驚くほど良好に機能し、埋め込みベースの RAG インフラストラクチャを必要としません。"
より多くのソースについては、Gist は検索を追加するように指示しています。例として qmd を挙げています。Gist は qmd を "BM25/ベクトル検索のハイブリッドと LLM 再ランク付けを備えた、マークダウンファイル用のローカル検索エンジン" と説明しています。
したがって、ルールはサイズに関するものです。ルールは置き換えに関するものではありません。ソースセットが小さい場合は検索インフラストラクチャを使用しないでください。ソースセットが大きくなったら検索を追加してください。
各ラボが実際に構築したもの
ここで、このパターンはアイデアからエンジニアリングへと変わり、実装間の違いが有用な部分となります。
Cognition: DeepWiki、公共ユーティリティとしての Wiki
Cognition はこの手法を GitHub 上のパブリックリポジトリに適用しました。パブリックリポジトリの URL の github.com を deepwiki.com に置き換えます。すると、そのコードベースの Wiki が表示されます。Wiki には、アーキテクチャの概要、ファイルインデックス、依存関係グラフ、および検索機能があります。Wiki にはソース（Cognition）へのリンクがあります。
5 万以上の最大のパブリックリポジトリに Wiki があります。リストには MCP と LangChain が含まれています。
2 つ目のポイントの方が重要です。Wiki はプロダクトではありません。Wiki はエージェントのための検索インフラストラクチャです。Devin は Wiki を使用してコードベース内の関連コードを見つけます。したがって、DeepWiki は Devin におけるコード検索の下にあるコンパイルされたレイヤーです（Devin Docs）。
Factory: AutoWiki、ビルド成果物としてのドキュメント
Factory はこの手法を継続的インテグレーションに適用しました。Factory は、ドキュメントはビルド成果物であるべきであり、別のプロジェクトであってはならないと書いています。ドキュメントはソースから生成され、コードベースの構造を持ち、リポジトリが変更されると変更されます（Factory）。
Wiki を作成する方法には 2 つのパスがあります。パス 1 は構造スキャンです。README ファイル、パッケージマニフェスト、CI 設定、エントリポイントを読み取ります。パス 2 はセマンティックスキャンです。ルート、API エンドポイント、サービス クラス、データベース スキーマ、フィーチャー フラグを読み取ります。
Factory は作業を専門化されたエージェント間で分割します。各エージェントはリポジトリの一部を担当します。各エージェントは、1 つの良いページを書くのに十分なコンテキストを取得します。この方法は、既知の問題を防ぎます。つまり、1 つのエージェントだけでは大規模なリポジトリの貧弱なドキュメントを作成してしまうという問題です。
Factory は、規律ではなくインフラストラクチャによって Wiki を正確に保ちます。/wiki コマンドで Wiki を再作成します。/install-wiki コマンドは CI ワークフローを作成します。このワークフローは、デフォルトブランチへのプッシュごとに Wiki を再作成します。GitHub の場合、Wiki はリポジトリの Wiki タブに移動します（Factory Docs）。
LangChain: OpenWiki、そしてコードからすべてへの飛躍
LangChain は OpenWiki をオープンソースソフトウェアとしてリリースしました。OpenWiki は CLI ツールです。コードベースのエージェントドキュメントを作成し、維持します。その後、LangChain は OpenWiki Brains をリリースしました。これには 2 つのモードがあります。Code Brain は最初のモードで、リポジトリ用です。Personal Brain は 2 つ目のモードで、あなた自身のソース用です（LangChain）。
Personal Brain が重要な変更点です。Gmail、Notion、git リポジトリ、X、Hacker News、ウェブ検索からデータを読み取ります。これらすべてのデータを 1 つのローカルマークダウン Wiki に書き込みます。エージェントはこの Wiki を読み取ります。この手法は、リポジトリのドキュメントから、あなたの仕事のドキュメントへと変わりました。
各チームは出力について同じ決定を下しました。出力は人が読むためのテキストではありません。出力は LLM コンテキスト用の構造化されたマークダウンです。見出し、ページ間のリンク、要約が含まれています。この構造により、エージェントは関連情報を迅速に見つけることができます。Wiki の読者はモデルです。
GBrain: 個人規模のオープンソース版
GBrain はこの手法を、コードベースではなく、個人の知識ストアに適用します。GBrain は git リポジトリ内のマークダウンを使用します。スキーマファイルを持っています。トピック間のリンクグラフを自動的に作成します。
GBrain は、この手法がごくわずかなインフラストラクチャしか必要としないことを示しています。ベクトルデータベースはありません。サービスはありません。ファイルがあるだけです。モデルがファイルを維持します。人がファイルを読むことができます。
テクニックマトリックス
4 つのシステムは同じ構造を持っています。git 内のマークダウンを使用しています。スキーマファイルを使用しています。取り込み時にコンパイルします。ソースが変更されたときに Wiki を再作成します。エージェントが読むためのページを書きます。4 つのチームが 4 つの異なる問題を解決し、同じ構造を作り上げました。この一致は、その構造が正しいという強力な証拠です。
メンテナンスにおいてシステムは異なります。Factory は CI でメンテナンスを行います。他の 3 つのシステムは、人がコマンドを実行したときにメンテナンスを行います。したがって、それらの Wiki は、最後のコマンドが実行された時点での正確さしかありません。
限界
限界 1 はサイズです。Karpathy がこの限界を示しています。埋め込みを使用しない方法は、約 100 のソースに対して正確です。より多くのページの場合は、検索エンジンを追加する必要があります。Gist は、BM25 検索とベクトル検索を一緒に使用することを指示しています。
限界 2 は精度です。モデルは取り込み時に情報をコンパイルします。初期の要約がソースから詳細を削除してしまう可能性があります。後の回答にはすべてこのエラーが含まれます。生の部分からの検索にはこの問題はありません。繰り返し作業のコストと引き換えに、データ損失のリスクを負うことになります。
限界 3 は古い情報です。ページは、最後の更新時点での正確さしかありません。これが、Factory の方法が重要である理由です。不正確な Wiki は、Wiki がないことよりも悪いです。不正確な情報は、正確な情報の形式をとっています。
限界 4 はコストです。ページを作成するためにトークンを支払います。誰も読まないページを作成する可能性があります。また、変更されていないページをリントするためにもトークンを支払います。
Wiki はメモリではない
知っておくべき違いが 1 つあります。この分野の言葉はまだ正確ではありません。
多くの人がこれらのシステムをメモリと呼んでいます。LangChain は OpenWiki を AI エージェントのための Wiki メモリレイヤーと呼んでいます。他の人々は、Wiki がエージェントにメモリを提供すると言います。メモリという言葉には、ここでは 2 つの異なる意味があります。
最初の意味は、ドキュメントセットの知識です。Wiki はこれを行います。ドキュメント、リポジトリ、または Gmail 内のデータをコンパイルします。ドキュメントに何が含まれているかを教えてくれます。
2 つ目の意味は、ユーザーのメモリです。これは異なるデータです。個人の好みが含まれます。個人の決定が含まれます。チームが却下した方法が含まれます。エージェントが別のアプリケーションで方法を試した結果が含まれます。
ユーザーのメモリは異なる構造を持っています。それはドキュメントセットではなく、個人に関連しています。取り込みではなく、インタラクションから生まれます。また、ユーザーごとに以下のタスクを実行する必要があります。矛盾する情報を修正し、古すぎる情報を削除し、各項目の出典を保持し、リクエストに応じてデータを削除することです。
Wiki は最初のタスクを正しく実行します。Wiki は 2 つ目のタスクを実行しません。あなたの Gmail Wiki は、エージェントにあなたの Gmail に何があるかを伝えます。火曜日の会話であなたがある決定を変更したことをエージェントに伝えることはできません。ある方法がすでにあなたにとって失敗したことをエージェントに伝えることはできません。
メモリレイヤーは 2 つ目のタスクを実行します。Mem0 はその一例です。各メモリを user_id とともに保持します。そのため、メモリはセッション、アプリケーション、エージェント間でユーザーとともに移動します。事実が変わったときに、その事実をその場で変更します。毎回新しいレコードを追加するわけではありません。
2 つのシステムは代替手段ではありません。両方を使用してください。間違いは Wiki を使わないことではありません。間違いは、Wiki がユーザーのメモリを提供してくれると考えることです。
まとめ
エージェント Wiki のアイデアは正しいです。知識を一度コンパイルします。その後、正確に保ちます。質問のたびに再構築しないでください。メンテナンスは人間の Wiki を頓挫させましたが、モデルはコストゼロでメンテナンスを行います。4 つのチームが数ヶ月で同じ構造を構築しました。これは強力な証拠です。
以下の 3 つのことを行ってください。ドキュメントセットが安定しており、頻繁に読む場合は、ドキュメントをページにコンパイルしてください。Gist が指示するように、ドキュメントセットが大きくなったら検索を追加してください。ドキュメントセットの知識とユーザーのメモリの違いを理解してください。Wiki は前者を提供します。Wiki は後者を提供しません。
In Context #17
このブログは、AI エージェントのメモリとコンテキストエンジニアリングを扱う [@mem0ai](https://x.com/@mem0ai) のブログシリーズ、In Context の一部です。
Mem0 は、LLM および AI エージェント向けに設計された、インテリジェントでオープンソースのメモリレイヤーです。セッションを超えた、長期的でパーソナライズされ、コンテキストを認識したインタラクションを提供します。
- 無料の API キーはこちらから入手してください: app.mem0.ai
- または、オープンソースの GitHub リポジトリ から mem0 をセルフホストしてください
参考文献
- Andrej Karpathy, LLM Wiki (GitHub Gist, April 2026)
- qmd: マークダウン用ローカルハイブリッド BM25/ベクトル検索
- Cognition, DeepWiki: あらゆるリポジトリ向け AI ドキュメント
- Devin Docs, DeepWiki
- Factory, Introducing AutoWiki
- Factory Documentation, AutoWiki 概要
- langchain-ai/openwiki (GitHub)
- LangChain, Wiki メモリ
- garrytan/gbrain (GitHub)
- Vannevar Bush, As We May Think (The Atlantic, 1945)
- Mem0
