【Obsidian x Claude Code②】Vaultフォルダ構成と指示書を書く

前回はObsidianとClaude Codeで毎朝のDaily Briefを作る概要を書いた。 第2回は土台になるVault設計について。 フォルダ分けとVault直下のCLAUDE.mdに何を書いたかをまとめる。

参考サイトを元に、実際にVaultの設計を作ってみた。 参考: How to Build an Obsidian Knowledge Vault That Gets Smarter Every Day

1. Vault全体のフォルダ構成

ObsidianVault/
├── CLAUDE.md         # Vaultの取り扱い指示書 (Claude Code用)
├── inbox/            # 自動キャプチャの着地点
├── notes/            # 処理済みの整理ノート (1ソース1ファイル)
├── ideas/            # 自分の出力 (思考・観察・ボイスメモ)
├── projects/         # 進行中プロジェクトのメモ
└── briefs/           # Claudeが毎朝書くDaily Brief

Obsidian運用事例だと10フォルダ前後に分ける例もよく見るけど、最初から細かく分けると挫折しそうなので、参考サイトを参考に最小限で分けた。

2. 各フォルダの意味

「他人の入力」と「自分の出力」を混ぜないというルールも参考サイトのまま使用する。

• 他人の入力: inbox/ notes/
• 自分の出力: ideas/ projects/
• AIの出力: briefs/

混ぜると半年後に「自分が書いたメモ」と「人の記事の引用」と「AIの出力」の見分けがつかなくなる。見分けがつかないと、ClaudeがVaultを読むときも文脈を取り違える。

3. CLAUDE.mdに書いた6セクション

CLAUDE.mdはClaude Codeが会話開始時に自動で読み込んでくれるファイル。

Claude Codeは起動したカレントディレクトリから親方向にたどってCLAUDE.mdを探すので、Vaultのルート (Obsidianで開いたときに最初に見えるところ) に置いておけば、Vault配下のどこでclaudeを起動しても拾ってくれる。

ただし公式ドキュメントにあるとおり、CLAUDE.mdの内容はシステムプロンプトではなくユーザーメッセージとして渡される「コンテキスト」なので、絶対に従ってもらえる設定ではない。書いたことを完全に守らせるものではないと思って書く。

Vaultが小さいうちは1ファイルで完結させる方が見やすい。

3-1. 自分の役割

何者で、どんな仕事をしていて、いまのフォーカスは何かを2〜3段落で書く。Claudeに「誰のVaultを読んでいるのか」を最初に伝える。

- 役割: Webエンジニアで技術ブログを運営している
- 現在のフォーカス: Next.js / Astro / Tailwind v4 の習熟、Claude Code を活用して
  思考と作業を拡張する仕組みづくり
- 2026年の目標: stock-blog を月20本出す、ナレッジシステムを稼働させる

3-2. 現在のプロジェクト

Active / Stuck on / Next milestoneの3つに分けて、いま動かしているプロジェクトと、止まっているもの、次のマイルストーンを書く。「今日何に集中すべき?」と聞いたとき、Claudeはここを参照する。

3-3. このVaultの使い方

上で書いたフォルダの意味を、Claude向けに説明する。

- inbox/ — 自動キャプチャの着地点。未整理でよい。迷ったらここに入れる
- notes/ — 処理済みの記事・ハイライト。1ソース1ファイル
- ideas/ — 自分の出力 (思考・観察)
- projects/ — 進行中プロジェクトのメモ
- briefs/ — 毎朝6:00にClaudeが自動生成するDaily Brief

3-4. Claudeに期待する振る舞い

「Claudeに何をしてほしいか」を箇条書きで宣言する。

- 連結を見つけて指摘してほしい: 私が気づいていない、Vault内の記事と最近の関心の繋がりを示す
- 同意する前に前提を疑ってほしい: 私が言ったことが過去のメモと矛盾していたら、根拠つきで指摘する
- 「今日何に集中すべき?」と聞かれたら、Vaultの文脈から答える
- 過去の自分との矛盾を flag する
- 朝のBriefではタスクではなく問いを返す

ここを書くと、Claudeの返事が一般論から「自分のVaultに沿った返事」に変わる。

3-5. 文体・出力ルール

Claudeが文章を書くとき (Brief、メモ、リプライ) のルール。

- 応答は日本語のですます調を基本にする
- stock-blogのブログ記事を生成するときは「だ・である調」
- 日本語の中に半角スペースを入れない
- 事実だけを淡々と書く。感想・心情・読者への呼びかけは入れない

出力をブログに使用することがあるので追記した。

3-6. 今週ハマっていること

毎週月曜の朝に5分だけ自分で更新する「What I Am Reading and Thinking About」セクション。 今ハマっているテーマ、抱えている問い、答えを探していることを5〜7行書く。

### 2026-05-19 (今週)
- Obsidian + Claude Codeを使った「外部記憶として育てるナレッジ Vault」の運用設計
- 自作スキルとサブエージェント連携の精度向上
- stock-blogと闘病ブログの更新
- Next.jsの勉強

CLAUDE.mdの中で唯一「今」の情報が入る場所。Daily BriefのPATTERNやQUESTIONはここから関心の中心を読み取ってくる。

4. 「迷ったらinboxに入れる」

inbox/は「未整理でよい」場所。Web Clipperで取り込んだ記事、思いついたこと、後で考えるネタ、迷ったものは全部ここに入れる運用にする。

整理しようとして手が止まるくらいなら、入れて先に進むようにしたい。 挫折しないようにゆるく...！

「整理は後でやる」と決めると、整理しないままになるのが普通だけど、Vaultはそれでよい。整理は手動でやらず、毎朝のDaily Briefに「これはnotes/に昇格すべきか」を判断してもらう設計にした。

5. inbox→notesの昇格判断

1週間運用してわかったこと。inboxの記事を全部notes化する必要はない。 3つの基準で振り分ける。

notesに上げるときは1ファイルに3つの要素を書く。

1. 元記事の情報 (フロントマター)
2. ハイライト3〜5箇所 (直接引用 + 1行の自分のコメント)
3. 関連する自分のideasや他のnotesへのリンク ([[...]]記法)

サンプル (架空):

---
title: Claude Code Skillの作り方
source: https://
captured: 2026-05-16
processed: 2026-05-17
tags: [claudecode, skills]
---
 
## なぜ保存したか
descriptionの書き方が自分のblog-md-creator改善に直接効く。
 
## ハイライト
 
> descriptionが曖昧だと、Claude Codeが「いつこのSkillを使うべきか」を
> 判断できず、トリガーされない
 
→ blog-md-creator の description に「いつ使うか」をもっと明示する。
 
## 関連
- [[ideas/2026-05-15-skill-hoge]]
- [[notes/hoge]]

ハイライトは引用 (15語以内) + 自分のコメント1行。 元記事のURLが残っているので、全文コピペはしない。

6. Daily Briefが整理を促してくれる

inbox→notesの整理は最初手動で全てやろうとすると挫折すると思ったのでDaily Brief側から促してもらうようにした。Brief自身が「この記事はnotesに昇格すべきでは？」と何度も指摘してくれる。

考えるポイントは「フォルダをいくつ作るか」ではなく、「Briefが指摘材料に使える状態に置けているか」だと思う。具体的には、

• inbox/にWeb記事が入っている → Briefが連結を出せる
• ideas/に自分の問いや観察が残っている → Briefが過去の自分と現在の自分を比較できる
• CLAUDE.mdの「今週ハマっていること」が更新されている → BriefのPATTERNが今の関心を踏まえてBriefを出力してくれる

7. 残課題

• notes/への昇格を半自動化する余地: Briefが指摘 →まだ手動運用
• ideas/の運用が薄い: 自分の思考を文字に落とすルートが固まっていない。ボイスメモ → Vaultの連携が次の検討対象

参考リンク:

• Obsidian (公式)
• Claude Code: How Claude remembers your project (memory)
• Obsidian Help: Internal links
• Obsidian Help: Create a vault