LLMで論理バグを直す頼み方 ― 再現条件・最小差分・テストで検証する

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。OpenAI・Anthropicの現在のコーディング／エージェント向け公式ガイダンスを確認し、旧版の「Thinking Processを全文出力させればデバッグ精度が上がる」という構成を、再現条件・最小差分・実行テスト・変更後検証を中心に見直しました。

検証ステータス：📘 OpenAI・Anthropic公式情報確認済み／個別言語・リポジトリでの網羅テストは未実施

LLMへコード修正を頼むとき、「よく考えて」と追加するより先に、バグを再現できる材料を渡す方が重要です。論理バグでは、入力、期待結果、実際の結果、関連コード、実行方法をそろえると、修正後の検証までつなげやすくなります。

まず渡す5点

コピペ用テンプレート

<goal>
次の不具合を修正する。
</goal>

<reported_issue>
期待: {{EXPECTED}}
実際: {{ACTUAL}}
再現手順: {{REPRO_STEPS}}
</reported_issue>

<scope>
主な対象: {{FILES}}
関係ないリファクタリングはしない。
</scope>

<verification>
修正後に: {{TEST_COMMAND}}
必要なら今回の不具合を再現する最小テストを追加する。
</verification>

<final_report>
- 原因の短い説明
- 変更ファイル
- 変更内容
- 実行したテスト
- 残る懸念
</final_report>

最小再現を作る

大きなコードベースでは、いきなり修正を始めるより、失敗するテストや最小入力を先に作ると原因を絞れます。修正前に失敗し、修正後に通ることが確認できれば、変更の目的も明確になります。

差分を小さくする

LLMは、バグ修正と一緒に変数名変更や関数分割まで行うことがあります。レビューしやすくするため、最初は「この不具合を直すために必要な最小差分」を要求します。リファクタリングが必要なら、バグ修正とは別の変更として扱う方が追跡しやすくなります。

説明より実行結果を重視する

もっともらしい原因説明が書けても、テストが通るとは限りません。OpenAIの現在のコーディング向けガイダンスでも、変更後に対象テスト、型チェック、lint、build、必要に応じたスモークテストなど、変更に見合う検証を実行する考え方が示されています。

変更:
- 対象ロジックを最小範囲で修正
- 再現テストを1件追加

検証:
- 対象テスト: PASS
- 静的チェック: PASS

未確認:
- 別OS環境は未確認

エッジケースはテストへ落とす

「空値・最大値・異常値を考えて」と書くだけでは一般論になりがちです。0件、1件、閾値ちょうど、閾値の前後、重複、順序違いなど、その関数に意味のある境界を実際のテストへ落とします。

ライブラリやAPIは存在確認する

モデルが存在しないメソッドや古いAPIを提案する可能性はあります。依存ライブラリのバージョン、公式ドキュメント、型情報、実際のテスト実行で確かめます。

検証できないときは止まる

依存サービスがない、テスト環境が壊れている、必要なデータがない場合は、推測で修正完了とせず、実行できなかった確認と不足条件を報告させます。

まとめ

LLMを使ったデバッグでは、長い思考過程より、再現可能性と検証可能性を高めます。再現ケースを作る → 最小差分で直す → テストを実行する → 実行結果を報告するという流れなら、モデルが変わってもレビューしやすくなります。

公式情報・一次情報

• OpenAI API ― Model guidance（Testing and verification）
• Anthropic ― Prompting best practices

この記事の更新履歴

• 2026-09-13 追加：最小再現、最小差分、実行テスト、検証不能時の停止条件を追加。
• 2026-09-13 変更：Thinking Process中心のデバッグから、再現条件とテスト中心のデバッグへ変更。
• 2026-09-13 削除：style_prompt、本文H1、逐語的CoT出力の強制、旧モデルに関する未検証の性能主張、「最強プロンプト」表現を削除。