AIコーディングを使っていると、最初の実装は驚くほど速いのに、最後の一つのエラーだけが何度頼んでも消えないことがあります。『このエラーを直して』と渡すとパッチは作られる。しかし再実行すると同じ症状が出る。もう一度頼むと、今度は別の場所へ条件分岐が足され、原因は見えないまま変更だけが増えていきます。
私もAIへエラー修正を任せる中で、最初の1回はそのまま自己修正させてもよいが、2回目からは人間も原因を考え、方向性を共有した方がよいと考えるようになりました。これはAIを諦めて自分で全部書くという話ではありません。同じ入力から別の結果が出ることを期待するのをやめ、AIが見えていない証拠を人間が追加するという役割分担です。
AIが同じエラーを繰り返すのは、入力される証拠が変わらないから
AIはエラーメッセージ、関連コード、リポジトリ内の規則、実行できるテストから原因を推測します。ところが人間が毎回『まだ直っていない』とだけ返すと、原因推定に使える材料はほとんど変わりません。同じ前提から、似た修正案を別の書き方で出し続けることになります。
さらに、AIが行った変更そのものが次の不具合を作る場合があります。失敗テストを直す代わりに条件を緩める、例外を握りつぶす、存在しないAPIや依存パッケージを前提にする。見た目にはコード量が増えているため進んだように感じますが、合格条件からは遠ざかっています。
GitHubのAI生成コード向け公式ガイドも、まずコンパイル、テスト、静的解析を行い、プロジェクトの意図と設計へ合っているかを確認するよう勧めています。特に、失敗したテストが修正ではなく削除・スキップされていないか、幻覚のAPIや依存関係が入っていないかは確認項目です。重要なのは『AIが修正したか』ではなく、外部から観測できる合格条件を満たしたかです。
1回目はAIへ任せ、2回目から人間が原因仮説を足す
私が使う境界は単純です。最初の失敗では、AIにエラー全文を読ませ、関連箇所を調べ、修正し、テストまで実行させます。AI自身に思い当たるバグや副作用を先に洗い出させてから人間が触る方が、細かな確認を何度も往復するよりコストが低いからです。
同じ症状が2回目に出たら、自動的な再試行を止めます。ここで『別の方法で直して』と頼むのではなく、人間が実行結果を見て、原因候補を一つ立てます。たとえば、コードのロジックではなくキャッシュが残っている、ローカルと本番で設定値が違う、テストが実際の失敗経路を通っていない、修正対象とは別のテンプレートが表示されている、といった仮説です。
2回という回数に科学的な正解があるわけではありません。私にとっては、同じ失敗が続いた時点で『モデルの推論をもう一度回す問題』から『観測方法を変える問題』へ切り替えるための運用ルールです。無制限に粘らせないため、先に境界を決めておくことに価値があります。
AIへ渡す「原因仮説パケット」5項目
2回目からは、長い会話履歴を丸ごと渡すより、次の5項目を短く揃えます。
- 期待する結果：どの操作の後、何が表示・保存・返却されれば成功か。
- 実際の結果：エラー全文、HTTPステータス、画面差分、失敗したテスト名など、観測した事実。
- 最小の再現手順：初期状態から失敗までを3〜5手順にする。
- 人間の原因仮説：最も疑う境界を一つ示し、その理由を書く。
- 合格条件と禁止事項：通すテスト、維持する仕様、触れてはいけないファイルやデータを定義する。
たとえば『ログイン後に一覧が空になる』だけでは情報が足りません。『APIは200で3件返すが、画面では0件。通信結果は正しいため、レスポンスのキー名と表示側の変換処理がずれていると考えている。データ形式は変更せず、変換処理を確認し、既存テストとこの再現手順を通す』まで渡せば、探索範囲が絞れます。
仮説は正解でなくて構いません。外れていれば、AIはコードやログを根拠に反証できます。何も仮説がない状態より、どの境界を調べ、何が違えば次へ進むかが明確になります。
AIの修正と検証を同じ仕事にしない
AIへ『直して、問題ないことも確認して』と一括で頼むと、作った本人が自分の変更を肯定する形になりやすい。そこで私は、修正を作る工程と、合格を判定する工程を分けます。
修正後は、まず差分を読みます。次に既存テスト、新しい再現テスト、静的解析を実行します。最後に、AIへ『この修正が失敗テストを消しただけではないか』『未確認の前提は何か』『元の仕様を壊す経路はないか』とレビューさせます。同じモデルでも、作成時の会話から切り離し、差分と合格条件だけを渡すと、役割を変えやすくなります。
NISTのDevSecOps向け資料でも、AI生成物は人間が監視・検証し、正確性と信頼性を検証可能な工程で担保する必要があるとされています。ここでいう人間の監視は、すべてのコードを手で書き直すことではありません。テスト、ログ、差分という証拠を残し、誰が見ても成功か失敗か判断できる状態を作ることです。
AIで速くなるかは、修正時間ではなく完了時間で測る
AI開発の速度は、コードが出た瞬間ではなく、要求を満たして安全に完了した時点で測る必要があります。Googleの96人のエンジニアを対象にした実験では、特定の社内環境と課題でAI支援に約21%の時間短縮が推定されました。一方、METRが2025年に経験豊富なオープンソース開発者を対象に行った実験では、当時の条件で19%の遅延が観測されました。METR自身が、この古い結果を現在のモデルへ一般化できないと注意し、2026年の後続調査にも選択バイアスがあると説明しています。
この差から『AIは速い』『AIは遅い』のどちらかを選ぶのは雑です。課題、リポジトリへの習熟、ツール、測定方法、修正後に求める品質で結果は変わります。だから自分の現場では、生成時間ではなく、最初の指示からテスト通過までの時間、再試行回数、巻き戻した差分量を記録します。同じエラーが三回続いているなら、出力速度が速くても開発は速くありません。
AIデバッグを止めて巻き戻す条件
原因仮説を渡しても、続行しない方がよい場面があります。私は次のどれかが起きたら、追加パッチではなく直前の正常状態へ戻します。
- 同じ症状が3回続き、観測事実が増えていない。
- 変更範囲が当初の原因候補から広がり続けている。
- テストを削除・緩和しないと成功扱いにできない。
- 認証、権限、個人情報、決済、データ削除へ影響が及ぶ。
- 新しい依存関係を追加しないと直せないが、必要性と安全性を説明できない。
巻き戻しは失敗ではありません。壊れ方を観測し、原因候補を減らした成果を残したまま、変更だけを捨てる操作です。小さなチェックポイントを作っておけば、AIが積み上げたパッチを守るために、さらに複雑なパッチを重ねずに済みます。
人間の仕事はコードを書くことより、観測を変えること
AIが同じエラーを繰り返したとき、人間が取り戻すべきなのはキーボードではなく、問題を見る視点です。画面しか見ていなければ通信を見る。コードしか見ていなければ実データを見る。本番だけ壊れるなら設定差を見る。AIが同じ前提の中を回っているなら、人間が境界の外から新しい証拠を持ち込みます。
私が2回目から原因仮説を足すのは、人間の方が常に正しいからではありません。AIは広く速く探索でき、人間は実際に触れた結果と事業上の制約を知っている。両方をつなぐ方が、一方へ丸投げするより失敗から早く抜けられるからです。
次に同じエラーが2回続いたら、もう一度『直して』と送る前に、期待、実際、再現、仮説、合格条件の5行を書いてみてください。AIを使い続けるために、人間が介入する。私はその切り替えこそ、AIコーディングで最も重要なデバッグ技術だと考えています。
