Claude Code×Obsidian連携｜Vaultを直接操作する7手順

Q: Claude Codeが .obsidian フォルダを書き換えないようにするには？

Vaultルートの .claude/settings.json に "deny": ["Edit(./.obsidian/**)"] を入れます。公式の権限仕様では、ファイル操作の権限は Edit(path) と Read(path) のルールだけが照合され、Write(path) の形で書いても参照されません。迂回まで止めたい場合は、PreToolUse フックで tool_input.file_path に /.obsidian/ が含まれる呼び出しを拒否します。

Q: サーバー上で定期実行するときの注意は？

claude -p はワークスペースの信頼ダイアログを出さずに、そのフォルダのフックを実行し .mcp.json のサーバーに接続します。Vaultに置く設定は拒否ルールと保護フックだけに絞り、--allowedTools は Read,Edit に限定してBashを渡さない形が基本です。--bare を付けるとCLAUDE.mdもフックも読まれないので、Vaultに書き戻すジョブでは使いません。

ObsidianのVaultはMarkdownの入ったフォルダなので、Claude Codeは専用MCPなしで読み書きできます。.obsidianの保護、wikilinkとプロパティの規約、CLIとSkillsの足し方を公式情報で整理。

2026年9月16日時点の結論。ObsidianとClaude Codeをつなぐのに、専用のMCPサーバーは要らない。ObsidianのVaultは「Markdownファイルが入ったローカルのフォルダ」であり、Obsidian公式ヘルプも他のテキストエディタで編集できること、外部からの変更を自動で反映することを明記している。Claude CodeはそのフォルダをそのままRead・Edit・Grepで扱えるので、連携の実装は「Vaultを作業ディレクトリにする」「.obsidian と機密ノートを権限で守る」「Obsidian記法の規約をCLAUDE.mdに書く」の3つで成立する。検索・デイリーノート・タスク一覧のようにアプリ側の機能が欲しいときだけ、Obsidian CLIか公開されているSkillsを足す。

「claude code obsidian」で検索している人が知りたいのは、たいてい「MCPサーバーを入れるべきか」「設定を壊されないか」「wikilinkを普通のMarkdownリンクに書き換えられないか」の3点だ。この3点は接続の話ではなく、作業ディレクトリと権限と規約の話で決まる。ここを先に押さえると、ObsidianのVaultはClaude Codeにとって「読み書きできる知識ベース」になり、Obsidianアプリ側は「人が読むための画面」に専念できる。

この記事の要点

入口：Vaultのフォルダで claude を起動するか、既存プロジェクトから --add-dir でVaultを足す。MCPサーバーは既定では不要。
守る対象：.obsidian/ 配下は Edit(./.obsidian/**) の拒否ルールで書き込み禁止にし、機密ノートのフォルダは Read も拒否する。書き込みの拒否ルールは Write(...) ではなく Edit(...) で書く（公式の権限仕様）。
規約：ノート間リンクは [[ノート名]]、外部URLだけ [text](url)、先頭にプロパティ、埋め込みは ![[ファイル名]]。この4行をCLAUDE.mdに置く。
足すもの：検索・デイリーノート・タスク・差分はObsidian CLI（Obsidian 1.12.7以降のインストーラで有効化）、記法の詳細はGitHubで公開されている kepano/obsidian-skills。
データ化：プロパティを揃えれば、Obsidian標準のBasesがそのまま表やカードの一覧になる。
対象読者：ObsidianにチームやプロジェクトのメモをMarkdownで蓄積している開発者、技術リード、ドキュメント担当。
今日やること：Vaultのルートに .claude/settings.json を作り、.obsidian/** への Edit 拒否ルールだけ先に入れる。

手順1｜連携の入口を決める（直接操作・Obsidian CLI・MCPの3経路）

ObsidianとClaude Codeをつなぐ経路は3つある。多くの解説記事が最初にMCPサーバーの導入から始めるが、順番は逆でよい。

ObsidianのVaultを中心に、Claude Codeの直接操作・Obsidian CLI・MCPサーバー・Obsidianアプリの4つがつながる関係を示した図 — Vaultはフォルダなので、直接操作が第一の経路になる

経路	何を使うか	向いている作業	前提
直接操作	Claude Codeの標準ツール（Read・Edit・Glob・Grep）	ノートの作成・整形・リンク付け・一括修正	Vaultがローカルのフォルダであること
Obsidian CLI	`obsidian` コマンド	検索・デイリーノート・タスク一覧・版の差分・プラグイン開発	Obsidian 1.12.7以降、アプリが起動していること
MCPサーバー	コミュニティ製のObsidian向けMCPサーバー	アプリ内部の状態をツール経由で取りたい特殊用途	サーバーごとの認証と保守

Obsidian公式ヘルプは、ノートを「Vaultと呼ぶフォルダの中のMarkdown形式のプレーンテキストファイル」として保存すること、そして「プレーンテキストなので他のテキストエディタやファイルマネージャで編集・管理でき、Obsidianは外部の変更に合わせてVaultを自動で更新する」ことを明記している（How Obsidian stores data）。つまりClaude Codeがファイルを直接書き換えても、Obsidian側は追加の同期処理なしに表示を更新する。

この仕様があるため、第一の経路は「直接操作」になる。Claude Codeは作業ディレクトリ内のファイルを読み書きするための道具であり、Vaultは作業ディレクトリとして扱えるフォルダだ。MCPサーバーの出番は、アプリの内部状態（開いているタブ、選択範囲、プラグインの状態）をツールとして取りたいときに限られる。日々のノート整理でそこまで必要になる場面は少ない。

Obsidian CLIは中間の選択肢だ。Obsidian公式は「Obsidianでできることはコマンドラインからもできる」と位置づけており、検索・デイリーノートへの追記・タスク一覧・ファイルの版の比較・プラグインのリロードなどを obsidian コマンドから実行できる（Obsidian CLI）。ただしアプリが起動している必要があるので、サーバー上のバッチ処理には向かない。手順5で扱う。

手順2｜Vaultを作業ディレクトリにする（`--add-dir` とスコープ）

もっとも単純な形は、Vaultのフォルダに移動して起動するだけだ。

cd ~/Obsidian/TeamNotes
claude

Vaultのルートに置いた CLAUDE.md と .claude/settings.json がそのまま読まれる。ObsidianのVaultは「ローカルのファイルシステム上のフォルダ」であり、既存のフォルダをVaultとして開くこともできる（Create a vault）。したがって、すでにGitで管理しているドキュメントのフォルダをObsidianで開く、という逆方向の設計も成立する。

コードのリポジトリを作業しながら、参照用のVaultも読ませたい場合は --add-dir を使う。

cd ~/work/service-api
claude --add-dir ~/Obsidian/TeamNotes

Claude Code公式のCLIリファレンスは --add-dir を「Claudeがファイルを読み書きできる追加の作業ディレクトリ」と定義し、セッションをまたいで固定したい場合は設定の permissions.additionalDirectories を使うよう案内している（CLI reference）。セッション中に足すなら /add-dir コマンドでもよい。

注意点が1つある。--add-dir で足したディレクトリからは、そのディレクトリの .claude/skills/ にあるSkillは読み込まれるが、.claude/ 配下の設定のすべてが読まれるわけではない。Vault側にObsidian用の権限ルールを置くつもりなら、Vaultを主の作業ディレクトリにして起動するほうが設定の所在が明確になる。逆に、複数のリポジトリから同じVaultを参照する運用なら、Vault側にSkillを置き、権限ルールは各リポジトリかユーザー設定に置く。この使い分けが手順3の前提になる。

もう1つ、Obsidian公式は「Vaultの中にVaultを作らない」ことを推奨している。内部リンクはVault単位で解決されるため、入れ子にするとリンクの更新が正しく動かないことがある（How Obsidian stores data）。Claude Codeに「サブフォルダを新しいVaultとして切り出す」ような指示を出す前に、この制約を思い出したい。

手順3｜`.obsidian` と機密ノートを権限で守る

Vaultのルートには .obsidian という設定フォルダがあり、ホットキー・テーマ・コミュニティプラグインなど、そのVault固有の設定が入っている（Configuration folder）。Claude Codeに「Vault全体を整理して」と頼んだときに、ここを触られると設定が壊れる。まずこの1点を止める。

Claude Codeからの編集と読み取りが拒否ルールとフックの2段の関所を通り、.obsidianと90_Privateは止まり、ノートだけが通る図 — 拒否ルールで広く止め、フックで細かく判断する

Claude Code公式の権限仕様には、ファイル操作の権限チェックで使われるルールについて明確な記述がある。ファイルへの権限は Edit(path) と Read(path) のルールに対してのみ照合され、Write(path) や Glob(path) のようなパス付きルールは受け付けられても参照されず、起動時に警告が出る。書き込みを止めたいなら Edit(docs/**) の形で書く（Configure permissions）。この仕様を知らずに Write(./.obsidian/**) と書いてしまうのが、Obsidian連携でいちばん多い設定ミスになる。

Vaultのルートに .claude/settings.json を置く。

{
  "permissions": {
    "deny": [
      "Edit(./.obsidian/**)",
      "Read(./.obsidian/plugins/**)",
      "Edit(./90_Private/**)",
      "Read(./90_Private/**)"
    ]
  }
}

Edit(./.obsidian/**)：設定フォルダへの書き込みを止める。読み取りは残しておくと、Claude Codeが「どのプラグインが有効か」を確認して記法を合わせられる。
Read(./.obsidian/plugins/**)：外部サービスに接続するコミュニティプラグインを使っているなら、その設定ファイルにトークンが保存されている可能性があるので読み取りも止める。公式の権限ガイドも、秘密情報を含むファイルには Read の拒否ルールを使うよう案内している。
Edit(./90_Private/**) と Read(./90_Private/**)：人事メモや契約の下書きなど、Claude Codeに見せないフォルダを1つ決めて両方止める。

パスの書き方には注意がある。公式の仕様では、./path または path は現在のディレクトリからの相対、/path は「設定ファイルの置き場所」からの相対、//path がファイルシステムのルートからの絶対パス、~/path がホームからのパスとして扱われる。ユーザー設定（~/.claude/settings.json）に Edit(/.obsidian/**) と書くと ~/.claude/.obsidian/** を指してしまい、Vaultは守られない。すべてのVaultに効くルールをユーザー設定に置きたいなら、Edit(//Users/<name>/Obsidian/**/.obsidian/**) のように // で始める。

設定ファイルによる拒否で足りない場合、たとえば「Vaultの外にコピーしてから編集する」ような迂回を止めたいときは、フックを重ねる。PreToolUse フックは Edit|Write のマッチャーで発火させ、tool_input.file_path（Write・Edit・Readでは常に絶対パス）に /.obsidian/ が含まれていれば拒否を返す。

#!/bin/bash
# .claude/hooks/protect-obsidian.sh
INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')
case "$FILE_PATH" in
  */.obsidian/*)
    cat <<'JSON'
{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"Obsidianの設定フォルダは編集対象外です"}}
JSON
    ;;
esac
exit 0

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/protect-obsidian.sh" }
        ]
      }
    ]
  }
}

拒否ルールとフックは役割が違う。拒否ルールは「そのパスを編集するツール呼び出し」を止める。フックは「呼び出しの中身を見て判断する」ので、パスの表記ゆれや条件付きの許可（たとえば特定のプラグインの設定だけ許す）に対応できる。まず拒否ルールで広く止め、例外が必要になったらフックで細かく開ける順番が安全だ。権限設計の考え方全体は権限設計ガイド、フックの書き方はHooks実践ガイドで扱っている。

手順4｜Obsidian記法の規約をCLAUDE.mdに書く（wikilink・プロパティ・埋め込み）

Claude Codeは何も指示しなければ、一般的なMarkdownの作法で書く。リンクは [表示名](パス.md) 形式になり、ノートの先頭にプロパティは付かず、画像は ![alt](path) で貼られる。Obsidianはどれも読めるが、Vaultの中で書き方が2種類に割れる。ここを規約として固定するのが手順4で、書く場所はVaultルートの CLAUDE.md だ。

CLAUDE.mdの中にプロパティ・本文の記法・リンクの3層が積まれ、各層に代表的な記法が添えられた図 — 規約は3層に分けてCLAUDE.mdに置く

規約は3層に分けると整理しやすい。先頭のプロパティ、本文の記法、そしてリンクの3つだ。

プロパティ。Obsidianのプロパティはファイルの先頭に --- で囲んで書く構造化データで、tags・cssclasses・aliases が既定のプロパティとして用意されている。型はテキスト・リスト・数値・チェックボックス・日付・日時・タグの7種類で、プロパティの型は名前ごとに決まる（Properties）。Claude Codeに「status には draft か reviewed だけを入れる」と決めさせておくと、手順6のBasesでそのまま絞り込みに使える。

本文の記法。ObsidianはCommonMark・GitHub Flavored Markdown・LaTeXに加えて、![[ファイル名]] の埋め込み、![[ノート名#^id]] のブロック参照、%%コメント%% のコメント記法を持つ。注意点として、HTML要素の中ではMarkdownが描画されない仕様で、<div> や <table> で囲んだ中の **太字** は効かない（Obsidian Flavored Markdown）。Claude Codeが「見栄えのため」にHTMLの表を作ると、中の記法が死ぬ。表はMarkdownの表で書かせる。

リンク。Obsidianの内部リンクはwikilink [[ノート名]] とMarkdown形式 [ノート名](ノート名.md) の両方に対応し、両者は等価だが、既定ではwikilinkが生成される。フォルダ内のノートはVaultルートからのパスを / 区切りで書き、存在しないノートへのリンクはそのパスにノートが作られる。ファイル名を変えたとき、Obsidianは内部リンクを自動で更新する設定を持つ（Internal links）。Claude Codeがリネームを含む整理をするときは、Obsidian側のこの自動更新に頼らず、Claude Code自身にリンクの書き換えまで任せるほうが、アプリを開いていない状態でも整合が取れる。

この3層をCLAUDE.mdに落とすと、次のような短い形になる。

# このVaultの書き方

## プロパティ
- 新規ノートの先頭に `---` で `tags` / `aliases` / `status` を置く
- `status` は draft / reviewed のどちらか。他の値を作らない

## 本文の記法
- 表はMarkdownの表で書く。HTMLの <table> や <div> で囲まない
- 画像・PDFは `![[ファイル名]]` で埋め込む
- 一時的なメモは `%%` で囲んでコメントにする

## リンク
- Vault内のノートへは `[[ノート名]]` の wikilink で書く
- 外部URLだけ `[表示名](URL)` を使う
- フォルダ内のノートは `[[30_Decisions/ノート名]]` のようにVaultルートからのパスで書く
- ノートをリネームしたら、そのノートへの wikilink を全件書き換えてから終了する

## 触らない場所
- `.obsidian/` と `90_Private/` は読み書きしない

Claude Code公式は、プロジェクトのCLAUDE.mdを ./CLAUDE.md または ./.claude/CLAUDE.md に置くこと、1ファイルは200行以内を目安にすること、読み込まれたかは /context の「Memory files」で確認できることを案内している（How Claude remembers your project）。/init は既存のコードベースを解析してCLAUDE.mdの叩き台を作るコマンドなので、ノートしかないVaultでは手で書くほうが早い。規約が増えてきたら .claude/rules/ にトピック別のファイルとして分割できる。CLAUDE.mdの設計そのものはCLAUDE.md設計・運用ガイドを参照してほしい。

手順5｜Obsidian CLIとobsidian-skillsで足りない部分を補う

直接操作で足りるのはファイルの作成・整形・一括修正までだ。「先週のデイリーノートに残ったタスクを一覧にして」「このノートの3つ前の版と比べて」のようにObsidianアプリの機能を前提にした指示は、ファイル操作だけでは答えられない。ここで足すのがObsidian CLIだ。

左に直接操作でできる作成・整形と一括修正、右にObsidian CLIを足すと届く検索・デイリーノート・タスク一覧・版の差分を並べた図 — 直接操作で足りる範囲と、Obsidian CLIを足して届く範囲

Obsidian CLIはObsidian公式の機能で、利用にはObsidian 1.12.7以降のインストーラが必要になる。有効化はアプリの設定から「General」→「Command line interface」を有効にし、案内に従って登録する。Obsidianアプリが起動していることが前提で、起動していなければ最初のコマンドがアプリを立ち上げる（Obsidian CLI）。ターミナルの作業ディレクトリがVaultならそのVaultが対象になり、別のVaultを指すときは vault= を最初のパラメータに置く。

# 利用できるコマンド一覧
obsidian help

# Vault内を検索する
obsidian search query="接続エラー" limit=10

# 今日のデイリーノートにタスクを足す
obsidian daily:append content="- [ ] 権限ルールをレビューする"

# デイリーノートのタスクを一覧にする
obsidian tasks daily

# タグを件数つきで一覧にする
obsidian tags counts

# ファイルの版を比較する
obsidian diff file=README from=1 to=3

ファイルの指定には2通りある。file= はwikilinkと同じ解決規則でファイル名だけから探し、path= はVaultルートからの正確なパスを要求する。同名ノートがVault内に複数あるなら path= を使う。Claude Codeからこれらを呼ぶには、Bashツール経由で obsidian ... を実行させればよく、毎回の確認を省くなら permissions.allow に Bash(obsidian *) を足す。ただし Bash(...) のプレフィックス一致には迂回の余地があるので、書き込み系のコマンドまで許可するかはチームの方針で決める。

記法の詳細をClaude Codeに毎回説明するのが面倒なら、GitHubで公開されている kepano/obsidian-skills を入れる。Agent Skillsの仕様に沿ったSkillの集まりで、Claude Code・Codex・OpenCodeのようなSkill対応エージェントから使える。収録されているのは obsidian-markdown（wikilink・埋め込み・コールアウト・プロパティ）、obsidian-bases（.base ファイル）、json-canvas（.canvas ファイル）、obsidian-cli、defuddle、knap の6つで、ライセンスはMITだ（kepano/obsidian-skills）。

/plugin marketplace add kepano/obsidian-skills
/plugin install obsidian@obsidian-skills

導入はマーケットプレイス経由が案内されているほか、リポジトリの内容をVaultルートの .claude フォルダに置く方法も書かれている。Claude Code側の仕様では、プロジェクトのSkillは .claude/skills/<名前>/SKILL.md、個人のSkillは ~/.claude/skills/ に置き、プラグイン由来のSkillは /プラグイン名:スキル名 で呼び出せる（Extend Claude with skills）。手順2で --add-dir を選んだ場合も、追加ディレクトリの .claude/skills/ は読み込まれるので、Vault側にSkillを置く設計が成立する。組織単位でSkillの配布を管理したい場合は全社ガバナンスの記事に整理がある。

MCPサーバーを選ぶ場面は残る。アプリの内部状態をツール経由で取りたい、あるいはClaude Code以外のMCPクライアントからも同じ経路でVaultに触りたい、という要件があるときだ。その場合はコミュニティ製のサーバーごとに認証と保守が発生するので、MCP実践ガイドのスコープ設計を先に読んでから決めるとよい。

手順6｜Basesとプロパティでノートをデータとして扱う

手順4でプロパティを揃えた効果が出るのがここだ。ObsidianのBasesは標準機能（コアプラグイン）で、ノートをデータベースのような一覧として表示し、プロパティで並べ替え・絞り込み・編集ができる。データはあくまでMarkdownファイルとそのプロパティに入っており、一覧の定義だけが .base ファイル、またはMarkdown内のコードブロックとして保存される。表示はテーブル・リスト・カードの3種類が用意されている（Introduction to Bases）。

つまり、Claude Codeがプロパティを機械的に揃えるだけで、Obsidian側には追加のツールなしに「決定事項の一覧」「レビュー待ちの一覧」が現れる。逆に、プロパティの名前や値が揺れていると、Basesの絞り込みは効かない。Claude Codeへの指示は次のように「既存の値を変えない」を明示する。

30_Decisions/ 配下の全ノートを確認し、先頭のプロパティに status が無いものだけ
status: draft を追加してください。既存の status の値は変えないでください。
変更したファイルの一覧と、status の値ごとの件数を最後に出してください。

.base ファイルの中身まで書かせたい場合は、手順5の obsidian-bases Skillを入れてから頼む。記法の説明を自分で書くより、公開されているSkillに任せるほうが、Obsidian側の仕様変更に追随しやすい。

手順7｜定期処理は `claude -p` でVaultに書き戻す

対話で一度うまくいった整理は、claude -p の非対話モードで定期処理にできる。流れは「収集」「整形」「書き戻し」「Obsidianで確認」「修正指示」の5つで、最後の修正指示がCLAUDE.mdの規約に戻ってくる。

claude -pによる収集・整形・書き戻しの後にObsidianで確認し、修正指示がCLAUDE.mdへ戻る循環を示した図 — 修正指示がCLAUDE.mdの規約に戻る循環

cd ~/Obsidian/TeamNotes
claude -p "10_Inbox/ にある今週作成のノートを読み、20_Weekly/ に今週のまとめノートを1本作ってください。\
各項目には元ノートへの wikilink を付け、先頭に status: draft を置いてください。" \
  --allowedTools "Read,Edit" \
  --output-format json

Claude Code公式は claude -p を「対話モードなしで応答を出力する」モードとして定義し、--allowedTools で確認なしに実行してよいツールを指定し、--output-format json で結果を構造化して受け取れるとしている（Run Claude Code programmatically）。Vaultのジョブでは --allowedTools を Read,Edit に絞り、Bashを渡さないのが基本形だ。

2つ注意がある。第一に、-p はワークスペースの信頼ダイアログを出さずに、そのフォルダの .claude/settings.json のフックを実行し、.mcp.json のサーバーに接続する。Vaultに置く設定は手順3の拒否ルールと保護フックだけに絞り、出所の分からない設定を混ぜない。第二に、--bare を付けるとCLAUDE.md・フック・Skillの自動読み込みが省かれる。起動は速くなるが、手順4の規約も手順3の保護フックも読まれないので、Vaultに書き戻すジョブでは --bare を使わない。定期実行の組み方全般はバッチ処理・定期実行の記事、-p の出力の扱いはヘッドレス自動実行ガイドにまとめている。

想定モデル：開発チームの技術メモVaultをClaude Codeで整える

ここからは実在の顧客事例ではなく、上の7手順を1つのチームに当てはめた想定シナリオだ。所要時間や削減率のような測定値は置かない。

バックエンド開発チームが、障害対応のメモ・設計の決定事項・手順書をObsidianのVaultに溜めているとする。フォルダは 10_Inbox（書きっぱなし）、20_Weekly（週次まとめ）、30_Decisions（決定事項）、40_Runbooks（手順書）、90_Private（人事・契約）の5つ。困りごとは「Inboxが溜まる」「決定事項に status が付いたり付かなかったりする」「手順書のリンクが切れている」の3つだった。

1週目：Vaultルートに .claude/settings.json を置き、.obsidian/** の編集と 90_Private/** の読み書きを拒否する。CLAUDE.mdに手順4の規約を書く。ここまでで、Claude Codeに「Vault全体を見て」と頼んでも触ってはいけない場所が決まる。
2週目：対話で 10_Inbox の整理を試す。「今週のノートを読んで 20_Weekly にまとめを1本作り、元ノートへ wikilink を張る」を数回まわし、出力を見て規約を直す。ここで「表をHTMLで書かないで」のような修正指示がCLAUDE.mdに戻る。
3週目：30_Decisions のプロパティを揃える。status が無いノートに draft を足し、Obsidian側にBasesで status ごとの一覧を1枚作る。レビューはObsidianの画面で人が行い、reviewed への変更も人が入れる。
4週目以降：2週目の指示を claude -p にして週次で回す。40_Runbooks のリンク切れは、Claude Codeに「存在しないノートへの wikilink を列挙して」と頼み、直すか消すかは人が決める。

この想定の要点は、Claude Codeの仕事を「書きっぱなしを整える」「プロパティを揃える」「壊れたリンクを見つける」に限定し、判断（reviewedにするか、リンクを消すか）を人とObsidianの画面に残していることだ。

つまずきやすい5点

Write(./.obsidian/**) と書いて守れていない。ファイルの権限チェックは Edit(path) と Read(path) だけが対象で、Write のパス付きルールは参照されず起動時に警告が出る。Edit(./.obsidian/**) に書き直す。
ユーザー設定に /path で書いて別の場所を指している。~/.claude/settings.json の Edit(/.obsidian/**) は ~/.claude/.obsidian/** を意味する。全Vault共通のルールは // で始まる絶対パスか ~/ で書く。
Vaultの中にVaultを作ってしまう。内部リンクはVault単位で解決されるため、公式は入れ子を推奨していない。サブフォルダを別Vaultに切り出す指示は出さない。
--bare で規約もフックも読まれていない。claude -p --bare はCLAUDE.md・フック・Skillの自動読み込みを省く。Vaultに書き戻すジョブでは外す。
Obsidian CLIをサーバーで動かそうとする。CLIはObsidianアプリの起動が前提で、起動していなければアプリを立ち上げようとする。アプリのない環境の定期処理は、直接操作（Read・Edit）だけで完結する形に寄せる。

まとめ｜今日からの3手

Vaultルートに .claude/settings.json を作り、Edit(./.obsidian/**) の拒否ルールを入れる。機密フォルダがあれば Read と Edit の両方を止める。
CLAUDE.mdに「wikilink・プロパティ・埋め込み・触らない場所」の規約を書き、/context で読み込まれたことを確認する。
10_Inbox から 20_Weekly へのまとめを対話で数回試し、安定したら claude -p の週次ジョブにする。

3つとも設定と文章だけで終わり、MCPサーバーの導入は要らない。Obsidianに置いた手順書やマニュアルの構造そのものを見直したい場合は社内マニュアルをDiátaxisで仕組み化する記事を、READMEや仕様書の生成まで広げるならドキュメント生成の記事を続けて読んでほしい。

よくある質問

Obsidian連携にMCPサーバーは必須ですか？

必須ではありません。Obsidian公式ヘルプは、ノートがVaultというローカルフォルダ内のMarkdownファイルであること、他のエディタで編集でき、外部の変更を自動で反映することを明記しています。Claude Codeは作業ディレクトリのファイルを標準ツールで読み書きできるので、Vaultをそのまま作業ディレクトリにすれば連携は成立します。MCPサーバーが要るのは、アプリの内部状態をツール経由で取りたい特殊な用途に限られます。

Claude Codeが `.obsidian` フォルダを書き換えないようにするには？

Vaultルートの .claude/settings.json に "deny": ["Edit(./.obsidian/**)"] を入れます。公式の権限仕様では、ファイル操作の権限は Edit(path) と Read(path) のルールだけが照合され、Write(path) の形で書いても参照されません。迂回まで止めたい場合は、PreToolUse フックで tool_input.file_path に /.obsidian/ が含まれる呼び出しを拒否します。

wikilinkではなく普通のMarkdownリンクで書かれてしまいます。

CLAUDE.mdに「Vault内のノートへは [[ノート名]] で書く。外部URLだけ [表示名](URL) を使う」と書きます。Obsidianはwikilink形式とMarkdown形式の内部リンクを等価に扱いますが、既定で生成されるのはwikilinkなので、Vault内の表記を揃えるならwikilinkに寄せるのが自然です。フォルダ内のノートはVaultルートからのパスを / 区切りで書きます。

Obsidian CLIはどの版から使えますか？

Obsidian公式ヘルプによると、Obsidian CLIの利用にはObsidian 1.12.7以降のインストーラが必要で、設定の「General」から「Command line interface」を有効にして登録します。Obsidianアプリが起動していることが前提で、起動していない場合は最初のコマンドがアプリを立ち上げます。

Obsidian Syncや他の同期サービスを使っていても大丈夫ですか？

Obsidian公式ヘルプは、VaultがObsidian Sync・Dropbox・iCloud・OneDrive・Gitなどのサービスと同期できると案内しています。Claude Codeによる書き込みは、他のテキストエディタでの編集と同じ「外部からの変更」として扱われます。同期中のファイルを別の端末で同時に編集しない運用にしておくと、衝突の切り分けが楽になります。

サーバー上で定期実行するときの注意は？

claude -p はワークスペースの信頼ダイアログを出さずに、そのフォルダのフックを実行し .mcp.json のサーバーに接続します。Vaultに置く設定は拒否ルールと保護フックだけに絞り、--allowedTools は Read,Edit に限定してBashを渡さない形が基本です。--bare を付けるとCLAUDE.mdもフックも読まれないので、Vaultに書き戻すジョブでは使いません。

運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る（無料）

参考・出典

Obsidian「How Obsidian stores data」（VaultはローカルのフォルダでノートはMarkdownのプレーンテキスト、他のエディタで編集可、外部の変更を自動反映、.obsidian 設定フォルダ、Vaultの入れ子は非推奨、Obsidian Sync・Dropbox・iCloud・OneDrive・Gitとの同期）
Obsidian「Create a vault」（Vaultはローカルファイルシステム上のフォルダ、既存フォルダをVaultとして開ける）
Obsidian「Configuration folder」（.obsidian フォルダにそのVaultの設定が入る）
Obsidian「Internal links」（wikilinkとMarkdown形式の等価性、既定はwikilink、フォルダはVaultルートから / 区切り、存在しないノートへのリンク、リネーム時の自動更新設定）
Obsidian「Properties」（先頭の ---、既定プロパティ tags・cssclasses・aliases、型の7種類、型は名前ごとに決まる）
Obsidian「Obsidian Flavored Markdown」（CommonMark・GFM・LaTeX、![[Link]]・![[Link#^id]]・%%Text%%、HTML要素内ではMarkdownが描画されない）
Obsidian「Introduction to Bases」（コアプラグイン、プロパティで並べ替え・絞り込み、データはMarkdownとプロパティに保存、.base ファイルまたはコードブロック、テーブル・リスト・カード）
Obsidian「Obsidian CLI」（1.12.7以降のインストーラ、General→Command line interfaceで有効化、アプリ起動が前提、vault= は最初のパラメータ、file= と path= の違い、search・daily:append・tasks・tags counts・diff の例）
kepano「obsidian-skills」（Agent Skills仕様、/plugin marketplace add kepano/obsidian-skills・/plugin install obsidian@obsidian-skills、収録6 Skill、MITライセンス）
Anthropic「Configure permissions」（ファイル権限は Edit(path)・Read(path) のみ照合、Write(path) は警告、//・~/・/・./ のパス解決、Read の拒否で秘密ファイルを守る、--add-dir と /add-dir、追加ディレクトリから読まれる設定の範囲）
Anthropic「CLI reference」（--add-dir の定義と permissions.additionalDirectories、--allowedTools、--bare の省略対象、-p・--output-format）
Anthropic「How Claude remembers your project」（./CLAUDE.md または ./.claude/CLAUDE.md、200行以内の目安、/context での確認、/init、.claude/rules/）
Anthropic「Extend Claude with skills」（.claude/skills/<名前>/SKILL.md、~/.claude/skills/、--add-dir のSkill、プラグインSkillの /プラグイン名:スキル名）
Anthropic「Hooks reference」（PreToolUse、Edit|Write マッチャー、tool_input.file_path は絶対パス、hookSpecificOutput.permissionDecision の deny、${CLAUDE_PROJECT_DIR}）
Anthropic「Run Claude Code programmatically」（claude -p、--allowedTools、--output-format json、--bare の挙動、-p が信頼ダイアログなしにフックとMCPを読む注意）

この記事の要点

手順1｜連携の入口を決める（直接操作・Obsidian CLI・MCPの3経路）

手順2｜Vaultを作業ディレクトリにする（--add-dir とスコープ）

手順3｜.obsidian と機密ノートを権限で守る

手順4｜Obsidian記法の規約をCLAUDE.mdに書く（wikilink・プロパティ・埋め込み）

手順5｜Obsidian CLIとobsidian-skillsで足りない部分を補う

手順6｜Basesとプロパティでノートをデータとして扱う

手順7｜定期処理は claude -p でVaultに書き戻す

想定モデル：開発チームの技術メモVaultをClaude Codeで整える

つまずきやすい5点

まとめ｜今日からの3手

よくある質問

Obsidian連携にMCPサーバーは必須ですか？

Claude Codeが .obsidian フォルダを書き換えないようにするには？

wikilinkではなく普通のMarkdownリンクで書かれてしまいます。

Obsidian CLIはどの版から使えますか？

Obsidian Syncや他の同期サービスを使っていても大丈夫ですか？

サーバー上で定期実行するときの注意は？

参考・出典

このテーマの関連記事

この事例を、自社の業務に置き換える。

関連記事

Claude Codeの音声入力｜/voiceの設定と使えない時の確認

Claude CodeのChrome連携｜ブラウザ操作の設定と効かない時

Claude Codeのoutput style設定｜切り替えと自作の手順

手順2｜Vaultを作業ディレクトリにする（`--add-dir` とスコープ）

手順3｜`.obsidian` と機密ノートを権限で守る

手順7｜定期処理は `claude -p` でVaultに書き戻す

Claude Codeが `.obsidian` フォルダを書き換えないようにするには？