Personal Knowledge Base（PKB）を「メモアプリにチャットを足しただけ」で終わらせると、取り込みは増えても整理が追いつきません。結論から言うと、Obsidian のローカル Markdown を共有メモリにし、Vault を CLI エージェントの作業ディレクトリ（cwd）として扱うと、取り込み・整理・蒸留のループを設計しやすくなります。
📑目次
本記事では、Vault をエージェント作業場にする段階設計を整理します。製品要件は Claudian 公式リポジトリ と Hermes Agent 公式ドキュメント を軸に、独立ガイドと運用報告で裏取りします。人気度や発見シグナルだけでは導入判断を確定しません。
なぜ「Vault＝エージェント作業場」なのか
結論はシンプルです。チャット履歴だけに知識を閉じ込めると、コンテキストが切れた瞬間に再利用性が落ちます。一方、Vault 上の Markdown を正本にすれば、人が読み、エージェントが read／write／search／bash で触る共通面ができます。
理由は次の三点です。
- 主権がローカルに残る — Obsidian はローカル Markdown を中心に置けるため、思考空間を Private／Malleable／Independent に保ちやすい、という整理が独立分析でも示されています（note.com / kagawatomo）。
- エージェントの作業単位が明確になる — Claudian は Vault を作業ディレクトリにし、サイドバーからマルチステップのエージェント操作を行う製品として説明されています（GitHub: YishenTu/claudian）。
- 役割を分割できる — 外部からの捕捉（capture）と Vault 内の蒸留（distill）を別レイヤに分けると、認証トークンの置き場と失敗面が読みやすくなります。Hermes 公式は外部ツール・gateway・永続メモリを持つ自律エージェントとして定義されています（Hermes Agent Docs）。
読者への含意は明確です。今日決めるべきは「最強の1ツール」ではなく、人が残す判断とエージェントが書いてよい領域の境界です。
2026年のPKB構図 — 人が考える場所とエージェントが保守する知識
2026年の議論では、知識ベース全体をエージェントに丸投げするより、人間の思考空間とエージェントの保守作業を分ける見方が現実的です。
独立分析が示す分業
独立分析（note.com / kagawatomo）は、Obsidian を「思考を研ぎ澄ます場所」として位置づけ、Karpathy の LLM Wiki（raw／wiki／schema と ingest／query／lint）、GBrain、Hermes Agent を「知識保守をエージェントへ寄せる」潮流として並べます。
ポイントは全自動化ではなく、どこまで任せてよいかを問う分業です。
Hermes 公式が示す製品定義
Hermes 公式ドキュメントは、Skills の自己改善、永続メモリ、多数のツール、MCP、メッセージング gateway を製品定義に含みます。IDE に閉じないエージェントとして、外部接続や捕捉を担当させる設計と相性がよいです。
公式の user stories には、Obsidian への日次ログ、タスク、Vault Markdown を長期メモリにするコミュニティ事例が集約されています。
実務で先に分ける三領域
実務で先に分けるとよい三領域は次のとおりです。
| 領域 | 人が担う例 | エージェントが担う例 |
|---|---|---|
| 判断 | 公開可否、優先度、最終承認 | 下書き案、要約候補、差分提案 |
| 保守 | フォルダ規約の決定 | ingest、lint、リンク修復、日次ノート生成 |
| 接続 | どの外部源を信頼するか | 許可されたツール経由の取得・書き戻し |
表の読み方は単純です。エージェントの能力表を集める前に、判断を渡さない領域を先に言語化してください。ここが曖昧なまま自動化すると、上書き事故や機微情報の混入が増えます。
出典（2026年7月時点の公開説明に基づく）:
Level 0 — Claudian で Vault をエージェント cwd にする
Level 0 の定義は「Vault を開いたまま、CLI エージェントをサイドバーから回す」最小構成です。単なる会話パネルの埋め込みではなく、Vault cwd 上でファイル操作を伴うエージェント実行が中核です。
製品として確認できること
Claudian 公式リポジトリ は、Claude Code／Codex／Grok／Opencode／Pi などを Obsidian に埋め込み、チャット（マルチタブ）、inline edit と diff、slash Skills、@mention、Plan Mode、MCP を提供すると説明しています。前提は次です。
- Desktop 版 Obsidian（1.7.2+）
- Claude Code CLI 必須（Codex 等は optional provider）
- Community Plugins、または release の
main.js/manifest.json/styles.css
独立ソースでの二次確認
独立要約で確認できる点:
- dsebastien.net も同系の機能セットと Desktop／1.7.2+ 要件を列挙しており、公式 README の二次確認になります。
運用ガイドで確認できる点:
- NateCue のガイド は、事前インストールした CLI への接続、sidebar chat、inline diff、Plan Mode、MCP hub としての位置づけをまとめています。
- プラグイン独自テレメトリなし（データは設定した provider のみ）、nvm 環境での CLI path トラブルシュートも実務視点で触れられています。
運用で効く型（半年運用の例）
Qiita（tasekino） は、Claudian 経由で Claude Code を半年運用した報告です。要点は次です。
daily/notes/news/memoなど、役割付きフォルダ規約を先に置く- 開いているノートをコンテキストに渡す
/dailyなどのカスタム slash で Daily 生成を一本化する- 上書き事故の後、
CLAUDE.mdに確認必須ルールを蓄積する（失敗→メモ→ルール化）
Level 0 で最初に入れるガードレール
機能追加より先に入れるべきなのは次です。
- Plan Mode と diff preview を既定にする
- 一括上書きを禁止する文言をプロジェクト指示へ書く
- 機微フォルダの ignore／許可リストを先に決める
- モバイル同期だけの環境では Level 0 を無理に推さない（Desktop 前提）
出典（2026年7月時点）:
役割分担 — Hermes capture / CLI distill / 代替アーキテクチャ
1つのエージェントに capture も distill も全部載せると、権限境界とトークン境界が曖昧になります。
三分業の実務フレーム
実務フレームとしては次の三分業が扱いやすいです。
- Hermes（capture） — 外部メッセージ、ツール認証、gateway 経由の取り込み。公式 docs の tools／MCP／messaging が根拠。
- CLI エージェント via Claudian（distill） — Vault 内の整理、要約、lint、リンク修復。
- 人（判断） — 優先度、公開可否、「本当に任せてよいか」の最終承認。
Hermes 導入済みかどうか
すでに Hermes を使っているなら、外部認証を Hermes 側に寄せ、Vault 作業を Claudian＋CLI に限定しやすいです。
Hermes 未導入なら、Level 0（Claudian のみ）から始め、capture は手動または後段で足すのが安全側です。
代替アーキテクチャ
代替比較として、obsidian-second-brain は Claude Code／Codex 向けの永続 Markdown メモリ、多数の Vault 保守コマンド、hybrid search、scheduled agents を公開しています。
Claudian Orchestra 系テンプレート以外にも、「CLI＋Vault second brain」が存在する、という比較軸になります。
採用分岐
採用分岐は次のように切ると迷いにくいです。
- ノートを開きながら直したい → Claudian Level 0
- チャット／メール等の外部流入が多い → Hermes capture を検討
- スキル群や scheduled 保守を厚くしたい → second-brain 等を比較
- モバイル中心／CLI を入れられない → 本記事の前提外。別経路を設計
出典:
比較表 — Claudian / Hermes / second-brain / 素のCLI
「どれが最強か」ではなく、cwd・UI・capture・保守コマンドのどこを製品に任せるかで選びます。
観点別の比較
| 観点 | Claudian + CLI | Hermes Agent | obsidian-second-brain | 素の CLI のみ |
|---|---|---|---|---|
| 主な場所 | Obsidian サイドバー / inline | CLI・Desktop・messaging gateway | Vault スキル群 + CLI | ターミナル |
| Vault を cwd に | 製品の中核 | 運用で接続（user stories で Obsidian 報告） | 永続メモリ前提 | 手動 cd |
| 強み | ノート文脈・diff・Plan Mode・MCP | 外部接続・Skills 自己改善・永続メモリ | 多コマンド保守・hybrid search・scheduled | 依存最小 |
| 導入前提 | Desktop Obsidian + Claude Code CLI 等 | インストールと provider 設定 | リポジトリ / Skills 導入 | CLI とパス規約 |
| 向く段階 | Level 0（中で回す） | Level 1+（外から取り込む） | 代替・拡張アーキテクチャ | 実験・最小 PoC |
読み方と出典
出典（2026年7月時点）:
元記事に出てくる「Orchestra」は役割分担の一例です。公式と独立ソースで各部品の実在を確認したうえで、自分の capture 源と Desktop 可否に合わせて段階を切ってください。
段階チェックリスト — 今日の次アクション
次アクションは「全部入れる」ではなく、今日の Level と 人が残す判断 の明文化です。
Level 0（今日〜今週）
- Desktop Obsidian 1.7.2+ と Claude Code CLI（必要なら Codex CLI）が動く
- Claudian を入れ、Vault がエージェント cwd になることを確認する
- Plan Mode / diff を既定にし、一括上書き禁止を
CLAUDE.md等へ書く - 機微フォルダの ignore / 許可リストを先に書く
Level 0.5（運用が回り始めたら）
-
daily/notes等のフォルダ規約と slash コマンドを1本だけ追加する（例:/daily） - 失敗→メモ→ルール化のループを週1で振り返る
Level 1（capture を外に出す）
- Hermes 等で外部ツール認証を Vault 外に隔離できるか検討する
- Inbox→整理→蒸留の担当を人とエージェントで表にする
採用判断（actionable judgment）
| 状況 | 判断 |
|---|---|
| ノートを開きながら直したい | Claudian Level 0 が適合しやすい |
| 外部流入が多い | Hermes capture を検討 |
| Claudian 以外のスキル群が欲しい | second-brain 等を比較 |
| モバイル中心 / CLI 不可 | 本記事の Level 0 前提外。無理に推さない |
⚠️ Plan Mode や diff なしの一括書き換え、機微ノートの無制限アクセス、モバイル同期のみでの Level 0 強行は事故りやすいです。導入前に権限境界を先に書いてください。
関連記事:
- Open Knowledge Format（OKF）とは？エージェント向けMarkdown知識仕様の導入判断
- MLOpsの継続的学習とエージェント評価｜Demo Hellを避ける実務設計
- エージェント向け検索の設計｜どう探させ、何を返すか
よくある質問（FAQ）
Q1. Claudian はチャット UI を Obsidian に埋め込んだだけですか？
A. いいえ。公式 README と独立ガイドは、Vault を cwd にした CLI エージェント（read／write／search／bash、Plan Mode、MCP 等）として説明しています。単なる会話パネルではありません。
Q2. Hermes は必須ですか？
A. 必須ではありません。Level 0 は Claudian + CLI で成立し得ます。Hermes は外部 capture・認証・gateway を分けたいときの Level 1+ 候補です。
Q3. スマホの Obsidian だけで同じことができますか？
A. Claudian は Desktop 前提です。モバイル同期のみの環境では Level 0 の前提が崩れます。別経路を設計してください。
Q4. 実践テンプレ記事だけ読めば足りますか？
A. 発見と手順の入口としては有用です。ただし製品要件・プライバシー・代替実装は公式 README と独立ガイド（dsebastien／NateCue／Qiita／note／second-brain）で裏取りしてください。本記事はその差分確認用です。
Q5. エージェントに Vault 全体を任せてよいですか？
A. 安全側は、人間の判断領域を残す分業です。CLAUDE.md のガードレール、Plan Mode、機微パス除外を先に置いてください。上書き事故後にルール化した運用報告とも同型です。
まとめ — 持ち帰る判断軸
- PKB を「Vault＝共有メモリ + エージェント cwd」として設計すると、取り込みと蒸留のループが回りやすくなります。
- Level 0 は Claudian の公式要件と独立ガイドで再現可能な最小構成です。運用知見は Qiita 等が補強します。
- Hermes と second-brain は必須ではなく、capture 分離や代替スキル群のための比較軸です。
- 読者の次アクションは、Desktop／CLI 可否を確認し、Level 0 チェックリストから1段だけ進めることです。人が残す判断を先に書いてください。
導入可否は、発見シグナルではなく、公式・独立ソースと自分の制約で決めてください。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す