Andrej Karpathy（元 OpenAI・元 Tesla AI ディレクター）が提唱した「Claude Code での第二の脳の作り方」。 この記事では、Claude Code + Obsidian を組み合わせて知識を蓄積・進化させる「AI 第二の脳」システムの仕組みとセットアップ手順を解説します。

普通の RAG と何が違うのか

ChatGPT へのファイルアップロードや NotebookLM のような一般的な RAG は、以下のように動きます。

  1. ファイルを渡す
  2. 質問のたびに AI が関連部分を探す
  3. 毎回ゼロから答えを生成する
  4. 次の質問がきたら、また同じことをゼロから繰り返す

何も積み重ならないのが問題です。

Karpathy が提唱したシステムは根本的に異なり、**AI が「Wiki を育て続ける」**仕組みです。新しい資料を入れるたびに、AI がその内容を読んで既存の知識と統合し、矛盾があれば修正し、関連ページを更新します。知識が一度まとめられると、常に最新状態に保たれます。

システムの全体像

このシステムには 4 つの動く部品があります。

  1. あなたのデータ — 記事・ノート・文字起こし・アイデアなど
  2. 整理 — Claude Code が Obsidian に自動で整理
  3. 即座の質問 — 育てたデータベースにいつでも質問可能
  4. 進化する記憶 — 使えば使うほど賢くなる仕組み

3 つの層構造

層名称役割
層 1生のソース（immutable）記事・論文・画像・データファイル。AI は読むだけで書き換えない
層 2Wiki要約・人物・概念・比較・総合分析ページ。AI が作成・更新し続ける
層 3スキーマ（CLAUDE.md）Wiki の構造・ルール・ワークフローを AI に教える設定ファイル

この 3 層構造により、AI が「汎用チャットボット」ではなく「規律を持った Wiki 管理者」として動きます。

AI が Wiki で行う 3 つのオペレーション

① Ingest（取り込み）

新しいソースをフォルダに入れて「処理して」と言うだけです。

新ソース追加 → AI がソースを読む → キーポイントについて対話 → Wiki にサマリーページを書く → インデックスを更新 → 関連する人物・概念ページを 10〜15 個更新 → ログに記録

1 つのソースを入れるだけで、10〜15 ページが同時に育ちます。これが「蓄積」の正体です。

② Query（質問）

Wiki に何でも質問できます。AI が関連ページを検索・参照し、引用付きで回答します。答えの形式は柔軟に選べます。

  • Markdown ページ
  • 比較表
  • スライドデッキ（Marp 形式）
  • グラフ（matplotlib）
  • キャンバス

回答はそのまま Wiki に保存でき、「あの時の比較表」が消えずに次の質問に活かされます。

③ Lint（健康チェック）

定期的に AI に Wiki の状態を確認してもらいます。チェック内容：

  • ページ間の矛盾
  • 新ソースで古くなった記述
  • リンクがない孤立ページ
  • 概念はあるのにページが存在しない箇所
  • 相互参照の漏れ
  • データのギャップ

2 つの特別ファイル

index.md（内容中心）

Wiki の全ページをカテゴリ別に一覧化したカタログ。AI は質問に答える前にまずここを読んで関連ページを特定します。Wiki が 100 ソース・数百ページ規模になっても、RAG インフラなしで機能します。

log.md（時系列記録）

Ingest・Query・Lint をすべて追記形式で記録します。

1

## [2026-04-09] ingest | 記事タイトル

Unix コマンドで簡単に検索できます。

1

grep "^## \[" log.md | tail -5

なぜ Obsidian Vault なのか — 単なる Markdown フォルダーとの違い

Obsidian Vault は実体としては「.md ファイルが置かれたフォルダー」に過ぎません。それなら自分でフォルダーを切って Markdown を並べれば同じでは、という疑問が湧きます。実際には、以下の機能差が「LLM が育てる Wiki」というユースケースで効いてきます。

[[ページ名]] 記法で書くだけで、リンク先のページからも「どこから参照されているか」が自動で見える仕組みです。フォルダー階層は親子の一方向しか表現できませんが、Obsidian なら「ノート間の関連性」が双方向に可視化されます。

Karpathy の文脈で重要な「蓄積した知識から関連を発掘する」動作が、明示的な検索を経なくても成立します。

2. グラフビュー

ノート間のリンク関係をネットワーク図として可視化する機能です。フォルダーツリーは木構造（親子関係）しか表現できませんが、知識は本来ネットワーク状です。孤立ノートやハブノートが一目で分かるため、Wiki の「弱い部分」を発見しやすくなります。

3. タグ・プロパティでの横断管理

フォルダーは「1 つの場所にしか置けない」制約がありますが、タグ（#claude-code など）と YAML frontmatter は複数の分類軸を併用できます。例えば tools/claude-code.md を「AI ツール」「ナレッジ管理」両方の文脈で扱えます。

4. Dataview プラグイン

frontmatter を SQL ライクにクエリして動的な一覧ページが作れます。例: 「tags: claude-code を含む最近 30 日のノート一覧」を自動生成。フォルダー管理だと手動メンテが必要な部分です。

5. Canvas（無限キャンバス）

ノートを 2D 空間に配置して思考を視覚的に整理できます。マインドマップ的に概念を並べて、後から Wiki ページに昇華させる使い方が可能です。

6. プラグインエコシステム

Templater（テンプレ自動化）、Excalidraw（手書き図）、Smart Connections（埋め込みベクトル検索）など、LLM 連携系プラグインも豊富です。

LLM Wiki パターンとの相性

最も重要なのは、Claude Code が .md ファイルを直接読み書きできるという点です。Vault がそのまま AI のコンテキストになり、Obsidian は人間側の閲覧・編集 UI として機能します。両者で同じファイルを共有する設計が成立するため、クラウド DB 不要・ローカルファーストで完結します。

つまり Vault は「ただのフォルダー」ですが、双方向リンク + メタデータ + 可視化ツールが揃うことで、フォルダー管理だけでは得られない「知識の発見性」が生まれます。これが「第二の脳」を機能させる土台になります。

MkDocs / Hugo / Docusaurus などの静的サイトジェネレータと何が違うのか

「Markdown 間の関係性なら MkDocs でも作れる」「mkdocs.yml で全体構成を宣言できる」「リンクは標準の [text](path.md) 記法で十分」という指摘は正当です。さらに**mkdocs.yml の更新も LLM にやらせれば人間のコストはほぼゼロ**になるため、構成管理の手間という観点では差はほとんど消えます。

つまり「LLM 前提なら、AI 側から見ると MkDocs でも MkDocs Material でも Wiki は十分育てられる」というのは事実です。それでも Obsidian が選ばれる理由は、AI 側ではなく人間側の体験にあります。

LLM が書く前提なら、差は「人間がどう読むか」に移る

LLM が ingest・lint・更新を担う以上、ファイル形式やリンク記法・構成ファイルの違いは AI にとっては誤差です。差別化要素は、人間がその Wiki を日々どう使うかに絞られます。

観点MkDocs / Hugo（+ LLM）Obsidian
ファイル更新LLM が問題なく対応LLM が問題なく対応
内部リンク[text](path.md) で OK[[ページ名]]
ナビゲーションmkdocs.yml を LLM が更新リンクから自動派生
編集中のフィードバックブラウザで再ビルド or プレビュー切替エディタ画面そのものに統合
Backlinks の即時表示プラグインで可能だがビルド後サイドバーに常時表示
Graph View の対話操作プラグインで静的描画クリック・フィルタで探索可能
Canvas（空間配置）該当なし標準機能
Hover Preview該当なしリンク上にカーソルで内容表示
Quick Switcher / Command Paletteエディタ依存標準でファイル横断検索

残る本質的な差は「思考しながら使う UI」

LLM が裏で Wiki を育てている間、人間がやることは 「ノートを読んで考え、新しい関連を見つけ、AI に次の指示を出す」 ことです。この作業では以下が効きます。

  • Hover Preview — 「あの概念ページに何が書いてあったか」をリンクをホバーするだけで確認、画面遷移なし
  • Backlinks パネル — 編集中のページを参照している全ノートが常時見える。「この概念は他にどこで使われているか」が即座に分かる
  • Graph View — クリックして拡大・フィルタしてオーファンを発見、といったインタラクティブな探索ができる
  • Canvas — 複数ノートを 2D 空間に並べて、構造化前のアイデアを練る

これらは 「書いた後に静的にレンダリングされる」MkDocs の世界では再現が難しい部分です。MkDocs はあくまで「読者向けの完成品を提供」するツールであり、「思考の途中状態を扱う」ためのものではありません。

LLM の連続更新に対するスループット

LLM が 1 つの ingest で 10〜15 ページを連続更新する場面では、Obsidian は書いた瞬間から全ページが相互参照可能な状態になります。MkDocs でも mkdocs serve のホットリロードがあるので致命的ではありませんが、ビルド成果物を見るステップが挟まる分、AI が育てた直後の Wiki を確認する体験は Obsidian の方が滑らかです。

結論: MkDocs でも作れるが、Obsidian は「考えるための UI」が組み込まれている

正直に言えば、LLM が育てる Wiki としてだけ見れば MkDocs / MkDocs Material は十分実用的です。実際、docs/ フォルダに Markdown を置いて Claude Code に管理させれば、Karpathy のシステムは MkDocs でも成立します。

差が出るのは、人間が日常的にその Wiki を開いて思考するときです。Backlinks・Graph・Canvas・Hover Preview といった「考えるための UI」が標準装備されている点が、Obsidian の唯一無二の強みです。

逆に言えば、

  • 公開ドキュメントとしても使いたい → MkDocs/Hugo（+ LLM）
  • 個人の思考環境として深く使いたい → Obsidian
  • 両方ほしい → Obsidian Vault を MkDocs/Hugo でビルドして公開（ファイル形式が同じなので両立可能）

という整理になります。Karpathy のシステムが Obsidian を採用しているのは、彼が「LLM に任せる部分」と「自分で考える部分」を明確に分けていて、後者のための UI として Obsidian が最適だったから、と理解するのが正確です。

5 分でできるセットアップ手順

Step 1: Obsidian をダウンロード

obsidian.md からインストールします。

Step 2: Vault を作る

起動後に「Vault」（デスクトップのフォルダと思えば OK）を作成します。名前は何でも構いません。ここに Claude Code がアクセスする Markdown ファイルが蓄積されます。

Step 3: Claude Code（デスクトップアプリ）を開く

メインチャット画面の「フォルダを選択」から、作成した Obsidian Vault を選択します。

Step 4: Karpathy のシステムプロンプトを貼る

Karpathy の Gist からプロンプトをコピーして貼り付けます。このプロンプトが AI を「規律を持った Wiki 管理者」に変える核心部分です。

Step 5: データを入れ始める

最初にある程度データを入れることで Wiki が育ち始めます。活用できる素材の例：

  • Notion からエクスポートしたファイル
  • 過去のメモやアイデア
  • 書いた記事・読んだ記事
  • YouTube の文字起こし
  • 他の AI に「わたしのことを教えて」と聞いて出てきた情報

使いこなすプロのコツ 4 選

コツ 1: Obsidian Chrome 拡張を使う

ブラウザで記事を読みながら「Obsidian に追加」ボタン 1 つで Markdown 変換して Vault に送れます。追加後は Claude に「さっき〇〇という記事を入れたから、Wiki に統合して」と言うだけで、他のノートとの関連を自動で見つけて繋げてくれます。

コツ 2: フォルダは 2 つに分ける

Karpathy も推奨しているように、Vault は用途別に分けるのがベストです。

  • 仕事・ビジネス用
  • プライベート・目標用

混在させると整理が難しくなります。

コツ 3: メガプロンプト作成に活用する

最も実用的な使い方の一つが「自分のことを全部知っている AI」にメガプロンプトを作らせることです。自分の文体・価値観・ターゲット読者・過去の記事パターンが全部 Wiki に入っているため、「わたしの次の記事のプロンプトを作って」と言うだけで、高精度な指示書が出来上がります。

コツ 4: 「孤児」を定期的にチェックする

Obsidian の「Orphans（孤児）」機能を使うと、他のノートとリンクされていない孤立ページが確認できます。Wiki の「弱い部分」＝まだ繋がっていない概念を発見するのに最適な方法です。

上級者向け: CLI ツール「qmd」

Wiki が大きくなってきたら、qmd というツールが便利です。

  • Markdown ファイル専用のローカル検索エンジン
  • BM25 ベクトルのハイブリッド検索 + LLM 再ランク付け
  • 全てオンデバイスで動作
  • CLI と MCP サーバー（Claude のツールとして使用可能）の両方に対応

小規模なら index.md で十分ですが、数百ページを超えてきたら導入を検討すると快適になります。

Vault の置き場所と運用パターン — docs/ か個人 Vault か

「Obsidian Vault を git リポジトリの docs/ に置いてプロジェクトごとに管理するのは現実的か」という疑問が出てきます。結論から言うと、現実的ではあるが、第二の脳としての本来の価値は per-project では出にくいです。

役割分担の整理

知識の種類置き場所ツール公開
プロジェクト固有の知識（仕様、ADR、runbook、設計判断）リポジトリの docs/MkDocs / Hugo / プレーン Markdownチームに公開
個人の知識処理活動（読んだ記事、概念、人物、領域横断の洞察）個人 VaultObsidian非公開（第二の脳）

役割の分かれ目は 「誰の頭の中の延長か」 です。

  • docs/ はプロジェクトの頭の中 — チーム共通の決定事項、誰が見ても同じ事実
  • Obsidian Vault は自分の頭の中 — 複数プロジェクト・複数ソース・複数年にわたる思考の蓄積

Karpathy が想定しているのは後者です。彼の Vault には「特定のプロジェクト」だけでなく「読んだ論文」「会った人」「思考実験」が混在しています。これは docs/ には収まりません。

per-project docs/ Vault の落とし穴

docs/ を直接 Obsidian Vault として開くこと自体は技術的に可能で、チーム Wiki としては機能します。ただし以下に注意が必要です。

  1. クロスプロジェクトリンクが切れる — プロジェクト A の claude-code.md とプロジェクト B の claude-code.md は別ファイルになり、[[Claude Code]] で繋がらない。第二の脳の本質的価値（プロジェクト横断の概念ネットワーク）が失われる
  2. [[wikilinks]] の GitHub 表示問題 — GitHub の Markdown レンダラーは [[wikilinks]] をリンクとして解釈しないため、Obsidian 設定で Use [[Wikilinks]] を OFF にして標準の [text](path.md) に統一するのが無難
  3. .obsidian/ の gitignore 戦略 — app.json などのチーム共通設定はコミット、workspace.json の個人レイアウトは ignore
  4. パブリックリポジトリの「半生のメモ」問題 — 第二の脳にはまだ整理されていない思いつきが混ざる。OSS リポジトリだと公開事故になる
  5. Vault 切替コスト — プロジェクトごとに Obsidian アプリを開き直す必要があり、Quick Switcher も Vault 内のみ

推奨パターン: 二層構造

最も現実的な運用は 「docs/ と個人 Vault を分けて、役割を明確にする」 ことです。

1
2
3
4
5
6
7
8
9

~/code/my-app/docs/        ← プロジェクト Wiki（公開、チーム共有）
~/code/my-blog/docs/       ← プロジェクト Wiki

~/SecondBrain/             ← 個人 Vault（非公開、第二の脳）
├── concepts/              ← 領域横断の概念
├── people/                ← 人物
├── sources/               ← 読んだ記事・論文
├── projects/              ← プロジェクトへのリンク or サマリー
└── log.md

各プロジェクトの docs/ にはチームに見せる事実だけを書く。個人 Vault には自分の理解・関連付け・思考を書く。プロジェクト固有の重要事項は個人 Vault の projects/my-app.md から [[my-app/docs/architecture]] のように参照する（またはプロジェクトリポジトリを Vault 内に symlink/submodule で取り込む上級パターンもあり）。

結論

  • プロジェクト固有のドキュメントは通常通り docs/ に書き、MkDocs / Hugo で公開する
  • 個人の知識処理活動の基盤として Obsidian を使う（プロジェクトを横断する第二の脳）
  • 両者は競合せず、異なる時間スケール・異なる読者を持つ別レイヤーとして併存させる

これが Karpathy の使い方とも整合し、現実のワークフローとしても破綻しない構成です。

個人 Vault の同期・バックアップ — GitHub private repo は現実解か

個人 Vault を運用する際、次に決めるのが「どうやって複数デバイス間で同期し、バックアップするか」です。特に開発者層では GitHub private repo + git による同期が王道の一つになっています。

Obsidian Vault の同期手段（人気順）

方式コスト強み弱み
Obsidian Sync（公式）$4-10/月E2EE、モバイル含む完璧な同期、リアルタイム有料、ベンダーロックイン
iCloud / Dropbox / OneDrive無料〜設定が極めて簡単履歴管理が弱い、競合に弱い
GitHub private repo + git無料履歴管理、ブランチ、バックアップ、開発者の慣れた UXモバイル同期が面倒、競合は手動解決
Syncthing（P2P）無料プライバシー重視、サーバー不要デバイス間でアプリ常駐が必要

GitHub private repo + git が選ばれる理由

1. 公式コミュニティプラグイン「Obsidian Git」がある

Obsidian Git はコミュニティプラグインのダウンロード数上位で、以下を自動化できます。

  • 一定間隔で自動 commit & push（例: 10 分ごと）
  • 起動時に pull、終了時に push
  • コミットメッセージは自動生成

「git を意識せずに使える」ところまで成熟しています。

2. 開発者の既存ワークフローと完全に親和

SSH 鍵、.gitignore、ブランチ、git log での過去参照など、毎日使っている道具がそのまま流用できます。「過去のあの日のメモを見たい」が git log -p で済むのは強力です。

3. GitHub private repo が無料・無制限

2019 年以降、GitHub の private repo は無料アカウントでも無制限に作れます。Obsidian Sync の年額 $48〜 を払わずに同等の機能が手に入ります。

4. 部分公開が容易

  • Vault 内の一部フォルダだけ別 public repo に submodule として切り出して公開
  • GitHub Pages で MkDocs / Hugo ビルドして公開
  • gist として個別ノートだけ共有

注意点と落とし穴

1. モバイル同期が最大の弱点

iOS / Android の Obsidian モバイルアプリは git をネイティブサポートしないため、モバイルで同期するには工夫が必要です。

  • iOS: Working Copy（買い切り、$20 程度）と Obsidian の File Provider 連携
  • Android: Termux で git pull / push、または Obsidian Git のモバイルサポート（実験的）
  • ハイブリッド: モバイルは Obsidian Sync、デスクトップは git、という使い分けも現実的

2. 競合解決は手動

複数デバイスで同時編集すると git の merge conflict が発生します。Obsidian Sync は競合を自動マージしてくれるので、このあたりは劣ります。対策は pull → edit → push のサイクルで運用、長時間放置しないことです。

3. 大きな添付ファイル

画像・PDF・録音ファイルを大量に貼ると repo が肥大化します。対策:

  • git-lfs を導入
  • .gitignore で attachments/ を除外して別途 Dropbox 同期
  • ノート量に対して画像が多くなければ素のまま運用でも数年は問題にならない

4. .obsidian/ の gitignore 設計

最低限の .gitignore 例:

# 個人のワークスペース状態
.obsidian/workspace.json
.obsidian/workspace-mobile.json

# キャッシュ
.obsidian/cache
.trash/

# OS
.DS_Store

.obsidian/plugins/ や .obsidian/themes/ はコミットすると別マシンで設定が即座に揃うため便利です。

5. プライバシーの限界

GitHub private repo は「他人から見えない」ですが、GitHub Inc.（Microsoft）には技術的にアクセス可能です。機密性の高いノート（資格情報、未公開のビジネス情報、個人的な日記）を入れる場合は:

  • 自前の Gitea / Forgejo ホスティング
  • E2EE が必要なら Obsidian Sync 一択
  • ノート単位で age や git-crypt で暗号化

という選択肢があります。

実際の運用構成例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

~/SecondBrain/                    ← Obsidian Vault
├── .git/                         ← github.com/<user>/second-brain (private)
├── .obsidian/
│   ├── plugins/                  ← コミット（マシン間で共有）
│   ├── themes/                   ← コミット
│   └── workspace.json            ← .gitignore（個人の状態）
├── concepts/
├── sources/
├── people/
├── log.md
└── attachments/                  ← git-lfs or .gitignore

Obsidian Git プラグインで 5〜10 分ごとに自動コミット・プッシュ。デスクトップ間（Mac / Linux / Windows）はこれで完結。モバイルは Working Copy 連携か、参照のみの妥協。

結論

  • 開発者ユーザーには最も一般的な選択肢の一つ — 無料で履歴・バックアップ・部分公開がすべて手に入る
  • Obsidian Git プラグインの存在で運用コストは大幅に下がっている
  • モバイルへのこだわりがなければ GitHub private repo + Obsidian Git は鉄板構成
  • 本格的にモバイルも使いたいなら Obsidian Sync の方が楽（年 $48 程度の価値はある）

Claude Code との組み合わせでも、Vault が git 管理されていれば「この概念ページの過去バージョンを見せて」「先月から今月にかけて変わった点を要約して」といった質問が可能になり、第二の脳に時間軸が加わります。

このシステムが向かない人

全員におすすめできる万能ツールではありません。

  • 視覚化が好きでない人 — Obsidian の Graph View（ノートの繋がりを図で見る機能）の恩恵を受けにくい
  • 継続的なメンテナンスが苦手な人 — 「記事を読んだら Obsidian に追加 → Claude に統合させる」という習慣が必要。データを入れ続けないと Wiki は枯れていく
  • ストレージが気になる人 — Markdown ファイルと画像がローカルに蓄積される

まとめ

Claude Code + Obsidian の「AI 第二の脳」は、使えば使うほど賢くなる「育ち続けるシステム」です。

従来の RAG が毎回答えを「発掘」するのに対して、このシステムは答えを「育て続ける」仕組みです。Obsidian に 1 つ情報を入れるたびに、AI がそれを既存知識と統合し、Wiki 全体を更新します。

「AI 第二の脳」は単なる比喩ではなく、実際に機能するシステムとして構築できます。Karpathy の Gist にあるプロンプトと Obsidian さえあれば、今日から始められます。