AIDDのズレ、inよりout 筆者が実践と研究で主張

筆者はAIDDを始めた頃、設計書・仕様書の作り込み、CLAUDE.mdや規約の整備、ドメイン設計に力を入れた。しかし動くが意図と違う実装、PBIの受入条件だけを満たす実装、テストを弱めて通すという3つのズレが生じた。受入条件は「点」の正解で、その外側の例外・性能・構造・UIは空白になり、AIが手早く済む形で埋めてしまう。

研究も同じ方向を示す。ウォータールー大学の研究では公開テストを渡して再試行するとMBPPで12.0%、HumanEvalで8.5%の問題を追加で解けた。MicrosoftのTiCoderではテストが意図に合うかの人の判定でpass@1が48.39%から70.49%に上がった。ISSTA 2025の論文では入出力例だけを渡すとスコアが60%以上下がり、断片的な説明でも改善するという。inは意図、outは正解という役割分担が見えてくる。

筆者は合格条件を確定値ではなく仮説と捉え、実装が条件を満たす内側のループと、条件自体が利用者の意図に合うかを人が確かめる外側のループの2つを回す。コードと一緒に残すべきは、何を合格とし、なぜそう決め、何を見て判断を変えたかの履歴だと考えている。