Obsidian Vault から DeMinds の作業ドキュメントへ
Obsidian Vault は、単一の Markdown ファイルであることはあまりありません。多くの場合、フォルダ、ホームノート、Wiki Link、添付ファイル、そして書き方の習慣によって形づくられた知識構造です。DeMinds がこのような内容を扱うとき、Vault 全体を引き継ごうとしたり、もう一つの Obsidian になろうとしたりはしません。
より正確に言うと、DeMinds が行うのは、ユーザーが明示的に選択した Vault の内容を、読めて、編集できて、プレビューでき、エクスポートできる Markdown 作業ドキュメントへ正規化することです。
1. README をそのまま開く前に、まず入口を識別する
通常の Markdown Package では、README.md、index.md、またはパッケージ名と同じ Markdown が入口として使われることがよくあります。一方、Obsidian Vault には Home/Home.md のような専用のホームノートがあり、.obsidian/app.json や Homepage プラグイン設定から参照されていることがあります。
DeMinds は、こうした Obsidian のホームシグナルを優先して識別します。そのため、ユーザーが Vault を開いたとき、ルート直下の README.md に誤って誘導されるのではなく、元の Vault の読み始めに近い推奨入口を確認できます。
このステップの目的は「Vault 全体を自動インポートする」ことではありません。ユーザーが正しい場所から選択を始められるようにすることです。
2. 開くドキュメントはユーザーが明示的に選択する
Obsidian Vault 内の Markdown には、それぞれ異なる役割があります。ホームノート、目次ノート、下書き、テンプレート、アーカイブ、デイリーノートなどです。DeMinds はすべての Wiki Link を再帰的にたどらず、Vault 全体を自動的に一つの長いドキュメントへ連結することもしません。
ユーザーは Document Chooser で、1 つまたは複数の Markdown ドキュメントを選択できます。
- 1 つだけ選択すると、そのドキュメントを作業ドキュメントとして開きます
- 複数選択すると、選択順または Vault 構造に基づいて新しい baseline を生成します
- キャンセルした場合、ワークスペースもスナップショットも作成されません
この設計により、DeMinds の境界は明確に保たれます。Vault を読み取ることはできますが、Vault 全体をインデックス化しません。作業ドキュメントは生成しますが、元の Obsidian フォルダをその場で書き換えることはありません。
3. すべてのノートを平坦化せず、Vault 構造を保つ
ユーザーが複数のドキュメントを選択した場合、DeMinds は Vault 構造に沿って作業ドキュメントを生成できます。たとえば Areas/Research/Methods/Literature Review.md は、単なるフラットな項目として扱われるべきではありません。Vault 内での位置そのものが意味を持っています。
これは読みやすさに大きく関わります。多くの Obsidian Vault では、フォルダ構造そのものが知識の整理方法です。Product、Package、Obsidian、Scenarios といったディレクトリは単なる入れ物ではなく、文脈と内容の境界を表しています。
DeMinds による正規化結果では、こうした構造が引き続き見える必要があります。同時に、選択された内容は 1 つの Markdown 作業ドキュメントへ収束し、導図と Markdown Preview の両方で読み進められるようになります。
4. Wiki Link と Wiki Embed を静的に扱う
Obsidian の [[Wiki Link]] と ![[Wiki Embed]] は、Vault 内部の読書体験にとって重要です。ただし DeMinds は Obsidian プラグインを実行せず、リンクグラフ全体を展開することもしません。
その代わり、DeMinds は静的な正規化を使います。
- 選択済みで一意に解決できる Wiki Link は、作業ドキュメント内の内部リンクに変換できます
- 未選択、欠落、または曖昧な Wiki Link は、読めるテキストへフォールバックします
- 画像の Wiki Embed は、標準の Markdown 画像参照へ変換されます
- ノートの Embed は再帰的に展開せず、読める参照として残します
この方法により、内容は読みやすく、構造は制御可能になり、エクスポート後も Obsidian の実行時状態に依存しない通常の Markdown として扱えます。
5. リソースパスは自己完結している必要がある
Markdown Package や Obsidian Vault では、同じファイル名のリソースがよく現れます。異なるフォルダにそれぞれ a.png があったり、あるドキュメントが images/a.png を参照し、別のドキュメントが assets/a.png を参照していたりします。
ファイル名だけでリソースを統合すると、画像が別のファイルを指してしまう可能性があります。DeMinds では、パスに基づくリソース閉包が必要です。つまり、選択されたドキュメントが直接参照し、実際に存在し、安全な境界内にあるリソースだけを保持します。
マージされた baseline では、リソース参照は説明しやすく、エクスポート可能な相対パスへ書き換えられます。これにより、エクスポートされた Markdown Package は自己完結し、DeMinds の外でも確認・保守できます。
6. Markdown Package 対応が Obsidian 対応の土台になる
Obsidian Vault 対応は、孤立した機能ではありません。入口の推奨、Document Chooser、複数ドキュメントのマージ、リソース閉包、パスを保つエクスポートといった、DeMinds の Markdown Package 能力の上に成り立っています。
通常の Markdown Package では、多くの場合「順序合併」が既定として自然です。Obsidian Vault では、多くの場合「Vault 構造」が既定として適しています。どちらも同じ基本原則に従います。パッケージ全体をコピーするのではなく、ユーザーの明示的な選択を中心に作業ドキュメントを生成することです。
7. DeMinds の価値：構造を、続けて作業できるドキュメントにする
DeMinds は Obsidian を置き換えようとしているわけではなく、すべての知識ベース機能をアプリ内に再現しようとしているわけでもありません。むしろ、次のようなワークフローに向いています。
- Obsidian、Web ページ、AI 会話、Markdown Package から、続けて扱いたい内容を取り出す
- Markdown 作業ドキュメントへ正規化する
- 導図で構造を確認する
- Markdown Preview で読む
- 編集、整理、エクスポートを続ける
長期的な知識資産にとって、この方法の価値は明確です。内容は Markdown のまま残り、構造は導図として確認でき、リソースパスは移行しやすく、成果物が単一のツールに閉じ込められません。
8. 典型的な場面：AI 会話を整理する
多くの AI 会話は生成された時点では有用ですが、長期保存すると管理しにくい長文になりがちです。DeMinds はこのような内容を構造化 Markdown に整え、さらにエクスポートしたり、知識ベースへ移したりする手助けができます。
この流れは、Obsidian Vault の扱いと同じ考え方に基づいています。DeMinds が重視するのは「どのツールから来た内容か」ではなく、その内容を読めて、編集でき、移行可能な構造化 Markdown にできるかどうかです。
まとめ
「Obsidian Vault から DeMinds の作業ドキュメントへ」は、完全な移行ではなく、Obsidian の代替でもありません。
それは構造化された読書の流れです。DeMinds は入口を識別し、ユーザーに内容を選ばせ、Vault 構造を保ち、リンクと添付ファイルを静的に扱い、続けて作業できる Markdown ドキュメントを生成します。
これが DeMinds の中核的な位置づけです。知識資産を読みやすく、編集しやすく、移行しやすい状態に保つ、ローカルファーストの Markdown + 導図ワークスペースです。