「オブシディアン・クロード・コード」のワークフローは、ヴォールト全体を“エージェントの記憶”に変える必要はありません。私はもっと範囲を狭くするでしょう：承認されたアーキテクチャ決定記録を一つ取得し、その決定を一つのリポジトリ内で適用し、コードとテストの証拠をレビューし、そして一つの実装ノートをオブシディアンに戻して追記します。

その境界は重要です。オブシディアンは、ソースノートが表示および編集可能であるため、有用なコーディングエージェントのナレッジベースになり得ます。一方、クロードコードは独自の権限とワークツリーの制御でリポジトリに対して動作できます。リスクがあるのは、取り出しが静かに無制限のボルトアクセスになった場合や、誰も実際に何が変わったかを確認する前にエージェントが書き戻す場合です。

私はレナです。ここで立ち止まったのは、最も自動化されたワークフローが最もクリーンなものではないからです。最もクリーンなワークフローとは、すべての引き継ぎが明確なものです。

ステージ	エージェントアクセス	人間のゲート
取得	スコープ付きCLIを介して1つのADRを読む	正確なノートと判断を確認する
適用	1つのリポジトリまたは分離されたワークツリー	差分と検証を確認する
追加	レビュー済みの証拠のみ	最終的なボールト書き込みを承認する

ボールトからコードへのタスクを定義する

1つのアーキテクチャ決定記録を取得する

1つのADRから始め、「すべての関連プロジェクトのコンテキスト」から始めないでください。Engineeringという架空のボールトがあり、その決定はArchitecture/ADR/ADR-0042.mdに保存されていると仮定します。リポジトリは~/work/acme-apiという別の架空のプロジェクトです。

取得の目標は簡単です: ADR を見つけ、その正確な内容を読み、現在の変更に必要な決定のみを Claude Code に渡します。Obsidian の現在の CLI は、ボールトのターゲティング、フォルダ単位の検索、正確なパスのターゲティング、およびファイルの読み取りをサポートしています。そのドキュメントには、ボールトを明示的にターゲットにする場合、vault=<name-or-id> をコマンドの前に置く必要があるとも記載されています。

制御されたルックアップは次のようにすることができます:

Bash

obsidian vault="Engineering" search query="ADR-0042" path="Architecture/ADR" format=json
obsidian vault="Engineering" read path="Architecture/ADR/ADR-0042.md"

いくつかのノートが同じ名前に解決される可能性がある場合、短いファイル名に頼るのではなく、検索後に正確なpath=を使用してください。これは小さな詳細ですが、ボールトの自動化から意外に大きなあいまいさを取り除きます。

1つの確認済み実装ノートを追加する

書き戻しは、二つ目の自律タスクになるべきではありません。既に人間がレビューした内容を記録するべきです：どのADRが適用されたか、どのリポジトリの変更がそれを表しているか、どの検証が実行されたか、そしてまだ残っている制限事項は何か。

私はクロードに自身のナラティブから「証拠」を作り出させるつもりはありません。証拠は検査可能なリポジトリの状態から得られるべきです：最終的な差分、テスト出力、そして該当する場合はコミット識別子です。そのメモはこれらの事実を要約することはできますが、置き換えるべきではありません。

ボールト、リポジトリ、CLI を準備する

最初の書き込みを行う前に、ボールトをバックアップしてください。ADRフォルダは、個人的なメモ、資格情報、会議記録、またはClaudeが必要としないものから分けて保持してください。このワークフローでは、Claude Codeの追加ディレクトリアクセスを通じてボールト全体を公開することはしません。代わりに、Obsidian CLIに特定のボールト読み取りを実行させ、Claude Codeはリポジトリ内で管理してください。

2026年9月3日現在、Obsidianの公式ヘルプによると、CLIはObsidian 1.12インストーラーを必要としており、現在はインストーラーのバージョン1.12.7以上を指定しています。デスクトップアプリも実行中である必要があります。閉じている場合、最初のCLIコマンドがアプリを起動します。コマンドを公開する前に、現在のObsidian CLIのドキュメントを確認してください。CLIの動作は、私が黙って仮定するよりも再確認したいタイプの詳細だからです。

クロード側では、保守的な権限モードから始めてください。Anthropicは現在、defaultが編集やほとんどのBash操作を承認後に行わせる一方で、組み込みの読み取り専用コマンドのセットはプロンプトなしで実行できると文書化しています。一方、planはソースファイルを編集せずにコードベースを探索することを意図しています。権限ルールは、敏感なパスへのアクセスを明示的に拒否することもできます。

これはまた、NISTが公開したエージェントツール使用の分類法に記載されているアクセスモデルとも一致しており、エージェントシステムを考える際に、読み取り専用、制限付き書き込み、より広範な書き込みアクセスを分けています。この開発者向け知識ワークフローでは、必要以上に権限を与えるよりも、少なめに権限を与え、追加のアクションを1つ承認する方が、コードエージェントに不要なフォルダへのアクセス権をひそかに与えるより安全だと考えます。

コードを編集する前にコンテキストを取得する

最初のClaude Codeのプロンプトは、実装タスクではなく読解タスクにすべきです。取得したADRを与え、次の三つを文章で求めてください：建築上の制約、影響を受ける可能性のあるリポジトリ領域、そして編集を妨げるべき曖昧さ。

それは有用なレビューのポイントを作ります。もしADRがすべてのアウトバウンドHTTPコールが共有のリトライポリシーを使用するべきだと言っているなら、クロードはすぐに5つのクライアントを変更すべきではありません。まずアウトバウンドコールがどこにあるか、そしてリポジトリが現在どのポリシーを使用しているかを特定するべきです。

もしその読みが間違っていれば、そこで止めてください。正しければ、別の編集フェーズに移ります。ここでプランモードが価値を発揮します：アーキテクチャの決定は文脈であり、しかしそれはトピックに関連するすべてを変更する許可ではありません。

決定を適用し、証拠を記録する

重要な変更の場合は、作業を分離してください。Claude Code は現在、自身の --worktree ワークフローを文書化しています。一方、Git は作業ツリーをリポジトリの履歴を共有する別の作業ディレクトリとして定義しています。

架空のセッションは次のように始めることができます:

Bash

cd ~/work/acme-api
claude --worktree adr-0042-retry-policy

現在のGit作業ツリーのドキュメントは、Claudeとは独立して作業ツリーを検査、一覧表示、修復、または削除する必要があるときに、手元に置いておく価値があります。

では、クロードに一つの限定された指示を出してください：特定されたモジュール内でのみADR-0042を実装し、その範囲外では動作を保持し、リポジトリで承認された検証を実行し、タスクを独自に拡張するのではなく必要なフォローアップを報告すること。

証拠は最高の意味で退屈であるべきです。差分を読み、変更されたファイルのリストを確認してください。変更が重要な場合は、自分で関連するテストを実行または再実行してください。コミットがある場合は、その識別子を記録してください。

Claude Codeは、現在のドキュメントによると、会話データをJSONLセッションファイルとしてローカルに保存し、変更前に影響を受けるファイルのスナップショットを作成します。私はそれを、実装が正しいことの証拠ではなく、セッションを再開したり巻き戻したりするための運用履歴として扱います。

人間による確認後のみ書き戻す

実装がレビューを通過したら、短い証拠ノートを1つ用意してください。安定した構造は後での検索をはるかに容易にします。

Plain

ADR: ADR-0042
Repository: acme-api
Reviewed change: retry policy applied to outbound billing client
Evidence: reviewed diff; targeted tests passed
Commit: <reviewed-commit-id>
Open issue: none
Reviewed by: human

それから、それを既知のプロジェクトノートに追加します：

Bash

obsidian vault="Engineering" append \
  path="Projects/Acme/API/implementation-log.md" \
  content="\n## ADR-0042 implementation\nADR: ADR-0042\nRepository: acme-api\nEvidence: reviewed diff; targeted tests passed\nCommit: <reviewed-commit-id>\nReviewed by: human"

オブシディアンは append を使用して、提供された内容をターゲットファイルに追加することを文書化しており、path= は正確なファイル選択に利用可能です。書き込みの後、一度ノートを読み返します。その最終読み取りは低コストであり、プロジェクト知識として定着する前に、間違ったボールト、間違ったパス、引用ミス、または重複書き込みのミスを検出できます。

一般的な障害と復旧

最初の失敗は間違った金庫をターゲットにすることです。ターミナルが金庫の中にある場合、Obsidianはデフォルトでその金庫を使用できます。それ以外の場合は、アクティブな金庫が使用されることがあります。このワークフローでは、vault=を明示的に指定し、最初に配置してください。

もう一つの失敗は、タスクが必要とする以上にクロードにアクセス権を与えることです。1つのADRがそこにあるという理由だけで、ノート全体のディレクトリを追加しないでください。機密パスは拒否したままにし、シェル呼び出しは意図的に承認し、通常のワークステーションでは権限回避モードを避けてください。

ワークツリーは独自のリカバリ境界を追加します。古いコーディングセッションを再開する前に、git statusとgit worktree listを確認してください。Claude Codeは現在、変更が残っている場合の異なる処理を含め、自動ワークツリー作成およびクリーンアップの挙動を文書化していますが、公開前にそれらの詳細を再確認し、永続的な方針として扱うのではなく検証した方がよいでしょう。

リトライは、実装ノートを重複させることもあります。公式の Obsidian CLI ドキュメントでは、append を冪等操作として説明していません。2回目の追加を行う前に、ADR ID またはレビュー済みコミットを宛先ノートで検索してください。

よくある質問

オブシディアンのベースはクロードコードに構造化されたコンテキストを提供できますか？

はい、条件付きで可能です。Obsidian CLIは現在base:queryを提供しており、ドキュメント化されたフォーマットにはJSON、CSV、TSV、Markdown、およびファイルパスが含まれます。Claude Codeは、ワークフローがそれを渡す場合や関連するコマンドを許可する場合にその出力を消費できます。これは公式に文書化されたネイティブのObsidian-Claude統合ではないため、クエリを制限し、権威あるコンテキストとして扱う前に戻ってきた内容を確認してください。

プラグイン生成のコマンドは、安定した機械可読の出力形式を生成しますか？

公式のObsidianドキュメントによると、CLIはプラグインによって登録されたコマンドを一覧表示し、コマンドIDで実行することができます。任意のプラグインコマンドから安定した機械可読スキーマが提供されるという公式の一般的な保証は見つかりませんでした。それ以上は自信を持って答えられないので、出力の契約は自動化の安定性を仮定するよりもプラグイン固有のものとして扱うべきです。

Claude CodeはCLIを通じて埋め込まれたCanvasコンテンツを取得できますか？

現在のCLIリファレンスには、Canvasに対応した取得コマンドは記載されていません。Obsidianは、.canvasファイルがオープンJSON Canvas形式を使用していることを文書化しています。したがって、生ファイルへのアクセスは別の方法を提供しますが、Obsidian CLIが現在Claude Codeのために埋め込まれたCanvasコンテンツのセマンティック抽出を行っているとは言えません。

Claude Code がノートを追加する際、ウィキリンクのエイリアスは保持されますか？

Obsidianはエイリアスの確認やコンテンツの追加操作を記録しますが、追加中にwikilinkのエイリアスが保持されることを特に保証する公開された情報は見つかりませんでした。エイリアスの構文が重要であれば、レビュー済みの正確なテキストを追加し、すぐに宛先ノートを読み返してください。

このワークフローで Obsidian Headless はデスクトップアプリの代わりになりますか？

同じCLIワークフローのドロップイン置き換えとしてではありません。Obsidianは現在、HeadlessをSyncやPublishを含むサービス向けのオープンベータ版の独立クライアントとして説明しており、Obsidian CLIはデスクトップアプリケーションを制御します。Headlessは、異なるファイルベースのエージェントワークフローのためにサーバーに同期されたボールトを配置することができますが、公式ドキュメントでは、デスクトップCLIコマンドの全面的な実装として位置付けられているわけではありません。(Obsidian)

結論

Obsidian Claude Code の便利なバージョンは意図的に小さい：1つのADRが出て、1つのコード変更がレビューされ、1つの証拠ノートが戻る。

それだけで、オブシディアンを開発者の知識ワークフローの一部にすることができますが、ボールトが自律的な記憶であるかのように装ったり、コーディングエージェントにプロジェクト知識への永久的な書き込み権限を与えたりする必要はありません。ボールトのバックアップを常に最新に保ち、権限を限定し、ワークツリーを検査可能にし、人間によるレビューを唯一の書き戻しの方法にしてください。

それはひとまずこの辺で置いておきます。興味深いのは、エージェントが金庫にどれだけ到達できるかではありません。重要なのは、どれだけアクセスを制限しても、ループを完了できるかです。

前の投稿:

このボールトからコードへのフローを他のコーディングエージェントのコントロールサーフェスと比較したい場合、T3 Code review は、プロバイダーCLI、権限モード、差分、PRの引き渡しを1つのワークスペースでどのように管理できるかを示しています。
Claude Code を外部ツールに接続する際の権限面については、Claude Code MCP security が、ツールの信頼、スコープされたアクセス、承認、機密パスに明確な境界が必要な理由を説明しています。
Obsidian ノートと実際のエージェントのメモリを混同しないようにするために、agent workflow memory は、再利用可能なルーチンと検証済みの経験が通常の保存されたコンテキストとどのように異なるかを説明しています。
この引き渡しの背後にある広範なアーキテクチャを知りたい場合は、AI agent architecture tools memory planning が、計画、メモリ、ツール、オーケストレーション、権限、リカバリがどのように組み合わさるかをマップしています。
レビュー済みの書き戻しの証跡レイヤーについては、deterministic replay for LLM agents が、ファイル読み取り、コード変更、テスト、承認、最終成果物に関する記録がどのように保持されるべきかを示しています。