DramaFork プレイアブルプレビューの問題をどう分類するか：ストーリー、インタラクション、素材はそれぞれどのステップに戻って直す？

プレイアブルプレビューで問題が出たら、まずノードを直そうとしない。一行の症状記録で「誰がどのタイミングで何を見たか」をはっきり書き、それがストーリー、インタラクション、素材のどれに属するか判断する。ストーリー系は企画または脚本に戻り、インタラクション系はインタラクションノードに戻り、素材系は絵コンテ、スタイル、キャラクター素材または動画に戻る。直した後は影響を受けた下流ステップだけを再確認し、プレビューが通ったことをリリーステスト合格とみなさない。

以下では架空の教学例で一貫して説明する：インタラクティブ映像ゲーム『霧港夜班』、主人公は夜勤の灯台守・林澈、目標は夜明けまで持ちこたえ失踪した船員の行方を突き止めること、秘密は彼がかつて同じ海域で船を捨てて逃げたこと、初期関係では配車係の沈嵐と互いに信頼していない。以下の人物、数字、台詞はすべて架空であり、いかなる実在プロジェクトにも対応しない。

症状記録には四項目を含めることを勧める：出現タイミング、プレイヤーが見た内容、期待内容、再現できる最短経路。タイミングは具体的なノードまで書く。例えば「ノード N-07 に入った後、最初に選択肢が表示されたとき」。 「真ん中のあの辺がなんか変」と書いてはならない。それでは特定できない。

『霧港夜班』の三件の記録はこう記入できる：

分類の根拠は「文字が間違いか、画面が間違いか、それとも出来事の順序が間違いか」。S1 の選択肢文字はノードが担うのでインタラクションに帰属；S2 の画面は動画素材から来るので素材に帰属；S3 は出来事の欠落なのでストーリーに帰属。

S1 の根源はノードの文案にある。ノードは表で組織され、一行が一つの出現位置に対応し、ドラッグ図ではない。修正時はまずそのノードにマウントされた動画と条件が動いていないことを確認し、選択肢テキストだけを変える。

元の選択肢：

• なぜ灯台に来たのか聞く
• 今夜の潮位を聞く
• 何も聞かない

次のように変える：

• なぜ灯台に来たのか聞く
• 今夜の潮位を聞き、ついでに「白鷗号」を知っているか探りを入れる
• 何も聞かず、振り返ってロープを点検する

二つ目の選択肢は林澈の秘密を探れる方向に変え、三つ目の選択肢は回避の姿勢を示す。直した後は N-03 以降のプレビュー断片だけを再確認し、三つの選択肢がそれぞれの後続に入れるかを確認し、線全体は再確認しない。

S2 の表情と台詞の衝突は、まず入力がこの表情を要求していたかを判断する。絵コンテはカメラ内の動作と感情意図を決め、スタイルは映像の質感を制約し、キャラクター素材は人物参考を提供し、動画こそが実際の生成結果である。本例の絵コンテはすでに「厳粛な問い詰め」と明記し、参考にも笑顔の要求はないが、生成断片はまだ笑っている。まずこの動画タスクから調べ始めてよく、画面だけからモデル内部がどのフレームを選んだかを推測してはならない。

処理方法は、対応する絵コンテと参考を照合し、必要なら動作記述を明確にし、この動画タスクだけを再試行すること。人物参考自体が不適切な表情を伴っているなら、キャラクター素材ステップに戻って修正し、その参考を使う他の断片も確認する。再試行後も実際の出力を見る必要がある；ここでの調査にはタイムラインやフレーム単位の表情置換機能は含まれない。

S3 は船を調べる過程が欠けており、出来事構造に属する。まず脚本に戻り、N-05 と N-06 の間に捜索の一場面を補う：林澈が貨物舱を点検し、切断されたロープを見つけ、上層の足音を聞く。補った後、企画の「失踪した船員の行方を突き止める」目標に初めて対応する段落ができる。

脚本を変えると下流の絵コンテ、スタイル、キャラクター、ノード、動画、プレビュー、エクスポートに影響する。実際の操作では、関連し既に完了したステップだけを要更新と標記し、旧データは保持する。意味的に正確な自動差分も、ワンクリック確認の再利用もないので、手作業で照合する必要がある：新たに補った捜索段落が古い絵コンテと動画の表現を依然として成立させるか。

三つの症状をそれぞれ直した後、再確認範囲は変更層で決まる：

1. ノード文案だけを変えた：そのノードとその直接後続のプレビュー断片を再確認する。
2. 動画素材だけを変えた：その動画をマウントしたノードの再生効果を再確認する。
3. 脚本に段落を新規追加した：新規段落に対応する絵コンテ、動画、ノード、および前後ノードとの接続を再確認する。
4. キャラクター素材を変えた：そのキャラクターを使うすべての動画とプレビュー断片を再確認する。

再確認時は同じ症状記録に結果を記入する。例えば S1 は「修正済み、三つの選択肢の語気が区別可能」、S2 は「対応動画を再試行済み、実際の表情と問い詰めが一致」、S3 は「捜索段を補完済み、N-05 から N-06 の接続が完全」と記す。これらも依然として架空の記入例であり、実際のプロジェクトは観察結果に従って記録すべきである。

• 各症状に出現タイミング、見た内容、期待内容、最短再現経路がある。
• 分類結論が具体的なステップを指し、「全体をもう一度調整」と書かない。
• ノードを変えるときはノードだけを動かし、動画を変えるときは動画だけを動かし、無関係なステップに波及していない。
• 上流変更後、関連する完了済みステップだけを要更新と標記し、旧データは保持する。
• 再確認範囲は変更層に対応し、線全体の再実行を唯一の手段としていない。
• プレビューが連続再生できても、リリーステスト合格とは等しくない；エクスポート後も素材パッケージの説明に従って確認する必要がある。

本文はDramaForkが整理し、現在のプロジェクト実装に基づいて説明する。プレイアブルプレビューはノードと素材の接続を確認するために使い、エクスポート後のプレイアビリティ検証を代替しない。ZIP の成功はプレイアビリティ検証と等しくなく、localhost は他人のコンピュータではその人のローカルを指し、汎用アクセス可能なドメイン名としては使えない。

次のステップ：最近遭遇したプレビュー症状を一つ選び、上の表に一行記入し、出現タイミングと最短再現経路を書き、それがストーリー、インタラクション、素材のどれに戻るか決める。