【LLM Wiki】Obsidian x Claude Codeで学んだ知識を構造化し記憶媒体を脳からAIに移行する

はじめに

こんにちは！「PayPayで！」バーコードリーダーを画面に直接押し当ててくるのは止めてください。たろう眼鏡です。
クラシル社でサーバサイドの開発をしています。

前回の記事ではKarpathy氏のautoresearchを紹介して、バックエンドのパフォーマンスチューニングに転用しました。今回もKarpathy氏です。もう完全にファンクラブです。

2026年4月、Karpathy氏が LLM Wiki というGistを公開しました。ざっくり言うと、RAGのように毎回ドキュメントを検索して回答を生成するのではなく、LLMに永続的なWikiを書かせて知識を蓄積&整理&育成していくというアプローチです。Obsidianと組み合わせると、LLMによりWikiが整理された状態で閲覧&グラフで可視化できるので相性がいいです。

RAGとの違い、Claude Codeへの実装、自分で追加した設計判断の3つを書きます。

LLM Wikiとは何か

RAGが苦手なこと

RAGは、LLMに外部ドキュメントの知識を使わせる手法で優れた方法です。ドキュメントをベクトルDBに格納しておき、質問が来たら関連するチャンクを検索して、LLMのプロンプトに注入して回答を生成する。

5つのドキュメントを横断する質問をしたとき、LLMは関連する断片を見つけて、合成して、回答する。同じ質問を明日もう一度しても、まったく同じ検索と合成をゼロからやり直します。
前回の回答は消えていて、知識としては残っていないので、知識の蓄積という観点で別のアプローチがあります。

知識をコンパイルするという発想

LLM Wikiは構造が違います。

ソースドキュメントを読んで、得た知識を永続的なWikiとして書き出す。新しいソースが追加されるたびに、既存のWikiページを更新し、相互参照を張り、新しいソースと既存のWikiに矛盾があれば修正する。知識は一度「コンパイル」されたら蓄積されていく。

ここでの「コンパイル」は、バラバラのソースから情報を読み取って、整理・統合・相互参照された構造に変換するという意味です。ソースコードを機械語に変換するのと同じで、生のドキュメントをLLMが扱いやすい形に一度加工しておく。加工済みなので、queryのたびに生ドキュメントに戻る必要がない。

RAGが「毎回ゼロから検索→合成」なのに対して、LLM Wikiは「検索→合成→コンパイル→新たな知識の蓄積」です。

ある知識から別の知識への参照がなかったが、会話の中で別の知識が必要だった場合、LLMはその会話を元に新しい相互参照を形成します。つまり、Wikiは静的なドキュメントの集合ではなく、LLMが動的に更新していく生きたナレッジベースになります。
また、既存のWikiに間違いがあれば、LLMは新しいソースを取り込む際にそれを指摘して修正することもできます。これにより、Wikiの品質が時間とともに進化し続けます。

3層アーキテクチャ

LLM Wikiは3つのレイヤーで構成されます。

Raw Sources（ソース） — ユーザーが集めた生のドキュメントです。主にObsidian Web Clipperで生成します。LLMはこれを読むが、絶対に更新しません。よってハルシネーションのリスクがない、信頼できる知識の源泉になります。

Wiki — LLMが生成・管理するマークダウンファイルです。要約ページ、概念ページ、エンティティページ、比較ページなど。ソースを情報源にLLMが全て書いて、全て定期的にメンテナンスします。AIが理解しやすい文章に書き換えられている状態です。

Schema（スキーマ） — Wikiの構造と規約を定義する地図のようなドキュメントです。これによりAIが会話に必要な知識に効率的にアクセスできます。

4つの操作

LLM Wikiには4つの基本操作があります。

ingest（取り込み） — メイン操作。新しいソースをLLMに読ませて、Wikiに統合する。ソースを読む→要約ページを作る→既存のWikiページを更新→相互参照を張る→index/logを更新、という流れです。1つのソースが10〜15のWikiページに影響するのは普通で、むしろそうなるべきです。

query（質問） — Wikiに対して質問する。LLMがindexを読んで関連ページを探し、内容を読み込んで回答を合成する。参照先が生のドキュメントではなくすでに構造化されたWikiページなので、回答の質が良いです。更に良い回答はWikiに書き戻して残します。

lint（健全性チェック） — Wikiの品質を定期的に点検する。ページ間の矛盾、孤立ページ（どこからもリンクされていない）、頻繁に言及されるのに独立ページがない概念、などを検出します。

index + log — indexはWikiのカタログ、logは操作の時系列記録。LLMはまずindexを読んでWikiの全体像を把握し、そこからページをたどる。logは「Wikiにどんな更新があったか」を正しく把握するための記録です。

各自カスタマイズする必要がある

Karpathy氏自身がGistの中でこう書いています。

This document is intentionally abstract. It describes the idea, not a specific implementation.

ディレクトリ構造もページフォーマットもツールも、ドメインと好みに応じてカスタマイズしろ、というスタンスです。「概念だけ伝えるから、あとは自分のLLMエージェントに読ませて一緒に作ってくれ」と。

なので、たろう眼鏡の解釈でClaude Codeのスキルに落とし込みました。次の章から詳しく説明します。

Claude Codeのスキルに落とし込む

Karpathy氏のGistをそのまま /skill-creator に投げます。
頭を使ってやることはほぼこれぐらいです。

/skill-creator はClaude Codeのスキル（SKILL.md）を対話的に設計・生成するスキルです。概念文書を読ませると、ユーザーとのQ&Aを通じて具体的なSKILL.mdを生成してくれます。

skill-creatorにいくつか質問されました。

ユースケース: 技術リサーチがメイン。MySQL、Railsなどジャンルごとにフォルダを分けたい。
閲覧ツール: Obsidianを使う。 [[wikilinks]] 形式とYAMLフロントマターを使う。
配置場所: ~/Documents/Obsidian Vault/llm-wiki/
言語: すべて日本語
ソースの場所: ~/Documents/Obsidian Vault/raw/Clippings/ （Obsidian Web Clipperで取り込んだもの）

SKILL.md

問答を元に、SKILL.mdが生成されました。引数パースのルール、ディレクトリ構造、ページフォーマット、4つの操作（init/ingest/query/lint）の手順、運用ガイドラインまで一式入っています。

できあがったスキルは以下のような構成になっています。

SKILL.md（クリックで展開）

name: llm-wiki description: LLMが永続的なナレッジベース（Wiki）を構築・維持するスキル。ソースドキュメントを取り込んでWikiページを生成・更新し、相互参照を維持する。「ナレッジベース」「Wiki」「取り込み」「ingest」「ソースを読んで」「Wikiに追加」「Wikiを検索」「ナレッジを整理」「lint」「健全性チェック」など、知識の蓄積・整理・検索に関する依頼で必ず使用すること。技術リサーチの文献管理、読書ノート、学習ログなどにも適用される。 argument-hint: “[ingest <パス> | query <質問> | lint | init <ジャンル>]“

LLM Wiki — 永続ナレッジベース構築スキル

LLMがソースドキュメントを読み込み、構造化されたWikiを段階的に構築・維持する。RAGのようにクエリのたびにゼロから知識を再発見するのではなく、知識を一度コンパイルし、ソースが増えるたびに蓄積していく。

ソース: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

引数のパース

$ARGUMENTS を以下のルールでパースする：

入力パターン	操作	例
`ingest`	デフォルトソースから未取り込みを検出して取り込み	`ingest`
`ingest <パス>`	指定ファイルを取り込み	`ingest ~/path/to/記事.md`
`ingest <ディレクトリ>`	ディレクトリ内の全ソースを取り込み	`ingest ~/path/to/dir/`
`query <質問>`	Wikiに対して質問	`query インデックスの設計原則は？`
`lint`	Wiki全体の健全性チェック	`lint`
`init <ジャンル>`	新しいジャンルフォルダを初期化	`init rails`
引数なし / 自由文	内容から操作を判断	`Clippingsの新しい記事取り込んで`

デフォルトソースディレクトリ: ~/Documents/Obsidian Vault/raw/Clippings/
ingest がパスなしで呼ばれた場合、このディレクトリ（サブフォルダ含む）を走査し、既存のソース要約ページと照合して未取り込みのファイルを検出する。未取り込みがあればリストを提示してユーザーに確認する。

パスにジャンル指定が含まれる場合（例: ingest ~/path/to/file.md rdb ）、末尾のジャンル名を取り出す。含まれない場合はソースの内容から自動判定するか、ユーザーに確認する。

コンセプト

ソース（raw）: ユーザーが収集した不変のドキュメント群。記事、論文、Web Clipなど
Wiki: LLMが生成・管理するマークダウンファイル群。要約、エンティティページ、コンセプトページ、比較など
スキーマ: Wikiの構造と規約を定義するこのドキュメント自体

ユーザーはソースの収集と問いを担当する。LLMは要約、相互参照、整理、メンテナンスのすべてを担当する。

ディレクトリ構造

~/Documents/Obsidian Vault/llm-wiki/ # Obsidian Vaultとして開く
├── index.md                        # 全体カタログ（ジャンル一覧と概要のみ）
├── wiki/
│   ├── rdb/                        # ジャンルフォルダ
│   │   ├── index.md                # ジャンル内の全ページカタログ
│   │   ├── log.md                  # ジャンル内の操作ログ
│   │   ├── _overview.md            # ジャンルの概要・知識構造マップ
│   │   ├── SELECT最適化.md
│   │   ├── WHERE句最適化.md
│   │   ├── インデックス戦略.md
│   │   └── 定数畳み込み.md         # 細かい概念は独立ページに
│   ├── rails/
│   │   ├── index.md
│   │   ├── log.md
│   │   ├── _overview.md
│   │   └── ...
│   └── general/                    # ジャンルをまたぐ横断的な知識
│       └── ...
└── sources/                        # ソースの要約・メタデータ（原本は別の場所）
    ├── rdb/
    │   └── mysql-8-select-optimization.md
    └── rails/
        └── ...

2層のindex/log構造:

全体 index.md: ジャンル一覧、各ジャンルのページ数・ソース数、ジャンルindex.mdへのリンクのみ。個別ページは載せない
ジャンル wiki/<genre>/index.md: そのジャンル内の全ページとソースの詳細カタログ
ジャンル wiki/<genre>/log.md: そのジャンル内の操作ログ。全体のlog.mdは不要（ジャンル別で管理する）

ジャンルフォルダ: ユーザーの指示やソースの内容に応じて作成する。最初から全部作らず、ソースを取り込む際に必要になったら新規作成する。

ソースの原本: ユーザーが指定した任意の場所にある（例: ~/Documents/Obsidian Vault/raw/Clippings/ ）。原本は絶対に変更しない。 sources/ ディレクトリにはソースのメタデータと要約のみを保存する。

ページフォーマット

すべてのWikiページは以下のフロントマターを持つ：

---
title: "ページタイトル"
genre: rdb          # ジャンル
type: concept       # concept | entity | source-summary | comparison | synthesis
sources:            # このページが参照するソース
  - "[[mysql-8-select-optimization]]"
related:            # 関連ページ
  - "[[WHERE句最適化]]"
  - "[[インデックス戦略]]"
created: 2026-04-11
updated: 2026-04-11
---

typeの種類：

concept: 概念や技術トピック（例：「インデックス戦略」「N+1問題」）
entity: 具体的な技術・ツール・プロダクト（例：「MySQL 8.0」「ActiveRecord」）
source-summary: ソースドキュメントの要約
comparison: 複数のものを比較分析したページ
synthesis: 複数のソースや概念を統合した総合考察

Obsidian記法

内部リンクは [[ページ名]] 形式を使う（相対パスではなくページ名のみ）
セクション内リンクは [[ページ名#セクション名|セクション名]]
タグは frontmatter の中に書く（インラインの #tag は使わない）
ページ名は日本語でOK。ファイル名とページ名を一致させる

操作

1. init — Wiki の初期化

ユーザーが初めてこのスキルを使うとき、または新しいジャンルを追加するとき：

~/Documents/Obsidian Vault/llm-wiki/ が存在しなければ作成する
index.md と log.md が存在しなければ初期テンプレートで作成する
必要なジャンルフォルダを wiki/ と sources/ の下に作成する
ジャンルの _overview.md を作成する（中身は後でingestを通じて充実させる）

初回のみ、Obsidianで ~/Documents/Obsidian Vault/llm-wiki をVaultとして開くよう案内する：

Obsidianを開いて「Open folder as vault」で ~/Documents/Obsidian Vault/llm-wiki を選択してください。

2. ingest — ソースの取り込み

これがメイン操作。ユーザーがソースのパスを指定するか、ディレクトリを指定して複数まとめて取り込む。

手順：

ソースを読む: 指定されたファイルを Read で読み込む。ソースの場所はユーザーが指定する任意のパスを受け付ける
ジャンルを判定: ソースの内容からジャンルを判定する。不明な場合はユーザーに確認する
既存Wikiの状態を把握: index.md を読んで、今あるページと構造を確認する。これにより新しいソースをどこに接続すべきかが分かる
要点を抽出しユーザーと議論: 主要なポイントをまとめ、ユーザーに提示する。ユーザーが何を重視するか、どう整理したいかを聞く。ユーザーが「おまかせ」なら自分の判断で進む
ソース要約ページを作成: sources/<genre>/ に要約ページを作成。元ソースへのパスを記録する
Wikiページを作成・更新: ソースから抽出した知識を既存のWikiに統合する（詳細は下記「ページの作成・更新の判断基準」参照）
index.md を更新: 新しいページ・更新されたページをカタログに反映
log.md に記録: 操作をログに追記
ソース原本をジャンル別フォルダに整理: ソースがClippings直下など未整理の場所にある場合、 Clippings/<genre>/ にサブフォルダを作成して移動する。これによりソースが増えてもジャンル別に整理された状態を維持できる。移動後、ソース要約ページの原本パスも更新する

ingestで大事なこと：

1つのソースが複数のWikiページに影響するのは正常。むしろ積極的に既存ページとの接点を見つけて更新する
相互参照（ [[wikilink]] ）を豊富に張る。これがWikiの価値の源泉
既存の知識と新しい知識をただ並べるのではなく、統合する。「Aという記述があったが、今回のソースではBと述べている」のように関係性を明示する

ページの作成・更新の判断基準

ingest時に最も重要な判断は「新しいページを作るか、既存ページを更新するか」。以下の基準で判断する：

新規ページを作成するとき：

そのコンセプトがまだWikiに独立ページとして存在しない
既存ページの1セクションに収まらないほどの情報量がある
複数のページから参照されそうな概念（例：「定数畳み込み」がWHERE句最適化とRange最適化の両方から参照される）

既存ページを更新するとき：

新しいソースが既存ページのトピックに直接関連する追加情報を含む
既存の記述を補強・修正・矛盾指摘する情報がある
新しい相互参照を追加できる

ページを分割するとき：

既存ページの1セクションが肥大化して独立したトピックとして成立する場合
分割元のページには要約を残し、 [[新ページ]] で詳細へリンクする

ソースを統合するページ（横断ページ）：

複数のソースにまたがる知識を1つのページにまとめる。例えば「インデックス戦略」ページが SELECT最適化、WHERE句最適化、Range最適化の3ソースすべてから得たインデックス関連の知識を統合する
これがWikiの真価。単なるソースの要約ではなく、知識の再構成

3. query — Wikiへの質問

ユーザーがWikiに対して質問するとき：

index.md を読む: 関連しそうなページを特定する
関連ページを読む: 見つけたページを読み込む。ページ内の [[wikilink]] をたどって追加で関連ページも読む（必要に応じて2-3ホップ先まで）
回答を合成する: 読み込んだページの内容を統合して回答する。回答にはソースページへの [[wikilink]] を含める。Wikiに書かれていない推測は明示的に区別する
（任意）回答をWikiに保存: ユーザーに「この回答をWikiに保存しますか？」と聞く。以下の判断基準で提案する：

保存すべきケース：

Wikiにまだない新しい切り口や視点を含む回答（例：複数概念を独自に比較した分析）
新しいコンセプトを導入している（既存ページにない概念が登場した）
繰り返し参照される可能性が高い汎用的な分析

保存不要なケース：

既存ページの知識を組み合わせただけで、新しい知識を追加していない
特定のクエリやコードなど、個別具体的すぎて再利用性が低い
既存ページに追記すれば済む程度の内容

4. lint — Wiki の健全性チェック

定期的にWikiの品質を点検する。 wiki/ 配下の全ページを走査し、以下をチェックする：

矛盾の検出: ページ間で矛盾する記述がないか
孤立ページ: 他のどのページからもリンクされていないページ
不足ページ: 頻繁に言及されるがまだ独立ページがないコンセプト（ [[存在しないページ]] へのリンクを探す）
古い情報: 新しいソースで上書きされた可能性のある記述
相互参照の不足: つながるべきなのにリンクされていないページ
次に調べるべきこと: Wikiのギャップから、追加で調査すべきトピックを提案

結果はカテゴリ別の表形式で報告する。修正はユーザーの許可を得てから実施する。

全体 index.md のフォーマット

ジャンル一覧と統計のみ。個別ページは載せない。

# LLM Wiki Index

最終更新: 2026-04-12

## ジャンル

| ジャンル | ページ数 | ソース数 | 詳細 |
|---|---|---|---|
| RDB | 10 | 4 | [[wiki/rdb/index]] |
| Rails | 3 | 2 | [[wiki/rails/index]] |

## 統計
- 総ページ数: 13
- 総ソース数: 6
- ジャンル数: 2

ジャンル index.md のフォーマット（wiki//index.md）

そのジャンル内の全ページとソースの詳細カタログ。

# RDB Index

最終更新: 2026-04-12

## ページ一覧
- [[SELECT最適化]] — SELECT文の最適化の全体像（ソース: 3）
- [[WHERE句最適化]] — WHERE句のオプティマイザ最適化（ソース: 1）
- [[インデックス戦略]] — インデックス設計の原則（ソース: 3）
- [[定数畳み込み]] — 定数と比較される式の自動伝播（ソース: 1）

## ソース一覧
- [[mysql-8-select-optimization]] — MySQL 8.0 Reference Manual 10.2.1
- [[mysql-8-where-clause-optimization]] — MySQL 8.0 Reference Manual 10.2.1.1

## 統計
- ページ数: 10
- ソース数: 4

ジャンル log.md のフォーマット（wiki//log.md）

# RDB Log

## [2026-04-11] ingest | MySQL 8.0 SELECT Optimization
- ソース: ~/Documents/Obsidian Vault/raw/Clippings/rdb/MySQL...10.2.1...md
- 作成: [[SELECT最適化]], [[WHERE句最適化]]
- 更新: [[インデックス戦略]]（相互参照を追加）

## [2026-04-11] lint
- 孤立ページ: 0
- 矛盾検出: 1（[[SELECT最適化]]と[[WHERE句最適化]]の定数畳み込みの説明）
- 修正済み: はい

## [ で始まる行はgrepで一覧できる: grep "^## \[" wiki/rdb/log.md | tail -10

運用ガイドライン

すべて日本語で書く 。ページタイトル、本文、コメントすべて日本語
原本は絶対に変更しない 。raw ソースは不変
1回のingestでジャンルのindex.mdとlog.md、全体のindex.mdを更新する 。忘れない
相互参照を惜しまない 。リンクはWikiの命。ページ本文の中で関連する概念が出てきたら [[ページ名]] を積極的に使う
既存ページとの統合を常に意識する 。孤立した情報は価値が低い。新しいソースを取り込むときは、まず既存ページとの接点を探す
ジャンルフォルダは必要に応じて増やす 。最初から全部作らない
ユーザーとの対話を大事にする 。特にingest時、要点を提示して方向性を確認する
知識は分解して再構成する 。ソースの構造をそのまま写すのではなく、概念ごとに分けて独立ページにし、相互にリンクする。1ソース = 1ページではなく、1コンセプト = 1ページが原則

YAMLフロントマター

各WikiページにはYAMLフロントマターがあり、 title 、 genre 、 type （concept/entity/source-summary/comparison/synthesis）、 sources 、 related が入ります。ページ間は [[wikilinks]] でリンクされ、グラフビューで全体の知識構造が可視化されるようにします。

運用のサイクル

実際の運用は以下のような流れです。

Webで気になる技術記事を見つける → ブラウザで記事を開く
Obsidian Web Clipperで保存 → ワンクリックでマークダウンに変換され、 Clippings/ に保存される
Claude Codeで /llm-wiki ingest → 保存したソースをWikiに取り込む。LLMがソースを読み、要約・概念ページの作成・相互参照の追加を行う
ObsidianでWikiを閲覧 → 更新されたページをリアルタイムで確認できる。グラフビューで知識の全体像を把握することも可能。
知りたいことがあれば /llm-wiki query → Wiki内の知識を統合して回答が返ってくる。質の良い回答で得た知識はWikiに蓄積させる
定期的に /llm-wiki lint → Wikiの健全性をチェックして、矛盾や孤立ページを見つけて改修する

Obsidian と Obsidian Web Clipper

Obsidian はマークダウンファイルをローカルで管理・閲覧するナレッジベースアプリです。ファイル間のリンク（ [[wikilinks]] ）をグラフで可視化できるのが特徴で、Wikiのページ間の関係が一目でわかります。データはすべてローカルのマークダウンファイルなので、LLMとの相性が非常に良いです。
グラフビューでは、ページ同士のリンクが線で結ばれて表示されます。これにより、ある概念がどれだけ他の概念と関連しているか、どのページが中心的な役割を果たしているかが視覚的に把握できます。また、孤立したページもすぐに見つけることができます。

Obsidianのグラフビュー

Obsidian Web Clipper はObsidian公式のブラウザ拡張で、Webページをマークダウン形式に変換して保存できます。YAMLフロントマター（タイトル、URL、保存日時など）が自動で付与されるので、そのままingestのソースとして使えます。これがかなり便利で、気になる技術記事を見つけたらカジュアルにObsidianに保存して、LLM Wikiに取り込むというサイクルがスムーズに回ります。

お試しでクエリしてみた

今回たろう眼鏡はローカルでMySQLのWikiを作りました。試しにこのWikiがどんなアウトプットを出すかをクエリしてみました。
質問は「SQLアンチパターンとMySQL最適化の知識をクロスして、“このアンチパターンを踏むとオプティマイザのこの最適化が効かなくなる”という対応表を作って」というものです。

↓がその結果です。短時間で沢山の知識を統合して、非常に有用な表を作ってくれました。どのファイルをクエリしたかはログを読めばすぐにわかるようになっています。

/llm-wiki queryでクエリを指示。どのページを読んだかはログに出力される

短時間で質の良いグラフを出してきた

自分なりのアレンジ

上述のスキルは既にブラッシュアップ済みですが、/skill-creatorが初期に生成したSKILL.mdは完璧ではありませんでした。
実際にingestを回してみると、ソースを変換しただけでは足りない部分が出てきました。「新規ページにするのか？既存ページに追記するのか？」「indexが肥大化してきたけどどうする？」といった、実運用に必要な判断基準が足りていませんでした。
そこでたろう眼鏡が追加した設計判断を3つ紹介します。

1. 2層index/log構造

最初のアウトプットではindexは1ファイルで、logも1ファイルでした。Wiki全体のページを1つのindexに全部載せる構成でした。

ジャンルが2〜3個、ページが20件くらいのうちは全然良いのですが、100件とかを超えてくるとqueryのたびにLLMが巨大なindexを全部読むことになり、コンテキストウィンドウの肥大化が心配になりました。そこでindexとlogを2層構造にしました。

全体index.md — ジャンル一覧と統計のみ。個別ページは載せない
ジャンルindex（ wiki/<genre>/index.md ） — そのジャンル内の全ページの詳細カタログ
ジャンルlog（ wiki/<genre>/log.md ） — そのジャンル内の操作ログ

LLMはまず全体indexでジャンルを特定し、そこからジャンルindexに飛んで個別ページを探す。2段階のナビゲーションになりますが、読み込むトークン量は大幅に減ります。全体のlog.mdは不要にしました。ジャンル別で管理すれば十分です。

2. ページの作成・更新・分割の判断基準

ingestで最も重要な判断は「新しいページを作るか、既存ページを更新するか」です。Karpathy氏のGistにはこの基準は特にありません。

LLMに暗黙の判断を任せると、セッションによって挙動がブレます。あるときは1ソースから10ページ作り、別のときは3ページしか作らないなど。
なのでSKILL.mdに明文化した判断基準を組み込みました。

新規ページを作るとき:

そのコンセプトがまだWikiに独立ページとして存在しない
既存ページの1セクションに収まらないほどの情報量がある
複数のページから参照されそうな概念

既存ページを更新するとき:

新しいソースが既存ページのトピックに直接関連する追加情報を含む
既存の記述を補強・修正・矛盾指摘する情報がある

ページを分割するとき:

既存ページの1セクションが肥大化して、独立したトピックとして成立する場合
分割元には要約を残して [[新ページ]] でリンクする

横断ページ（これがWikiの真価）:

複数のソースにまたがる知識を1つのページにまとめる。例えば「インデックス戦略」ページがSELECT最適化、WHERE句最適化、Range最適化の3ソースすべてから得たインデックス関連の知識を統合する

3. query結果をWikiに保存する/しないの判断基準

Karpathy氏は「良い回答はWikiに保存できる」と書いています。とはいえ、何が「良い回答」なのかの基準は示されていません。

基準がないと、「全部保存」か「全部保存しない」のどちらかに偏ります。全部保存するとWikiが肥大化して質が下がるし、全部保存しないとqueryを通じて得た新たな知識が消えてもったいないです。

SKILL.mdに以下の判断基準を追加しました。

保存すべきケース:

Wikiにまだない新しい切り口や視点を含む回答（例: 複数概念を独自に比較した分析）
新しいコンセプトを導入している
繰り返し参照される可能性が高い汎用的な分析だと判断できる

保存不要なケース:

既存ページの知識をただ組み合わせただけで、新しい知識を追加していない
特定のクエリやコードなど、個別具体的すぎて再利用性が低い
既存ページに追記すれば済む程度の内容

queryのたびにLLMが「この回答はWikiに保存しますか？」と聞いてくるようにしてあり、上の基準に基づいて提案理由も説明します。最終判断はユーザーが行います。

Wikiに回答のナレッジを蓄積させるか聞いてくる

まとめ

LLM Wikiは知識を一度コンパイルして蓄積しAIが関連ドキュメントを見つけやすくするアプローチです。

Karpathy氏のGistが抽象的なのは意図的で、そのぶんカスタマイズの余地が大きかったです。
今回紹介した3つの設計判断（2層index、ページ判断基準、query保存基準）は自分のユースケースに合わせたもので、別のドメインや別のワークフローなら違う判断になると思いますので、是非オリジナルのSKILL.mdを育成してみてください。

興味がある方は、 Gist をそのままLLMに投げるだけで始められますよ！！

llm-wiki

エクスプローラー