最近、Andrej KarpathyのGistがテックコミュニティで広く拡散されています。読んで最初に思ったのは、このアイデアはほとんどの人が気づいている以上にObsidianと深い関係があるということです。この記事ではそのことについて書きます。
Karpathyとは
AIの世界を追っている人なら、この名前はおなじみでしょう。しかしあまり詳しくない方のために、まず説明しておく価値があると思います。
Karpathyは「大企業で製品を管理するAIリーダー」というタイプではなく、深層学習分野の真の第一人者です。
彼はスタンフォード大学でFei-Fei Li（ImageNetを主導し、現代のコンピュータビジョンを実質的に立ち上げた人物）の下で博士号を取得しました。Fei-Fei Liの研究室を離れた後、KarpathyはOpenAIに共同創業者の一人として加わりました。2017年、Teslaは彼を引き抜き、Autopilotの視覚認識システムを率いさせました。
Tesla在籍中、多くの人が今ではその結果を知っています。当時、Teslaはライダーを使わず、カメラ＋ニューラルネットワークだけという純粋なビジョンアプローチにこだわったほぼ唯一の自動運転企業でした。このアプローチは当時、あまりに過激だと酷評されました。その後の結果は誰の目にも明らかです。
彼は2022年にTeslaを去り、2023年に一時OpenAIに戻りましたが、その後再び離れ、自身のAI教育プロジェクトkarpathy.aiを立ち上げました。
私が彼に興味を持つのは、経歴だけでなく、彼が稀有な状態を保っているからです。世界クラスのエンジニアリングができる一方で、一般の人々に技術の根底にあるロジックを説明するために、記事を書いたりコースを録画したりする時間を惜しまない。
彼のGitHub上のnanoGPTやmicrogradは、GPTとバックプロパゲーションの最小限の再実装であり、一般の人々が本当に理解できるように設計されています。YouTubeのCS231nコースは、数え切れない人々に深層学習を教えてきました。
だからこそ、彼がGitHubに「LLMを使って知識ベースを管理する」というGistを書いたとき、それは瞬く間にテックコミュニティに広まりました。私はそれをじっくり読む価値があると思います。
彼が言ったこと
Gistのタイトルは LLM Wiki: A pattern for building personal knowledge bases with LLMs です。元のリンク：
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
彼の出発点は、多くの人が感じたことのある感覚です。知識ベースは増え続けるのに、実際に使える部分は減り続ける。
記事をブックマークし、Notionに読書メモを取り、Obsidianにメモの山を築く。しかし、次に特定の知識が必要になったとき、それを見つけられる確率は高くありません。見つけられないのではなく、散らばりすぎていて、相互に関連づけられていないのです。たとえ見つけても、断片であり、自分でつなぎ合わせなければなりません。
彼はこの問題を、既存の2つのソリューションの欠点に帰しています。
第一に：ブックマーク方式。
原文をそのまま放り込み、何もせず、検索に完全に依存する。問題は、検索が文書を見つけるのであって、答えを見つけるわけではないことです。自分で読んで、理解して、統合しなければなりません。
第二に：RAG方式（Retrieval-Augmented Generation）。
AIに大量の文書を提供し、その場で検索・生成させる。これはブックマークよりはるかに優れていますが、常に一時的で、毎回ゼロから始まり、蓄積がありません。
彼が提案するLLM Wikiは別のアイデアです。検索時にAIに一時的に整理させるのではなく、AIに絶えず更新され続けるWikiを維持させる。
LLM Wikiの仕組み
全体のアーキテクチャは3層です。
Raw Sources（生ソース）
普段読むもの：記事、書籍、動画の字幕、会議メモ。これらはそのまま、生の素材としてここに保存されます。
Wiki
一連のMarkdownファイル。それぞれがトピック、概念、エンティティに対応します。例えば、「機械学習 - 過学習」ページ、「読書メモ - ゲームに没頭する」ページ、「人物 - ファインマン」ページなどがあるかもしれません。
これらのファイルはあなたが書くのではなく、AIが書き、継続的にメンテナンスします。新しい素材が入ってくるたびに、AIは関連ページを更新し、ページ間の相互参照を確立し、矛盾があればフラグを立てます。
Schema（スキーマ）
「このWikiをどうあるべきか」をAIに伝える設定。例えば、各ノートに含めるべきフィールド、整理方法、孤立ノートとは何か、どの概念に専用ページが必要かなど。
そして3つのコア操作：
Ingest（取り込み）
新しい素材が入ってくるたびに、AIがそれを読み、10～15のWikiページを更新します。新しいページを作成するだけでなく、既存のコンテンツを更新し、相互参照を追加し、さらに確認が必要な領域にフラグを立てます。
Query（クエリ）
質問をすると、AIがWikiから答えを合成します。重要なのは、クエリ自体が価値ある新しい統合を生み出した場合、AIはそれをWikiに書き戻すことです。つまり、使えば使うほどWikiが豊かになります。
Lint（リント）
彼が特に言及している操作で、このスキームで最も賢い部分だと思います。AIが定期的にWiki全体のヘルスチェックを行います。
- 矛盾する内容の2つのページはないか？
- 古くなった記述はないか？
- 他のページからリンクされていない孤立ページはないか？
- 明らかに欠落している相互参照はないか？
これらを手動で行うのは面倒で、持続するのはほぼ不可能です。しかしAIにとっては、純粋な雑用です。
役割分担は次の通りです。
人間の担当： キュレーション（何を含める価値があるかの選択）、批判的判断（この結論は正しいか？）、監督（AIの更新を定期的にレビュー）
AIの担当： bookkeeping（簿記）—相互参照、一貫性維持、孤立ノードのクリーンアップ、フォーマット
彼は bookkeeping という言葉を使っています。この言葉は適切です。AIにあなたの代わりに考えさせるのではなく、やるべきだと分かっていながら先延ばしにしているメンテナンス作業をAIに任せることです。
Obsidianユーザーが特に注目すべき理由
最近気づいたことがあります。プログラミングコミュニティの友人の一部で、以前はObsidianに興味がなかった人たちが、次々と使い始めているのです。
理由を聞くと、答えはほぼ同じです。AIと連携するのに非常に適しているから。 ローカルファイル、プレーンマークダウン、ベンダーロックインなし——これらは以前はニッチな好みでしたが、今ではアドバンテージになっています。Claude Codeなどのツールは、追加設定なしでObsidian Vaultを直接読み書きでき、AIができることは直接実行できます。
KarpathyのGistは、ある意味でこれをさらに明確にしています。
私自身も以前からObsidianを使っていますが、このGistを読んで強く感じました。
彼が説明するWikiは、本質的にAIが積極的にメンテナンスするObsidian Vaultです。
考えてみてください。Obsidianの核心は何ですか？ 双方向リンクで結ばれたローカルのMarkdownファイルの集まりです。
LLM Wikiの核心は何ですか？ Markdownファイルの集まりと、リンクの作成・維持、コンテンツの統合、ヘルスチェックを支援するAIです。
基盤となるメディアはまったく同じです。Obsidian Vaultは、LLM Wikiの最も自然な実装の一つです。
現在手動で行っていること——ノートに双方向リンクを作成する、Maps of Content（MOC）を書く、定期的に整理・アーカイブする——これらのかなりの部分は、LLM Wikiの設計における「bookkeeping作業」としてAIが実行できます。
私自身の例を挙げましょう。記事を書き終えた後、双方向リンクを作成・整理するステップは、今ではSkillが担当しています。AIが私のノートVaultをスキャンし、関連記事を見つけて自動的に双方向リンクを追加します。以前はこのステップを毎回先延ばしにしていましたが、今ではほとんど気にしなくなりました。
KarpathyのLLM Wikiはこれをさらに進めます。記事を書いた後に一度実行するだけでなく、知識ベース全体を継続的にメンテナンスされた状態に保ち、Ingest、Query、Lintをすべて自動化します。
もちろん、このアプローチには問題があるという意見もあります。
テックコミュニティでは、Zettelkastenとの比較がなされています。伝統的なZettelkastenは、能動的にノートを書くという行為自体が理解のプロセスであることを強調します——収集するのではなく、書くことでつながりを構築する。AIが要約し関連付けを行ってしまうと、その理解のプロセスが失われるのではないか？ きれいな知識ベースは手に入るが、脳内には何も残らないのではないか？
これは本物の問いであり、標準的な答えはないと思います。
しかしObsidianユーザーにとって、私自身の判断は次の通りです。これら二つは矛盾しません。ただし、「本当に考える必要があるタスク」と「面倒なbookkeeping」を明確に区別するならば。
例えば：
- 記事を読み、核となるアイデアを抽出し、自分の感想や考察を書く → これは思考であり、自分で行うべき
- どのノートが3ヶ月間リンクされていないかを確認する → これはbookkeepingであり、AIに任せるのは完全に合理的
- ある概念の下で複数のソースを統合する → AIにドラフトさせ、自分がレビューする
- 多数のノートのfrontmatterフィールドをメンテナンスする → これは純粋な雑用であり、AIが行う
本当のリスクは、AIを使うことで考えなくなることではなく、「AIにこの記事を要約してもらうこと」と「この記事を読んだこと」を同一視することです。
この区別ができれば、LLM WikiのアプローチはObsidianユーザーにとって実際にかなり価値のある拡張です。
次のステップ
KarpathyのGistは現在、「良いパターンを提案しているが、すぐに使えるツールは提供していない」段階です。
コミュニティの数人が、このアイデアをさまざまな方向で実装し始めていますが、まだ非常に初期段階です。
私は自分のセットアップを本格的にアップグレードするつもりです。まずObsidianノートVaultをLLM Wikiのアプローチに従って再編成し、次に既存の双方向リンクSkillをさらに拡張し、IngestとLintのロジックを追加して、より完全なSkillにしようと考えています。
Claude Code + Obsidian Vaultを使って、最初から最後までプロセス全体を実行します——何が機能し、何が落とし穴で、何を再設計する必要があるかを確認します。うまくいけば、全体をパッケージ化して共有し、他の人がゼロから構築しなくても直接使えるようにします。
次の章では、この実践的なプロセスを扱います。
まとめ
今日学んだこと：
- Karpathyはスタンフォード大学出身の深層学習研究者であり、TeslaのAutopilotにおける純粋ビジョンアプローチのリーダー、OpenAIの共同創業者であり、現在はAI教育に注力している。
- LLM Wikiは「AIが能動的に知識ベースをメンテナンスする」パターンであり、RAGのような受動的検索とは対照的。
- コアアーキテクチャは3層：Raw Sources → Wiki（Markdownファイルの集合） → Schema（構造定義）。
- 3つの操作：Ingest（取り込み・更新） / Query（クエリと書き戻し） / Lint（ヘルスチェック）。
- コアの役割分担：人間はキュレーションと判断、AIは「bookkeeping」——相互参照、一貫性維持、孤立ノードのクリーンアップ。
重要なポイント：
- Obsidian Vaultはそれ自体がMarkdownファイルの集合であり、LLM Wikiのメディアと高度に一致し、最も自然な実装の一つである。
- 現在手動で作成している双方向リンクやMOCは、まさにLLM WikiでAIが自動維持する相互参照である。
- 「AIが代わりに考える」ことへの懸念は合理的だが、それはAIに「bookkeeping」を任せることとは別問題——混同してはいけない。
- このパターンには現在、すぐに使えるツールはなく、自分で構築する必要がある。
- 次の章では実践的な実装を解説し、うまくいけばSkillとしてパッケージ化して共有する。