Scribe と Obsidian：ナレッジベース＋原稿の二段階ワークフロー

Scribe と Obsidian：ナレッジベース＋原稿の二段階ワークフロー

2026年現在、Obsidian はインディー著者の間で最も使われているノート・ナレッジツールの一つです。双方向リンク、ローカルの Markdown ファイル、プラグインのエコシステムが、「長期的な参考ライブラリを育てる」という用途においてほぼ無敵の地位を作っています。多くの著者は一冊書き終えてから、本当に時間を投じたのは数百時間のドラフトではなく、何年も走らせてきた、人物ファイルや年表や世界観の細部が詰まったボールトだったことに気づきます。

問題は、Obsidian の強みが「仕上げ」工程ではそのまま弱みになる、という点です。ボールトは原稿ではありません。「章順」という線形概念を持たず、PDF/EPUB 書き出し時には Wikilink がプレーンテキストになり、テンプレートプラグインの YAML ブロックが本文に漏れ出し、散在する数百のノートは統一された組版やフォントを共有しません。これは設計上の欠陥ではなく、「ナレッジツール」と「原稿ツール」の本質的な差です。ボールトをそのまま印刷に回そうとするのは、道具の選び方を誤った使い方です。

Catalpas Atelier Scribe は、このフローにおいて Obsidian の代替ではなく、その下流に位置します。Obsidian は長期的な蓄積――世界観、人物表、調査メモ、着想のかけら――を引き受けます。Scribe は「この一冊」――線形の章、組版、最終的な EPUB と印刷 PDF――を引き受けます。境界線を引いてしまえば、「このノートはどちら側に置くか」「ボールト内の章ドラフトを編集し続けるべきか」と悩む必要はなくなります。

ボールトは原稿ではない：それを強いるべきでない理由

Obsidian を初めて触る著者の多くは、ボールト内で章を直接書く実験をします――1章につき1ノート、01-prologue.md、02-chapter-1.md のように命名して。最初の10章までは問題なく見えます。しかし50章まで進み、改稿を重ね、「12章の前に回想を一つ挿入したい」といった構造変更が入ると、問題が積み重なり始めます。Obsidian のファイルブラウザには長編原稿向けの章順序がなく、一括並び替えもなく、版のスナップショットもありません。検索は「このキャラクターがどのノートで言及されたか」には強いが、「この稿と前の稿でこの場面はどこが変わったか」には不向きです。

本当の頭痛の種は書き出しです。Obsidian 公式の PDF 書き出しは Markdown のレンダリングスタイルをそのまま保持する形式で、印刷用としては精度も安定性も足りません。コミュニティプラグイン（Pandoc Plugin、Better Export）はより複雑な書き出しを可能にしますが、設定コストが高く、Obsidian 本体やプラグインの更新で突然パイプラインが壊れることもあります。「ボールト内で章を書くべきか」という問いの核心は、技術的にできるかどうかではなく、ドラフトの完成度が80%を超えたとき、ボールトが助けになるか足を引っぱるか、という点です。一冊書き切った経験のある著者はほぼ全員、ある時点からボールトが足を引っぱり始めた、と答えるはずです。

二段階ワークフロー：切り替え点はどこか

より持続可能な進め方は、Obsidian と Scribe を明確な引き継ぎを伴う二段階に分けることです。

第一段階（Obsidian 内） ―― まだ形になっていない一切がここに住みます。人物ファイル、世界観、調査クリップ、着想、ざっくりした章順、各章の試し書きの最初の数段落まで。この段階の特徴は「情報密度は高く、構造は緩い」で、必要なのはボールトの双方向リンクと検索です。長期的に走らせるボールトを、向こう十年の執筆の基盤として、プロジェクト横断で再利用できるものにできます。

引き継ぎ点 ―― ある特定プロジェクトのアウトラインが安定し、「順番に章を書いていく」段階に入る準備が整ったとき、切り替えどきです。一般的な信号は、章タイトルの80%以上を挙げられ、各章を一、二文で要約できる状態。それより前は Obsidian に留まるのが正しく、それを過ぎても Obsidian に留まると進行が鈍ります。

第二段階（Scribe 内） ―― アウトラインを独立した Scribe プロジェクトに落とし込みます。ここでは「章」が第一級市民として扱われ、組版とフォントは統一され、EPUB と印刷 PDF への書き出し経路が用意されます。この瞬間から、本文の最新版は Scribe プロジェクトにしか存在しません。Obsidian 内の章ドラフト（あれば）は「参考」に格下げされ、以後は編集されません。

この二段階アプローチの核心は技術ではなく、規律です。どの成果物がどのツールに住むかを明示的に決め、本文の「最新版」を二箇所で抱えないこと。本文を両側で並行管理した瞬間、作業量は1.5倍に膨らみ、版の不一致リスクが累乗的に増えます。

資産の移行：何を持っていき、何を残すか

第二段階が始まるとき、ボールトから持ち出すものはあります――が、全部ではありません。

持っていくもの：このプロジェクトの章アウトライン（ボールトに書いていた場合）、人物カードのコアフィールド（名前、関係、本作を貫く核心的な世界観）、本文中に直接出てくる必要のある引用や原典資料。これらは執筆中に繰り返し参照するので、毎回ツールを切り替えるのは時間の浪費です。手作業でコピーしてください。「一括同期」を試みないでください。一括同期システムは別の長期保守プロジェクトであり、インディー著者にとって割の合うトレードではありません。

残すもの：プロジェクト横断の世界観（複数の本で同一宇宙を共有している場合）、調査メモ（第3作で再び要るかもしれません）、着想（その大半は本作には載りません）。これらは Obsidian に残し、必要なときに参照します。Scribe プロジェクトに押し込むと原稿ファイルが膨れます。

移行時の書式の罠：ボールトからのコピペで最も多い混入物は Wikilink（[[キャラクター名]]）と、テンプレート生成の YAML ブロックです。Wikilink は Scribe で自動解決されないので、移行時にプレーンテキストへ変換するか、Obsidian の「Copy as Markdown」を使って wiki 構文を剥がします。Scribe プロジェクトで実際に使っていないフィールドの YAML ブロックは削除します。どちらも難しい作業ではありませんが、省くと書き出し時に「なぜこの段落の書式がおかしいのか」を調べる羽目になります。

二つのツールの長期共存：これは暫定セットアップではない

「ツール移行」を扱う記事の多くは、「最終的にすべてを一つに集約する」ことを終着点として想定しています。Obsidian ＋ Scribe は移行関係ではなく、長期的な共存です。理由は単純です。ボールトは今作が出ても成長を止めない10年資産で、Scribe プロジェクトは特定の本の「完成状態」であり、次の本は新しいプロジェクトを開きます。二つのツールのライフサイクルが、そもそも同期していないのです。

その事実を受け入れるとワークフローはきれいに整います。「いつかは統合するべきか」と悩むのをやめ、「リアルタイム双方向同期」のような小技に時間を投じるのをやめます。Obsidian はナレッジベースを育て続け、Scribe は次の本を出し続ける。二段階の引き継ぎは手動・意図的・プロジェクトごとに行われる――これ自体が良いことで、切り替え時に「このアウトラインは本当に安定しているか？」を確認させる装置として機能します。

すでに Obsidian に大きなボールトを持っていて、「これを次の本にどう変えるか」で詰まっているなら、必要なのは Obsidian のプラグインを足すことではなく、「仕上げ」工程をそれ専用のツールに切り出すことです。Scribe はその役を担おうとしています。

Obsidian ボールトの下流にどう収まるか、Scribe で確かめる →

こちらも合わせて

• Scribe のコラボレーション・ハブ ―― 他の執筆・ノート・レビューツールとのワークフローへの入り口
• ローカルファーストの執筆ソフト ―― ローカルファイル＋Markdown のより踏み込んだ議論