はじめに：Karpathy の Gist との出会い

先週、Karpathy が執筆した 1 つの Gist を読みました。原文はこちら。

そこで彼が論じていたのは、生のドキュメントとユーザーの間に LLM が自動メンテナンスする Wiki 中間層を配置するという方向性です。

コアの考え方はこうです。ナレッジは一度きりの検索によって生まれるものではない。新しいドキュメントが読み込まれるたびに、LLM が自動的に要約を書き、既存のページを更新し、新旧の記述之间的矛盾発見し、ページ間のリンクを維持する――ナレッジは累積されていくのです。

RAG と Wiki：両者の本質的な違い

原文では RAG と Wiki のアプローチが明確に対比されており、私には非常に腹落ちする説明でした。

RAG は、クエリが発生するたびに生のドキュメントから断片を探し、答えを組み合わせます。検索が終わればそれで終わり――何も残りません。新しいドキュメントが来たらインデックスに追加するだけで、過去の検索結果には関与しません。

一方、Wiki のアプローチはナレッジを継続的に存在させます。新しいコンテンツが入ってきた後、既存のページを更新し、ナレッジ自身が成長していくのです。

Karpathy はこれを 3層アーキテクチャ として定義しています：

• 生のソース（読み取り専用）
• Wiki 層（LLM が自身の読み書きを行う）
• スキーマ（LLM に Wiki の管理方法を指示する）

そして重要な操作として Lint があります。定期的に Wiki をスキャンし、矛盾はないか、古いページはないか、お互いにリンクされていない孤立ページはないかを確認する作業です。Karpathy が言うには、LLM はメンテナンスを面倒だとは思わない――一度に十几个のファイルを修正でき、リンクの更新を忘れることもありません。

これを読んで、自分の開発ワークフローに適用できないだろうか――と考え始めました。

Obsidian との組み合わせ

私は日常的に Obsidian をノートツールとして使っています。しかし Obsidian には課題があります。ページの整理もリンクの作成も、すべて手動でやらなければならない点です。

Karpathy の案は LLM がこれらの作業を自動化するというもの。そこで思いついたのが、Obsidian は表示と閲覧を担当し、LLM は生成とメンテナンスを担当するという分担です。両者は代替関係ではなく、補完関係になります。

ディレクトリ構造

実際に手を動かす前に、まずディレクトリ構造を設計しました。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

my-wiki/
├── 0_Source_Documents/              ← 入れた資料、読み取り専用、変更しない
├── 1_Session_Fragments/              ← セッションから抽出した生記録、日付でサブディレクトリ
│   └── 2026-04-19/
│       └── ses_xxx_トピック.md
├── 2_Knowledge_Graph/              ← 抽出・精錬後の永続ナレッジ、カテゴリでサブディレクトリ
│   ├── 01_Knowledge_Management/
│   │   └── 0001_LLM-Wikiアーキテクチャ.md
│   ├── 02_Workflows/
│   │   └── 0010_プロジェクト計画審査フロー.md
│   ├── 03_Architecture_Dev/
│   │   └── 0022_依存性注入規範.md
│   └── 04_Ops_Environment/
│       └── 0041_ブログSFTPデプロイ方案.md
├── index.md                  ← エントリーインデックス、カテゴリ別に全ページを一覧
├── log.md                    ← ワークフロー実行ログ、追記のみで変更しない
└── AGENTS.md               ← ルールファイル。人間とLLMが共に育てる

各ディレクトリの役割は明確に分かれています。

0_Source_Documents は読み取り専用層です。プロジェクトドキュメント、技術記事、参考資料を問わず、放り込んだら LLM は読むだけで変更しません。

1_Session_Fragments は生記録のアーカイブ層です。LLM とのセッションの中で、保存価値のある技術議論、ハマったポイント、アーキテクチャの意思決定を抽出して保存します。日付でサブディレクトリに分けることで、1 つのディレクトリにファイルが溢れるのを防ぎます。命名規則は session_id + セッションテーマ。後からセッション ID で遡れるようにするためです。

2_Knowledge_Graph がコア層です。フラグメントは生の記録であり、Knowledge_Graphは精錬されたナレッジです。各ページには番号、要約、詳細内容、そして Wikilink による相互リンクがあります。Knowledge_Graphはテーマ別に 4 つのサブディレクトリに分類されます：01_Knowledge_Management（Wiki アーキテクチャ、システム設定）、02_Workflows（計画審査、実行フレームワーク）、03_Architecture_Dev（マイクロサービス、開発規範、ツールチェーン）、04_Ops_Environment（デプロイ、環境設定）。Wikilink は必ずフルパスで参照します。例えば [[2_Knowledge_Graph/03_Architecture_Dev/0022_依存性注入規範]] のように。

index.md はエントリーポイントです。ベクトル検索は使いません。単純な Markdown テーブルに、カテゴリ別に全知識ページを列挙し、各ページに一行要約とタグを添えるだけです。調べものをするときはまずインデックスをざっと見て、それから具体的なページに飛ぶ。中規模（数十〜数百ページ）なら非常に効果的です。

log.md は追記のみの操作ログ。ワークフローを実行するたびに、どのページに影響したか、何が追加されたか、どんな発見があったかを記録します。

AGENTS.md がルールファイルです。My-Wiki がどう動くか、ファイルフォーマットの要求、増分更新戦略を LLM に伝えます。このファイルは一度決めたら終わりではありません。実践の中でルールが足りない部分に気づいたら都度修正し、修正したことは log に記しておきます。

3 つのワークフロー

ディレクトリ構造が決まった後、3 つの Skill を作成して完全なワークフローを構築しました。

my-wiki-src（生のドキュメント摂取）：0_Source_Documents/ にユーザーが置いた資料を読み込んで、ナレッジを 2_Knowledge_Graph/ に抽出します。1 篇のドキュメントを読むと、既存の十余りの知識ページに影響を与えることもあります――更新、補足、新しい Wiki リンクの構築。

my-wiki-talk（セッションからのナレッジ抽出）：これが一番よく使っています。セッション API を使って歴史的なセッションを読み込み、価値のある対話内容をナレッジフラグメントとして抽出し、知識库に統合します。具体的なフローは：セッション読み込み → フラグメントファイル生成 → ナレッジページ抽出 → Wikilink 双方向リンク構築 → インデックス更新 → ログ追記。

my-wiki-think（セルフチェック）：定期的に実行します。すべての知識ページをスキャンし、矛盾する記述、孤立ページ、見落としのリンク、AGENTS.md の基準に従っていない箇所を検出します。さらに「何度も言及されているのに独立したページになっていない」コンセプトも発見し、新ページの作成を提案します。

この 3 つのワークフローは、Karpathy が提言する 3 つのコア操作に相当しています：Ingest（摂取）、Query（照会 → ここでは talk で代替）、Lint（健康診断）。

初回実行

Skill を書いた後、初めて /my-wiki-talk を実行しました。今年 1 月から 4 月までの歴史的セッションを全スキャンします。

15 セッションを読み込み、15 のフラグメントファイルを生成、8 つの初期知識ページを抽出しました。

この 8 ページは当時のコアトピックをカバーしていました：LLM-Wiki アーキテクチャ自身、システム設定規範、企業級ナレッジベースの構築経験、計画審査フロー、E2E テストの概念、思考言語の設定、運用ツールの選定。

その後も何度か実行を重ね、異なるテーマのセッションから継続的に抽出していきました。異なるプロジェクトの移行戦略、サービスの引越しでハマったポイント、CI/CD ビルドの修正、依存性インジェクションの型マッチングルール、マイクロサービスの階層アーキテクチャ設計――すべてがシステマティックに知識图谱へ蓄積されていきました。

実行のたびに出力をチェックしています。フラグメントファイルの YAML ヘッダーは正しいか、知識ページの要約は正確か、Wikilink に存在しないページを指していないか――これらを確認します。完全な放置状態ではなく、やはり人間の目が必要です。

知識ページは 8 から 43 へと増えていきました。

実践の方法論

一通り実践してみて、いくつかの方法論にたどり着きました。新しい理論ではありせん。自分で一度走り抜けて、覚えておいてよかったと思うことです。

ナレッジは「抽出」するものではなく「累積」するもの

これが最も本質的な転換です。以前の習慣は、問題に当たって調べ、解決したら忘れる。次に同じ問題に遭遇したら、また最初から探し直す。

今は違います。ハマったポイントが再利用価値を確認できたら、知識ページとして抽出して保存します。そして重複を恐れません。同じコンセプトが異なるプロジェクトのセッションで複数回登場しても、毎回違う角度、違うコンテキストからのアプローチです。セッションフラグメントは生記録を保持し、知識图谱は共通項を抽出します。

例えばある技術ポイントの処理がいくつものプロジェクトのセッションで登場しました。1 回目は基本設定ルール、2 回目は特殊シナリオでの落とし穴、3 回目は型不一致のエラー修正。これら 3 つのフラグメントはそれぞれでアーカイブし、知識图谱では完全な使用規範として統合し、出典を明記します。次にもう類似の問題に直面しても、何百ものセッション記録を漁る必要はありません。対応するページを直接見ればいいのです。

層別隔離で連鎖反応を防ぐ

0_Source_Documents は触らない、1_Session_Fragments は日付アーカイブで変更しない、2_Knowledge_Graph は自由に増改できる。この層別は実践の中で非常に役立ちました。

• 生のドキュメント は読み取り専用層。何を放り込んでも、LLM は読むだけ。これで生資料の完全性が保証され、LLM が「手伝っているのか邪魔しているのか」という曖昧な境界線もなくなります。LLM は読むだけで、生のドキュメントの最適化には関与しません。
• セッションフラグメント はアーカイブ層。日付でサブディレクトリに分け、各ファイルは session_id にテーマを加えて命名します。session_id はユニークなので競合しません。日単位ディレクトリの利点は、1 つのディレクトリに何百ものファイルが溜まらず、Obsidian で開いても重くならない点です。これらのフラグメントファイルは git のコミットログようなもので、生記録として簡単には変更しません。
• 知識图谱 は読み書き層。ここで LLM が CRUD を行います。あるコンセプトの説明を一括で更新したければ、知識图谱のページを修正するだけで、フラグメントファイルを漁る必要はありません。インデックスと知識图谱の番号は 1 対 1 で対応し、ファイル名を変更した場合は index.md を同期更新するだけ。
• ルールファイル（AGENTS.md） も独立してメンテナンスします。実践の中でプロセスにステップ不足やフォーマット合意の不鮮明さに気づいたら、直接 AGENTS.md を修正する。ルールが変われば、次回のワークフロー実行で LLM が新しいルールに従います。修正後は log.md に記録しておき、後から「いつ、なぜ変えたか」を追跡可能にします。

セルフチェックは必須項目

当初、知識图谱が完成したらメンテナンス不要でずっと使えると思っていました。実際はそうではありませんでした。

知識ページが長く多くなるにつれ、リンク関係も複雑になっていきます。インデックスにだけ存在して他の知識ページから一度も参照されていない孤立ページ、複数のページで繰り返し言及されているのに独立したページがないコンセプト、ファイル名が変わって切れてしまった Wikilink――これらは自然に発生します。

そこで、ナレッジをまとめて追加するたびに /my-wiki-think を実行します。全ページをスキャンし、問題箇所を教えてくれます。問題を確認した後、どう処理するかを決められる――重複の統合、見落としのページ作成、切れかけたリンクの修正。

これはコードレビューに似ています。コードを書く時に問題ないと思っていても、リンターを回したら変数名のスペルミス、未使用の import、2 つの関数のロジックが競合しているなどが見つかった。知識图谱も同じで、チェックしない限り問題は蓄積されていくのです。

人間の役割は「編集者」ではなく「アーキテクト」

LLM がやれること：読み込み、生成、リンク、修正、ナンバリング、インデックス更新。

LLM がやれないこと：どのナレッジを蓄積する価値があると判断するか、どの重複を統合するか、どのコンセプトを独立したページにするか、コンフリクトに遭遇したらどちらを優先するか。

LLM が実行し、私が決める。

この分担は Karpathy が提起するものとも完全に一致します。このシステムにおける人間の役割は軽くなったのではなく、**「ドキュメントを書く人」から「ドキュメントを管理する人」**へ移行したのです――ソースの選別、分析の誘導、良い問いを立てる、そしてこのナレッジが何を意味するかを考える。残りは機械的な作業、LLM に任せればいい。

Obsidian のポジショニング

私はずっとローカルのノートに Obsidian を使っています。My-Wiki 構築後、Obsidian の役割は閲覧と編集のインターフェースになりました。

知識图谱のページは純粋な Markdown ファイルなので、Obsidian で直接開けます。Wikilink も [[ページタイトル]] フォーマットで、Obsidian が正常に認識してジャンプしてくれます。Obsidian のグラフビューを開けば、すべての知識ページ間のリンク関係が可視化されます。どのページがコアで、どれがエッジか、一目瞭然です。

Obsidian がプレゼンテーション、検索、手動編集を担当。LLM が生成とメンテナンスを担当。両者は代替ではなく、補完の関係にあります。

データ同期

知識图谱はすべて純粋な Markdown ファイルなので、バージョン管理と同期に天然に適しています。私は ZeroTier でネットワークを組み、Syncthing で異なるデバイス間で my-wiki ディレクトリ全体をリアルタイム同期しています。会社の PC、自宅の Mac、ノート PC。どこからでも最新の知識ページにアクセスでき、データが 1 台のマシンにしか存在しないという心配もありません。

現在の状態

現在、知識图谱はモジュールごとにグループ分け・番号付けされています：ナレッジベースとシステム、計画とワークフロー、マイクロサービスとアーキテクチャ、開発とツールチェーン、運用と環境。各ページに要約、タグ、出典トレースがあります。

Obsidian で my-wiki ディレクトリ全体を開けば、完全な関係グラフが表示されます。どのページがどこを参照しているか、どのコンセプトがどのプロジェクトで使われているか、どのセッションフラグメントから抽出されたか――すべてが一目でわかります。