karpathy-llm-wiki は何を解決し、何を意図的に捨てたか
Agent Skills-compatible LLM wiki for Claude Code, Cursor, and Codex. Build a Karpathy-style knowledge base from raw sources, citations, and linting.
ひと目でわかる
- これは何？
- LLM が wiki ページを保守するという Karpathy のアイデアを Agent Skills 形式に梱包した Python 製スキル。ingest、query、lint の3操作と、設計境界として明示された「作らないもの」の一覧を読む。
- 誰に向いている？
- 採用に向くのは、自分で選んだソースを継続的に積み上げ、その上で引用付きの回答が欲しい個人や小規模チームである。大量コーパス横断の検索精度を最優先する用途、ベクトル検索やグラフ検索を前提にした構成、スケジュール実行や自動フックをスキル側に期待する使い方は対象外で、README もそれを設計境界として明記している。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 54 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
RAG の再計算をやめ、ingest 時に知識を確定させる
このスキルが狙うのは、質問のたびに生データを検索し直す運用からの離脱である。README の比較表では、RAG は知識が「生のチャンクと埋め込み」に置かれ、合成がクエリ時に行われるのに対し、LLM wiki は知識が「キュレーションされた markdown ページ」に置かれ、合成が ingest と保守の時点で行われると説明されている。向く用途として挙げられているのは、横断的な検索そのものではなく、要約や相互リンクが積み上がっていく知識である。
対象読者は、日々読む論文やブログ記事を後から引ける形で残したい個人、あるいは小規模チームだ。Karpathy の原文の役割分担を README はこう要約している。LLM が wiki を保守し、人間はソースの選択と良い問いの投げかけに集中する。つまり人間が編集者としてページを書き続ける前提ではなく、素材を選ぶ側に回る前提の道具である。
raw/ は不変、wiki/ は LLM が書き換える
ディレクトリ構成は README に図として載っている。your-project/ の下に raw/ と wiki/ が並ぶ。raw/ は「不変のソース素材」で、topic/ の下に 2026-04-03-source-article.md のような日付付きファイルとして置かれる。wiki/ は LLM が保守する「コンパイル済みの知識ページ」で、topic/concept-name.md のような概念単位のファイル、全体の目次である index.md、追記専用の操作ログ log.md で構成される。
データの流れは一方向ではない。1 つの新しいソースが複数のページを更新し、相互参照を強め、矛盾を記録することがある、と README は述べている。ここが単なるノート整理ツールとの分岐点で、ingest はファイルを 1 枚足す操作ではなく、既存ページ群に対する差分適用として設計されている。log.md が追記専用なのは、この差分適用の履歴を残すためだと読める。
ingest・query・lint の3操作と、何も新しくなければ記録だけする分岐
操作は 3 つに絞られている。ingest はソースを raw/ に取り込み、トリアージしたうえで wiki 記事を作成または更新する。README の表で見落としやすいのは「新しいものが何もなければログに記録するだけ」という分岐が明記されている点だ。すべての取り込みがページを生むわけではない。
query は wiki を検索し、markdown ページへのリンク付きで回答する。回答が引用を持つのは、根拠が生データではなくコンパイル済みページにあるためだ。lint は index の整合性、リンク、wiki の健全性を検査し、自動修正と報告を行う。壊れたリンク、index の欠落エントリ、古くなった相互参照が検査対象として挙げられている。3 操作のうち自動修正まで含むのは lint だけで、ingest と query はエージェントとの対話を通じて起動される。
導入は npx add-skill 1 行、ただし Codex CLI だけ経路が違う
標準の導入コマンドは npx add-skill Astro-Han/karpathy-llm-wiki である。README の互換表では、Claude Code、Cursor、OpenCode がこのコマンドを使う。Codex CLI だけは別経路で、.agents/skills/karpathy-llm-wiki/ へコピーする。表に載っていないツールの場合も、SKILL.md、references/、scripts/ をそのツールのスキルディレクトリへコピーする、とされている。
設定キーや環境変数の類は README には出てこない。プロジェクト固有の設定ファイルを書くのではなく、スキルディレクトリに配置されたファイル群と、raw/ および wiki/ という作業ディレクトリの規約で動く形になっている。したがって導入時の作業は、コマンドを 1 回走らせることと、wiki を置くプロジェクトの場所を決めることの 2 点に集約される。
設計境界という名の、作らないもの一覧
この README で最も情報量が多いのは Design Boundaries の節である。3 か月の運用ログと、LLM Wiki v2、llm-wiki-compiler、OKF、agent-memory 系の文献の調査を経て、意図的に作らなかったものが列挙されている。
ソースのハッシュによる鮮度追跡は不採用。raw/ が不変なので、ハッシュが守るはずの事象が起こり得ないという理由である。行番号付きの永続引用も不採用で、観測された忠実性の誤りはすべて「値がソースに存在しない」種類のもので、ファイル全体への grep で捕まる、と説明されている。数値の信頼度スコアは較正の裏付けがない偽の精度だとして退けられ、根拠の強さは本文の散文で表す方針が示されている。
記事ごとのレビュー日付も不採用である。ドメインがどれだけ速く動くかをコンパイル時に予測できない以上、保守はページ単位のタイマーではなく wiki 全体の lint で駆動すべきだという判断だ。アクセス頻度による減衰も退けられている。よく聞かれることは真であることと同じではない、という一行に集約されている。
ベクトル検索とグラフ検索も現時点では不採用である。キュレーションされた wiki が 5 万から 10 万トークンの範囲では grep と読み込みのほうが信頼できるとしており、検索ツールを足すのは再現率が測定可能な形で劣化してからでよい、という条件付きの判断になっている。型付きの関係オントロジー、OKF 準拠、retract や悪質ソース向けの機構、自動フックとスケジュール実行も同じ節で落とされている。スケジュール実行はツール非依存のスキルではなくエージェント側のハーネスに属する、という線引きである。
RAG と何が違うのか、どこで wiki モデルが負けるのか
比較対象として README が挙げるのは RAG である。違いは検索技術ではなく、合成のタイミングと知識の置き場所にある。RAG はクエリ時に毎回関係を導出し直す。LLM wiki は ingest と保守の時点で合成を済ませ、以後はそのページを引用する。大規模コーパスを広く拾う用途では RAG が向き、要約と相互リンクが積み上がる知識では wiki が向く、という切り分けになっている。
wiki モデルが負ける場面は README の設計境界から逆算できる。5 万から 10 万トークンを超えて再現率が落ちたとき、grep と読み込みという前提が崩れる。生データをそのまま検索させたいだけの用途では、コンパイルという手間が成果に結びつかない。ソースの撤回や誤りの混入が日常的に起きる環境も想定外で、retract 機構は「まだ起きていない」ことを理由に手動対応とされている。つまり、ソースの品質管理が自分の手に負えない規模や速度で崩れる現場には向かない。
MIT ライセンスと、保守コストの実態
ライセンスは MIT で、リポジトリに LICENSE ファイルが置かれている。スキル本体は SKILL.md、references/、scripts/ という構成のファイル群なので、フォークして自分の運用に合わせて書き換えることが想定しやすい。MIT はその種の改変と再配布を許容するが、無保証である。ライセンス条項の解釈はここでは扱わない。
保守コストについて README が示す数字は Usage Stats の節にある。2026 年 4 月から毎日保守されている実運用の知識ベースで、13 のトピックディレクトリに 94 の wiki 記事、99 のソース素材、直近 7 日で 87 件の操作ログ。これは利用者の運用実績であり、スキル自体のベンチマークではない。読み取れるのは、記事数とソース数がほぼ同数であり、1 ソースが 1 記事に対応するとは限らないという構造である。
アップグレード経路は README からは確認できない。リリースは取得されておらず、バージョン番号やマイグレーション手順の記述もない。npx add-skill で入れたスキルをどう更新するかは、この材料だけでは判断できない。wiki 側の markdown は自分のリポジトリに残るので、スキルを入れ替えても知識は手元に残る、という構成だけは構成図から読み取れる。
編集部の結論
採用に向くのは、自分で選んだソースを継続的に積み上げ、その上で引用付きの回答が欲しい個人や小規模チームである。大量コーパス横断の検索精度を最優先する用途、ベクトル検索やグラフ検索を前提にした構成、スケジュール実行や自動フックをスキル側に期待する使い方は対象外で、README もそれを設計境界として明記している。導入前に確認すべきは、自分のエージェントが agentskills.io 標準のスキルディレクトリを読むかどうか、そして wiki/ 配下の markdown を人間が直接編集する運用を許容できるかである。Codex CLI だけは npx add-skill ではなく .agents/skills/karpathy-llm-wiki/ へのコピーが必要で、ここを間違えるとスキルが読み込まれない。
コミュニティノート