投稿画面の3段階：入力・確認・公開の画面はなぜ分かれているか

3段階を「同じ四つの問い」で切り分ける

3段階を比べるには、段階ごとに同じ物差しを当てる必要があります。次の四つの問いを使います。

1. この段階で、自分は何を決めたり変えたりできますか。
2. 次へ進むボタンを押すと、何が起きますか。
3. 前の段階へ戻ると、入力した内容は残りますか。
4. この段階の内容は、他の利用者から見えますか。

四つ目が特に重要です。入力と確認は作者だけが見ている段階で、公開から先は他人が見る段階だと予想できます。この境界がどこにあるかを自分の目で確かめるのが、分析の中心です。

アソバースでは、下書き保存、公開内容の更新、非公開化、削除ができます。公開後も取り返しがつかないわけではありません。それでも、公開前に直すのと公開後に直すのとでは、直す相手が違います。公開前に直せば作者のファイルだけが対象で、公開後に直すと、すでに遊んだ人や付いたレビューがあるかもしれない作品を差し替えることになります。

準備するもの

次のものを用意します。

• 投稿予定の作品、または投稿の練習用に作った小さなHTMLゲーム。ボタンを押すと数字が増えるだけのものでも構いません。
• 3段階を書き込む記録表。紙でも表計算でも使えます。
• メールアドレスの確認が済んだアカウント。公開にはメール確認が必要です。

練習用を使う場合は、回数に気をつけます。アップロードは1人あたりUTC（協定世界時）で1日10回までで、アカウントごとに100アップロード・1GiBの上限もあります。UTCの日付替わりは日本時間の午前9時です。何度も試すと上限に近づくので、先に記録表の項目を決め、1回の試行で全項目を記録するようにします。

アップロードの制限も確認しておきます。ファイルは20MiB以内、ZIPなら展開後に合計100MiB・1,000ファイル以内、1ファイルは30MiB以内です。入口は直下のindex.htmlで、素材は相対パスで参照します。

記録表は次の形にします。

• 入力、決めたり変えたりできること：、次へ進むと起きること：、戻ったときの入力内容：、他の利用者から見えるか：
• 表示の確認、決めたり変えたりできること：、次へ進むと起きること：、戻ったときの入力内容：、他の利用者から見えるか：
• 公開、決めたり変えたりできること：、次へ進むと起きること：、戻ったときの入力内容：、他の利用者から見えるか：

手順：画面を見ながら表を埋める

入力の段階

HTMLかZIPをアップロードするか、公開済みURLを入れるかを選びます。URLで投稿する場合は、作品が先にどこかで公開されている必要があります。入力画面では次を記録します。

• 必須の項目と任意の項目はどれか。
• 作品名や紹介文以外に、設定できることはあるか。
• 下書き保存は、この段階で使えるか。

投稿画面には「紹介文と遊び方を作成」という機能があります。公開済みのURL、または本人の検証済みアップロードを読み取り、選択した言語で下書きを作ります。生成された文章は、「この文章を使う」を押したときだけ反映されます。生成の操作だけで公開されることはありません。

この仕組みは、3段階の発想と同じ向きです。機械が作った案を、人が採用するまで確定させません。生成された文を押す前後で、入力欄の内容がどう変わるかを記録しておきます。利用は1時間3回まで、全体でUTC1日20回までの制限があるので、何度も試し押しはしないでください。

表示の確認の段階

この段階が分析の中心です。記録するのは次の項目です。

• 何が表示されるか。作品が実際に動く状態で出るのか、情報の一覧だけなのか。
• 作品を起動して操作できるか。
• 入力段階に戻れるか。戻ると入力内容は残るか。
• この段階で、他の利用者に見えているか。

「確認の画面でゲームが動くか」は、記事では断定できません。画面を開いて確かめる項目です。動くなら、公開後の実行環境と同じ条件かどうかも気になるところですが、これも画面だけでは判別しにくいので、次の節の検証項目で補います。

公開の段階

公開ボタンを押した後に、何が変わるかを記録します。

• 作品ページが作られるか。自分の作品として、どこから開けるか。
• 非公開化、内容の更新、削除の入口はどこにあるか。
• 自分の作品に、自分で評価を付けられないことは、画面でどう表現されているか。自作の評価は仕様上できません。

作品ページを開いたら、プレイ回数の表示にも注目します。プレイ回数は作品起動の実測回数で、人数ではありません。同じ端末と作品の組み合わせで30分以内に再起動した分は重複として除かれます。確認の段階で自分が何回起動したかをメモしておけば、公開直後の表示との関係を観察できます。ただし、確認での起動が数えられるのかは確認済みではありません。この数え方に答えを出すには、起動回数と表示の両方を記録する必要があります。1回の記録では偶然の影響を除けないので、複数の作品や複数回で見ます。

確認の段階で見る六つの項目

確認の画面が動作を見せてくれるなら、公開前に直せる失敗を見つける最後の機会です。次の六項目を順に点検します。点検の単位は「項目ごとに、問題なし・問題あり・判断できない」の三択です。

1. 入口：ZIPの場合、直下にindex.htmlがあるか。フォルダごと圧縮すると、入口が一段深くなる失敗が起こりやすいところです。
2. 素材の読み込み：画像や音が出るか。絶対パスや、自分のパソコンの場所を指す書き方になっていないか。素材は相対パスで指定します。
3. 使えない構成：サーバー側の処理を呼んでいないか。サービスワーカーやSharedArrayBufferに頼っていないか。これらは投稿の対象外なので、手元で動いても公開先では動きません。
4. 保存の挙動：進行や記録を保存する作品なら、画面を再読み込みして残るかを見ます。アップロード作品内のlocalStorageやsessionStorageは、一時メモリーの互換処理です。端末に永続的に保存される仕組みとは考えず、永続的な保存が必要なら、アップロードに自動で追加されるSDKのクラウドセーブ（作品ごとにJSONで128KiBまで）を使う設計かどうかを見直します。URLで投稿する作品は、作者がSDKを読み込んだときに、作品専用のプレイヤーIDとクラウドセーブが使えます。
5. 操作と画面幅：キーボードだけ、タッチだけで最後まで遊べるか。画面を狭くしたとき、ボタンが画面外に出ないか。
6. 最初の10秒：開いた直後に、何をする作品かが分かるか。遊び方の説明がなくても最初の操作が見つかるか。

6項目のうち、「判断できない」が付いたものは、確認の画面で見えていないということです。公開後に作品ページで再確認する項目として、別に控えておきます。

結果の読み方

記録表と点検結果を、次のように読みます。

境界の位置を読む。 「他の利用者から見えるか」の列が、どの段階から「はい」に変わるかを見ます。公開の段階から変わるなら、入力と確認は作者専用の試し場という仮説が支持されます。確認の段階でも見えるような記録があれば、確認画面の使い方に注意が必要になるので、その旨をメモします。

戻りやすさを読む。 確認から入力に戻ったとき、入力内容が残っているなら、修正して再確認するやり方が楽になります。内容が消えるなら、確認前にメモを手元に残しておく必要があります。

確認の画面が動作を見せるかを読む。 作品が動くなら、六項目の点検が確認の段階でできます。情報の一覧だけなら、動作の点検は公開後になるため、非公開化できる点を前提にした慎重な手順が必要です。どちらなのかは記録で決まります。

点検結果の偏りを読む。 問題あり、が入口や素材パスに集中していれば、ファイルの組み方の問題です。保存や使えない構成に集中していれば、作り方の前提の問題です。前者は圧縮の仕方を直し、後者は設計を見直します。

起こりやすい誤り

• 手元で動いたことを理由に確認を飛ばす。 手元のブラウザでファイルを直接開く環境と、別オリジンのsandbox付きiframeでは、権限が違います。動作の一致を前提にしないでください。
• 練習の投稿を重ねて上限を使い切る。 1日10回の上限は、本番の投稿に回す分を残して考えます。
• 「生成した紹介文」を読まずに使う。 「この文章を使う」を押すと反映されるので、遊び方の説明が実際の操作と合っているか、押す前に作品と見比べます。
• プレイ回数を人数と読む。 数えているのは起動の実測回数です。
• 1回の記録で結論を出す。 画面の挙動は作品や状況で変わる可能性があります。違う作品で、もう一度同じ表を埋めて比べます。
• 確認済みでない仕様を断定する。 画面に書いていないこと、特に確認画面での起動の扱いなどは、現在の案内で確認します。

次の行動

記録表を作り、次の投稿で入力、表示の確認、公開の3段階に同じ四つの問いを当ててみてください。確認の段階では、六項目の点検を済ませてから公開に進みます。「判断できない」が残った項目は、公開後の作品ページで見直すリストとして残しておきます。