Claude Codeに頼むだけで、Obsidianのフォルダ構成はどこまで決められる？

この記事では、Windows環境のClaude Codeで実際に試した結果をもとにまとめています。

ObsidianのVaultを開いたとき、「このノート、どこに置けばいいんだっけ？」と迷った経験はないだろうか。フォルダ構成は一度決めると変えにくいのに、正解が見つからず放置してしまう。そこで、Claude Codeに「Obsidianのフォルダ構成を考えて」と頼むだけで、どこまで実用的な構成ができるか試してみた。

この記事で確かめること

Claude Codeに「フォルダ構成を決めて」とだけ頼み、出てきた案をそのまま評価する。そのあと修正指示を出して改善させ、「頼むだけでどこまで使える構成ができるか」を確かめる。

目指すのは、ノートを迷わず置けて後からサッと見つけられる、運用し続けやすい構成。分類基準があいまいだったり階層が深すぎたりすると逆効果になる。

やりたいこと——どういうフォルダ構成にしたいか

Obsidianは自由度が高い。フォルダを作っても作らなくても動くし、タグだけで管理することもできる。その自由さが逆に厄介で、「どういう単位でフォルダを切るか」「深さはどのくらいにするか」が決まらないままノートだけが増えていく。

よくある失敗パターンがある。

深すぎる階層: 「仕事 > プロジェクト > 2024 > クライアントA > 会議議事録」のように掘り下げすぎると、ノートを置くたびに迷う
分類基準の混在: 「カテゴリ別」のフォルダと「日付別」のフォルダが同居していると、新しいノートをどちらに置くか毎回判断しなければならない
空フォルダの放置: 「いつか使うかも」と作ったフォルダが空のまま増え、かえって探しづらくなる

理想はシンプルだ。ノートを迷わず置けて後からサッと見つけられること。運用ルールを暗記するのではなく、フォルダ構成自体が自然に導いてくれる状態がベストだ。

Step 1: 最初の依頼——Vaultのフォルダ構成を考えて

まずはClaude Codeにシンプルに頼んでみた。依頼文はこうだ。

ObsidianのVaultのフォルダ構成を考えてほしい。
用途：ブログのネタ帳、読書メモ、日記、プログラミング学習メモ
ノート数：今は50件程度だが増える予定
[Windows環境で使っている](/claude-codewindows-3/)
浅めの階層が好み（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が番号なしで最後に置かれているが、これも連番に統一した方がすっきりする

基礎的な骨組みはしっかりしている。ただ、自分の使い方とすり合わせるにはもう一歩必要だと感じた。

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内の細分化は、自分の執筆プロセス（アイデア出し→下書き→公開）にそのまま合致している。

一方で、Blogが2階層目に入ったことで、唯一の「深い」部分になった。ただしBlog内の3フォルダは迷いようがない分類なので、実用上の問題はなさそうだ。

Step 5: どこまで頼むだけでできた？

この実験での「頼むだけでできたこと」と「人の判断が必要だったこと」を整理する。

頼むだけでできたこと

フォルダの骨組み（連番付きの用途別分類）
命名規則の統一（00_Inboxのようなゼロパディング）
Archiveの移行ルール案（3ヶ月未更新）
Blog内のワークフロー細分化（Ideas → Drafts → Published）
_Resourcesのようなメディア管理フォルダの提案

人が判断したこと

「読書メモとブログの関係」をどうするか（自分の執筆スタイルに合わせた）
将来の「仕事」カテゴリをいつ追加するか
Archiveの3ヶ月という期間が自分に合うか（今のところ様子見）
提案された構成が自分にとって使いやすいかどうかの最終評価

やり取りの回数: 2回（最初の依頼 + 修正指示）

2回のやり取りで実用的な構成ができた。ただし、「自分の用途に合うか」の最終確認と、既存ノートの移行方針は自力で考える必要がある。ここはAIに丸投げできない部分だ。

最終結果

完成した構成をあらためて示す。

Vault/
├── 00_Inbox/
├── 01_Blog/
│   ├── Ideas/
│   ├── Drafts/
│   └── Published/
├── 02_Reading/
├── 03_Diary/
├── 04_Dev/
├── 05_Work/（将来用）
├── 06_Archive/
├── 07_Templates/
└── _Resources/

この構成でしばらく運用してみて、違和感が出たらまたClaude Codeに修正を頼めばいい。フォルダ構成は「一度決めたら変えられない」わけではなく、「変えるのは手間」というだけ。最初の依頼文で自分の用途（ブログ運営、読書メモ、日記、学習）をきちんと伝えておくことが、良い構成を出すコツになる。

関連する記事として、タグの命名ルール整理やリンク構成の整理も今後取り上げる予定だ。フォルダ構成が決まったら、次は「タグをどう付けるか」「ノート同士をどうつなぐか」が課題になってくる。

この検証の振り返り

依頼 → 結果 → 修正 → 限界の確認 → 完成。この流れを一通り体験して感じたことをまとめる。

依頼文のコツ

最初の依頼文で「用途」「ノート数の規模」「好みの階層の深さ」を伝えたことが功を奏した。漠然と「フォルダ構成を決めて」と頼むよりも、自分の前提条件をいくつか書き添えるだけで出力の質が変わる。特に「用途」は必須情報だ。

修正指示のコツ

修正は最小限にとどめた。構成の骨組み自体は最初の案で良かったので、「ここだけ直して」というピンポイントの指示で十分だった。全く別の構成に作り直す指示を出すより、良かった部分を生かす方が早く仕上がる。

限界の整理

Claude Codeは「一般的に使いやすい構成」を出すのは得意だが、「あなた個人の運用習慣に合うか」は判断できない。既存ノートが大量にある場合の移行方針も、一人ひとり違うのでAIに一概には決められない。ここが「頼むだけでできた範囲」と「人が確認すべき範囲」の境界線だ。

初心者が試すときのポイント

最初の依頼文に自分の用途（3〜5個）を書き出す
階層の深さの好みを指定する（「2階層まで」など）
結果を見て「ここは自分の使い方と合わない」と思った部分だけ修正指示を出す
最終確認は人間が行う

頼むだけでここまでは進められた。ただし最後は人が確認する。

まとめ

Claude Codeに2回頼むだけで、ObsidianのVaultフォルダ構成の骨組みは実用的なレベルまで仕上がった。連番による並び制御、用途別の分類、Archiveの移行ルールまで含めて提案してくれる。一方で、自分の運用習慣との適合性や既存ノートの移行方針は、最終的に人が確認する必要がある。まずは依頼文に自分の用途を書き添えて、出てきた案をベースに微調整する——この進め方が一番手堅い。

今回の結果は、利用モデル、接続先、時期、環境によって変わる可能性があります。再現する時は検証条件もあわせて確認してください。

Claude Codeでどこまでできる？