この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。OpenAIの現在のモデルガイダンスを確認し、旧版の「詳細な処理過程を書かせればバグ修正精度が上がる」という構成を、再現条件・最小差分・実行可能なテストを中心に見直しました。検証ステータス：📘 OpenAI公式情報確認済み／特定コードベースでの横断ベンチマークは未実施
論理バグは、構文エラーのように「ここが壊れている」と分かりやすく出ないことがあります。条件分岐、状態管理、境界値、複数関数の連携などが原因になるため、LLMへコードだけ渡して「直して」と頼むと、表面的な変更に流れることがあります。
実務では、再現ケース・期待値と実際値・変更範囲・テストを先にそろえる方が、修正を検証しやすくなります。
最初に4点を渡す
| 項目 | 内容 |
|---|---|
| Target | 対象コードと関連する最小範囲 |
| Reproduce | 不具合が再現する入力・操作 |
| Expected | 期待する結果 |
| Actual | 現在の結果・エラー |
修正依頼の基本形
対象コード:
[コード]
再現条件:
input = ...
期待値:
...
実際値:
...
制約:
- 公開APIは変更しない
- 不具合に関係ないリファクタリングはしない
- 変更は最小限にする
出力:
1. 原因の短い説明
2. 最小修正案
3. 修正コード
4. 再現ケースを含むテスト
5. 影響範囲と未確認事項
OpenAIの現在のガイダンスでも、目的、成功条件、許可される副作用、出力形を明確にし、変更後はテストやlintなど具体的な検証を行う設計が推奨されています。
「最小差分」を条件にする
バグ修正と同時に大規模なリファクタリングまで行うと、どの変更が効いたのか分かりにくくなります。
- 修正対象外の命名変更をしない
- 不要な関数分割をしない
- 依存ライブラリを勝手に追加しない
- 公開インターフェースを変える場合は明示する
再現テストを先に作れると強い
可能なら、修正前に失敗するテストを用意します。
def test_discount_never_below_zero():
result = calculate_discount(price=1000, coupon=1500)
assert result == 0
このテストが修正前に失敗し、修正後に通るなら、変更の目的を機械的に確認できます。
正常系だけで終わらせない
| 種類 | 例 |
|---|---|
| 正常系 | 一般的な入力 |
| 境界値 | 0、最大値、閾値直前・直後 |
| 欠損 | null、空文字、空配列 |
| 状態遷移 | 連続実行、再試行、二重送信 |
| 回帰 | 既存の重要ケース |
モデルに「実行した」と言わせるだけでは足りない
コードを実行できる環境がない場合、モデルの「テストは通るはずです」という説明は検証ではありません。実行環境があるなら実際にテストを走らせ、ない場合は未実施として明示します。
差分レビューで見るポイント
- 修正箇所が再現ケースと対応しているか
- 新しい分岐が別の境界値を壊していないか
- 既存APIや戻り値を変えていないか
- 例外処理を握りつぶしていないか
- テストが実装詳細ではなく期待動作を確認しているか
まとめ
論理バグ修正では、説明の長さよりも、不具合を再現できること、修正差分が小さいこと、修正後をテストできることが重要です。
LLMを「正解を当てる人」としてではなく、再現ケースと制約に基づいて修正案を作り、テストで確認する開発補助として使うと安全性と再現性を高められます。
公式情報・一次情報
この記事の更新履歴
- 2026-09-13 追加：再現ケース、最小差分、失敗テスト、境界値・回帰テストの観点を追加。
- 2026-09-13 変更：長い処理説明を求める設計から、実行可能な検証を中心とした修正フローへ変更。
- 2026-09-13 削除：style_prompt、本文H1、旧モデル前提、詳細な内部処理説明を必須とする記述、未検証の精度向上表現を削除。
