作品のURLに版の印を付けると、なぜ古いHTMLが表示されなくなるのか

ブラウザは「URL」を見出しにして覚えている

ブラウザのキャッシュは、URLを見出しにした引き出しのようなものです。あるURLのファイルを受け取って保存し、次に同じURLを求められたとき、期限内であれば通信せずに引き出しの中身を渡します。

ここで大事なのは、ブラウザが中身を見て「新しくなったか」を判断しているわけではない点です。判断の材料は、URLと、サーバーが付けた保存の指示（保存してよい期間など）です。サーバー側でファイルが差し替わっても、期限内で同じURLなら、手元の古いファイルが使われることがあります。

ゲームのHTMLは1枚で完結しているとは限りません。入口のHTMLが、JavaScript、画像、音声などを読み込みます。更新で入口だけが新しくなり、読み込まれる側が古いままだと、新旧が混ざった状態になります。表示が崩れる、ボタンが反応しないといった、原因の見えにくい不具合になりやすい場面です。

URLを変えれば「別のファイル」として扱われる

キャッシュがURLを見出しにしているなら、中身を変えるときに見出しも変えれば、古い引き出しは使われません。これが「バージョン付きURL」の考え方です。主な書き方は次の3つです。

• クエリ文字列、URLの例：game.js?v=3、特徴：手軽に付けられます。版の数字を書き換え忘れると効果がありません
• ファイル名に版や指紋、URLの例：game.3f9a1c.js、特徴：中身から作った短い文字列を使うと、中身が変わったときだけ名前が変わります
• 経路に版、URLの例：/v3/game.js、特徴：版ごとにまとまりで管理できます。古い版を残すか消すかの判断が必要です

3つに共通するのは、「同じURLなら同じ中身」という約束を作ることです。この約束が守られていれば、素材のような変わらないファイルは長く保存させても安全になります。変わったときは名前も変わるので、古い版は呼ばれなくなります。

注意したいのは、入口のHTMLです。入口のURLまで毎回変えると、遊ぶ人が持っているリンクやブックマークが無効になります。そのため、入口は毎回「新しくなったか」を確かめさせ、中で読み込む素材にだけ版の印を付ける組み合わせがよく使われます。入口が新しければ、そこに書かれた素材のURLも新しくなり、芋づる式に最新へ切り替わります。

アソバースの確認済み事項から読み取れること

アソバースの案内で確認できる事項のうち、この話に関係するものを挙げます。

• 作品は投稿後に「公開内容の更新」ができます。
• アップロード作品では、直下の index.html が入口です。素材は相対パスで指定します。
• アップロードしたコードは、sandbox付きiframeの中で、メインサイトとは別のオリジンから配信されます。
• サービスワーカー（ブラウザ内に常駐してキャッシュを自前で制御する仕組み）は対象外です。
• アップロード作品の localStorage と sessionStorage は、一時メモリーの互換処理です。

ここから「設計から読み取れること」を、確認済みの範囲で3点に絞って書きます。

1. 素材が相対パスなので、読み込み先は入口HTMLの位置を基準に決まります。入口のURLが版ごとに変わる設計なら、素材もそれに追従して新しい場所から読まれます。入口の位置が版で変わるかどうかは、確認済み事項にはありません。
2. サービスワーカーが対象外なので、作品側が独自のキャッシュ制御を持ち込み、更新後も古い版を返し続けるという経路が、仕様の上で一つ減っています。残るのは、ブラウザ標準のキャッシュの挙動です。
3. 別オリジンでの配信とiframeの組み合わせにより、遊ぶ人の画面では「サイト本体」と「作品」が別々のURLで読まれます。古い表示が出たときは、どちらのURLが古いのかを分けて考える必要があります。

一方、作品のURLに版の印が付いているか、付いているならどの方式か、公開内容を更新したときにどの部分が変わるのかは、確認済みの事項に含まれていません。この部分は次の節の方法で、作品を開いて確かめてください。

自分で確かめるための設計書

実際の挙動は、小さな実験で確かめられます。問いは「公開内容を更新したあと、遊ぶ人の画面で新しい版が読まれるまでに、何が変わるのか」です。

準備するもの

• 画面に「版A」と大きく表示するだけのHTMLと、「版B」と表示するだけのHTML。中身はそれ以外同じにします。
• 非公開のまま確認できる下書き、または自分用の投稿。公開の可否は、アソバースの現在の案内で確認してください。
• ブラウザの開発者ツール（多くのブラウザでF12キー）の「ネットワーク」タブ。

手順

1. 版Aを投稿し、作品ページで開きます。ネットワークタブを開いた状態で再読み込みし、読み込まれたファイルのURLを記録します。
2. 公開内容を版Bに更新します。
3. 同じブラウザで作品ページを通常の再読み込みで開き、「A」と「B」のどちらが出るかを記録します。
4. 別のブラウザ、またはシークレットウィンドウでも同じ作品を開き、結果を比べます。
5. 手順1と3で記録したURLを見比べ、入口や素材のURLに違いがあるかを確かめます。

何を記録するか

次の4項目を、1回ごとに表へ書き留めます。

• どちらの版が見えたか（A／B）
• 入口HTMLのURL（クエリ文字列や版らしい文字列の有無）
• ネットワークタブの「サイズ」列が通信量かキャッシュ表示か
• 試した回数（各条件で3回以上）

結果の読み方

• 通常の再読み込みで即座に版Bが出て、URLのどこかが変わっていれば、URLで切り替わる設計と読めます。
• URLが同じなのに版Bが出る場合は、サーバーが毎回新しさを確認させている可能性があります。キャッシュの指示はレスポンスヘッダーで確認できます。
• 版Aが残る場合は、キャッシュの期限が働いている可能性があります。ただし、ブラウザ拡張機能や別の要因もあるので、1回では決めずに手順4の別環境と比べてください。

起こりやすい誤り

• 開発者ツールの「キャッシュを無効にする」を入れたままだと、キャッシュの挙動が見えません。条件を揃えるため、最初に設定を確認します。
• 更新直後の1回だけで結論を出す誤りです。複数回、複数環境で比べます。
• 保存データと混同する誤りです。次の節で触れます。

「ファイルの版」と「セーブの版」は別の話

もう一つ、混同しやすい点があります。ファイルを新しくしても、遊ぶ人の進行データが自動で新しい形式になるわけではありません。

アソバースの13作品では、古い保存（version1）が新しい形式（version2）へ移行される、と確認されています。つまり「ファイルの版」と「保存形式の版」は別の軸で、後者はゲーム側のコードが責任を持って変換する前提です。クラウドセーブは作品ごとにJSONで128KiBまでと決まっているので、版を上げるときも、古いデータを読める形で受け取る設計が必要です。

作る人が更新するときは、次の順で確認すると、取りこぼしを減らせます。

1. 入口HTMLと素材の参照が、相対パスのまま正しく解決されるか。
2. 更新後のコードが、古い形式のセーブを読めるか。
3. 保存形式を変えたなら、版を表す項目をセーブ自体に持たせているか。

遊ぶ人側で古い表示が続くときは、ページの再読み込みを試し、それでも変わらなければ、ブラウザのキャッシュ削除や別ブラウザでの確認が手がかりになります。ゲストの進行は端末内に保存されるとされているので、キャッシュ削除の範囲に保存データが含まれるかどうかは、削除する前にブラウザの案内で確認してください。

次の行動

自分の作品か、試作用の小さなHTMLで「版A→版B」の更新を行い、この記事の手順で入口と素材のURLを記録してみてください。URLに版の印があるかどうかは、作品を開いて確かめるのが確実です。更新を重ねる作品なら、セーブの形式に版の項目を持たせておくと、あとで助かります。

参考資料

• MDN Web Docs「HTTP キャッシュ」
• RFC 9111 HTTP Caching