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

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

人間には重すぎたATDDをAIに任せる

　AIが実装に合わせたテストを書いてしまうのは、テストが実装の後に書かれるからだ。それならば順序を逆にして、テストを先に書き、そのテストを通す実装をAIに書かせればいい。つまりTDDの発想だ。大園氏はここからさらに一歩進め、ファンクション単位ではなく「開発工程全体をTDD化できないか」という問いを立てた。

　そこにたどり着いたのが、ATDD（Acceptance Test-Driven Development、受け入れテスト駆動開発）だ。2000年代初頭から存在し、2008年ごろにElisabeth Hendrickson氏が講演で広めたとされるが、大園氏が「聞いたことがある方は？」と会場に問いかけると、手を挙げたのはごく一部だった。

　ATDDでは、ユーザーが「こういうストーリーを経験するとしたら満たすべき条件は何か」を、アクセプタンスクライテリア（受け入れ条件）として実装前に関係者で定める。それがそのままE2Eテストになる。

　流行らなかった理由は明確だと大園氏は話す。

　「面倒くさいんです。実装前にブラウザやアプリを実際に動かすようなE2Eテストを書かなければいけない。さらにATDDはチーム全体を巻き込む必要があるので、TDDのように個人で選択できるものでもありません」

　ATDDの普及に貢献した一人であるHendrickson氏自身も、2024年のコラム「Acceptance Test Driven Development (ATDD) Revisited」で「現実世界の開発には重すぎた」と認めている。

　しかし、状況は変わりつつある。10〜20年前と比べて自動テストまわりの技術は大きく進化し、今では部品単位にとどまらず、サービス全体の開発にAIを使うエンジニアも多い。こうした流れの中で、ATDDの名前を耳にする機会も少しずつ増えてきた。大園氏自身も、そうした変化を見るうちに、ATDDへの見方が変わっていったという。

　「人間にはつらくても、AIにやらせるのであれば別に大丈夫なのではないか。アクセプタンステストはAIに書かせればいいし、足並みをそろえるための実装前の設計もAIにアシストさせられます。AIに投げて夜中に実装してくれれば、時間がかかっても大丈夫ではないか。これが、ATDDとAIは相性がいいのではないかと考えたきっかけです」

外側と内側の「ダブルループ」でAIを制御する

　大園氏は、外側のATDDループと内側のTDDループを同時に回す手法を「ダブルループ」と呼び、AIにこのループを回させる仕組みを作った。

　まず外側のアクセプタンステスト（AT）を、次に内側のユニットテストを書く。どちらも実装がないので失敗する。ユニットテストを通す実装を積み上げ、外側のATも通れば1サイクルが完了し、まだ失敗するなら次のユニットへ進む。

外側のループでアクセプタンステスト、内側のループでユニットテストを回す「ダブルループ」

　外側のATはアクセプタンスクライテリアと1対1で対応させるのが定石で、内側の開発はTDDでもSDDでもBDDでもかまわない。ただ、アクセプタンスクライテリアが10個に及ぶ機能もあり、E2Eテストが増えればCIの時間や計算コストが膨らむ。そこで大園氏は、決済のようなクリティカルなユーザーパスだけを外側のE2Eテストにするやり方も試し、折り合いのつけ方を模索しているという。

　ただし、運用には1つ注意が必要だ。実装を担当するAIに、テストを修正させてはいけないと大園氏は強調する。

　「実装の途中でAIがテストをしれっと書き換えてしまうことがあります。書き換えられると最初の問題に戻ってしまい、本来ガードレールになるはずのテストが、何の意味もないものになってしまいます」

　テストの修正が必要なときは承認制にする、別のAIに任せる、前段の設計に戻るなど、実装中のAIに修正させない仕組みを用意しておくことが重要だという。