この記事では、Windows環境のClaude Codeで実際に試した結果をもとにまとめています。
ObsidianのVaultを開いたとき、「このノート、どこに置けばいいんだっけ？」と迷った経験はないだろうか。フォルダ構成は一度決めると変えにくいのに、自分にとってしっくりくる構成が見つからず放置してしまう。そこで、Claude Codeに「Obsidianのフォルダ構成を考えて」と頼むだけで、どこまで使えそうな構成ができるか試してみた。
この記事で確かめること
Claude Codeに「フォルダ構成を決めて」とだけ頼み、出てきた案をそのまま評価する。そのあと修正指示を出して改善させ、「頼むだけでどこまで使える構成ができるか」を確かめる。
目指すのは、ノートを迷わず置けて後からサッと見つけられる、運用し続けやすい構成。分類基準があいまいだったり階層が深すぎたりすると逆効果になる。
やりたいこと——どういうフォルダ構成にしたいか
Obsidianは自由度が高い。フォルダを作っても作らなくても動くし、タグだけで管理することもできる。ただ、自由すぎるあまり「どういう単位でフォルダを切るか」「深さはどのくらいにするか」が決まらないままノートだけが増えていくことはよくある。
よくある失敗パターンがある。
- 深すぎる階層: 「仕事 > プロジェクト > 2024 > クライアントA > 会議議事録」のように掘り下げすぎると、ノートを置くたびに迷う
- 分類基準の混在: 「カテゴリ別」のフォルダと「日付別」のフォルダが同居していると、新しいノートをどちらに置くか毎回判断しなければならない
- 空フォルダの放置: 「いつか使うかも」と作ったフォルダが空のまま増え、かえって探しづらくなる
理想はシンプルだ。ノートを迷わず置けて後からサッと見つけられること。運用ルールを暗記するのではなく、フォルダ構成自体が自然に導いてくれる状態がいい。
Step 1: 最初の依頼——Vaultのフォルダ構成を考えて
まずはClaude Codeにシンプルに頼んでみた。依頼文はこうだ。
ObsidianのVaultのフォルダ構成を考えてほしい。
用途：ブログのネタ帳、読書メモ、日記、プログラミング学習メモ
ノート数：今は50件程度だが増える予定
Windows環境で使っている
浅めの階層が好み（3階層まで）
Beforeの状態は、「Inbox」「メモ」「日記」の3フォルダだけがあるシンプルな構成。ノートはInboxにすべて放り込まれていて、分類が追いついていない状況だ。
期待していたのは「用途ごとに分けつつ共通のInboxがある」程度の構成。PARAやZettelkastenのような特定の手法は指定していない。まずはClaude Codeが何を出してくるか見たかった。
Step 2: 最初の結果——提案された構成
Claude Codeが提案したフォルダ構成はこうなった。
Vault/
├── 00_Inbox/ ← 受け皿（未分類ノート）
├── 01_Blog/ ← ブログネタ・下書き
├── 02_Reading/ ← 読書メモ
├── 03_Diary/ ← 日記
├── 04_Dev/ ← プログラミング学習メモ
├── 05_Archive/ ← 古いノート
└── Templates/ ← テンプレート
良かった点
- フォルダ名の先頭に連番（00、01…）がついていて、エクスプローラーで開いたときに並び順が固定される。これは地味に嬉しい工夫
- 「Inbox → 各用途フォルダ → Archive」の流れが自然で、ノートのライフサイクルを想像しやすい
- 階層が1段で止まっていて、迷う余地が少ない
気になった点
05_Archiveの運用ルールが不明確。「いつアーカイブに移すのか」を自分で決めないと、結局Inboxと同じく溜まり場になる- 読書メモとブログネタの境界があいまいで、「読んだ本からブログ記事を書く」ケースでどちらに置くか迷いそう
Templatesが番号なしで最後に置かれているが、これも連番に統一した方がすっきりする
連番のおかげでフォルダの並びが安定し、階層も1段で済むので、ノートの置き場で迷う余地は少ない。ただ、自分の使い方とすり合わせるにはもう一歩必要だと感じた。
Step 3: 修正指示——自分の用途に合わせる
最初の案をベースに、いくつか修正を指示した。
以下の点を修正してほしい：
1. 読書メモからブログ記事を書くことが多いので、
「02_Reading」と「01_Blog」の関係を明確にして
2. Archiveの移行ルールを決めてほしい
（「3ヶ月以上更新していないノート」等）
3. Templatesも連番に含めて
4. 将来的に「仕事」カテゴリを追加する余地を残して
修正の狙いは、自分の使い方（読書→ブログ執筆の流れ）を構成に反映させること。特定の手法（PARAやZettelkasten）への変更は指示していない。今の構成をベースに、実運用に寄せていく方向で頼んだ。
大きな変更ではなく、既存の骨組みを微調整する範囲で収まるだろうと思っていた。
Step 4: 修正後の結果
Claude Codeが出した修正後の構成がこちら。
Vault/
├── 00_Inbox/ ← 受け皿（未分類）
├── 01_Blog/
│ ├── Ideas/ ← 記事アイデア（読書メモ由来もここ）
│ ├── Drafts/ ← 執筆中
│ └── Published/ ← 公開済み
├── 02_Reading/ ← 読書メモ（そのまま記録として残す）
├── 03_Diary/ ← 日記
├── 04_Dev/ ← プログラミング学習
├── 05_Work/ ← 将来用（現在は空）
├── 06_Archive/ ← 3ヶ月以上未更新のノート
├── 07_Templates/ ← テンプレート
└── _Resources/ ← 画像・添付ファイル
変わったポイント
01_Blogが3つに細分化され、「読書メモ → Ideas → Drafts → Published」の流れが明確になった06_Archiveに「3ヶ月以上未更新」という目安がついた05_Workが将来用として追加され、空フォルダでも「いつか使う」という意図が明示されている_Resourcesで画像等のメディアファイルを一元管理する提案も追加された
個人的には、Blogの細分化が一番効いている。新規ノートをどこに置くかの判断が「IdeasかDraftsか」で済むようになり、公開済み記事と下書きが混ざることもない。画像の置き場所が_Resourcesに固定されるのも、ファイルが散らばりにくい。
一方で、Blogが2階層目に入ったことで、唯一の「深い」部分になった。ただしBlog内の3フォルダは迷いようがない分類なので、探す手間は増えなかった。
なお、_Resourcesによる一元管理や「3ヶ月未更新でArchive」という目安は、あくまで今回の提案の一例。Claude Codeが提案してくれた運用案であり、これが万人に共通する正解というわけではない。
Step 5: どこまで頼むだけでできた？
この実験でClaude Codeが出してくれた部分と、こちらが判断した部分を整理する。
頼むだけでできたこと
- フォルダの骨組み（連番付きの用途別分類）
- 命名規則の統一（
00_Inboxのようなゼロパディング） - Archiveの移行目安（3ヶ月未更新という一案）
- Blog内のワークフロー細分化（Ideas → Drafts → Published）
_Resourcesのようなメディア管理フォルダの提案
人が判断したこと
- 「読書メモとブログの関係」をどうするか（自分の執筆スタイルに合わせた）
- 将来の「仕事」カテゴリをいつ追加するか
- Archiveの3ヶ月という期間が自分に合うか（今のところ様子見）
やり取りの回数: 2回（最初の依頼 + 修正指示）
2回のやり取りでここまでまとまった。ただし、既存ノートの移行方針など、自分で決める部分は残る。
最終結果
完成した構成をあらためて示す。
Vault/
├── 00_Inbox/
├── 01_Blog/
│ ├── Ideas/
│ ├── Drafts/
│ └── Published/
├── 02_Reading/
├── 03_Diary/
├── 04_Dev/
├── 05_Work/ ← 将来用
├── 06_Archive/
├── 07_Templates/
└── _Resources/
この構成でしばらく運用してみて、違和感が出たらまたClaude Codeに修正を頼めばいい。フォルダ構成は「一度決めたら変えられない」わけではなく、「変えるのは手間」というだけ。最初の依頼文で自分の用途を書き添えておくと、出てくる案が変わってくる。
関連する記事として、タグの命名ルール整理やリンク構成の整理も今後取り上げる予定だ。フォルダ構成が決まったら、次は「タグをどう付けるか」「ノート同士をどうつなぐか」が課題になってくる。
この検証の振り返り
依頼→結果→修正→完成の流れを通して感じたことをまとめる。
依頼文と修正のコツ
最初の依頼文で「用途」「ノート数の規模」「好みの階層の深さ」を伝えたのがよかった。漠然と頼むより、前提条件をいくつか書き添えるだけで出力が変わる。特に「用途」は書いておくといい。
修正は最小限で済んだ。骨組みは最初の案で良かったので、「ここだけ直して」というピンポイントの指示で十分だった。全く別の構成に作り直すより、良かった部分を活かす方が早い。
試すなら、まず依頼文に自分の用途を3〜5個書き出し、階層の好みも指定しておく（「2階層まで」など）。出てきた案のうち、合わない部分だけ修正指示を出せばいい。
この構成が向いていそうな人・向かなそうな人
用途がはっきり分かれている人（ブログ・読書・学習など）には向く。「このノートはどのフォルダ？」の迷いが減り、分類に頭を使わなくて済む。一方、日付ベースで日記をつけるのが主目的の人や、タグ中心でフォルダをあまり使わない人には、別のアプローチの方が合うかもしれない。
まとめ
Claude Codeに2回頼んで、Obsidianのフォルダ構成の骨組みをまとめることができた。連番による並び制御、用途別の分類、Archiveの移行目安など、自分一人で悩むと決めきれない要素を短期間で出してくれる。まずは依頼文に自分の用途を書き添えて、出てきた案をベースに微調整する——骨組みが短時間でできるので、合わない部分だけ後から直せばいい。
今回の結果は、利用モデル、接続先、時期、環境によって変わる可能性があります。再現する時は検証条件もあわせて確認してください。
