RL RanceLee Tutorials
← Tutorialsへ戻る

KarpathyスタイルのWikiを再利用可能なスキルに変える

このスキルを動かすのに、ここ数日本当に苦労した。

最初はOpus 4.6で試した。20ドル以上費やした。それでも動かなかった。2026年4月8日の朝にリリースされた新しいモデルが、すべての計算リソースを吸い取ってしまったのではないかとさえ疑った。そうでなければ、なぜ一瞬理解したかと思えば、次の瞬間には脱線するのか。

その後、Codexに切り替えて、なんとか構築できた。

しかし、新たな問題が浮上した。構築できたからといって、それが確実に動くわけではない。

特に本格的にテストし始めると、時々指示を無視して勝手に変更を加えることがあり、それが本当に腹立たしかった。

だからこの記事では、「スキルを作ったので自由にダウンロードしてください」と言いたいだけではない。

もう一つ明確にしたいことがある。Karpathyが提案したLLM Wikiメソッドを、Obsidian vaultで実際に実装する方法だ。

前の章ではメソッドを説明した。この章は実践編だ。

現在の、機密情報を除去したバージョンのスキルをダウンロードしたい場合は、以下のリンクからどうぞ：

https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/

APIキーやローカルパスなどは既に削除してある。ただし、先に言っておく。そのまま丸写しにしないでほしい。

このメソッドから学ぶことはできる。このスキルを修正することもできる。しかし、そのまま動くとは期待しないでほしい。各自のノートvaultはあまりにも異なるからだ。

作ったのは「AIがノートを整理する」ではなく、「AIが簿記をする」もの

まず、KarpathyのGistを振り返ろう。

元のリンク：

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

核となるアイデアは実にシンプルだ。

現在、ほとんどの人はLLMを文書処理に使う際、RAGを利用している。ファイルを大量に放り込み、クエリのたびに検索して回答をその場で生成する。

それでももちろん機能する。

しかし問題は、それがすべてアドホックであることだ。

一度質問すれば、一度組み立てる。もう一度質問すれば、またゼロから始める。蓄積がない。

そこで彼が提案したのは中間層だ。クエリごとにその場で回答を組み立てるのではなく、Wikiを継続的にメンテナンスする。

これを読んだとき、最初の反応は「すごい」ではなかった。

むしろ、これこそObsidianが最も得意とするタスクではないか？ と思った。

なぜならObsidianは、そもそもローカルのMarkdownファイルvaultだからだ。

Karpathyが説明するWikiは、基本的にMarkdownファイルの集まりだ。

基盤となるフォーマットはほぼ同じ。

違いは以下の点にある：

  • 以前は、手動でバックリンク、トピックページ、構造ページをメンテナンスしていた
  • 今はAIがこの「簿記」作業を手伝ってくれる

注意：簿記であって、思考ではない。

この考えにますます同意するようになった。

記事を読み、判断し、自分の意見を書く——これらは依然として自分がやるべきことだ。

しかし、バックリンクの補完、著者名の統一、フォーマットのチェック、派生ページの更新といった作業は、本質的に雑用だ。AIに任せられる。

Karpathyの3層構造をObsidianでどう実装したか

Karpathyのメソッドで最も重要なのは、次の3つの層だ：

  • Raw Sources（生ソース）
  • The Wiki（Wiki）
  • The Schema（スキーマ）

私のobsidian-wikiスキルも、この3層を中心に構築されている。

第一層：Raw Sources

私のvaultでは、この層は以下で構成される：

  • 01-Notes/
  • 04-Output/

つまり、生のコレクション、生のノート、そして自分が書いた記事だ。

この層は非常に抑制的に保っている。

その唯一の責務は、元のコンテンツを保存することだ。

余計な機能を持たせない。

派生コンテンツを混ぜない。

生の記事が、トピックページとインデックスページのハイブリッドにならないようにする。

なぜなら、混ざってしまうとメンテナンスが難しくなるからだ。

このスキルを構築する過程で学んだ最も深い教訓の一つは、生の層がきれいであればあるほど、他のすべてが簡単になるということだ。

第二層：The Wiki

この層は私のvaultでは分離されている：

01-Notes/wiki/

ここにはAIが派生させた構造層が置かれる。例えば：

  • 著者ページ
  • トピックページ
  • インデックス
  • ログ
  • バックリンクディレクトリ

つまり、原文は原文のまま。

WikiはWiki。

2つの層は分離されている。

これは些細なことに聞こえるが、実は非常に重要だ。

なぜなら、層を分離しないと、AIが整理するたびに原文が乱雑になる傾向があるからだ。

今日はトピックブロックを追加する。

明日はインデックスを挿入する。

明後日は自動生成されたサマリーを追加する。

最終的にvault全体は、常に片付けられているのにどんどん散らかっていく部屋のようになる。

第三層：The Schema

多くの人がこの層を見落としている。

Karpathyは元の投稿でスキーマに言及している。私の理解では、vaultがどうあるべきかをAIに伝える必要があるということだ。

私の場合、これには以下が含まれる：

  • SKILL.md
  • 多数のscripts/
  • frontmatterの規約
  • 著者やトピックの書き方に関する制約
  • lintやingestのプロセス制約

例えば、現在以下のルールを強制している：

  • 著者はバックリンク形式でなければならない
  • トピックはバックリンクリストでなければならない
  • 著者ページとトピックページは01-Notes/wiki/にのみ置く
  • 00-Inbox/は処理用の受信箱であり、Wikiに直接混ぜない
  • 生の記事には派生パラグラフを含めない

わかるだろう。スキルを機能させるのは、プロンプトがどれだけ美しく書かれているかではない。本当の鍵は、これらの制約が先に確立されていることだ。

3つのアクションを実行可能なワークフローに変換する

Karpathyには、さらに3つの核となるアクションがある：

  • Ingest（取り込み）
  • Query（クエリ）
  • Lint（リント）

私も同じアプローチを取った。

このスキルの実際のワークフローでは、次のようになる：

  • Ingest：wiki_lint.py --preflight + ob_shuanglian.py suggest/apply + wiki_ingest.py
  • Query：最初にwiki/index.md、authors/*.md、topics/*.mdを読み、その後必要に応じて原文に戻る
  • Lint：wiki_lint.py、wiki_migrate.py、wiki_build_skeleton.py

Ingest：新しいコンテンツをvaultに追加する前にチェックする

AIに「記事を見て即興で処理させる」ことはしない。

現在のワークフローは、まずプリフライトチェックから始まる。

最初にfrontmatterが正しいか確認する。

次に過去の汚染がないか確認する。

その後、バックリンクの提案を行う。

ユーザーが確認した後、実際に適用する。

最後に、Wikiの派生層をリフレッシュする。

なぜこんなに手間をかけるのか？

なぜなら、モデルに何度も教えられたからだ。

これらのガードレールを追加しないと、AIは熱心に「あなたのために決定」を下そうとする。

問題は、その決定があなたの望むものとは限らないことだ。

そこで、強力な確認ゲートを追加した。

トピックを勝手に書かせない。

バックリンクを直接適用させない。

著者の別名を独断で決めさせない。

提案を出し、私が確認し、それから書き込む。

これは効率が悪いように見えるかもしれない。

しかし、知識ベースにおいては、遅いことよりも、静かに間違ったことを書き込まれることの方がはるかに怖い。

Query：原文の海で漁るのではなく、まずWiki層を読む

クエリに関しては、「vault全体を検索してAIに要約させる」という方法は取っていない。

代わりに、まず以下を通過させる：

  • wiki/index.md
  • authors/*.md
  • topics/*.md

AIにまず構造化された層を見させる。

必要に応じて、特定の記事に戻って詳細を確認する。

利点は明らかだ：

毎回散らばった原文から再構成する必要がない。

代わりに、すでに整理された層から回答する。

これはKarpathyが言う「蓄積」に近い。

Lint：最も重要で、最も過小評価されているステップ

多くの人はLLM Wikiを見るとQueryに注目する。

しかし、実際に取り組めば取り組むほど、Lintこそが真の価値があると感じる。

なぜなら、知識ベースが成長すると、最大の頭痛の種は「答えが得られないこと」ではなく、以下のようなことになるからだ：

  • frontmatterが乱雑
  • 著者名が一貫していない
  • トピックが散らばっている
  • 原文に過去の構造が残っている
  • 派生ページがますます歪んでいく
  • 同じ概念が複数の異なる名前で存在する

これらを手動でメンテナンスしようとすると、気が狂いそうになる。

そして、維持できなくなる。

まさにこれこそがAIの最も得意とするところだ。

あなたに代わって世界を理解することではない。

しかし、vaultをパトロールし、調整し、汚れたデータを見つけ、相互参照を埋めること。

だからこそ、Karpathyの用語は非常に適切なのだ。簿記。

本当の落とし穴はモデルではなく、私の古いノートvaultだった

これこそが、皆さんに最も警告したい点でもある。

多くの人はこのような記事を読むと、反射的にこう思う：

「ああ、スキルをダウンロードしてインストールすれば、AIが知識ベースを管理してくれるんだ。」

そうではない。

このスキルの最大の課題は、プロンプトでもスクリプトでも、モデルでもない。

それは、私が古いノートを大量に持っており、それらのフォーマットが一貫していないことだ。

今、lintを実行すると、以下の規模が目に入る：

  • 記事タイプのRaw Sources：457
  • Rawファイルの総数：833
  • 保留キュー：249
  • バックリンクディレクトリにはすでに471のトピックがある

このボリュームを考えてみてほしい。

これはもはや「いくつかのノートを整理する」というレベルではない。

どちらかというと、長い歴史があり、一貫した基準がない古いシステムを引き継ぐようなものだ。

著者名が完全に記載されている記事もある。

別名が使われている記事もある。

非常に詳細なトピックもある。

非常に散らばっているトピックもある。

古いファイルには、以前の構造の名残がまだ残っているものもある。

そこで、私はますます一つのことを確信するようになった：

LLM Wikiを構築したいなら、最初のステップはAIに任せることではない。最初のステップは、自分のvaultを「任せるに値する」状態にクリーンアップすることだ。

そうしないと、AIが勤勉であればあるほど、混乱を広げてしまう。

では、このスキルは実際に何を追加で行うのか？

Karpathyの元の投稿だけを読むと、非常にエレガントな方法論だと思うだろう。

しかし、実際に構築してみると、埋めるべきエンジニアリングの細部がたくさんあることがわかった。

例えば：

  • frontmatterの標準化
  • 著者別名の正規化
  • トピックのバックリンク形式の強制
  • 生の層と派生層の完全な分離
  • 00-Inbox/を処理用の受信箱として使用
  • 重要なステップでのユーザー確認ゲートの追加
  • lint、migrate、ingestなどのスクリプトによるワークフローの分割

Karpathyがこれらを考えていなかったわけではない。

彼のGistはパターンを説明しているのであって、あなたのvaultに特化した実装を説明しているわけではない。

実際に実装する際には、この層を自分で埋めなければならない。

私の現在のobsidian-wikiスキルは、基本的に次のことを行っている：

抽象的なパターンを、自分のObsidian vault上で動作するワークフローに変換する。

だから、もしダウンロードするなら、学ぶべき最も重要なことは「私のディレクトリ構造をコピーすること」ではない。

理解すべきは、なぜこのように層を分けたのか、なぜここで確認が必要なのか、なぜここでlintを行うのか、なぜここで自動適用を使わないのかということだ。

もし自分でもやりたいなら、まずこれらを修正してほしい

機密情報を除去したバージョンを、私のブログのダウンロードページに置いてある：

https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/

しかし、ダウンロードした後、最初にすべきことは実行することではない。

修正することだ。

少なくとも以下の点を確認してほしい：

  1. あなたのvaultのパスは私のものと同じか？
  2. 01-Notes/、04-Output/、00-Inbox/の構造は同じか？
  3. frontmatterのフィールドは私のものと一致しているか？
  4. 著者名やトピック名はすでにある程度一貫しているか？
  5. 私の「提案→確認→書き込み」というワークフローを維持したいか？
  6. スクリプトがAPIを呼び出す場合、自分のキーに置き換えたか？

公開したバージョンでは、APIキーとローカルパスは既に除去してある。

入手したら、自分の環境に合わせて適応させる必要がある。

そして、やはり推奨する。私の方法をテンプレートとしてではなく、参考として扱ってほしい。

あなたのvaultが主に読書ノートであれば、ルールは私のものと異なるかもしれない。

あなたのvaultが主にプロジェクトノートであれば、トピックの粒度が異なるだろう。

あなたのvaultがまだ「まず収集、後で整理」の段階であれば、最初にQueryに集中するのではなく、LintとIngestをスムーズに動かすことに注力すべきだ。

だから、丸写しにしないでほしい。

アプローチに基づいて修正する方が、より確実だ。

まとめ

この記事を書き終えて、自分の感覚はより明確になった。

Karpathyの提案は、単に「AIが知識ベースを整理してくれる」というアイデアではない。

その真の価値は、知識管理における人間とAIの役割分担を再定義したことにある。

人間は判断を担当する。

AIは簿記を担当する。

これに取り組めば取り組むほど、その言葉を信じるようになる。

今日学んだこと：

  1. KarpathyのLLM Wikiの鍵は、3層構造と3つの操作であり、単一のプロンプトではない
  2. obsidian-wikiのようなスキルの鍵は、「要約できるか」ではなく、Raw Sources、Wiki、Schemaを分離できるかどうかにある
  3. 実践上、LintはQueryよりも重要であることが多い。なぜなら、過去のデータのクリーンアップが作業の大部分を占めるからだ
  4. 古いノートが多く、フォーマットが乱れているほど、他人のスキルを直接コピーすべきではない
  5. スキルのダウンロードは簡単だが、本当の課題はそれを自分の知識ベースに合うように適応させることだ

重要なポイント：

  • AIは簿記に最も適しており、あなたに代わって考えることには適していない
  • 生の層と派生層は分離しなければならない。そうしないと、整理すればするほど知識ベースが乱雑になる
  • ユーザー確認ゲートは余分なステップではなく、AIの暴走を防ぐために必要なガードレールである
  • まずフォーマットを標準化し、それから自動化を語れ。順序を逆にすると後で苦労する
  • このスキルは修正可能だが、そのままコピーすることは推奨しない