llmwiki レビュー：生ソースを引用可能な wiki にコンパイルする CLI
The knowledge compiler. Raw sources in, interlinked wiki out. Inspired by Karpathy's LLM Wiki pattern.
ひと目でわかる
- これは何？
- llmwiki は Karpathy の LLM Wiki パターンを TypeScript で実装した知識コンパイラだ。二段階の LLM パイプラインでソースから概念を抽出し、型付きページを生成する。採用判断の鍵は、ライフサイクルプロファイルという fail-closed な契約を運用に耐えられるかどうかにある。
- 誰に向いている？
- 採用を検討すべきなのは、論文や議事録など変化の遅いソースから、引用元を追跡できる知識ページを継続的に作りたいチームだ。逆に、高速に更新されるログへの ad-hoc 検索が目的なら llmwiki は道具が違う。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 5 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
llmwiki が解こうとしている問題は検索ではなく蓄積
RAG 的な発想では、質問のたびに生ファイルを検索し、その場で知識を再構成する。llmwiki はこの順序を逆にする。README は Karpathy の LLM Wiki パターンの説明として「クエリ時に生ファイルから知識を再発見する代わりに、一度コンパイルして耐久性のあるページに蓄積する」と述べている。つまり対象は、何度も参照される知識であり、毎秒変わるログではない。
想定読者は README の「When to use this repo」に列挙されている。論文、ノート、README、文字起こし、PDF、画像、Web ページを型付きの wiki ページにコンパイルしたい人。エージェントに散らばったファイルの山ではなく、引用を辿れる安定したコンテキストパックを渡したい人。生成された知識を、出典引用、レビューキュー、鮮度チェック、品質ゲートで監査可能に保ちたい人だ。逆に README は、汎用静的サイトジェネレータとして、重量級のオントロジーデータベースとして、あるいは高速に変化する生ログへの ad-hoc 検索の代替として使うことを明示的に否定している。この線引きはかなり率直で、道具の限界を先に言ってしまう姿勢は好ましい。
二段階コンパイルと型付きページという設計
中核の仕組みは二段階の LLM パイプラインである。README によれば、第一段階で概念を抽出し、第二段階で型付きページを生成する。ページ種別は `concept`、`entity`、`comparison`、`overview` の 4 つが既定で用意されている。チャンクをベクトル化して終わりではなく、ページという単位に構造を与える点が RAG との実装上の分岐点だ。
出力は引用可能な markdown で、段落や主張がソースファイルと行範囲を引用する。`llmwiki lint` がそのリンクを検証する。検索側は単純なベクトル一本ではなく、セマンティックなチャンク検索、BM25 による再ランキング、wikilink グラフの展開を組み合わせて、クエリやエージェント向けのコンパクトな証拠パックを組み立てる。ハイブリッド構成を採っているのは、埋め込みだけでは固有名詞や略語の一致に弱いという前提があるのだろう。
閲覧は `llmwiki view` でローカルの読み取り専用 UI が開き、検索、ページメタデータ、グラフ探索、ソース鮮度バッジ、引用チップが確認できる。生成物を人間が読む経路と、エージェントが読む経路の両方を同じ成果物から取れるのが、この設計の実利である。
CLP はプロンプト規約ではなくランタイムの契約
1.0 の中心は Configurable Lifecycle Profiles（CLP）だ。`.llmwiki/profile.json` という検証済みのファイル 1 枚が、型付きエンティティとフィールド、有向関係、ライフサイクル状態、遷移に必要な証拠、複数段のワークフローと宣言されたアクション、ハッシュで固定された artifact、サードパーティ製コネクタのバインディング、コンテンツ階層、検索ポリシーを定義する。
ここで重要なのは README が繰り返し述べている点で、これらの規則は「プロンプトの慣習ではなくランタイムによって強制される」。無効なプロファイルと、宣言されたゲートを迂回する書き込みは fail closed で失敗する。関係、証拠、artifact、人間またはエージェントのゲートが書き込み経路で検査され、事後のドリフトは常設の lint が検出する。
CLI、SDK、MCP サーバー、ビューア、コンテキストビルダー、lint、status、export、OKF 交換がすべて同じプロファイル契約から動く。プロファイルが破れば全表面が一貫して止まるという意味でもある。後方互換は構造的に確保されていて、`.llmwiki/profile.json` がなければ組み込みの既定プロファイルが使われ、1.0 以前の挙動が保たれる。既存プロジェクトを壊さずに段階移行できるのは、この手のツールでは珍しく実務的な配慮だ。
導入コマンドとテンプレートの選び方
プロファイルを自分で書く場合、README はエンティティ型を 1 つずつ足していく進め方を示している。`llmwiki profile init research --entity paper` で research プロファイルの雛形を作り、`llmwiki profile validate` で検証する。ワークフローの一覧は `llmwiki workflow list` で確認できる。
既成の構成を借りるならテンプレートを使う。`llmwiki template list` で一覧、`llmwiki template inspect autosci` で中身を確認、`llmwiki template init autosci` で展開する。`autosci` は論文、アイデア、実験、原稿、証拠 artifact、ワークフロー、Crossref 取り込みを備えた研究向けの構成で、`newsroom` は同じ汎用機構を記事、デスク、署名、編集ワークフローに当てた構成だと説明されている。両者は意図的に方向性が違うため、自分の用途がどちらに近いかを `inspect` で確かめてから選ぶのが順当だ。
テンプレートは設定と例だけを含み、実行可能なプラグインコードは含まないと明記されている。配布経路も用意され、発行者は `llmwiki template publish` で Ed25519 署名付きのオフライン配布物を作れる。署名付きテンプレートは信頼済み tap から導入する。ここは供給網の観点で押さえておく価値がある。
エージェント連携と可搬フォーマット
`llmwiki serve` は MCP サーバーを立て、ingest、compile、query、lint、read、status、eval、context-pack、OKF 交換といったツールを MCP 対応エージェントに公開する。シェルを経由せず TypeScript から扱いたい場合は SDK の `createWiki({ root })` が ingest、compile、query、context、status、export、eval、OKF の import/export を担う。エージェントに知識ベースを触らせる経路が CLI と MCP と SDK の 3 つあるのは、既存のワークフローに合わせやすい。
持ち出し形式は幅がある。Open Knowledge Format（OKF）のバンドルで markdown ネイティブな知識交換ができ、外部から取り込んだ OKF は既定でレビューキューを経由する。信頼できるバンドルに限り、明示的にライブ書き込みできる。ほかに JSON、JSON-LD、GraphML、Marp スライド、`llms.txt` を出力できる。
プロバイダは Anthropic、Claude Agent SDK のローカルログイン、OpenAI Codex CLI のローカルログイン、OpenAI 互換サーバー、Ollama、GitHub Copilot、Atlas Cloud、OrcaRouter、ローカルの OpenAI 互換ランタイムに対応する。特定ベンダーに閉じない設計だが、対応先の一覧は README の記載であり、各プロバイダでの実際の挙動差は当該資料からは判断できない。
向かない場面と、運用上の本当のコスト
README 自身が否定する用途は先に見た通りで、汎用静的サイトジェネレータ、重量級オントロジーデータベース、高速に変化する生ログへの ad-hoc 検索の代替にはならない。加えて構造から読み取れる制約がある。知識を「コンパイルし、レビューし、再利用する価値がある」ときに最も強く、と README が書いている以上、ソースが数時間で陳腐化する領域では、`llmwiki refresh --stale` で修復を回しても追いつかない可能性が高い。
もう一つの現実的なコストはプロファイル設計そのものだ。CLP は fail closed なので、宣言したゲートを満たさない書き込みは失敗する。これは監査性の裏返しで、エンティティ型、関係、遷移要件を自分で決められないまま autosci や newsroom を借りると、ドメインに合わない契約に書き込みが弾かれる。テンプレートはあくまで出発点であり、契約の設計は利用者側に残る。
保守面では、既定プロファイルを使う限り 1.0 以前との後方互換が保たれると README は述べている。ライセンスは MIT で、fork や社内改変の余地は大きい。ただし MIT が保証するのは利用の自由であって、生成物の正確性や、同梱テンプレートの内容の正しさではない。法務判断はここでは扱わない。
比較対象としての Obsidian と静的サイトジェネレータ
同じ markdown wiki を作る道具として Obsidian が挙げられる。違いは生成の主体だ。Obsidian は人間がリンクを張って育てるのに対し、llmwiki は二段階の LLM パイプラインが概念抽出とページ生成を行い、引用と行範囲を出力に埋め込む。人間の役割は執筆からレビューへ移る。README が `obsidian` をトピックに含めているのは、出力が markdown と wikilink であるためで、既存の vault に持ち込む経路を意識していると読める。
静的サイトジェネレータとの差はもっと明確だ。サイトジェネレータは与えられた markdown を HTML に変換するだけで、知識を抽出しない。llmwiki は抽出、型付け、関係の付与、レビュー状態の管理までを担う。逆に言えば、単に markdown を公開したいだけなら llmwiki は過剰で、`llmwiki view` の読み取り専用 UI 以上の表示制御は期待できない。
検索基盤との比較も同じ構図になる。ベクトル検索はクエリのたびに知識を再構成する。llmwiki はコンパイル済みのページを蓄積し、その上でセマンティック検索、BM25、グラフ展開を組み合わせる。蓄積された構造に価値があるかどうかが、採用の分かれ目である。
採用前に確かめるべき 3 つの具体的な点
第一に、自分のドメインで `.llmwiki/profile.json` を書けるか。最小構成は `llmwiki profile init research --entity paper` から始め、`llmwiki profile validate` が通ること、`llmwiki workflow list` に意図した遷移が出ることを確認する。ここが組めないなら CLP の利点は得られない。
第二に、引用の精度を `llmwiki eval` で測れるか。README によれば eval はヘルススコア、最悪ページを示すページ別ヘルス分布、wikilink グラフの健全性、引用カバレッジと精度、コーパス統計、回帰デルタ、任意の judge モデルによる引用支援を報告する。数値の水準は資料からは分からないので、自前のコーパスで一度回して基準を作る必要がある。
第三に、エージェントに渡す経路をどれにするか。`llmwiki serve` の MCP か、SDK の `createWiki({ root })` か、CLI かで運用の形が変わる。外部から OKF を取り込む予定があるなら、既定でレビューキューを経由する挙動と、信頼バンドルをライブ書き込みする明示操作のどちらを標準にするかを先に決めておきたい。この 3 点が自分の用途で埋まらないうちは、llmwiki の採用は早い。
編集部の結論
採用を検討すべきなのは、論文や議事録など変化の遅いソースから、引用元を追跡できる知識ページを継続的に作りたいチームだ。逆に、高速に更新されるログへの ad-hoc 検索が目的なら llmwiki は道具が違う。導入前に確認すべきは一点、`.llmwiki/profile.json` を自分で書けるかどうかである。CLP はランタイムで強制される契約であり、ここを設計できないと autosci や newsroom テンプレートを借りても自分のドメインには落ちない。まず `llmwiki profile init research --entity paper` で最小のプロファイルを作り、`llmwiki profile validate` が通る状態を一度手で組んでから本採用を決めればよい。MIT ライセンスなので fork して自社用プロファイルを保守する道も残る。
コミュニティノート