TL;DR
- セカンドブレインに何でも突っ込むと公私が一緒くたになる
- 複数の Wiki を用意して透過的にアクセスするが正解だった
- ブレインを分離したら、ついでにポータビリティまで手に入った
こんな人に読んでほしい
- セカンドブレインになるはずだった Obsidian ノートが増えすぎて死蔵している
- Claude Code に Wiki をメンテさせる「LLM Wiki」、試したけどピンとこなかった
- グローバルなナレッジベースを1個作ったら便利すぎて全部突っ込んでたけど、プライベートな情報を入れようとした時に思いとどまった。
どれか刺さったなら、多分同じ沼にいる。答えは単純で、Wiki を1個にまとめようとするから沼にハマる。最初から複数作って、レジストリで緩く繋げばいいだけだった。
「自分の書いた文章を自分で読み直す」がポイントではなかった
LLM Wiki ってパターン、知ってるだろうか。Andrej Karpathy 氏が提唱したやつで、raw/（生ソース。保存版。変更しない）、wiki/（entity・concept・synthesis 等の、LLM が作る構造化ページ群）、schema（CLAUDE.md とか AGENTS.md の様な Wiki の構造とルールを LLM に教える文書）の3層で LLM にナレッジベースを継続メンテさせる、というやつだ。自分はこれをにゃんた氏の YouTube 動画（
Claude Codeで知識を整理する！調べごとや勉強をする際に使えるナレッジ構築の仕組みについて解説してみた）で知った。
最初これを試した時、ピンとこなくて、自分の書いた文章を Wiki に突っ込んで、AI に綺麗に構成し直してもらって、それを……自分が読む？いや別に元のメモのままでよくない？としばらく放置したままにしてしまっていた。
ある日「これ自分が読むもんじゃなくて、AI に読ませるためのもんだ」と気がついて衝撃が走る。天の声が聞こえた瞬間だった。放り込んだ情報について、なんでも聞けば答えてくれる。人間側が wiki をわざわざ読み直す必要なんてなかったのだ。
長年 Obsidian でアイデア集や忘備録を書き溜めて、律儀にインデックスページまでメンテしてきた身としては、これはもう完全にチートだった。ノートが増えれば増えるほど「これ前に書いた気がするけど、どこだっけ」になって、結局インデックスも荒れて見なくなる。全て AI に聞けばいいだけだった。
「どこからでも」が欲しくなってくる
Claude Code に Wiki のメンテを任せ始めたわけだが、最初の構成は「プロジェクトのリポジトリに.wiki/を作って、そのリポジトリで作業してるときだけ更新する」という、プロジェクト縛りの構成だった。
これはこれで便利なんだけど、使ってると欲が出る。「今思いついたこのアイデア、どのプロジェクトとも関係ないけど、どこかに置いときたい」「以前 Wiki に書いたネタ、今は別のリポジトリで作業してるけど参照したい」——プロジェクトの境界と、頭に浮かぶ情報の境界なんて、そもそも一致するわけがない。
そこで作ったのが、どこからでもアクセスできるグローバル Wiki（以下 gwiki）。ホームディレクトリの下の決まったパスに置いて、どの Claude Code セッションからでも読み書きできるようにした。これがバカみたいに便利だった。カレントディレクトリなんて気にせず、思いついた瞬間に放り込める。知りたいことがあれば、どこからでも聞ける。最高か？と思った。
便利すぎて詰んだ話
問題はここから。便利すぎるので、gwiki にはあらゆる情報がぶち込まれるようになった。仕事のメモ、個人の思いつき、家族の予定、どうでもいい調べもの——全部同じ場所に。
読み出すのは Claude Code なので、引き出す側には何の問題もない。問題は逆方向だった。ある日、gwiki の内容を元に仕事の資料を AI に作ってもらってたら、「これ、個人的な話が紛れ込む可能性もある……」と気づいてゾッとした。仕事用の Wiki と、脳内のダンプ先が同じ場所にあると、情報の露出範囲を自分でコントロールできなくなる。当たり前だった。
最初に思いついた対応は「じゃあグローバル領域をもう一個作ればいいのでは」。仕事用グローバル Wiki と、プライベート用グローバル Wiki。でもこれ、やり出すと「じゃあ趣味用は？家族用は？」でキリがない。「たった1つの特別なグローバル Wiki」というモデル自体が、そもそも詰んでいた。
発想を変える：Wiki は何個あってもいい、ただし緩く繋がっててほしい
行き着いた答えは拍子抜けするほどシンプルだった。最初から複数作る前提にして、それぞれ対等に扱って、緩いネットワークで繋ぐ。それだけ。
具体的にはこんな感じ。
各 Wiki は完全に独立
personal、work、family、あるいは特定のプロジェクト単位のもの——トピックごとに好きなだけ作る。それぞれが独立した.wiki/ディレクトリで、raw/wiki/schema の3層構成を持つ、単体で完結した LLM Wiki。
レジストリに各 Wiki を登録
各 Wiki は、マシン上に1個だけあるレジストリファイル（~/.claude/wiki-registry.md）に、自分の絶対パスと "内容の要約" を以下のスキルで登録する。
/wiki regiter
クエリを投げるときは、まず、そのレジストリの要約だけ見て、関連しそうな Wiki をふるいにかける。そのあとで、絞り込んだ Wiki の Index を読みに行く。つまりレジストリは Index の Index だ。
読み取りは串刺し、編集は各 Wiki で
他 Wiki へのアクセスはRead/grep のみ。書き込み・編集は自分の Wiki 以外には一切やらない。他 Wiki のページへのリンクも張らない。
これによって、どこからでも全ての Wiki に横断的にアクセスできるようになる一方で、ナレッジベースの情報境界は Wiki 単位で完全にコントロールできる。おかげで各 Wiki ディレクトリは単体でコピーしても壊れない、完全にポータブルな単位のままでいられる。
"内容の要約" の更新はスクリプトで
Wiki はクエリ時、他の Wiki の要約を確かめにレジストリを見に行く。分散 Wiki を成立させるには、この要約の正確さが重要になる。そこで Wiki では、ingest のたびに追加する内容が今の要約でカバーされているかをチェックし、されていなければ要約を書き直すという作業を行う。
このとき、毎回レジストリまで確かめに行かせるのもいちいち時間がかかるので、自分の Wiki の Index に要約を書いておき、それと同じものをレジストリにも書く、というふうにした。
ただ、この「2箇所を一致させる」という同期処理自体を毎回 LLM にやらせるのもやっぱり時間がかかるので、wiki-sync-description.sh という同期用のスクリプトを作成し、これを呼ばせるようにした。やることは決まりきった機械的な書き換えなので、LLM に毎回プロンプトでやらせる意味はなかった。
分散させて初めてできるようになったこと
単一のグローバル Wiki ではどう頑張っても無理だったことが、この構成で一気にできるようになった。
- トピックごとに無限に Wiki を作れる: personal、work、family、趣味のプロジェクト……作りたいだけ作る。
- Wiki 単位のポータビリティ: ディレクトリを1個コピーすれば、それだけで完結した Wiki として持ち運べる
- 特定 Wiki だけ他人と共有・共同編集できる: プロジェクト用の Wiki は GitHub リポジトリに入れてチームで共有。プライベートな wiki は自分のマシン専用、みたいな使い分けが自然にできる
- 使い捨ての Wiki も作れる: 「来月のイベント企画」みたいな、最初から寿命が短いとわかってる情報は、専用の一時 Wiki に隔離できる。long-run の知見を貯める Wiki に賞味期限切れの情報を混ぜてノイズにしなくて済む。使い終わったらレジストリから削除。(エディタで開いてエントリーから削除するだけです。)
- 全 Wiki に、どのセッションからでも透過的な読み取りアクセス: レジストリに登録さえしてあれば、どこで作業してても、関係しそうな Wiki の知見をクエリのたびに拾ってこれる
リポジトリをどんな単位で切るか
Wiki は結局のところ、.wiki/を持ったリポジトリだ。既存のコードプロジェクトの Wiki ならそのプロジェクトのリポジトリにそのまま.wiki/をぶら下がるだけなので、単位を気にする余地はない。プロジェクトの区切りがそのまま Wiki の区切りになる。
悩むのは、特定のコードプロジェクトに紐付かない「知識だけの Wiki」（personal、family、work、趣味の調べもの……）を作るときだ。Wiki 専用のリポジトリを新しく用意することになるが、その新しいリポジトリはどういう単位で切るのか。今のところ判断材料にしているのはだいたい3つの軸になる。
- 公開境界: Public / Private という軸。これを混ぜると、Wiki からドキュメントを作った時に、資料に個人情報が交じることになる。
- 情報の寿命: 情報の「賞味期限」が揃っているか。上の「使い捨ての Wiki」の例。生涯使う Wiki に短命な情報はノイズになるので混ぜない。
- 関心の境界: 言わずもがなだが、そもそも扱っているトピック・関心事がまとまっているか
実際は大して考えずに、思いついたら作る、くらいの感覚でどんどん作っている。何個作っても串刺しでクエリできるのがこの構成の特徴なので、区切りを多少間違えたところで後で困らない。だから気軽にサクサク作れる——これも分散構成の利点の一つだろう。
未だ試していないが、特定の内容について新しい Wiki に切り出すみたいなことも LLM に頼めばやってくれるだろう。
それでも gwiki だけは特別扱いする
ここまで「Wiki は全部対等」と言ってきたが、1個だけ運用上どうしても特別な Wiki がある。どこからでもアクセスできる gwiki だ。
プロジェクト単位の Wiki は、そのリポジトリで作業してるときにしか更新が発生しない。作業のコンテキストと Wiki のコンテキストが自然に一致するので、リポジトリ縛りのアクセスで何の問題もない。
一方で gwiki は「everything else」の受け皿だ。どのプロジェクトにも属さない、アイデア、自分のプロフィール、雑多なメモ——こういうのは、どこにいても、思いついた瞬間に放り込みたい。だから gwiki だけは、カレントディレクトリに関係なく常にアクセスできる、独立したスキルとして持っておく必要がある。
gwiki スキルは読み取りも編集も gwiki 専用だが、同時に wiki スキルも使えるので問題ない。
実装はどうなってるか
Claude Code のスラッシュコマンド（スキル）として以下の２つを実装。
-
/wiki（プロジェクトの.wiki/を操作） -
/gwiki（どこからでも呼べるグローバル Wiki）
gwikiもレジストリには登録されるので他の Wiki から見つけてもらえる存在にはなる。ただしクロス Wiki 検索を持つのは/wiki側だけ。/gwikiは gwiki だけを見る作りにしている。要約の同期に使うwiki-sync-description.shは両方から共通で使っている。
実装はここに置いておきます。
私の Wiki 定義はリンクに Obsidian リンクではなくて、Markdown リンクを使う指示になっている。Obsidian リンクにすると Wiki コンテンツとして一般に公開したい時に、リンク解決ができなくてリンクが壊れるからだ。結局 LLM がリンクを作成更新するので、Markdown リンクを選んだ。
この様に、人によって Wiki の細かい特性が違っていたりするので、このまま使うより、この記事とリポジトリを Claude Code に読ませて、「これと同じ仕組みを自分用にアレンジしてスキルにして」と頼むのが一番早い。設計思想（対等な Wiki、レジストリによる発見、read-only/no-cross-link、gwiki の特別扱い）さえ伝われば、細部は好みで組み直せるはずだ。
まとめ
- LLM Wiki は自分が読むためのものじゃない、AI に聞くためのものだ
- 単一のグローバル Wiki は便利だが、いずれごった煮になってプライバシー管理が崩壊する
- Wiki は最初から複数作る前提にして、中央レジストリで緩く発見できるようにすればいい
- gwiki だけはアクセス方法の違いから独立したスキルとして残す価値がある
セカンドブレインを1個の Wiki に抱え込んで身動き取れなくなってる人がいたら、とりあえず分散させてみてほしい。マジで楽になる。
質問あればコメントで気軽にどうぞ。