Obsidian×Claude Code連携｜作業場にする設定4点と確認5項目

「Obsidianに貯めたメモを、そのままAIエージェントに読ませたい」。そう考えたとき、最初に探されるのはプラグインです。連携という言葉には、あいだをつなぐ部品が要るという響きがあります。

ところが、この組み合わせに部品は出てきません。Obsidianはフォルダとマークダウンファイルの集まりで、専用のデータベースを必要としません（出典: Obsidian公式ドキュメント）。Claude Codeのほうは、起動したディレクトリをそのまま作業範囲にします。Vaultのフォルダで立ち上げた時点で、両者はもう同じ場所を見ています。

だから作業は、配線を引くことではなく、同じ場所の使い方を決めることになります。決めるのは4点だけです。素材は自社Vaultの設定ファイルで、検証環境はclaude-sonnet-5・Claude Code v2.1.x系・Obsidianデスクトップ版・macOS 15（2026-07-28検証）です。

案内役は、はじめて触る若葉さんと、自分の手で設定したい高梨課長、それに鈴木さん（本誌監修）です。

01ObsidianとClaude Codeの連携って、AIエージェントの作業場を用意することなんですか？

若葉さん

若葉さんの発言

連携と聞くと、どこかに接続用の設定画面がある気がするのですが、それは無いんですか。

鈴木さん

鈴木さんの発言

共有オフィスの合鍵を渡すのに近いと思っています。配線を引くのではなくて、同じ部屋をどう使うかの約束ごとを決める作業です。

ここでいう連携とは、Vaultをそのまま作業ディレクトリにして起動する設定を指します。Obsidian側にもClaude Code側にも、相手を認識させるためのスイッチはありません。片方が置いたファイルを、もう片方がそのまま読む。それだけの関係です。

決めることは、次の4点に収まります。

前提は3つです。Vaultがgitリポジトリになっていること、Claude Codeが入っていること、そしてObsidianのコミュニティプラグインは要らないこと。最後の点は意外に思われるので、あとの「よくある質問」で補足します。

02Claude Codeを起動する場所は、AIエージェントの作業範囲とどう関係するんですか？

Claude Codeは、既定では起動したディレクトリのファイルだけにアクセスします（出典: Claude Code公式ドキュメント）。つまり、どこで立ち上げたかが、そのまま作業範囲の外周線になります。

やることは1つです。Obsidian Vaultのルートフォルダで起動する。ここを間違えると、あとで書く指示書も権限も、範囲の外に置かれたまま読まれません。

自社Vaultでは、.obsidianと.claudeが同じ階層に並ぶ兄弟フォルダになっています。ルート直下はこうです。

.claude/       ← Claude Codeの設定・hooks・skills
.obsidian/     ← Obsidianの設定・プラグイン・ワークスペース
.git/          ← gitリポジトリ本体
CLAUDE.md      ← ルールファイル（次の章）
MEMORY.md      ← Claude Codeのauto memoryの索引

並べてみると、どちらか一方が相手を抱え込む形になっていないことが分かります。上下関係ではなく、同じ屋根の下に別々の部屋がある構造です。

範囲の外で起動しても、エラーは出ません。ただ「そのファイルは無い」という前提で話が進みます。設定を書いたのに反応が薄いとき、いちばん最初に疑うのはここです。

03ルールファイルは、AIエージェントとObsidianの両方から見える場所に置くんですか？

高梨課長

高梨課長の発言

指示書はどこに置くのが正解でしょうか。隠しフォルダの中でもいいのでしょうか。

鈴木さん

鈴木さんの発言

公式が認めている置き場所は2つあります。どちらでも読まれますが、Obsidian側からも開きたいなら、ルート直下のほうが扱いやすいです。

CLAUDE.mdは、プロジェクト向けの指示ファイルです。置き場所は./CLAUDE.mdか./.claude/CLAUDE.mdのどちらかです（出典: Claude Code公式ドキュメント）。Vaultのルートに置けば、起動のたびに読み込まれます。

この連携ならではの挙動が1つあります。CLAUDE.mdは拡張子が.mdの普通のファイルなので、Obsidianからも1つのノートとして開け、検索の対象にもなります（出典: Obsidian公式ドキュメント）。設定ファイルでありながら、書き手にとってはただのノートとして見える。だから、思い出したときにその場で直せます。

自社のCLAUDE.mdは15章構成（§0〜§14）で、Vaultのルートに置いています。編集にはaskルールをかけているため、無断で書き換わることはありません（2026-07-28時点の設定ファイルを確認）。

重なりの部分に置いたものだけが、両方から編集できます。ルールファイルをここに置く理由は、読ませるためというより、人が直すのを面倒にしないためです。

04Obsidianの個人環境ファイルは、AI社員の視界からどうやって外すんですか？

.obsidianフォルダの中には、端末ごとに変わるファイルと、Vault全体で共有すべきファイルが混ざっています（出典: Obsidian公式ドキュメント）。分けないままgitに載せると、開いた端末の数だけ差分が出ます。

Obsidian公式は、workspace.jsonとworkspaces.jsonを個人環境ファイルと位置づけ、「.gitignoreへの追加を検討すべき」と明記しています（出典: Obsidian公式ドキュメント）。自社の.gitignoreは、これに連携で気づいた項目を足した形になっています。

# --- Obsidian: 端末ごとの作業状態・ゴミ箱 ---
.obsidian/workspace.json
.obsidian/workspace-mobile.json
.obsidian/cache/
.trash/

# --- Obsidianプラグインのローカルデータベース ---
.smart-env/
.smtcmp_json_db/

書いたあとは、その場で返事をもらいます。

$ git check-ignore -v .obsidian/workspace.json
.gitignore:41:.obsidian/workspace.json	.obsidian/workspace.json

行番号とパターンが返ってくれば効いています。無言で終わったら、書いたつもりのパターンが当たっていません。

05Claude Codeの権限のdeny・ask・allowは、AIエージェントの書き込みをどの順で判定するんですか？

Claude Codeの権限ルールはdeny・ask・allowの3種類です。評価順序は常にdeny→ask→allowの固定順で、ルールの詳しさでは変わりません（出典: Claude Code公式ドキュメント）。

順番が固定だという点が、設計の勘どころになります。細かく書いたallowが、ざっくり書いたdenyを追い越すことはありません。止めたいものを広めに書いておいて、あとから通したいものだけを狭く開ける、という発想は通用しない。開けたい範囲は、denyに引っかからない形で書きます。

自社の.claude/settings.jsonには、2026-07-28時点でdenyが19件、askが26件、allowが11件登録されています。守っている代表例です。

配分の考え方そのものは、Claude Codeの権限設定｜AIエージェントに任せる範囲と3列の配分で扱っています。

06Claude Codeの信頼ダイアログを承認する前は、AIエージェントの権限設定はどこまで効かないんですか？

Vaultを初めて開いたときは、ワークスペースの信頼ダイアログが表示されます。allowルールとadditionalDirectoriesは、これを承認するまで適用されません（出典: Claude Code公式ドキュメント）。

一方で、denyとaskは承認前から効きます。つまり、危ないほうを止める力だけは先に働いていて、通すほうの指定だけが待たされている状態です。

この非対称は、設定を確かめる順番に影響します。承認前に/permissionsを開くと、書いたはずのallowが載っていません。設定ファイルの誤りだと思って直しにいくと、直すところが無い。ダイアログを片づけてから見に行くだけで済む話です。

07チームでAI活用するとき、Claude Codeの設定はどこまで共有していいんですか？

高梨課長

高梨課長の発言

複数人で同じVaultを開くと、設定を上書きし合ってしまいませんか。

鈴木さん

鈴木さんの発言

そこは置き場所で分かれています。全員に効かせたいものと、自分の手元だけで変えたいものを、別のファイルに書く決まりになっています。

全員に効かせるルールは.claude/settings.jsonに書き、gitで共有します。個人の上書きは.claude/settings.local.jsonに置きます。役割が分かれているので、複数人が同じVaultを開いても、互いの設定を書き直す作業は発生しません。

個人の上書き用の.claude/settings.local.jsonは、作成時に自動でgit管理から外れます（出典: Claude Code公式ドキュメント）。自分で先に作ってしまった場合だけ、.gitignoreへ手動で足します。除外設定は、Obsidian側とClaude Code側の両方で1回ずつ確認しておくと取りこぼしません。

共有と個人を混ぜないことは、体裁の問題ではありません。混ざると、誰かの都合で書き換えた1行が全員に効いてしまい、それを戻す相談から始めることになります。

08ObsidianとClaude Codeの連携でつまずくのは、AI導入のどのあたりなんですか？

若葉さん

若葉さんの発言

Obsidianで[[ノート名]]と書いておけば、関係するノートも一緒に読んでくれますよね。

鈴木さん

鈴木さんの発言

そこは分かれます。Obsidianの中ではリンクとして働きますが、指示書として読み込ませる書き方は別に決まっているんです。

つまずきどころは3つあります。はじめの2つは、書き忘れが原因です。

1. プラグインの認証情報をgitに載せてしまう。.obsidian/plugins/配下には、APIキーやOAuthトークンが保存されることがあります。自社Vaultでは、この理由で一部プラグインの設定ファイルを.gitignoreに登録していますが、2026-07-28時点で該当パスにファイル自体は生成されておらず、シンボリックリンクも未設置です（実測）。いま無いから書かない、としてしまうと、将来ファイルが生まれた日にコミット履歴へ残ります。
2. [[内部リンク]]が自動で読み込まれると思い込む。CLAUDE.mdの@pathインポートに慣れると、Obsidian流の[[ノート名]]も同じように展開されると考えてしまいます。公式ドキュメントが定義するインポート構文は@pathのみで、[[...]]への言及はありません（出典: Claude Code公式ドキュメント）。読ませたい関連ノートは@で名指しします。

09エラーが出ないのに連携の設定が効かないのは、AIエージェントの側で何が起きているんですか？

3つめは、書き忘れではなく順番の問題です。信頼ダイアログを承認し忘れると、前章のとおりallowルールとadditionalDirectoriesは適用されません。承認前は、書いた設定が読まれているだけで、まだ効いていない状態です。

3つに共通するのは、どれも画面上は何も起こらないことです。エラーが出ないぶん、気づく機会が遅れます。設定ファイルを読み返しても、そこには間違いが書かれていません。

だから最後に、効いているかどうかを自分で確かめる工程を挟みます。読み返すのをやめて、実行して返事を見るほうへ切り替えます。

10ObsidianとClaude Codeの連携ができたかは、AIエージェントに何をさせて確かめるんですか？

判定は、印象ではなくコマンドの返事で行います。次の5項目を上から順に見ます。

• /contextを実行し、Memory filesの一覧にVault直下のCLAUDE.mdが表示される
• git check-ignore -v .obsidian/workspace.jsonを実行し、.gitignoreの行番号とパターンが返ってくる
• /permissionsを実行し、.claude/settings.json由来のルールが一覧に出る
• Vaultで初めてClaude Codeを起動した回だけ、ワークスペースの信頼ダイアログが表示され、承認できる
• git statusを実行し、.obsidian/workspace.jsonや.trash/が追跡対象に含まれていない

5つとも満たせば、4点すべてが効いています。1つでも外れたら、対応する章へ戻って見直します。順番に意味があるのは、上が外れていると下も外れて見えるためです。上から潰したほうが、探す範囲が狭くなります。

Vaultの階層そのものをどう設計するかは、ObsidianをAIエージェントの知識基盤にする3つの設計にまとめています。

11よくある質問

12まとめ｜今日やる3つのこと

決めるのは4点、順番は上から。確かめるのは画面ではなくコマンドの返事。この2つが分かっていれば、連携でつまずく余地はかなり狭くなります。