VPSでObsidian vaultをClaude Code管理する方法
Obsidian vaultはMarkdownフォルダーなので、Claude Codeでノートの再配置や監査ができます。VPSの構成と、40個のノートを一括改変させない権限ルールを解説します。
Obsidian vault で Claude Code が機能する理由
Obsidian vault は Markdown ファイルのフォルダーです。そのため、Claude Code はコードリポジトリと同じ方法で操作できます。Obsidian の公式サイトには、ノートを「プレーンテキストの Markdown ファイルとしてローカルに保存する」と記載されています。また、Obsidian のヘルプでは vault を「Obsidian がノートを保存するローカルファイルシステム上のフォルダー」と定義しています。間にデータベースはなく、エクスポートも必要ありません。
この事実が、この組み合わせが機能する理由のすべてです。Claude Code はもともとディレクトリの読み取り、テキスト検索、ファイルの直接編集、shell コマンドの実行に対応しています。vault には Markdown ファイル、各ファイルの先頭にある YAML front matter、ノート間のリンク、そして意味を持つディレクトリツリーがあります。capture の再配置やインデックスの再構築は、どちらも通常のファイル操作です。Obsidian のプラグインは必要ありません。エージェントが操作するマシンで Obsidian を起動しておく必要もありません。
ただし、ノートはコードではありません。テストが失敗すれば、エージェントがビルドを壊したことを確認できます。一方、エージェントが 40 個のノートを気付かれないまま言い換えても、それを知らせるものはありません。このガイドの大部分では、その安全策を取り戻す方法を説明します。
VPS 上で vault を実行する利点
laptop 上の vault に対して Claude Code を実行する方法は機能します。5 分で終わる作業なら、これが適切です。vault をサーバーに移すと、現実的に依頼できる作業の範囲が広がります。
- セッションが laptop の稼働時間に左右されません。サーバー上の tmux セッション内で agent を起動すれば、蓋を閉じても長時間の処理が継続します。
- SSH 接続を開ける場所ならどこからでも vault にアクセスできます。phone からもアクセスできます。
- agent は普段使いの端末とは別のマシンで動作します。そのため、ミスの影響を再構築可能な 1 台のマシンに限定できます。
- サーバー上で同期が継続するため、agent が編集したコピーを phone で数秒後に開けます。
最も重要なのは永続セッションです。構成は VPS 上の tmux 内で Claude Code を実行する方法 と同じです。handset からそのセッションに接続する方法については、phone から Claude Code を操作する方法 を参照してください。長時間のファイル再整理ジョブで 1 つのセッションを使用中に、その隣で 2 つ目のセッションを開始すると、一方のセッションからもう一方へ作業を引き渡せます。結果を手作業で中継する必要はありません。
サーバーに vault を配置する
vault 専用のディレクトリを作成します。既存の vault をノート PC から rsync でサーバーへコピーします。このコマンドはサーバーではなく、ノート PC 上で実行します。
rsync -av --exclude '.obsidian/workspace*.json' \
~/Documents/notes/ you@your-vps:vaults/notes/次に、サーバー上でコピーされた内容を確認します。
ls -a ~/vaults/notes
du -sh ~/vaults/notes最上位のフォルダーと .obsidian ディレクトリが表示されます。.obsidian には vault 固有の設定が保存されます。app.json と workspace.json も含まれます。workspace.json には開いているペインが記録されるため、デスクトップアプリでペインを移動するたびに内容が変わります。そのため、rsync 行ではこれを除外します。マシン間でコピーすると頻繁な差分が発生するだけで、利点がないためです。
ラップトップとスマートフォンに vault を同期する
Syncthing を使うと、第三者にファイルを預けずに、サーバー上のコピーと各デバイスを同期できます。Syncthing はプロジェクト独自の apt リポジトリからインストールします。
sudo mkdir -p /etc/apt/keyrings
sudo curl -L -o /etc/apt/keyrings/syncthing-archive-keyring.gpg https://syncthing.net/release-key.gpg
echo "deb [signed-by=/etc/apt/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing stable-v2" \
| sudo tee /etc/apt/sources.list.d/syncthing.list
sudo apt-get update
sudo apt-get install syncthingユーザーアカウントに紐付けた system service として実行します。
sudo systemctl enable syncthing@$USER.service
sudo systemctl start syncthing@$USER.service
systemctl status syncthing@$USER.servicestatus は active (running) を返す必要があります。Web インターフェースはデフォルトで 127.0.0.1:8384 で待ち受けるため、インターネットには公開されず、ファイアウォールルールも必要ありません。ラップトップから SSH でポート転送してアクセスします。
ssh -L 8384:127.0.0.1:8384 you@your-vps接続を確立したまま、ブラウザーで http://127.0.0.1:8384 を開き、~/vaults/notes をフォルダーとして追加して、ラップトップをペアリングします。Syncthing は Linux、macOS、Windows、Android に対応しています。公式 Android アプリは 2024 年末にリリース提供を終了しました。代わりに使われているコミュニティ版は F-Droid の Syncthing-Fork です(2026 年 8 月確認)。Syncthing の FAQ には、「現在の Syncthing チームには、近い将来 iOS を公式にサポートする予定はありません」と記載されています。そのため、iPhone では第三者製クライアントか、まったく別のツールが必要です。すでに運用しているサーバーの背後にファイルを置きたい場合は、Syncthing と Nextcloud の比較でそれぞれのトレードオフを確認できます。
Vault の横に Claude Code をインストールする
curl -fsSL https://claude.ai/install.sh | bash
claude --versionインストールが正常に完了すると、2.1.211 (Claude Code) のようなバージョンが表示されます。シェルが claude: command not found と返す場合、インストーラーはバイナリを ~/.local/bin/claude に配置しましたが、そのディレクトリが PATH に含まれていません。シェルのプロファイルに追加して、新しいシェルを開きます。claude doctor を実行すると、セッションを開始せずにインストールと設定の診断結果が表示されます。問題を確認する最も早い方法です。
Claude Code には Pro、Max、Team、Enterprise、または Console アカウントが必要です。無料の Claude.ai プランでは利用できません。Vault 内から起動してください。作業ディレクトリが、デフォルトでファイルツールのアクセス先になるためです。
tmux new -s vault
cd ~/vaults/notes
claudeCtrl-b の後に d でデタッチすると、セッションは実行を続けます。後で tmux attach -t vault で再接続できます。Claude セッション自体が終了しており、単にデタッチされているだけではない場合は、claude --resume で再開できます。セッションを再開してトランスクリプトを確認するでは、エージェントがノートに実際に行った操作を読み返す際に、サーバー上のトランスクリプトが保存されている場所を説明します。
ボルトの規約を記載した CLAUDE.md を作成する
Claude Code は、各セッションの開始時に作業ディレクトリと、その上位にあるすべてのディレクトリから CLAUDE.md を読み込みます。コードリポジトリでは、規約の半分はコード自体から確認できます。ボルトでは確認できません。ファイル内に、00-inbox/ がステージング領域であることや、アーカイブ済みのノートが変更禁止であることを示す情報はありません。規約を明文化しないと、エージェントは推測します。
# Vault conventions
## Layout
- `00-inbox/` holds unfiled captures. Only I write here.
- `10-notes/` holds permanent notes, one idea per file.
- `20-daily/` holds daily notes named `YYYY-MM-DD.md`.
- `90-archive/` is frozen. Never edit anything under it.
## Rules
- Every note opens with an H1 that matches its filename.
- Front matter holds `tags` and `created` only. Do not invent fields.
- Link by note name using Obsidian double bracket links. No paths, no `.md`.
- Never rename or move a file. Ask me instead.
- Never edit more than five files in one go without listing them first.200 行未満に収めてください。Claude Code のドキュメントでは、この長さを目安としています。ファイルが長いほどコンテキストウィンドウを多く消費し、規約も一貫して適用されにくくなるためです。セッション中に /context を実行し、Memory files の下に表示される一覧を確認して、読み込まれたことを確認します。Claude Code が読み込むのは CLAUDE.md であり、AGENTS.md ではありません。別のツール用にどちらかをすでに使用している場合は、AGENTS.md と CLAUDE.md の関係を参照してください。数千件のノートがあるボルトでは、大規模なリポジトリと同じ制限に達します。この点については、Claude Code でのコンテキスト管理で説明しています。
権限ルールで一括書き換えを防ぐ
これを vault 内の .claude/settings.json として保存します。
{
"permissions": {
"defaultMode": "plan",
"deny": [
"Read(/90-archive/**)",
"Edit(/90-archive/**)",
"Bash(rm *)"
],
"ask": [
"Bash(git push *)",
"Bash(mv *)"
],
"allow": [
"Bash(git status)",
"Bash(git diff *)"
]
}
}このファイルについて知っておくべき点は4つあります。いずれも、実際の運用で問題になったことがある点です。
- ルールは deny、ask、allow の順に評価され、最初に一致したルールで決まります。具体性によって順序は変わらないため、広い deny ルールの中に allow-list の例外を設定することはできません。
Readの deny ルールは、同じパスに対する Edit ツールと Write ツールもブロックします。その場所に新しいファイルを作成する操作も対象です。一致するEditルールも追加すれば、Readルールが対象にできない組み込みツールもカバーできます。- Claude Code は、ファイルパスを
Edit(path)ルールとRead(path)ルールに対してのみ確認します。Write(...)またはGlob(...)のパスルールを書いても受け付けられますが、参照されません。起動時には、ファイル権限チェックに一致しないルールとして報告されます。Write(...)のつもりならEdit(...)を使用してください。 permissions.defaultModeをplanに設定すると、Claude はファイルを読み取り、読み取り専用コマンドを実行しますが、計画を承認するまでノートを編集しません。acceptEditsはその逆で、確認なしにすべてのファイル編集を受け付けます。vault では、planが適切なデフォルトです。
Read ルールと Edit ルールでは、gitignore のパターン構文を使用します。Read(/90-archive/**) の先頭にあるスラッシュは、パターンをプロジェクトルートに固定します。そのため、vault の最上位にある 90-archive/ に一致し、それ以外には一致しません。スラッシュを付けずに記述すると、deny ルールは vault 配下の任意の階層にある同名のディレクトリに一致します。Private というフォルダーには、通常こちらの指定を使用します。ルールが適用されると、ツールは File is covered by a Read deny rule in your permission settings を返します。
1つ、明確にしておくべき制限があります。これらのルールが対象にするのは、Claude の組み込みファイルツールと、Bash で認識されるファイルコマンド(cat、head、tail、sed など)です。スクリプトが独自にファイルを開く場合は対象になりません。そのため、最初の防御層は設定ではなく配置です。モデルに絶対に読ませたくないものは、vault のルート配下に置かないでください。deny ルールは第2層です。VPS 上で Claude Code を安全に実行する方法では、マシンレベルの対策を説明しています。auto mode と権限設定では、各モードについて詳しく説明しています。
Git を保管庫の取り消しボタンにする
保管庫にはテストスイートがないため、バージョン管理が唯一の安全網になります。エージェントに保管庫を見せる前に、リポジトリにします。
cd ~/vaults/notes
git init
printf '.obsidian/workspace*.json\n.trash/\n*.sync-conflict-*\n' >> .gitignore
git add -A
git commit -m "Vault before the agent touches it"ジョブを開始する前にコミットします。終了後ではありません。開始時の作業ツリーがクリーンなら、終了後の差分はエージェントの作業だけになります。git status は、編集を行う各プロンプトの前に nothing to commit, working tree clean を出力する必要があります。
git diff --stat
git restore .git diff --stat は、変更されたすべてのファイルと、各ファイルで移動した行数を表示します。その一覧が想定より長い場合、git restore . ですべての未コミット変更を作業ツリーから破棄し、保管庫を開始時の状態に戻せます。すでにコミット済みの場合、git revert <sha> で以前のコミットを取り消す新しいコミットを作成します。
git と同期処理が組み合わさると、問題が起きます。Syncthing が保管庫のフォルダーを共有している場合、.git も他のすべてのファイルと一緒に複製されます。2 台のマシンが同時に git のインデックスを書き込むと、リポジトリ内に競合ファイルが生成されます。git はサーバー上だけで使用し、保管庫のルートにある .stignore ファイルへ .git を追加します。
.git
.obsidian/workspace*.json引き継ぐ価値のある3つのジョブ
これらはスクリプトではなく、プロンプトです。どれも、実行後に git diff --stat で結果を確認できるように記述されています。
インデックス用ノートを再構築する
Read every file in 10-notes/ and rewrite 10-notes/index.md so it lists each
note under its primary tag, sorted alphabetically within each tag, using the
one-line summary from each note's front matter. Change no file except
index.md. Show me the plan before you write anything.制約はプロンプト内に記述されており、検証対象も同じです。git diff --stat の結果には1つのファイルだけが含まれている必要があります。複数のファイルが示された場合は、git restore . を実行し、対象をより限定して指定します。
孤立ファイルとリンク切れを見つける
List every note in 10-notes/ that no other note links to, and every link in
the vault that points at a file that does not exist. Write the results to
90-reports/orphans.md and edit nothing else.リンクの監査では、vault 全体を対象にテキスト検索を行います。これは、このツールが特に得意とする作業です。1つのレポートファイルを除き、既存の内容は読み取り専用で扱われます。そのため、エージェントがノートをどのように扱うかを把握している途中の最初のジョブとして適しています。
会議の記録をタスクに変換する
Read 00-inbox/2026-08-19-standup.md. For each action item, create one file in
10-notes/tasks/ named after the action, with front matter holding owner, due
and status. Leave the source file untouched. List the files you created.既存の内容は変更されないため、ロールバックは新しく作成されたファイルを削除するだけです。プロンプトの文言よりも、この性質がジョブを安全に試せる理由になります。
毎回、差分を確認してください。CLAUDE.md はモデルが読むガイダンスであり、クライアントが強制するルールではありません。そのため、実際に何が起きたかを記録する正式な情報として、git diff --stat のファイル一覧を扱ってください。
発生する問題
File is covered by a Read deny rule in your permission settings で読み取りに失敗する。 読み取り対象のパスに deny ルールが一致しています。deny ルール内の、先頭に / がない単一セグメントのディレクトリパターンは、任意の深さで一致します。そのため、Read(archive/**) は 10-notes/archive/ もブロックします。先頭にスラッシュを付けて、1 か所だけに一致するよう固定します。
起動時に、ファイル権限チェックではルールが一致しないと Claude Code が警告する。 ファイルチェックが参照しないツール用のパスルールを記述しています。Write(90-archive/**) を Edit(90-archive/**) に置き換えると、警告は消えます。
ファイル名に sync-conflict が付いたファイルが現れる。 Syncthing は同時編集の一方を、<filename>.sync-conflict-<date>-<time>-<modifiedBy>.<ext> のパターンを使ってリネームします。エージェントがサーバー上のノートを編集している間に、ノートパソコンでも同じノートを開いていると発生します。編集場所を同時に複数にせず、切り替える前に同期が完了するまで待ちます。
エージェントがノートを移動した後、リンクが壊れる。 Obsidian は、Obsidian 内でリネームされた場合に内部リンクを書き換えます。別のプロセスが行ったリネームは認識できません。そのため、サーバー上のエージェントが移動したファイルは、すべてのリンクが古い名前を指したままになります。これが、vault の CLAUDE.md に「ファイルをリネームまたは移動しない」と記載し、リネームはデスクトップアプリで行う理由です。
言及していないノートをエージェントが編集する。 permissions.defaultMode を確認します。acceptEdits では、すべてのファイル編集がプロンプトなしで承認されます。plan に設定すると、計画を承認するまでセッションは読み取り専用で開始されます。
FAQ
Obsidian の vault で Claude Code を使うには、Obsidian プラグインが必要ですか?
いいえ。Obsidian は通常のフォルダー内にノートをプレーンテキストの Markdown ファイルとして保存するため、Claude Code は通常のファイル操作ツールでそれらを読み書きできます。Obsidian 内には何もインストールしません。Obsidian を起動しておく必要もありません。エージェントがファイルを操作し、Obsidian はそのファイルを読み込む複数のプログラムの 1 つです。
Claude Code が vault 内の非公開ノートを読み取らないようにするには、どうすればよいですか?
非公開ノートを vault のディレクトリの外に置いてください。これが確実な対策です。権限ルールが対象にするのは Claude の組み込みファイル操作ツールと、Claude が認識する Bash のファイルコマンドであり、ファイルを直接開くスクリプトではないためです。第 2 層の対策として、.claude/settings.json のパスに対する Read と Edit の deny ルールを両方追加してください。そこにあるファイルを 1 つ開くよう Claude に指示してルールをテストします。読み取りがブロックされると、File is covered by a Read deny rule in your permission settings が返ります。
Claude Code によって Obsidian のリンクが壊れることはありますか?
特定の方法では、壊れる可能性があります。Obsidian は Obsidian 内でノートの名前を変更すると内部リンクを更新しますが、別のプロセスによる名前変更は認識できません。サーバー上でエージェントがファイルを移動すると、リンクは古い名前を指したままになります。CLAUDE.md に、ファイルの名前変更や移動を決して行わないようエージェントへ指示し、名前変更はデスクトップアプリで実施してください。ノートの内容の編集は安全です。リンクはファイル内のプレーンテキストだからです。
VPS ではなく、ノート PC 上の vault に対して実行できますか?
はい。CLAUDE.md、権限ルール、git の運用方法は同じです。サーバーを使うと、蓋を閉じても継続するセッションと、SSH 接続を開ける任意のデバイスからのアクセスが得られます。目の前の作業でそのどちらも必要ないなら、ローカルで実行してください。マシン自体を管理したくないことが主な理由なら、Cowork は Anthropic sandbox 内で、接続したフォルダーを対象に実行できます。Cowork と Claude Code の比較では、このような vault にどちらが適しているかを説明しています。
vault を git リポジトリにする必要はありますか?
Claude Code の動作に git リポジトリは必要ありません。ただし、安全のためには必要です。vault にはテストスイートがないため、作業後に git diff --stat を実行すると実際の変更内容を最も低コストで確認でき、git restore . は変更を元に戻す最も低コストな方法です。各作業の前に commit して、diff にエージェントの作業だけが表示されるようにしてください。Syncthing でフォルダーを共有する場合は、.git を .stignore に追加し、リポジトリがデバイス間で複製されないようにしてください。