緑のテストが何も保証していないとき —— 受け入れ前にわざと壊す4つの型

AIに実装させ、AIがテストを書き、そのテストが「全件通過」と報告する。この完璧に見える報告ループの中に、構造的な盲点がある。実装も検査も同じ相手がしているので、実装者が試していない箇所は、テストの網目をすり抜ける。AI師範が実測したデータは苦いものだ。540件の発注のうち、テストが緑で通ったのに後で修正が必要になったのが20件。倍率にして4.8%。20分の1に見えるが、この1件は最も気づきにくい場所、つまり「テストが緑だったから確認しなかったところ」に潜んでいる。

対策はミューテーションテストだが、適当に壊してはいけない。実装者はすでに壊しやすいと思った箇所は自分で試しているからだ。同じ場所を試しても何も見つからない。そこで師範は実践の中で4つの型に収束させた。ガード自身を壊す、現実の流れ方向に壊す、複合条件のうち片方だけ孤立させる、一度も踏まれていない分岐条件を反転させる。型を決めておく理由は、決めないと毎回いちばん壊しやすいところを壊してしまうからだ。つまり、検査の質は「何を試したか」ではなく「試していない場所を意図的に作るか」で決まる。

中小企業がAIに仕事を任せるとき、この構造は必ず現れる。納品前の受け入れで「テストは全件通った」という報告を受けたら、自分たちで1回わざと壊してみる。鳴らなければ、そのテストはそこを見ていなかった。緑は「大丈夫」の証明ではなく、「ここを試した」のしるしにすぎない。この区別が、AIとの仕事の信頼性を決める。