AIに既存コードを壊させない指示：変更範囲を限定する言い方
遊びをつくる執筆にClaudeを使用しています。
AIにコードの修正を頼んだら、動いていた別の部分まで書き換えられてしまった――そういう経験は、AIを使ってゲームを作っていると一度は起きます。「スコア表示を直して」と伝えただけなのに、衝突判定のロジックまで「改善」されて、動作がおかしくなる。原因はコードにあるのではなく、AIへの指示に変更範囲を伝えていなかったことにあります。 AIはプロンプトに書かれていない情報を文脈から推測します。「直して」という言葉は、AIにとって「よりよくする余地があれば全体を整えてよい」と読めることがあります。変更してほしい場所と、絶対に触れてほしくない場所を明示しなければ、AIは善意で余計な最適化を加えます。 この記事では、変更範囲を限定するための具体的な言い方と、その判断基準を整理します。ゲームのHTMLやJavaScriptを題材にしていますが、考え方はどんなコードにも使えます。
なぜAIはコードを「勝手に」書き換えるのか
AIがコードの複数箇所を変えてしまう背景には、「コード全体を一つの文脈として読む」という動作原理があります。あなたが「スコアの計算がおかしい」と伝えると、AIはスコアに関係しそうな変数、関数、イベントリスナーをすべて候補として検討します。そのうえで「ここも変えた方が整合性が取れる」と判断したとき、指示されていない箇所まで手を入れます。
特に起きやすいのは次の三つの場面です。一つ目はリファクタリング（コードの整理）を兼ねて修正するとき。二つ目は変数名や関数名を変更するとき（使っている全箇所を自動で直そうとする）。三つ目はバグ修正の過程で「根本的に書き直した方が早い」と判断したとき。どれも悪意ではなく、AIが「良い結果を出そうとした」結果です。ただ、作業中のコードには「今は触れたくない未完成の部分」や「意図的に残している特殊な処理」があるため、善意の書き換えが壊滅的なデバッグコストを生みます。
変更範囲を限定する五つの言い方
1. 「この関数だけ」と対象を関数単位で指定する
updateScore() 関数だけを修正してください。
それ以外の関数には一切手を加えないでください。関数名を明示することで、AIの注意を一点に絞ります。「一切手を加えない」という否定形の明示が重要で、「できるだけ変えないで」という曖昧な表現より効果的です。
2. 変えてよい行番号・ブロックを伝える
コードを貼り付けるとき、対象の行に // ←ここだけ変えてよい とコメントを添えてから渡す方法があります。AIはコメントを指示として読むため、マーカーとして機能します。変更後にコメントを削除するよう合わせて伝えておくと、出力がきれいになります。
3. 「出力は変更した部分だけ返して」と要求する
コード全体を出力させると、変わった箇所と変わっていない箇所の差分が見えにくくなります。
変更した関数だけをコードブロックで返してください。
ファイル全体は出力しないでください。この指示には副次的な効果があります。AIが全体を出力しようとするとき、変更範囲が広がりすぎていることが多いため、「変更箇所だけ返す」という制約が自然にスコープを絞る圧力になります。
4. 「壊れていない部分」を明示的に保護する
触れてほしくない処理がある場合は、その名前を列挙して保護を宣言します。
collision() と draw() は現在正常に動作しています。
これらには絶対に手を加えないでください。
今回の修正対象は spawnEnemy() のみです。「正常に動作している」という言葉を添えると、AIが「改善の余地がある」と判断して介入する動機を取り除けます。
5. 変更の理由を一行で添える
なぜその箇所だけを変えるのかを短く説明すると、AIが文脈から不要な推論をしにくくなります。
敵の出現間隔が難易度に関係なく固定されているバグがあります。
spawnEnemy() 内の interval の値を難易度変数に連動させてください。
それ以外の敵の動きや当たり判定のロジックは変更しないでください。「なぜこの関数だけか」が伝わると、AIは余計な整合性調整をしなくなります。
指示が機能しているか確認する方法
変更範囲を限定する指示を出しても、AIが意図通りに動いたかを確認しないと意味がありません。確認には次の手順が有効です。
- 差分を先に聞く：コードを受け取る前に「何を変えましたか？変更した箇所をリストで教えてください」と質問します。予想より多い箇所が挙がったら、コードを適用する前に追加の制約を伝えて再生成できます。
- git などのバージョン管理を使う：変更前のコードをコミットしておくと、AIが何を変えたかをgit diffで一目で確認できます。バージョン管理を導入していない場合は、変更前のファイルを別名でコピーしておくだけでも十分です。
- 同じ指示を二回試して結果を比べる：AIの出力は確率的にばらつくことがあるため、同じプロンプトでも別のセッションで試すと別の箇所が変わることがあります。重要な修正は一度で信頼しきらず、同じ指示を試して挙動が安定しているか見ます。
失敗しやすい指示のパターンと修正例
「バグを直して」だけ伝える：これはAIに全権を委任する指示です。AIはバグの原因を特定するために関連するコードを広く読み、「まとめて直した方が効率的」と判断しがちです。修正例は「〇〇関数で△△が起きるバグを、その関数内だけで修正してください」です。
「リファクタリングしながら直して」と頼む：リファクタリングと機能修正を同時に頼むと、変更範囲の定義が崩れます。修正してから整理する、または整理してから修正する、という順序に分けてください。
コードの一部だけを貼ってコンテキストが欠ける：該当関数だけを渡すと、AIは欠けている部分を補完しようとして、存在しない変数や関数を作り出すことがあります。依存関係のある変数や関数の定義は一緒に渡し、「この部分は参照用なので変更不要です」と明示します。
「なるべく変えないで」という曖昧な程度の表現：「なるべく」はAIに判断の裁量を与えます。「〇〇以外は変更禁止」という禁止形の方が範囲を絞れます。
次の行動
次にAIへコードの修正を依頼するときは、「何を変えるか」と同時に「何を変えないか」を箇条書きで一行ずつ書いてみてください。コードを受け取る前に変更箇所のリストを確認する習慣をつけると、想定外の書き換えに気づくタイミングを早められます。HTMLゲームをアソバースへ投稿する前の最終確認にも、この差分チェックの手順はそのまま使えます。
