2人のクリエイターが交代でレビューするとき、「ここが違う」を実行可能な修正票にどう書くか？

「ここが違う」を修正票に変える核心的な動作はただ一つ：すべての意見をバージョン、ノード、現象、期待、理由、責任、確認の7枠に落とし込むことです。2人が交代でレビューするときは、まず各自が独立して票を記入し、次に衝突項目を統合し、最後に初めて原稿に手を入れます。以下では架空の教学例で全行程をたどります。人物、台詞、数値はすべて実測資料ではありません。

修正票は文学評論ではなく、引き継ぎ可能な作業票です。7列を固定し、1列でも欠けたら改稿キューに入れないことを推奨します：

「ノード」とはインタラクティブ映像作品における単独で位置特定できるインタラクション単位を指し、通常は表で構成され、ドラッグ式キャンバスではありません。ノード番号を明記してこそ、2人が同じ箇所を指せます。

架空プロジェクト『霧港来信』、ブランチ mist-dev を設定します。第三幕ノード N-07、プレイヤーが演じる見習い配達人は、返送された手紙を老船医に返さなければなりません。現在のテキスト原文は：

老船医は手紙を受け取り、笑った：「机に置いてくれ、後で見る。」

レビュアー甲（キャラクター線担当）の記入：

• バージョン：mist-dev 10-04
• ノード：N-07
• 現象：「笑った」が老船医の「弟子を失ってから人前で手紙を開けなくなった」という既存設定と衝突
• 期待：彼が手紙を押し戻し、「これは君が届けるべきものではない」と言うよう変更
• 理由：彼の目標は過去を回避することであり、受け取るより押し戻す方が回避に合う
• 責任：甲がテキストを修正
• 確認：乙が一度読み、新たな過去の話が追加されていないことを確認

レビュアー乙（インタラクションリズム担当）の記入：

• バージョン：mist-dev 10-04
• ノード：N-07
• 現象：プレイヤーは長距離護送を終えたばかりで、ここでの「机に置いてくれ」の一言が選択の重みを失わせる
• 期待：手紙を受け取る動作は残すが、プレイヤーに先に「来意を説明する」か「黙って手紙を渡す」を選ばせる
• 理由：2つの選択肢は異なる関係状態に対応し、プレイヤーは自分の選択が受け止められたと感じられる
• 責任：乙がノード選択肢を修正
• 確認：甲が2つの選択肢ともキャラクターの境界に反しないことを確認

2つの票はどちらも規定に適合していますが、「受け取るか押し戻すか」で直接矛盾しています。このとき、それぞれ半分ずつ直してはいけません。

矛盾する意見の処理は順番に進め、ステップを飛ばしません：

1. バージョンを揃える。2人が同じ mist-dev 10-04 を見ていることを確認する。一方が古い保存版を見ている場合、その票を先に無効にする。
2. 事実と好みを分離する。「押し戻す」が関連するのは明記済みのキャラクター設定であり、事実層に属する。「選択の重みが失われる」は体験層に属する。両層が成立する場合、事実層が優先的に制約し、体験層はその内部で実現する。
3. 最小の共通変更を探す。統合結果は：押し戻す動作を残し、「来意を説明する／黙って手紙を渡す」を押し戻す前の2つの選択肢とする。これでキャラクターは壊れず、リズムも補える。
4. 唯一の責任者を指定する。テキストは甲が直し、ノード選択肢は乙が直し、2人とも相手の列を越えて直さない。
5. 確認方法を書く。確認は「もう一回見る」ではなく、具体的な動作：甲がN-07全文を朗読し、提供されていない過去の話が一句ずつ出てこないか照合する；乙が2つの選択肢を一通り歩き、どちらも次のノードに入れることを確認する。

2ステップ後もなお衝突する場合、両方の意見を保留にし、「保留」と標記して改稿に入れない。保留は強引な統合より安全です。強引な統合はしばしばキャラクターをどっちつかずに変えてしまうからです。

「理由」列に書くのは関連であり、判決ではないことに注意。それは第三者が変更の越界を判断できるようにし、レビュアーを保証するものではありません。

N-07のテキストと選択肢の変更は、ノードの変更に属します。現在のプロジェクト実装では、関連する完了済みプレビューとエクスポートは「要更新」と標記され、旧データは保持されます。クリエイターは旧プレビューのテキストがまだ成立するか、新エクスポートが改訂内容を含むかを照合すべきです。今回の意見が動画内の動作も変えた場合、対応する断片を別途列挙すべきで、「ノードは変更済み」の一言に隠してはいけません。

エクスポートは2種類：ローカル素材パッケージ localAssets は素材、プレイヤー、説明ファイルを含み、説明に従って実行しオフラインで確認する；リモートリンクパッケージ remoteUrls はアプリドメイン下の安定した入口からアクセスし、ネットワークとサービスに依存し、永久リソースの保証ではありません。localhost は他人のパソコンではその人自身のマシンを指し、汎用アドレスとしてチームメイトに送れません。圧縮パッケージが解けることは、プレイアビリティが検証済みであることを意味しません。

修正票が改稿に入れるのは、7列が揃い、かつ次を満たす場合に限ります：

• 現象列が原文または具体的ノードを引用できる；
• 期待列が第三者の独立判断で達成可否を判断できる；
• 理由列がキャラクター設定または前後文を指し、個人の好みではない；
• 責任列に改動者が1人だけ；
• 確認列が動作であり、態度ではない。

2人が交代でレビューするときは、各ラウンドで同一ノードの衝突だけを処理し、処理が終わってから次のノードを開くことを推奨します。本文はDramaForkが整理し、現在のプロジェクト実装に基づいて説明します。ドキュメント協作にはリアルタイム多人数同時編集の約束はなく、2人は上記の順序で引き継げばよいです。

次回レビュー前に、まず各自が7列を埋め、それから顔を合わせて衝突した1枠だけを話し合いましょう。