利益:
- エラー メッセージ、スタック トレース、最小の再現インスタンスを使用して AI にバグを効果的に説明する機能
- AI を使用して体系的なデバッグ フローを実行し、仮説を立てて段階的に絞り込むことで根本原因を見つける機能
- AI が提案した修正が実際に問題を修正したことを再現テストと回帰テストによって検証する機能
デバッグは、プログラムが予想と異なる動作をする理由を突き止めて修正するタスクであり、ほとんどのエンジニアはこれに多くの時間を費やします。優れたデバッグは、推測ゲームに基づいているのではなく、症状を明確にし、仮説を立て、仮説をテストし、根本原因を突き止めるという体系的な絞り込みに基づいています。 AI はこのサイクルにおいて非常に強力なパートナーです。ただし、それはあなたが彼に正しい情報を与えた場合に限ります。 「コードが機能しないので修正してください」と言うと、AI は推測して包括的な提案をすることになります。完全なエラー メッセージ、スタック トレース、最小の再現サンプルを提供すると、根本原因が見つかります。
この単元では、AI にバグを効果的に説明し、仮説を段階的に絞り込み、提案された修正が実際に問題を解決することを回帰テストを通じて検証する方法を見ていきます。覚えておいてください: バグを「修正する」ことと「バグの症状を抑制する」ことは別のことです。根本原因を見つけずに修正を行うと、エラーが別の場所に移動します。
概念: スタック トレース: エラー時にどの関数がどの順序で呼び出されたかを示すダンプ。最小限の再現: エラーを引き起こす最も単純で短いコード/入力。根本原因: 症状ではなく、問題の本当の原因。回帰テスト: 同じエラーが繰り返されないことを確認するテスト。
AI にバグを説明する
AI が根本原因を発見する可能性は、提供する情報の質に直接比例します。適切なエラーの説明には、実行しようとしたこと、予期していたこと、何が起こったのか、正確なエラー テキストとスタック トレース、関連するコード、環境 (言語/バージョン/OS)、エラーを生成した最小のサンプルが含まれます。
- 症状を明確にします。 「期待された X、実現された Y」の形式。
- 完全なエラー テキストとスタック トレースを貼り付けます。短くしたり、検閲したりしないでください。ただし、構造を壊さないでください。
- 最小の再現を与えます。エラーをトリガーする最小入力とコード。
- 環境を指定します。言語バージョン、ライブラリバージョン、実行環境。
効果的なエラー説明プロンプト: 「バグをデバッグしています。情報:- やろうとしていること: [X]- 予想される動作: [Y]- 実際の動作: [Z]- 完全なエラー メッセージとスタック トレース: [貼り付け]- 環境: [言語/バージョン、ライブラリ/バージョン]- 必要な最小限のコード: [コード] 直接的な修正はしないでください。まず、可能性の高い 3 つの根本原因を可能性の高い順にリストし、それぞれを確認するためのチェックを教えてください。」
仮説によるフローの絞り込み
体系的なデバッグは、可能性を 1 つずつ排除する技術です。 AI を使用して仮説を生成し、各仮説をテストする実験を設計します。次に、実験を実行して結果を返します。このサイクルは、「ショットガン デバッグ」と呼ばれる、ランダムな変更を行ったり停止したりする習慣よりもはるかに高速です。
二分探索 (二分法) ヘルパー プロンプト: 「このエラーは昨日はありませんでしたが、今日はあります。最後の 20 の変更のうち、どの変更が二分法でエラーを引き起こしたかを調べたいのです。段階的な計画を教えてください。どの点をテストする必要があり、結果に応じてどの半分に進む必要があります。また、各ステップで何を確認するかを正確に教えてください。」
ログ挿入戦略プロンプト: 「この関数の中間値が表示できないため、エラーを見つけることができません。どの変数を出力するログ行をどの時点に追加する必要があるのか教えてください。各ログに「このログから何を学ぶか」の説明を追加します。また、機密データのログ記録を妨げる警告も指定してください。」
ヒント: エラーを解決できない場合、ほとんどの場合、問題は誤った想定にある場所にあります。 AI に「私のどの仮定が間違っている可能性がありますか?」と尋ねます。尋ねることはあなたの盲目を破るでしょう。最も重大な間違いは、「これは正しく機能していると確信している」という場所に隠れています。
弱いプロンプト / 強いプロンプト
WEAK:「コードでエラーが発生しました。修正してください: [200 行のコード]」(結果: AI は、それがどのようなエラーなのか、何が予想されるのかを知りません。推測に基づいて一般的な提案をしますが、そのほとんどは役に立ちません。)STRONG:「NullPointerException が発生します。予期: ユーザー リストが返されるはずです。実際: getUsers() の呼び出しで爆発します。スタック トレース: [貼り付け]。環境: Java 17。最小値繰り返し: ユーザー リストが空の場合は発生しますが、いっぱいの場合は発生しません。関連する 15 行: [コード]。根本原因と空のリストがトリガーされる理由を説明し、修正を提案します。
強力なプロンプトにより、エラーがコンテキストに表示されます。エラーが発生する場合 (空のリスト)、発生しない場合 (完全なリスト) です。この 1 つの手がかり (「空のときに発生する」) は、根本原因をほぼ直接示しています。この情報は弱いプロンプトでは利用できないため、AI は盲目的に推測します。
修正の確認
修正は次の 3 つのことを実行する場合にのみ本当の修正となります。
コントロール
質問
確認方法
エラーは消えましたか？
同じエントリは現在も機能しますか?
最小限の再現を再度実行します
新しいエラーはありませんか?
他に壊れたものはありますか？
テストスイート全体を実行する
繰り返されないでしょうか？
また同じエラーが発生するのでしょうか？
このシナリオに回帰テストを追加する
根本原因を見つけずに修正を行うと、多くの場合、症状が抑制されます。たとえば、null エラーを「null の場合はスキップ」でごまかしてしまうと、「なぜデータが null になるのか」という本当の理由がわかります。表示されず、別の場所でエラーが再発します。
ミニケース
ケース 1 — 症状抑制の罠。チームは、時折発生する null エラーをトライキャッチで黙らせます。エラーは消えますが、2 週間後にデータが失われたように見えます。本当の理由は、サービスがタイムアウト時に null を返すためです。 AI に「なぜ null になるのですか?」と尋ねると、根本的な原因が明らかになります。実際の修正には 1 時間かかりますが、永続的に修正されます。
ケース 2 — 最小限の再現力。開発者は「時々クラッシュする」というバグを修正することはできません。 AI の提案により、エラーが最小限の入力に削減されます。問題は、トルコ語の文字を含むファイル名でのみ発生します (エンコード エラー)。 300 行の不確実性が 5 行の最終的な再現に削減されると、解決策は明らかになります。
ケース 3 — 反回帰テスト。 AI が日付計算エラーを修正します。エンジニアはこれに満足していません。誤ったシナリオ (月末、1 月 31 + 1 か月) の回帰テストを追加します。 4 か月後に同じ領域に別の変更が加えられると、テストが赤色になり、運用環境に到達する前にバグが捕捉されます。
よくある間違い
- 「機能していないので修正してください」という意味です。エラー テキスト、予想、再現がなければ、AI が推測します。
- スタックトレースを提供しません。多くの場合、スタック トレースは根本原因を直接示します。
- ランダムな変更を加え続けます。仮説を立てずに実験を行うのは時間の無駄です。
- 症状を抑制し、根本原因を見逃します。エラーは別の場所で再発します。
- 回帰テストで修正を確保していない。今後、同じエラーが静かに戻ってきます。
要約すれば
効果的なデバッグは、推測ではなく体系的に絞り込むことです。 AI に完全なエラー テキスト、スタック トレース、最小限の再現、および環境情報を与えると、根本原因を見つける可能性が飛躍的に高まります。 AI を使用して仮説を生成し、各仮説をテストする実験を設計します。あなたは実験を実行します。バグが解消され、新しいバグが導入されておらず、回帰テストによって保護されていることが確認された場合にのみ、修正が「完了」したとみなします。
アプリケーションタスク
実際のエラーまたは人為的なエラーを考えてみましょう。まず、誤差を最小の再現値（どの入力で発生するか、どの入力で発生しないか）まで削減します。効果的なバグレシピのプロンプトを使用して、AI に 3 つの根本原因仮説とそれぞれの検証ステップを尋ねます。仮説を 1 つずつテストして根本原因を見つけ、それを修正してから、このシナリオの回帰テストを作成して実行し、バグが解消され、テストによって保護が提供されることを示します。
チェックリスト
- [ ] 私は症状を「予想と実現」として明確にしました。
- [ ] エラー テキスト全体とスタック トレースを AI に渡しました。
- [ ] 誤差を最小限に抑えて再現しました。
- [ ] 仮説を一つずつ検証していき、根本原因を見つけました。
- [ ] 症状を抑えるのではなく、根本原因を解決しました。
- [ ] 同じエラーに対して回帰テストを追加して実行しました。