claude-obsidian は、Obsidianのvaultを「普通のMarkdownのディレクトリ」のまま保ちながら、Claude Codeに整理させるローカルファーストのナレッジ基盤です。★11,358を集めており、Obsidian×AIの構成としては現時点でもっとも規模の大きいOSSのひとつになっています。
- ・正体:Claude Code / Agent Skills 向けの15スキル同梱ナレッジ基盤。★11,358・MIT・v2.1.0
- ・何ができる:素材の取り込み → 出典と主張の台帳化 → リンク・MOC・Canvas生成 → vault内根拠からの回答
- ・何を代替できる:クラウドに閉じるAIノートサービス。vaultはただのMarkdownのまま手元に残る
- ・安全設計:破壊的操作は計画表示 → SHA-256を書き戻して承認 → 適用の二段階
- ・並行実行:ワーカーは下書きを返すだけ。適用は1つのオーケストレータが1トランザクションで行う
- ・注意:最終pushは2026-08-01でオープンIssueは133件。導入前にvaultのバックアップを用意する
vault内の情報から回答を組み立てる仕組みは広義のRAGです。基礎から押さえたい方は RAGとは?仕組み・構築・ベクトルDB選定までの2026年実装マップ を先にどうぞ。本記事は「Obsidianのvaultを対象にした場合、何がどう作られるか」に絞ります。
claude-obsidianの4段ループ——保存して終わりにしない設計
READMEの主張はシンプルです。多くのAIノートのワークフローはテキストを保存した時点で止まる。claude-obsidianはそこから先を回すために組まれている、と。
・取り込む(Capture) — ローカルの素材を目に見えるinboxを通し、要約する前に内容アドレス指定の不変コピーを保存する
・裏を取る(Ground) — 出典台帳と主張台帳が、典拠・鮮度・支持・矛盾・確信度・レビュー状態を保持する
・つなぐ(Connect) — リンクされたページ、索引、MOC(Maps of Content)、方法論を意識した構造、Obsidian Canvasのビューを作る
・使い直す(Reuse) — 毎回ゼロから会話を始めるのではなく、すでに分かっていることを検索・調査・検証・要約して再利用する
READMEはこのプロジェクトが何でないかも明記しています——自動の議事録レコーダーではない、クラウド同期サービスではない、事実の神託ではない、バックアップやバージョン管理の代わりでもない。過剰な期待を先回りで潰しにいく書き方で、この姿勢自体が設計思想の一部になっています。
① 何ができる:素材を出典付きのリンクされたObsidianページに変え、vault内の根拠から回答を組み立てる。② 何を解決する:AIに要約させると出典が失われ、後から検証できなくなる問題。③ 何を代替できる:クラウドに閉じるAIノートサービス。ファイルの所有権を手放さずに済む。
claude-obsidianの15スキルは何を担当しているのか
READMEは「15 skills, one system」と書いています。skills/ 配下のSKILL.mdを数えると、テスト用フィクスチャを除いてちょうど15でした。役割ごとに整理すると次のようになります。
| 役割 | スキル | 何をするか(SKILL.md要約) |
|---|---|---|
| 土台 | wiki |
vaultの初期化・既存vaultの採用・作業のルーティング |
| 取り込み | wiki-ingest |
素材を来歴と主張追跡つきでvaultへ取り込む |
| 取り込み | defuddle |
明示的なネットワーク同意のもとで外部HTTPSページをMarkdown化 |
| 検索 | wiki-query |
vaultを変更せず、vault限定の質問に答える |
| 検索 | wiki-retrieve |
vault内にBM25索引を構築。多言語Nomicによる再ランクも可 |
| 保守 | wiki-lint |
読み取り専用の健全性チェック。孤立ノート検出など |
| 保守 | wiki-fold |
最近のログ項目を抽出的に要約。既定はdry-run |
| 保守 | wiki-mode |
分類方法論(Generic / LYT / PARA 等)の設定と配置提案 |
| 調査 | autoresearch |
範囲を限った出典準拠の調査ループ。引用付きドシエを作る |
| 記録 | save |
選ばれた回答・決定・洞察を1トランザクションでvaultへ保存 |
| 可視化 | canvas |
Obsidian JSON Canvas ボードの作成・検査・更新 |
| 記法 | obsidian-markdown |
Obsidian Flavored Markdown の説明・生成・検証 |
| 記法 | obsidian-bases |
Obsidian Bases の .base ファイルを検証つきで扱う |
| CLI | wiki-cli |
公式Obsidian CLIを検出し、読み取り専用アクセスに使う |
| 思考 | think |
10段階の思考ループを重要な判断に適用する |
読み取り専用と書き込みが明確に分かれているのが特徴です。wiki-query は「vaultを変更せず」、wiki-lint は「読み取り専用」、wiki-cli は「読み取り専用アクセス」と、SKILL.mdの説明文レベルで宣言されています。vaultを触るのは wiki-ingest save wiki-fold など限られたスキルだけで、しかもそれらは後述の承認フローを通ります。
wiki-retrieve がBM25という語彙ベースの手法を主軸に据えている点も実務的です。ベクトルDBを立てずvault内で完結でき、多言語Nomicによるコサイン再ランクは任意という構成なので、「まず動かす」までの距離が短くなっています。
導入手順——安全側に倒した2段階セットアップ
導入で最初に理解しておくべきなのは、チェックアウトしたリポジトリはvaultではないということです。READMEが明示しています。
git clone https://github.com/AgriciDaniel/claude-obsidian.git
cd claude-obsidian
次にvaultを別途初期化します。ここが特徴的で、いきなり適用されません。
export GENERATED_AT="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
export OPERATION_ID="init-reviewed"
python3 scripts/claude-obsidian.py init "$HOME/Documents/MyKnowledgeVault" \
--generated-at "$GENERATED_AT" --operation-id "$OPERATION_ID"
これはJSONの実行計画を出力するだけで、ファイルには手を触れません。計画の中に approved_plan_sha256 という値があり、それをコマンドラインへ書き戻してはじめて適用が通ります。
python3 scripts/claude-obsidian.py init "$HOME/Documents/MyKnowledgeVault" \
--generated-at "$GENERATED_AT" --operation-id "$OPERATION_ID" \
--approved-plan-sha256 "<計画に出たsha256>" --apply
最後にvaultのディレクトリでClaude Codeを起動します。
cd "$HOME/Documents/MyKnowledgeVault"
claude --plugin-dir /absolute/path/to/claude-obsidian
既存のvaultに入れたい場合は、init ではなく非破壊の adopt ワークフローが用意されています。ただし最初の一回は新しいvaultで試すのが公式の推奨です。
ファイルは変更しない"] B --> C["利用者が計画を読む"] C --> D{"内容に納得したか"} D -- いいえ --> E["中止(何も起きていない)"] D -- はい --> F["approved_plan_sha256 を
コマンドへ書き戻す"] F --> G{"計画のSHA-256と一致?"} G -- 不一致 --> H["適用されない"] G -- 一致 --> I["--apply で1トランザクション適用"]
分類の流儀を選べる——wiki-modeという逃げ道
Obsidian界隈で意見が割れるのがノートの分類方法論です。PARA(Projects / Areas / Resources / Archives)、LYT(Linking Your Thinking)、Zettelkasten——どれを採るかで、フォルダ構成もリンクの張り方も変わります。
claude-obsidianはここで流儀を押しつけません。wiki-mode スキルが「vaultの分類方法論を読み取り・設定し、これから作る知識の配置先を提案する」役割を持ち、Generic / LYT / PARA といった方法論を切り替えられるようになっています。
これは実務的に重要な設計判断です。既存のvaultには既に分類の流儀が入っています。ツールが自分の流儀を強制すると、導入した瞬間にvaultが二重構造になって破綻します。方法論を設定値として外に出しておけば、既存vaultの流儀に合わせて配置先を提案するという振る舞いが可能になります。前述の非破壊 adopt ワークフローと合わせて、既存vaultへの後付け導入を現実的にしている部分です。
実際の一巡はどう進むか
15スキルの役割分担を、実際の作業の流れに沿って並べ直すと理解しやすくなります。
| 段階 | 使うスキル | 起きること |
|---|---|---|
| 1. vaultを用意 | wiki |
新規初期化、または既存vaultの非破壊採用 |
| 2. 流儀を決める | wiki-mode |
Generic / LYT / PARA から選び、配置先の方針を固定 |
| 3. 素材を入れる | wiki-ingest / defuddle |
ローカル素材を取り込む。Web記事は明示同意のうえMarkdown化 |
| 4. 出典を残す | (取り込み時) | 内容アドレス指定の不変コピーと、出典・主張の台帳が作られる |
| 5. 索引を張る | wiki-retrieve |
vault内にBM25索引を構築。任意で多言語再ランク |
| 6. 質問する | wiki-query |
vault内の根拠だけで答える。vaultは変更されない |
| 7. 深掘りする | autoresearch |
範囲を限った調査ループを回し、引用付きドシエを作る |
| 8. 結果を残す | save |
選んだ回答・決定を1トランザクションでvaultへ |
| 9. 可視化する | canvas |
Obsidian Canvas に知識マップを描く |
| 10. 掃除する | wiki-lint / wiki-fold |
孤立ノート検出、ログの抽出的要約(既定dry-run) |
6と8が分かれているのがポイントです。質問しただけではvaultは変わりません。AIとの会話で得た内容のうち、残す価値があると人間が判断したものだけ save で書き込む。「AIとの会話が全部自動でノート化される」タイプのツールとは、ここで思想が分かれます。
他のObsidian AI連携と何が違うか
Obsidian AI の組み合わせ方はいくつも存在します。代表的な選択肢と並べると、このプロジェクトの立ち位置が見えます。
| 軸 | claude-obsidian | Obsidianの汎用AIプラグイン | クラウド型AIノート |
|---|---|---|---|
| ファイルの所有 | 手元のMarkdown | 手元のMarkdown | サービス側のDB |
| 出典の保持 | 台帳で明示的に管理 | 実装次第 | 要約優先で失われがち |
| 書き込みの制御 | 計画→SHA-256承認→適用 | 即時反映が多い | 自動 |
| 検索 | vault内BM25+任意の再ランク | プラグイン依存 | サービス側 |
| 動作環境 | Claude Code / Agent Skills ホスト | Obsidianアプリ内 | ブラウザ・アプリ |
| 抜けやすさ | ファイルが残るだけ | 同左 | エクスポートが必要 |
会話を自動でノート化するタイプの代表例は Claude Memory Compilerとは|会話を知識ベースに自動コンパイルするOSS で扱ったものです。あちらは「会話を漏らさず知識化する」方向、claude-obsidianは「人間が残すと決めたものだけ書き込む」方向で、目指しているものが逆と言っていいほど違います。どちらが良いかは、ノートに求めるものが網羅性か信頼性かで変わります。ナレッジ系OSS全体の見取り図は ドキュメント/ナレッジ系OSSの選び方|知識グラフ・図解生成・構造化抽出マップ にまとめてあります。
Obsidianのプラグインではない点は押さえておく必要があります。claude-obsidianはClaude Code側のスキル集で、Obsidianアプリの中では動きません。Obsidianは「できあがったvaultを見るためのビューア」として使う形になります。逆に言えば、Obsidianを開かなくてもvaultは育ちますし、Obsidian以外のMarkdownエディタでも中身は読めます。
vaultを壊さないための仕掛け
AIにファイルを触らせる以上、事故の可能性はゼロにはなりません。このプロジェクトが取っている対策は、実装として確認できるものだけでも複数あります。
| 仕掛け | 内容 |
|---|---|
| 計画の事前提示 | 変更を伴うセットアップは、適用前に正確な操作内容をプレビューする |
| SHA-256 承認 | 計画のハッシュを書き戻さないと --apply が通らない。計画が変わればハッシュも変わる |
| dry-run 既定 | wiki-fold のような要約系は既定がdry-runで、明示しない限り適用しない |
| 読み取り専用の明示 | wiki-query wiki-lint wiki-cli は変更しないことをSKILL.mdで宣言 |
| 単一書き込み者 | 並行エージェントは下書きを返すのみ。適用は1つのオーケストレータが1トランザクションで行う |
| 能力の正直な申告 | 任意ツールは検出され、成熟度が宣言され、アダプタ不在はシミュレートせず明確に劣化する |
最後の項目は地味ですが重要です。READMEの言葉では「Capabilities are stated honestly(能力は正直に申告される)」。依存ツールが無いときに、あるふりをして中途半端な結果を返すのではなく、無いと明示して機能を落とす、という方針です。AIツールで最も厄介な「動いているように見えて実は何もしていない」を避ける設計になっています。
承認フローがあるとはいえ、READMEはこのプロジェクトが「バックアップやバージョン管理の代わりではない」と明記しています。既存のvaultへ入れる場合は、
・vault全体をgitでバージョン管理しておく(Markdownなので差分が読める)
・初回は
adopt ではなく新規vaultで一通り試す・Obsidianの同期を使っている場合は、同期を止めてから大きな取り込みを行う
の3点は自分で担保してください。オープンIssueが133件ある規模のプロジェクトなので、エッジケースは残っていると考えるのが自然です。
thinkスキルだけ毛色が違う
15スキルを眺めていて1つだけ浮くのが think です。SKILL.mdの説明はこうなっています——「Fable由来の10段階ループ(OBSERVE, OBSERVE, LISTEN, THINK, CONNECT, CONNECT, FEEL, ACCEPT, CREATE, GROW)を、重大な判断に適用する」。
vault操作とは直接関係のない、思考の型そのものを与えるスキルです。OBSERVE と CONNECT が2回ずつ現れるのが特徴で、「観察してから、もう一度観察する」「繋いでから、もう一度繋ぐ」という反復が組み込まれています。ナレッジベースを作る作業は結局のところ判断の連続なので、その判断自体に手順を与えにきた、という位置づけでしょう。
好みが分かれる部分ではあります。他の14スキルが「vaultに対して何をするか」という機械的な役割を持つのに対し、これだけは思考法の押しつけと受け取られる余地があります。使わないなら発動させなければいいだけですが、15スキル全部が同じ粒度の道具ではないことは知っておくと混乱しません。
出典台帳と主張台帳が持つ情報
「出典を残す」と一口に言っても、URLを1行貼るだけなら普通のノートアプリでもできます。このプロジェクトが台帳として保持すると宣言しているのは、もう少し細かい項目です。
・典拠(authority) — その主張がどの出典に支えられているか
・鮮度(freshness) — 出典がいつのものか
・支持(support) — 主張を裏づける材料があるか
・矛盾(contradiction) — その主張と衝突する別の記述がvault内にあるか
・確信度(confidence) — どの程度確からしいとみなすか
・レビュー状態(review state) — 人間が確認済みかどうか
矛盾を潰さず保持するという設計が特徴的です。AIに要約させると、複数の出典が食い違っている箇所は、どちらか一方に丸められるか「諸説あります」で薄められがちです。矛盾を項目として残せば、後から見返したときに「ここは決着していない」と分かります。
あわせて取り込み時に内容アドレス指定の不変コピーを保存する点も効いています。元記事が消えても書き換えられても、要約の根拠になった当時のテキストが手元に残る——リンク切れで検証不能になるノートの弱点を、構造的に塞ぎにいっています。
ライセンスと開発状況
ライセンスは MIT です。実測したメタデータは次のとおりです。
| 項目 | 実測値(2026-08-24時点) |
|---|---|
| ★ | 11,358 |
| フォーク | 1,309 |
| オープンIssue | 133 |
| リポジトリ作成 | 2026-04-07 |
| 最終push | 2026-08-01 |
| 最新タグ | v2.1.0 |
| 主言語 | Python |
| ライセンス | MIT |
★11,358・1,309フォークという数字は、この分野では十分に大きい部類です。一方で最終pushが2026-08-01で、本記事執筆時点から3週間ほど動きがありません。v2.1.0のタグが付いた状態で安定しているのか、開発ペースが落ちているのかは、この時点では判断できません。導入するならタグ付きリリースを基準にし、main の未リリース変更に依存しないほうが無難でしょう。
リポジトリの作り込みは丁寧です。CITATION.cff・SECURITY.md・CODE_OF_CONDUCT.md・RELEASE_MANIFEST.json・SHA256SUMS が揃っており、配布物のハッシュまで公開されています。個人プロジェクトとしては珍しい水準の整備で、前述の「計画にSHA-256承認を要求する」設計とも一貫しています。
向いている人・向いていない人
・向いている — 既にObsidianを使っていて、調べ物の出典が散逸している自覚がある人。ファイルの所有権を手放したくない人。AIに書かせた内容を後から検証したい人
・向いていない — 会話や議事録を自動で全部ノート化してほしい人(save は人間が選んだものだけ書き込む設計)。Obsidianを使っておらず、まずノートアプリから決めたい人。セットアップにコマンドライン操作を挟みたくない人
セットアップがPythonスクリプトと承認ハッシュを経由する時点で、GUIだけで完結したい層は対象外です。そのぶん、何が起きるかを事前に読めるという利点と引き換えになっています。
まとめ
・Obsidianのvaultを普通のMarkdownのまま保ちながらClaude Codeに整理させるローカルファースト基盤
・15スキルが取り込み・検索・保守・可視化・調査を分担。読み取り専用と書き込みが明確に分離されている
・設計の軸は取り込む→裏を取る→つなぐ→使い直すの4段ループ。要約が出典を殺さない
・破壊的操作は計画提示 → SHA-256を書き戻して承認 → 1トランザクション適用の二段階
・検索はBM25主軸でvault内完結。ベクトルDBを立てずに始められる
・★11,358・MIT・v2.1.0。ただし最終pushは2026-08-01、オープンIssue 133件。既存vaultへ入れる前にgit管理とバックアップを用意する
導入を検討するなら、判断の順序はこうなるでしょう。まず新規vaultで一巡させて(取り込み→質問→保存→lint)、出力されるMarkdownの形が自分の好みに合うかを見る。合わなければそこで終わりで、消すのはディレクトリ1つです。合いそうなら既存vaultをgit管理下に置いてから adopt を試す。この順番なら、どの段階で降りても失うものがありません。
Obsidian×AIのツールは数多くありますが、このプロジェクトが目を引くのはAIに何をさせないかを決めている点です。読み取り専用のスキルを分け、書き込みは1つの経路に絞り、適用前に計画のハッシュを人間に確認させる。機能を足す方向ではなく、事故の経路を塞ぐ方向に労力が割かれています。
自分のノートをAIに触らせるかどうかで迷っているなら、判断材料はそこにあるはずです。vaultがただのMarkdownのまま残るという設計なら、合わなければ抜けるだけで済みます。ロックインが無いことが、試す側にとっては一番の安心材料でしょう。
参照ソース
・AgriciDaniel/claude-obsidian(公式リポジトリ・README) — 4段ループ・15スキル・2段階セットアップ・並行実行時の単一書き込み者設計の出典。skills/ 配下のSKILL.mdはスキル数と各役割の確認に使用
・Obsidian 公式サイト — vault・Canvas・Bases などの前提となる本体
・Agent Skills Specification — 同梱15スキルが準拠している仕様