Karpathyの「LLM Wiki」を「自分OS」に昇華させた話

投稿者： Hayate Takeda 公開日： 2026年4月19日 トピック： AI、skill、llm、Claude、Claude Code、tech

はじめに — RAGの限界とWikiという発想

個人の知識管理ツールとしてNotionやObsidianが定番になってきた中で、LLMの登場がアプローチを二段階で進化させている。

項目	RAG	LLM Wiki
知識の扱い	クエリごとに検索して投げ込む	ソース取り込み時にコンパイルして蓄積
統合のタイミング	リアルタイム（毎回）	事前（インクリメンタル）
次のクエリへの引き継ぎ	ない	Wikiとして残る

Andrej Karpathyがこのアイデアの原点で示唆したのは、“「LLMはRAGのように毎回ゼロから考えなくていい。人間の脳みたいに、一度理解したことを整理して蓄積すればいい」“というシンプルながら鋭い着眼点である。

しかし著者が問いたのは、Karpathyの設計が見ていない問題は何か という点だ。

Karpathyの設計を読んで気づいたこと

Karpathyの設計は3層構造になっている：

Raw Sources  ──→  Wiki Pages  ──→  Schema / Index
（記事・論文）    （LLMが管理）     （構造と参照の定義）

ユーザーはソース収集と問い立てに専念し、LLMが要約・統合・メンテナンスをすべて担う役割分担は秀逸だ。

しかし著者は一つの引っかかりを感じた：Karpathyの設計は外向きなのだ。エンティティと概念の関係性を精密に記述するシステムだが、“「いつ・どういう状態で考えたか」の記録が残らないのではないか”という疑問を抱いた。

自分コンテキストを混ぜた途端に、Wikiは「静的な知識ベース」から「時系列を持つ観測ログ」へと変質する。この違いが設計の根幹を変えることになったのだ。

「外向き」から「内向き＋外向き」へ

自分の意思決定と外部知識は切り離せない。「なぜDynamoDBを選んだか」は、DynamoDBの特性（外部知識）だけでなく、当時の自分がどんな制約と価値観を持っていたか（自分コンテキスト）に強く依存する。

そこでWikiを3領域に分けることにした：

領域	何を蓄積するか	方向性
`Knowledge/`	技術・概念・外部情報	外向き（世界を理解する）
`Decisions/`	自分の意思決定ログ	内向き×外向き（判断の記録）
`Self/`	思考・行動の繰り返しパターン	内向き（自分を観測する）

そして3領域が交差する場所に Synthesis/ を置く。このメタパターン層がKarpathyの設計にはない。

3層スキーマ設計

ディレクトリ構造

vault/
├── Raw/                    # 生ソース層 — 不変・LLMはread専用
│   ├── Clippings/          # 記事クリップ
│   ├── Dialogue/           # 壁打ちログ
│   └── Daily/              # デイリーノート
│
├── Sources/                # 整形ソース層 — Rawを構造化・read専用
│   ├── Knowledge/
│   ├── Decisions/
│   └── Self/
│
└── Wiki/                   # 知識統合層 — LLM完全管理・自己増殖する
    ├── Knowledge/
    │   ├── rdb/
    │   │   ├── _index.md
    │   │   ├── _log.md
    │   │   ├── _overview.md
    │   │   └── SELECT最適化.md
    │   └── aws/
    │       └── dynamodb/
    ├── Decisions/          # アーカイブ原則（書き換え禁止）
    │   ├── _index.md
    │   └── _patterns.md
    ├── Self/
    │   ├── profile.md
    │   ├── Patterns/
    │   └── Timeline/
    └── Synthesis/          # 3領域の交差点（Karpathyにはない層）

各ジャンルが _index.md / _log.md / _overview.md の3点セットを持つことがポイントだ。LLMが次のセッションで呼ばれたとき、この3ファイルを読むだけで「今Wikiがどういう状態か」を把握できる。

ジャンルは2階層まで入れ子にでき、フロントマターの genre フィールドはスラッシュ区切りで表現する。

genre: aws/dynamodb

Sources/ ディレクトリも Wiki/ と同じ入れ子構造をミラーする。

レイヤー別の自動化レベル設計

どこまでLLMに自律実行させて、どこで人間を挟むかという判断軸が最も悩ましい：

操作	Knowledge	Decision	Self
新規ページ作成	✅ 自動	⚠️ 確認後	⚠️ 提案のみ
既存ページへの追記	✅ 自動	⚠️ 確認後	⚠️ 提案のみ
既存ページの書き換え	⚠️ diff表示→承認	❌ 禁止	⚠️ 提案のみ
矛盾の指摘	⚠️ 必ず上げる	⚠️ 必ず上げる	⚠️ 必ず上げる
パターン抽出	—	—	⚠️ 提案のみ

矛盾指摘とパターン抽出は必ず人間を挟む。ここを自動化するとLLMが勝手に「あなたはこういう人」を固定化してしまい、Wikiが自己成就的予言になってしまうのだ。

Self フロー — 「自己成就的予言」の罠を避ける

Self/ 領域の設計には特に慎重さが必要だ。行動パターンを抽出する機能は、使い方を間違えると “「LLMのフレームに自分を当てはめる」バイアス” を生む危険性がある。

デイリー記録はハイブリッドにしている：

朝: 2分だけ自由記述（フレームなし）
    ↓ LLMが裏で構造化してSelf/Daily/に格納
    ↓ 必要に応じて「昨日の気づきと繋がりそうだけど、どう？」と投げる

夜: 構造化質問（朝の自由記述を踏まえた上で）

自由記述で観測の生データを取り、構造化質問で解釈と接続をする。この非対称性が効く。

パターンページのフロントマター例：

---
title: "0→1集中型"
type: pattern
first_observed: 2024-06-01
last_observed: 2026-04-10
observation_count: 12
confidence: medium          # low | medium | high
status: active
evidence:
  - "2026-07_転職先選定"
  - "2025-12_ISMS推進着手"
---

confidence は観測回数と文脈の強さで判定される。10回以上かつ異なる状況で一貫して出現したものだけが high になる。自分についての確信はゆっくり育てるべきで、LLMに急かされてはいけない。

アーカイブ原則 — Wikiに「化石層」を作る

Karpathyが書いていないが超重要なことがある。それはWikiの寿命だ。

Wikiは育つが同時に古くなる。過去の自分の意思決定と現在の意思決定は異なる文脈から出てくる。Wikiが「常に最新」を保とうとすると、過去の自分を上書きしてしまう。

だから Decisions/ にはアーカイブ原則を適用する：

意思決定ログは書き換えない
新しい判断が出たら新しいページを作り、superseded_by で連鎖させる
date フィールドは決断日で固定し、更新しない

決断ページのフロントマター例：

---
title: "2026-07 転職先選定"
type: decision
date: 2026-04-11
status: active
superseded_by: null
context_snapshot: "SES2年目、SA志向が固まった時期"
options_considered:
  - "フリーランス"
decision: "Sierへの転職決断"
---

これだけで、Wikiが**「思考の化石」と「現在の地図」の両方**として機能する。過去の判断を「間違いだった」と上書きするのは簡単だが、「あの時点の自分はこの情報でこう考えた」という記録が残っていることの方が、長期的には価値が高い。

スキルとしての実装 — ingestフロー

Claude Codeのスキルとして実装するときのフロー：

ingest 開始
  │
  ├─ [STEP 1] ソースを読む
  ├─ [STEP 2] ジャンルを判定（不明なら確認）
  ├─ [STEP 3] 既存Wikiの状態を把握（_index.md読み込み）
  ├─ [STEP 3.5] 影響範囲アセスメント（内部処理）
  │
  └─ [STEP 4] レイヤー判定で分岐
        ├─ Knowledge → 自動処理
        ├─ Decision  → 確認を挟む
        └─ Self      → 提案・承認待ち
              │
  ├─ [STEP 5] Sources/に要約ページ作成
  ├─ [STEP 6] Wiki/にページ作成・更新
  ├─ [STEP 7] _index.mdを更新
  └─ [STEP 8] _log.mdに記録

STEP 3.5 の影響範囲アセスメントがポイントだ。これはユーザーには見せない内部処理で、「このソースで何が変わるか」を事前に整理してから提示する。

ログのフォーマット例：

## 2026-04-19 09:30
 
- **操作**: ingest
- **ソース**: `mysql-8-select-optimization.md`
- **作成ページ**: `[[SELECT最適化]]`, `[[カバリングインデックス]]`
- **更新ページ**: `[[インデックス戦略]]`（追記）
- **備考**: インデックス戦略ページと部分的に矛盾あり。ユーザーに確認済み

Phase 1で作るべき最小セット

最初から完璧なシステムを作ろうとしない。最初の1週間で動かすべき最小構成：

SKILL.md（ingest / query / morning / evening の4コマンドのみ）
schema/knowledge-template.md
schema/decision-template.md
Wiki/<genre>/_index.md（手書きで最初の数ページ分だけ埋める）
Wiki/<genre>/_log.md（空でOK、LLMが追記する）

あえて含めないもの：

Synthesis/（Phase 2以降。データが溜まってから）
lintや整合性チェック（最初は人間が目視でいい）
Patterns抽出（3週間分くらい溜まってから）

システムの価値はデータが溜まって初めて出る。最初の設計に凝りすぎると、肝心のデータが溜まる前に飽きる。

まとめ

Karpathyの設計から学んで、自分なりに拡張した結論：

LLM Wikiの本質は「コンパイル」 — RAGと違い、知識は事前に統合される
自分コンテキストを注入する — 「外向き」だけでなく「内向き+外向き」が必要
自動化レベルを領域で変える — Knowledge は積極的に、Self は慎重に
パターン抽出は人間を挟む — 自己成就的予言を避けるため
アーカイブ原則でWikiに化石層を作る — 思考の進化を記録する

これを実装してから、自分のNotionとLLMの使い方が変わった。「情報を貯める」から「思考を育てる」へのシフトが実現した。

llm-wiki

エクスプローラー

Karpathyの「LLM Wiki」を「自分OS」に昇華させた話

Karpathyの「LLM Wiki」を「自分OS」に昇華させた話

はじめに — RAGの限界とWikiという発想

Karpathyの設計を読んで気づいたこと

「外向き」から「内向き＋外向き」へ

3層スキーマ設計

ディレクトリ構造

レイヤー別の自動化レベル設計

Self フロー — 「自己成就的予言」の罠を避ける

アーカイブ原則 — Wikiに「化石層」を作る

スキルとしての実装 — ingestフロー

Phase 1で作るべき最小セット

まとめ

グラフビュー

目次