AIテストは信用できる? AIテストの外堀の埋め方

こんにちは、横井です。

前回はAIコーディングに対する品質担保についてお話ししました。結論としては人がコーディングしようが、AIがコーディングしようが、設計通りに実装できているか? を確認するにはテストが必要。というごくごく当たり前の話でした。(笑)

もう一つは生成AIでもテストコードは生成可能という話です。しかし、そのテストコードがどれだけ信頼できるかは、作成方法や段取りに大きく依存する問題でもあります。

一般的な開発プロセスでは、まず設計を行い、次にアプリケーションコードを作成し、最後にテストコードを作成するという流れになります。しかし、その場合、テスト実行時にエラーが発生した際、問題がアプリケーションコードにあるのか、テストコードにあるのか判断が難しくなるという課題があります。これはAIコーディングに限らず、スクラッチでの開発においても同様の悩みとなります。つまり、アプリケーションコードの品質を担保するためにテストコードが必要となり、そのテストコードの品質を担保するためにさらにテストコードが求められる、いわゆる「テストコードの無限ループ」問題に突き当たります。

このような問題に対する解決策として、TDD（テスト駆動開発）の手法が提唱されています。TDDとは、アプリケーションコードを作成する前に、まずテストコード、すなわちテストケースを作成し、その状態で初めてアプリケーションコードを実装するという流れです。常にテストコードを実行し、テスト結果がグリーン（合格）の状態を維持することを重視する考え方です。

ただし、TDDのポイントは単にテストコードを先に作成することではなく、まずはテストケースを漏れなく洗い出すことにあります。そしてそのためには、十分な設計が不可欠です。設計が整っていなければ、網羅的なテストケースの洗い出しは難しくなります。つまり、TDDとは、テストコードを作成するためにテストケースを検討し、その検討のために設計をしっかり行うという、一連の決められたプロセスに基づいてワークフローを回すことが肝心なのです。

以上の話はスクラッチ開発での一般的な話ですが、実際にはこの方法論はAIコーディングにおいても十分に適用可能です。常にテスト結果を確認しながら開発を進めることで、生成AIの高速なコーディング能力と、求める品質の両立が実現できると考えます。

では。

---

すみません、追記です。

TDDを実践することでコードの品質を上げることができると書きましたが、この場合当然の事ながらテスト実行の回数が増えます。CLIベースのテストツールだと、テスト実行中のモニタリング情報を秒単位で出力します(画面でリフレッシュさせているような感じ)。結果として、例えばエラーが1つしか出なくても、テストが完了するまでのモニタ表示用の出力が延々と続き、結果としてLLMへの送信量が莫大になります。しかも、膨大なログを解析するの時間もかかり、結果一つしかエラーが無いとか、エラーがゼロとかだと、API呼び出しの待ち時間とコスト消費が馬鹿になりません。(あっという間にチャージしたクレジットが溶けていきます)

これはAIコーディングを品質良く実施する事の可否と、技術的コスト的問題は別物であるという事です。なので、私のブログを見たからといってすぐさまTDDに取り組むのであればそれなりのお金の消費を覚悟する必要があります。

では。