AIにバグ原因を調査させる方法｜「修正役」と「確認役」を分けて誤修正を防ぐ実践手順

AIにコード修正を任せると、原因を取り違えたまま「直したつもり」で本番に反映され、別の不具合を生むことがあります。本記事では、AIを「原因調査役」「修正役」「確認役」に分け、一度の修正を無検証で反映しない仕組みを解説します。

この記事の結論

• AIに1回で「原因特定→修正→反映」まで任せない。工程を分けると誤修正が激減する。
• 調査役・修正役・確認役の3ロールに分割する。同じAIでも「役割ごとに別セッション」で運用できる。
• 確認役は修正内容ではなく"再現テスト"で判定する。「動いた」の自己申告を信じない。
• 本番反映の前に必ず人間の承認ゲートを1つ置く。自動化してもここだけは残す。
• まず「調査役プロンプト」と「確認チェックリスト」の2つを用意すれば今日から始められる。

この記事が役立つ人

対象は、AIコーディングツール(Claude Code、Cursor、GitHub Copilotなど)を使ってバグ修正をしている開発者・チームリーダーです。「AIが直したはずなのに再発する」「修正差分が大きすぎて怖い」と感じている方に向いています。

前提として、GitのようなバージョンContro（変更履歴を記録する仕組み）と、簡単なテストを実行できる環境があると効果的です。ただし手動確認でも本記事の考え方は使えます。

なぜ「AIの一発修正」で事故が起きるのか

原因は、AIが「もっともらしい修正」を出すことに最適化されているためです。原因が特定できていなくても、それっぽいコードを自信満々に提示します。これは推測であり断定ではありませんが、多くの現場で報告される傾向です。

さらに、同じAIが「修正」と「確認」を兼ねると、自分の修正を自分で肯定する構造になります。人間でもレビューを他者に任せるのはこのためです。AIも例外ではありません。

> 強調ボックス：一発修正の3大リスク

> ① 症状(エラーメッセージ)だけ消して真因が残る

> ② 関係ない箇所まで書き換えて副作用を生む

> ③ 「テスト通りました」の自己申告が検証されない

図: バグ対応の流れ。「①調査役=原因の仮説」→「②修正役=最小差分」→「③確認役=再現テストで検証」→「④人間承認」→「本番反映」。①②③は分離し、④は必ず人間が担当。

誤修正を防ぐ5つのポイント

1. 「修正させる前に、原因の仮説を言語化させる」

結論：コードを触らせる前に、AIに原因の仮説と根拠を文章で出させると精度が上がります。

具体例：「ログイン後に画面が真っ白」というバグで、いきなり修正させると認証処理を書き換えがちです。しかし先に「考えられる原因を3つ、根拠となるログ・コード行とともに挙げて」と指示すると、真因が「APIレスポンスのnull処理漏れ」だと判明することがあります。

実践方法：調査役プロンプトを固定文にします。「①症状 ②再現条件 ③原因候補3つと該当ファイル ④まだ確定できない点」を必ず出力させます。

2. 「修正役には"最小差分"だけを許可する」

結論：修正の範囲を「原因箇所のみ・最小の変更」に限定すると、副作用が減ります。

具体例：null処理漏れなら、変えるのは該当の1関数だけのはずです。もしAIが5ファイルを書き換えたら、それは黄信号です。

実践方法：修正役への指示に「変更は原因ファイルのみ。整形・リファクタリング・命名変更は禁止」と明記します。差分行数が想定より多ければ却下します。

3. 「確認役は"直ったか"でなく"再現しなくなったか"で判定する」

結論：確認の基準を「元の再現手順でバグが出ないこと」に固定します。修正内容の良し悪しではありません。

具体例：ポイント1で「①症状 ②再現条件」を記録済みなら、その再現条件をそのまま実行するだけで判定できます。「たぶん大丈夫」を排除できます。

実践方法：確認役には修正差分を見せず、再現手順と期待結果だけを渡します。「この手順で症状が出るか、Yes/Noで答え、根拠のログを添付」と指示します。

4. 「同じAIでも"役割を切り替えるセッション"にする」

結論：ロールごとに会話を分けるだけで、自己肯定バイアスを緩和できます。別ツール・別人を用意する必要はありません。

具体例：Claude Codeなら調査用チャットと確認用チャットを別に開く。確認用には修正前の情報を渡さず、白紙の状態で再現テストだけ依頼します。

実践方法：3つのプロンプトテンプレートを用意し、同じスレッドに混在させないルールにします。

5. 「本番反映の前に、人間の承認ゲートを1つ残す」

結論：どれだけ自動化しても、本番反映の直前だけは人間が承認します。ここを省くと事故の被害が最大化します。

具体例：確認役がYesを出しても、差分が20行あれば人間が「なぜこの変更で直るのか」を1分読む。理解できなければ差し戻します。

実践方法：Gitのプルリクエスト（変更をまとめて承認申請する仕組み）を承認ゲートにします。マージ権限を人間だけに残します。

| 役割 | 入力に渡すもの | 出力するもの | 渡さないもの |

|---|---|---|---|

| 調査役 | 症状・ログ・コード | 原因候補と根拠 | — |

| 修正役 | 確定した原因のみ | 最小差分 | 無関係な要望 |

| 確認役 | 再現手順・期待結果 | Yes/Noと根拠ログ | 修正差分 |

| 人間 | 差分と確認結果 | 承認/差し戻し | — |

AIやツールで自動化する方法

工程分割は、既存ツールの組み合わせで自動化できます。特定製品が必須ではありません。以下は一例です。

• 調査・修正・確認の分離：Claude CodeやCursorで「役割ごとのプロンプト」をファイル保存し、都度読み込む。
• 再現テストの自動実行：確認役の判定を、PytestやJestなどの自動テストに置き換えると客観性が上がる。
• 承認ゲート：GitHub Actions（変更時に自動処理を走らせる仕組み）でテストを実行し、成功しても自動マージはしない設定にする。マージは人間が押す。

> 強調ボックス：自動化しても外さない1点

> 「テストが通る」＝「安全」ではありません。テストが元のバグを再現できていなければ、通っても意味がない。再現テストが先、修正は後の順序を守ってください。

図: GitHub Actionsを使う場合。プルリク作成→自動で再現テスト実行→結果をコメント表示→人間がマージボタンを押す（ここは自動化しない）。

体験メモ（筆者の運用例・一般化はできません）：調査役の出力に「まだ確定できない点」欄を足しただけで、AIが早合点で修正を始めるケースが体感で減りました。数値化はしていないため参考程度に捉えてください。

実践チェックリスト

• [ ] 修正前に「症状・再現条件」を文章で記録した
• [ ] 調査役に原因候補を3つ、根拠付きで出させた
• [ ] 修正役への指示に「最小差分・整形禁止」を明記した
• [ ] 確認役には差分を渡さず、再現手順だけで判定させた
• [ ] 確認は「Yes/No＋根拠ログ」の形式で受け取った
• [ ] 本番反映の前に人間の承認ゲートを通した
• [ ] 差分の内容を人間が読んで理解できた

まとめ

AIの誤修正は「1回で原因特定から反映まで任せる」ことで起きます。調査・修正・確認を分け、確認は再現テストで、反映前に人間承認を1つ残すのが解決の核心です。

最初に着手すべきは、「調査役プロンプト（症状・再現条件・原因候補3つ）」を1つ作ること。これだけで一発修正の事故が目に見えて減ります。

次に読む記事

• 基礎：AIコーディングツールの選び方｜Copilot・Cursor・Claude Codeの違いと使い分け
• 実践：バグ再現手順の書き方｜「動かない」を"必ず再現する条件"に変える技術
• 発展：GitHub Actionsで作るレビュー自動化｜自動マージを避けて安全に高速化する設計

よくある質問

Q. 役割を分けると手間が増えて遅くなりませんか？

A. 単純なバグでは確かに手数が増えます。ただし誤修正による再発・切り戻しの時間を含めると、複雑なバグほど分割した方が結果的に速くなる傾向があります。軽微な修正は分割を省く判断もありです。

Q. AIが1つしか使えません。それでも分離できますか？

A. できます。同じAIでもチャット（セッション）を分け、確認役には修正差分を渡さず再現手順だけを渡せば十分効果があります。重要なのはツールの数でなく「情報の渡し方」です。

Q. 確認役のAIが「Yes」と言えば本番反映してよいですか？

A. いいえ。確認役の判定は参考情報です。本番反映の直前は必ず人間が差分を読み、承認してください。この1ゲートを省くと自動化の事故が最大化します。