LLM Wiki

Andrej Karpathy が2026年4月に公開した、LLMに知識ベースの構築・保守を委任するパターン。

核心

  • 従来のRAG(毎回検索→再解釈)ではなく、取り込み時点で知識を構造化してMarkdownで永続化する
  • 三層構造: raw/(不変のソース)→ wiki/(LLMが維持する構造化ページ)→ CLAUDE.md(スキーマ・ルール)
  • 3操作: Ingest(取り込み・整理)、Query(照会)、Lint(定期ヘルスチェック)
  • 人間の仕事は「ソースのキュレーションと良い質問」、LLMの仕事は「それ以外全て」

わーさんの保管庫との関係

保管庫は「当時の記録」が本体であり、知識の倉庫ではない。LLM Wikiをそのまま適用する対象ではないが、以下の点で既に近い実践がある:

  • CLAUDE.md / _COWORK_RULES.md がスキーマ層として機能している
  • for_LLM/ がLLM向け参照資料として raw 的な役割を果たしている
  • LLM引き継ぎ がセッション間の知識持続を担っている(log.md に相当)

逆に LLM Wiki にない、わーさん独自の実践:

  • プライバシー制御の粒度(publish制御)
  • 複数出力先への配信設計(Quartz、ロリポップ)
  • LLMフィルター多重化への警戒(LLM補助 タグによる来歴管理)

この保管庫での導入方針

「気になる一時メモ」等を起点にした インプット管理の仕組み として部分導入。

  • LLM wiki/ にLLMが整理するページを置く
  • 流れ: 気になる → LLMに調べ物を頼む → 会話で意見・感想を交わす → 成果をwiki化
  • 一時メモは「まだ会話していないもの」のキュー

興味先行運用と、ナレッジ管理の目的化の罠

LLM Wikiの本来の分業は、「核心」に書いた通り人間が担うのはソースのキュレーションと良い質問だけで、それ以外はLLMが自動的に編む——つまり人間はナレッジ管理そのものを担わなくていい設計になっている。ここを取り違えて「自分で効率よく管理しよう」と人間側が主語になった瞬間、分類・命名・リンク設計・定期棚卸しといった作業が前提スキルとして要求されはじめる(罠1:分業の抱え込み)。一方で、ナレッジを効率的に管理することそのものに溺れて目的を見失う人もいる。noteなどで「AIとObsidian連携」が繰り返しネタとして消費される現象は、この分業の取り違えと管理の目的化が交差したところに立ち上がっているように見える。

もうひとつの罠は、分業を正しく引き受けた先で待っている(罠2:選定の完璧主義)。人間の役割が「良いソース/良い質問」だと聞いた瞬間、「良いって……?」と問い直して基準を先に立てようとし、結果としてソースも問いも投げられなくなるパターンだ。ゲートを厳しくするほどwikiは育たない。

抜ける道は 興味先行運用 にある。興味があるものはその時点で本人にとって既に「良い」——だから「良さ」を意識的に選定するのではなく、興味があるものをそのまま投げれば、それが結果として「良いソース」「良い質問」になる。興味そのものが本来の分業(ソース+質問)を人間側に保たせ続けるエンジンになり、罠1(抱え込み)と罠2(完璧主義)の両方を構造的に回避できる。この保管庫の「気になる → LLMに調べ物 → 会話で意見・感想 → 成果をwiki化」というフローは、Karpathyの本来の分業を尊重したうえで、調べ物と成果の間に「対話」を挟むことで質を一段上げる改造版として設計されている。

ソース

最終リンク確認: 2026-04-21(大手除外)