Claude Code x Obsidianで、LLM Wiki構築 | セッションを切り替えても会話を続けられる方法

Claude Code を使っていて、「この機能の構造、前に調べたのにまた一から調べさせてる」とか「セッションをまたぐたびに同じ説明をしている」と感じたことはありませんか？

LLM はセッションをまたぐとそれまで教えた情報を持ち越せないので、毎回ゼロから説明し直すことになります。これがトークンの無駄になりますし、地味にストレスです。
私はいつも長々とプロンプトを書き、背景説明を行っていて、それが煩しく感じていました。

これを解決する方法として有名なのが、元OpenAI創業メンバーで現在AnthropicのPre-trainingチーム所属のAndrej Karpathy が公開した LLM wiki です。大変革新的な方法なのですが、使う中で自己増殖の部分など、不都合があると感じた点が出てきたため、自分で記録するタイミングを決める形に一部運用方法を組み替えて使っているので、今回はそのご紹介です。

背景

きっかけは Karpathy's LLM Wiki

karpathy/llm-wiki.md

Karpathy の LLM Wiki の方法は、ざっくりと説明するとObsidian のローカル Vault をコーディングエージェント（Claude Code）が直接読み書きできる知識ベースとして扱い、その内容を参照しながら作業を進める、というやり方をとっています。

LLM が長期記憶を持たないので、セッションを切り替えてもプロジェクト特有の前提知識(コンテキスト)をローカルに置いておくというわけです。さらにそれをObsidianのVault化すれば、検索性がぐっと上がり、コーディングエージェント（Claude Code）が探しやすくなります。中身はただの Markdown なので、エージェントが grep でも全文検索でも自由に扱えますし、人間も普通に読み書きできます。ベンダーロックインもありません。

Karpathy方式で感じた問題点

ただ、Karpathy方式をそのまま真似ると、コーディングエージェント（Claude Code）が作業のたびにノートを自動生成・自動追記して、自己増殖していきます。少し使ってみたのですが、自分の使い方には以下の点で不都合を感じました。

1. セットアップが面倒
自動増殖を安全に回そうとすると、いつ・何を・どこに書くかをエージェントに委ねるための仕組み（フックやルールファイル、命名規約の自動順守、スキル）を整えないといけません。

2. メンテナンスがしづらい
自動で増えたノートには、間違った情報・もう不要になった情報・重複した情報もどんどん混ざっていきました。
なぜ・いつ書いたのかも後から追いづらく、私は内容を見ない状態が続くので、特に間違った情報が存在しうる問題はずっとつきまといます。増えるスピードが速い分、古くなる情報も速く溜まってしまい、これがトークンの無駄遣い、コンテキストの腐敗に繋がっている気がしました。

3. 自分でハンドリングしづらい
自分の頭の中の最新情報と、エージェントが勝手に作ったディレクトリ構造もだんだんズレていきます。どこに何があるか見通せなくなり、自分が管理するナレッジベースという感覚が次第に薄れ、見なくなります。

方針：LLM wiki の制御と管理は自分で行う

そこで、自己増殖はやめて、以下の方針に組み替えました。

• 書くタイミングは自分が決める。Claude Code が勝手に追加するのではなく、恒久的に残す価値があると自分で判断した時だけ、「ai_wiki/ へここまでの作業を記録して」と頼む様にしました。
• ディレクトリ構成は自分が設計する最初は「ai_wiki/ へ記録して」と頼んでみて、出来上がったディレクトリを見ながら、Claude Code と相談して整理しました。
• 確定・退避・削除の見極めも自分が握る。その情報が「まだ動いている」のか「確定した」のか「役目を終えた」のか、プロジェクトの状況から自分で判断して、作業が一区切りついたタイミングで Claude Code に指示を出して整理をする様にしました。

項目	Karpathy	本記事
ノート生成	自動	手動トリガ
整理	AI	人間判断
導入コスト	高	低
腐敗リスク	高	中
保守性	中	高

LLM Wiki作成方法

ここからは具体的な作成方法、育て方をまとめます。

wiki専用ディレクトリをプロジェクトのルートディレクトリに作成

まずは Claude Code の wiki にしたい専用ディレクトリをプロジェクトのルートディレクトリに作りましょう。
この時点ではただフォルダを作るだけで大丈夫です。
私は ai_wiki/ という名前にして、プロジェクトのルートディレクトリに置くルールにしています。
a から始まるとファイルツリーの一番上にきて見つけやすいので、この名前にしました。

フォルダができたらそのフォルダを Obsidian で開きます。
まだ Obsidian を入れていない人は公式からインストールしてください。
インストールしたら Obsidian を起動して、作ったフォルダを「保管庫としてフォルダを開く」のボタンから開くだけで、そのフォルダは自動でセットアップされて、ただの Markdown ファイルが検索性にすぐれた Obsidian の Vault になります。

ai_wiki/ は .gitignore や .gitignore_global、.git/info/exclude に書いておけば、リモートリポジトリに誤って push してしまうこともありません。
私は常に ai_wiki という名前で Claude Code 専用 wiki を運用すると決めているので、プロジェクトごとに .gitignore や .git/info/exclude に書かずにグローバルな .gitignore_global に ai_wiki を書いています。

参考：.gitignoreではなくて、個人的にgit追跡から省きたいファイル、フォルダを設定する方法 | .gitignore_global, .git/info/exclude

ディレクトリ作成

ディレクトリ構成は、自分が使いやすい形を Claude Code と話しながら作っていくのが一番いいと思っています。何かの作業をしているときに、一度以下のような指示を出してフォルダとインデックスを作ってもらいました。

ai_wiki以下をClaude Codeの専用wikiとしたいです。
ここまでの会話をai_wiki以下に記録し、ここにClaude Codeの専用wikiがあるということをプロジェクトのメモリに記録してください。

これを繰り返していくとディレクトリ構成が自然と出来上がっていくので、一旦その状態でディレクトリ構成やインデックスの様子を見て、ファイル数が増えてきたタイミングでディレクトリ構造の整理に着手しました。

LLM wikiの使い方、育て方

実際の依頼は、だいたい以下のどれかのパターンで使っています。

(A) 機能・モデルの情報を恒久保存したいとき

ここまでの調査結果を、ai_wiki以下に記録して、別セッションを開いた時にすぐ会話が開始できるようにしてください

ある機能の実装が一段落して、「この構造は今後も参照しそう」と思ったタイミングで、コーディングエージェント（Claude Code）に概念ノートを作ってもらいます。
このときコーディングエージェント（Claude Code）はコードベースを実際に読みに行って、ファイルパスや呼称を裏取りしたうえでノートにまとめてくれます。記憶や推測ではなくその時点のコードを確認させた上でこの作業をさせておくと、あとでその調査結果をもとに作業させたいときにまた調査からやり直す必要がなくなります。
何か調べたら必ずこれをやっておくと自分で見返すときにも便利ですし、Claude Code のコンテキストウィンドウやトークンの節約にもなります。Obsidian Vault にしているぶん、情報をたどるのも速いです。

(B) セッションを切り替える必要があるとき

作業が長くなって Claude Code のコンテキストが膨らみ、どうしても新しいセッションに切り替えたい、という場面に、この方法を使います。

セッション切り替えを行いたいので、続きの作業を別セッションで再開できるようにai_doc以下に記録をしてください

こう指示するだけで、セッション間の引き継ぎメモになります。ちなみに私はこういう作業途中の情報は ai_wiki/investigations 以下に置いています。

(C) 機能追加タスク後に情報整理したいとき

機能がリリースされて仕様が確定したら、開発中に溜まった引き継ぎメモ群を整理してもらっています。
ここがこの運用の肝なので、次の節で改めて説明します。

確定時期の見極めと整理をして腐敗をコントロール

自己増殖方式で一番困るのが、不要になった情報をいつ捨てるか、という点です。
これを Claude Code 側に判断させることは難しいみたいで、任せきりにすると不要な内容、検討してたけど辞めた仕様、開発中に聞いてた話が間違ってた、覆った時の情報なと、余計なファイルがどんどん溜まっていきます。
そこで手動方式では、ここを人間が能動的に判断するステップとしています。

たとえば私の場合、調査ログや引き継ぎログ、タスクの進捗や残タスクのログは /ai_wiki/investigations にどんどん溜まっていくので、開発がほぼ終わったタイミングで棚卸しをしています。
以下のようなプロンプトをClaude Codeに渡しています。

〇〇機能は開発がほぼ終わりました。ai_wiki/investigations以下にあるファイルを整理し、残タスクの状態のみ残して情報を整理してください。

念のため残しておきたい場合は、こちらでもいいです。

〇〇機能は開発がほぼ終わりました。ai_wiki/investigations以下にあるファイルを整理し、残タスクについての情報のみ残し、不要な情報はai_wiki/investigations/archiveへ移動し、インデックスから外してください。

こう指示すると、Claude Code は次のような整理をしてくれます。

1. 全ファイルを読んで評価してくれる
ファイルごとに「今の価値」を判定させると、作業マイルストーン表・PR 番号・レビューの往復・「次セッションでやること」みたいな進行管理のためのメモは、確定後はほぼ価値ゼロになる、という判断が返ってきます。

2. 残すべき情報がどこにあるかを確認してくれる
最終的な構造は (A) で作った概念ノートに集約済みであれば、開発中の価値がなくなった情報は安心して退避できます。将来的に価値があるもの（将来この条件になったら再検討するというトリガー）だけは、残すノートを1件選んでおきます。

3. 削除ではなく archive へ退避
もしいきなり消すのが不安であれば、最初は investigations/archive/ に移して、Index からは外す運用をしてました。履歴としては残りますが、Index 上の見える範囲からは消えます。あとで「やっぱり全部いらないな」と思えばフォルダごと消せばいいです。こうやって二段構えにしておくと、消し過ぎのリスクを下げられます。

4. リンク切れも直してくれる
ファイルを移動すると、それを参照していた別ノートの Obsidianのリンクが切れます。これもコーディングエージェント(Claude Code) にまとめて直してもらいます。

この方法のメリット

1. コンテキストのハンドリングが効く

Indexのノートを入口にして関連ノートだけを読ませる構造なので、セッションごとに「今回必要な知識」だけをコーディングエージェント(Claude Code)が探して、コンテキストに使います。Vault全体が膨らんでも、入口の Indexと実際に動いている機能の仕様や現在着手中の機能の仕様など、寿命別に分けたディレクトリ整理もしていくので、人間もAIも必要な情報にたどり着くコストが上がりません。作業をコーディングエージェント(Claude Code)に頼むときにも、コンテキストウィンドウをあまり消費せずに済みます。

2. コンテキストの腐敗をコントロールしやすい

古い情報が紛れ込んで、誤った前提で作業してしまう原因は更新性が損なわれている状態だと思っています。手動方式では、

• フロー型（investigations/）とストック型（concepts/ など）を寿命で分けてあるので、どの状態の情報がどこにあるかは自分で把握ができます。
• (確定タイミングで能動的に棚卸しして、役目を終えたものを archive に退避してもOK)
• ストック型ノートは「実コードで裏取りしてから書く」運用なので、書いた時点での正確性が担保されます。

必要なぶんだけ増やして、確定したら整理する」というサイクルを回す運用にしています。

3. 確定時期の見極めがスムーズ

何を・いつ恒久ノートに昇華するか、いつフロー型を退避するか、という点を自分が握っているので、その判断を開発の節目に自然に差し込めます。
自動増殖だと気づいたら大量に溜まっていて棚卸しが億劫になりがちですが、手動だと小さい単位で都度片付くので、整理が重い作業になりません。

4. セットアップが軽い

特別なフックや自動化基盤は要りません。必要なのは、以下です。

• プロジェクトのルートディレクトリに置く Markdown フォルダ（Obsidian Vault）
• 用途別に切った最低限のディレクトリ構成
• 入口になるインデックス（例：00-Index.md）
• Obsidian のアプリ
• コーディングエージェント（Claude Code）

コーディングエージェント(Claude Code)に頼むという人間のアクションが起動トリガーなので、自動実行の安全設計に悩まなくてよいです。導入の敷居が低くて、運用を止めたり再開したりも自由にできます。

5. Claude Code以外のコーディングエージェントとの連携がスムーズ

この方法は Claude Code 以外のコーディングエージェントでも使えます。
たとえば Codex なら、プロジェクトのルートディレクトリの AGENTS.md に、この ai_wiki にナレッジベースがあることを書いておくだけです。
マルチエージェントで作業しているときもエージェント間の情報がスムーズに伝わるので、作業ごとにエージェントを変えるときの引き継ぎメモとしても使えて便利です。

まとめ

Karpathy の LLM Wiki が示したプレーンテキストでAI専用のwikiをエージェントに読み書きさせるという核は活かしつつ、自己増殖のところだけを手放してみました。

この分担にしてから、セッション切り替え時の引き継ぎも、特定機能やモデル情報の恒久保存も、確定タイミングでの整理も、どれもやりやすくなりました。そして何より、コンテキストのハンドリングと腐敗のコントロールが自分の手元でできるようになったのが一番大きいです。

感覚的には、今日初めて立ち上げたセッションであっても、昨日までに話していたことを丁寧にプロンプトに書き込まなくても会話が成立します。ニッチなプロジェクト特有のキーワードを突然使って会話しても、会話が成立します。
プロンプトを書く時間もかなり少なくすることができました。

以前はSerenaを使用したり、自分用にローカルにドキュメントを置いて管理したりしていました。
けれど、まずSerenaは.serenaに英語でドキュメント保存するので、自分で修正も参照することも純ジャパの私には管理が難しいですし、自分用のドキュメントはパスを指定しないと見てくれないので煩わしかったので、これで少し工数削減ができて嬉しい限りです。

おまけ

出来上がったLLM wikiをObsidianのグラフビューで関連性を可視化すると、Indexが非常に大きく、たくさんのディレクトリと繋がっていることがわかります。
この相互リンク化と整理がObsidianをLLM Wikiに活用する醍醐味だと、日々実感しています。