AIに24時間開発させたら、人間が吸収していた曖昧さがレビューに戻ってきた

テスト駆動開発でAIに実装させるのは、もう標準的な使い方だ。テストが赤なら直させる。どこにも魔法はない。ところが、その状態で「席を立てるか」という問いは別だ。人間がいない状態で、最後まで無人で回せるか。その境界が思ったより手前にある、という記事の報告だ。著者は Jira のチケットを拾わせ、受け入れ条件を読ませ、テストを書かせ、実装させ、PR を作らせるという一連の作業を無人で24時間回した。止まることはなく、テストは緑だった。ただし返ってきたのは15本のPRと67件のレビュー指摘。テストが通っているのに「直してくれ」が次々出てくる。統計ではなく一度きりの実験だが、その一度が教えてくれた事実は重い。67件を分類すると、仕様整合23件、テスト7件、規約17件、命名6件、設計8件、実装バグ2件、差し戻し3件。うち45%が「要件の解釈が間違っていた」類だ。

AIの鬼が見る本質は、これが AIの能力不足ではなく「人間が何を提供していたか」という暴露だということだ。対話していれば、AIは曖昧なところで「どちらにしますか」と聞く。聞いてこなくても、同じ画面で実装を追っていれば気づける。その曖昧さを人間が無言で吸収していたのだ。席を立つと吸収する主体がいなくなり、曖昧さはそのまま実装として確定する。一覧の絞り込みをアプリ側でやるか DB側でやるか、エラーメッセージにどこまで情報を含めるか——どれも仕様には書いていなかった。書いていない以上、AI は何かに決めるしかなく、そう決めた事実は誰にも記録されないまま、レビューまで来ちゃった。いちばん恐ろしいのは「テストが通っているのに検証が失敗した」という状況だ。テストは「AI自身が解釈した要件に、AI自身の実装が適合している」ことだけを確認する。その解釈が間違っていれば、間違ったテストがそのまま固定される。独立した検証者がいないかぎり、この穴は検出できない。

だから気づくべき次の真実は、無人化には曖昧さが許されないということだ。「完全自動化するには仕様が明確である必要」ではなく、自動化しようとすると、明確さが要求される。記事の著者が次に試すのは、テストを書くセッションと実装するセッションを分離することだが、同じ受け入れ条件を同じモデルが似たコンテキストで読めば、解釈の誤りは相関したまま残るだろう。ここが、中小企業がAIエージェントで社内システムを自動化するときのいちばん大きな落とし穴だ。「AIなら無人で回る」という期待は、その前に「要件が明文化される」という条件を満たす必要がある。曖昧さを許容する部分が残っている限り、AIの出力は常に人間の検収を必要とする。