Obsidian と Claude Desktop の MCP 接続でハマった話 — 同名 config ファイルの参照パス不一致
Obsidian と Claude Desktop を MCP で繋ごうとして詰まったときの記録。原因は同じ名前で別の場所にある claude_desktop_config.json でした。
Obsidian で書いていたメモを Claude Desktop から直接触れるようにしたくて、MCP で接続しようとしました。手順自体はプラグインを入れるだけのはずなのですが、設定の自動追記が一向に効かず、半日ほど詰まりました。
詰まった原因は、結論から言うと 同じ名前で別の場所にある claude_desktop_config.json を、Claude Desktop と Obsidian の MCP プラグインがそれぞれ別々に読み書きしていた という単純なものでした。次に同じ症状に遭った人がすぐ抜け出せるよう、経緯と診断の順序を残しておきます。
やろうとしていた構成
最終的に組みたかったのは、Obsidian の Vault を Claude Desktop が直接読み書きできる状態です。具体的には、Obsidian 側に Local REST API プラグインを入れて、その API を MCP サーバー経由で Claude Desktop に喋らせる、という構造になります。
セットアップ自体は短い手順です。まず Obsidian で Local REST API プラグインをインストールして API キーを発行します。続けて MCP Tools プラグイン(jacksteamdev/obsidian-mcp-tools)を入れ、設定画面の「Install Server」を押すと、ローカルに MCP サーバーのバイナリがダウンロードされ、同時に Claude Desktop の claude_desktop_config.json にサーバー定義が自動追記されるはずでした。
最後に Claude Desktop を再起動すれば完了、という想定だったのですが、ここから先が思うように動きませんでした。
詰まった現象
Install Server を押しても、Claude Desktop 側の MCP 設定に何も増えてこないように見えました。Claude Desktop の Developer メニューから Edit Config で開ける claude_desktop_config.json を覗いても、Obsidian のサーバー定義はどこにも書かれていません。
そこで自分で手動で追記してみたのですが、保存後に Claude Desktop を再起動すると、エラー扱いで設定が元に戻る現象も起きました。「自動追記処理が走っていない上に、手書きの内容も弾かれる」という二重に詰まった状態に見えて、最初は MCP Tools プラグインのバグを疑いました。
ただ、ここで「自動追記が走っていない」と判定したのが、結果的に最初の誤診でした。自動追記は走っていたのですが、Claude Desktop が読み込まない別ファイルに対して走っていた のが実態です。
根本原因 — 同名の claude_desktop_config.json が複数あった
落ち着いて MCP Tools プラグインのログを確認すると、プラグインは確かに claude_desktop_config.json への書き込みを成功させていました。一方で Claude Desktop 側が Edit Config で開いていたのも claude_desktop_config.json です。ファイル名は同じだが、実体は別の場所にあるファイル だったのが今回のトラブルの本質でした。
| 書き込み側・参照側 | 実際のパス(私の環境では) |
|---|---|
| MCP Tools プラグインが書き込んでいた先 | %APPDATA%\Claude\claude_desktop_config.json |
| Claude Desktop が読みに行っていた先 | %LOCALAPPDATA%\Packages\Claude_<ID>\LocalCache\Roaming\Claude\claude_desktop_config.json |
ファイル名で会話していると気付きにくいのですが、これは別物です。MCP Tools 側からすれば「正しく書いた」、Claude Desktop 側からすれば「設定は空のまま」、両方が嘘をついていない状態で、噛み合っていないだけでした。
AppData\Local\Packages\... という長いパスは、Microsoft Store(MSIX)版の Claude Desktop のサンドボックスパスに似ています。私が使っていたのは公式インストーラ版だったはずなのですが、過去のインストール経路や設定の破損が原因で、Claude Desktop の参照先がイレギュラーな場所に向いていたようです。
解決と、再インストールという回り道
Claude にこのパスを見せて相談したところ、「これは MSIX 版固有のサンドボックスパスでは。MSIX 版だと MCP がサイレントに無視される既知バグがあるので、再インストールしてみてはどうか」という指摘が返ってきました。
実際に MSIX 版だったかどうかは確認しきれず、AI の推測としては当たっていなかった可能性もあります。それでも、結果としてこの提案に乗って Claude Desktop を再インストール したところ、参照パスが %APPDATA%\Claude\ の正規の場所に統一され、MCP Tools の自動追記がそのまま反映されて MCP 接続が確立しました。
原因の正体(過去のインストール残骸なのか、MSIX 版の挙動なのか、別の設定破損なのか)は最後までは特定できていません。ただ、こうしたアプリ側の参照パスがイレギュラーになるケースでは、原因を厳密に詰めるより まず再インストールで状態を正規化する のが時間効率上は合理的だと感じました。AI の診断が当たることもあれば外れることもありますが、提案された具体的アクションが結果につながるなら、原因の解像度はあとから上げれば十分です。
同じ症状に遭ったときのチェック順
ここまでの経験を踏まえて、同じ詰まり方をしたときに最短で抜けるためのチェック順をまとめておきます。順序が大事で、上から順に潰していくのが効率的です。
- Claude Desktop が 実際に参照している
claude_desktop_config.jsonのフルパスを特定する(Developer → Edit Config で開かれるパスを見る) - MCP プラグインが 実際に書き込んでいる
claude_desktop_config.jsonのフルパスを特定する(プラグインのログ、または書き込み後のファイル更新日時で確認) - 1 と 2 が 同じファイルか を、フルパスで突合する
- 違っていたら、それが根本原因。同じファイル名でも別物なので、ファイル名だけで判断しない
- 同じファイルなのに反映されない場合は Claude Desktop を再インストール する
公式インストーラ版の Windows なら、claude_desktop_config.json の正規のパスは次のとおりです。
C:\Users\<ユーザー名>\AppData\Roaming\Claude\claude_desktop_config.jsonAppData\Local\Packages\... のような長いパスが見えたら、MSIX/Store 版の残骸や設定破損を疑ってよい、という判断材料になります。
プラグイン選定とセキュリティ上の注意
最後に、これから同じ構成を組む方向けの注意点を 2 つ残しておきます。
ひとつは MCP Tools プラグインの今後 についてです。作者の jacksteamdev 氏は、サプライチェーン攻撃のリスクを理由に開発停止を表明しており、README で HTTP/SSE 方式の代替プラグインへの移行を推奨しています。代替候補として挙げられているのは、バイナリ配布を伴わない iansinnott/obsidian-claude-code-mcp です。これから新しく接続を組むなら、最初からこちらを選ぶことも視野に入る選択肢になります。
もうひとつは MCP 接続が Vault に与える権限の広さ です。MCP 経由で Vault に繋ぐということは、AI に対して読み書き・削除のフルアクセスを与えることと等しくなります。重要な Vault は事前に Git でバックアップを取り、必要のないときは Claude Desktop の設定で MCP サーバーを無効化できるようにしておくと、万一のときの被害を限定できます。
接続自体はうまく動くと非常に便利で、Obsidian で書いたメモをそのまま Claude に渡して整理してもらえる体験は、一度味わうと戻れない種類のものです。便利さと引き換えにどこに権限を渡しているかは、繋ぐ前に自覚しておきたいところでした。