Scribe と Notion：共同アウトラインから単独原稿への引き継ぎ

Scribe と Notion：共同アウトラインから単独原稿への引き継ぎ

2026年現在、多くの執筆サークルにとって、最も摩擦の少ない協業ツールは Notion です。「深い個人ナレッジベース」のレーンに位置する Obsidian と異なり、Notion の真の強みは、複数人が同じコンテンツを同時に閲覧・編集・議論できる点にあります。共著サークル、IP の共同開発、シニア編集者が最初から最後まで併走する著者――こうした座組では、Notion 内に肥大したプロジェクト空間ができあがっていきがちです。アウトライン、人物表、調査資料、議論メモ、刊行スケジュールが、同じワークスペースに同居しているわけです。

しかし Notion は、本文そのものを書く場所としては適しません。ブロックベースのエディタは長い連続読みに不向きで、カーソル移動、ページング、文字数表示すべてがプレーンテキスト系エディタより半拍遅れて感じられます。「ページ」という概念は、本の章境界を曖昧にします。「第3章の後半がサブページの中に入っている」といった構造的混乱が起きやすいのです。より実務的な問題として、Notion はクラウド型の協業ツールなので、編集には常にネット接続が必要です。これは長編ドラフトに求められる没入状態にも、リリース前で厳しいアクセス制御を要する原稿にも、好ましくありません。

Catalpas Atelier Scribe と Notion の関係は、「前段の協業 → 後段の仕上げ」に近いものです。本当に複数人を必要とする部分――アウトラインの合意、素材集め、スケジュール調整――は Notion に残します。「一人で章ごとに書き進める」「EPUB と印刷用 PDF を書き出す」は Scribe が引き取ります。二つのツールは衝突しません。重要なのは、引き継ぎが正しい時点で起きることです。

Notion はアウトライン向き、本文向きではない

トライアル期間に Notion の柔軟さに魅せられて「本文もここで書いてしまえないか」と考える著者は少なくありません。短期的には可能です。2万字以下の中編や、単一ラインのノンフィクションなら、Notion でも処理できます。しかし8万字を超える長編原稿を Notion に入れると、時間とともにいくつかの問題が浮上します。

第一に、長文編集のパフォーマンス。単一ページが数万字を超えると、カーソル応答、自動保存、スクロールすべてに体感できる遅延が出てきます。これはブロックベース・アーキテクチャの長文に対する性質であり、単一のアップデートでは恒久的には解決しません。第二に、章構造が断片化する点。Notion のサブページ機構は、章ごとに子ページを切ることを促しますが、書式を統一したい、総文字数を数えたい、頭から通して読みたいとなると、サブページをまたぐ操作が痛みになります。第三に、オフラインとバックアップ。Notion のオフラインモードはまだ限定的で、「原稿は自分のハードディスクの上に置いておきたい」という長編の基本要件を満たし切れません。

これらは設計上の欠陥ではなく、「協業ワークスペース」と「長編執筆ツール」の本質的な違いです。Notion は自分のレーンでは依然として優れています。

引き継ぎ点：アウトライン凍結 ＋ 第一章が固まる前

Notion から Scribe へ切り替えるのはいつか。二つの信号が重なるところが引き継ぎ点です。

信号その一：アウトライン凍結 ―― あなたと協業者（または編集者）が Notion 上でアウトラインを合意し、章順、主要プロット、キャラクターアークの80%以上が固まっている状態。今後の変更は局所的になります。アウトラインがまだ大きく動いている段階で切り替えると、双方を何度も同期する作業に時間を取られるだけです。

信号その二：第一章が固まる前 ―― 本文に着手していないか、簡単な試行シーンを書いた程度。Notion でもう5、6章ドラフトしてしまっている場合、「既存の本文をどう処理するか」という追加の問いに直面します。その場合の現実解は、既存の本文を Scribe に「下書き素材」として取り込み、Scribe 上で章ごとに整えていくことです。「ロスレス移行」をしようとしないでください。

切り替え後も、Notion のアウトラインページを削除しないでください。明示的に「参考状態」と記しておきます。今後アウトラインを変更するときは、まず Scribe プロジェクトのアウトラインビュー上で行い、その結果を Notion に書き戻して協業者が見られるようにします。中核ルールは一つ。本文とアウトラインの最新版は、それぞれ一箇所にしか存在しない。

Notion 書き出しの落とし穴：入れ子トグル、データベース、サブページ

Notion から Markdown に書き出すと情報が落ちます。よくある損失を三つ把握しておけば、切り替え時の驚きを避けられます。

入れ子トグル ―― Notion のトグルブロック（クリックで展開／折りたたみ）は、Markdown 書き出しで見出しとインデントになり、二階層を超えると崩れがちです。アウトラインの階層構造がトグルの折りたたみに依存しているなら、書き出し前に H2/H3 見出しへ平坦化してください。

データベース ―― Notion のデータベース（人物表、章テーブル、ToDo リスト）は、書き出し時にプレーンなテーブルかリンクの羅列になり、構造的なリレーションはほぼ失われます。最も確実な手は、書き出し前に重要なデータベースをスクリーンショットで残し、コアフィールドを別ファイルの Markdown テーブルにコピーすることです。「書き出した後でリレーションを復元しよう」はほぼ機能しません。

サブページ ―― 子ページは Markdown 書き出しで個別のフォルダとファイルに分かれ、リンク関係が散らばります。Notion 内でサブページを多用してコンテンツを整理していた場合、書き出し後には、手作業で繋ぎ直す必要のある .md ファイルの山が残ります。

これらを踏まえると、最善は「アウトライン＋人物表のコアフィールド」だけを移行し、Notion ワークスペース全体をローカルに鏡映しようとしないことです。Notion の協業空間は生かしたまま運用を続けます。それは協業プロセスの乗り物であって、原稿そのものではありません。

刊行後：ナレッジの行き先

本が完成して出荷された後、Notion のプロジェクトページにも処遇を決める必要があります。一般的な選択肢は二つです。

参考資料としてアーカイブする ―― ワークスペースを「完了」と印を付け、権限を読み取り専用に切り替え、Notion 上に将来プロジェクト向けの参考ライブラリとして残します。同じ協業者と次の本を作る予定があるなら、これが最もコストの低い選択です。

個人ナレッジベースに濾し直す ―― Obsidian ボールトなど長期的なナレッジシステムを別に維持しているなら、プロジェクト横断で再利用できる内容（世界観、共有設定、調査資料）を書き出し、個人ベースにマージします。プロジェクト固有のスケジュールや議論メモは Notion に残します。

やってはいけないこと：「念のため」と言って Notion の内容を全部 Scribe プロジェクトやローカルアーカイブに押し込まないでください。Scribe プロジェクトはこの本の完成原稿であって、プロジェクトのアーカイブではありません。何でも詰め込むとプロジェクトファイルが膨張し、書き出し時に奇妙な組版の崩れを引き起こします。

Notion と Scribe の長期的な共存には、単純な根拠があります。協業はなくなりません（次の本でも編集者とアウトラインを作るかもしれません）。仕上げ工程もなくなりません（各本には依然として EPUB と印刷用 PDF が要ります）。それぞれが得意分野を引き受ければ、ワークフローはかなりすっきりします。

Notion の共同アウトラインの下流にどう収まるか、Scribe で確かめる →

こちらも合わせて

• Scribe のコラボレーション・ハブ ―― 他の執筆・ノート・レビューツールとのワークフローへの入り口
• Scribe と Obsidian：ナレッジベース＋原稿の二段階ワークフロー ―― 個人ナレッジベースも Obsidian で運用している場合