AIとテスト駆動開発：先にテストを書かせる指示法
実装を先に頼んでからテストを書かせると、テストは実装に合わせて甘くなりがちです。先にテストを書かせ、それに合格する実装を後から書かせる順番にするだけで、品質は大きく変わります。
最終更新: 2026-07-23・読了目安 約3分
テスト駆動開発とは何か
テスト駆動開発とは、実装より先に「その機能が満たすべき条件」をテストとして書き、そのテストに合格するように実装を進める開発の進め方です。先にテストを書くことで、「何ができれば完成か」が明確になり、実装が終わった後に確認漏れが起きにくくなります。この進め方は1990年代にKent Beck氏が体系化したもので、Martin Fowler氏によるTest Driven Developmentの解説でも、テストと実装の短いサイクルを繰り返す手法として紹介されています。
AIコーディングエージェントに開発を任せる場合、この順番は特に効果を発揮します。実装を先に頼んでからテストも書いてもらうと、AIは自分が書いた実装を正当化するようなテストを書いてしまうことがあり、本来見つけるべき不具合を見逃しやすくなるためです。
先にテストを書かせる指示の型
AIに次のような順番で指示を出すと、テスト駆動開発の流れに沿った進め方になります。
- 1. 受け入れ基準を伝える：「〜のとき、〜になれば正しい」という条件を先に共有する
- 2. テストだけを書かせる：「まだ実装はせず、この条件を確認するテストコードだけ書いてください」と明示する
- 3. テストが失敗することを確認する：実装がない状態でテストが失敗するのは正しい状態。ここで一度、テスト自体が意図通りに動くか確認する
- 4. テストに合格する最小限の実装をさせる：「このテストに合格する実装を書いてください」と依頼する
- 5. テストが通ることを確認する：全テストが合格した状態を確認してから次の機能に進む
この受け入れ基準は、要件定義書の書き方やDESIGN.mdテンプレート実例で作った受け入れ基準の項目をそのまま流用できます。
「実装に自分で気づいていないバグ」を防ぐ効果
先にテストを書く最大の効果は、実装者（この場合はAI）が自分の実装に都合の良いテストを書けなくなることです。例えば「空の入力を渡すとエラーになる」という条件を、実装完了後に追加でテストしようとすると、たまたま実装がその条件を無視していた場合、テストの方が甘く書かれてしまうことがあります。先に条件を固定しておけば、実装がその条件を満たしているかどうかを、後からブレなく判定できます。
小さな機能単位で繰り返す
テスト駆動開発は、大きな機能全体に一度に適用するよりも、小さな機能単位で「テストを書く→実装する→確認する」のサイクルを繰り返す方がうまくいきます。一度に多くの条件を積み上げると、どのテストがどの実装に対応しているかが把握しづらくなるためです。1つの機能を確認できたら、次の小さな機能に移る——このリズムを保つことが、AIとのテスト駆動開発を安定させるコツです。テストで動作が保証されている状態は、後からリファクタリングを安全に頼むための土台にもなります。
よくある失敗パターン
- 実装とテストを同時に頼む：どちらが先に書かれたか曖昧になり、テストが実装に迎合しやすくなる。
- テストが失敗する状態を確認しない：テスト自体が壊れていて常に合格してしまう状態に気づけない。
- 一度に多くの機能のテストを書かせる：条件と実装の対応関係が追いづらくなる。
- テストが通ったら中身を確認しない：合格したテストの内容自体が本当に意図した条件を検証しているか、時々読み返す必要がある。
よくある質問
Q1. テスト駆動開発では、なぜ実装より先にテストを書くのですか？
実装を先に書くと、実装者（AI）が自分の実装を正当化するようなテストを書いてしまい、本来見つけるべき不具合を見逃しやすくなるためです。先に条件を固定しておくことで、実装がその条件を満たしているかをブレなく判定できます。
Q2. AIコーディングエージェントにテストだけを先に書かせるにはどう指示すればいいですか？
「まだ実装はせず、この受け入れ基準を確認するテストコードだけ書いてください」と明示します。実装がない状態でテストが失敗することを確認してから、合格する最小限の実装を依頼する順番が基本です。
Q3. テスト駆動開発は大きな機能にも一度に適用できますか？
大きな機能に一度に適用するより、小さな機能単位で「テストを書く→実装する→確認する」のサイクルを繰り返すほうがうまくいきます。一度に多くの条件を積み上げると、どのテストがどの実装に対応しているか把握しづらくなります。