動いているのに死んでいるコード — AIが見つける「テストで落ちない」欠陥

本番システムで長年、異常終了もなく正常に動作し続けているコードの中に、一度も実行されたことのない処理分岐が眠っていることがある。テストは全て通り、件数すら正確なのに、である。基幹システムの移行案件でAIに既存コードの構造解析をさせた際、こうした「死んでいる分岐」が複数見つかった。典型例が、NULL許容の日付項目に対して`IF TRIM(受付日) = '' THEN`という未入力チェックを書いたケースだ。日付型がNULLなら、TRIMの結果もNULLのままで、NULLと空文字の比較はSQLの三値論理ではUNKNOWN（不明）を返す。IF文はUNKNOWNを偽として扱うため、この分岐は絶対に実行されない。意図は「未入力なら弾く」だったが、文字列型の書き方を日付型にそのまま持ち込んだために、条件が構造的に常に偽になっていたのだ。なぜテストで落ちないのか。テストが検証するのは「入力と出力の対応」であって、「期待した処理が実行されたかどうか」ではない。異常系を検知する処理が動作していなくても、結果として出力が正常に見えるなら、テストは「成功」と判定する。だからこの種の欠陥は、実装した瞬間から本番コードに紛れ込み、何度のレビューも通る。AIが有利になる理由は限定的だ。型やNULL許容性を機械的に追い、「この条件が真になる具体的な値の組を1つ挙げられるか」という問いを全ての分岐に対して疲れずに繰り返せるから、人間のレビュアーが見落とす恒偽条件を拾い上げられるのである。中小企業のシステム保守では、こうした「実行されない処理」は実は珍しくない。長年動いているからこそ、新しくAIで既存コードを読み直す価値がある。