AIレビューのP2を消し続ける前に、デバッグの終了条件を決める

AIにレビューを頼み、指摘を直し、もう一度レビューする。それでもP2が残るとき、指摘件数だけを追っていても、作業が進んだのかは分かりません。公開記事「AIデバッグはなぜ収束しないのか」が扱っているのは、この修正ループです。

記事の軸は、AIレビューを「確定済みのバグ一覧を消す作業」と捉えないこと。Codexの公開レビュー基準も合わせて読むと、指摘を増やすことと、不具合を確かめることを分ける必要が見えてきます。

同じP2でも、増えた理由は違う

参照記事は、指摘が残る理由を三つに分けています。以前からあった不具合を後から見つける場合、修正で別の不具合を作る場合、そして仕様や入力の前提によって判定が揺れる場合です。

最初のケースなら、コードと評価基準を固定したまま探索を続ける意味があります。二つ目なら、修正が壊した経路を調べるべきでしょう。三つ目で先に必要なのは変更ではなく、「その入力は実際に届くのか」「呼び出し側が何を保証するのか」の確認です。同じP2というラベルでも、次の作業は変わります。

Codexの公開リポジトリにあるレビュー基準では、P2は通常の優先度で、いずれ修正すべき問題とされています。ただし、優先度は指摘が正しいことの証明ではありません。同じ基準は、明示されていない前提に依存した指摘や、他の箇所が壊れるかもしれないという推測だけの指摘を避けるよう求めています。

なお、GitHub連携の公式ドキュメントは、報告対象をP0とP1に絞ると説明しています。ここで考えるP2の修正ループは、P2まで扱うレビュー運用の話であり、GitHub連携の既定動作と同一ではありません。

参照記事が提案するのは、探索・修正・回帰確認の分離です。まずコードを変えずに、対象範囲、呼び出し元、テストを調べて指摘を集める。その後で修正し、別の経路を壊していないか確認します。

ここではレビュー範囲も揃えたいところです。Codexの公開基準は、変更で導入された不具合を対象にし、既存の不具合は指摘しない方針です。リポジトリ全体の不具合探索と差分レビューを混ぜると、「前回はなかった指摘」の意味まで変わってしまいます。

指摘を採用する前には、発生する入力や環境、影響を受ける呼び出し箇所を確かめます。本当に不具合なら、再現するテストを残して修正する。前提が違うなら、仕様や呼び出し側の保証を確認する。レビューの言い方が変わるたびにコードを直すのではなく、判断の根拠を残すわけです。

「すべて列挙して」と頼むだけで網羅性が保証されるわけでもありません。公開基準にはすでに、最初の指摘で止まらず、条件に合う指摘をすべて返す旨が書かれています。指示を強めるだけでなく、探索範囲と検証方法を決めるほうに目を向けたいところです。

参照記事は、P0・P1が残っていないこと、重要なP2の検証と修正、回帰テストの追加、必要な型チェック・Lint・ビルドなどの成功を、終了条件の例に挙げています。これはP2を無視するという話ではありません。何を確かめたら修正済みと扱うかを、AIの再判定だけに委ねないという提案です。

同じ指摘が戻ってきたら、いったん変更を止めて原因を分析する。テストが通っても未検証の経路は残りえますが、少なくとも確認済みの条件は次のレビューへ持ち越せます。次にP2が出たときは、件数を減らす前に「これは未発見の問題か、回帰か、前提の食い違いか」を切り分けるところから始めたいと思います。