AIの修正案を採用してよい？ゲームで確かめる受け入れ条件

受け入れ条件とは何か

ソフトウェア開発の文脈では、ある変更を「完了した」と判断するために満たすべき基準を受け入れ条件（acceptance criteria）と呼びます。簡単に言えば、「これが確認できたら修正を採用する」と事前に決めておく条件の一覧です。

ゲーム制作でこれが重要になる理由は、不具合の多くが「特定の操作手順のときだけ」「特定の状態のときだけ」「2回目以降のプレイでだけ」再現するからです。一度うまく動いたように見えても、それが「すべての条件で直った」ことを意味するわけではありません。

AIに修正を頼む場合、AIは「問題の記述」と「コードの文脈」をもとにロジックを推論して案を出します。ゲームを実際に起動して操作した結果ではないため、提示された修正案が本当に問題を解消しているかどうかは、制作者がゲームを動かして確認しなければわかりません。受け入れ条件を先に決めておくことで、「何を確認すれば採用を判断できるか」が明確になります。

確認の4つの角度：正常・終了・再起動・境界値

修正を評価するとき、「一度動かして問題が出なければOK」という確認は不十分です。ゲームの状態変化を考えると、少なくとも次の4つの角度から確認することが有効です。

① 正常動作の確認

最も基本的な確認です。修正前に再現していた問題が、修正後の通常の操作手順で発生しなくなっているかを確かめます。ここだけ確認して終わりにするケースが多いのですが、これは出発点であって終点ではありません。

② 終了時・完了時の確認

ゲームが「終わる」瞬間——ゲームオーバー画面の表示、ステージクリアの処理、タイムアップによる強制終了——など、通常プレイとは別の終了経路を一通り試します。スコア集計、状態のリセット、次のステージへの遷移などはゲームの終了時に起きるため、修正の影響が出やすい場所です。

③ 再起動・リトライの確認

ゲームを1回終了して、もう一度最初からプレイしたとき、前の状態が正しく消えているかを確認します。変数の初期化漏れや、前のゲームのデータが残ったまま2回目が始まる問題は、このタイミングで現れます。「2回目以降だけ問題が出る」という報告の多くはここに原因があります。

④ 境界値の確認

ゲームの設計上の「端」を試します。スコアが0のとき、残機が1のとき、最後のステージ、所持できる最大数のアイテム、タイマーが0になった直後——こうした極端な値や状態のときに修正が正しく機能するかを確認します。境界値の付近でロジックが変わることが多く、通常の操作では気づかない問題が潜んでいます。

受け入れ条件テンプレート

AIに修正を依頼する前か依頼した直後に、次のテンプレートを埋めておくことを勧めます。テンプレートの目的は「修正後に何を確認するか」を自分が決めることです。AIにこのテンプレートを埋めさせることもできますが、最終的にゲームで確認するのは制作者です。

このテンプレートはAI生成コードに限らず、自分自身が書いたコードの修正にも使えます。テキストファイルやコメントとして残しておくと、後で同じ場所を修正するときの手がかりになります。

テンプレートの項目

1. 問題の記述：どの操作手順でどの問題が起きるか、1〜3文で書く。
2. 正常動作の条件：修正後に期待する動作を「〇〇したとき、〇〇になる」の形で書く。
3. 終了・完了の確認：ゲームオーバー、クリア、強制終了などの終了経路を列挙し、それぞれの期待結果を書く。
4. 再起動の確認：1回終了してリトライしたとき、前の状態が引き継がれていないことを確認する手順を書く。
5. 境界値の一覧：スコア0・残機1・最大値など、確認すべき極端な状態を箇条書きにする。
6. 壊れていないことの確認：修正した箇所に隣接する機能が引き続き動いているかを確認する項目を1〜3個書く。

6番目の「壊れていないことの確認」は見落とされがちです。AIの修正は問題の箇所を直す一方で、そのコードに依存していた別の部分を壊すことがあります。修正前後で隣接する機能も動かして確かめることで、このリスクを小さくできます。

具体例：スコア加算の不具合に適用する

「アイテムを取得したときにスコアが加算されない」という不具合を例に、テンプレートの使い方を説明します。この例は実際のゲームの計測結果ではなく、制作者が遭遇しやすいパターンを一般化したものです。

問題の記述

プレイヤーがアイテムに触れたとき、画面上のスコア表示が変化しない。コンソールにはエラーが出ていないが、スコアの値が0のまま変わらない。

受け入れ条件の例

• 正常動作：アイテムに触れた直後、スコア表示が設定した点数分だけ増える。
• 終了時：ゲームオーバー画面で表示されるスコアが、プレイ中の表示と一致する。
• 再起動：リトライ後の最初の状態でスコアが0に戻っている。前回取得したアイテムの状態が残っていない。
• 境界値：スコアが0の状態でアイテムを取得したとき、表示が正しく変化する。最大スコアに近い状態で取得したとき、表示が正しく処理される。
• 隣接機能：スコアに関係しない当たり判定（障害物との衝突など）が引き続き正しく動いている。

このリストをAIに修正案と一緒に渡すこともできます。「以下の受け入れ条件をすべて満たす修正を提案してください」と添えると、AIが見落としやすい再起動時や境界値を意識した案が返ってくることがあります。ただし、AIが「条件をすべて満たしています」と答えたとしても、実際にゲームを動かして確認することが必要なのは変わりません。

採用しない判断をするとき

受け入れ条件を確認していて、修正案を採用しない方がよい場面があります。主に次のケースです。

• 別の問題が現れた：修正対象の問題は直ったが、隣接する機能が壊れた場合。このときはAIに「この修正を適用したところ、〇〇という別の問題が起きました」と具体的に伝えて再提案を求めるか、自分でロールバックして原因を絞り込む。
• 何が変わったかわからない：AIから返ってきた修正量が多すぎて、どの変更が問題を解決したのか判断できない場合。一度に大きな変更を受け入れると後の追跡が難しくなるため、「最小限の変更で提案してください」と依頼し直す。
• 受け入れ条件のいずれかを満たさない：境界値や再起動で問題が再現する場合。このとき「正常動作のケースは直りましたが、〇〇の条件では△△という問題が残っています」とAIに伝えることで、残っている問題に絞った次の修正案を引き出せます。

AIとのやりとりは一回で完結することは多くなく、確認と再提案の繰り返しになります。受け入れ条件を持っていると、「まだ満たしていない条件は〇〇だ」という形で次の依頼を具体化でき、やりとりの精度が上がります。

受け入れ条件を通した修正を、ゲームに反映する

受け入れ条件の考え方は、AIを使うかどうかに関係なく、自分でコードを修正するときにも同じように使えます。重要なのは「正常動作を一度確認して終わり」ではなく、終了・再起動・境界値という、問題が隠れやすい3つの確認を毎回意識することです。

特に、ゲームを2回以上プレイする人には必ず「再起動後の確認」が影響します。アソバースに投稿されるゲームはブラウザで動作するため、ページのリロードや再訪問が「再起動」に相当します。投稿前に、ページをリロードしてもう一度プレイするという確認を加えるだけで、再起動に関連する問題を公開前に発見できることがあります。

修正後の確認が終わったら、受け入れ条件のリストをコメントや作業メモとして残しておくことを勧めます。後で同じ箇所を変更するとき、何を確認すればよいかがすぐわかります。AIへの次の依頼文にもそのまま使えます。

AIが出した修正案の採用判断は、制作者が行います。「直った」という説明は出発点として使い、受け入れ条件を通したうえで採用する——その習慣を積み重ねることで、AIとのやりとりがゲームの品質向上に結びつくようになります。