Obsidian × Claude Code 連携｜MCP設定と安全運用

ObsidianのVaultをClaude Codeから参照できるようにすると、散らばっていたメモや設計メモを、ターミナル上でそのまま検索・要約・確認できる流れが作れます。
この記事は、Obsidianを使っていてClaude Codeの連携を始めたい初心者から中級者の開発者に向けて、MCPの基本から接続確認までを順に整理したものです。

連携方法はひとつではなく、Local REST APIとMCP Toolsを組み合わせる方法と、obsidian-claude-code-mcpのような専用プラグインを使う方法で考えると混乱しません。
私はまずテスト用Vaultで接続し、ファイル一覧が返るところまで確かめてから本番Vaultに広げていますが、この手順にしておくと設定ミスや権限まわりの切り分けが進みます。

両者はもともと拡張と外部連携の余地が大きいツールです。
この記事では、安全に接続する考え方を押さえつつ、自分の環境でMCP接続を再現し、Vault内のファイル一覧取得までたどり着くところまで案内します））。

Obsidian × Claude Code連携でできること

Obsidianはローカル保存のMarkdownベースでノートを育てていく知識管理ツールで、ノート同士を双方向リンクでつなげられる点と、コミュニティプラグインで機能を拡張できる点が軸になっています。
Obsidian 公式サイト（その前提がはっきり示されています。
一方のClaude Codeはターミナルで動くAIコーディング支援ツールで、コードの読解や編集だけでなく、MCPによって外部ツールやデータソースを安全な枠組みで呼び出せます。
Claude Code の仕組み（https://code.claude.com/docs/ja/how-claude-code-worksを見ると、単にファイルを読むだけでなく、ツール経由で必要な情報に絞って扱う思想がわかります））。

この2つをMCPでつなぐと、Claude Code上からObsidianのVaultを対象に、検索、要点抽出、ノート間リンクのたどり直し、追記案の作成といった作業をまとめて進められます。
対応するMCPサーバーやプラグインが公開しているツールの範囲には差がありますが、実務では次のような操作が中心になります。

• Vault内をキーワードで検索します。
• パス指定で絞り込むことも可能です。
• キーワードやパスを指定してVault内を検索する
• 見つかったノートだけを対象に抜粋や要約を取る
• リンク先ノートを順にたどって背景情報を集める
• 既存ノートの文脈に沿ったドラフトや追記案を出す
• ノート一覧やメタデータを取得して、関連メモの位置関係を確認する

私自身、Vault全体を直接読ませるより、MCP経由でまず検索してから対象ノートだけを絞って要約させる流れのほうが往復が短いと感じています。
特に設計メモや日次ノートが混在しているVaultでは、最初の検索で候補を狭め、その結果に対して要約や比較をかけたほうが、意図しないノートまで文脈に混ざりにくく、会話の精度も保ちやすくなります。

本記事では2つの実装方式を扱う

本記事で扱う連携方法は、名前が似た仕組みを混同しないように、2系統に分けて整理します。
ひとつはLocal REST APIと、コミュニティ事例として使われることがある「MCP Tools」を組み合わせる方式です。
Local REST APIは Obsidian 側に REST エンドポイントを提供し、ノートの読み書きや検索などを扱えます。
一方で「MCP Tools」や mcp-server を Vault 配下に置いて Claude 側へ登録するという手法はコミュニティ事例として散見されますが、必ずしも単一の公式配布物として一貫して提供されているわけではありません。
導入前に、対象プラグインや配布パッケージの README／リリースを確認し、Vault 配下に mcp-server の実体があるかどうかを確かめてください。

前提条件と準備するもの

加えて、Claude Codeを使える環境も前提になります。
ターミナルから起動でき、MCPサーバーを追加する準備ができている状態を想定します。
導入元の説明や実践記事では Node.js 18+ を前提にした手順が多く、ローカルでMCPサーバーを立ち上げる構成ではこの条件がそのまま効いてきます。
Claude Codeはターミナル上で動くため、GUIアプリの初期設定だけで完結するタイプではありません。
Nodeが古いままだと、プラグインやサーバー側の起動段階でつまずくことがあります。

Obsidian側では、コミュニティプラグインを有効化できる状態も欠かせません。
Obsidian 日本語ヘルプ: コミュニティプラグイン（https://publish.obsidian.md/help-ja/%E9%AB%98%E5%BA%A6%E3%81%AA%E3%83%88%E3%83%94%E3%83%83%E3%82%AF/%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3で案内されている通り、設定の中でコミュニティプラグインを有効にします。
必要ならセーフモードを解除しておくとよいでしょう。
実際にやってみると、ここを先に済ませておくだけで、その後の「プラグインが見つからない」「有効化ボタンが出ない」といった初歩的な詰まり方を避けられます）。

Vaultの場所は、単に覚えているだけでは足りず、OS上の実パスとして把握しておくのが肝心です。
MCP設定ではVault名ではなくファイルシステム上の場所を参照する場面があり、日本語やスペースを含むパスはクオート漏れで失敗の原因になります。
筆者は最初、本番の知識ベースではなくテスト用Vaultを新規作成して試しましたが、この進め方だとプラグイン設定の副作用とVault固有の問題を分けて見られました。
接続確認の段階では、ノートが少ない小さなVaultのほうが、ファイル一覧や検索結果の成否を目で追うのに適しています。

なお、Obsidian本体は個人利用・商用利用とも基本アプリを無料で使える一方、同期などのオプションは有料サービスです。
この連携作業そのものに有料プラン加入が必須というわけではなく、まずはローカルのVaultで検証できます）。

専用MCPプラグイン方式を選び、しかも複数Vaultを運用する予定があるなら、ポート設計も準備段階で頭に入れておきたいところです。
VaultごとにMCPサーバーが立つ実装では、同じポート番号を使い回すと衝突します。
仕事用と個人用を同時に扱うなら、どのVaultにどのポートを割り当てるかを先に整理しておくと、後で「起動しているのに見つからない」という混乱を防げます。

APIキーの扱い

Local REST APIのようにAPIキーを使う方式では、キーの管理方針を最初に決めておく必要があります。
GitHub上のLocal REST APIはHTTPSインターフェースをAPIキー認証で保護する設計を案内しており、Vaultに対する読み書きや検索を外部から扱う以上、この入口を無防備にしないことが前提になります。

APIキーはメモ帳やノート本文に貼るのではなく、設定ファイルや環境変数で閉じた状態に置くのが基本です。
普段使っている他サービスと同じキーを流用するのではなく、この用途専用に分けておくと、切り分けと失効対応がしやすくなります。
実務では「試しに一度つながればよい」と考えて雑に扱ってしまいがちですが、Vaultには設計メモ、日報、認証情報の断片など、想像以上に広い情報が入っています。
キーを別発行にして用途を限定しておくと、万一の見直しも短時間で終わります。

Claude Code Security（新しく追加するMCPサーバーは信頼できるものだけに絞る前提が示されています。
MCPは便利な仕組みですが、同時に外部ツールへ文脈を渡す窓口でもあります。
ローカル限定で動かす、公開範囲を広げない、必要以上のサーバーを登録しないという順番で整えると、構成が増えても把握しやすくなります）。

OS別の設定ファイルパスを事前把握

Claude Code側の設定ファイルは、どこを書き換えるのかを先に押さえておくと手順全体がぶれません。
Mac/Linux では ~/.claude.json、Windows では %USERPROFILE%\.claude.json が基本の置き場所です。
MCPサーバーの追加やユーザースコープ設定は、このあたりのファイルに反映される形で管理されます。

このパスを事前に知っていると、claude mcp add を実行した後に「設定は入ったのか」「どこを見れば修正できるのか」をすぐ追えます。
逆に保存先を把握していないと、CLIで追加したはずの設定が見当たらず、同じ登録を繰り返してしまいがちです。
実際に触ってみると、トラブル時はコマンドの成否より先に設定ファイルの中身を見たほうが状況を整理できます。

Windowsではパス区切りがバックスラッシュになり、PowerShellや cmd の扱いも絡むため、文字列の引用方法でつまずく場面があります。
Mac/LinuxでもVaultパスにスペースが入っていると、シェルが途中で引数を分割してしまいます。
設定ファイルの場所とあわせて、Vaultパスも文字列としてどう扱うかを意識しておくと、MCPサーバーの実行パスやVault指定のミスを見つけやすくなります。

方法1：Local REST API + MCP Toolsで接続する手順

A. Obsidian側プラグイン導入

この構成では、Obsidian側に Local REST API と MCP Tools の2つを入れ、Claude Code側にはMCPサーバーとして mcp-server 実行ファイルを登録します。
Vaultを直接読むだけの連携より設定項目は増えますが、ノート一覧取得や検索、書き込み系の操作まで視野に入れやすいのがこの方式の利点です。

まずは配布元（GitHub など）の README を確認し、Community Plugins に掲載があるかを確かめてください。
一般的には Community Plugins で見つかることが多いものの、配布が GitHub のみで手動インストールを要するプラグインもあります。
該当プラグインが Community Plugins にない場合は、公式リポジトリのインストール手順に従って導入してください。
次にMCP Toolsを入れます。
こちらもObsidianのコミュニティプラグイン画面から MCP Tools で検索して導入し、有効化します。
ただし、MCP Toolsについては単独プロジェクトとしての公式配布ページを検索結果から明確に確定できませんでした。
「Vault配下に mcp-server 実体を展開する実例があるプラグイン」として扱い、後段の実体パス確認で必ず現物を見る前提で進めます。
名前の近いMCP関連プラグインは複数あるので、mcp-server を含む bin ディレクトリがVault内に作られるかまで確認しておくと、後の登録で迷いません。

Local REST APIを有効化したら、プラグイン設定画面でAPIキーが見える状態まで進めておきます。
このキーはこのあと claude mcp add の環境変数で渡す形にすると整理しやすく、ノート本文や別のメモに貼る必要もありません。
接続作業中はAPIキーの値そのものより、「どこに設定するか」を固定するほうが切り分けが早く進みます。

MCP Toolsを有効化したら、次はClaude側に登録する「実行ファイルの本当の場所」を確認します。
実例としてよく使われるのはVault配下の次のパスです。
ただし、プラグインの配布方法は多様で、Community Plugins に掲載されていない場合や、GitHub から手動で導入する必要がある場合もあります。
/.obsidian/plugins/mcp-tools/bin/mcp-server

ここで見たいのは、ショートカットや見かけの表示名ではなく、OSが認識しているフルパスです。
Mac/LinuxならFinderやファイルマネージャでVaultを開いて .obsidian/plugins/mcp-tools/bin/ をたどり、mcp-server が存在するかを見ます。
Windowsでも同じ階層構造をたどれますが、こちらは表示上のパスと実体パスがずれることがあり、失敗の原因になりがちです。
筆者は最初、エクスプローラーのサイドバーに出るショートカット経由の見え方をそのまま信じて登録し、存在するはずのファイルが見つからない扱いになりました。
エクスプローラーのアドレスバーをクリックしてフルパス文字列をそのまま取得すると、余計な混乱を挟まずに済みます。

Mac/LinuxでもWindowsでも、Vault名やユーザー名にスペースが入っているなら、その時点でクオート前提と考えたほうが安全です。
実際、筆者もパスにスペースを含む環境でクオートを省いたまま claude mcp add を打ち、途中で引数が分割されて登録に失敗しました。
"..." で二重クオートしてからは同じコマンドが通ったので、ローカルパスは「文字列」として扱う意識を早めに持っておくと詰まりません。

合わせて、Local REST API側の設定画面も開き、APIキーを控えます。
記事内にキー値の例は出しませんが、Claude側登録で -e オプションに渡すので、コピーできる状態にしておくと流れが止まりません。
REST APIの詳細なエンドポイントは coddingtonbear の対話型ドキュメントで確認できますが、この章ではまず「mcp-server の現物がある」「APIキーを取得できる」という2点がそろえば十分です。

C. claude mcp add 実行と設定ファイル更新

mcp-server の実体パスとAPIキーが確認できたら、Claude CodeでMCPサーバーを登録します。
MCPの追加は claude mcp add で行えます。
Claude CodeのMCPドキュメントでも、-s でスコープを指定し、-e で環境変数を渡し、-- の後ろに実行コマンドを置く形が案内されています。

Mac/Linuxの例は次の形です。

claude mcp add obsidian-local-rest -s user -e OBSIDIAN_API_KEY="YOUR_API_KEY" -- "/Users/you/Your Vault/.obsidian/plugins/mcp-tools/bin/mcp-server"

パスにスペースがないならクオートなしでも通る場面はありますが、実運用では二重クオートで囲ったほうが安定します。
たとえばVault名が Work Notes なら、次のようにパス全体を " で囲います。

claude mcp add obsidian-local-rest -s user -e OBSIDIAN_API_KEY="YOUR_API_KEY" -- "/Users/you/Work Notes/.obsidian/plugins/mcp-tools/bin/mcp-server"

WindowsではPowerShellや cmd の解釈が絡むので、まずはフルパスを明示した形で登録するほうが通しやすいのが利点です。
PowerShellでの例は次のとおりです。

claude mcp add obsidian-local-rest -s user -e OBSIDIAN_API_KEY="YOUR_API_KEY" -- "C:\Users\you\Obsidian Vault\.obsidian\plugins\mcp-tools\bin\mcp-server"

ショートカット経由の見え方ではなく、エクスプローラーのアドレスバーから取ったフルパスをそのまま貼ると、Windows特有の取り違えを減らせます。
Vault名が Project Notes のように空白を含むなら、ここでも "C:\Users\you\Project Notes\..." の形を崩さないことが肝になります。

-s user で追加した場合、登録内容はユーザースコープの設定に保存される形になります。
Mac/Linuxでは ~/.claude.json、Windowsでは %USERPROFILE%\.claude.json が確認先です。
claude mcp add が自動更新してくれることが多いものの、状態確認や手修正のために中身を読めたほうが作業が早いので、最低限の構造だけ把握しておく価値があります。

以下に示す ~/.claude.json の断片は、コミュニティ実例としてよく見られる「一例」です。

{
 "mcpServers": {
   "obsidian-local-rest": {
     "command": "/Users/you/Your Vault/.obsidian/plugins/mcp-tools/bin/mcp-server",
     "env": {
    "OBSIDIAN_API_KEY": "YOUR_API_KEY"
    }

（上の JSON はコミュニティ実例としてよく見られる一例です。
） "command": "C:\\Users\\you\\Obsidian Vault\\.obsidian\\plugins\\mcp-tools\\bin\\mcp-server", "env": { "OBSIDIAN_API_KEY": "YOUR_API_KEY" }

実際の保存フォーマットはClaude側のバージョンやスコープの扱いで差が見えることがありますが、少なくとも **名前、実行コマンド、環境変数** の3点が入っているかを見ると、登録内容を追いやすくなります。すでに別の設定項目が入っている環境では、既存JSONの途中に追記することになるため、末尾カンマの入れ方で壊しやすい場面です。`~/.claude.json` や `%USERPROFILE%\.claude.json` はコメントを入れず、純粋なJSONとして保存します。ここに説明メモを書き足すと、その1行だけで起動時の読み込みに失敗します。

推奨構成としては、MCPサーバー名を `obsidian` のような短すぎる名前にせず、`obsidian-local-rest` のように方式まで含めておくと、あとで専用MCP方式を並行検証したときに識別しやすくなります。複数Vaultを切り替える予定があるなら、サーバー名にVault名を織り込むより、まず1本を通してから増やしたほうが設定ファイルの見通しが保てます。

### D. 初回接続テスト（ファイル一覧取得）とミニチェックリスト

登録後は、Claude Code側で新しく追加したMCPサーバーに対する信頼確認が出ることがあります。これはMCPが外部ツールをClaudeに接続する仕組みだからで、初回だけ明示的に許可する流れです。ここで追加した[Obsidian](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)用サーバーを承認すると、Claude側からVaultの情報にアクセスできる状態に進みます。

接続テストでは、まず **Vault内ファイル一覧の取得** を試すのが一番わかりやすいです。検索や書き込みより前に、「ノート一覧が返るか」を見れば、MCPサーバー起動、APIキー受け渡し、Vault到達の三つをまとめて確認できます。CLI上でMCPサーバーが見えている状態なら、Claude CodeにVaultのファイル一覧取得を依頼し、ノート名が複数返ってくれば接続は通っています。ここで見出しだけでなく、実際のMarkdownファイル名が並べば成功判定として十分です。

もし一覧取得で止まるなら、詰まりどころは限られます。切り分け用に見直す点を短く並べると次のとおりです。

- [Obsidian](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)側で[Local REST API](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)とMCP Toolsの両方が有効になっている
- Vault配下に `/.obsidian/plugins/mcp-tools/bin/mcp-server` が実在する
- `claude mcp add` で指定したパスがショートカットではなくフルパスになっている
- パスにスペースがある場合、実行ファイルパス全体を二重クオートで囲っている
- APIキーが `-e` オプションまたは設定ファイルの `env` に正しく入っている
- `~/.claude.json` または `%USERPROFILE%\.claude.json` にJSON構文エラーがない
- 初回の信頼確認で追加したMCPサーバーを許可している

この方式では、失敗したときに「Obsidianプラグインの問題なのか」「Claude側の登録ミスなのか」が混ざりやすいのですが、ファイル一覧取得までの導線を一段ずつ分けると、原因は絞り込みやすくなります。実際には、APIキーそのものより **実行ファイルのパス文字列** でつまずく場面のほうが目立ちます。特にWindowsはフルパス取得の精度が結果を左右し、Mac/Linuxはスペース入りパスのクオート有無で成否が分かれます。ここを越えると、Claude Codeから[Obsidian](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)のVaultを扱う土台が整います。

## 方法2：Obsidian専用MCPプラグインで接続する手順

### A. プラグインの導入と基本設定

この方法の軸になるのは、専用プラグインobsidian-claude-code-mcpで[Obsidian](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)自身をMCPサーバーとして動かす考え方です。GitHubのobsidian-claude-code-mcp READMEに沿うと、Claude CodeはWebSocket経由で自動発見できる設計で、Claude DesktopはHTTP/SSEで接続する前提になっています。前の方法のように[Local REST API](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)とMCP Toolsを組み合わせて、`bin` 配下の `mcp-server` を探してCLI登録する流れより、構成がひと目で把握しやすいのが特徴です。

導入は[Obsidian](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)のコミュニティプラグイン画面からobsidian-claude-code-mcpを検索してインストールし、有効化します。初回有効化の直後は、ローカル通信や外部クライアント連携に関する確認が出ることがあります。この確認を通すと、Vaultごとの設定画面でポートや接続方式を調整できる状態になります。自動発見でそのままつながる構成だと、`claude mcp add` の手作業を挟まずに試せるので、接続確認までの往復が減ります。実際、この方式は「まず通るかを見る」段階が短く、設定ファイルを書き換えて再起動する回数も抑えられました。

ここで前の方式との違いも整理しておくと混乱しません。[Local REST API](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)方式では、[Local REST API](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)の導入に加えてMCP Toolsも入れ、Vault配下の `/.obsidian/plugins/mcp-tools/bin/mcp-server` が存在するかを確認し、その実行ファイルをClaude Code側へ登録していました。たとえばMacやLinuxでは次のような形です。

claude mcp add obsidian-local-rest -s user -e OBSIDIAN_API_KEY=YOUR_API_KEY -- "/Users/you/Your Vault/.obsidian/plugins/mcp-tools/bin/mcp-server"

パスにスペースが含まれるなら、`"..."` で全体を囲う書き方が欠かせません。Windowsでも同じで、たとえば `"C:\Users\you\Obsidian Vault\.obsidian\plugins\mcp-tools\bin\mcp-server"` のようにクオートしておかないと、途中の空白で引数が分断されます。専用MCPプラグイン方式は、この `bin` 配下の実行ファイル確認が不要になるぶん、作業の焦点が[Obsidian](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)内の設定に寄ります。

> [!TIP]
> 入手元は[Obsidian](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)のコミュニティプラグイン画面か、プラグインの公式リポジトリに絞るのが前提です。MCPはClaudeに外部データや操作を渡す仕組みなので、信頼できる提供元以外から導入すると、接続以前の段階で安全性を損ねます。

### B. 既定ポート22360と複数Vaultのポート設計

obsidian-claude-code-mcpの既定ポートは **22360** です。1つのVaultだけで使うなら、そのままでも足りますが、複数Vaultを同時に開く運用ではポート設計を最初に決めておいたほうが混乱を避けられます。READMEベースの素直な設計は、Vaultごとにユニークなポートを割り当てることです。たとえば仕事用Vaultと個人用Vaultを分けているなら、片方を22360、もう片方を別ポートにして、どのVaultがどこで待ち受けるかを固定しておく、という考え方です。

ここは実運用で見落としやすい箇所です。自分も2つ目のVaultを開いた直後に接続が急に不安定になって、最初はClaude Code側の不具合だと思いましたが、原因はポートの重複でした。専用プラグイン方式は自動発見があるぶん、接続先が自然につながって見える場面があり、ポート衝突に気づくまで少し時間がかかります。

競合時の症状と回避策は、次の形で把握しておくと切り分けが速くなります。

- 片方のVaultでは接続できるのに、もう片方では接続が現れたり消えたりする
- 自動発見で見えていたサーバー名が、Vaultを増やした直後から不安定になる
- 手動で `ws://localhost:22360` に向けても、期待したVaultではない側に当たる
- 回避するには、各Vaultでポートを重複させず、Vault名とポートの対応をメモして固定する
- 外部公開は前提にせず、待受先はローカル限定で扱う

ポートを分けるだけでなく、「どのクライアントがどのVaultへ向くか」までそろえると、後から見返したときに迷いません。専用プラグイン方式はローカル接続前提で組むのが自然で、LANや外部へ広げる設計にはしないほうが筋が通ります。

### C. Claude Code vs Claude Desktopの設定差

同じMCPでも、Claude CodeとClaude Desktopでは接続の考え方が少し違います。Claude CodeはREADMEの仕様どおり、WebSocketでの自動発見が第一候補です。[Obsidian](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)側のプラグインを有効にしてポートが立ち上がると、追加登録なしで見つかるケースがあり、このときは `claude mcp add` を打たずに試験に入れます。自動発見が即座に通る構成は、設定ファイルとCLIの両方を触る必要がなく、どこで間違えたのかを追う工程が一段減ります。

一方のClaude Desktopは、READMEでHTTP/SSE接続が案内されている点が違いです。つまり、同じプラグインを使っていても、Claude Codeの「自動で見つかるかもしれない」体験をそのまま期待する構図ではありません。接続先URLを明示して扱う場面が増えるので、UI上でサーバー定義を編集する意識が必要になります。

手動登録が必要なケースに備えて、Claude Code側のユーザー設定ファイルを直接編集する形も押さえておくと復旧が速くなります。保存先はMac/Linuxなら `~/.claude.json`、Windowsなら `%USERPROFILE%\.claude.json` です。実際のキー名は環境差があり得るものの、少なくとも「サーバー名」「URLまたは起動情報」が読める形で入っているかを見ると状態を追えます。たとえばWebSocketの接続先を持たせる例としては次のようなイメージです。

{ "mcpServers": { "obsidian-vault-main": { "url": "ws://localhost:22360" }

Windowsでも置き場所が `%USERPROFILE%\.claude.json` になる以外は、考え方は同じです。前の方式のようにローカル実行ファイルを登録する場合は、Windowsパスのバックスラッシュに加えて、スペースを含むパスのクオートも絡みます。たとえば[Local REST API](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)＋MCP Toolsで手動登録するなら、`"C:\Users\you\Obsidian Vault\.obsidian\plugins\mcp-tools\bin\mcp-server"` のように丸ごと囲った形が必要です。専用MCPプラグイン方式ではその煩雑さが減る反面、接続方式の違いをClaude CodeとClaude Desktopで取り違えないことがポイントになります。

### D. 自動発見が効かない時の手動接続テスト

自動発見でつながらないときは、まず[Obsidian](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)側のプラグインが起動済みで、対象Vaultのポートが想定どおりかを確認したうえで、手動の接続テストに切り替えると原因が絞れます。Claude Codeなら、READMEに沿ってWebSocketのエンドポイント `ws://localhost:22360` を基準に見ます。複数Vault構成なら、ここを各Vaultに割り当てたポートへ読み替えます。

CLIでの登録が必要な場面では、たとえば次のようにサーバー名を付けて追加します。

claude mcp add obsidian-vault-main -s user -- "ws://localhost:22360"

この種の書式は、利用しているCLI実装やバージョン差で扱いが分かれることがあるため、うまく通らない場合は `~/.claude.json` または `%USERPROFILE%\.claude.json` に直接追記して、JSONとして読み込まれるかを見るほうが切り分けしやすくなります。たとえばMac/Linuxなら次のような形です。

{ "mcpServers": { "obsidian-vault-main": { "url": "ws://localhost:22360" }

Claude 。ここで大事なのは、「Claude CodeではWebSocket」「Claude DesktopではHTTP/SSE」という区別を混ぜないことです。プロトコルを取り違えると、ポートが合っていてもつながりません。

手動テストでも通らない場合は、接続先の入力ミスより、Vault側のポート重複か、プラグイン起動そのものが止まっている場面が多い印象です。専用プラグイン方式は構成が整理されているぶん、詰まったときの確認点も少数に絞れます。自動発見が外れた瞬間にすぐCLIと設定ファイルの両方をいじるより、まず `ws://localhost:22360` に相当する接続先が本当にそのVaultを指しているかを見るほうが、復旧までの距離が短くなります。

設定が終わった直後は、まず Vault の中身を一覧できるかを確認するのが定番です。一覧取得が成功すれば、MCPサーバー起動・認証・Vault到達の三点が揃っていることが一目で分かります。

### A. 初回疎通: ファイル一覧取得

設定が終わった直後は、まずVaultの中身を一覧できるかを見るのが定番です。ここで成功していれば、「接続先が見えているか」「認証や起動が通っているか」「Claude側がそのツールを呼べるか」を一度に確認できます。最初から長い要約や生成を試すより、一覧取得から入り、そのあと単一ノートの要約、さらに差分抽出へと段階を踏むほうが、意図しない編集を混ぜずに状態を追えます。実際、この順番にしておくと、どこで挙動が変わったのかを切り分けやすくなります。

最初の一文としては、英語なら **What files are in my Obsidian vault?**、日本語なら「ObsidianのVault内にあるファイル一覧を表示してください」で十分です。抽象的な整理や要約では英語プロンプトのほうが広く解釈してくれる場面がありますが、一覧取得や検索のような素直な操作は日本語でもほとんど遜色ありません。接続確認の段階では、むしろ自分が後で読み返しやすい文面で統一したほうが流れが安定します。
[Local REST API](https://github.com/coddingtonbear/obsidian-local-rest-api（GitHub)を使っているなら、裏側ではファイル列挙系のエンドポイントが動いています。たとえばローカルで直接叩いて疎通を見るなら、次のような形です。

curl -H "Authorization: Bearer YOUR_API_KEY" \

Claude Code側からMCP経由で確認するなら、プロンプトはもっと素朴で構いません。たとえば次の3つは、初回テストとして通りが見やすい文面です。

1. `What files are in my Obsidian vault?`
2. `ObsidianのVault内にあるファイル一覧を、フォルダ構造がわかる形で表示してください。`
3. `List the top-level folders and a sample of notes in my Obsidian vault.`

一覧が返ってきたら、そのまま「最近触ったノート」を見る流れに進むと、日常運用で使う感覚に近づきます。最初に試す候補としては、次のような依頼が適しています。

1. `Show me the most recently edited notes in my Obsidian vault.`
2. `最近編集したノートを上位10件だけ表示してください。`
3. `タグ #meeting のノートを探して、各ノートを2〜3行で要約してください。`
4. `先週のデイリーノートからハイライトを抽出してください。`

もしClaude Code の概要（[https://code.claude.com/docs/ja/overview](https://code.claude.com/docs/ja/overview)やClaude Code Security（[https://code.claude.com/docs/en/security](https://code.claude.com/docs/en/security)で案内されている考え方に沿って運用するなら、この段階では読み取り中心の問い合わせに寄せておくとよいでしょう。そうすることで動作確認と安全確認を同時に進めやすくなります））。

### B. ノート検索・抽出

一覧取得が通ったら、次は「狙ったノートにたどり着けるか」を見ます。検索はノート名、タグ、フォルダの3つで試すと、Vaultの構造を横断して把握できます。ここでも、最初は曖昧な依頼より、対象が絞られた検索文のほうが結果を評価しやすくなります。

ノート名指定の基本形は、「`Project Alpha` という名前を含むノートを探して内容を要約してください」や `Find notes with "Project Alpha" in the title and summarize the latest one.` あたりです。日英どちらでも通りますが、タイトルの一部をそのまま引用符で囲うと、検索対象がぶれません。

タグ検索では、会議メモや読書メモのように運用ルールが決まっているVaultで効きます。たとえば次のような文面が適しています。

タグ #meeting が付いたノートを探して、直近のものから3件だけ要約してください。

Find notes tagged #meeting and give me a concise summary of each.

フォルダ単位で見るなら、特定の作業領域をまとめて読ませる形が便利です。たとえば `Daily`、`Projects`、`Engineering` のように役割が分かれたVaultでは、次のような依頼で十分です。

フォルダ "Daily" 配下の先週分ノートだけを抽出してください。

Search only inside the "Engineering" folder and list notes related to authentication.

検索結果を受け取ったあとに、すぐ要約へ飛ばず、まず候補一覧を出し、その中から1件を指定して読む流れにすると、Claudeが別ノートを拾ってしまう事故を減らせます。私自身、一覧取得のあとに単一ノート要約、そのあとで「前回との差分だけ見せてください」と進めたときのほうが、欲しい情報に短距離で着地しました。逆に、最初から「今週の議論を全部整理して」と広く投げると、範囲の広さに引っ張られて、要約対象が思ったより拡散しがちです。

### C. 週次振り返りテンプレートの骨子

接続後の実用例として手応えが出やすいのが、1週間分のデイリーノートからの振り返り生成です。単なる要約ではなく、**事実の集約 → ハイライト抽出 → KPT化** の順に頼むと、結果の解像度が上がります。日報やデイリーがすでに蓄積されているVaultなら、この用途だけでも連携の価値が見えます。

まずは対象期間をはっきりさせたうえで、デイリーノートをまとめて読ませます。たとえば次のようなプロンプトです。

先週のデイリーノートを読み込み、1週間の出来事を日付順に3〜5項目へ整理してください。

そのあとで、要約を振り返りの型に落とし込みます。KPTまで含めるなら、次のテンプレートが適しています。

先週のデイリーノートをもとに週次振り返りを作成してください。 出力形式:

1. 今週の要点
2. ハイライト3件
3. Keep
4. Problem
5. Try
6. 来週の最重要タスク

事実ベースでまとめ、ノートに書かれていない内容は補わないでください。

英語で投げるなら、抽象化と再構成のまとまりが少し良く出ることがあります。

Read last week's daily notes and create a weekly review with:

• key events
• 3 highlights
• Keep / Problem / Try
• top priority for next week

Base it only on what is written in the notes.

この用途では、「何をやったか」だけでなく、「どこで詰まったか」や「来週の焦点」まで一度に出せるのが強みです。日々の記録は散らばりやすいため、週単位で眺めると全体の輪郭が把握しやすくなります。デイリーノートを丁寧に書いている人ほど、この変換の恩恵を受けやすいはずです。

> [!NOTE]
> 週次振り返りは、最初から完成版を求めるより、「時系列要約」と「KPT」を分けて生成したほうが、元ノートとの対応関係を追いやすくなります。

### D. 実装メモ（ADR/TODO）参照の型

開発用の Vault を育てているなら、実装メモの参照は早い段階で試したいところです。とくに `ADR`、`TODO`、`meeting notes` が同居している構成では、設計判断と未処理タスクを分けて読み出すだけで、プロジェクトの現状把握がぐっと楽になります。

> [!NOTE]
> 典型的なのは、リポジトリ連携メモや `Engineering` フォルダ配下を対象にして、設計決定事項を拾う依頼です。たとえば次のような文面が素直です。

フォルダ "Engineering" またはタイトルに "ADR" を含むノートを探し、設計上の決定事項を要点だけまとめてください。

Find notes related to ADRs and summarize the decisions, trade-offs, and open questions.

TODOの把握は、タグや見出しを拾う形にするとまとまりやすくなります。

タグ #todo の付いたノートと、"TODO" 見出しを含むノートを読み、未着手・進行中・保留に分けて整理してください。

実装メモ全体を俯瞰するなら、ADRとTODOを一緒に読ませて「決まったこと」と「まだ残っていること」を並べるのが有効です。

1. すでに決まった設計事項（ADR）
2. まだ残っている作業（TODO）
3. 議論中の論点
に分けてまとめてください。

Read my implementation notes and summarize:
1. architecture decisions already made
2. remaining TODOs
3. unresolved design questions
Prefer ADR notes, project notes, and meeting notes if they exist.

この手の問い合わせは、単なる検索より一段実務寄りですが、一覧取得と単一ノート要約が通っていれば、その延長で扱えます。
Obsidianを設計メモ置き場として使っている人ほど、「仕様書を開くほどではないけれど、前にどう決めたか思い出したい」という瞬間が多いはずです。
そこにClaude Codeが入ると、リポジトリを読む文脈とノートを読む文脈がつながり、実装前の確認コストが下がります。

2つの方式の選び方

A. 初期設定と運用手間

最初の分かれ目は、導入時にどこまで設定を抱えられるかです。
ここではLocal REST API+ MCP Tools 構成、obsidian-claude-code-mcp、Vault直接参照の3つで性格がはっきり分かれます。

Local REST API+ MCP Tools 構成は、手順の数そのものは多めです。
Obsidian側でLocal REST APIを動かし、Claude側では claude mcp add でローカルMCPを登録し、必要に応じて ~/.claude.json や Windows の %USERPROFILE%\.claude.json に反映された内容も見ます。
設定点は増えますが、そのぶん記事や実践例に沿って一つずつ確認でき、再現のしやすさがあります。
個人で検証するときはこの再現性が効きました。
昨日通った構成を今日もう一度組み直しても、どこを見れば戻せるかが明確だからです。

一方のobsidian-claude-code-mcpは、ObsidianプラグインがMCPサーバーとして振る舞うので、接続の見通しが整理されています。
GitHubのリポジトリobsidian-claude-code-mcpでは自動発見の考え方が示されていて、Claude DesktopとClaude Codeの両方にまたがって扱える点も魅力です。
チーム共有ではこの「まず見つかる」体験が効きました。
各メンバーに細かなCLI設定を説明しなくても、接続までの距離が短く、引き継ぎの会話が減ります。
ただし新しい方式なので、Vaultを複数持っている場合はポート設計を先に決めておかないと、あとで整理し直すことになります。
既定ポートが 22360 という前提も含め、1 Vault 1ポートで揃えるか、役割別に割り当てるかで運用感が変わります。

Vaultを直接ファイル参照する方法は、もっとも軽い始め方です。
MCPを挟まず、Claude CodeにVaultのディレクトリを読ませるだけなので、接続確認までの距離は短くなります。
Node.js 18+ を前提にClaude Codeを使う構成に乗っていれば、追加要素が少ないぶん着手は速いです。
ただし、あとから「ノートの一部だけ更新したい」「Obsidianの文脈に沿って操作したい」となったときに伸び代が限られます。
最小構成で始める価値はありますが、運用を続けるほど専用連携との差が見えてきます。

比較すると、導入の軽さだけなら直接参照、運用の整理のしやすさならobsidian-claude-code-mcp、手順の再現性と可搬性ならLocal REST API+ MCP Tools という並びになります。

B. 操作の深さと拡張性

次に見るべきなのは、単に読めるかどうかではなく、どこまで踏み込んで操作したいかです。
この点ではLocal REST API+ MCP Tools 構成が一歩先に出ます。

Local REST APIは、ノートの読み書き削除だけでなく、ファイル一覧取得、検索、コマンド実行、さらにPATCHで特定セクションへ挿入する流れまで持っています。
単なる「Markdownを読む」接続ではなく、VaultをAPIとして扱えるので、たとえば日次メモの見出し配下だけ更新する、候補ノートを絞ってから要約する、定期ノート作成の流れに寄せる、といった操作に広がります。
Claudeに頼む内容が「参照」から「整形」「追記」「定型化」に進むほど、この柔軟さが効きます。

obsidian-claude-code-mcpも、読み書きや検索のツール群が揃っているぶん、専用MCPとしては十分に実務寄りです。
ObsidianのノートをClaudeに渡す導線として自然で、専用プラグインならではのまとまりがあります。
ただ、RESTベースの構成はHTTP経由で他の自動化や補助ツールにつなぎやすく、MCPの外側にも広げやすいのが強みです。
あとからワークフローを増やしたくなったとき、RESTの層がある構成は選択肢が残ります。

Vault直接参照は、この比較軸では最も浅い位置にあります。
Claude Codeがファイルを直接読めるので、要約、検索、関連ノート抽出のような用途には十分です。
ただし、Obsidian特有の構造に沿った扱いは弱く、専用ツールを呼び出してノート編集を組み立てる流れには向きません。
ノートを「ファイル集合」として扱うには問題なくても、「Obsidianの作業面」として使いたい場面では限界が見えます。

判断に迷ったら、最初はobsidian-claude-code-mcpで自動発見の恩恵を受け、やりたい操作が増えてきた段階でLocal REST API+ MCP Tools に寄せる順番が収まりやすいのが利点です。
段階的に深くしていく発想だと、初期負担を抑えつつ、あとから詰まりにくくなります。

C. 安全性と管理のしやすさ

連携方法を選ぶときは、便利さだけでなく、どこを信頼の境界にするかも見ておきたいところです。
外部ツールが増えるほど、設定の数ではなく、権限の置き方が運用の差になります。

Local REST APIは、APIキーによるアクセス制御が基本設計です。
つまり、鍵の管理が運用の中心です。
設定ファイルやシェル履歴にどう残さないか、どこまでをlocalhost前提にするか、誰がAPIキーを扱うかが整理されていれば、管理ポイントは明快です。
逆に言うと、ここが曖昧だと便利さがそのまま管理コストに変わります。

obsidian-claude-code-mcpは、APIキー管理が前面に出にくいぶん、ポート公開範囲とVaultごとの切り分けが焦点になります。
単一Vaultなら話は単純ですが、仕事用と個人用を並行で開くと、どのVaultがどのポートで待ち受けているかを把握できる形にしておかないと混線します。
チームで使うときも、「誰でもつながる」状態に寄せるより、用途単位で接続先を分けたほうが後から追いやすくなります。

Vault直接参照は、ネットワークやMCPの管理が減る代わりに、「Claudeがどこまで見えるか」の境界がそのまま安全性になります。
フォルダ単位で参照を絞る、業務用Vaultと個人メモを分ける、といった構成上の切り分けがそのまま効きます。
MCPがないから安全というより、参照範囲を狭く保てるなら管理が単純になる、という理解のほうが実態に近いです。

簡易的に整理すると、次の表が判断の土台になります。

運用面まで含めて眺めると、共同利用ではobsidian-claude-code-mcpの自動発見が効き、個人での試行錯誤や記事どおりの再構成にはLocal REST API+ MCP Tools が向いています。
直接参照は入口としては軽いものの、Obsidianを積極的に操作したくなった時点で専用連携との差がはっきり出ます。
読者の判断軸としては、まず専用MCPで入り、足りない操作が見えてからREST構成へ進む順番が、無理なく収まるはずです。

実践ワークフロー3選

A. 設計メモ→実装タスクリスト化

この連携が実務で効く場面として、まず手応えが出やすいのが、過去の設計メモからそのまま実装タスクを起こす流れです。
Obsidianに設計ノートやADRが溜まっていると、方針は書いてあるのに、実装に落とす段階で読み返しコストが発生しがちです。
そこでClaude Code側から関連ノートを引き、要件、制約、未決事項を分けて整理させると、設計の文脈を失わずに作業単位まで落とし込めます。

実際の流れは、ターミナルで対象機能名を起点に検索し、その後にObsidianで該当ノートを開いて補足を足す、という往復になります。
たとえば朝に新機能へ着手するとき、まずClaude Codeで「認証周りの設計メモとADRを集めて、API変更、DB変更、UI変更、テスト観点に分けて要約して」と投げます。
返ってきた要約を見ながらObsidianで足りない前提を書き足し、もう一度「依存順に並べた実装タスクリストへ変換して」と続けると、設計の意図が残ったまま実行可能な粒度へ寄っていきます。

最初の1往復は、たとえば次のような形です。

クエリ 「Vault内の決済リトライに関する設計メモとADRを探し、要件・制約・未決事項に分けて要約してください。
要件は実装可能な文に直し、制約は見落とすと不具合につながるものを優先してください。
」

回答 「関連ノートから、要件としてリトライ回数上限、失敗理由の記録、管理画面からの再実行が抽出できます。
制約として二重課金防止、外部APIのタイムアウト時の冪等性維持、監査ログ保存が目立ちます。
未決事項は管理者権限の範囲と通知条件です。
実装対象はAPI、ジョブ、DBスキーマ、管理UI、テストに分割できます。
」

この段階でObsidianに戻り、設計ノートの末尾に「今回の実装では通知条件は一次対応から外す」「監査ログは既存テーブル拡張で吸収」といった決定を追記します。
そこから改善の1往復を入れると、タスクリストの精度が上がります。

追加指示 「未決事項のうち今回スコープ外にしたものを除外し、残りを実装順に並べてください。各タスクに完了条件と確認方法も付けてください。」

回答 「1. DBスキーマ更新。
完了条件はリトライ回数と最終失敗理由を保持できること。
確認方法はマイグレーション適用後の保存テスト。
2. ジョブ実装。
完了条件は上限回数まで再試行し、成功時に状態更新されること。
確認方法は疑似失敗ケースのジョブ実行。
3. API更新。
完了条件は管理画面から再実行要求を受け付けること。
確認方法は権限付きリクエストの統合テスト……」

この形のよさは、設計メモをただ読ませるだけで終わらず、実装順、完了条件、確認方法まで一続きで作れるところです。
Claude Codeのターミナル操作で抽出と整形を進め、Obsidianで判断や注釈を追記し、またターミナルへ戻す。
この交互運用が定着すると、古い設計メモが「残っているだけの記録」ではなく、着手前の下書きとして機能し始めます。

B. デイリー→週報

日々のメモを週報へ集約する流れも、連携の恩恵が見えやすいところです。
1日単位のDailyには会話の断片、作業メモ、詰まった点、翌日の宿題が混ざっています。
そのままでは読み返しに時間がかかりますが、Claude Codeで1週間分を束ねると、進捗の筋が見えてきます。
私は朝会の前に前日のメモを一度要約してから発言内容を整理することがありますが、頭の中で散っていた論点が先に並ぶので、会議中に話す順番で迷う場面が減りました。
週報でも同じで、先に骨組みを作っておくと報告の密度が安定します。

ここでは、月曜から金曜までのDailyを集約し、KPT、ハイライト、次週アクションを出す流れが扱いやすいのが利点です。
まずターミナルで対象期間のノートを集め、出来事を圧縮します。
返ってきた下書きを見て、Obsidianで「これは成果に入れる」「これはKeepではなくProblem」と微調整し、再度Claude Codeに整形させます。

最初の1往復はこうです。

クエリ 「今週のDailyノートを集約して、KPT形式の週報下書きを作ってください。
Keepは継続したい行動、Problemは停滞要因、Tryは来週の具体的行動に限定してください。
あわせて今週のハイライトを3件、次週アクションを3件出してください。
」

回答 「Keep: 設計メモを先に要約してから実装に入ったため、着手判断が速かった。
朝会前に前日メモを見返したことで共有内容が整理された。
Problem: 障害調査のログが別ノートに散り、再現条件の把握に時間がかかった。
Try: 障害メモに固定テンプレートを導入する。
ハイライト: 決済リトライ方針の合意、管理画面の再実行フロー実装、監査ログ項目の整理。
次週アクション: 統合テスト追加、障害テンプレート整備、通知条件のADR起票。
」

ここでObsidianの週報ノートを開いて、チーム向けの表現に合わせて追記します。
たとえば「設計メモを先に要約」は内部的な工夫なので、「事前整理により認識合わせが短時間で済んだ」と言い換える、といった調整です。
そのうえで改善の1往復を重ねます。

追加指示 Problemを事実ベースに書き換え、Tryは来週の予定に落としてください。
ハイライトは成果が伝わる表現に寄せ、週報テンプレートとしてそのまま貼れる形に整えてください。

回答 「Keep: 事前に設計メモを整理したことで、実装前の確認論点が明確になった。
朝会前に前日メモを要約したことで、共有時の重複説明が減った。
Problem: 障害調査時、再現条件と確認ログが複数ノートに分散していた。
Try: 障害対応用テンプレートを週内に作成し、次回調査から統一する。
ハイライト: 決済リトライ機能の実装方針を確定。
管理画面からの再実行導線を実装。
監査ログ項目の洗い出しを完了。
次週アクション: 統合テストケース追加、障害テンプレート導入、通知条件の整理ノート作成。
」

週報テンプレートも、固定の型をひとつ決めておくと回しやすくなります。

• 今週のハイライト
• Keep
• Problem
• Try
• 次週アクション
• 共有したい論点

このワークフローは、ターミナルで集約し、Obsidianで言い回しと事実関係を整え、再度ターミナルで体裁を揃える、という往復が自然です。
単なる要約ではなく、発言用の整理、週報用の整形、次週アクションへの接続まで一気通貫で進むので、デイリーノートが「書きっぱなし」で終わりません。

C. 学習/障害ログ→再利用テンプレ

学習メモや障害対応ログは、書いた直後よりも、次に再利用できたときに価値が出ます。
Obsidianに知識を貯めても、あとで探し出せなければ記録止まりです。
そこでClaude Codeに、学習ログから重要概念を抜き出させ、関連ノートのリンクを辿って復習計画へつなげる使い方が効きます。
障害ログでも同様で、時系列の出来事をその場限りにせず、再発時に使えるチェックリストへ変換すると、次回の初動が速くなります。

あるテーマのノート群をターミナルで横断します。
たとえば「キャッシュ戦略」や「冪等性設計」の学習ログを対象にして、概念、誤解しやすかった点、次に読むべき関連ノートを抽出させます。
その結果を見てObsidian側でリンクを整理し、復習ノートにまとめる形です。

最初の1往復は次のようになります。

クエリ 「Vault内の冪等性に関する学習メモを集め、重要概念を3つに要約してください。
各概念について、自分の理解が浅いまま残っている論点と、関連ノートのつながりも示してください。
」

回答 「重要概念は、同一リクエストの重複処理防止、外部API失敗時の再送制御、状態更新と監査ログの一貫性です。
理解が浅い論点として、タイムアウト時の成功判定、リトライキーの保存期間、非同期処理での整合性確保が残っています。
関連ノートとして、決済リトライ設計、ジョブ実行基盤、障害振り返りメモが接続しています。
」

ここでObsidianの復習ノートを開き、関連ノートを見ながら「理解が浅い論点」を手動で補います。その後、改善の1往復で学習計画に変えます。

追加指示 「理解が浅い論点をもとに、30分単位の復習計画へ変換してください。読む順番は関連ノートの依存関係に沿って並べてください。」

回答 「1コマ目はジョブ実行基盤ノートを読んで非同期処理の前提を確認。
2コマ目は決済リトライ設計ノートを読み、リトライキーと保存期間の理由を整理。
3コマ目は障害振り返りメモを読み、タイムアウト時の成功判定が実運用でどう問題化したかを確認。
各コマの終わりに、自分の言葉で3行要約を書く。
」

障害ログの再利用も、同じく交互運用で回ります。
インシデント発生時のメモは、Obsidian側で時系列に残しておくと後から強い材料になりますが、記録だけでは次の現場で開きにくいことがあります。
そこでClaude Codeに「初動確認」「切り分け」「一次復旧」「恒久対応」「共有事項」のような見出しでチェックリストへ再構成させると、次回の入口が整います。
障害振り返りから作ったチェックリストは、次のインシデントでそのまま開いて使える資産になりました。
記憶に頼らず、まず同じ順番で確認できるので、焦っているときほど効きます。

最初の1往復はこうです。

クエリ 「この障害対応ログから、次回の類似障害で使えるチェックリストを作ってください。
時系列の記録ではなく、初動から復旧後までの確認項目として整理してください。
」

回答 「初動確認では影響範囲、発生時刻、直前デプロイ有無、アラート内容を確認。
切り分けでは再現条件、依存サービス状態、ログ取得箇所、暫定回避策の有無を確認。
復旧後では原因、恒久対応候補、監視追加、共有先を整理する、という形にできます。
」

その回答をObsidianのテンプレートノートへ貼り、実際の運用に合わせて項目名を整えます。さらに改善の1往復で、現場向けの粒度へ寄せます。

追加指示 「各項目を、担当者がそのまま手を動かせる文に書き換えてください。確認観点だけでなく、記録欄の見出しも付けてください。」

回答 「影響範囲を確認する直前30分の変更を列挙するアプリログとインフラログの取得先を開く暫定回避策を適用した時刻を記録するのように動詞から始まる項目へ変換します。
記録欄は確認結果判断次の行動共有先で揃えると再利用しやすくなります。
」

こうして見ると、学習メモも障害ログも、価値が出るのは保存した瞬間ではなく、次の行動に変換できたときです。
Claude Codeで抽出と整形を行い、Obsidianでリンクやテンプレートを育てていくと、個別のノートが少しずつ再利用可能な部品に変わっていきます。

セキュリティと運用上の注意点

複数Vault時のポート競合と露出範囲

Obsidianを複数のVaultで運用していて、obsidian-claude-code-mcpやLocal REST API系の連携を並行して試すと、まず詰まりやすいのがポートの重複です。
MCPサーバー側やプラグイン側が同じ待受ポートを使おうとすると、片方が起動できなかったり、意図しないVaultに接続されたりします。
obsidian-claude-code-。

このとき意識したいのは、単に「起動したか」ではなく、どこまで露出しているかです。
ローカル連携のつもりで立てたMCPサーバーでも、待受アドレスやOS側の共有設定によっては、手元の端末の外から到達できる状態を作ってしまいます。
運用の基本は localhost などローカル限定に寄せ、使っていないVaultは閉じるか、該当プラグイン自体を無効化して待受口を減らすことです。
Vaultを開きっぱなしにしていると、どのノート空間がClaude側から見えているのか把握しづらくなり、参照対象の切り分けも曖昧になります。

新しいMCPサーバーをClaude Codeへ追加するときは、信頼確認ダイアログを丁寧に扱うことが欠かせません。

APIキーを使う構成では、キーの扱いもポート設定と同じくらい慎重に分ける必要があります。
Local REST APIはGitHub上の説明でAPIキー認証付きのHTTPSインターフェースを掲げていますが、だからといってキーを平文でメモに貼る運用は避けたいところです。
キーは用途を絞ったものを使い、不要になったら無効化し、設定値はシェルの環境変数やOSの秘密管理に寄せる方が整合が取れます。
claude mcp add でも環境変数を渡す運用ができるので、設定ファイルや履歴に秘密情報をばらまかない構成に寄せると、後から見直したときの不安が減ります。

プロジェクト設定やフックも盲点です。
自動実行、外部コマンド呼び出し、ファイル更新を伴うフローを最初からまとめて許可すると、便利さより先に事故が来ます。
自分の運用では、最初は参照だけに限定し、検索・要約・関連ノート探索の流れが固まってから編集APIを開けた方が安定しました。
いきなり書き込みまで許すと、ノートの命名規則や保存先が固まっていない段階で意図しない更新が起きやすく、あとで差分を追う手間の方が大きくなります。
最小権限で始め、必要になった権限だけを足していく方が、Vault全体の秩序を保ちやすい構成です。

Windowsでは、パス設定に絡んで \\ で始まるUNCパスやWebDAV系の共有先をそのまま有効化する構成にも気を配りたいところです。
ローカルVaultのつもりで扱っていても、実体がネットワーク共有だと参照範囲の前提が変わります。
セキュリティガイド類でも、この種の共有経路は扱いを一段慎重にする前提で書かれることが多く、少なくともMCPやCLIの初期構成では避けた方が整理しやすいのが利点です。
まずはローカルディスク上のVaultで構成を固め、その後に共有経路を検討する方が、切り分けも権限管理も明快になります。

不要プラグインの無効化・アップデート管理・Changelog監視の運用ポイント

連携が動き始めると、次に差が出るのは日々の保守です。
Obsidianのコミュニティプラグインは便利ですが、MCP連携、REST API、ファイル操作、同期補助のように役割が近いものを積み上げると、機能の重複や権限の重なりが起きます。
使っていないプラグインを残したままにすると、起動時に余計な処理が増えるだけでなく、どのプラグインがノートに触っているのか追いづらくなります。
MCPやAPIに関係するものは、とくに「今このVaultで必要か」を軸に絞った方が運用の輪郭がはっきりします。

アップデート管理では、本体とプラグインを一緒くたにせず見るのがコツです。
Obsidian Changelog（DesktopとMobileの最新版として v1.12.5 が確認でき、更新内容も継続的に追えます。
ここで見ておきたいのは、新機能そのものより、プラグイン互換や同期まわり、APIまわりの変更です。
連携用途では、見た目の改善より内部仕様の差分の方が運用に響く場面が多く、たとえばObsidian Syncのheadless operation対応のような更新は、自動化との相性を考えるうえで見逃せません）。

プラグイン側はChangelogやRelease noteを読む習慣があるだけで、トラブルの質が変わります。
新バージョンが出たから即日上げる、ではなく、「APIの扱いが変わったか」「既定ポートや接続方法に変更がないか」「権限まわりの説明が増えていないか」を見てから切り替える方が落ち着いて運用できます。
とくにGitHub配布のプラグインは、ストア経由のアプリより変化が速いので、更新頻度だけでなく変更の方向を見る必要があります。
READMEの更新、Issueの増え方、メンテナの応答状況まで眺めると、信頼の置き方が変わってきます。
プラグインの Changelog や Release note を確認する習慣をつけるだけで、トラブルの原因特定が速くなります。
新バージョンを適用する際は、UI の改善だけでなく「API の扱い」「既定ポートの変更」「権限まわりの修正」が含まれていないかを重点的にチェックしてください。
GitHub 配布のプラグインでは Issue の動きやリリース日も参考になります。
重大変更が含まれる場合は、まず検証環境でアップデートを試してから本番に反映する運用が安全です。

よくあるトラブルと対処

A. 接続エラー系の基本動線

Failed to connect が出たときは、設定ファイルをいきなり全部書き換えるより、接続経路を順番に潰していく方が早く着地します。
詰まりやすいのはClaude Code側の登録ミスに見えて、実際にはObsidian側のサーバー未起動、既定ポートの競合、ローカル通信を止めるファイアウォールの順で止まっている場面です。
obsidian-claude-code-mcp系では既定ポートが 22360 なので、この番号を前提に見ていくと切り分けが進みます。

最初の確認はシンプルで、サーバーが本当に起動しているかです。
Obsidianの対象Vaultを開いたうえで、MCPプラグインやLocal REST APIが有効な状態になっているかを見ます。
次にポートが待ち受け状態かを確認します。
ここでリスンが見えなければ、Claude Codeの問題ではなく、MCPサーバー側が立ち上がっていません。
Windows なら netstat -ano | findstr 22360、macOS や Linux なら lsof -i :22360 のように見ると、どのプロセスが掴んでいるか把握できます。

そのうえで、ローカル通信を遮っている要因も外せません。
Windows Defender Firewall や企業端末の保護ルールで localhost 通信まわりが引っかかると、サーバーは動いていても Failed to connect が消えないことがあります。
加えて、自動発見に対応する構成でも、クライアント差異や登録状態によっては検出されないことがあります。
自動で見つかる前提で止まるより、手動登録に切り替えて接続先を明示した方が、どこで失敗しているか輪郭が出ます。

チェックリストにすると、見る順番は次の形です。

• 既定ポート 22360 など、想定ポートで待ち受けがあるか確認してください。
• ファイアウォールやセキュリティ製品がローカル接続を止めていないか確認してください。
• 自動発見に頼っている場合、手動登録に切り替えると接続できるか試してください。
• Claude Codeに登録したサーバー名や起動コマンドが、今のVault構成と一致しているか

自分の環境では、ここで最小構成のテストVaultに切り替えて再現させると、一気に原因が絞れる場面が多くありました。
常用Vaultはプラグインや設定が積み重なっているので、接続そのものの問題なのか、Vault固有の差分なのかが見えづらくなります。
空に近いVaultで同じMCPを立ち上げて接続できるなら、原因はClaude Code全体ではなく、元のVaultの設定差分に寄っています。
自分の環境では、ここで最小構成のテストVaultに切り替えて再現させると、原因の絞り込みが速く進みました。
常用Vaultはプラグインや設定が積み重なっているため、問題の所在が分かりにくくなる傾向があります。

B. パス/権限/キーの再確認ポイント

接続できない原因がポートではないときは、APIキー、実行パス、権限の3点を並べて見直すと崩しやすくなります。
Local REST APIを使う構成では、APIキー未設定のまま Failed to connect に見えることがあります。
キーが必要なのはどのツールかを混同しやすく、Obsidianプラグイン側の認証なのか、Claude Codeの claude mcp add で渡す環境変数なのかが曖昧なまま進めると、見た目は同じ失敗でも中身が変わります。
まず「どのサーバーが何のキーを要求するのか」を一つずつ分けて考える方が確実です。

APIキー未設定や権限不足の切り分けでは、普段使いのキーを疑い続けるより、テスト用に一時キーを発行して差し替える方が速いです。
キーそのものの誤記、期限切れ、コピー時の空白混入をまとめて外せるからです。
Claude CodeのMCP登録では -e KEY=VALUE 形式で環境変数を渡す例がClaude CodeのMCPドキュメントでも見られるので、キーが必要なサーバーでは設定値の流れをそこで確認できます。
ユーザースコープやローカルスコープで設定が残っていると、古い値を掴んだまま失敗することもあり、~/.claude.json や Windows の %USERPROFILE%\.claude.json に以前の設定が残っていないかを見ると筋が通ります。

mcp-server の実体パス不一致も、見落としやすい定番です。
とくに Vault ごとに mcp-tools/bin/mcp-server を持つ前提で組んだ場合、今開いているVaultとは別の .obsidian/plugins/mcp-tools/bin/mcp-server を指していて起動に失敗することがあります。
ショートカットやエイリアス経由で指定していると、見た目のパスと実体がずれていて、更新後に壊れる場面も出ます。
登録済みコマンドの文字列だけを見るのではなく、対象Vault配下の mcp-tools/bin/mcp-server が本当に存在するか、実体ファイルを直接たどる視点が欠かせません。

パスにスペースや日本語を含む場合も、起動失敗の原因としてよく残ります。
Windows ではダブルクオートで全体を囲う形が扱いやすく、たとえば "C:\Users\name\Obsidian Vault\.obsidian\plugins\mcp-tools\bin\mcp-server" のように一続きで渡した方が、途中で分割されません。
macOS や Linux でも "..." でまとめるのが手堅く、シェル展開に頼らない形に寄せると誤解釈を減らせます。
日本語フォルダ名や長い階層で失敗が続くなら、検証用として英数字だけの短いパスに一時コピーしたVaultを作ると、文字コードと引数解釈の問題を切り離せます。
恒久運用にそのまま使うというより、まず起動系の障害を外すための短い代替パスです。

C. ポート/複数Vaultの切り分け

ポート競合は、MCP連携で最も再現しやすいトラブルの一つです。
22360 を使う構成では、すでに別のObsidianVaultや前回起動したプロセスがそのポートを掴んでいると、新しい接続が失敗します。
症状としては Failed to connect にまとまって見えても、実際には「サーバー未起動」ではなく「別プロセスが先に待っている」状態です。
Windows なら netstat -ano | findstr 22360、macOS と Linux なら lsof -i :22360 で現在のリスン状況を見ると、切り分けの起点になります。

競合している場合は、既存プロセスを止めるか、代替ポートを割り当てるかの二択になります。
常用Vaultと検証Vaultを同時に開く運用では、片方を別ポートにずらさないと、どちらのMCPにClaude Codeがつながっているのか曖昧になります。
複数Vaultの同時起動を避け、使うVaultだけを立ち上げる形にそろえると、接続先の誤認も減ります。
前のセクションで触れた通り、常用Vaultだけ起動して検証Vaultは必要時のみ開く運用は、ポート問題だけでなく、どの知識ベースを見ているかの追跡にも効きます。

Vaultが複数ある場合の切り分けでは、テスト用Vaultで再現できるかどうかが分岐点になります。
テスト用Vaultではつながるのに常用Vaultだけ失敗するなら、原因は有効プラグイン、Vault固有設定、パス構成のどこかにあります。
自分の経験でも、最小構成のテストVaultに切り替えて再現テストをすると、見ていた問題が「MCP全体」ではなく「このVaultの追加プラグイン」や「このVault名のパス」に縮んでいくことが多くありました。
差分として見る項目は、有効化しているプラグイン、MCPサーバーの実体パス、Vault名に含まれるスペースや日本語、ポート設定の4つが中心です。

自動発見を使う構成では、複数Vaultのどれが見えているのかが曖昧になりやすい点にも注意が必要です。
見つかったから正しいVaultとは限らず、別Vaultのサーバーを拾っていると「接続はできるのにノートが違う」という混乱が起きます。
こういう場面では、まずテストVaultだけを開いて接続先を固定し、その後に常用Vaultとの差分を一つずつ戻す方が、原因特定までの距離が短くなります。

まとめと次のアクション

着手はテスト用Vaultからが安全です。
導入の一歩目はobsidian-claude-code-mcpのような専用MCPプラグイン側から試し、流れがつかめたらLocal REST APIとMCP連携へ広げる順だと、失敗箇所の切り分けが短く済みます。
実際、私はファイル一覧取得から入り、次に検索、そこから要約へ進む三段ロケットの順番にすると、操作の勘どころを掴みながら公開範囲も絞れて、運用を崩さず進められました。

本番Vaultへ移す段階では、機密ノートを先に分離し、公開不要のAPIキーは使い回さず再発行して組み込む方が後戻りを防げます。
接続できた直後に編集権限まで広げるより、読む操作だけで小さく検証した方が、設定ミスの影響を局所化できます。
運用ルールとしては、バージョン依存や料金の確認日をメモに残します。
Obsidian Changelog（https://obsidian.md/changelogやClaude Codeの公式MCPドキュメント（https://code.claude.com/docs/ja/mcpを確認する前提で更新判断を回す形にしておくと、あとで迷いません））。