この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。OpenAIの現在のモデルガイダンスを確認し、旧版の「バグ修正とリファクタリングを一度に行う」構成を、再現・最小修正・テスト・別工程での改善という流れへ見直しました。検証ステータス：📘 OpenAI公式情報確認済み／特定リポジトリでの横断評価は未実施
LLMへ「このバグを直して、ついでに読みやすくリファクタリングして」と頼むと、修正範囲が広がりやすくなります。結果として、どの変更が不具合を直したのか分かりにくくなります。
実務では、バグ修正とコード改善を分ける方がレビューしやすく、ロールバックもしやすくなります。
最初はバグだけを直す
目的:
報告された不具合だけを修正する。
制約:
- 公開APIは変更しない
- 依存ライブラリは追加しない
- 命名変更や関数分割はしない
- 変更は最小限にする
- 再現テストを追加する
再現ケースを用意する
function calculateDiscount(price, type) {
if (type = "VIP") {
return price * 0.8;
}
return price;
}
この例では、= が代入になっているため、StandardでもVIP扱いになります。修正前に「Standardなら割引しない」というテストを置くと、目的が明確になります。
test("Standard user is not discounted", () => {
expect(calculateDiscount(1000, "Standard")).toBe(1000);
});
修正コミットと改善コミットを分ける
flowchart LR
A[再現テスト] --> B[最小修正]
B --> C[テスト成功]
C --> D[レビュー]
D --> E[必要なら別工程で改善]
まず不具合だけを直し、テストが通ったあとで可読性や性能の改善を別工程にします。
LLMへ渡す情報
| 項目 | 内容 |
|---|---|
| 対象 | 変更してよいファイル・関数 |
| 再現 | 失敗する入力・操作 |
| 期待 | 正しい出力 |
| 実際 | 現在の出力 |
| 制約 | 変えてはいけないAPI等 |
| 検証 | 実行するテスト・lint・build |
改善工程では目的を限定する
バグ修正後にリファクタリングする場合も、目的を1つに絞ります。
- 重複処理を減らす
- 関数名を明確にする
- 複雑度を下げる
- 性能ボトルネックを改善する
「全部きれいにして」ではなく、何を改善するかを限定すると差分をレビューしやすくなります。
出力形式より実行確認を優先する
JSON形式で修正内容を返しても、コードが正しく動く保証にはなりません。実行環境があるなら、対象テスト、型チェック、lint、buildなどを実際に走らせます。
まとめ
LLMによるコード修正では、バグ修正とリファクタリングを同時にしないことが大切です。再現ケースを固定し、最小差分で直し、テストを通してから次の改善へ進みます。
この流れなら、AIが使えない状況でも人間が同じ手順で確認でき、変更理由も追跡しやすくなります。
公式情報・一次情報
この記事の更新履歴
- 2026-09-13 追加：再現テスト、最小修正、別工程でのリファクタリング、実行確認を追加。
- 2026-09-13 変更：バグ修正と改善を一括で行う構成から、差分を分離する開発フローへ変更。
- 2026-09-13 削除：style_prompt、本文H1、旧モデル前提、詳細な内部処理説明の要求、未検証の精度向上表現を削除。
