Hacker News、Karpathyの「LLM Wiki」構想に注目

RAGではなく、維持され続けるwikiという発想

Andrej Karpathyが2026年4月4日に公開した LLM Wiki のgistは、多くのdocument workflowが依然としてRAGにとどまっていると指摘する。つまり、raw fileを投入し、query時にrelevant chunkを探し、その場で答えを組み立てる方式だ。クロール時点でこの話題のHacker Newsスレッドは 274ポイント、89コメント で、反応の中心は「knowledge managementの新しい作法」よりも「agent workflowの設計図」としての価値にあった。

Karpathyの提案は、raw documentの上に LLMが継続的に書き換えるinterlinked wiki を置くことだ。新しいsourceが入るたびに、agentは単にindexを更新するのではなく、topic summaryを修正し、entity pageを更新し、矛盾を記録し、cross-linkを増やし、全体のsynthesisを育てていく。こうしてwikiは、質問のたびにその場で再構築されるものではなく、すでに整理済みの知識が積み上がる persistent artifact になる。

3つの層と3つのoperation

構造は3層だ。1つ目は raw sources。記事、論文、画像、データなどのimmutableな原典群で、agentは読むだけで変更しない。2つ目は wiki。summary、concept page、entity page、comparison、synthesisなど、LLMが書き続けるmarkdown群だ。3つ目は schema で、CodexのAGENTS.mdやClaude CodeのCLAUDE.mdのように、wikiの構造や運用規則をagentに教える文書である。

operationは Ingest、Query、Lint に整理される。Ingestでは新しいsourceを読み、summaryを書き、indexを更新し、関係するページを横断的に修正し、logに追記する。Queryではwikiを検索して回答を作り、その分析結果自体を新しいwiki pageとして保存できる。Lintでは矛盾、stale claim、orphan page、弱いcross-reference、不足しているconceptを点検する。加えて index.md と log.md を分けることで、content-orientedな地図とchronologicalな履歴の両方を保つ設計になっている。

なぜ今、刺さるのか

この案が強いのは、LLMを検索補助ではなく 保守作業の代行者 として扱う点にある。KarpathyはObsidianをIDE、LLMをprogrammer、wikiをcodebaseに例える。knowledge base運用の本当のコストは、思考そのものではなく、cross-link更新、summary修正、矛盾整理、複数ページの整合性維持といった bookkeeping にある。人間はそこに疲れてwikiを放棄しがちだが、agentにはその種の退屈がない。

このgistは意図的に抽象度を高く保っており、それもまたHNで受けた理由だろう。personal research、読書メモ、due diligence、team wikiなど、sourceが時間とともに増える領域ならどこにも当てはめられる。要するに「より賢いRAGを作る」話ではなく、「knowledge maintenanceそのものをagentに引き受けさせる」話なのである。

出典: Karpathy gist, Hacker News議論