OpenAI 創辦團隊成員、Tesla 前 AI 總監 Andrej Karpathy が X 上で「LLM Knowledge Bases」工作手順を公開し、彼が最近、大量 token の使用量を「コード操作」から「知識操作」へ切り替えたことを説明している—LLM を使って散らばった論文、記事、フォルダ、画像を、自動で維持される個人 wiki にまとめ上げる。彼の一連の仕組みは、彼自身の研究プロジェクトで既に約 ~100 本の記事、~40 万字ほどが蓄積されており、全工程が LLM による書き込みと更新で行われている。本稿では Karpathy の完全な setup を整理し、同じものを複製したい開発者に実装できるチェックリストを提示する。
コア理念：raw データ → LLM 編譯 → wiki → Q&A
Karpathy の設計哲学は、一言に圧縮するとこうなる：「raw data を入力し、LLM が wiki に編譯し、wiki をさらに LLM が検索し、検索結果を引き続き wiki に書き戻す」。このシステムの鍵は、人間の役割を「メモを書く」から「LLM が書いたメモを監督する」へと移し、knowledge base は手動で維持する Notion や Roam Research ではなく、LLM が自動で書き込み・維持する markdown ファイル群にする点にある。
彼は、自分は wiki を直接編集することがほとんどない—書き込み、リンク補完、構造の抽出、一貫性のチェックはすべて LLM が行う、と述べている。この「LLM 主導のコンテンツ、人間は監視」という方式は、多くの人が手動で Obsidian／Notion を書く習慣とはまったく違っており、このワークフローの核心となる転換だ。
Step 1：Data Ingest—すべての raw データを raw/ フォルダに放り込む
Karpathy の入口はシンプルだ。raw/ フォルダを作り、すべてのソース資料をそこに投げ込む—論文 PDF、ニュース記事、code repo、データセット、画像、講演資料。LLM はこのフォルダを入力として受け取り、段階的に「編譯」して wiki を出力する。
彼は特に次の 2 つのツールに触れている：
Obsidian Web Clipper 拡張機能—Web の記事を直接 .md ファイルに変換して raw/ に保存する
カスタム hotkey—Web 上の関連画像をローカルにダウンロードできるようにして、LLM が後続の引用時に直接参照できるようにする
重要な設計：すべての外部資料を「オフライン・ローカル」形式で保持し、その後の LLM 検索が「元のリンクが見つからない」問題で詰まないようにする。
Step 2：LLM 編譯 wiki—自動で分類し、記事を作り、逆リンクを張る
raw/ が準備できたら、Karpathy は LLM を使って wiki をインクリメンタル（incrementally）に「編譯」する。つまり、.md ファイルで構成される目次構造だ。LLM は次の 4 つを行う：
raw/ 内のすべての資料に対して要約を書く
資料を概念（concepts）に分類する
各概念ごとに 1 本の記事を書く
記事同士の間に逆リンク（backlinks）を作る
このプロセスは「インクリメンタル」だ。新しく raw/ に追加されたデータだけを LLM が更新し、影響を受ける wiki の部分だけを直せばよく、全体を最初から大編譯する必要がない。長期的に積み上げる研究テーマ（Karpathy 自身の研究 wiki は既に ~100 本の記事、~40 万字規模）では、このインクリメンタル更新のほうが、一度きりの大編譯より実用的だ。
Step 3：Obsidian を IDE「フロントエンド」として、Marp などのプラグインで拡張
Karpathy は Obsidian を、このシステムの視覚化フロントエンドとして使う—raw/ の資料、編譯された wiki、そして派生するビジュアル（スライド、図表）を同時に確認できる。Obsidian の利点は、そもそも markdown エディタであり、LLM が出力する .md ファイルと自然に相性がよく、plugin 拡張にも対応していることだ。
彼は特に Marp というプラグインに言及している。markdown をそのまま投影スライド形式にレンダリングできるため、LLM は文字だけでなくプレゼンも出力できる。
Step 4：Q&A—wiki 全体を LLM の「検索対象」にする
Karpathy の wiki が「~100 本の記事、~40 万字」の規模に到達すると、最も面白い能力が見えてくる。LLM agent に対して任意の複雑な質問を投げると、それが自分で調べに行き、wiki の関連段落を引用して答えを作ってくれる。
当初彼は、「fancy RAG」（ベクトル検索、埋め込みモデル、re-ranking など）がこの規模で必要だと見込んでいたが、実測の結果こう分かった：LLM 自身が index ファイルと各記事の短い要約を維持し、検索時にはそれらの index と要約によって関連段落を見つけられるので、複雑な RAG を使わなくても「~40 万字」というスケールで十分うまく動く。
この観察は、2024 年以降の「ベクトル DB が過熱しており、実際には多くのケースで不要」という産業の合意とも一致している—knowledge base が百万字以下なら、structured markdown + LLM が自主管理する index で足りる。
Step 5：出力—単なるテキストではなく markdown／slides／図表
Karpathy のもう 1 つの設計：彼は LLM に「ターミナルの文字だけ」を返させたいのではなく、LLM が構造化された出力を生成するようにする—markdown ファイル、Marp のスライド、matplotlib のグラフ、可視化データなど。これらの出力は Obsidian 内で確認できる。
さらに重要なのは循環だ。生成された結果はしばしば Karpathy が「アーカイブ」として wiki に書き戻し、将来の検索を強化する。彼は「自分の探索と検索は常に knowledge base に積み上がっていく（add up）」と表現している—これは stateful で、成長し続けるものだ。ChatGPT の会話が「毎回ゼロから始める」のと対照的である。
Step 6：Linting—LLM が自己健康診断し、一貫性の問題と新しい記事候補を見つける
Karpathy は wiki に対して LLM を動かし、「健康チェック」として次の 3 種類の問題に対応する：
資料の不一致を見つける（同じ概念が異なる章で矛盾して説明されている）
Web 検索で不足データを補う
面白いクロス概念のつながりを見つけ、新しい記事候補を推薦する
この linting パスは、時間とともに wiki を「よりきれいに」するための鍵だ。これがないと、自動編譯で生成された wiki は徐々に矛盾やノイズが蓄積していく。LLM はこのタスクで良い結果を出しており、Karpathy は、このワークフローを長期運用できる理由の一つだと考えている。
Step 7：自作の追加ツール—たとえば自前 wiki 検索エンジン
Karpathy は「vibe coded」で小型の検索エンジンを作り、それを自分の wiki 上で動かしたと述べている。このツールには 2 つの使い方がある。（1）彼自身が直接 Web UI で使う。 （2）より一般的には、この検索エンジンを CLI インターフェース経由で LLM に渡して、LLM が大規模な問い合わせを行うときに関連段落へ正確にヒットできるようにする。
この方式（人間が CLI を用意し、LLM がそれをツールとして使う）は、Claude Code や OpenAI Codex のような agent フレームワークにおける中核設計だ。LLM がすべてのデータを直接読むのではなく、ツール（CLI、search engine、file system）によって必要なサブセットを取得する。
Step 8：未来の方向性—合成データ生成、モデルの微調整
wiki の規模が十分に大きくなったとき、Karpathy は次の 2 つの発展方向を提示している：
wiki から合成データ（synthetic data）を生成する—特定のテーマについて LLM が自動で Q&A のペアや教材文、サンプルを作り出す
合成データで専用 LLM を微調整する—個人用 LLM が「重み」の中でこれらのデータを知っている状態にし、単に context window の中で読むだけにとどめない
この方向性は knowledge base を「外部記憶」から「内化記憶」へ進めるもので、パーソナライズされた AI の次のステップだ。ただし Karpathy 自身も、これにはより多くの基盤整備が必要で、現時点ではまだ探索段階だと認めている。
Karpathy の「Idea File」発想：構想は共有するがコードは共有しない
この投稿がバズった後、Karpathy は続く投稿で新しい概念「idea file」を提案した。LLM agent の時代において、具体的なコードを共有するよりも「アイデア」を共有し、相手の agent がそれに基づいてカスタムされ、自分のために作り込んでくれるようにする、というものだ。
彼はこの LLM Knowledge Bases の「idea file」を GitHub gist に置いており、意図的に抽象度を高く保ち、各人の agent が自由に発揮できる余地を残している。これは将来の dev community の新しい共有スタイルになるかもしれない—GitHub repo でも npm パッケージでもなく、「指示ファイル」で、LLM 向けのオープンな仕様になる。
実装の提案：台湾の読者はどう始めるか
このシステムをまるごと複製したい台湾の開発者に向けた実務的な入門ルート：
Obsidian は無料ソフトで、macOS／Windows／Linux すべてに対応しており、公式サイトからダウンロードできる
Web Clipper 拡張機能は Chrome／Firefox／Edge にインストール可能
LLM 側は Claude Code（CLI）、ChatGPT（API）、またはローカルの Ollama（強力な顯卡 があるなら）を選べる
raw/ と wiki/ の 2 つのフォルダは Obsidian vault と同じ階層に置くのがおすすめで、.gitignore 以外のバージョン管理も追加する（LLM が壊して書き換えたときに救える）
最も馴染みのある研究テーマから始める—たとえば「2026 暗号取引所のコンプライアンス動向」「LLM 推論アーキテクチャ」など。30–50 本ほど積み上げると、Q&A の能力が明らかに改善する
Karpathy は投稿の最後でこう言っている：「ここには素晴らしい新製品を作る余地がある、いまのような雑なスクリプトの寄せ集めの形ではない。」builder にとって、この thread はワークフローの説明であると同時に、起業のネタでもある—LLM が自動で wiki を作る、という領域は、まだ明確なプロダクトの勝ち組がいない市場だ。
この記事は Karpathy が初めて明かした：LLM で個人ナレッジベースを作る完全な方法 最初に 鏈新聞 ABMedia に掲載された。
関連記事
