AI の性能差は、実は「モデルの賢さ」だけでは決まらない。もっと効いているのは、どれだけ自分の知識・過去の意思決定・業務文脈を読ませられるかだ。市場で最も賢いモデルでも、あなたのことを何も知らなければ、平均的なアウトプットしか返さない。逆に、自分だけの知識ベースにつなぐと、同じモデルが別のマシンに変わる。海外の AI 実践者コミュニティで話題になった「Fable 5 で第二の脳を作る方法」^[1] を、日本語で噛み砕いて再構成した。

• 0%超
  顧客履歴を与えた時の会計タスク精度（履歴なしは約70%）
• 0倍
  ファイル記憶を持たせた Fable の改善幅（前世代比・Anthropic 検証）
• 0構造
  第二の脳を構成するフォルダは、たった4つ

user@sinyblog:~/second-brain ❯ 01_intro.md90秒ダイジェスト：なぜ「文脈」が勝負を分けるのか

結論から言う。今後の AI 活用で差がつくのは「どのモデルを使うか」ではなく、自分だけの文脈をどれだけ蓄積できているかだ。第二の脳とは、あなたのビジネス・顧客・過去の判断・語り口を、AI が自力で読み歩ける形で置いておく ローカルの Markdown 倉庫のこと。データベースもクラウドも要らない。プレーンテキストのフォルダが1つあればいい。

接続すると、同じモデルの出力がこう変わる。コードは自社の設計思想に沿い、文章は自分の語り口に近づき、提案は過去の顧客情報と意思決定に基づき、リサーチは一度きりで終わらず資産になる。しかもこれは特定の業務に限らない――コーディング、マーケ、コンテンツ、営業、リサーチ、どのワークフローでも効く。

user@sinyblog:~/second-brain ❯ 02_why-context-wins.md性能差の正体：モデルより「ファイル」が結果を運ぶ

「最も賢いモデルが、なぜ平凡な仕事を量産するのか」。理由は1つ、あなたのことを何も知らないからだ。ビジネスも、読者も、過去の意思決定も情報がない。だから推測し、推測はどうしても“一般論っぽく”読める。ここに数字を置くと、話が具体的になる。

つまり、結果を運んでいるのはモデルの“ティア”よりファイルの方だ。しかも新世代はこれを従来以上に報いる。Anthropic 自身の検証で、Fable にファイルベースの記憶を持たせてデッキ構築ゲームを通しでプレイさせたところ、前世代フラッグシップの3倍のペースで上達したという^[1]。ベンダー自身が測った1ゲーム分の数字にすぎないが、それが指し示す打ち手のコストは「Markdown のフォルダ1つ」。取っておいて損はない。

user@sinyblog:~/second-brain ❯ 03_what-is-obsidian.mdObsidian とは何か（1分で）

Obsidian は、あなたのPC上にある「Markdown ファイルのフォルダ」の上にかぶせて使う無料アプリだ。データベースもクラウドロックインもない。ノートはあなたが所有するプレーンテキストで、アプリはそれを美しく覗くための窓にすぎない。必要な機能は2つだけ。

1. [[wikilinks]]：ノート名を二重角括弧で囲むと、2つのノートが即座につながる。
2. グラフビュー：すべてのノートを点、リンクを線として描画し、知識を「網」として見せてくれる。

これがエージェントと相性抜群なのは、vault が単なるフォルダだから。Fable は、あなたのマシンで動くターミナルアプリ「Claude Code」を通じて、この vault を直接いじれる。プラグインもコネクタも特別な設定も不要――エージェントが Markdown を読み書きし、Obsidian が変更点を見せてくれる。あなたはアプリを使い、エージェントはフォルダを使う。両者は同じ脳を見ている。

user@sinyblog:~/second-brain ❯ 04_four-structure.md構造は4つだけ：raw / entities / concepts / INDEX.md

ファイルの山と「脳」を分けるのは構造だ。そして、ほぼ全員がここで間違える。発想の元は Karpathy の「llm-wiki」――知識ベースをコードベースのように扱う考え方だ。Obsidian はエディタ、モデルはプログラマ、wiki はコードにあたる^[1]。公開されている実運用・テンプレ・失敗談を掘ると、繰り返し現れた要素はたった4つだった。

vault/
├── raw/          # 取り込んだ原文をそのまま置く（読み取り専用の履歴）
│   ├── articles/         記事・ブログ
│   ├── transcripts/      議事録・動画の文字起こし
│   └── call-notes/       商談メモ・競合ページ
├── entities/     # 具体的な対象ごとに1ページ
│   ├── acme-corp.md      顧客
│   ├── competitor-x.md   競合
│   └── john-doe.md       人物
├── concepts/     # 抽象概念ごとに1ページ
│   ├── pricing-strategy.md   戦略
│   ├── onboarding-pattern.md パターン
│   └── q3-lesson.md          学び
└── INDEX.md      # 玄関：全ページを1行要約で列挙

エージェントの仕事は「コンパイル」だ。raw/ の新しい素材を読み、entity ページと concept ページを更新し、辿りながらリンクを張っていく。書き込みルールは4行に収まる。

1. 1ファイル＝1つの学び。冒頭に1行要約を置く
2. 新規を作らず、既存ページを更新する（重複を作らない）
3. 間違いだと分かったノートは削除する
4. raw の原文と、コンパイル済みページは常に分けておく

user@sinyblog:~/second-brain ❯ 05_knowledge-graph.md知識グラフ：育つほど強くなる理由

ページは価値の半分にすぎない。本当のエッジはページ同士のリンクに隠れている。エージェントが2つのページの間に書く [[link]] は、グラフの「辺（エッジ）」になる。これが vault とただのノートの山を分ける決定的な差だ。

Karpathy 自身の vault は約100記事・40万語規模で、すべてモデルがコンパイルし、すべてつながっているという^[1]。2週間これを回してからグラフビューを開くと、自分のビジネスが「生きた地図」として立ち上がる。その絵を見るだけで、自分が何を知っているかの捉え方が変わる。

user@sinyblog:~/second-brain ❯ 06_populate-goals.mdゴールで一気に埋める（バックフィル）

「1ヶ月コピペし続けるのか？」――否。最初の一手はバックフィル（一括流し込み）で、Fable のゴールシステムがこの仕事のために作られている。Claude Code の /goal は、ゴール（＝ゴールライン）を1つ書くと、モデルが自走し続け、別の小さなモデルが審判役として読みながら、ラインを越えたかを確認する仕組みだ^[1]。

コツは、審判が「会話に見えているもの」しか判定できない点。だからゴールは審判が読める“証拠”を要求する形で書く。走らせる前に、すでに手元にある素材を raw/ に流し込んでおく――古いチャット履歴、ブックマークしたスレッド、ノートアプリのエクスポート、顧客フォルダ、過去のリサーチ。あとは離席して、コンパイル済みの脳を受け取りに戻る。

1. すべての変更は diff で出す。「更新した」という主張ではなく、before / after の実際の行で証明させる。
2. raw/ への出典リンクが無いページは信用しない。ソース無しページはフラグを立て、鵜呑みにしない。

user@sinyblog:~/second-brain ❯ 07_keep-alive-loops.mdループで生かし続ける

思い出したときだけ養分を与える脳は、3週間で死ぬ。だからメンテナンスは「記憶」ではなく「スケジュール」で回す。作業ログを保存し、毎晩整理し、毎週矛盾や重複をチェックし、重要な知見を統合する――このループが第二の脳を業務 OS に変える。

重要なのはルーティンをプレミアムモデルに流さないこと。ノート更新のような定型作業を最上位モデルに投げるのは、お金を無駄に燃やす典型だ。プレミアムが席に見合う働きをするのは、週1回の synthesis だけでいい。

user@sinyblog:~/second-brain ❯ 08_research-machine.md脳に養分を送るリサーチマシン

ここで vault は「保管庫」から「エッジ（差別化の源泉）」に変わる。ただし、ゴミが混入しやすい工程でもある。既定の AI リサーチは「1プロンプト→チャットボット→スクロールに埋もれて消える」。しかも古い知識に立脚しがちで、AI 分野では半年前のアドバイスが今は積極的に間違っていることも多い。実務家の生の層――今まさに何が動き、何が壊れ、何が効くか――は公式ドキュメントではなくSNSにある。

1. 1つの問いを入れると、3〜5個のサブ問いに分割される。
2. 並列エージェントが扇状に展開。SNS（実務家層）、Web（ドキュメント・価格）、スクレイパー（本文全文）と、それぞれ別の面を探る。
3. すべての発見がレシートになる：主張・出典リンク・日付。
4. そして本物にする関門――懐疑役エージェントが全主張に噛みつき、殺そうとする。単一ソースの誇張はラベリング、矛盾は表面化、生き残りだけが通過。
5. 検証済みの発見だけが、日付とリンク、そして賞味期限付きのページとして vault に着地する。古い知識が自分で「私は古い」と名乗る。

user@sinyblog:~/second-brain ❯ 09_read-cheap.md課金を燃やさず読む技術

どれだけ立派な vault も、読むコストがリターンを上回れば無意味だ。そしてここが、ほとんどのセットアップで漏れているところ。メンタルモデルはこうだ――コンテキストウィンドウは高い部屋で、そこに入るテキストはすべてトークンで課金される。

# 1. CLAUDE.md は「常時課金される税」
#    セッション開始時に毎回自動ロードされる。
#    → 200行以下に抑え、vault を"指す"だけ。中身は入れない。

# 2. それ以外はすべて「読んだ分だけ課金」
#    INDEX.md を見る → リンクを辿る → キーワードを grep →
#    痕跡が示すページだけ開く。フォルダ全スキャンは絶対にしない。

# 3. 大きな問いには"労働者"を送る
#    サブエージェントが別コンテキストで50ページ読み、
#    結論を1段落にして返す。高い部屋には"蔵書"ではなく"決定"だけ置く。

要は、高い部屋には決定だけを置き、蔵書は外に置く。INDEX.md を地図に使い、必要なページだけをピンポイントで開く。重い調べものはサブエージェントに外注し、返ってくるのは1段落の結論だけ。これで vault は「長期的に安く読める資産」になる。

user@sinyblog:~/second-brain ❯ 10_wire-everything.mdあらゆる仕事に配線する

保管するだけの vault は「ファイリングの趣味」。この脳はあらゆるプロジェクトに養分を送る。やることは、各プロジェクトの CLAUDE.md に3行足すだけだ。

## knowledge
- 開始前に ~/vault/entities/ と ~/vault/concepts/ の関連ページを読む
- 自社・顧客・読者に関する主張は、必ず vault のページを根拠にする

これだけで出力が即座に変わる。マーケ：一般的なペルソナではなく、実在の読者ページと競合履歴に根ざしたブリーフ。コンテンツ：自分の過去リサーチを引用し、voice profile に合った下書き。コーディング：プロジェクトごとの“生きた設計ノート”を vault に持つので、盲目で始まるセッションが無くなる。顧客業務：すべての納品物が、背後にある関係の全履歴とともに開く。

そして後半戦――vault 自体がプロダクトになる。リサーチページは記事やガイドに、concept ページは講座に、顧客ページはケーススタディに。もう白紙から作らない。マシンがすでに検証したものを“パッケージ化”するだけだ。

user@sinyblog:~/second-brain ❯ 11_sync-warning.md脳が死ぬのは「同期」で、が定番

最後に、vault を救う警告を1つ。vault が死ぬのは、たいてい同期（sync）だ。エージェントがファイルを書いている最中に iCloud などがそれを同期すると、コンフリクトコピーが生まれ、フォルダがぐちゃぐちゃになる。

cd ~/vault
git init
git add .
git commit -m "checkpoint: 第二の脳のスナップショット"
# 以降、区切りごとに add → commit でセーブポイントを刻む

user@sinyblog:~/second-brain ❯ 12_do-dont.mdDO / DON'T チェックリスト

user@sinyblog:~/second-brain ❯ 99_summary.mdまとめ

同じ Fable 5 でも、空っぽで使うか、第二の脳を接続して使うかで、出力は“別リーグ”になる。差をつけるのはモデル選びではなく、自分だけの文脈をどれだけ蓄積できているかだ。要点は3つに集約できる。

1. 構造が9割。raw / entities / concepts / INDEX.md の4つと、リンクで結ぶ知識グラフ。検索型は育つほど濁り、リンク型は育つほど澄む。
2. 脳は運用ループで生きる。セッション毎の記録、毎晩のコンパイル、毎週の lint と synthesis。ルーティンは安いモデル、統合だけプレミアム。
3. 使うほど賢くなる業務 OS へ。全プロジェクトに3行で配線し、課金を燃やさず読み、git で守る。vault はやがてプロダクトそのものになる。