AI アシスタントがゲームに加えた変更は、残す前にどう確認すればいいですか？

変更されたファイルをタスクと見比べ、diff を削除部分から読み、確認を自分で実行し、変更箇所を遊んでから、初めてコミットします。

次の四つを、この順番で見ます。どのファイルが変わったか、diff が何を消して何を加えたか、確認を自分で実行したときに何が出るか、そして変更が入った場所が遊んでみてどうか。四つすべてが頼んだ内容と合っているときだけ変更を残し、コミットとして残します。どれか一つでも合わなければ、変更を取り消し、よりよいタスクで頼み直します。アシスタントの報告はどこを見ればよいかを教えてくれますが、それ自体は確認ではありません。

なぜ「完了しました」では足りないのですか？

それは主張であり、証拠は変更そのものだからです。アシスタントは、コードがビルドできることしか確かめていないのに機能が動くと言うことがありますし、ファイルを一つ触っただけと言いながら、実行したコマンドが三つ書き換えていることもあります。

その一部はエディターではまったく見えません。Visual Studio Code の AI による編集の確認のページには、保留中の編集はすでにディスクに保存されていること、ターミナルのコマンドやスクリプトで行われた変更は編集の一覧に出ないこと、チェックポイントはターミナルのコマンドやデプロイを元に戻さないことが書かれています。2026 年 10 月 29 日に読んだ内容で、最終更新は 10 月 21 日でした。どのツールを使っていても、頼れるのはバージョン管理が見せる景色です。つまり、前回のコミットと違うすべてのファイルです。

だから最初の一歩は、アシスタントが始める前にあります。動くバージョンをコミットとして保存しておくことです。それがなければ、変更を比べる相手も、戻る場所もありません。

最初に何を見ますか？

変更されたファイルの一覧です。二つのコマンドで出せます。

git status
git diff --stat

git status は変更されたファイルと新しいファイルをすべて挙げます。git diff --stat は、それぞれのファイルで何行増えて何行減ったかを加えます。git diff だけでは、新しく作られてまだ Git に追加されていないファイルは表示されません。git status には表示されるので、両方を読んでください。

次に、一覧をタスクと見比べます。変更をどこに入れ、何を変えてはいけないかを書いたタスクを書いていれば、数秒で済みます。

どれもそれだけで間違いとは限りません。ただ、どれも確認するつもりのなかったものなので、先に見ます。

プログラマーでなくても diff は読めますか？

消された行（赤、- 付き）と加えられた行（緑、+ 付き）の一覧として読み、消された行から始めます。消えた一行は最も見落としやすく、遊んでいても最も気づきにくい変更です。プレイヤーが壁をすり抜けないようにしていたチェック、スコアのリセット、空のセーブへの備えなどです。

それから、言語を知らなくても見つけやすいパターンをいくつか探します。

• 変わった数値：速さ、残機、タイマー、価格。どれもタスクに書かれているはずです。
• コメントに変えられたコード、あるいはまるごと消されて別の場所に書き直されたブロック。
• 古い関数に似た新しい関数：同じ仕事が二度行われ、二つのコピーはやがてずれていきます。
• プレイヤーが見る文字：メニュー、ヒント、エラーメッセージ。まだ正しく、正しい場所にありますか？

読めない行があれば、それが何をしていて、何から呼ばれるのかをアシスタントに聞きます。聞くのにコストはかかりませんし、コードと合わない答えが返ってくれば、それ自体が発見です。

どの確認を自分で実行しますか？

タスクで指定したものを、報告で済ませずに自分で実行します。タスクでテストを求めたなら、テストを実行して結果を読みます。エラーなしでページが読み込まれることを求めたなら、ブラウザーのコンソールを開いた状態でゲームを開きます。自分の目で通るのを見た確認は、「通りました」という一文より重みがあります。

緑のテストが証明するのは、そのテストが調べることだけです。同じ diff の中でテストのファイルが変わっていたら、その部分を読みます。リスタート後にスコア 0 を期待していたテストが、今はコードが返す値をそのまま期待しているなら、もう何も確かめていません。

変更を残す前に何を遊びますか？

まず変更そのものを、タスクに書いたとおりに。次に、ゲームの残りを短いルートで回ります。毎回同じルートです。一か所の変更が別の場所を壊すことはよくあるからです。

1. 新しく開いたページからゲームを始める。
2. すべての操作を一度ずつ使う。キーボードで、ゲームにタッチ操作があればスマートフォンでも。
3. ポーズ、負け、リスタート。
4. セーブ、ページの再読み込み、ロード。

このルートは数分で終わり、テストがめったに拾わないものを捕まえます。反応しなくなったボタン、抜けられない画面、戻ってこないセーブです。変更でキーや画面が増えたなら、タッチでも動くか確かめます。KittenGalaxy にタッチ操作を加えて以来、私たちが守っているルールです。

変更を残すには、または捨てるにはどうしますか？

残すなら、プレイヤーの言葉で何が変わったかを書いたメッセージを付けてコミットします。「ウェーブごとに 10% 速く、最大で開始速度の 2 倍まで」のように。一つのタスクに一つのコミット。後で何かが壊れたとき、どの変更が原因かを見つけ、それだけを取り消せます。

捨てるなら、前回のコミットに戻ります。Git では、git restore . が、Git がすでに追跡しているファイルを前回のコミットの状態に戻します。ただし変更が git add でステージされていない場合です。アシスタントが新しく作ったファイルはこのコマンドでは消えないので、もう一度 git status を見て手で削除します。独自の取り消しやチェックポイントを持つエディターでも、説明されている範囲内で同じことができます。そのうえで、よりよいタスクを書きます。何がうまくいかなかったかを書き、それを捕まえられたはずの確認を加えます。

ほぼ正しい変更を残し、残りは次のタスクで直したくなるものです。そうするのは、何が間違っているかを言葉にでき、それが小さいときだけにします。理解できない変更は、次の変更がその上に積まれても理解しやすくはなりません。アシスタントと作るゲームはこうして手に負えなくなります。だからこそ、小さな最初のゲームのほうが動く状態を保ちやすいのです。

別の AI に確認を任せられますか？

diff を一緒に読むことはできます。行を説明し、消されたチェックを指摘し、新しい関数が何のためにあるのかを尋ねてくれます。コードを読まない人には特に助けになります。けれども、ゲームがまだあなたの望むことをしているかどうかは判断できません。それを知っているのはあなただけですし、代わりに遊ぶこともできません。二人目の読み手として使い、承認の代わりには決して使わないでください。

よくある質問

確認にはどれくらい時間をかけるべきですか？ 変更が小さければ、そのぶん短く済みます。diff を読むのにタスクを書くより時間がかかるなら、タスクが大きすぎたのでしょう。次は分けてください。

このために Git は必要ですか？ 何が変わったかを見て、元に戻せる手段が必要です。Git が一般的な手段で、無料です。ほとんどのエディターやアシスタントが Git と一緒に動きます。

変更は正しいのに、コードが散らかって見えたら？ 動いていて理解できるなら残し、片付けは別のタスクにして、同じ確認を付けます。片付けを新機能の変更に混ぜないでください。

画像、音、ステージのファイルの変更も確認しますか？ はい。diff を読むのではなく、見て遊んで確認します。どれを見ればよいかは、変更されたファイルの一覧が教えてくれます。

ほかの人に遊んでもらえるのはいつですか？ 上のルートが新しいページで通り、知らない人があなたの助けなしでゲームを最後まで遊べるときです。そうなったら HeapPlay に投稿できます。