AIにバグ修正を頼んだら、自信満々に修正コードを出してきて、実行したら別のバグが増えた。

この経験、私だけではないはずです。土地勘のない街で道を聞いたら、自信たっぷりに間違った方向を教えてくれた親切な人と同じ構図です。善意は本物だが、精度は別の話。

Stack Overflowの開発者調査(2025年)によると、開発者の66%が「AI生成コードはほぼ正しいが完全ではない」と回答し、45%が「AI生成コードのデバッグはより時間がかかる」と感じています。AIは「もっともらしいコード」を生成する能力に優れています。しかし「このコードが壊れる条件は何か」を検証する能力は持っていません。

では、人間がデバッグで使う思考法をAIに渡せば、精度は上がるのか。答えはイエスです。この記事では、10のデバッグ技法をAIに渡すプロンプトの形に変換します。

なぜAIは「もっともらしい修正」に飛びつくのか

例えば「APIが500エラーを返す」とAIに伝えたとします。多くの場合、AIは過去に見た類似パターンからtry-catchを追加したり、nullチェックを入れたりします。症状が消えることもある。しかし本当の原因がコネクションプールの枯渇だった場合、try-catchは問題を隠蔽しただけです。数時間後、別の場所で同じ障害が再発します。

大規模言語モデルは「次に来る最も確からしいトークン」を予測する仕組みです。「エラーハンドリングのパターン」は学習データに大量に存在します。だから根本原因の調査よりも、パターンマッチングによる修正を優先しがちです。

人間のデバッガーが持つ「まだ原因が分かっていない。調査を続ける」という判断は、明示的に指示しなければAIには伝わりません。

10の技法を5つのプロンプトブロックに凝縮する

10の技法をそのままプロンプトに並べると冗長になります。実務で使いやすいように、5つのブロックに再構成しました。

ブロック1: 前提を疑う + 再現性（技法1-2）

修正に入る前に確認してください:
- ログ出力は全件取れていますか? 欠損の可能性はありませんか?
- モニタリングデータは信頼できますか?
- ヘルスチェックは「応答できる」ではなく「正しく動作している」を検査していますか?

まずバグを再現してください。最小限の再現手順を示してください。
再現できない場合は、再現できない旨を報告してください。
推測で修正しないでください。

「推測で修正しないでください」の一文が地味に効きます。これがないと、AIは再現を試みる前に「おそらくこれが原因です」と修正に入ります。

ブロック2: 境界と差分（技法3-4）

問題が発生する境界を特定してください。
- どのコンポーネントまでは正常で、どこから異常が始まりますか?
- 動いていた状態と壊れている状態の差分は何ですか?
- git log で最近の変更を確認してください

「どのコンポーネントまでは正常で」という問いは、AIにバイナリサーチを強制します。全体を一度に見ようとするのではなく、正常/異常の境界を絞り込んでいく。人間のデバッガーが無意識にやっていることを、AIには明示的に指示する必要があります。

ブロック3: 時系列と制御ロジック（技法5-7）

時系列で整理してください:
- この問題はいつから発生していますか?
- 急激な変化ですか、それとも徐々に悪化していますか?
- リトライ、キャッシュ、タイムアウトの設定を確認してください
- 小さなエラーが増幅されるパスはありませんか?

「急激な変化か、徐々に悪化か」の質問は、原因の性質を分類するフィルターになります。急変ならイベント起因、漸増ならリソース枯渇。この分類ができるだけで、調査範囲が半分になります。

ブロック4: 観測と削減（技法8-10）

原因の特定に必要な観測ポイントが不足している場合は、
ログやトレースの追加を提案してください。
不要な要素を削って問題を単純化できる場合は、その手順を示してください。
仮説を検証するために意図的に壊すテストも検討してください。

ブロック5: ストップシグナル（3回ルール）

3回連続で同じテストが失敗した場合は、修正を中止してください。
以下の情報を整理して人間に報告してください:
- 試みた修正の内容と結果
- 根本原因についての現時点での仮説
- 構造的な問題の可能性(アーキテクチャ、仕様の曖昧さ等)
- 人間に判断を仰ぎたい点

このブロックは保険です。AIが同じアプローチで3回失敗しているなら、それは単一のコード修正では解決できない構造的な問題である可能性が高い。人間に戻す判断をAI自身にさせる仕組みです。

私の経験上、3回失敗してもAIは4回目を試みます。止めなければ延々と同じ穴を掘り続ける。明示的なストップシグナルは、トークン代の節約にもなります。

「原因特定なき修正」を禁じる一文

5つのブロックの中で最も重要な原則は、1つの文に集約されます。

根本原因を特定するまで修正に入らないこと。

Claude Codeのベストプラクティスとして知られているルールです。"NO FIXES WITHOUT ROOT CAUSE FIRST"。4フェーズを順番に踏むことを強制する仕組みです。

フェーズ	やること	AIが飛ばしがちな理由
1. 根本原因調査	ログ、トレース、コード解析	「似たパターンを知っている」と判断して省略
2. パターン分析	同じバグが他にないか確認	目の前の1箇所だけ直そうとする
3. 仮説検証	テストを書いて原因を確認	テストより修正のほうが速いと判断
4. 実装	検証済みの原因に対して修正	ここから始めたがる

フェーズ1を飛ばしてフェーズ4に入ることを、プロンプトの制約として明示的に禁止する。これだけで、AIのデバッグ精度は体感で大きく変わります。

テスト駆動デバッグ -- AIに「ゴール」を渡す

AIにデバッグを頼むとき、最も効果的なのは「ゴールを明確にすること」です。

「バグを直してください」と渡すと、成功の定義が曖昧です。しかし「このテストを通してください」と渡すと、成功の定義が厳密になる。AIは明確なゴールがあるタスクに強い。

手順はこうです。

バグを再現するテストを書く（Red）
テストが失敗することを確認する
AIにテストを渡し、「このテストが通るように修正してください」と依頼する
テストが通ることを確認する（Green）
既存テストがすべて通ることを確認する

テストが存在しないコードのデバッグでは、まずテストを書くことが最初のステップです。「テストを書く時間がない」という声が聞こえます。しかしテストなしでAIにデバッグを任せると、修正が別のバグを生みます。結果的にもっと時間がかかる。

クロスモデルデバッグ

1つのモデルが同じバグに対して複数回の修正を試み、いずれも失敗する場合があります。同じ前提、同じ学習パターンに基づいて推論するため、同じ盲点にはまり続ける。

そのような場合、別のモデルに同じ問題を渡すことが有効です。

以下のバグについて、前任のエージェントは3回修正を試みましたが、
いずれも失敗しました。失敗した修正内容は以下のとおりです:
[失敗した修正1, 2, 3の内容]

別のアプローチで根本原因を分析してください。
前任のエージェントと同じ修正を繰り返さないでください。

人間のデバッグでも同じです。1人のエンジニアが行き詰まったとき、別のエンジニアに見てもらうと解決することがある。ペアデバッグの効果は、人間同士でもAI間でも機能します。

まとめ

プロンプトは思考プロセスの伝達手段です。「何を調査すべきか」「どの順番で考えるべきか」「いつ立ち止まるべきか」を伝える。

5つのプロンプトブロックで、10のデバッグ技法をAIに渡せる形にした
"NO FIXES WITHOUT ROOT CAUSE FIRST" -- この一文が最も効く制約
テスト駆動デバッグで、AIにゴールを明確に渡す
3回失敗で停止のストップシグナルを入れておく

あなたが最後に遭遇したバグで、AIに最初に渡した指示は何でしたか？「このエラーを直して」か「まず原因を特定して」か。その一言の違いが、デバッグの結末を分けています。

付録: AIデバッグスキル（コピペ用）

本記事の5ブロックを統合したスキル定義です。CLAUDE.md やAIエージェントのスキルファイルにそのまま貼れます。

# AIデバッグスキル -- 根本原因を特定してから修正する

## 絶対ルール

根本原因を特定するまで修正に入らないこと（NO FIXES WITHOUT ROOT CAUSE FIRST）。
3回連続で同じテストが失敗した場合は修正を中止し、人間に報告すること。

## デバッグ手順

以下の順番で実行する。フェーズを飛ばさないこと。

### フェーズ1: 前提確認と再現

- ログ出力は全件取れているか。欠損の可能性はないか
- モニタリングデータは信頼できるか
- バグを再現する最小手順を示すこと。再現できない場合はその旨を報告し、推測で修正しないこと

### フェーズ2: 境界と差分の特定

- どのコンポーネントまでは正常で、どこから異常が始まるか
- 動いていた状態と壊れている状態の差分は何か
- git log で最近の変更を確認すること

### フェーズ3: 時系列と制御ロジック

- この問題はいつから発生しているか
- 急激な変化か、それとも徐々に悪化しているか
- リトライ、キャッシュ、タイムアウトの設定を確認すること
- 小さなエラーが増幅されるパスはないか

### フェーズ4: 観測と仮説検証

- 原因特定に必要な観測ポイントが不足している場合、ログやトレースの追加を提案すること
- 不要な要素を削って問題を単純化できる場合、その手順を示すこと
- 仮説を検証するテストを書き、原因を確認してから修正に入ること

### フェーズ5: 修正の実装

- フェーズ1-4を完了してから、ここに入ること
- 修正後、既存テストがすべて通ることを確認すること
- 同じバグパターンがコードベースの他の箇所にないか確認すること

## ストップシグナル

3回連続で修正が失敗した場合:
1. 試みた修正の内容と結果を整理する
2. 根本原因についての仮説を報告する
3. 構造的な問題の可能性を指摘する
4. 人間に判断を仰ぐ

参考文献

David Agans, Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems (2002) -- デバッグ原則の古典
Stack Overflow, "2025 Developer Survey - AI" (2025) -- AI生成コードに対する開発者の認識調査
Kent Beck, Test Driven Development: By Example (2002) -- Red-Greenループの原典