Obsidianを第二の脳にする 第3回: 保管庫の運用をAIに任せる、指示書CLAUDE.mdとingest/query/lint

目次 / INDEX

第2回の最後に、断片を拾って割って繋いで2枚のファイルに1行ずつ足す工程を「地味に面倒くさい」と書いた。今回はあの工程をまるごとAIに渡す。連載の核はここだと思っていて、第1回・第2回で作ってきたルールが全部「AIへの指示書」に化ける回だ。やることは2つだけ。保管庫の直下に指示書を1枚置く。そして、取り込み(ingest)・問い合わせ(query)・健診(lint)の3つの操作をAIに回させる。

ここから先、実際に手を動かすのはAIの側になるから、あなたが持っておくのは「どう頼むか」の型だけでいい。

結論 第3回は運用をAIに任せる回。保管庫の直下に指示書「CLAUDE.md」を置き、ingest（取り込み）・query（検索要約）・lint（点検）の3操作をAIに投げる。健診は機械に、判断だけAIにやらせるのがコツ。

保管庫の直下に「CLAUDE.md」を置く

僕はClaude CodeというAIコーディングツールを使っている。ターミナルで動くAIで、フォルダを指定して起動すると、そのフォルダの中のファイルを読み書きしてくれる。で、このツールには決定的に便利な仕様が一つある。起動したフォルダに「CLAUDE.md」という名前のファイルがあると、起動時に自動で読むんだ。

つまり保管庫の直下にCLAUDE.mdを置いて、そこに保管庫の運用ルールを書いておけば、毎回「index.mdに1行足してね、幽霊リンクを作らないでね」と説明しなくて済む。AIは起動した瞬間からルールを知っている状態で仕事を始める。このファイルはノートじゃない。AIへの指示書だ。

種明かしをすると、この設計は僕のオリジナルじゃない。AI研究者のKarpathyが提唱した「LLM Wiki」というパターンの翻案で、知識ベースを raw / wiki / schema の3層に分ける考え方だ。僕の保管庫だと対応はこうなる。

• raw = 会話アーカイブなどの生ログ。追記だけして書き換えない
• wiki = それ以外のすべてのノート。AIが書き、人間が読む
• schema = CLAUDE.md。人間とAIが合意して改訂する

第1回で分けた「生ログ島」がraw、brainがwikiに当たる。あのとき切っておいた区画が、ここでそのまま層になる。

raw、wiki、schemaと横文字が3つ並んで、急に難易度が上がった気がするかもしれない。実際は「触らない生ログ」「育てるノート」「ルールの紙」と呼び替えただけで、しかも指示書のたたき台を書くこと自体もAIに頼める。人間の仕事は、出てきた文面が自分の運用と合ってるか読んで直すことだけだ。

で、肝心の指示書に何を書くか。僕が実際に置いているものを、骨組みだけサニタイズして見せるとこうだ。

# この保管庫の運用規約(schema層)
このファイルはノートではなくAIへの指示書。読み書きの前に必ず読む。

## 索引と台帳
- index.md に全ノートを1行で載せる。新しいノートを作ったら必ず1行足す。
- log.md は追記専用。過去行は書き換えない。

## 3つの操作: ingest / query / lint(下記)

## リンク規約
- 普通名詞を[[ ]]にしない。知識ノートは必ず柱フォルダへ。生ログ島とは繋がない。

見ての通り、中身は第2回までに手で決めたルールそのままだ。新しいことは何も書いていない。手で回して固まった運用を、AIが読める場所に書き写しただけ。だから第2回を飛ばしてここから始めると、書くべきルールが自分の中に無くて詰まると思う。

もう一つ、schema層の対応表に「人間とAIが合意で改訂」と書いた意味。この指示書は書いたら終わりじゃなくて、運用中に育っていく。AIが変な動きをしたら、その原因になった曖昧さを指示書に1行足して塞ぐ。逆にAIの側から「このルール、こういうケースで困るから直したい」と提案してくることもあって、採用するかは人間が決める。rawは触らない、wikiはAIが書く、schemaだけは両者の合意で直す。層ごとに書き換えの権限が違うのがこの3層の肝だ。

AIにやらせる3つの操作

指示書の本丸がこの3操作の定義で、保管庫に対するAIの仕事をこの3つに限定する。

ingest(取り込み)

新しい会話、調べ物、デイリーノートの断片が入ったときの操作。手順を指示書にこう書く。

1. 断片を読んで要点を抽出する
2. 既存の関連ノートに統合する。似たノートを新規に作らない(重複禁止)
3. 統合先と関連ノートに相互リンクを張る
4. index.mdとlog.mdに1行ずつ追記する

第2回で手でやった工程1〜6が、ほぼそのまま4手順に圧縮されているのがわかると思う。特に効くのが2の重複禁止で、これを明文化しないとAIは似た概念のノートを平気で新規に作る。僕は最初この一文を書いてなくて、同じ話のノートが2枚できているのに気づいたときは、統合し直しながら「先に書いとけばよかった」と本気で後悔した。AIは書かれていないルールは守らない。当たり前なんだけど、手で運用していた頃の暗黙の了解は全部明文化が要る。

query(問い合わせ)

保管庫に質問するときの操作。

1. まずindex.mdを読む。全ノートを読みに行かない
2. 該当しそうなノートだけ開いて読む
3. 答えに出典(ファイルパス)を付ける。推測で補った部分には「⚠要確認」を付ける
4. 答えに再利用価値があれば、ノートにしてwikiに戻す

1が第2回で仕込んだ伏線の回収だ。index.mdという1行カタログがあるから、AIは300枚のノートを全部読まずに、300行の目次から当たりを付けられる。速いし、読み込みの無駄が減る。

3は信頼性の話。AIの答えは堂々としているけど、たまに保管庫に書いていないことを混ぜてくる。だから「どのファイルを根拠にしたか」を毎回言わせて、根拠の無い部分には印を付けさせる。出典パスがあれば人間が3秒で裏を取れる。

4は地味に好きなルールで、質問の答えとして良い説明が生成されたら、使い捨てずにノート化して保管庫へ戻す。質問するたびに脳が育つ。

lint(健診)

保管庫の健康診断。検出するのは4種類。

1. 矛盾: ノート間で言っていることが食い違う箇所
2. 孤立: どこからもリンクされていないノート
3. 未作成ページ: 本文で[[X]]と書いたのにX.mdが実在しない(第2回の幽霊リンク)
4. 鮮度: 古くなった記述、過ぎた予定が残っている箇所

1と4は人間だとまず見つけられない類のやつだ。矛盾は、たとえば片方のノートに「週1で回す」、別のノートに「毎日回す」と書いてある食い違い。書いた時期が違うだけで、どっちも当時は正しかったりする。鮮度は「来週の試験に出るらしい」が半年残っているような箇所。第2回で「時限情報を知識ノートに書かない」と決めたのはこのためで、それでも混入は起きるから健診で拾う。

そして一番大事なルールが「検出するだけ。修正は人間の承認を得てから」。ここだけは絶対に譲らない方がいい。lintと修正を一気にやらせると、AIが「矛盾している」と判断した側のノートを勝手に書き換えることがあって、その判断が間違っていたら知識が静かに壊れる。壊れたことに気づくのは大抵ずっと後だ。検出と修正の間に人間の承認を1枚挟むだけで、この事故は防げる。

実際に投げる指示は、拍子抜けするほど短い

指示書に全部書いてあるから、僕が実際にAIに投げる言葉はこのくらい自然でいい。

調べたいとき(query)はこう。

あのタスクの進捗教えて

あの企画、今どこまで進んでたっけ?

覚えさせたいとき(ingest)はこう。

これ覚えといて

健診したいとき(lint)はこう。

保管庫の健診して

見ての通り、「index.mdを読んで」も「出典パス付きで」も「index.mdとlogを更新して」も、一言も言っていない。それでもAIは、まずindex.mdを見て、該当ノートだけ開いて、出典パスを付けて答える。覚えさせれば、既存ノートに統合して、indexとlogまで自分で更新する。全部schema層に書いたルールを勝手に守るからだ。

毎回のように機械的な指示を繰り返さなくていい、というのが指示書方式の一番の旨みだと思う。こっちは「何を」だけ言えばいい。「どうやって」は、ファイル一枚に永続的に預けてある。

健診は機械にやらせて、AIには判断だけさせる

最後にもう一段の効率化。lintのうち「未作成ページ」と「孤立」の検出は、実は純粋な突き合わせ作業だ。保管庫内の全ファイルから[[ ]]を抜き出して、実在するファイル名の一覧と照合すれば機械的に出る。これを毎回AIにやらせると、全ファイルを読み込むぶん遅いし無駄が多い。

だから僕はここを小さなPythonスクリプトに切り出した。やっていることは単純で、保管庫の全Markdownから正規表現で[[ ]]の中身を全部拾って集合にして、実在するファイル名の集合と差分を取る。リンク集合にあってファイル集合に無いのが未作成ページ、ファイル集合にあってどのリンクからも指されていないのが孤立ノート。生ログ島のフォルダは第1回の設計通り対象から外す(あそこは孤立していて正常だから)。数十行で書けるし、書くこと自体AIに頼めばいい。AIには、スクリプトが吐いた一覧を読ませて「これはノートを作るべき、これは囲みを外すべき」の判断と修正案だけをさせる。

つまり分担はこうなる。機械で検出、判断はAI、承認は人間。全部AIにやらせるより速くて、全部機械にやらせるより賢くて、全部人間がやるより楽。3者の得意なところだけ使う形に落ち着いた。

スクリプトと聞いて身構えた人も大丈夫。ここで自分がコードを書く場面は一つもない。「突き合わせは機械の方が得意そうだから切り出して」とAIに言えば、書くのも動かすのもAIがやる。必要なのはプログラミングの腕じゃなくて、この分担を思いつける程度の見取り図だけだ。

手で一周したから、一枚で渡せる

第2回で「手で一周やっておくと、AIが何をやっているか全部わかる状態で任せられる」と書いた。今回やったのはまさにそれで、手で回して固めたルールを指示書一枚に書き写したら、ingestもlintも委譲できてしまった。逆順は無理だったと思う。自分の中に無いルールは、指示書に書けない。

これで保管庫は、放り込めばAIが育ててくれる箱になった!

連載の最初に、この作業は最終的にAIに丸投げできると言った。その丸投げの正体がこの一枚で、要は考え方さえ言葉にできれば、あとの手はぜんぶAIが動かしてくれるということだ。

関連連載 自分専属のAI秘書を作る 保管庫をAIに運用させるこの考え方は、予定やタスクを任せるAI秘書づくりにそのまま地続き。合図・記憶・定期実行まで全4回。 連載を読む →

次の第4回は最終回で、rawの層の話。日記やAIとの会話ログを自動で溜めて、そこから知識を蒸留してbrainへ送る流れを作る。ここまで来ると、第二の脳は「書く場所」じゃなくて「勝手に育つ場所」になる。