AIとテスト駆動開発：先にテストを書かせる指示法
AIコーディングエージェントに実装を任せるなら、先にテストを書かせるTDD（テスト駆動開発）が手戻りを減らす近道です。基本の考え方と、そのまま使える指示プロンプト、AIが書いたテストを鵜呑みにしないためのチェックポイントをまとめました。
テスト駆動開発（TDD）とは何か
TDDは「テストを先に書き、それを通す最小限の実装をし、最後に整える」というサイクルを繰り返す開発の進め方です。一般にRed（失敗するテストを書く）→ Green（最小実装で通す）→ Refactor（整理する）の3段階と説明されます。この定義はソフトウェア開発の第一人者であるMartin Fowler氏が公開している解説記事にまとまっています。
AIコーディングエージェントとの相性が良いのは、テストが「何を実装してほしいか」を人間とAIの間で共有する受け入れ基準そのものになるためです。自然文の指示だけだと解釈がぶれやすい部分も、テストコードという実行可能な形にしておけば、AIの出力が期待どおりかを機械的に確認できます。
AIに先にテストを書かせる3ステップ
ステップ1：要件を受け入れ基準に分解する
いきなり「テストを書いて」と頼むと、AIは何を正解とすべきか判断できません。先に「入力が空文字ならエラーを返す」「同じメールアドレスは登録できない」のように、受け入れ基準を箇条書きで渡しましょう。要件を分解する具体的な書き方は仕様駆動開発の記事でも扱っています。
ステップ2：失敗するテストを書かせる指示文
受け入れ基準を渡したら、実装より先にテストだけを書かせます。指示文の例は次のとおりです。
- 「以下の受け入れ基準をもとに、実装コードは書かずにテストコードだけを書いてください」
- 「今の時点でテストは失敗して構いません。まず失敗することを確認してから次に進みます」
- 「境界値（0件・1件・上限値）のケースも含めてください」
ステップ3：最小実装で通してからリファクタする
テストが失敗することを確認したら、そのテストを通す最小限の実装をAIに指示します。通った後の整理は範囲を絞って段階的に進めるのが安全です。進め方はリファクタリングの頼み方の記事で詳しく解説しています。
AIが書いたテストを鵜呑みにしないためのチェックポイント
AIはテストを「通すことが目的化」しやすく、アサーションが緩い（何でも通ってしまう）テストを書いてしまうことがあります。公開前に次の3点を確認してください。
- アサーションが具体的か — 戻り値の型だけでなく、実際の値や件数まで検証しているか。
- 回帰テストとして再実行できるか — 後から機能を追加したときに、既存のテストがそのまま壊れの検知に使えるか。
- レビューの観点を指定して依頼したか — 「このテストで検知できないケースはあるか」をAI自身にも聞き返すと精度が上がります。依頼文の型はレビュー依頼文例集の記事にまとめています。
テストとレビューを組み合わせた全体のチェックリストはAIが書いたコードのテストとレビューの記事もあわせて参考にしてください。
よくある質問
TDDは初心者でも取り入れられますか？
取り入れられます。むしろ実装経験が浅いうちほど、先に受け入れ基準とテストを言語化しておくとAIとの認識ズレに気づきやすくなります。最初は1機能ずつ、小さな単位で試すのがおすすめです。
テストを書く分、開発が遅くならないですか？
テストを書く指示を出す分、最初の一手は増えます。ただし手戻りや仕様の勘違いによる修正が減るため、機能単位で見るとトータルの時間は短くなりやすい傾向があります。
個人開発でもTDDは必要ですか？
すべての処理に必要というわけではありません。お金の計算やログイン処理など、間違えると困る中核ロジックから優先的に取り入れると効果を実感しやすいです。