AIに仕様だけ渡してテストを書かせたら全部緑。それでも実装変更は3件必要だった

AIに実装を任せると、テストも自動で付いてくる。これまでの経験則では「テストが全部通った＝実装は正しい」だった。だが、この記事が示しているのは、その安心が本当には担保されていない、という怖い話だ。事例は返金計算。月額料金から解約日までの日割り返金額を計算し、その結果を決済プロバイダのAPIに直結させる。金銭・外部送信が関わるので、やり直しは効かない。

著者は3つの独立したセッションを走らせた。実装側、テスト側、仕様検証側。結果、テストは83ケース全部緑だった。一見、完璧だ。しかし人間が仕様を読み直して「決められなかった点」をリストアップすると、14件の曖昧さが出てきた。その中から3件の実装変更が必要だと判明する。最も刺さったのが税金の話だ。引数は「月額（税抜）」なのに、返り値は税込額で決済プロバイダに渡される。返金が約10％不足してしまう。これはテストでは原理的に出ない。実装も仕様も技術的に正しくても、仕様の内部矛盾は検出されないからだ。

ここが「AIコード生成の本当の危険」だ。コードの書き方の誤りは、テストや静的解析で見つかる。しかし仕様レベルの矛盾——「外部システムとの接続で何が起きるか」「税計算をどこで入れるか」といった業務ロジックの一貫性——は、人間がコンテキストを読み直さないと出てこない。AIテストが全部通ったからといって、それは「仕様の矛盾がない」ことの証拠ではなく、「テストが仕様と同じ読み間違いをしている」可能性もあるということだ。製造業の設計業務やメディアの企画業務でAIを使う場合、「AIが勝手に書いた提案がすべて妥当か」を、人間がビジネス視点で再検証する工程は絶対に省略できない。