はじめに
最近、業務で「詳細設計をある程度固めてから、生成AIにテストファーストでコードを書かせる」という流れを試してみました。
結論としては、想像以上にうまくいき、特にテスト作成の負荷が大きく下がりました。
この記事では、実際にどのような準備をし、どのようにAIへ投げ、どんなメリットと課題があったのかを具体的にまとめます。
1. なぜ詳細設計＋テストファースト＋AIを試したのか
私が担当している領域は、抽象化すると次のような性質があります。
- 複数テーブルをまたぐ集計処理
- yyyyMMdd 形式の期間指定を使ったフィルタ
- 境界条件と例外系が多い
- 条件漏れが実害につながりやすい
こういった処理は、テストファーストにすることでロジックの抜け漏れを早期に見つけやすくなります。
一方で、人間が最初から大量のテストケースを書くと時間がかかります。
そこで、「仕様を丁寧に整理した状態で生成AIにテストを書かせるとどうなるか？」を試してみました。
2. 事前に用意したもの
AIに任せるとはいっても、投げる前の準備が重要でした。
実際に用意したものは次の通りです。
-
詳細設計書
- 入出力仕様
- 条件一覧
- 例外パターン
- 境界ケース
-
データフローの説明（文章で十分）
-
ディシジョンテーブル
- 正常、異常、境界条件を網羅
-
SQL要件
- 利用するテーブルと結合条件
- 期間条件（例：開始日含む/含まないなど）
特に「テスト観点が箇条書きで整理されている状態」が重要で、AIの出力のブレが大きく減りました。
3. draw.io は必須ではないと感じた理由
当初は draw.io でフローチャートを作っていましたが、最終的には「なくても問題ない」という結論になりました。
1. AIに渡すには一度テキスト化が必要になる
draw.io のままでは扱えないため、
- XMLを展開して中身を確認
- 必要な要素だけ抽出
- Mermaid 形式に書き直す
といった作業が入り、余計な工程が増えました。
2. 複雑なフローチャートは読み手が限定される
フローチャートは便利ですが、複雑になるほど「読む側に前提知識が必要」になります。
非エンジニアとのコミュニケーションにも使いにくい場面が多かったです。
3. シンプルな分岐なら文章の方が早い
むしろ、条件を箇条書きにしたテキストの方が修正しやすく、AIも確実に理解します。
結果として、AI前提で考えるなら「テキストの詳細設計」の方が扱いやすいと感じました。
4. 実際にAIへ投げたプロンプト（概要）
使った指示はシンプルで、毎回ほぼ同じです。
- 最初にテストコードを書く（Red）
- テストが落ちる理由付きで提示する
- テストを通すための最小実装を書く（Green）
- 最後にリファクタリング案を提示する（Refactor）
- テスト名は日本語にする
- DBは実DBを使い、モックは使わない
- ディシジョンテーブルの観点を漏れなく反映する
「まずはテストを書いてから始める」という流れを明確にすると、AIの挙動が安定しました。
5. やってみて良かった点
テストファーストの負担が軽くなった
AIがベースとなるテストコードを自動生成するため、こちらは次の作業に集中できました。
- 境界テストの追加
- 想定と異なる部分の修正指示
- データセットの見直し
まっさらな状態から書き始めるより圧倒的に速いです。
条件漏れがほとんど出なくなった
あらかじめディシジョンテーブルで観点を整理しているため、AIがすべて拾ってテスト化してくれます。
こちらが取りこぼしに気づく場面が減りました。
SQLや期間処理のミスを事前に発見しやすい
期間境界、集計タイミング、条件の解釈など、微妙なズレがテストの段階で露出します。
これは実装後に気付くより、はるかに効率的でした。
実DBを使うテストとの相性が良い
日本語のテスト名をテストエクスプローラーで一覧し、漏れに気づきやすくなった
これは特に効果を感じたポイントです。
テスト名を日本語で書くようにしているのですが、
生成されたテストをテストエクスプローラーで一覧すると、
- 想定していた観点が入っているか
- 表現が曖昧なテストがないか
- 抜けたテストがないか
- 類似テストの重複がないか
といったチェックが非常にやりやすくなりました。
「観点を視覚的に並べて確認できる」という点が、
生成AIのテストファーストと相性が良かった部分です。
6. 課題に感じた点
設計が曖昧だと誤解されやすい
要件が文章で曖昧なまま投げると、AI側で勝手に補完されてしまい、意図しない挙動になります。
情報が多すぎると理解がぶれる
一度に多くの仕様を渡すと、テストと実装の整合が崩れることがありました。
章ごとに分割する方が安定します。
Red → Green → Refactor を守らせるのに少し工夫が必要
AIは時々「実装先に書きたい癖」が出るため、進め方テンプレートの提示は必須でした。
7. ベストプラクティス
設計資料は「テストを書ける粒度」に落とす
細かく書きすぎず、次のレベルで十分です。
- 入出力仕様と前提条件
- 条件をすべて箇条書きにした一覧
- 境界ケース（期間、金額など）
- 正常系と異常系の整理
- 必要なテストデータ例
テストの進め方を最初に固定する
どの言語で、どの構成でテストを書かせるかを明確にすると、出力のばらつきが減りました。
ディシジョンテーブルを中心にする
AIは表形式の仕様が得意で、観点を並べると抜け漏れなくテストを生成しやすくなります。
大きな仕様は分割して渡す
期間 → 金額 → 条件A → 条件B
のように、小さく刻んで投げる方が安全です。
最後は必ず人間がレビューする
特に境界条件と例外系は慎重に確認しました。
8. 実務インパクト（主観）
実際に試してみて感じた効果は次の通りです。
- テストコードの作成が2〜3倍速くなった
- 実装の内容が安定し、ブレが少なくなった
- バグや取りこぼしが減り、QAのやり直しがほぼなくなった
- 設計→テスト→実装の流れがスムーズでストレスが少ない
特に、複雑な条件が多いドメインほど効果を実感しました。
まとめ
- draw.io のようなフローチャートは必須ではなく、テキストの詳細設計の方が扱いやすかった
- 仕様を箇条書きで整理するとAIが正確にテストを書いてくれる
- テストファーストの敷居がかなり下がる
- 仕様が複雑な領域ほどAIの効果が大きい
- 「AIに任せるための設計」を意識すると開発がスムーズに進む