Windows環境のClaude Codeで実際に試した結果をもとに書いています。
Obsidianを使い始めて、「ノートは増えたのにリンクが繋がっていない」と感じたことはありませんか？ グラフビューを開くと点々と浮かぶ孤立ノート、Obsidianの外でファイル名を変えたせいで増えたリンク切れ、手動で直すには数が多すぎる。この状況、Claude Codeに頼むだけで、どこまで整理できるのでしょうか。
何を確かめるのか
「Claude Codeに頼むだけで、Obsidianのリンク整理はどこまでできる？」——この問いに、実際にVaultを用意して検証しました。
孤立ノートの検出、リンク切れの一括修正、MOC（Map of Content）の自動生成。この3つをWindows環境で、追加ツールなしでどこまでやれるのか、その境界線を正直に報告します。
前提：Windows環境で必要な準備
検証を再現するために必要なものを整理しておきます。
前提条件:
– Windows 10 または 11
– Obsidianがインストール済みであること
– Claude Codeが使える状態であること
Claude CodeはMarkdownファイルを直接読み書きできるので、Vaultを作業対象にしやすいのが利点です。プラグインの導入も、特別な設定ファイルの編集も不要。
たとえば、Vaultが C:\Users\あなた\Documents\MyVault にある場合、Claude Codeのプロンプトでそのパスを指定すると、そのフォルダを作業対象として扱いやすくなります。
テスト用Vaultの準備:
最初は本番のVaultではなく、10〜30ノート程度の小規模なVaultで試すのが安全です。ノートを何か書き換える前に、Vaultのフォルダごとコピーを取っておけば、いつでも元に戻せます。
補足: 最近のObsidianには、設定から有効化できるコマンドライン機能（CLI）が用意されています。ただし、この記事の検証では使わず、Claude Code単体でどこまでできるかを試します。
Claude Codeの基本的な使い方がまだの方は、はじめ方の記事を先に読んでおくとスムーズです。
やりたいこと：Vaultが散らかっている状況
Obsidianを使っていると、あるあるの悩みにぶつかります。
ノートはどんどん増えるのに、リンクが繋がっていない。どのノート同士を繋げばいいかを手動で判断するのは、ノートが50を超えたあたりで現実的ではなくなります。
グラフビューを開くと、中央にいくつかの簇があるだけで、周囲にぽつんと浮かぶ点が大量にある。それが孤立ノートです。どこからもリンクされていないノートたちで、せっかく書いた内容がVaultの奥底に埋もれている状態。
Obsidianの外でファイル名を変えると、[[旧ファイル名]] への参照が残ってリンク切れになることがある。
この「散らかったVault」を、Claude Codeでどこまで整理できるのか。試してみます。
Step 1：最初の依頼 — Vault全体のリンク状況を把握させる
まずは安全な方向から始めました。Vault内のMarkdownファイルをスキャンして、WikiLinkの構造を解析するだけの依頼です。書き換えは一切させない、読むだけの指示にしています。
依頼文の要約はこうです：
「このVault内のすべての .md ファイルを読み込んで、各ファイル内の [[リンク]] を抽出してください。どのノートがどこへリンクしているかの一覧と、どのノートがどこからもリンクされていないか（孤立ノート）の一覧を作ってください。」
いきなり書き換え指示を出すと、意図しない編集が入るリスクがあるからです。まずは状況を把握して、結果を見てから次の指示を考える——この「依頼→確認→次の指示」のリズムは、このあともずっと続きます。
ここで気をつけたポイントは、指示を具体的にすること。「整理して」という漠然とした依頼ではなく、「どのファイルのどの行にどんなリンクがあるか」を列挙させる。そうすると、Claude Codeが勝手に解釈を広げすぎるのを防げます。
Step 2：最初の結果 — リンク状況はどこまで見えたか
まずまずの結果が出揃いました。
できたこと:
Claude CodeはVault内のMarkdownファイルを順番に読み込み、各ファイル内の [[リンク]] 記法を正しく抽出しました。出力として、以下の3つの一覧を返してくれました。
- リンク一覧: 各ノートがどのノートへリンクしているか
- 孤立ノート一覧: どこからもリンクされていないノート
- リンク切れ一覧: 存在しないノートへの参照
今回の小規模テストVault（25ノート）では、孤立ノートが8つ、リンク切れが3つ検出されました。手動では1つずつファイルを開いて確認しないと分からない情報が、1回の依頼で出揃ったのは大きいです。
足りなかったこと:
ノート数が多いVaultでは、一度に扱う情報量が増えるため精度や想起が落ちやすい場面があります。今回のテストVault（25ノート）では問題ありませんでしたが、数百ノートのVaultだとフォルダ単位で分割して指示した方が安全です。
目で確かめたポイント:
出力された孤立ノートの一覧を見て、本当にどこからもリンクされていないかを何件か手元で確認しました。結果は正確でした。ただし、フロントマター（YAMLヘッダー）内の tags や aliases と本文中のリンクを区別して扱っているかは、念のため確認した方がいいと思います。
Step 3：修正指示 — 孤立ノートにリンクを張らせる
次は、検出された孤立ノートに対してリンクを張る指示を出します。
ただし、その前に安全対策を挟みました。Vaultのフォルダごとコピーを取ってバックアップを作ります。これで、もし Claude Code の編集が想定と違っても元に戻せます。
修正の依頼文はこうです：
「孤立ノートとして検出された各ノートの内容を読み、関連する他のノートを見つけて、双方向に [[リンク]] を追加してください。リンクはノートの末尾の『関連ノート』セクションに追加してください。既存の本文は書き換えないでください。」
この依頼で気をつけたのは3点です。
- リンクの追加先を指定した — 末尾の「関連ノート」セクションに限定することで、本文を書き換えるリスクを減らしました
- 既存の本文は触らせない — 意図しない文章の変更を防ぐため
- 双方向リンクを指定した — AからBにリンクを張るなら、BからAにもリンクを張る指示
指示文の中に「どこを」「どう変更するか」を明確に書くと、Claude Codeが誤動作しにくくなります。初心者ならここで意識しておきたいポイントです。
Step 4：修正後の結果 — リンクは正しく繋がったか
修正後のVaultを開いて見てみます。
孤立ノート8つのうち6つに、適切なリンクが追加されました。「読書メモ_原子の習慣」に「習慣化の仕組み」へのリンクが追加されており、文脈を見ても妥当。グラフビューでは、点々と浮かんでいた孤立ノートのいくつかが中央の簇に繋がりました。
一方で、残り2つにはやや強引なリンクが提案されていました。内容の関連性が薄いのにリンクが張られているケースです。たとえば「旅行の思い出_京都」と「仕事のタスク整理」が繋がっていたり。これらは手動で外しました。
見ていて感じたのは、同じキーワードが含まれていると関連性が高いと見なされがちだということ。文脈の深い理解までは難しいようですが、8つのうち6つは適切だったので、提案されたリンクを人がふるいにかける使い方であれば実用的です。
やり取りはここまでで3回（状況把握→修正指示→結果確認）。一発では完璧にならないけれど、修正すれば確実に前に進む感覚がつかめてきました。
Step 5：リンク切れの一括修正に挑戦
次はリンク切れの修正です。
Step 2で検出された3つのリンク切れは、いずれもファイルのリネームが原因でした。[[旧ファイル名]] への参照が残っているが、実際のファイルは新しい名前に変わっている状態です。
依頼文はこうしました：
「Vault内に存在しないノートへのリンク（リンク切れ）を検出して、正しいファイル名に修正してください。修正前に対象ファイルのバックアップ（.bak付きコピー）を作成してください。」
3つのリンク切れのうち2つは正しく修正されました。残り1つは、リネーム後のファイルが2つ候補としてあり、Claude Codeが間違った方を選んでいました。こういう「複数候補がある場合」は人が判断するのが確実です。
修正前後でVaultを開いて確認したところ、修正された2件はグラフビューでも正しく繋がっていました。リンク切れは [[旧名]] から [[新名]] に書き換えられており、元のファイルのバックアップ（.bakファイル）も残っていました。
なお、Obsidianにはファイル名を変更した際に内部リンクを自動更新する設定があります。ただし、Obsidianの外（エクスプローラーや外部エディタ等）でファイル名を変えた場合はこの更新が働かないため、リンク切れが残ることがあります。そういう場面で今回の手法が役立ちます。
Step 6：MOC（Map of Content）の自動生成
最後に、テーマ別のMOCページを自動生成させてみます。
MOC（Map of Content）は、関連するノート群をまとめるハブノートです。たとえば「読書メモ」のMOCがあれば、読書関連のノートが一箇所に集約されて、Vault内の回遊性が上がります。
依頼文はこうです：
「Vault内のノートの内容を読んで、共通のテーマでグループ分けしてください。各グループについて、テーマ名を見出しにしたMOCノートを作成してください。MOCノートには、そのテーマに関連するノートのリンクをリスト形式で含めてください。MOCノートは
MOC/フォルダの中に作成してください。」
結果:
今回のテストVaultでは3つのMOCが生成されました。「読書と学習」「仕事とタスク管理」「趣味と記録」というテーマで、それぞれに関連ノートがリストアップされています。
内容を確認すると、分類はおおむね適切でした。ただ、一部のノートがどのMOCにも含まれていない、という抜け漏れがありました。また、「仕事とタスク管理」のMOCに「日記_2026年3月」が含まれていたのは、日記の中に仕事の話題が少し混ざっていたため。このように、MOCの粒度や分類の基準は人の感覚とズレることがあります。
手動で調整した部分:
- 抜けていたノートを該当するMOCに追加
- 分類ミスのノートを移動（日記を「趣味と記録」に移動）
- 各MOCに簡単な説明文（「このテーマには○○に関するノートをまとめています」）を追加
MOCの自動生成は、ゼロから手動で作るよりはるかに速いです。雛形ができるので、あとは人が微調整するだけで済みました。
どこまで頼むだけでできた？
6つのStepを通して、「頼むだけでできたこと」と「人の確認が必要だったこと」を整理します。
Claude Codeだけでできたこと:
- Vault内の全ノートのリンク構造の解析
- 孤立ノートとリンク切れの自動検出
- 孤立ノートへのリンク提案（今回のテストVaultでは8件中6件が適切）
- リンク切れの修正（同3件中2件が正確）
- テーマ別MOCの雛形生成
頼むだけでは到達しなかったこと:
- リンク先の妥当性の最終判断（文脈の理解に限界がある）
- 複数候補がある場合の正しい選択
- MOCの分類の粒度と基準の調整
やり取りの回数: 6回（状況把握→結果確認→修正指示→結果確認→リンク切れ修正→MOC生成）
一発で完璧にはならなかったけれど、毎回確実に前に進んだことが重要だと思います。依頼文を少し変えるだけで結果が変わるので、コツを掴めば効率は上がります。
この検証の振り返り
依頼→結果→修正→限界→完成。このサイクルが6回転しました。Vaultのリンク状況を把握するところから始まって、孤立ノートへのリンク追加、リンク切れの修正、MOCの自動生成まで。それぞれのStepで、Claude Codeに任せやすい領域と、目での確認が欲しい箇所の区別が少しずつ見えてきました。
依頼文のコツ:
指示を具体的に書くことが一番効いたと感じた点をいくつか。
- 「どのファイルのどの行にどんなリンクがあるか」を列挙させる — 漠然とした「整理して」より精度が上がる
- 「どこを」「どう変更するか」を明確に書く — 本文を誤って書き換えるリスクを減らせる
- 読むだけの指示と書き換えの指示を分ける — まず状況把握、その後修正の流れが安定する
大規模Vaultでの注意点:
ノートが数百を超えるVaultでは、フォルダ単位で絞り込んで指示すると安定しやすいです。
今回の小規模テストVaultでの検証を通して、Vault全体のリンク状況把握、孤立ノートの検出とリンク提案、リンク切れの修正、テーマ別MOCの雛形生成までは頼むだけで進められる、という感触を得ました。
次に試すなら
この記事を読んで「自分のVaultでも試してみたい」と思った方に、いくつかコツをお伝えします。
始め方のコツ:
まずは本番のVaultではなく、コピーしたテストVaultで試すこと。10〜30ノートの小規模なVaultなら、結果の確認もしやすいです。
依頼文は「何をしてほしいか」を具体的に書くこと。「このフォルダ内の .md ファイルを読んで、各ファイルの [[リンク]] を一覧にして」くらい具体的だと、結果が変わります。
大規模Vaultへの応用:
ノートが多いVaultでは、一度に全部を処理しようとせず、フォルダ単位やテーマ単位で絞り込んで指示するのが確実です。「このフォルダの中だけお願い」と限定すると、一度に扱う情報量が増えすぎる問題も起きにくい。
関連記事への導線:
Claude Codeの基本的な使い方がまだの方は、はじめ方の記事を先に読むのがおすすめです。Claude Codeのインストールから最初のプロジェクトの始め方までを説明しています。
リンク整理以外にも、Claude Codeでいろいろなことが試せます。このブログでは引き続き「どこまでできるか」の検証を続けていくので、気になったらまた覗いてみてください。
まとめ
雛形づくり、候補出し、一次整理——このあたりはClaude Codeに頼むだけでかなり進みます。孤立ノートの検出、リンク切れの修正案、テーマ別MOCのたたき台までは揃えやすいです。ただし「このリンク先で本当にいいのか」「この分類は自分の意図と合っているか」という意味の妥当性の判断は、ツールには任せきれない部分でした。手動でゼロからやるよりはるかに速く骨組みができるので、まずはテストVaultで試して、どこからが自分の確認が必要かを確かめてみてください。
今回の結果は、利用モデル、接続先、時期、環境によって変わる可能性があります。再現する時は検証条件もあわせて確認してください。
