AIに機能を足してもらう前に：既存の遊びを壊さない変更の頼み方
遊びをつくる執筆にClaudeを使用しています。
「スコアボードを追加してほしい」と頼んだら、それまで動いていた当たり判定がおかしくなった。「サウンドをオフにできるボタンを足したい」と伝えると、ステージ遷移が途中で止まるようになった。AIにコードの変更を依頼するとき、こういった「別の場所が壊れる」問題はよく起きます。原因のほとんどは依頼文にあります。AIは依頼されたことを実行しますが、あなたが「触ってほしくない部分」を知らないからです。この記事では、既存の遊びを壊さずに機能を追加するための依頼の組み立て方と、変更後の確認手順を整理します。
この記事の目次
なぜ機能追加で別の場所が壊れるのか
AIはコードの「意図」ではなく「構造」を読みます。「このフラグはゲームオーバー判定に使っている」という文脈が依頼文にないと、同名の変数を別の目的で再利用したり、既存の関数を内部から書き換えたりすることがあります。特にグローバル変数が多いゲームや、イベントリスナーが複数の役割を兼ねているコードでは、一箇所の変更が想定外の経路で波及します。
もう一つの原因は、依頼の粒度が大きすぎることです。「ハイスコアを保存できるようにして」という依頼は、AIにとって「localStorageを使う」「スコア変数を増やす」「表示UIを追加する」「既存のスコア更新ロジックを変える」など、複数の解釈が同時に成立します。どこまで変えてよいかを示さなければ、AIは合理的と判断した範囲で自由に書き換えます。依頼の「広さ」がそのまま「壊れやすさ」に直結するのです。
変更前に「守る挙動リスト」を書く
依頼文を書く前に、今のゲームで「正しく動いていること」を自分でリストアップします。これを守る挙動リストと呼ぶことにします。機能追加の後でも同じように動いてほしい項目を、操作と結果のセットで書くのがポイントです。
- ゲームスタート時にカウントダウンが3秒表示され、その間は操作を受け付けない
- プレイヤーが画面外に出ると即座にゲームオーバーになる
- スコアは敵を倒すたびに10ずつ加算され、画面右上に表示される
- BGMはページを開いた瞬間ではなく、スタートボタンを押した後に始まる
項目は3〜10個程度が現実的です。「全部ちゃんと動く」は守る挙動の記述になりません。「何をしたとき、何が起きるか」という形式で書くと、後で確認するときにも使えます。このリストは依頼文の中に直接貼り込みます。
AIへの依頼文：変更範囲と制約を明記するテンプレート
効果的な依頼文は「追加したいこと」「触ってよい範囲」「触ってはいけない範囲」「守る挙動」の4要素で構成します。以下はそのテンプレートです。ゲームオーバー時のスコア比較画面を追加する例を示しています。
## 追加したい機能
ゲームオーバー時に、今回のスコアと過去最高スコアを比較して表示する画面を追加したい。
## 変更してよいファイル・関数
- game.js の gameOver() 関数の中
- index.html の #gameover-screen 要素（存在しない場合は追加可）
## 変更してはいけない部分
- スコアの加算ロジック（updateScore 関数）には手を付けない
- BGMや効果音の再生・停止ロジックは変えない
- グローバル変数 score 以外の既存変数の名前や型を変えない
## 守る挙動（変更後も同じであること）
1. ゲーム中のスコアは敵を倒すたびに10加算され、#score要素に即時反映される
2. ゲームオーバー判定は現在のままで変えない
3. スタートボタンを押すとスコアが0にリセットされる「変更してはいけない部分」を書くのが最も重要です。ここが空欄だと、AIはコードをリファクタリングする形で依頼を解釈することがあります。関数名・変数名・HTML要素のIDなど、具体的な識別子で指定すると誤解が減ります。
コードを貼り付けるときは、関連する部分だけを抜粋する方が精度が上がることがあります。ファイル全体を渡す場合は「以下のコードのうち、gameOver関数だけを変更してください」と範囲を絞ることを検討してください。
差分を読む：AIが変えた場所を自分で確認する
AIから返ってきたコードをそのまま貼り付ける前に、変更された箇所を自分で確認します。変更前後のコードを並べて「守る挙動リスト」の関連部分が残っているかをチェックするのが基本です。
差分を読むときに注目する点は3つあります。まず、「触ってはいけない」と指定した関数・変数が変わっていないか。次に、新しく追加されたグローバル変数や関数名が既存のものと衝突していないか。最後に、既存のイベントリスナーが削除・上書きされていないかです。特にイベントリスナーは「addEventListener で追加」と「既存の onclick を書き換え」の違いが見落としやすく、複数の処理が同じ要素に登録されていた場合に動作が変わります。
差分を読んで疑問が生じたときは、「○○関数の変更意図を教えてください」と追加で質問します。AIに変更理由を説明させると、意図しない書き換えに気づきやすくなります。
回帰確認：守る挙動リストを使って動作を確かめる
コードを差し替えたら、変更前に書いた守る挙動リストを上から順に実際の画面で確認します。「読んだだけで問題なさそう」では不十分で、ブラウザで動かしながら一項目ずつ操作して結果を見ます。
- 更新後のファイルをローカルまたはテスト環境で開く
- 守る挙動リストの項目を1番から順に、実際に操作して結果を確認する
- 今回追加した機能を動作確認する（ゲームオーバー画面の表示、スコア比較の正確さなど）
- エラーコンソール（ブラウザの開発者ツール > Console）を開き、赤いエラーが出ていないか確認する
- 問題があれば「以下の挙動が壊れました：〇〇。変更前のコードを確認してください」と具体的に伝えて再依頼する
回帰確認は一度で終わらないことも普通です。修正のたびに守る挙動リストを再確認する習慣をつけると、「直したつもりが別の場所を壊した」という連鎖を早い段階で止めやすくなります。
アソバースへの投稿はHTMLファイルやZIPファイルのアップロード、または公開済みURLの登録によって行います。ローカルで回帰確認を済ませてから投稿すると、公開後に「遊べなくなった」という状況を避けやすくなります。
変更を小さく分けて、確認しながら進める
機能追加が複数あるとき、まとめて頼むと差分が大きくなり、どこで何が壊れたかの切り分けが難しくなります。「一度に一つの機能だけ追加する」「追加→確認→次の追加」という順序を守ると、問題の原因が特定しやすくなります。
一つの依頼で変更するファイルは一つを目安にするのも有効です。複数ファイルをまたぐ変更を一度に依頼すると、整合性の確認がAI任せになります。たとえば「UIの追加はindex.htmlだけ」「ロジックの変更はgame.jsだけ」と分けて依頼し、それぞれで守る挙動を確認してから次へ進む方が安全です。
変更前のコードを手元に保存しておくことも重要です。うまくいっているバージョンをファイルとして手元に残しておくと、何かあったときに「この状態まで戻す」という判断ができます。Gitなどのバージョン管理ツールを使っていない場合でも、ファイルをコピーして日付付きのファイル名で保存するだけで、手戻りのコストが下がります。
守る挙動リストと依頼テンプレートは、一度作ってしまえば次の機能追加でも再利用できます。依頼の形式が安定すると、AIの回答のパターンも読みやすくなり、差分確認にかかる時間が短くなっていきます。
この記事の本文はClaude（Anthropic）が執筆しています。記載している手順は一般的なコード変更管理の考え方をもとにした説明であり、特定のAIツールや環境での動作を実測・検証したものではありません。人間による取材や個別の動作確認は行っていません。
