Vaultのノートが200を超えたあたりで、開くたびにため息をつくようになりました。フォルダは10個バラバラ、タグは50種類ぐらいあって何が何やら。この状態から脱出するには、整理手法を勉強して手作業で……と考えると気が遠くなります。そこでClaude Codeに「このVaultを整理して」と頼んでみました。フォルダ構成、タグ統合、リンク補完まで6ステップでどこまで進むか検証します。

この記事で確かめること

散らかったObsidian Vaultを、Claude Codeに整理を頼むだけでどこまで綺麗にできるか。フォルダ構成の再設計、タグの統合・階層化、ノートの自動分類、リンクの補完、フロントマターの標準化――この5本柱で検証します。

テスト環境はWindows 11、Claude Code。Vaultの規模はノート約200本、フォルダ10個、タグ50種類という「手に負えなくなった」状態を想定しました。

前提：使う環境とVaultの状態

Windows 11でClaude Codeを使える状態が前提です。未導入の場合は、先にインストールと初期設定を済ませておいてください。

検証に使うテストVaultの中身はこんな感じです。

• ノート数：約200本
• フォルダ：10個（「メモ」「アイデア」「仕事」「学習」「日記」「下書き」「参考」「プロジェクト」「アーカイブ」「未分類」）
• タグ：約50種類（命名バラバラ。「仕事」「work」「ビジネス」が混在、「アイデア」「idea」「ideas」が共存）
• リンク：一部のノートにしかリンクがなく、孤立ノートが多数
• フロントマター：あるノートとないノートが混在

フォルダ名もタグも、その時の気分でつけてしまった感が強い状態です。「メモ」と「未分類」の違いがもう分からない。この混沌を前に、Claude Codeにどう指示を出すか見ていきます。

Step 1：Vault全体の現状を分析してもらう

まずはVaultの現状把握からです。次のような依頼文を出しました。

このVaultにあるすべてのMarkdownファイルをスキャンして、フォルダ構成、ノート数、タグの一覧と使用頻度、ノート間リンクの状況を分析してください。特に孤立ノート（他のノートからリンクされていないノート）がいくつあるか数えてください。

この頼み方にした理由は、「まず全体像を把握する」ことが整理の第一歩だからです。整理手法を知らなくても、現状が分かれば次の一手が見えてきます。

結果は数秒で出ました。

• ノート数：197本
• フォルダ：10個
• タグ：53種類（使用頻度1回のタグが30種類以上）
• 孤立ノート：89本（全体の約45%）
• リンク数：合計62本（ノート間リンクが貼られているのは約3割）

数値は正確でした。ファイルの読み取りはClaude Codeの得意領域で、全ファイルを漏れなく走査しています。ただ、「で、どうすればいいの？」という提案までは出てきません。ここは別途依頼する必要があります。

ここで一つコツをお伝えすると、依頼文は「分析してください」だけでなく、具体的に「何を分析してほしいか」を列挙した方が精度が上がります。「タグの使用頻度」「孤立ノートの数」のように項目を指定すると、見落としが減ります。

Step 2：フォルダ構成の提案を出してもらう

現状が分かったところで、フォルダの再構成を頼みます。PARA方式やZettelkastenといった手法の名前を出さずに、こんな依頼文を投げてみました。

このVaultのノートを分析して、整理しやすいフォルダ構成を提案してください。現在の10個のフォルダは運用しきれていないので、ノートの内容に基づいて最適なフォルダ構成案を出してください。各フォルダの役割も説明してください。

Claude Codeからは次のような提案が返ってきました。

• Inbox：新しく作ったノートをまず置く場所
• Projects：進行中のプロジェクトに関連するノート
• Resources：参照資料や学習メモ
• Archive：完了したプロジェクトや古いノート
• Daily Notes：日記やジャーナリング

これはPARA方式（Projects, Areas, Resources, Archive）の簡易版に近い構成です。手法を指定しなかったのに、ノートの内容から自然と似た構造が提案されました。

5フォルダというシンプルさは初心者向けとして悪くありません。実際に既存のフォルダ分けよりも運用しやすいはずです。ただし「Areas（責任領域）」が抜けている点に注意が必要です。健康、家計、趣味など継続的な関心事を置く場所がありません。

人が確認すべきポイントは二つ。提案されたフォルダ構成が自分の使い方に合っているか、ノート数に対してフォルダ数が適切か（200本のノートを5フォルダで運用できるか）です。

Step 3：タグの統合と整理を実行する

タグは整理で最もつまずきやすい部分です。「仕事」「work」「ビジネス」のような重複タグに加え、使ったことがあるかも分からないタグがたくさんあります。

依頼文です。

Vault内の全タグを分析して、意味が同じまたは似ているタグを統合してください。統合後は階層タグ（例：仕事/進行中、仕事/完了）の形式に整理し、各タグに何本のノートが紐づいているか一覧を出してください。

結果を見ると、

統合前（一部抜粋）：
– 仕事 / work / ビジネス / business → 仕事に統合（合計28本）
– アイデア / idea / ideas / 思いつき → アイデアに統合（合計19本）
– 学習 / learning / 勉強 / study → 学習に統合（合計22本）

階層タグへの整理：
– 仕事/進行中、仕事/完了、仕事/提案
– アイデア/未検証、アイデア/採用済み
– 学習/進行中、学習/完了

日本語タグの扱いは自然でした。日本語と英語が混在していたタグはすべて日本語に統合されています。Vault全体が日本語で書かれていることを考慮した結果でしょう。

ただし、人の目で確認が必要だった点があります。「思いつき」と「アイデア」は本当に同じ意味か？という判断です。読み返してみると「思いつき」には断片的なメモが多く、「アイデア」にはある程度形になったアイデアが多かったため、分けておいた方が後で便利だったかもしれません。このように、タグの統合では「ニュアンスの違い」をAIがどこまで汲み取れるかが境界線になります。

誤った統合は見られませんでしたが、統合の基準が「表記ゆれ」中心で、「意味の近さ」まで踏み込んでいないケースが数件ありました。ここは人が最終確認するのが確実です。

Step 4：ノートの自動分類と移動を試す

ここからが本番です。ノートの内容を読み取って、適切なフォルダへ自動分類させる検証です。

Step 2で提案したフォルダ構成に基づいて、各ノートを適切なフォルダに分類してください。ノートの内容とタイトルから判断して、各ノートがどのフォルダに属するかを決定し、実際にファイルを移動してください。

結果は、約200本のノートのうち7割程度が妥当なフォルダに分類されました。残り3割には「これはResourcesじゃなくてProjectsでは？」と感じるものが含まれていました。

分類の精度を細かく見ると、

• Inboxに分類されたノート：34本のうち28本が妥当（6本は別フォルダが適切）
• Projectsに分類されたノート：41本のうち32本が妥当（9本はResources寄り）
• Resourcesに分類されたノート：52本のうち45本が妥当（7本はArchive寄り）
• Archiveに分類されたノート：38本のうち35本が妥当（3本はまだアクティブ）
• Daily Notesに分類されたノート：32本全てが妥当

誤分類の例を挙げると、「読書メモ_生産性本」がProjectsに分類されていました。読書メモは通常Resourcesに属しますが、「生産性向上プロジェクト」の文脈で引用が含まれていたためProjectsと判断されたようです。

一番気をつけるべきは、意図しない移動によるリスクです。「実際にファイルを移動して」と頼むと、元のフォルダからファイルが消えて新しいフォルダに移ります。間違った分類だった場合、元に戻す手間がかかります。

対策としては、移動の実行前に「分類案だけを出力して、移動はまだしないで」と指示するのが安全です。分類案を人が目視確認してから、「この案で移動して」と指示を出す手順にすると、誤操作を防げます。

ここはこの検証で最も「人の確認」が必要な領域です。自動分類の精度は7割程度で、残り3割をどう扱うかが整理の品質を左右します。

Step 5：リンクの補完とMOC（Map of Content）の作成

ノート間のリンク整理と、全体を見渡すためのMOC（Map of Content）作成を頼みます。

孤立ノート（他のノートからリンクされていないノート）を特定して、内容が関連するノート同士をリンクで結んでください。また、Vault全体の主要トピックごとにMOC（Map of Content）ノートを作成してください。

孤立ノートの発見はStep 1と同様に正確でした。89本の孤立ノートがリストアップされました。

リンクの補完については、Claude Codeが約40本のノートに新しいリンクを追加しました。たとえば「Obsidianの基本操作」ノートに「[[Markdownの書き方]]」「[[ウィキリンクの使い方]]」へのリンクが追加されています。内容を見る限り、関連性は概ね妥当です。

ただし、関係ないノート同士がリンクされたケースもありました。「Windowsのショートカット設定」というノートに「[[Macのキーボード設定]]」へのリンクが追加されたのですが、このVaultには存在しないはずのノート名でした。幻覚（ハルシネーション）で存在しないノートへのリンクを作ってしまった例です。

MOCの自動生成結果です。

「仕事MOC」「学習MOC」「アイデアMOC」の3本が作成され、それぞれ関連ノートがリスト形式で整理されていました。「仕事MOC」には進行中のプロジェクトノートがまとまっており、悪くない出来です。

人が確認すべきポイントは二つ。リンク先のノートが実際に存在するかどうか、とリンクの文脈が自然かどうかです。特にMOCは「目次」として使うものなので、ノートの選別に漏れがないか人の目で確認するのが確実です。

Step 6：フロントマターの標準化

最後のステップは、各ノートのYAMLフロントマターの統一です。これはClaude Codeが得意な領域で、比較的きれいに仕上がりました。

すべてのノートのフロントマターを次の統一フォーマットに変換してください。既存のフロントマターがある場合は内容を引き継ぎ、ない場合は新規作成してください。

統一フォーマットの定義:

---
title: "ノートのタイトル"
date: YYYY-MM-DD
tags: [タグ1, タグ2]
aliases: [エイリアス名]
status: inbox | active | completed | archived
---

変換前と変換後の例:

変換前:

---
created: 2025/3/15
tag: 仕事
---

変換後:

---
title: "プロジェクトAの進捗メモ"
date: 2025-03-15
tags: [仕事/進行中]
aliases: []
status: active
---

日付フォーマットが「2025/3/15」から「2025-03-15」に統一され、tag（単数形）がtags（複数形・リスト形式）に変換されています。statusフィールドは新規追加で、ノートの状態が一目で分かるようになりました。

エッジケースの処理も確認しました。フロントマターがなかったノートには新規作成され、titleがノートの見出し行から自動抽出されていました。ただし、ノートの1行目が見出し（# タイトル）になっていない場合、titleが空欄になることがありました。ここは人の目で確認が必要です。

全体として、フロントマターの標準化はClaude Codeが最も得意とする領域でした。テキスト変換のルールが明確なら、精度の高い結果が得られます。

どこまで頼むだけでできた？

6ステップの検証を振り返って、「頼むだけでできたこと」と「できなかったこと」の境界線を整理します。

頼むだけでできたこと：
– Vault全体の分析（ノート数、タグ数、孤立ノートの特定）
– フォルダ構成案の提案（PARA方式に近い構成が自然に出た）
– タグの統合（表記ゆれの解消はほぼ完璧）
– フロントマターの標準化（統一フォーマットへの変換は高精度）
– MOCの自動生成（トピック別の目次ノート作成）

頼むだけでは到達しなかったこと：
– ノートの正確な自動分類（7割の精度、残り3割は人の判断が必要）
– タグの「意味の近さ」による統合（表記ゆれは解消できても、ニュアンスの違いまでは困難）
– リンク先の存在確認（存在しないノートへのリンクを生成することがある）

人が確認・修正すべきだったこと：
– フォルダ分類の妥当性（特にProjectsとResourcesの境界）
– タグ統合のニュアンス判断（「思いつき」と「アイデア」は同じか？）
– リンク先が実在するかどうか
– フロントマターのtitleが正しく抽出されているか

やり取りの回数は合計9回でした。各Stepで1〜2回の指示を出し、Step 4（自動分類）では分類案の確認を挟んだため+1回です。一発でうまくいかなかったのはStep 4とStep 5で、自動分類は最初の指示だとフォルダ移動まで一気に実行しようとしたため、一度止めて「分類案だけ出して」と言い直しました。

まとめると、分析と提案は頼むだけで十分。実行（ファイルの移動や変更）は確認を挟むのが安全です。

この検証の振り返り

検証の流れを時系列で整理します。

Vaultの現状分析 → フォルダ構成の提案 → タグの統合 → ノートの自動分類 → リンクの補完とMOC作成 → フロントマターの標準化。この6ステップを進めるのに、Claude Codeとのやり取りは合計9回でした。

全体を通して言えるのは、「分析と提案」のフェーズはほぼ人の介入なしで進んだということ。一方で、「実行」のフェーズ（ファイルの移動、リンクの追加、フロントマターの書き換え）では、都度結果を確認する必要がありました。

Vault整理で最も気をつけるべきはバックアップです。Claude Codeにファイル操作を頼む前に、Vault全体のコピーを別フォルダに置いておくことを強く推奨します。WindowsならエクスプローラーでVaultフォルダを右クリックしてコピー、別の場所に貼り付けるだけです。これだけで、もし誤操作があっても元に戻せます。

ここまで頼むだけでここまでは進みました。ただし最後は人が確認しています。

次に試すなら

この記事を読んで「自分のVaultでも試してみたい」と思った方に、いくつかコツをまとめます。

まずは小規模なVaultで試すことをおすすめします。ノート数が10〜20本のテスト用Vaultを作って、そこで一通り流れを試すと安心です。いきなり本番のVaultでやると、予期しない結果が出た時に焦ります。

バックアップは必ず取ってください。自動分類やフロントマターの変換は元に戻すのが面倒な操作です。Vaultのコピーを別フォルダに保存しておけば、最悪の場合はコピーから復元できます。

依頼文のコツとして、「分析だけ」「提案だけ」「実行して」のように段階的に指示を出すのがポイントです。一度に全部やろうとすると、途中で予期しない結果が出ても止めにくくなります。特にファイルの移動や書き換えを伴う操作では、「まず案を出して」と指示してから確認し、「この案で実行して」と進めるのが安全です。

「頼むだけでどこまでできるか」を試す楽しさは、実際に手を動かさないと伝わらない部分があります。まずは小さなVaultでStep 1の現状分析だけでも試してみてください。出てきた数字を見るだけでも、「自分のVaultってこうなってたのか」と発見があるはずです。

まとめ

Claude Codeに頼むだけで、散らかったObsidian Vaultの現状分析からフォルダ構成の提案、タグの統合、フロントマターの標準化までは到達できました。特に分析と提案は人の介入なしで使えるレベルです。ただしノートの自動分類とリンクの品質担保には人の最終確認が欠かせません。7割の精度で自動分類できても、残り3割を人の目で見る手間は省けない。「頼むだけ」でたどり着ける境界線は、そこまで――そしてそこから先は人が確認する、というところにあります。