Claude Code × Obsidian は何が嬉しいのか ─ プレーンMarkdownを共有レイヤーにする実践ユースケース集

はじめに

Claude Code を日常的に回しているエンジニアと、Obsidian を Personal Knowledge Management (PKM) の母艦にしている人の集合は、ここ半年で急速に重なり始めている。理由はシンプルで、両者ともに「プレーンMarkdownファイル」を一次データとして扱うからだ。LLM 側のワークスペースと、人間側のノートが同じレイヤーに並んだ瞬間、これまで「コピペで橋渡し」していた知的作業のかなりの部分が、エージェントの仕事として自動化できる射程に入る。

本記事は、すでに両ツールを使い始めている中級以上のエンジニアを対象に、

• なぜ Claude Code × Obsidian の相性が "良すぎる" のか（思想的な側面）
• 主要な3つの連携方式の比較（MCP / Local REST API / Filesystem直）
• 実運用で価値が出やすい8つのユースケース
• 罠とアンチパターン

を、既存記事を踏まえてまとめ直したものだ。新規セットアップ手順は他記事に詳しいので最小限に絞り、「で、結局何ができるの？」 に正面から答える構成にしている。

動作環境（前提）

項目	バージョン / 構成
Claude Code	1.x 系（Opus / Sonnet / Haiku のいずれか）
Obsidian	1.6+（Vault は Markdown ファイル群）
MCP サーバ	obsidian-mcp-server / mcp-obsidian / obsidian-claude-code-mcp 等
OS	Windows / macOS / Linux いずれも可

TL;DR

• Vault がプレーン Markdown だから、人間の知識と LLM の作業空間が同じレイヤーになる。これが Claude Code × Obsidian の本質的な相性。
• 連携方式は実質3パターン: (A) Local REST API + MCP、(B) Obsidian プラグイン直営の MCP、(C) ファイルシステム直アクセス。要件に応じて使い分ける。
• ユースケースは「長期メモリ / デイリーサマリ / 技術調査保存 / 執筆パイプライン / 知識探索 / 会議メモ整形 / ジャーナリング / Skills 置き場」の8系統に整理できる。
• 罠は Vault 巨大化によるトークン爆発、private 情報の混入、書き込み境界の曖昧さ、同時編集コンフリクト の4つ。

---

相性の本質: プレーンMarkdown × LLMワークスペースという「同レイヤー性」

Claude Code が他の AI ツールと違うのは、ローカルファイルを直接 grep / read / write する ことを前提に設計されている点だ。一方の Obsidian も、プロプライエタリなDBを持たず、Vault は単なる .md ファイルの集合である。両者が出会うと何が起きるか。

普通の SaaS 型ノートアプリ（Notion / Evernote 等）でこれをやろうとすると、

1. API を叩く
2. リッチテキストを LLM が読める形に変換
3. 編集結果をまた API 経由で書き戻す

という3段の橋を架ける必要がある。Obsidian なら そもそも橋が要らない。LLM が読み書きする対象と、人間が翌朝開くノートが、ファイルシステム上で同一物だ。

この「同レイヤー性」が、後述する全ユースケースの土台になっている。

ここでの主張は「Notion がダメ」という話ではない。SaaS 型は SaaS 型で同期・共有面の強みがある。ただ LLM が一次市民として参加する空間 としては、ローカル Markdown が現状もっとも摩擦が少ない、という話。

連携方式の整理

Claude Code から Obsidian Vault を扱う方法は、大きく3パターンに整理できる。

比較表

方式	必要なもの	書き込み	検索 / メタデータ	セットアップ難度	向くユースケース
(A) Local REST API + MCP（mcp-obsidian 等）	Obsidian + Local REST API plugin + MCPサーバ	◎	◎（タグ・バックリンク経由）	中	高度なPKM、研究ノート、知識探索
(B) Obsidian プラグイン型 MCP（obsidian-claude-code-mcp 等）	専用Obsidianプラグイン1つ	◎	○	低（プラグインインストールのみ）	ジャーナリング、日常PKM、Obsidian中心の人
(C) Filesystem 直アクセス	なし（Vault フォルダを Claude Code に渡すだけ）	◎	△（grep ベース）	極低	開発ログ、技術調査メモ、Skills 置き場

(A) Local REST API + MCP

Obsidian の Local REST API コミュニティプラグインが Vault を HTTP で公開し、その上に MCP サーバ（mcp-obsidian 等）を被せる構成。最も機能が豊富 で、タグ検索・メタデータ取得・バックリンク辿り・ノート部分置換などが MCP の tool として揃う。

.mcp.json

{
  "mcpServers": {
    "obsidian": {
      "command": "uvx",
      "args": ["mcp-obsidian"],
      "env": {
        "OBSIDIAN_API_KEY": "<plugin で発行した API key>",
        "OBSIDIAN_HOST": "127.0.0.1"
      }
    }
  }
}

(B) Obsidian プラグイン直営の MCP

iansinnott/obsidian-claude-code-mcp のように、Obsidian プラグインそのものが MCP サーバとして振る舞うパターン。WebSocket と HTTP/SSE のデュアルトランスポートで、Claude Code 側からは claude 起動後に /ide コマンドで Vault を選ぶだけで繋がる。REST API plugin を別途入れる必要がなく、セットアップが最短。

(C) Filesystem 直アクセス

最も泥臭く、しかし最も簡単な方法。Vault のディレクトリをそのまま Claude Code の作業ディレクトリ（または additionalDirectories）として渡す。Claude が Read/Write/Grep/Glob で直接ファイルを操作する。MCP のツール抽象は使えないが、逆に LLM が Vault を「コードベースと同じ感覚」で扱える のが強みで、開発ログや調査メモ用途では十分すぎる。

3方式は排他ではない。(C) を常用しつつ、検索の重い場面だけ (A) を使う のような併用が現実的。

---

ユースケース集

ここからが本題。「で、結局何ができるの？」に答える8つのパターン。

Tip 1: エージェントの長期メモリとして Vault を使う

Claude Code はセッションをまたぐと記憶を失う。Vault の特定フォルダをエージェントの長期メモリ領域として割り当てる と、これが解決する。

Vault/AgentMemory/

AgentMemory/
├── projects/        # 進行中プロジェクトの状態
├── decisions/       # 過去の意思決定ログ
├── feedback/        # ユーザー指示・嗜好
└── references/      # 外部システムへのポインタ

Claude Code 標準の ~/.claude/projects/.../memory/ 機構を Vault 配下に置くだけでも、人間がノート閲覧アプリで自分のエージェントの記憶を読める という、なかなかパンチのある体験になる。MCPVault のように "live agent memory" として明示的に設計したスキルも出てきている。

Tip 2: デイリーノート群から週次サマリを自動生成

Obsidian のデイリーノート（Daily/2026-05-06.md 形式）をそのまま入力にして、

「今週月曜〜日曜のデイリーノートを読んで、進捗 / 詰まったこと / 来週の宿題 を3節構成でまとめ、Weekly/2026-W19.md に書き出して」

と指示するだけで、週次レビューが完成する。テンプレ化して /weekly-review のようなスラッシュコマンドにすれば、毎週金曜の儀式が30秒で終わる。

Tip 3: 技術調査メモを Vault にそのまま保存する

「ライブラリ X の評価」「Y を実現する方法」のような調査結果を、Claude Code の作業ログとして Vault の TechResearch/Reference/ や TechResearch/HowTo/ に直接書き込む。調査の結果を Markdown ファイル "として" 残せる のは、構造化 DB を持たない Obsidian ならではの軽さだ。

筆者は「調査結果 = Reference型 / HowTo型 のどちらか」というテンプレを Skill 化していて、Claude が調査終了時に自動で然るべきフォルダに保存するワークフローを組んでいる。

このパターンは Vault を「自分専用の Stack Overflow」に変える。後日同じ問題に当たったとき、まず自分の Vault を grep するのが第一歩になる。

Tip 4: リサーチ → 構成 → Qiita 下書きまでの執筆パイプライン

本記事自体がそうなのだが、

1. Claude Code に Web 検索で類似記事を集めさせる
2. Vault 内の関連ノート（過去の調査ログ）を参照させる
3. アウトラインを Markdown で起こす
4. Vault の 11_Qiita/drafts/ 配下に下書きを保存
5. Qiita REST API で投稿

までを Vault を中継して一気通貫 で回せる。途中の中間生成物が全て Markdown なので、人間がいつでも介入・編集できる点が大きい。

Tip 5: バックリンクとグラフ構造を LLM に辿らせる知識探索

Obsidian の真骨頂はバックリンクとグラフだが、これらは結局「[[NoteName]] という記法のリンク」に過ぎない。MCP 経由で search_notes / get_backlinks のツールを叩かせれば、Claude が自分でグラフを多段に辿りながら関連知識を集めて回答する ことができる。

ユーザー: 「3年前のあのプロジェクトで議論した認可方針、いまの設計に照らして再評価して」
Claude:
  1. "認可" でVault全文検索 → 候補ノート N 件
  2. 候補ノートのバックリンクを辿る → コンテキスト周辺ノート
  3. 関連 ADR / 議事録を読み込み
  4. 現行設計のコードと照合（プロジェクトリポジトリ側）
  5. 比較サマリを Markdown で出力

ここで効いているのは「Vault が静的な資料ではなく、LLM がグラフ探索できる動的な情報空間 になっている」ことだ。

Tip 6: 会議メモの整形・タグ付け・Action Item 抽出

会議中に殴り書いた Meetings/2026-05-06_team-sync.md を Claude に渡して、

• 参加者リスト
• 議題ごとの要旨
• 決定事項
• Action Item（担当者・期限）
• 関連プロジェクトへの [[link]]

を後付けで整形させる。LLM に書かせるのではなく、自分の生メモを LLM に整形させる のがコツ。生の思考ログは残しつつ、構造化された出力も得られる。

Tip 7: 「対話で育てる日記」 ─ ジャーナリング

ジャーナリングは Obsidian の伝統的ユースケースだが、Claude Code を併用すると 「書きっぱなしの日記」ではなく「読み返して問いを返してくれる相手」 になる。

• 今朝のエントリと、過去30日の同曜日のエントリを比較
• 繰り返し現れるテーマを抽出
• 「あなたが先週書いた X と、今日の Y は矛盾しているけれど、どう整理する？」と問いを返す

このパターンを Skill 化して、「以上です」 で締めると自動保存される運用にしている人も既にいる（参考: kazuyuki_yamashita 氏の記事）。

Tip 8: CLAUDE.md / Skills 置き場としての Vault

ここまで「Vault に書き込む」話をしてきたが、逆方向もある。Claude Code の CLAUDE.md、.claude/skills/、.claude/commands/ 自体を Vault 内のノートとして管理する運用だ。

メリットは:

• Claude の挙動指示そのものが Obsidian で検索・バックリンク可能になる
• Skill の改訂履歴を Daily Note から [[Skill: save-tech-research]] のように引ける
• 「自分の AI に何を仕込んでいるか」が読み返せる資産になる

Vault/.claude/

.claude/
├── CLAUDE.md
├── skills/
│   ├── save-tech-research.md
│   └── weekly-review.md
└── commands/
    └── /journal.md

Vault と Claude Code の作業ディレクトリを揃えてしまえば、.claude/ の中身もそのまま Obsidian で開ける。「自分の AI を編集する作業」が、ノート編集と同じ UX になる。

---

注意点とアンチパターン

ここまでの理想像にはいくつか実運用上の罠がある。

Vault 巨大化によるトークン爆発

数千ノート規模になった Vault を毎回フル投入すると、コンテキストが即死する。対策:

• MCPの検索ツールを使い、必要最小限のノートだけ取り込む
• グレップを先に絞り込み、ヒットした周辺だけ読み込む
• フォルダ単位で additionalDirectories を分割

Private 情報の混入

Vault には日記・パスワード断片・社外秘メモが混ざりがち。LLM プロバイダに送って良い領域とそうでない領域を、フォルダレベルで分ける のが現実解。

Vault/
├── public/      # AIに渡してよい
└── private/     # AI禁止 (allowedDirectories から外す)

Obsidian の .obsidianignore だけに頼らず、Claude Code 側の additionalDirectories / 権限設定でも二重に制限する。片方しか効いていないと事故る。

書き込み境界の曖昧さ

「LLM が Vault を勝手に編集して、過去ノートが書き換わっていた」という事故が一番痛い。対策:

• 重要ノートに対する 書き込みは新規ファイル作成のみ に縛る運用ルール
• Vault を git 管理しておき、いつでも git diff できる状態にする
• 破壊的編集が必要なときだけ明示的に許可する（例: --dangerously-edit-existing 相当のフラグを Skill 側に持たせる）

同時編集コンフリクト

Obsidian アプリで開いているノートを Claude Code が同時に書き換えると、Obsidian 側のキャッシュと衝突して片方の編集が失われる。Claude が書く対象のファイルは Obsidian で開かない か、書き込み後に Obsidian 側を手動リロードする運用が安全。

---

まとめ

Claude Code × Obsidian の本質は「プレーンMarkdownを共有レイヤーにすることで、人間の知識作業とエージェントの作業空間を同一視できる」点にある。連携方式は3つあり、用途に応じて使い分ければよい。8つのユースケース ─ 長期メモリ、週次サマリ、技術調査保存、執筆パイプライン、知識探索、会議メモ整形、ジャーナリング、Skills 管理 ─ はどれも、Vault を "LLM が一次市民として参加する空間" に押し上げる ための具体的な道具立てだ。

未実装の人は、まず (C) Filesystem 直アクセスから入って、慣れたら (A) Local REST API + MCP に進むのが学習コスト的に楽。Obsidian 中心で生活している人は (B) のプラグイン直営型でいきなり繋いでも良い。

Vault は最初は単なるメモ置き場でも、Claude Code を相棒に組み込むと 「自分の二つ目の脳」のうち、機械が走り回れる側の領域 に育っていく。一度味を覚えるとほぼ後戻りできない種類の体験なので、まだ繋いでいない人はぜひ。

参考記事

連携方式の実装・各 MCP サーバの詳細・既存ユースケースの実例は、以下の先行記事が詳しい。