ゲームのバージョン管理：公開後の更新を安全に行う
遊びを届ける執筆にClaudeを使用しています。
ゲームを公開した後、「バグを直したい」「新しいステージを追加したい」と思ったとき、最初に不安になるのは「更新しても今遊んでいる人のプレイに影響が出ないか」という点ではないでしょうか。開発中と違い、公開後のファイルには実際にプレイしている人がいます。不用意に上書きすると、ゲームが途中で壊れたり、過去のセーブデータと噛み合わなくなったりする事故につながります。 バージョン管理とは、「どのファイルがいつどのように変わったか」を記録し、問題が起きたときに前の状態へ戻せるようにする仕組みです。ソフトウェア開発では当たり前の習慣ですが、個人でブラウザゲームを作っている場合は後回しにされがちです。この記事では、公開後の更新を安全に行うための考え方と具体的な手順を整理します。
更新を安全に行うために決めておくこと
更新作業を始める前に、三つのことをルールとして決めておくと、後の判断がずっと楽になります。
① バージョン番号の付け方を統一する
ゲームのHTMLやJavaScriptの先頭に、// version: 1.2.0 のようにバージョン番号をコメントで書いておくと、どのファイルがどの状態かをすぐ確認できます。番号の体系は メジャー.マイナー.パッチ（セマンティックバージョニング）が広く使われています。バグ修正だけなら末尾の数字を上げ、新機能を加えたら真ん中を上げ、ゲームの仕組みを大幅に変えたら先頭を上げるという目安で運用できます。どんな体系を使うにしても、「決めて統一する」ことが大切です。
② 更新履歴をファイルで残す
CHANGELOG.md や 更新履歴.txt という名前のテキストファイルを一本作り、「いつ・何を・なぜ変えたか」を3行程度でメモしておきます。これはプレイヤーに見せるためだけでなく、自分が数か月後に「なぜこう変えたんだっけ」と迷ったときに戻れる地図になります。
③ 公開用ファイルと作業用ファイルを分ける
ローカルの作業フォルダに release/ と dev/ を作り、公開に使うファイルだけを release/ に置くというルールを決めます。「最後に公開したもの」が常に一か所に揃っている状態を保つだけで、事故の多くを防げます。
Git を使ったバージョン管理の基本手順
Git はファイルの変更履歴を記録するツールで、無料で使えます。コマンドラインが苦手な場合は、GitHub Desktop などのGUIアプリを使うとほぼ同じことを視覚的に操作できます。
最初に一度だけ行う設定
- Git をインストールし、GitHub（または同種のホスティングサービス）にアカウントを作成します。
- プロジェクトのフォルダをリポジトリ（履歴を管理する単位）として初期化します。
- .gitignore ファイルを作り、一時ファイルや個人の設定ファイルなど履歴に含めたくものを除外します。
- ここまでの状態を最初のコミット（記録）として保存します。
更新のたびに行う作業
- ブランチを切る：main ブランチはいつでも動く安定版を置く場所と決め、作業は必ず別のブランチ（例：fix/score-bug）で行います。
- 変更してコミットする：一つの目的（バグ修正、機能追加など）が完結したらコミットします。一回のコミットに複数の無関係な変更を混ぜないようにすると、後で「どのコミットで壊れたか」を探しやすくなります。
- テストする：ブランチ上でローカルのブラウザを使い、意図した動作になっているかを確認します。
- マージしてタグを付ける：問題がなければ main にマージし、公開するタイミングで v1.2.0 のようなタグを付けます。タグがあると「このバージョンを配布した」という記録が明確になります。
- プラットフォームに反映する：ZIPやHTMLファイルをアップロードします。
「戻せる」状態を保つための判断基準
更新後に不具合が出たとき、「どこまで戻すか」を素早く判断するためには、戻す先が明確である必要があります。
タグやリリースブランチを残すことが前提になります。GitHub であれば Releases 機能を使うと、タグに紐づけてZIPを保存でき、過去バージョンのファイル一式をいつでもダウンロードできます。これが「ロールバック（前の版へ戻す）」の実体です。
セーブデータとの互換性は最も注意が必要な点です。ゲーム内部でローカルストレージや IndexedDB にデータを保存している場合、データの構造をバージョンアップで変えると、古いデータを読み込んだときにエラーになることがあります。対処法として、データを読み込む処理の中に「バージョンが古いデータを新しい形式に変換するマイグレーション処理」を書いておくと安全です。変更の大きさによっては、旧形式のデータは無視して初期化することをプレイヤーに事前に案内する方法もあります。
「破壊的変更」かどうかを判断することも重要です。バグ修正はほぼ常に後方互換（古い状態と合わせやすい）ですが、スコア計算式の変更やデータ構造の再設計は既存プレイヤーに大きく影響します。影響が大きい変更をするときは、更新ノートをゲームの起動画面やプラットフォームの説明欄に書いておくことで、プレイヤーの混乱を減らせます。
小規模な開発でも無理なく続けるコツ
Gitのすべての機能を使いこなす必要はありません。「一人で作っていて規模も小さい」という場合は、次の最小構成から始めるだけで十分な安全網になります。
- 公開の直前に必ずZIPでバックアップをローカルに保存し、日付をファイル名に入れる（例：mygame_20261020.zip）
- バージョン番号をHTMLコメントに書く
- 変更内容を一行でも更新履歴に残す
これだけでも「一つ前の公開版に戻す」「何を変えたか確認する」という二つの基本操作ができます。慣れてきたら Git を導入し、記録の粒度を細かくしていけばよいです。
完璧な管理体制を最初から作ろうとすると続きません。「最後に公開したファイルがどこにあるか、常に把握できている」という状態を最初の目標に据えると、習慣として定着しやすくなります。
次の行動
手元のプロジェクトフォルダを確認し、「最後に公開したファイル」がすぐ見つけられる状態かどうかを確かめてみてください。見つけにくければ、今日のうちに release/ フォルダを作って整理するだけでも大きな一歩です。ゲームが完成してアソバースへ投稿する際は、バージョン番号や更新内容を説明欄に書いておくと、プレイヤーへの案内としても役立ちます。
参考資料
- Semantic Versioning 公式仕様（semver.org）
- Git 公式ドキュメント
- GitHub Releases 公式ガイド（GitHub Docs）
- MDN Web Docs — Web Storage API、IndexedDB API
