Obsidian と Claude Skills で「第二の脳」を勝手に構築する、という記事を読んだ。元 OpenAI / Tesla の Andrej Karpathy が示した方法論をベースに、raw / wiki / reports の3フォルダと Skill だけで知識ベースを回す、という話だ。
読んでいて、耳が痛かった。自分の Obsidian が、まさに記事の言う「クリップ置き場で止まった第二の脳」そのものだったからだ。
せっかくなので、記事の方法論をそのまま真似するのではなく、自分の環境に合わせて接ぎ木するところまでやってみた。その記録を残しておく。
出典：【保存版】Obsidian×Claude Skillsで第二の脳を勝手に構築する方法（元ネタは Andrej Karpathy のポスト）
まず、自分の Vault を数えて絶望した
記事の主張はシンプルだ。第二の脳が育たないのは、AIを「賢いGoogle」として使っているから。タブを閉じれば記憶はリセットされ、容れ物（フォルダ）だけが増えていく。必要なのは、素材を読んで構造化し続ける「コンパイラ」と、それを横断引用する「図書館係」の仕組みだ、と。
自分に当てはめて、Vault のノート数を数えてみた。結果はこうだった。
- raw 相当（Inbox + Fleeting Notes）：約 504件
- wiki 相当（Permanent + Structured Notes）：約 52件
比率にして、およそ 10 対 1。素材は500件以上も溜まっているのに、構造化された知識は52件しかない。放り込む習慣はあるのに、それを読んで書き直す仕組みがなかった。記事が言う「フォルダは作った、でもコンパイラがいない」状態、そのものだった。
Fleeting Notes が365件も滞留していたのも、同じ症状だ。溜めることはできる。育てることができていなかった。
3フォルダを作り直す、はやらなかった
記事は「raw / wiki / reports の3フォルダに戻せ」と言う。整理もリネームもするな、ただ放り込め、と。ミニマルで気持ちのいい思想だ。
ただ、自分の場合はここで素直に従わなかった。理由は単純で、既存のツェッテルカステンが、すでにこの3フォルダに対応していたからだ。元記事の raw / wiki / reports を、自分の既存フォルダに突き合わせると、こう対応する。
| 役割 | 元記事の構造 | 自分の環境（既存ツェッテルカステン） |
|---|---|---|
| raw（放り込む・整理しない） | raw/ |
00-Inbox/ ＋ 01-Fleeting-Notes/ |
| wiki：概念ページ（1アイデア1ノート） | wiki/concepts/ |
01-Permanent-Notes/ |
| wiki：目次・MOC | wiki/index.md |
index.md ＋ 01-Structured-Notes/ |
| reports（問いへの答え） | reports/ |
02-Reports/（← 新設） |
| Vault の憲法 | CLAUDE.md |
CLAUDE.md（既存に追記） |
| Skill 群 | .claude/skills/ |
.claude/skills/（kb-compile / report / lint） |
こうして並べると、新しく作ったのは reports フォルダだけで、あとは既存フォルダに役割を割り当て直しただけだとわかる。元記事は「3フォルダをゼロから作れ」だが、自分にとっての正解は「4段のツェッテルカステンに、raw / wiki / reports の役割をかぶせ直す」だった。
新しく3フォルダを切って並行運用すると、500件の既存資産とリンクが宙に浮く。二重管理になって、たぶんどっちも腐る。だから、足りないのは箱ではなく、箱を動かす仕組みのほうだと割り切った。
これは今回いちばん学びになったところだ。他人のメソッドを取り込むとき、器ごと入れ替える必要はない。自分の器に、足りない部品だけ接ぎ木すればいい。
足りなかったのは Skill 3本と、週次の掃除だった
では何が足りなかったのか。整理すると3つだった。
1. コンパイラ（編纂役）がいない。 504件の raw を読んで、繰り返し出てくる概念を Permanent Notes に落とす担当がいなかった。
2. reports の置き場と習慣がない。 「Vaultだけを使って答えて、ファイルで残せ」の受け皿がなかった。答えはいつもチャットに流れて消えていた。
3. 週次の掃除がない。 これが記事のいちばんの肝で、追加ばかりして整理しないと Vault は必ず腐る、という話だ。矛盾も重複も溜まる一方だった。
そこで、この3つをそれぞれ Claude の Skill にした。SKILL.md を1枚書けば、毎回プロンプトを書き直さずに同じ動きを呼び出せる。
- kb-compile — Inbox を読んで、概念ごとに Permanent Notes を書く（コンパイラ）
- kb-report — 問いに対して wiki だけを読み、答えを reports に残す（図書館係）
- kb-lint — 週1で wiki をスキャンし、矛盾・重複・欠落を洗い出す（掃除）
ポイントは、Skill の中に自分の Vault の作法を全部書き込んだことだ。どのフォルダが raw で、Permanent Notes のフロントマターはどう書くか、日本語はですます体で textlint に通す、といったローカルルール。コピペしてきた汎用スキルではなく、自分の器の形に合わせて彫った道具になっている。
実際にどう置いたか（配置とコマンド）
抽象的な話ばかりだと再現できないので、実際にやった配置を残しておく。既存の 11-Zettelkasten/ はそのまま使い、新しく作るのは reports フォルダと Skill 3本の置き場だけだ。
cd ~/Vault # 自分の Obsidian Vault のルート
# reports だけ新設（raw / wiki は既存フォルダを流用する）
mkdir -p 11-Zettelkasten/02-Reports
# Skill 3本の置き場
mkdir -p .claude/skills/kb-compile \
.claude/skills/kb-report \
.claude/skills/kb-lint
# wiki の目次（kb-compile がここに1行サマリを追記していく）
touch 11-Zettelkasten/index.md
結果として、Vault の中はこういう役割分担になった。
11-Zettelkasten/
├── 00-Inbox/ # raw：放り込むだけ（読み取り専用）
├── 01-Fleeting-Notes/ # raw（副）
├── 01-Permanent-Notes/ # wiki：概念ページ（1アイデア1ノート）
├── 01-Structured-Notes/ # wiki：目次・MOC
├── 02-Reports/ # ← 新設。問いへの答えがファイルで残る
└── index.md # wiki の目次
.claude/skills/
├── kb-compile/SKILL.md # コンパイラ
├── kb-report/SKILL.md # 図書館係
└── kb-lint/SKILL.md # 掃除
Skill の中身は SKILL.md 1枚だ。たとえば kb-compile はこんな骨格にした。フロントマターの description がルーティングキーになっていて、ここを見て Claude が「いま使うべきか」を判断する。
---
name: kb-compile
description: 00-Inbox と 01-Fleeting-Notes（raw）をスキャンし、繰り返す概念を 01-Permanent-Notes（wiki）に書き出す。Inbox が溜まったとき等に使う。
---
# kb-compile
## 何をするか
1. 00-Inbox（必要なら 01-Fleeting-Notes）のファイルを Read する
2. 3ファイル以上で繰り返される概念を列挙する（単発はスキップ）
3. 概念ごとに 01-Permanent-Notes/{concept}.md を作る／既存なら更新する
4. index.md に概念名と1行サマリを追記する
## 制約
- raw（00-Inbox / 01-Fleeting-Notes）は読み取り専用。削除・改名しない
- 出典のない断定をしない。数値は元ファイルと一致させる
- 日本語・ですます体。箇条書きは体言止め、textlint に通す
そして、Vault 全体のルールは CLAUDE.md（Vault の憲法）に書いておく。新しいセッションを開くたびに自動で読まれるので、毎回説明しなくてよくなる。肝は raw を触らせないことだ。
## Vault Layout
- raw（00-Inbox / 01-Fleeting-Notes）は読み取り専用。削除・改名は禁止
- wiki（Permanent / Structured / index.md）と reports は Claude が自由に書く
- reports は wiki 経由で引用し、raw を直接引用しない
- 追加だけでなく、週1で kb-lint を回して整合性を保つ
あとは Vault のルートで Claude Code を起動して、コマンドを叩くだけだ。
cd ~/Vault
claude
# raw を読んで wiki を書かせる
/kb-compile
# wiki だけを読んで、答えを reports に残させる
/kb-report 「AI時代のエンジニアの役割を、wiki だけで論点を5つに整理して」
# 週1で掃除する
/kb-lint
流れを一本の線にすると、こうなる。
raw に放り込む → /kb-compile で wiki 化 → /kb-report で問いを資産化 → reports に蓄積 → 週次 /kb-lint で掃除。 人間が手で書くのは raw に放り込むところと、最後に少し直すところだけだ。
図にすると、こういう一連の流れになる。
raw から reports までが日々のメインの流れで、その上を回っているのが週次の掃除（/kb-lint）だ。人間が手を動かすのは raw に放り込むところと、最後に少し直すところだけ。ここで育てた wiki を素材にブログへ展開する話も出てくるが、それはこの運用ループとは別軸なので、また別に書く。
実際に動かしたら、バラバラのクリップが3つの塊になった
道具だけ作って満足しても意味がないので、実際に kb-compile を回した。
Inbox の最新28件を対象にした。中身は、ハーネスの話、Agent Skills の話、「エンジニアの仕事はどうなるか」系、トークンマキシング、AIへの仕事の任せ方 … バラバラだ。これを Skill に読ませて、3ファイル以上で繰り返される概念だけ拾わせた。
出てきたのは 5つの概念 だった。
- AIハーネス（出力制御から理解の強制へ）
- Agent Skills の本質（コンテキスト管理とルーティング）
- サブエージェント・オーケストレーション
- AIへの仕事の任せ方（成果移譲と批判ループ）
- AI時代に人間へ残る役割（何を作るかと検証）
それぞれに出典リンクと相互リンクが張られ、目次にも1行サマリが追記された。Obsidian のグラフビューで見ると、28個のバラバラな点が、3つくらいの塊に集まって見える。クリップ置き場が、はじめて「構造」に見えた瞬間だった。
さらに、この5つを束ねる Structured Note（マガジン）を1枚立てた。そうすると今度はそれが、ブログのネタ地図になる。実際いまこうして記事を書けているのも、その副産物だ。
複利は「掃除」から来る、という納得
やってみて、記事のいちばん地味な主張が、いちばん腹落ちした。
複利の正体は、追加ではなく週次の掃除にある。
多くの人は（自分もそうだった）「溜める」ことばかり考える。でも、ただ追加するだけの Vault は時間とともに腐る。同じ概念が微妙に違う定義で二重に書かれ、根拠のない数字が残り、似たページが増えていく。そこを週1でスキャンして整えるかどうかが、半年後の差になる。
だから今回いちばん大事に作ったのは、実は派手な kb-compile ではなく、地味な kb-lint のほうかもしれない。掃除する仕組みを持っているかどうか。ここが、賢くなっていく Vault と、ただ重くなる Vault の分かれ目だと思う。
まとめ：器は変えず、仕組みだけ足す
やったことを短くまとめると、こうなる。
- 他人の「第二の脳」メソッドを、器ごと真似しなかった
- 既存のツェッテルカステンに、足りない Skill 3本だけを接ぎ木した
- Skill には汎用ルールではなく、自分の Vault の作法を書き込んだ
- 実際に回して、504件のクリップから最初の5概念を立ち上げた
新しいツールや方法論を見るたびに、つい一から作り直したくなる。でも、たいていの場合、必要なのは全とっかえではなく、いま動いている仕組みに足りない部品を見極めることだ。今回の一番の収穫は、その順番を思い出せたことだった。