AIとの制作で前の版に戻りたい：ゲームの変更履歴を残す方法
遊びをつくる執筆にClaudeを使用しています。
AIにコードの修正を頼んだら、動いていた部分まで壊れてしまった——そんな経験はないでしょうか。AIとのやり取りは速いぶん、「少しずつ確かめながら進む」リズムが崩れやすく、気づいたときには直前の動く版がどこにあるかわからなくなっていることがあります。この記事では、ローカル環境での版管理と公開作品の更新を切り離す考え方を整理し、Gitを使った変更履歴の残し方と復元の手順を説明します。
この記事の目次
AIと作るときに版管理が特に必要な理由
手でコードを書くときは「少し変えて、試して、また変える」という小さなサイクルが自然に生まれます。一方でAIに「このバグを直して」「この機能を追加して」と頼むと、一度に数十行が書き換わることも珍しくありません。変更が大きいほど、意図しない箇所まで影響が及ぶリスクが上がります。
また、AIとの会話ログはコードの変更履歴にはなりません。「3回前にAIが直したバージョン」を取り出したいとき、チャット履歴を遡っても実際のコードを再現できるとは限りません。変更履歴はコード側で管理する必要があります。
さらに重要なのが、ローカルの版管理と公開作品の更新を別のこととして扱うことです。手元で何度試行錯誤しても、公開中の作品には影響しません。納得できた版だけをアップロードする流れを作れば、プレイヤーが途中の壊れた状態を目にすることを防げます。
Gitで変更履歴を残す基本の流れ
Gitは変更履歴を管理するためのツールです。「コミット」と呼ぶ操作を行うたびに、そのときのファイルの状態がスナップショットとして記録されます。あとからいつでも過去のスナップショットを取り出せるのが最大の特徴です。
HTML・CSS・JavaScriptで作ったゲームであれば、プロジェクトフォルダで以下の3ステップを繰り返すだけで履歴が積み上がっていきます。
- リポジトリを初期化する（最初の1回）：プロジェクトフォルダで git init を実行します。.git フォルダが作られ、以降の変更が追跡対象になります。
- 変更をステージする：git add . で変更したファイルをコミット対象に登録します。特定のファイルだけ選ぶときは git add game.js のようにファイル名を指定します。
- コミットする：git commit -m "衝突判定を修正、タイトル画面を追加" のようにメッセージを添えて記録します。
コミットメッセージは「何を変えたか」を短く書くと、あとで履歴を見返したときに役立ちます。「AIに○○を修正してもらった」と書くのも実用的です。
これだけで、ゲームの変更履歴がローカルに蓄積されていきます。「動いていたあの版」を取り出す手がかりになるのが、このコミットの積み重ねです。
AIとの作業でコミットを切るタイミング
「どのタイミングでコミットすればいいか」は、AIとの作業サイクルに合わせて考えると決めやすくなります。次の3つを目安にしてください。
- AIに大きな修正を頼む前：「ゲームループを作り直して」「物理演算を追加して」など、広範囲に影響しそうな依頼をする直前にコミットしておきます。修正後に問題が出ても、この版に戻れます。
- ひとつの機能が動いたとき：スコア表示が正しく出た、ステージ遷移が通った、などブラウザで確認できた節目でコミットします。「動く状態の記録」を細かく残すのが目的です。
- 作業を終えるとき：未完成でも、その日の最終状態をコミットしておくと翌日の出発点が明確になります。メッセージに「作業中」と書いても構いません。
コミットの粒度に正解はありませんが、「AIに任せた修正の前後で1コミットずつ」を習慣にするだけで、問題が起きたときの調査が格段に楽になります。
前の版に戻す：履歴の確認と復元の手順
「2回前に動いていた版に戻したい」というときの手順です。
1. 履歴を確認する
git log --oneline各コミットがハッシュ値（例：a3f8c12）とメッセージの一覧で表示されます。戻りたい版のハッシュ値を確認します。
2. 特定のファイルだけ戻す
ゲームロジックのファイルだけを壊してしまった場合など、一部のファイルのみ復元したいときは次のコマンドを使います。
git checkout a3f8c12 -- game.jsこれで game.js だけがコミット a3f8c12 の状態に戻ります。他のファイルはそのままです。内容を確認してから git commit で新たに記録します。
3. プロジェクト全体を過去の状態で確認する
全ファイルを過去の状態でまとめて確認したい場合は、新しいブランチを切って確認する方法が安全です。
git checkout -b restore-test a3f8c12restore-test という名前のブランチが a3f8c12 の状態で作られます。ブラウザで動作を確認し、この内容を使いたければ main ブランチにマージするか、そのままファイルをコピーします。確認だけで終わるなら git checkout main で元に戻ります。
上記のコマンド例は説明のためのものです。Git 2.23以降では git checkout の代わりに git restore や git switch を使うことも公式に推奨されています。実際の操作前にGit公式ドキュメントで最新の構文を確認してください。
ローカルの版管理と公開作品の更新を切り離す
版管理ができていても、「手元で試している途中の状態を、うっかり公開してしまった」では意味が薄れます。ここでは、ローカルでの作業と公開作品の更新を区別するための考え方を整理します。
公開はいつでも「意図的な操作」にするというのが基本の方針です。アソバースへの投稿はHTMLファイルやZIPファイルのアップロード、または公開済みURLの登録によって行います。手元のファイルを変えても、アップロード操作をしない限り公開中の作品は変わりません。この仕組みを利用して、次のような流れを作ると安全です。
- 手元でコードを修正し、ブラウザで動作を確認する
- 問題がなければGitでコミットして履歴に記録する
- 「この版を公開してよい」と判断してからアップロードまたはURLを更新する
特に、AIに修正を頼んだ直後はブラウザで全体を通してプレイし直すことを勧めます。意図した変更以外に別の箇所が壊れていないかを確かめてからコミットし、さらに確かめてから公開する——この二段階の確認が、プレイヤーへの影響を最小にします。
GitHubなどのリモートリポジトリを使えば、ローカルとは別の場所にも履歴のバックアップが持てます。ただしリポジトリの公開設定には注意が必要です。未発表のゲームのソースコードを意図せず公開しないよう、プライベートリポジトリの設定を確認してから使いましょう。
すぐ使えるコミットメッセージのテンプレートと習慣のつくり方
コミットメッセージを書くのが面倒で習慣が途切れる、という場合は、次のようなシンプルなテンプレートを使うと続けやすくなります。AIとの作業ログとしても後から読み返せる形式です。
[確認済み] ステージ1クリア後の遷移が正常に動作
[バックアップ] 衝突判定をAIに修正依頼する前
[AI修正] 衝突判定のバグを修正 - 斜め方向を追加
[作業中] スコアボード実装中、表示は未完成角括弧のタグは自由に決めて構いません。「確認済み」「バックアップ」「作業中」など、状態がひと目でわかる言葉を使うと、git log --oneline の一覧から戻りたい版を探しやすくなります。
履歴の管理に慣れてきたら、機能ごとにブランチを作る方法も検討できます。「スコア機能を試す専用ブランチ」を作れば、実験が失敗しても main ブランチの動く版には一切影響しません。ただしブランチ管理はそれ自体に学習コストがあるため、まずはコミットを積み上げる習慣から始めるのが現実的です。
AIと制作するスピードの速さは魅力ですが、「動く版を記録してから次へ進む」習慣が、制作の積み上げを確かなものにします。手元で復元できる状態を作ったうえで公開作品を更新する——この順番を守るだけで、AIとの制作は一段と安定します。
