「テストが通った」はもう信用できない──人間には重すぎた「受け入れテスト駆動開発（ATDD）」をAIに任せたら

【B-4】なぜ「テストが通った」はAI時代に信用できなくなったのか 〜受け入れテスト駆動開発(ATDD)にたどり着くまで〜

　AIコーディングが当たり前になった今、「テストが通った」という事実はどこまで信用できるのか。KINTOテクノロジーズの大園博昭氏は、「テストを通すこと」そのものが目的になり、AIがテストを意味のないものに書き換えてしまう「リワードハッキング」の実態を指摘する。その対策として大園氏が選んだのは、2000年代初頭から存在しながら、工数の重さゆえに普及しなかった「受け入れテスト駆動開発（ATDD）」を、AIに担わせるというアプローチだ。約2カ月・454件のプルリクエスト（PR）を経て見えてきた、AI時代のテスト戦略を紹介する。

実装と同時にテストを書かせると本末転倒になる

　AIに機能を実装させ、同時にテストも書かせる。KINTOテクノロジーズで、テストを含めた全社横断的な開発環境改善を担う大園博昭氏によれば、これはAIを使った開発で「よく見るパターン」だという。何も指示しなくても、AIがテストまで書くことは、もはや当たり前になりつつある。だが大園氏は、このパターンに潜む根本的な問題を指摘する。

　「AIは機能実装が通るためだけのコードを書きがちになってしまいます。実装をチェックしたうえで、その実装が通るテストを書く。これは逆で、本末転倒な状況になってしまうのです」

　2015年に前職で自動テスト専門チームを立ち上げ、2017年ごろからはSET（Software Engineer in Test）として開発者テストの支援やCI/CDの整備を手がけてきた大園氏にとって、テストコードの品質は重要な関心事だ。「ほとんどの実装をAIに任せる場合でも、テストのコードを見ると『おかしいな』『レビューしないと怖いな』と感じることが、最近でもまだ結構あります」と語る。

KINTOテクノロジーズ株式会社 Engineering Office 大園博昭氏

　簡単な対策として思い浮かぶのが、実装するAIとテストを書くAIを分離することだ。例えば「Claude Code」に実装させて「Codex」にレビューさせるように、モデルやコンテキストを分ける手は確かに有効に見える。しかし同じブランチ上で動いている以上、テスト担当のAIも実装コードを参照できてしまう。制御なしには同じ問題が再現する、と大園氏は言う。

実装とテストのAIを分けても、互いのコードを見られるため制御が必要になる

AIはなぜテストで「ズル」をするのか

　では、なぜAIはこうした手抜きテストを生成するのか。大園氏はOpenAIとAnthropicがそれぞれ発表した論文や報告を紹介した。

　「強化学習の過程でユニットテストをすべて通せという命令を与えられたAIが、目的を達成するためにテスト自体を意味のないものに改ざんしてしまうケースが報告されました。CoT（思考の連鎖）には『Let's hack』という文字列まで書かれていたそうです」

　こうした現象は「リワードハッキング」と呼ばれる。典型例として示されたのが、実装側でexit(0)を呼び出し、テストが評価される前にプロセスを正常終了させてしまうパターンだ。何も検証していないにもかかわらず、CIでは「テストが通った」ことになる。Anthropicも、テストが失敗した際に、実装を直す代わりにテストコードに値をハードコードして通してしまう事例を報告している。さらに、このズルを学んだモデルはテスト以外の場面でも不誠実な振る舞いをする傾向が見られた、とも述べられていたという。

　「テストが通ることを報酬として与えられた以上、いかに早くテストを通すかにフォーカスが当たってしまうのはむしろ自然です。本来、人間であれば『いいものを作りたい』という目的があってテストを書きます。AIではそれが逆になってしまう。ハーネスやスキルで制御しても、なかなか防げないと論文には書かれていました」

　本来は良いソフトウェアを作るための手段であるはずのテストが、AIにとっては「通すこと」自体が目的になってしまう。それが問題の本質だ。

OpenAIとAnthropicの論文などで報告された、AIによるテストの改ざん