結論(ループを抜ける具体的な指示)
「治りません。修正に仕様変更が必須と感じる場合は、パターンを挙げて下さい。仕様変更が必須でないと感じる場合は、仕様変更せずに治せそうである事を教えて下さい」
を指示した後に
「これらの中から必要と思う仕様変更を加えて修正して下さい。また、このチャットで発生したコードの中で不要なコードは削除して下さい。」
を指示する。
前書き
AIでコードの修正作業をしていると、
「〇〇のバグを修正してください」
と何度依頼しても、なかなか治らないことがあります。
経験則ですが、AIは既存コードへの影響を避けるため、できるだけ仕様変更をせずに直そうとする傾向があるように感じます。
これは普段は非常にありがたいのですが、バグの原因そのものが既存仕様にある場合は、不利に働くことがあります。
例えばの話
例えば、次のような状態です。
- 既存仕様と、求めている修正内容が競合している
- 既存仕様を維持したままでは修正が難しい、あるいは不可能
- 修正のために一部の仕様変更が必要
- AIは既存仕様をできるだけ維持したまま修正しようとする
- 「修正してください」という依頼に対して結果を返そうとするため、「仕様変更が必要です」と提案する方向に進みにくい
- 必要な仕様変更を勝手に行うことも避けようとする
- 既存仕様の範囲内で修正を繰り返し、いつまでも問題が解決しない
このような状態が、「何度修正を依頼しても治らない」状況が続く理由の一つではないかと考えています。
ループを抜ける具体的な指示
何度か修正しても治らない場合に、まず次のように聞いています。
治りません。修正に仕様変更が必須と感じる場合は、パターンを挙げて下さい。仕様変更が必須でないと感じる場合は、仕様変更せずに治せそうである事を教えて下さい
すると、単純なコード修正だけでなく、仕様を変える場合の候補も出してくれます。
その後、
これらの中から必要と思う仕様変更を加えて修正して下さい。また、このチャットで発生したコードの中で不要なコードは削除して下さい。
と依頼します。
この2段階にすると、既存仕様を守ることより、問題そのものを解決することを優先してもらいやすくなる印象があります。
あくまで経験則ですが、AIで何度修正しても同じバグが残る場合は、「修正方法」ではなく「仕様変更の候補」を一度聞いてみるのも有効そうです。
下記のカスタム指示も刺さる事があるかもしれません。
If hard to fix, propose spec changes instead of coding.
If the bug cannot be fixed while preserving the current specification, explain why and propose minimal specification changes before coding.