はじめに
こんにちは！
AIを使ってコードを修正していると、
「このバグを修正して」とだけお願いしてしまうこと、ありませんか？
特に急いでいると、
期待する動作や制約を細かく伝えないまま、
抽象的な指示だけで修正をお願いしてしまいがちですよね。
では、同じコードに同じ指示を何回も出した場合、
AIは毎回同じ修正をしてくれるのでしょうか？
また、期待する動作や制約を伝えると、修正結果は変わるのでしょうか？
今回は、これを実際に検証してみることにしました！
今回の記事
今回は、バグを含んだリトライ処理のファイルを用意して、
以下の2パターンで修正結果を比較します。
- 「バグを修正して」という抽象的な指示
- 期待する動作・制約・完了条件を指定した指示
抽象的な指示は同じ条件で2回実行し、同じ指示でも修正内容に違いが出るのかも確認します。
検証環境
今回の検証では、以下の環境を使用しました。
- Python 3.13
- GPT-5.6 Luna
- 推論強度：max
モデルによって出力結果は変わるため、今回の結果がすべてのAIに当てはまるとは限りません。
今回はモデルと推論強度を固定し、指示内容だけを変えて比較します。
また、リポジトリは作成せず、検証用のファイルを毎回同じ状態から開始しました。
検証用のファイル
今回は、外部通信なしで確認できるリトライ処理を題材にしました。
buggy_retry.py
import time
from collections.abc import Callable
from typing import TypeVar
T = TypeVar("T")
class HttpError(Exception):
def __init__(self, status_code: int) -> None:
self.status_code = status_code
super().__init__(f"HTTP {status_code}")
def call_with_retry(
operation: Callable[[], T],
max_attempts: int = 3,
) -> T:
"""外部APIを呼び出し、失敗した場合は最大3回まで再試行する。"""
for attempt in range(max_attempts + 1):
try:
return operation()
except (HttpError, TimeoutError) as error:
if isinstance(error, HttpError) and error.status_code < 500:
raise
time.sleep(2**attempt)
raise RuntimeError("operation failed")
一見すると動きそうですが、今回は以下の問題を含めています。
- 最大試行回数が1回多い
- HTTP 429をリトライしない
- 最終試行後にも待機する
- 最後に発生した例外をそのまま返さない
評価方法
修正後のファイルに対して、別ファイルの評価用テストを実行しました。
評価用テストは、AIには見せずに修正結果の確認だけに使用しています。
確認したケースは以下です。
| ケース | 期待する結果 |
|---|---|
| 1回目で成功 | 1回だけ実行する |
| 500エラー後に成功 | リトライして成功する |
| 429エラー後に成功 | リトライして成功する |
| 400エラー | リトライせず、元の例外を返す |
| 3回連続で失敗 | 3回で終了し、最後の例外を返す |
| TimeoutError後に成功 | リトライして成功する |
まずは抽象的な指示で修正してみる
最初は、よくやってしまいがちな指示を出してみます。
buggy_retry.pyのバグを修正してください。
この指示を、元のファイルに対して2回実行しました。
1回目の修正結果
1回目は、以下の修正が行われました。
- for attempt in range(max_attempts + 1):
+ for attempt in range(max_attempts):
- time.sleep(2**attempt)
+ if attempt < max_attempts - 1:
+ time.sleep(2**attempt)
最大試行回数と、最終試行後の待機は修正されました。
しかし、429はリトライされず、すべて失敗した場合はRuntimeErrorに置き換えられたままでした。
テスト結果は、6ケース中4ケース通過でした。
2回目の修正結果
2回目も最大試行回数は修正されました。
さらに、最終試行時に元の例外を再送出する修正も行われました。
if attempt == max_attempts - 1:
raise
ただし、こちらも429の扱いは修正されませんでした。
テスト結果は、6ケース中5ケース通過でした。
同じ指示でも、修正された箇所と修正されなかった箇所に違いが出ました。
期待する動作・制約・完了条件を指定してみる
次に、修正してほしい内容を具体的に指定します。
buggy_retry.pyを以下の仕様を満たすように修正してください。
【目的】
外部APIのリトライ処理を正しくする。
【期待する動作】
- 初回実行を含めて最大3回まで実行する
- HTTP 429と500系エラーはリトライする
- 400系エラー（429を除く）はリトライせず、元の例外を返す
- TimeoutErrorはリトライする
- 最終試行後には待機しない
- すべて失敗した場合は、最後に発生した例外をそのまま返す
【制約】
- 関数の公開インターフェースは変更しない
- 外部ライブラリは追加しない
- 待機時間の計算方法は基本的に維持する
【完了条件】
- 上記の期待する動作をすべて満たすこと
- 不要なファイルを変更しないこと
修正結果
今回は、以下のような修正が行われました。
for attempt in range(max_attempts):
try:
return operation()
except (HttpError, TimeoutError) as error:
should_retry = isinstance(error, TimeoutError) or (
isinstance(error, HttpError)
and (error.status_code == 429 or 500 <= error.status_code < 600)
)
if not should_retry or attempt == max_attempts - 1:
raise
time.sleep(2**attempt)
期待した条件がすべて反映され、評価用テストは6ケース中6ケース通過しました。
結果を比較してみる
| 指示 | 結果 | 修正されなかった内容 |
|---|---|---|
| バグを修正して（1回目） | 4/6ケース通過 | 429、最終例外の扱い |
| バグを修正して（2回目） | 5/6ケース通過 | 429 |
| 条件を指定して修正して | 6/6ケース通過 | なし |
なるほど!
同じ「バグを修正して」という指示でも、AIがどの問題をバグとして判断するかに違いが出ました。
1回目は最終試行後の待機を修正しましたが、最終例外はそのままでした。
2回目は最終例外を修正しましたが、429については考慮されませんでした。
これは、元のコードだけでは「429もリトライ対象にする」「最後の例外を維持する」といった仕様が明確になっていなかったためだと考えられます。
なぜ指示によって結果が変わったのか
抽象的な指示の場合、AIは不足している仕様をコードや一般的な実装例から推測する必要があります。
今回のコードでは、以下のような判断が必要でした。
-
max_attemptsはリトライ回数か、総試行回数か - 429はリトライ対象か
- すべて失敗した場合、どの例外を返すか
- 最終試行後に待機する必要があるか
この判断をAIに任せた結果、同じ指示でも修正内容に差が出ました。
一方で、期待する動作・制約・完了条件を伝えた場合は、AIが判断する範囲が狭くなります。
今回の検証では、実装方法を細かく指定しなくても、テストを通過する修正になりました。
今回の学び
- 「バグを修正して」だけでは、AIに仕様の推測まで任せることになる
- 同じAI・同じ指示でも、修正内容が毎回同じになるとは限らない
- 期待する動作を具体的に伝えると、修正結果を評価しやすくなる
- 制約を指定すると、不要な変更を抑えやすくなる
- 完了条件を指定すると、「何をもって修正完了とするか」が明確になる
今回の結果から、AIに修正を依頼するときは、以下のような形で指示を出すのがよさそうです。
【目的】
何を解決したいのか
【期待する動作】
どのような入力に対して、どの結果になってほしいのか
【制約】
変更してはいけないもの、守ってほしい条件
【完了条件】
どのテストや条件を満たせば完了なのか
「この方法で修正して」と実装方法をすべて指定するよりも、
「この条件を満たして」と伝えて、実装方法はAIに任せるほうが使いやすそうです。
まとめ
今回は、同じファイルに対して、
「バグを修正して」という抽象的な指示と、
期待する動作・制約・完了条件を指定した指示で修正結果を比較しました。
抽象的な指示では、同じ指示でも修正内容に違いが出ました。
一方で、条件を具体的に指定した場合は、
評価用テストを6ケース中6ケース通過する修正になりました。
ただし、今回は1つのコードと1つのモデルで行った検証です。
モデルや推論設定、コードの内容によって結果は変わる可能性があります。
感想
今回の検証を通して、AIをうまく活用するには、
AIに推測させる部分をできるだけ減らすことが大切だと分かりました。
「バグを修正して」とお願いするだけでなく、
期待する動作や制約、完了条件を先に整理して伝えることで、
自分が期待する結果に近づけることができました。
また、これはAIへの指示だけでなく、
仕様書駆動で開発することの大切さにもつながると感じました。
仕様が明確になっていると、
AIに修正を依頼するときだけでなく、
実装やレビューのときにも認識を合わせやすくなります。
AIに任せる部分は残しつつ、
何を実現したいのかは具体的に伝える。
この点を意識しながら、これからの開発でもAIを活用していきたいと思います。
この記事が、少しでも誰かの参考になればうれしいです！
では、また！