最終章から最初のページへ
原稿ソースを選び、引き渡しを確認し、本の制作を始めるまでの実践的な Scroll から Scribe へのワークフロー。
「本を書き、それから出版する」と言えば、二つの行動に聞こえます。セルフ出版を経験した人なら、その間にどれほどの仕事が隠れているかを知っています。正しいバージョンを見つけ、章を集め、欠落を確認し、レイアウトを作り直し、校正で一文だけ直すたびに同じ流れを繰り返します。
結末がまだ動いているのに改ページを調整し始めたら。改稿のたびに「最終」の書き出しが増えたら。電子書籍版と印刷版がそれぞれ別の原稿を抱えたら、半年後にどちらを信頼するのでしょう。
セルフ出版ワークフローの負担は、執筆にも組版にも属さない、その境界にたまります。
Scroll と Scribe は、意図した専門分業でこの境界に向き合います。Scroll は長い作品が構想、執筆、改稿を通じて変わる余地を確保し、交付する原稿ソースを明示的に準備できるようにします。Scribe は、そのソースが Appearance、ページネーション、出版出力へ進めるほど成熟したところから始まります。どちらのデスクトップアプリケーションも同じローカル Project フォルダーを中心に作業を続けられますが、引き渡しが自動であるかのようには扱いません。
まず、方向を見失わずに作品を変えられるようにする
長編執筆が最初のアウトラインを一直線に進むことはほとんどありません。脇役がより多くの場所を求め、書き手が Timeline を見直して日付の矛盾に気づき、ひとつの資料が章全体の論旨を変えます。書き手に必要なのは、早すぎる完成形を要求するレイアウトファイルではなく、変化を受け入れる環境です。
Scroll では、原稿と制作上の文脈が近くにあります。人物と場所、Story data、Timeline、関係、調査、改稿タスク、今日書く章。異なる Story ビューは、小説を別々の容器へ複製せず、問いごとに異なる確認を助けます。
独立系作家にとって、Project として把握できる感覚は、増えていく文字数と同じほど重要です。伝統的な出版社なら、バージョン管理、編集コメント、制作計画を複数の人が分担します。セルフ出版では一人がすべてを抱えることがあります。Scroll はその仕事を本文の近くに置き、ページデザインは原稿が移行に値するまで待たせます。
次に、「最終」を説明できる判断にする
本が完成へ近づくと、ファイル名から先に意味が失われます。編集者確認、著者修正、最終、最終その2。出版意図よりも、その瞬間の感情をよく記録した名前です。
Scroll の Works、原稿バージョン、Publish Version を使うと、今回の版にどの作品と原稿ソースを使うのかを明示できます。古い結末、削除した章、別案は創作の履歴に残しつつ、現在の出版ソースを装わせずに済みます。
これらの記録は本文を凍結せず、Git のスナップショットを作らず、複製をアップロードしません。価値は文脈にあります。「今回は何を出版するのか」が記憶だけに依存しなくなります。修正版、後日の増刷、数か月後にも元原稿を特定したい翻訳では、とくに有用です。
引き渡しの前に現在の作業を保存し、Project フォルダー全体をバックアップしてください。ローカルファーストのファイルも、デバイス故障、誤削除、同期競合の影響を受けます。クラウド同期フォルダーを使うなら、競合の解決と復旧可能な複製の保持はユーザーの責任です。
Scroll で交付を準備する
Scroll の Delivery Center、Delivery readiness、Resolved source は交付準備段階の機能です。Delivery readiness は準備状態を示し、Resolved source は交付に使うソースを明らかにします。選んだ作品、ソース、Project の状態が、作ろうとしている本を表しているかを確認する助けになります。
Delivery readiness は、Scribe が何かを受信または認識した証明ではありません。Scroll 内の準備状況です。書き手は境界の反対側を別途確認します。
この控えめな接続は、運搬専用の原稿を余分に作ることを避けます。同時に「自動出版」も約束しません。Scroll は完成した PDF、EPUB、印刷レイアウトを直接作らず、Scribe の Appearance も作りません。ソースを準備し、制作上の文脈を上流に保ちます。
Scribe で引き渡しを確認する
Scribe で Project を開いたら、フォントを選び、章扉を調整する前に立ち止まります。認識された作品と Publish Version、Source folder（ソースフォルダー）、章数と順序、原稿バージョンを確認してください。予想外のものが認識されたなら、誤った原稿に合わせてデザインせず、ソースの判断へ戻ります。
この確認が済んで初めて、注意は Story の構造から本の構造へ移ります。Scribe では問いが変わります。章をどう始めるか。ページのリズムは文章を支えるか。目次は意図した階層を示すか。今回の版には、対応しているどの出版出力が必要か。
このタイミングなら、Appearance とページネーションはより安定した土台に置かれます。Scribe が本制作を担うあいだ、上流の Story data、調査、タスク、バージョンの文脈は Scroll に残ります。
校正で一語の欠落を見つけた場合も、正本をどこで修正するかを決め、必要な確認を繰り返すのは書き手です。この流れは責任を取り除きません。複数のファイルがすべて最終版を名乗るときの曖昧さを減らします。
ミステリー小説が境界を越える
3つの時系列が絡むミステリーを書き終えようとしている人を想像してください。最初の3か月、切実な問いは証言、人物の認識、構造改稿に残るタスクです。Scroll の Story data、Timeline、関係、タスクは、それらの問いを本文につないでおきます。この段階で章タイトルのフォントを選んでも役には立ちません。
編集改稿後、編集者確認済み原稿を文脈として残し、著者修正版を今回の Publish Version に選びます。Delivery Center で、Resolved source と Delivery readiness が意図する本に合っているかを確認します。
Scribe では、認識された作品と Publish Version、Source folder、章数と順序、原稿バージョンを確認します。その後で Appearance、章扉、ページネーション、出力へ進みます。遅い段階の校正修正があっても、どのソースが正本で、どの確認をやり直すべきかが分かります。
これが、滑らかなワークフローの現実的な意味です。引き渡しが存在しないのではなく、書き手が本を再構築しなくても済む引き渡しです。
一連の流れが向いている人
Story をまだ探っている、または大きな構造改稿をしている書き手は Scroll だけでも作業できます。すでに安定した原稿があり、主にページデザインと出版出力が必要な人は Scribe から始められます。
両方を通る流れは、長編の深い構想を大切にしながら、自分で電子書籍や印刷版を作る人に向いています。二つのアプリケーションは別々にも使え、Writing Suite は両方の段階が必要な人の選択肢です。
現在の原稿が境界に達したかを考えるには、原稿が Scribe に進める5つのサインへ進んでください。分業全体を見直すなら、Scroll と Scribe のワークフローハブへ戻れます。現在の正確な引き渡し手順は、公開連携ガイドで扱います。
大切なのは、すべての書き手に二つのアプリケーションが必要かどうかではありません。明確に選んだソースがページ作業へ進めるまで、創作を柔軟なまま保つことが、その本に役立つかどうかです。