シナリオ用テキストエディタの連動スクロールを評価するなら、隣り合う二場面を眺めるだけでは足りません。離れた場面を四つの観測行に置き、地点間の三回の移動ごとに連動先の固有内容を記録する試験を先に設計します。たとえば開始点をSC03とし、SC27、SC11を経てSC03へ戻る順序へ、「青い封筒」「壊れた時計」「非常階段」という確認語を割り当てます。
この試験票を改稿ごとに同じ順序で再利用すると、台詞の加筆で行位置が動くたびに、シナリオと対応資料の場面をゼロから探して並べ直す作業を減らせます。ここでいう「並べ直し」は、ウィンドウ配置や保存レイアウトの復元ではありません。改稿後もSC03、SC27、SC11の同一性をIDと確認語で確かめ、同じ対応関係を作り直す手間を減らすことです。
この記事の主題は、原稿・人物表・時系列表を三画面へ固定することではありません。初稿と改稿の変更を分類する記事でもありません。シナリオの非連続な場面を使い、連動スクロールが正しい内容へ追従したかを判定できる試験票の作り方に絞ります。
場面番号が近い試験だけでは誤追従を見抜けない
長いシナリオでは、場面見出しが似ます。「室内・夜」が何度も登場し、登場人物名も複数の場面で繰り返されます。さらに、一つの場面へ台詞を追加すると、その後ろの行位置がずれます。
この状態でSC03からSC04へ移動して追従したように見えても、連動先が単に近い縦位置へ動いただけかもしれません。場面名だけを見ても、別の「室内・夜」を開いた可能性を排除できません。
そこで、観測する場面を意図的に離します。序盤、終盤、中盤、序盤という順番なら、連続したスクロール量に頼った見かけ上の成功を避けられます。判定に使うのはピクセル位置や行番号ではなく、その場面にしかない内容です。
改稿ごとに同じ試験票を再利用する
最初の改稿で、三つの場面ID、確認語、移動順、期待内容を試験票へ固定します。次の改稿で台詞やト書きを加えて行位置が変わっても、新しい場面順を考え直しません。同じSC03 → SC27 → SC11 → SC03をたどり、同じ四行へ実際に見えたIDと確認語を書きます。
四行がすべて一致すれば、その改稿では対応関係をゼロから作り直す必要がありません。不一致が出た場合も、新しいレイアウト全体を設計するのではなく、該当行の場面ID、確認語、場面境界のどれが変わったかを調べます。場面自体を改名した、または確認語を削除した場合だけ、その行の期待内容と変更理由を更新します。
ここで管理する「改稿」は、版ファイルの保存や文章差分の分類ではありません。改稿を重ねても場面の同一性を同じ試験票で追い、対応場面を毎回探し直す範囲を不一致行へ絞る運用です。所要時間の短縮を実測した結果ではなく、再利用する項目と更新する条件を定めた一般的な方法です。
三つの場面アンカーへ固有の確認語を用意する
一般的な検証方法として、複製した短いシナリオと対応資料を用意し、三つの場面に次の情報を置きます。
SC03-PORT：確認語「青い封筒」SC27-TOWER：確認語「壊れた時計」SC11-STAIRS：確認語「非常階段」
IDは重複させません。確認語も、その検証用入力の別場面に出ない言葉を選びます。場面見出し、ID、確認語の三つが揃えば、連動先が本当に対象場面かを内容で確認できます。
記録には、観測点、期待する連動先のID、期待する確認語、実際に見えた先頭見出し、実際に見えた確認語を残します。「動いた」「だいたい同じ位置だった」では判定しません。
四つの観測行と三回の移動を分ける
試験票の順序をSC03 → SC27 → SC11 → SC03とします。ここに並ぶのは四つの観測点です。地点間の移動は、SC03からSC27、SC27からSC11、SC11からSC03の三回です。
一行目は開始状態の観測です。連動先の先頭見出しがSC03-PORTか、画面内に「青い封筒」があるかを記録します。第一の移動後はSC27-TOWERと「壊れた時計」、第二の移動後はSC11-STAIRSと「非常階段」、第三の移動後は再びSC03-PORTと「青い封筒」を観測します。
これは製品固有の「アンカー選択ジャンプ」を確認済み操作として示す順序ではありません。四行の期待値と実測値を比較するための一般的な試験設計です。実行時は、対象エディタで確認できる移動方法を使い、開始操作と三回の移動を別々に記録します。
追従の合否は内容の組み合わせで決める
正しい追従は、IDと確認語の両方が期待値と一致する状態です。SC27の観測行でSC27-TOWERと「壊れた時計」が見えれば、その行は一致として記録できます。
次の状態は分けて残します。
- IDはSC27だが確認語が「非常階段」：内容が別場面と混ざっている
- 確認語は「壊れた時計」だがIDがSC26：場面境界の位置を再確認する必要がある
- 連動先が動いたがIDも確認語も見えない：追従したとは判定できない
- SC03への戻りだけ一致しない：往路と復路で結果が異なる
大切なのは、誤追従を「少しずれた」で済ませないことです。どの観測点で何が期待され、実際には何が見えたかを残せば、場面IDの重複、確認語の不足、連動処理のどこを調べるべきかが分かります。
場面資料を増やす前に一往復を固定する
人物表、ロケーション表、小道具表まで同時に開くと、どの資料が誤追従したのか分かりにくくなります。最初の試験は、主となるシナリオと一つの対応資料に絞ります。
一往復で四行の記録が揃ってから、別の資料を追加します。資料を追加した場合も、同じ移動順と同じ期待値を使います。入力を変えながら機能を比較すると、追従結果の違いが資料の違いなのか操作の違いなのかを判断できないためです。
この方法は、資料の正本を決める方法ではありません。誰がどのファイルを編集するかも判定しません。あくまで、四つの観測点で連動先の内容が期待した場面と一致したかを確かめる試験です。
Rune Studioで確認済みの範囲と、まだ断定しない範囲
Rune Studioの全機能資料には、二つ以上の参加ペインで同じ順番の目印同士を対応させ、目印間を位置比率で合わせる連動スクロールが記載されています。これは、長さの違うシナリオと対応資料を、共通の場面区切りに沿って読む用途に関係します。この根拠は資料記載を照合したStage 1であり、実画面で参加ペインや目印設定を確認したStage 3の証拠ではありません。
ただし、資料は「場面アンカーを選択すると特定場面へジャンプする」という操作を示していません。また、この記事のSC03 → SC27 → SC11 → SC03を開始から結果まで実行した記録もありません。したがって、この四行はRune Studioで成功確認済みの手順ではなく、文書化された相対的な目印連動へ適用する前の試験設計です。
Rune Studioで実行する場合は、現行画面で連動へ参加するペインと目印の設定方法を確認し、実際に使えるスクロール操作で各観測点へ進みます。開始状態、三回の移動、四行の結果を残して初めて、その入力での合否を判断できます。本記事はその結果を先回りしません。
目印連動スクロールは、自動差分比較、版の統合、脚本内容の正誤判定ではありません。二つの場面が物語上対応するか、人物設定が正しいかを自動で決める機能とも分けます。
三画面比較や改稿監査は別の仕事
STUDIO-005は、一つの現在原稿を人物表と時系列表へ照合し、三つの役割を固定する記事です。STUDIO-012は、初稿と改稿の変更を変更IDと「削除・追加・意味変更」で監査します。
本記事はどちらも代替しません。三つの資料を一般的に並べる方法、変更理由を記録する方法、レイアウトを再起動後に戻す方法は扱わず、非連続な四つの観測点で得た追従内容だけを判定します。
結論：四つの観測行と三回の移動を記録する
シナリオで連動スクロールを評価するなら、最初に一意の場面IDと固有の確認語を三組作ってください。そしてSC03 → SC27 → SC11 → SC03を、開始点を含む四つの観測行と、地点間の三回の移動に分けます。各行へ期待したIDと確認語、実際に見えたIDと確認語を残します。
四行が一致すれば、少なくともその入力では「画面が動いた」ではなく「正しい場面内容へ追従した」と説明できます。不一致があれば、どの移動で何が違ったかを示せます。これが、一般的な三画面比較とは違う、シナリオ固有の連動スクロール検証です。
この運用で減らすのは、画面レイアウトの復元ではなく、改稿のたびに対応場面をゼロから探して並べ直す作業です。四行の順序と期待内容を次の改稿でも再利用すれば、一致した行はそのまま残し、不一致の行だけを再確認できます。これが、場面見出しで改稿を管理しながら毎回の並べ直しを減らす、この記事固有の結論です。
目印連動スクロールを候補にする場合は、Rune Studioの製品ページで現行の目印対応と参加ペインの範囲を確認し、この四行・三移動の試験票を複製原稿で実行してください。
