Claude Codeでどこまでできる?

Claude Codeの使い方や連携を、実際に試してわかりやすく伝えるサイト

Claude Codeに頼むだけで、Obsidianのリンク整理はどこまでできる?

,

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

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のプロンプトでそのパスを指定すれば、中の .md ファイルをすべて読めます。

テスト用Vaultの準備:

最初は本番のVaultではなく、10〜30ノート程度の小規模なVaultで試すのが安全です。ノートを何か書き換える前に、Vaultのフォルダごとコピーを取っておけば、いつでも元に戻せます。

補足: Obsidian 1.12以降を使っている場合、Settings → General → Command line interface を有効化するとコマンド obsidian が使えるようになります。ただし、この記事の検証では使わず、Claude Code単体でどこまでできるかを試します。

Claude Codeの基本的な使い方がまだの方は、はじめ方の記事を先に読んでおくとスムーズです。

やりたいこと:Vaultが散らかっている状況

Obsidianを使っていると、あるあるの悩みにぶつかります。

ノートはどんどん増えるのに、リンクが繋がっていない。どのノート同士を繋げばいいかを手動で判断するのは、ノートが50を超えたあたりで現実的ではなくなります。

グラフビューを開くと、中央にいくつかの簇があるだけで、周囲にぽつんと浮かぶ点が大量にある。それが孤立ノートです。どこからもリンクされていないノートたちで、せっかく書いた内容がVaultの奥底に埋もれている状態。

ファイルを整理しようとしてフォルダを移動したりファイル名を変えたりすると、今度はリンク切れが増える。[[移動前の名前]] への参照があちこちに残って、リンク先が見つからない警告が出る。

この「散らかったVault」を、Claude Codeに頼むだけでどこまで整理できるのか。それを確かめるための実験を始めます。

Step 1:最初の依頼 — Vault全体のリンク状況を把握させる

まずは安全な方向から始めました。Vault内のMarkdownファイルをスキャンして、WikiLinkの構造を解析するだけの依頼です。書き換えは一切させない、読むだけの指示にしています。

依頼文の要約はこうです:

「このVault内のすべての .md ファイルを読み込んで、各ファイル内の [[リンク]] を抽出してください。どのノートがどこへリンクしているかの一覧と、どのノートがどこからもリンクされていないか(孤立ノート)の一覧を作ってください。」

いきなり書き換え指示を出すと、意図しない編集が入るリスクがあるからです。まずは状況を把握して、結果を見てから次の指示を考える——この「依頼→確認→次の指示」のリズムは、このあともずっと続きます。

ここで気をつけたポイントは、指示を具体的にすること。「整理して」という漠然とした依頼ではなく、「どのファイルのどの行にどんなリンクがあるか」を列挙させる。そうすると、Claude Codeが勝手に解釈を広げすぎるのを防げます。

Step 2:最初の結果 — リンク状況はどこまで見えたか

結果は、思ったよりちゃんと出ました。

できたこと:

Claude CodeはVault内のMarkdownファイルを順番に読み込み、各ファイル内の [[リンク]] 記法を正しく抽出しました。出力として、以下の3つの一覧を返してくれました。

  • リンク一覧: 各ノートがどのノートへリンクしているか
  • 孤立ノート一覧: どこからもリンクされていないノート
  • リンク切れ一覧: 存在しないノートへの参照

25ノートのテストVaultで試したところ、孤立ノートが8つ、リンク切れが3つ検出されました。手動では1つずつファイルを開いて確認しないと分からない情報が、1回の依頼で出揃ったのは大きいです。

足りなかったこと:

ノート数が多いVaultだと、Claude Codeが一度にすべてのファイルを処理しきれない場合があります。コンテキストの制限に引っかかると、後半のノートが解析から漏れる。今回のテストVault(25ノート)では問題ありませんでしたが、数百ノートのVaultだと分割して指示を出す必要がありそうです。

人が確認したポイント:

出力された孤立ノートの一覧を見て、本当にどこからもリンクされていないかを何件か手元で確認しました。結果は正確でした。ただし、フロントマター(YAMLヘッダー)内の tagsaliases と本文中のリンクを区別して扱っているかは、念のため確認した方がいいと思います。

Step 3:修正指示 — 孤立ノートにリンクを張らせる

次は、検出された孤立ノートに対してリンクを張る指示を出します。

ただし、その前に安全対策を挟みました。Vaultのフォルダごとコピーを取ってバックアップを作ります。これで、もし Claude Code の編集が想定と違っても元に戻せます。

修正の依頼文はこうです:

「孤立ノートとして検出された各ノートの内容を読み、関連する他のノートを見つけて、双方向に [[リンク]] を追加してください。リンクはノートの末尾の『関連ノート』セクションに追加してください。既存の本文は書き換えないでください。」

この依頼で気をつけたのは3点です。

  1. リンクの追加先を指定した — 末尾の「関連ノート」セクションに限定することで、本文を書き換えるリスクを減らしました
  2. 既存の本文は触らせない — 意図しない文章の変更を防ぐため
  3. 双方向リンクを指定した — AからBにリンクを張るなら、BからAにもリンクを張る指示

指示文の中に「どこを」「どう変更するか」を明確に書くと、Claude Codeが誤動作しにくくなります。初心者ならここで意識しておきたいポイントです。

Step 4:修正後の結果 — リンクは正しく繋がったか

修正結果を確認します。

良かった点:

孤立ノート8つのうち6つに、適切なリンクが追加されました。内容を確認すると、確かに関連性のあるノート同士が繋がっています。「読書メモ_原子の習慣」に「習慣化の仕組み」へのリンクが追加されており、文脈を見ても妥当。グラフビューでは、点々と浮かんでいた孤立ノートのいくつかが中央の簇に繋がりました。

問題があった点:

残り2つの孤立ノートには、やや強引なリンクが提案されていました。内容の関連性が薄いのにリンクが張られているケースです。たとえば「旅行の思い出_京都」と「仕事のタスク整理」が繋がっていたり。これらは手動で外しました。

人の確認で気づいた点:

リンクの妥当性の判断は、やはり人がやる必要があります。Claude Codeは「同じキーワードが含まれている」ことで関連性を判断しているふしがあり、文脈の深い理解までは難しかった。ただ、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/ フォルダの中に作成してください。」

結果:

3つのMOCが生成されました。「読書と学習」「仕事とタスク管理」「趣味と記録」というテーマで、それぞれに関連ノートがリストアップされています。

内容を確認すると、分類はおおむね適切でした。ただ、一部のノートがどのMOCにも含まれていない、という抜け漏れがありました。また、「仕事とタスク管理」のMOCに「日記_2026年3月」が含まれていたのは、日記の中に仕事の話題が少し混ざっていたため。このように、MOCの粒度や分類の基準は人の感覚とズレることがあります。

手動で調整した部分:

  • 抜けていたノートを該当するMOCに追加
  • 分類ミスのノートを移動(日記を「趣味と記録」に移動)
  • 各MOCに簡単な説明文(「このテーマには○○に関するノートをまとめています」)を追加

MOCの自動生成は、ゼロから手動で作るよりはるかに速いです。雛形ができるので、あとは人が微調整するだけで済みました。

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

6つのStepを通して、「頼むだけでできたこと」と「人の確認が必要だったこと」を整理します。

Claude Codeだけでできたこと:

  • Vault内の全ノートのリンク構造の解析
  • 孤立ノートとリンク切れの自動検出
  • 孤立ノートへのリンク提案(8件中6件が適切)
  • リンク切れの修正(3件中2件が正確)
  • テーマ別MOCの雛形生成

頼むだけでは到達しなかったこと:

  • リンク先の妥当性の最終判断(文脈の理解に限界がある)
  • 複数候補がある場合の正しい選択
  • MOCの分類の粒度と基準の調整

人が確認・修正したこと:

  • 不適切なリンク提案の除外(2件)
  • 複数候補からの正しいリンク先の選択(1件)
  • MOCの分類ミスの修正と抜け漏れの補完

やり取りの回数: 6回(状況把握→結果確認→修正指示→結果確認→リンク切れ修正→MOC生成)

一発で完璧にはならなかったけれど、毎回確実に前に進んだことが重要だと思います。依頼文を少し変えるだけで結果が変わるので、コツを掴めば効率は上がります。

この検証の振り返り

全体の流れを振り返ります。

依頼→結果→修正→限界→完成。このサイクルが6回転しました。Vaultのリンク状況を把握するところから始まって、孤立ノートへのリンク追加、リンク切れの修正、MOCの自動生成まで。それぞれのStepで、Claude Codeができることと、人が確認すべきことの境界線が少しずつ見えてきました。

人が確認したポイントのまとめ:

  • リンク提案の妥当性(内容に関連しているか)
  • リンク切れの修正先(複数候補がある場合)
  • MOCの分類基準(自分の感覚と合っているか)
  • フロントマターと本文中リンクの区別

大規模Vaultでの注意点:

ノートが数百を超えるVaultだと、Claude Codeのコンテキスト制限に引っかかる可能性が高くなります。その場合は、フォルダごとに分割して指示を出すか、一度に処理するノート数を絞るなどの工夫が必要です。

補足: Obsidian 1.12以降で Command line interface を有効化している環境なら、Vaultの操作をObsidian経由で行う選択肢もあります。ただし、今回の検証はClaude Code単体で完結する範囲で試しています。

今回の検証を通して、「Claude Codeに頼むだけで、Vault全体のリンク状況把握、孤立ノートの検出とリンク提案、リンク切れの一括修正、テーマ別MOCの自動生成までは進められる」という結論に至りました。ただし、リンク先の妥当性の最終判断と、ノートの意図の解釈は人が必ず確認する必要があります。

次に試すなら

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

始め方のコツ:

まずは本番のVaultではなく、コピーしたテストVaultで試すこと。10〜30ノートの小規模なVaultなら、結果の確認もしやすいです。

依頼文は「何をしてほしいか」を具体的に書くこと。「リンクを整理して」ではなく、「このフォルダ内の .md ファイルを読んで、各ファイルの [[リンク]] を一覧にして」というレベルで指示すると、精度が上がります。

大規模Vaultへの応用:

ノートが多いVaultでは、一度に全部を処理しようとせず、フォルダ単位やテーマ単位で分割して指示を出すのが確実です。「このフォルダの中だけお願い」と絞り込むと、コンテキスト制限の問題も起きにくい。

関連記事への導線:

Claude Codeの基本的な使い方がまだの方は、はじめ方の記事を先に読むのがおすすめです。Claude Codeのインストールから最初のプロジェクトの始め方までを説明しています。

リンク整理以外にも、Claude Codeに頼むだけでいろいろなことが試せます。このブログでは引き続き「どこまでできるか」の検証を続けていくので、気になったらまた覗いてみてください。

まとめ

Claude Codeに頼むだけで、ObsidianのVault整理は「かなりのところまで」進みます。孤立ノートの検出、リンク切れの修正、テーマ別MOCの雛形生成まで、1回のセッションでここまでできる。ただし、リンク先が本当に適切か、MOCの分類が自分の意図と合っているか——これらの最終確認は人が必ず挟む必要がある。手動でゼロからやるのに比べれば圧倒的に速いので、まずはテストVaultで試して、自分のペースで境界線を確かめてみてください。


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