書き出し前に納品目標を書く：受け取り手のデバイス、ネットワーク、検証ルートを1ページで説明する

書き出し前に1ページの納品説明を書き、受け取りデバイス、ネットワーク条件、実行方法、目標ルート、受け入れ基準を明確にしてから、ローカル素材パッケージかリモートリンクパッケージかを決めます。順序は逆にできません。まず受け取り側がどう開き、どう成功と判断するかを定め、それから納品形態を選びます。以下では架空の教学例で全体の流れをたどります。プロジェクト名は『潮汐郵便局』、受け取り側は協力先「岸線スタジオ」の2名のレビュアーです。

受け取りデバイス：相手がどのマシンで開くか。OSの大分類、画面サイズの規模、再生に影響する独立GPUの有無といったレベルまで書き、具体的な型番までは不要です。

ネットワーク条件：相手がどのネットワーク下で検証するか。常時接続、初回のみ接続、完全オフラインのいずれかです。

実行方法：相手がものを受け取った後に何をするか。解凍後に起動ファイルをダブルクリックするのか、ブラウザでアドレスを開くのか。

目標ルート：相手が今回たどるストーリーパス。インタラクティブ映像作品には分岐がよくあり、明確に書かないと、相手が途中で内容欠落と誤解する可能性があります。

受け入れ基準：相手が何をもって「OK」と言えるか。これをチェック可能な項目として書き、「正常に見える」ではいけません。

これら5項目を先に紙に落としてから、納品形態を決めます。ローカル素材パッケージは、完全な素材を保存しオフラインで検証する必要がある場面に適しています。リモートリンクパッケージは、相手にすべての動画を含まないプレイヤーパッケージを先にダウンロードしてもらい、その後ネット接続で素材を読み込むことができます。どちらもパッケージ内の説明に従って開く必要があり、選択の根拠はデバイス、ネットワーク、保持条件です。

以下は架空の教学例であり、デバイス、ネットワーク、パスはすべて創作で、実在の協力先や実測結果に対応しません。

『潮汐郵便局』試遊納品説明（岸線スタジオレビュー用）

受け取りデバイス：WindowsノートPC 2台、画面14～16インチ、統合GPU。外部モニターは不要。

ネットワーク条件：レビュー機Aは常時接続可能。レビュー機Bはファイルコピー時のみ接続し、検証時は切断。

実行方法：2台のマシンはそれぞれ受け取ったパッケージを解凍し、パッケージ内の説明に従ってプレイヤーを起動。レビュー機Aはリモートリンクパッケージを使い、再生中は接続を維持。レビュー機Bはローカル素材パッケージを使い、起動後に切断して検証。

目標ルート：オープニングから郵便局に入り、「手紙を残す」を選択し、第2章「引き潮の受取人」の終わりまで進む。このルートは全ノードの約半分をカバーし、叙事のトーンと画面のつながりを判断するのに十分。

受け入れ基準：

1. オープニングから第2章終了まで中断がない。
2. 「手紙を残す」を選択した後、次の叙事が選択した分岐に対応している。
3. レビュー機Bの切断状態で第2章終了まで進める。
4. 画面と文字に明らかなずれがない。

既知の制限：本パッケージはプレイヤーを提供し、編集や他エンジンへの再書き出しを約束するものではありません。リモート素材はネットワークとサービスに依存します。リソースアドレスに制作者のPC上のlocalhostを誤用してはいけません。レビュー機Bはローカルパッケージ内の素材を読み込むべきで、実際の切断結果は別途記録します。

問題報告フォーマット：問題が発生したら4行で書いてください——発生位置（第何章、どの選択の後か）、あなたがしたこと、あなたが見たもの、あなたが期待したもの。例：「第2章冒頭、『手紙を残す』を選んだ後、画面が約2秒空白のまま停止。郵便局内観がすぐに現れると期待した。」「固まった」とだけ書かないでください。

この説明の要点は、受け入れ基準がすべてチェック可能で、目標ルートが具体的な章まで書かれ、既知の制限がプレイヤーにできないことを直接伝えている点です。

上記のページを書き終えると、選択は明確になります。レビュー機Bは切断検証が必要で、リモートリンクパッケージでは満たせないため、ローカル素材パッケージを渡す必要があります。レビュー機Aは接続可能なので、リモートリンクパッケージを快速ルートとして渡します。2つのパッケージは2つの検証ルートに対応し、二者択一ではありません。

もし2台ともオフラインを要求するなら、ローカル素材パッケージを提供します。相手が初回ダウンロード量を減らしたいかつ接続可能なら、リモートリンクパッケージを提供できます。まったくダウンロードせず、Webページを開くだけを要求する場合は、アクセス可能なオンライン体験入口がすでにあるかを別途確認すべきで、リモートZIPパッケージをそのままホスト済み作品ページとして扱ってはいけません。

この段階の判断根拠は説明から来るもので、2つのモードの抽象的な比較からではありません。

書き出し完了はプレイアビリティ検証通過を意味しません。ZIP成功はパッケージング動作が完了したことだけを示し、相手が開ける、たどれることは示しません。以下の順序で確認することを勧めます。実測条件がない場合は、確認方法と期待結果を説明に書き、相手に代わりに検証してもらいます。

1. ローカル素材パッケージを解凍後、説明ファイルと起動ファイルが両方あることを確認し、説明に従って一度実行し、切断状態で目標ルートをたどる。
2. リモートリンクパッケージを解凍起動後、想定アプリケーションドメイン経由で素材を読み込むことを確認し、目標ルートをたどる。
3. 目標ルート内の各選択点と期待分岐を照合し、ずれがないことを確認する。
4. 説明内の既知の制限が実際と一致するか確認する。特にプレイヤーは編集できず、他エンジンへ再書き出しできないという2点。
5. 問題報告フォーマットが説明に書かれ、受け取り手が問題をどう記述すべきか分かることを確認する。

第1步と第2步は2つの独立したルートであり、互いに代替しません。片方だけを行うと、もう片方の問題は露見しません。

見落としやすいのは目標ルートの終点です。「一通りたどる」だけでは不十分で、相手は最初の分岐で止まるかもしれません。具体的な章または具体的な選択の後まで書く必要があります。

もう一つの漏れは、受け入れ基準を感覚語で書くことです。「画面が滑らか」「体験が良好」はチェックできません。「中断なし」「分岐対応」「切断でもたどれる」といった判断可能な項目に変えます。

完了チェック：説明に5項目がそろっているか。目標ルートに明確な終点があるか。受け入れ基準が每条チェック可能か。既知の制限に、プレイヤーはエディターではない、リモートリンクはネットワーク依存、localhostは汎用不可の3点が含まれるか。問題報告フォーマットに4行の例があるか。5項目がそろい、4条がチェック可能で、3つの制限が明記され、フォーマットに例があれば、このページはパッケージとともに送れます。

送る前に最後に一つ：この説明ページをプロジェクトに参加していない人に読んで聞かせ、目標ルートと受け入れ基準を復唱してもらいましょう。その人が復唱できれば、受け取り手もそれに従って実行できる可能性があります。