SE歴20年・現在4つのプロジェクトでClaude Codeを並行稼働させている筆者が、Andrej KarpathyがXに投げた「LLM Wiki」のアイデアを自分のワークフローに落とし込んだ実録です。2026年4月時点でセットアップから1週間運用した結果をまとめます。

ムラサキ

「前回どうしたっけ」がなくなっただけで、体感の生産性がかなり変わりました。トークン消費ゼロで知識が勝手に溜まる設計の話です。

なぜClaude Codeに「記憶」を持たせたくなったのか

セッションリセット問題が積み上がるコスト

Claude Codeのセッションは終わると記憶がリセットされる。これは設計上の仕様で、悪いことではない。ただ、毎日使う側にとっては地味に効いてくる。

具体的に困る場面を挙げる。「先週このバグをどう直したか」「このライブラリを選んだ理由」「使ったけど廃止したアプローチは何だったか」。プロジェクトが1つならCLAUDE.mdに書いて済む話だが、筆者は現在4つ動かしている。ゲームのマッチングサービス、pSEOサイト群、コンテンツ自動化、動画自動化。それぞれで独立した知識が積み上がる。

プロジェクト単位のCLAUDE.mdだけでは、横断的な知見——たとえば「Claude Codeのトークン消費を抑える実用的なコツ」「Windowsでよく踏む改行コード問題の対処」——が共有されない。同じ試行錯誤を別プロジェクトで繰り返す。これが時間もトークンも食う。

Karpathyが4月に投げたアイデア

この問題意識のタイミングで、Andrej Karpathyが自身のLLM Wikiワークフローを公開した。2026年4月3日のX投稿だ。

要点はシンプルで、LLMに自分専用のWikiを維持させるという発想。生ソースをフォルダに投げ込む、LLMがMarkdownファイル群を整理する、Wikilinksで相互参照させる、これだけ。Karpathy自身の研究Wikiは1トピックで100記事・約40万語まで育っているという。

この投稿をきっかけに、Nick Spisakが実装版をGitHubで公開し、Claude Code×Obsidianで構築する派生パターンが一気に広がった。筆者が今回組んだ仕組みもこの系譜に乗っている。

自分のワークフローに落とし込む条件

ただし、Karpathyの元案をそのまま真似してもうまくいかない。筆者の運用条件は以下のとおり。

• 4プロジェクトをまたいで同じ知識を参照したい
• トークン消費はできるだけゼロに近づけたい（Claude Max 5xプランでも月末は枯れる）
• セッション終了時に手動で何かする運用は続かない
• Windowsネイティブで動くこと

この条件で設計したのが、次の章で説明する「Obsidianに集約・インターフェースはユーザーグローバル・重い処理はサブエージェント」という構造です。

Karpathy式Second Brainの核心思想

“super simple and flat”という原則

Karpathyが強調しているのは、凝った階層構造・タグ・メタデータは不要という点だ。1トピック1ファイル、kebab-caseのファイル名、末尾に関連リンク。これだけ。

これはObsidianユーザーが陥りがちな「整理しすぎて使えなくなる」罠の逆を行く設計思想だと感じる。知識は整理するためじゃなく取り出すために存在する、という考え方。

LLMが書き手、人間が読み手という役割分担

もう1つの重要な転換点は、Wikiを書くのも維持するのもLLM、人間は主に読み手という役割分担だ。従来のZettelkastenやObsidian運用は「人間がメモを書く・LLMが質問に答える」だったが、Karpathyの構想はこれを反転させる。

人間がやることは3つだけ。

1. 生ソースをraw/に放り込む
2. 必要なときにwiki/に問いを投げる
3. 月に1回くらいヘルスチェックの結果を眺める

書く作業・リンクを張る作業・矛盾を見つける作業は全部LLMが担う。これが「自分の知識が勝手に育つ」感覚の正体で、継続運用の閾値を下げる最大の要因だった。

設計の要所｜トークン効率を最優先にした

MCPサーバーを使わなかった理由

普通に実装するとMCPサーバーを立てたくなる。Obsidian用のMCPサーバーもすでに複数公開されている。ただ、筆者は今回あえて使わない選択をした。

理由はトークン効率。MCPは常時スキーマをロードする性質上、たとえ使っていない時間もコンテキストを占有する。普段のコーディングセッションで「今は使わないけど一応接続してある」状態がずっと続くのは、トークン単価の観点で悪手だと判断した。

ナレッジベース1箇所集約＋インターフェースはユーザーグローバル

代わりに採用したのが次の方針だ。

• ナレッジベース本体は1箇所（C:worksecond-brain）に集約する
• Claude Codeへのインターフェース（スラッシュコマンド・サブエージェント）は~/.claude/に置き、全プロジェクトから参照する
• 重い処理はサブエージェントに委譲し、メインコンテキストの肥大化を防ぐ

プロジェクトごとに分散vaultを持たせる案もあったが、却下した。知識が断片化するうえ、同じ内容を複数vaultが重複保持する状況になる。1箇所集約のほうが運用コストも低い。

セッション終了時のLLM呼び出しをゼロにした

設計で一番こだわったのがここ。セッション終了時にLLMを呼ばないこと。

筆者の使い方は1日6セッションくらいを長く使い込むスタイルで、頻繁にセッションを切るわけではない。それでも原則としてセッションEndのたびにLLM呼び出しを挟むのは避けたかった。呼び出し回数が積もれば、Claude Max 5xの制限にじわじわ効いてくる。

採用したのは、トランスクリプトファイルをシェルコマンドでコピーするだけのアプローチ。LLMは呼ばない。深夜に1回だけ、溜まったtranscriptをまとめて結晶化する。こうするとLLM呼び出しを日次1回に圧縮できる。

フォルダ構造と運用パターン

Vaultのレイアウト

実際に組んだ構造は以下のとおり。

C:worksecond-brain

├── CLAUDE.md          ← Vault作業時のみロードされるスキーマ定義

├── raw/               ← 生素材。読み取り専用で扱う

│   └── sessions/      ← transcriptが自動投入される

├── wiki/              ← AIが結晶化した知識

│   ├── INDEX.md       ← 全トピック目次（自動再生成）

│   └── qa/            ← 質疑応答の蓄積

└── outputs/           ← ヘルスレポート等の成果物

ポイントは、raw/とwiki/を明確に分けていること。raw/は生データ置き場で、人間もLLMも直接編集しない。wiki/はLLMが整理した成果物で、人間は基本的に読むだけ。この分離があると、データの信頼性と整形のしやすさが両立する。

スラッシュコマンドの役割分担

Claude Codeのユーザーグローバル設定（~/.claude/commands/）に、4つのスラッシュコマンドを配置した。

この4コマンドに対応するサブエージェント（wiki-compiler、wiki-asker、wiki-health）も同じくユーザーグローバル配置。プロジェクトを切り替えても、どこからでも同じコマンドが使える。

アンビエント蓄積——何もしなくても溜まる仕組み

この設計で一番の肝が、日常作業中は何もしないという運用になっていること。

Claude CodeのSessionEnd hookにtranscriptコピーを1行仕込んでおくと、セッションが終わるたびに自動でraw/sessions/にファイルが積まれる。筆者の環境ではWindowsなので、PowerShellのCopy-Itemを噛ませる構成にした。

LLMは呼ばない、ただのファイルコピー。つまりこのステップのトークン消費はゼロ。SessionEnd hookの仕様はClaude Code公式Hooksガイドにまとまっている。

その後、深夜03:00にClaude Codeのスケジュール機能で/sb-compileを自動実行する。前日までのtranscriptが翌朝にはwiki/に結晶化されている、という運用だ。

運用1週間で見えたメリットと注意点

レビュー指摘の蓄積もナレッジベースに流しておくと、同種バグの再発防止に使える。実バグ6本で比較したレビュー手法の選び方と組み合わせると開発品質が底上げされる。

実際に変わったこと

セットアップから1週間運用してみて、一番変わったのは「前回どうしたっけ」という問いかけがほぼ消えたことだった。/sb-askで聞けば過去の自分の判断が返ってくる。しかも4プロジェクトのどこから作業していても、同じナレッジベースを参照できる。

具体例を挙げると、pSEOサイト群の作業中に「Batch APIで大量生成したときにハマった制限」を聞くと、数日前にマッチングサービスの作業中に記録したメモがちゃんと引き当たる。プロジェクトをまたぐ知識が活きる瞬間だ。

注意点｜初週は結晶化の粒度がブレる

導入直後の1週目はwiki/の粒度がかなりブレた。1トピックが短すぎたり、逆に詰め込みすぎていたり。これはLLMに渡すCLAUDE.md（Vault用スキーマ）の調整で改善する領域で、3〜4日目から安定してきた印象がある。

筆者環境（Windows 11 + Claude Code v2.1系 + Claude Max 5xプラン）での確認値だが、スキーマを微調整するたびに再実行する運用で、4日目以降は手放しでもそれなりの品質になった。

注意点｜raw/のサイズ管理

transcriptは1セッションあたり数百KB〜100MB級まで幅広い。pSEOやYouTube台本生成のような長時間・大量データ系セッションは1ファイルが100MB超になることもある。実際、運用1週間で17件・計1.1GB蓄積した（平均65MB/件、最大126MB）。

対策は2つ。古いraw/ファイルを圧縮アーカイブに回すか、結晶化済みのものは削除するか。wiki/の結晶が残っていればraw/自体は捨てても問題ないという設計思想なので、ここは思い切って削る想定で組んでいる。

よくある質問

まとめ｜自分の知識を「勝手に育つ脳」に変える

Claude Codeに外部記憶を持たせるだけで、4プロジェクトをまたいだ作業の摩擦がかなり減った。要点を3つに整理する。

• セッションリセット問題は設計で解く。hookとスケジュール機能で「何もしない運用」が成立する
• ナレッジベースは1箇所集約、インターフェースはユーザーグローバルに置くと、プロジェクト横断で効く
• LLM呼び出しを挟むのは結晶化と質問応答のタイミングだけ。日常運用のトークン消費はゼロにできる

コピペで動く全実装が欲しい人向け

本記事は設計思想と運用1週間の実体験までで止めている。「自分の環境にコピペで再現したい」「PowerShell hook・スラッシュコマンド・サブエージェントの全コードが欲しい」場合は、以下のnoteに全実装をまとめている。

併せて、Claude Code自体の使いこなしを底上げしたい場合は/powerupの18レッスンを網羅した入門記事が参考になる。

ムラサキ

Obsidianは以前から使っていましたが、LLMを「書き手」に据える発想は新鮮でした。1ヶ月後にwiki/がどう育っているか、またレポートします。