AIデバッグはなぜ収束しないのか？P2が消えない原因と終了条件

CodexなどのAIコーディングエージェントを利用してコードレビューと修正を繰り返していると、通常のバグ修正とは異なり、優先度の低い問題が何度直しても出続ける現象が見られます。なぜ有限なはずの問題がゼロに近づかないのか、その構造的な理由とデバッグを収束させるための手順が整理されています。

直したはずの問題が再発するのはなぜ？

AIにプログラムコードを点検させ、見つかった箇所を修正して再レビューを依頼するサイクルは、多くの開発フローで取り入れられています。このレビューでは、発見した問題の重大度を整理するためにP0からP3といった優先度表記が使われるのが一般的です。P0はリリースを阻害する致命的な不具合、P1は緊急で対応すべき重要な問題、P2は通常対応としていずれ修正すべき一般的な問題、P3は影響が小さい軽微な問題を指します。

通常の手作業によるデバッグであれば、10件あった問題は修正を重ねるごとに7件、4件、1件と順調に減少し、最終的には0件に達するという見通しが立ちます。しかし、AIエージェントにP2の問題を修正させると、前回の指摘をすべて解消したはずなのに、次回のレビューで再び別のP2や同様のP2が検出される現象が発生します。

修正しても修正しても新しいP2が出現し続けると、作業の終わりが見えなくなり、API利用料や時間のリソースが消費され続ける原因となります。

P2が減らない背景にある3つの要因

AIデバッグにおいてP2が解消しにくい現象は、AIの不具合ではなく、探索の性質とプログラムの構造が組み合わさることで発生します。具体的には、最初から存在していた問題の小出し発見、修正に伴う新たな問題の発生、そして着眼点による判定の揺らぎという3つの要因が重なっています。

第1の要因は、コード全体に元から潜んでいた問題をAIが一度に数え上げず、段階的に見つけ出す点です。AIはレビューを行うたびに対象コードをあらためて探索するため、仮に最初から10件のP2が存在していても、1回目に3件、2回目に別の3件、3回目に2件といった形で提示されることがあります。修正によって問題が増えたのではなく、未発見だった既存の問題が小出しに出力されている状態です。

第2の要因は、コード間の相互依存によって修正箇所が別の問題を生み出す現象です。プログラムは複数の部品が連動して動作しているため、問題Aを修正した結果として別の問題Bが発生し、問題Bを直したことで問題Cが引き起こされるケースがあります。状況によっては、問題Bの修正によって当初直した問題Aが再発する循環も生じるため、P2を1件修正しても全体の件数が減らない結果につながります。

第3の要因は、文脈や前提条件によってP2かどうかの判断が変わる点です。アプリのクラッシュやデータの破壊といったP0やP1の致命的な問題とは異なり、P2には仕様の解釈や周辺コードの前提に依存する項目が多く含まれます。たとえば、呼び出し元が不正な入力を排除しているか、例外をその場で捕捉すべきかといった判断は、見る角度によって結論が分かれます。大規模言語モデル（LLM）は毎回完全に同一の観点でコードを走査するわけではないため、着眼点の変化によって同じコードに対する判定が「問題なし」と「P2」の間で行き来します。

レビューと修正の工程を分けると何が変わる？

P2の無限ループを回避するアプローチとして、探索と変更を別々のフェーズとして切り離す手法があります。指摘が出るたびに即座に修正コードを書かせるのではなく、問題を網羅的に洗い出す段階、発見した内容をまとめて反映する段階、そして変更による副作用がないかを検証する段階の3工程に分離します。

最初の段階ではコード自体の変更を行わせず、レビュー対象のファイルだけでなく、呼び出し元や関連するテストまでを含めて全体を探索させます。CodexのようなAIエージェントは1回の指示で数件の指摘を出すと探索を終了してしまう傾向があるため、プロンプト側で探索の継続を明示する手法が有効です。

具体的な指示文としては、「今回は修正しないでください。まずレビューだけを行ってください。P0〜P2の問題を可能な限り一度ですべて列挙してください。問題を数件発見しても探索を終了せず、対象範囲全体のレビューが完了するまで続けてください」といった形式が挙げられます。探索範囲を広げて網羅的に出力させることで、数件ごとの小出し修正による往復回数を抑える構成をとります。

AIの判定をテストコードで固定する仕組み

P2が出続ける状況にあっても、検出された指摘そのものを無視して放置するわけではありません。提示されたP2が実際の動作環境において本当に問題となるのかを検証し、該当する不具合を再現するテストコードを書き加える手順が取られます。

AIが提示したP2に対して検証を行い、必要な修正を加えた上で再現テストを追加すると、評価の基準が変化します。AIモデルによる「問題かもしれない」という推論ではなく、「自動テストが通るかどうか」という客観的で機械的な基準に置き換わります。

テストコードとして期待する振る舞いを固定しておけば、その後のレビューでAIの着眼点が変わったり別の観点から指摘が入ったりしても、過去に修正した不具合が再発していない事実を自動実行によって確認できます。

終了条件を「P2ゼロ」以外に置く判断基準

デバッグ作業を終わらせる合図として、AIの画面上で「P2が0件」になる状態を目指すと、着眼点の揺らぎによって作業が停止しなくなります。そのため、AI自身の指摘件数だけに頼らない明確な終了判定をあらかじめ設定する運用が有効です。

具体的な判定基準としては、P0およびP1の深刻な不具合が0件であること、重大と判断したP2の検証と修正が完了していること、修正箇所に対応するテストコードが追加されていること、そして構文チェックを行うLintやデータ型の整合性を確認する型チェック、ビルド処理が正常に通っていることなどが挙げられます。

もし同一のP2指摘が何度も繰り返される場合には、修正命令を出し続けるのではなく、「コードは変更せず、この問題が繰り返し指摘される原因を分析してください」とプロンプトを変更し、原因の究明へタスクを切り替える選択肢もあります。

AIデバッグの構造的な性質と具体的な運用方法については、npaka氏による解説記事において詳細な背景と対策が述べられています。AIの探索特性を理解した上で、人間による検証と自動テストを組み合わせる体制が整えられています。