AIに書かせたテストは、バグごと仕様を固定する

テストもコードもAIが書く現場

AIにコード生成を任せる開発現場では、実装と一緒にテストコードまで生成させることが増えている。関数を書かせ、その関数が満たすべき条件をテストとして書かせ、両方が一括で出力される。効率は良い。だが効率の良さは、テストが本来担っていた役割——実装から独立した検証——を静かに掘り崩す原因にもなる。

具体例で考える。ある通販サイトで、10%割引のクーポンと20%の会員割引を併用できる仕様を実装させたとする。正しい仕様は「割引を掛け合わせる」方式で、価格に (1 - 0.1) × (1 - 0.2) = 0.72 を掛け、1000円の商品なら720円、割引率は28%になる。AIが生成した実装がこの掛け算ではなく足し算で0.1 + 0.2 = 0.3を計算し、価格に0.7を掛けて700円を返してしまったとする。テストの期待値が720円のまま書かれていれば、このテストは失敗し、これは正常な検証だ。

期待値を実装に合わせる、という選択

テストが失敗したとき、対応は大きく二つに分かれる。一つは実装の掛け算ロジックを修正し、720円を返すようにすることで、これはバグを終わらせる対応であり延命とは正反対だ。もう一つは、期待値の方を700円に書き換えてテストを通すことだ。この一回限りの書き換えは実装のバグをそのままコードに残し、テストという監視装置だけを黙らせる。バグは消えず、「テストが通っている」という誤った安心感の中で延命する。

だが、もっと厄介なのは個々の書き換えそのものではない。「テストが落ちたら、まず期待値を実装の出力に合わせる」という対応を習慣にすることだ。AIにテストの再生成を任せていると、この習慣は簡単に定着する。失敗したテストを見せて「直して」と頼めば、AIは実装を直すこともあれば、期待値を実装の出力に合わせて書き換えることもある。どちらが起きたか人間が確認しなければ、テストは仕様の代弁者であることをやめて実装の出力に追従する鏡になり、これは個別のバグの延命とは別の、テストという仕組み全体の機能不全だ。

期待値はどこから来るべきか

網羅性の高さや、アサーションの細かさは、良いテストを語るときによく持ち出される尺度だ。だがこれらは期待値が正しいという前提の上に成り立つ。700円という誤った期待値を、より多くの入力パターンで、より細かい粒度で確認したところで、確認しているのは「実装が一貫して間違っている」という事実に過ぎない。網羅性と粒度は期待値の土台の上に積み上がるものであり、土台が誤っていれば積み上げるほど誤りが強化される。

これを避ける厳密な方法は一つしかない。期待値を、実装を動かして得られた出力からではなく、仕様書や計算式など実装から独立した情報源から導出することだ。720円という数字は「掛け算方式で割引を併用する」という仕様から手計算で出せる値であり、実装のコードを一度も読まずに書ける。この順序——先に仕様から期待値を確定し、後から実装の出力と照合する——を守らない限り、テストは何を検証しているのかという問いに答えられない。

現実的な妥協としての人間レビュー

とはいえ、生成されるテストの数が数百に及ぶ現場で、すべての期待値を人手で仕様から独立に計算し直すのは非現実的だ。ここで採れる現実的な妥協は、期待値を仕様と突き合わせる人間のレビューを、全件ではなく重要な分岐やお金が絡む計算などリスクの高い箇所に絞って行うことである。これは前節で述べた厳密な方法の代替ではなく、コストの制約下でその方法を部分的にしか適用できないときの次善策にすぎない。抜き取ったレビューをすり抜けた期待値は、依然として実装の鏡である可能性を残す。

割引計算のように金額に直結する処理では、この妥協すら省略しない方がいい。AIが書いたテストが通っているという事実は、実装が仕様通りだという証拠にはならない。期待値がどこから来たかを確かめない限り、テストは検証ではなく追認になる。