Macのテキストエディターで初稿と改稿を三画面比較するなら、画面を同じ位置へ揃えることより、変更を一件ずつ説明できる証跡を残すことが大切です。左に初稿、中央に改稿、右に変更記録を置き、変更ごとにIDを振ります。そのIDへ変更前の引用、変更後の引用、「削除・追加・意味変更」の分類、変更理由、確認結果を結び付ければ、行数がずれても「何をどう変えたか」を追えます。
この記事は、現在の原稿を人物表や時系列表と照合する方法ではありません。また、三画面の配置を終了後に復元できるかも合否にしません。対象はあくまで、初稿から改稿へ移した一件の変更を監査できるかです。
三画面比較の単位は「行」ではなく変更ID
初稿へ一文を加えると、その後ろの行番号はすべてずれます。段落を二つに分けたり、台詞の順番を入れ替えたりした場合は、左右の同じ行を眺めても対応関係が分かりません。三画面を開いただけでは、この問題は解決しないのです。
そこで、比較の単位を画面位置から変更IDへ移します。たとえば第八場面の十四番目の検討項目なら、M14のような短いIDを付けます。左画面で変更前、中央画面で変更後を読み、右画面の記録でM14を探します。これなら、前後に別の加筆が入ってもM14の説明は動きません。
変更IDは場面を探すためだけの目印ではありません。その変更について、編集者が何を判断したかを束ねるキーです。三画面の中心は「同じ場所へ戻ること」ではなく、「一件の判断を初稿・改稿・記録の三方向から確認すること」にあります。
変更記録には六つの事実を残す
一般的な方法は、表計算やメモでも実行できます。変更一件につき、次の六項目を一行へまとめます。
- 変更ID
- 対象となる章・場面・段落
- 初稿から必要最小限に抜き出した変更前の文
- 改稿から抜き出した変更後の文
- 削除・追加・意味変更の分類
- 変更理由と、後から確認する人の結果
ファイル名や行番号だけではなく、短い引用を両方残すのが要点です。引用があれば、改稿後に行が動いても検索できます。理由欄には「読みやすくした」のような感想ではなく、「主語を明示した」「伏線をこの場面では隠した」「発言者の意図を拒絶から保留へ変えた」のように、何が変わったかを書きます。
この記録を作る時点では、初稿を編集しません。左は変更前の根拠、中央は編集対象、右は判断の根拠です。初稿を保存し直してしまうと、変更前引用が正しいかを確認できなくなるためです。
「削除」と「追加」だけでは意味変更を見落とす
文章の差は、文字列だけを見れば削除と追加へ分解できます。しかし編集の判断としては、それだけでは足りません。
「彼は行くと言った」を「彼は、まだ決めていないと答えた」へ変えた場合、文字は削除され、新しい文字が追加されています。ただし重要なのは、人物の意思が決定から保留へ変わった点です。この変更を単なる削除一件、追加一件として記録すると、物語上の影響が記録から消えます。
分類は次のように使い分けます。
- 削除：情報や表現を取り除き、代わりの内容を置いていない
- 追加：既存の意味を保ったまま、情報や描写を加えた
- 意味変更：人物の意図、事実関係、時間、因果、視点などが変わった
一つの変更が複数に当てはまる場合は、物語への影響が最も大きい分類を主分類にし、補助欄へ削除・追加を併記します。分類の目的は件数をきれいに揃えることではなく、後の読み直しで影響範囲を見逃さないことです。
M14を三画面で監査する
説明例として、場面SC08の台詞を変更IDM14で記録します。
左の初稿には「私は港へ行く」とあります。中央の改稿では「港へ行くかは、夜明けまで決めない」へ変えました。右の変更記録には、対象=SC08、変更ID=M14、主分類=意味変更、理由=行動の確定を保留へ変更し、次場面の選択を残すと書きます。
監査では、まず左右の引用が実際の本文と一致するかを見ます。次に、「保留へ変わった」という理由が改稿文から読み取れるかを確認します。最後に、後続場面が「港へ行くことが決定済み」という前提で書かれていないかを別途点検します。
この例の合否は、三画面が同時に見えたかでは決まりません。M14の変更前、変更後、分類、理由を別の人が読み、同じ変更内容を説明できれば監査可能です。逆に、画面がきれいに並んでいても理由が「修正した」だけなら、証跡としては不足します。
Rune Studioは変更判断を自動化せず、監査机として使う
Rune Studioの機能資料には、1〜3列・1〜3行の分割とペイン間のタブ移動が記載されています。これは文書記載の確認であり、現行版の実画面や操作完遂を確認した証拠ではありません。この記事では、その文書化された範囲を三つの根拠を同時に読む監査机の候補として扱います。
たとえば左に初稿、中央に改稿、右に変更記録を置けば、M14の前後文と理由を同時に読む構成を試せます。ただし、三タブを開いてh3へ配置する一連の操作は、本記事の証跡では開始から結果まで追試できていません。現行版で同じ配置ができるかは、自分の複製原稿で確かめる必要があります。
一方、Rune Studioが文章差分を自動検出する、削除・追加・意味変更を自動分類する、初稿と改稿を自動マージするとは書けません。M14の分類と理由は編集者が作る記録です。機能資料に記載された候補範囲と、未確認の実画面、配置操作、全章の変更監査を分けます。
この方法が向く作業と、扱わない作業
この方法が向くのは、改稿の理由を後で説明したい作業です。共同で校閲するとき、編集者からの指摘へ対応するとき、長編の伏線や人物の意思を変えたときに、変更IDが役立ちます。文字列の違いだけでなく、作品上の意味まで残したい人に向いています。
現在の原稿を人物表と時系列表へ照合したい場合は、STUDIO-005が担当する別の仕事です。非連続な場面アンカー間で連動スクロールが正しい内容へ追従するかを試したい場合は、STUDIO-329の範囲です。本記事は一般資料の参照、レイアウトの再起動復帰、自動差分、自動マージを代替しません。
結論：まず一件の変更を説明できる形にする
初稿と改稿の三画面比較で最初に行うのは、全章を並べることではありません。一場面から一件を選び、変更ID、変更前、変更後、分類、理由、確認結果を埋めます。
別の人がその一行と二つの本文を読み、「何がどう変わり、物語上どんな意味があるか」を説明できれば、比較は監査へ変わります。Macのテキストエディターは、その三つの根拠を同時に読むために使います。まずM14のような一件を完成させ、それから同じ記録方法を章全体へ広げてください。
三タブの監査机を候補にする場合は、Rune Studioの製品ページで現行の画面分割範囲を確認し、自分の一場面の複製で同じ記録を試してください。
