初稿の次にすること：長編小説の構造改稿ワークフロー
原稿全体に及ぶ感想を一つの構造的な問いへ絞り、必要なビューで点検し、終わりの見える複数章の作業へ変えます。
10万語の初稿を書き終えた翌日、小説家が3人の読者から届いた感想を開きます。第2幕が長すぎる。三つの視点で動機の強さが揃っていない。失踪の日付が別の章と矛盾しているかもしれない。第19章こそ本当の始まりに感じる。投稿締切は1か月後です。一つひとつはもっともらしい指摘ですが、まとめて見ると「本全体を変えなければならない」と言われているように感じます。
構造改稿で最も難しいのは、問題を終わりのある作業へ変えることです。1ページ目から文章を磨いても、第2幕は短くなりません。ペース、人物の成長、世界観、言葉を同時に直せば、一つの判断が次の変更で上書きされます。
安全な出発点は一文です。今回の改稿では、どの構造的な問いに答えるのか。
最初の一文を直す前に、軸を一つ選ぶ
「第2幕が長すぎる」だけでは、まだ広すぎます。主人公の目標が現れるのが遅いのか、複数の捜査場面が重複しているのか、一人の視点人物が動かないのか、クライマックス前に説明章が積み重なっているのかもしれません。観察できる問いまで絞ります。「第9章から第18章の各章で、捜査の方向は変わっているか」。
一つの軸を選んでも、ほかの感想を無視することにはなりません。語り口、日付の矛盾、調査不足は、後のタスクへ分けます。相反する感想を多数決にする必要もありません。「遅すぎる」「変化が急すぎる」「文脈が足りない」を、問いへ翻訳します。新しい行動を生まない章はどれか。変化の前にどんな選択があったか。読者は必要な文脈をどこで得るか。
感想は症状を述べます。診断する問いを選ぶのは作家です。
Story ビューはレンズであり、診断ではない
Scroll は、記録した Story data を章順以外からも表示できます。Spreadsheet では出来事の目標、参加者、状態を比べられます。Timeline は日付と順序を確認します。Subway は、複数人物の物語線に記録された参加が近づき、交差する様子を点検できます。Relationship graph は明示的な関係を中心に表示し、ビュー設定によって共有イベントなどから派生する読み取り専用のつながりも重ねられます。本文を読んで関係を推理したり、正式な関係を自動作成したりはしません。Whiteboard は仮の因果関係の並べ替えを受け止めます。
どのビューも、第2幕が長すぎると宣言したり、筋書きの穴を検出したりはしません。先に問いを立て、そのあとでビューを選びます。捜査の進展を見るなら、関係する各出来事が加える新しい行動を記録し、重複する型を探します。作中時間の出来事から一人の視点が消えていないかを見るなら Subway が役立つかもしれません。視点章の間隔を見るなら、原稿ツリーと章順へ戻ります。
第11章、第13章、第15章がどれも資料庫の捜索を繰り返し、選択を変えていないと気づくかもしれません。この結論は編集上の判断です。ビューは、離れた章を同じ問いの下へ集める助けになります。
診断を、範囲の明確な複数章タスクへ変える
「第2幕を直す」には、目に見える終点がありません。「第11章と第13章の資料発見を一つにする」「第14章で第2の視点人物に取り消せない選択をさせる」「第9章から第18章で捜査の方向転換を確認する」なら、完了条件があります。
タスクを関係する章や Story カードへつなぎ、プロジェクトタスクボード、プロジェクトタスクリスト、プロジェクトタスクカレンダー、プロジェクトタスクスケジュールから確認します。タスク Notes には、変更する理由、完了条件、今回触れない箇所を残します。3日後に戻っても、すべての感想を読み直さず、編集意図を取り戻せます。
進行中のタスクは二つか三つに絞ります。新たに五つの章を開く前に、いまの章を閉じます。タスクを完了にしても、文書が保存済みで、問いに答えられたとは限りません。Project を閉じる前に本文と未保存状態を確認してください。この作業量の制限は Scroll が課す規則ではなく、著者自身の方法です。
Story の出来事と著者の作業を分ける方法は、小説執筆を進めるプロジェクトタスクボードのワークフローで詳しく紹介しています。
編集上の判断を、本文に混ぜず本文のそばへ置く
構造改稿では、本に入らない文章が生まれます。読者の感想、場面を削る理由、調査上の問い、人物の成長に関する仮説です。Notes はそうした判断を保持できます。Related Files や構造化された関係で、タスクを章、人物、出来事へつなげられます。通常の原稿リンクは別の Project ファイルへ移動するために使えます。
どの形式も同じ章を指せますが、意味は同じではありません。「この場面はもっと前に必要」という考えは、判断が固まるまで Notes に置けます。そのあとで実際の原稿を変更します。
集中して作業する日は、まず保存し、現在のタスクに必要な章だけを開きます。Black House、Mask、Typewriter は集中を支えますが、編集判断を代行しません。エディター外観が本の Appearance になることもありません。この境界は、持続できる没入型の執筆空間で説明しています。
原稿を組み替える前にファイル操作を理解する
構造上の判断によっては、ファイルそのものを変える必要があります。Scroll には カーソル位置で分割、選択項目を連結、選択項目を追加、選択項目を結合があり、効果はそれぞれ異なります。分割はカーソルより後の内容から新しいファイルを作り、連結は参照元ファイルを分けたまま順序付きのグループを作ります。追加は選択した内容を移動先の末尾へ加えて参照元を残し、結合は内容を移動先へ統合してほかの参照元を Trash（ゴミ箱）へ移します。公開されている動作は、最新の長編執筆・改稿ドキュメントで確認してください。原稿を保存し、Project 全体をバックアップし、結果が不確かな操作は複製で試します。
三視点の小説なら、まず 選択項目を連結で三つの章を連続して読み、前へ移すべき視点を カーソル位置で分割できます。新しい順序が機能したあと、重複部分を 選択項目を結合でまとめるか、参照元を残す 選択項目を追加を使うかを決めます。各操作は一つの編集上の問いに仕え、章順、接続部分、リンクを確認して終えます。
改稿に終点を作る
第9章から第18章を、選んだ問いに沿って再確認します。古い仮置きを検索し、関連タスクを見直します。完了した作業を整理し、今回触れなかった感想を次の改稿へ持ち越します。
分割、結合、移動のあとは接続部分を点検します。代名詞、時間を示す言葉、人物の登場、見出し階層、リンクが古い構造のままかもしれません。変更箇所の前後一章を読み、削除した場面の語句を検索します。外部編集者がファイルへ手を入れた場合は、競合する保存内容を解決してから続けます。
今回の改稿について、短い記録を残します。問い、採用した変更、後回しにした感想、次の改稿の入口、バックアップの場所です。将来の自分が判断の理由を理解でき、今回の作業が実際に終わったことも確認できます。
小説には、まだ文章推敲、事実確認、校正、バージョン確認が必要かもしれません。それでも、複数の修正を同時に抱えるのではなく、説明できる構造上の結果を一つ得られました。次は一つの Story に11のビューが必要になる理由を読むか、原稿バージョンと Project 全体のバックアップで次の境界を整えられます。
Scroll は、Story data、タスク、本文が変化していく文脈を支えます。判断を下すのは作家です。原稿が安定したら、Scribe が Appearance、ページネーション、出版出力を担います。Scroll 長編執筆ワークフローへ戻るか、Scroll 製品ページをご覧ください。