投稿直前に見つかる問題を自分で集める：公開ボタンの前の点検実験

問いの立て方と準備するもの

実験の問いは、次の三つに分けます。

1. 手元で開いたときには見えず、表示の確認で初めて見える問題は、どの種類か。
2. 表示の確認でも見えず、公開後に気づく問題は、どの種類か。
3. 点検の順番を変えると、見つかる件数は変わるか。

準備するものは次のとおりです。

• 公開予定の完成に近いゲーム1本。複数本あれば、種類の違うもの（保存あり／なし、音あり／なし）を選ぶと比較しやすくなります。
• 投稿用に固めたZIP、または単体のHTMLファイル。
• 記録シート。表計算ソフトか紙の表で足ります。
• 確認用に使う別のブラウザ、またはシークレットウィンドウ。拡張機能やキャッシュの影響を切り離します。
• 可能なら、画面の狭い端末か、ブラウザの開発者ツールの端末表示。

あらかじめ、投稿の制約を点検項目に書き出しておきます。確認済みの制約は次のとおりです。

• アップロードは20MiB以内。ZIPは展開後に合計100MiB、1,000ファイル、1ファイル30MiB以内。
• 入口は直下の index.html。素材は相対パスで参照する。
• サーバー用コード、サービスワーカー、SharedArrayBufferを使うマルチスレッドは対象外。
• 1人につきUTCで1日10回、アカウントごとに100アップロード・1GiBまで。

アップロード回数には上限があるため、投稿画面へ通す前に手元でできる点検を済ませておくのが、この実験の前提になります。表示の確認がアップロード回数に数えられるかどうかは、この記事では断定できません。現在の案内で確認してください。

点検の手順：六つの視点で順に開く

点検は、視点を固定して同じ順に行います。順番がばらつくと、あとで件数を比べられないからです。

手順0：読み込み失敗を拾う小さな目印を入れる

手元の点検では、読み込み失敗や実行エラーを画面に出す仕掛けがあると、見落としが減ります。次のスニペットを index.html の <head> の先頭に貼ります。点検が終わったら必ず外してください。

<script>
(function () {
  var log = [];
  var box;
  function render() {
    if (!document.body) return;
    if (!box) {
      box = document.createElement('pre');
      box.style.cssText = 'position:fixed;left:0;bottom:0;max-width:100%;' +
        'margin:0;padding:4px 8px;background:#300;color:#fff;' +
        'font-size:12px;z-index:99999;white-space:pre-wrap';
      document.body.appendChild(box);
    }
    box.textContent = log.join('\n');
  }
  window.addEventListener('error', function (e) {
    var t = e.target;
    if (t && t !== window && (t.src || t.href)) {
      log.push('読み込み失敗: ' + (t.src || t.href));
    } else {
      log.push('実行エラー: ' + e.message);
    }
    render();
  }, true);
  window.addEventListener('unhandledrejection', function (e) {
    log.push('未処理の失敗: ' + e.reason);
    render();
  });
  document.addEventListener('DOMContentLoaded', render);
})();
</script>

画像や音声の読み込み失敗は、通常のエラーとは違って上へ伝わりません。そのため、第三引数を true にして途中で捕まえています。画面左下に赤い帯が出たら、一行が一件の候補です。

視点1：入口と構成

ZIPを展開した直後の階層を見ます。index.html が直下にあるか。フォルダごと圧縮したために一段深くなっていないか。ファイル数と最大ファイルのサイズも、この時点で数えます。

視点2：参照の仕方

素材の参照が相対パスになっているかを確認します。絶対パスや、手元のフォルダ名を含むパスが残っていないかを探します。大文字小文字の違いも見ます。手元の環境では動いても、配信側では区別されることがあります。

視点3：対象外の仕組み

サービスワーカーの登録、サーバーへの通信を前提にした処理、SharedArrayBufferを要する処理が残っていないか、コードを検索します。試作の途中で入れた仕組みが残っているケースが想定されます。

視点4：操作と画面

表示の確認の画面で、起動から一周遊びます。ここは次の項目を一つずつ確かめます。

• 最初の操作が、説明なしで分かるか。
• キーボード、タッチ、マウスのうち、想定した入力がすべて通るか。
• 画面の狭さや拡大・縮小で、ボタンが画面外に出ないか。
• ライト／ダークの切り替えで、文字が背景に溶けないか。
• 「動きを抑える」設定にした状態で、点滅や大きな動きが残っていないか。

視点5：保存と再開

保存をもつゲームは、再読み込みで進行が残るかを見ます。アップロードした作品の localStorage と sessionStorage は、一時メモリーとして働く互換処理だと案内されています。再読み込みや別の日に同じ状態が続くことを前提にした作りは、ここで崩れる可能性があります。ログイン中の利用者が使えるクラウドセーブは、作品ごとにJSONで128KiBまでです。保存データの大きさも見積もっておきます。

ゲストの進行は端末内に保存され、ログイン後のアカウントへ自動では混ざりません。「ゲストで遊んだ記録を、ログイン後も使える」と思い込んだ設計になっていないかも、あわせて見ます。

視点6：言語と文章

作品名や紹介文、遊び方の文章を読み返します。サイトの表示言語は日本語と英語で切り替わりますが、作者が入力した作品名や紹介文は書き換えられません。ゲーム内の文言を両言語に対応させるかどうかは作者の判断です。対応しないなら、遊び方の文に前提を書いておきます。

投稿画面の「紹介文と遊び方を作成」で下書きを作った場合は、実際の動きと食い違う記述がないか読み比べます。この機能は「この文章を使う」を押したときだけ反映されます。押す前に、ゲームを遊んだ目で一文ずつ照合してください。

記録の取り方：一件ずつ、同じ形で残す

見つけた問題は、その場で一件ずつ書き留めます。あとでまとめて思い出そうとすると、小さな問題から抜けていきます。記録の項目は次のとおりです。

• 番号、書く内容：通し番号
• 発見した段階、書く内容：手元／表示の確認／公開後（または公開を想定した再確認）
• 視点、書く内容：上の視点1〜6のどれか
• 症状、書く内容：見えたことを一文で
• 再現手順、書く内容：他人がたどれる最短の操作
• 原因、書く内容：分かった場合のみ。不明なら「不明」
• 修正にかけた時間、書く内容：分単位の概算
• 修正後の再確認、書く内容：済／未

記録の単位は「症状」ではなく「原因」を意識します。赤い帯が5行出ても、原因が一つのパス間違いなら一件です。逆に、見た目が同じでも原因が二つあれば二件にします。迷った場合は、いったん別々に書いておきます。

回数は、同じゲームで最低3周を目安にします。1周目は普段の確認のやり方で行い、2周目は上の視点順に行い、3周目は修正後の再確認として行います。1周目と2周目の件数の差が、「視点を決めて点検する価値」の目安になります。

結果の読み方：件数より「どの段階で見えたか」を見る

記録がたまったら、次の三つの切り口で並べ替えます。

1. 視点別の件数。 特定の視点に偏っているなら、その分野は次回から手元で先に確認する項目になります。
2. 発見した段階の分布。 「表示の確認」で見つかったものが多ければ、手元の確認が実際の配信と条件を揃えられていません。ローカルの静的サーバーで開く、別のブラウザで開く、といった条件の寄せ方を検討します。
3. 修正時間。 件数が少なくても時間の大半を占める問題があれば、そこに事前の対策を集中させます。

判断の目安は次のとおりです。

• 視点1〜3（構成・参照・対象外）の問題が中心なら、機械的に防げる種類です。公開前のチェックリスト化が効きます。
• 視点4（操作・画面）が中心なら、制作者本人の慣れが原因の場合があります。作品を初めて見る人に一周遊んでもらう方法が合います。
• 視点5（保存）が中心なら、保存の仕様を設計の段階で決め直す必要があります。
• 3周目でも同じ原因が再発するなら、修正が症状への対処で止まっている可能性があります。

件数が少ないこと自体は、良い結果とも悪い結果とも決まりません。点検の粒度が粗かっただけかもしれません。視点ごとに「何を見たか」を記録に残しておくと、その区別がつきます。

起こりやすい誤り

• 手元の成功を本番の成功と同じに扱う。 ファイルを直接開く方法と、配信された状態で開く方法とでは、読み込みの条件が違います。ゲームはsandbox付きのiframeで動き、アップロードしたコードはメインサイトと別のオリジンから配信されます。実行環境に由来する差は、作品を開いて確かめる以外に確実な方法がありません。
• キャッシュが古いまま確認する。 修正したのに症状が消えないとき、古いファイルを見ている場合があります。別のブラウザかシークレットウィンドウで開き直します。
• 確認用スニペットを残したまま公開する。 点検用の赤い帯は、公開版には不要です。手順0のコードは、点検の最後に削除して、削除後にもう一度開きます。
• アップロード回数を点検に使い切る。 1日10回の上限があります。手元で潰せる項目を先に済ませ、投稿画面へ通すのは確認の最終段階に限ります。
• 紹介文の下書きを読まずに採用する。 生成された文章は、ゲームの実際の動きと照合してから使います。
• 記録を「直した」で終える。 修正後の再確認の欄が空のままでは、3周目の意味がなくなります。

次の行動

まず、手元のゲームを1本選び、上の記録シートを作ってください。1周目は普段どおりの確認で、何件見つかるかを数えます。2周目は六つの視点の順に行い、視点ごとの件数を比べます。投稿画面の「表示の確認」は、その2周目の仕上げとして使ってください。