AIがコードを書く量が増えるほど、そのコードが正しいことをどう確かめるかが問題になります。そこで再び注目されているのがテスト駆動開発（TDD）ですが、AIと組み合わせるときには落とし穴があります。

この記事では、テスト駆動開発とAIの組み合わせが再注目される理由と噛み合わない理由を整理したうえで、Red・Green・Refactorのサイクルを回す手順、単体・結合・総合・受入の4種別でテスト工程をどう設計し、どこまでAIに任せるかを判断する基準を解説します。開発プロセス全体の考え方はAI駆動開発（AIDD）とはで扱っています。

テスト駆動開発（TDD）とは

テスト駆動開発は、実装より先にテストを書き、そのテストが通るように実装を進める手法です。失敗するテストを書く（Red）、通す実装を書く（Green）、整理する（Refactor）というサイクルを小さく回します。

提唱者のKent Beckは、この手順をCanon TDDとして整理しています。確かめたい振る舞いのリストを作る、そのうち1件だけを実行可能なテストにする、そのテストと既存のテスト全部が通るようにコードを変える、必要ならリファクタリングする、リストが空になるまで繰り返す、という流れです。Beckはこの手順の狙いを、動いていたものが動き続け、新しい振る舞いが期待どおりに動き、次の変更に進める状態を保つことだと説明しています。

順番そのものより、「何が正しいか」を実装より先に言語化するという性質が本質です。これがAIに実装を任せる場面で効いてきます。AIは指示されたものを作りますが、何が正しいかを勝手に決めてはくれません。

TDDの定義と背景はMartin Fowlerの解説がまとまっています。

AI時代にテスト駆動開発が再注目される理由

TDDは新しい手法ではありません。それがAIコーディングの普及とともに再評価されているのは、AIの弱点をちょうど補う性質を持っているからです。理由は3つに整理できます。

AIが生成したコードを検証する基準を先に持てる

AIの出力は確率的で、同じ指示でも毎回同じコードが返るとは限りません。見た目がもっともらしいコードでも、仕様とずれていることがあります。実装より先に書いたテストがあれば、生成されたコードを人の目視ではなく、機械的な合否で検証できます。レビューの負荷が実装量に比例して増えていく状況への、実務的な答えになります。

テストが仕様として機能し、AIへの指示が明確になる

自然言語の指示には曖昧さが残りますが、期待する入力と出力をテストとして渡せば、達成条件が一意に決まります。Claude Codeの公式ベストプラクティスでも、機能の説明だけを渡すのではなく、期待する入出力の例をテストケースとして添えることが推奨されています（2026年8月時点）。テストを書く行為が、そのままAIへの仕様伝達になります。

AIがテストを実行しながら自走できるループを作れる

前掲のClaude Code公式ドキュメントは、AIに自分で実行できる検証手段（テストスイートやビルド）を渡すことを勧めています。合否の信号があれば、AIは実装、テスト実行、結果の確認、修正というループを人が張り付かなくても回せるからです。逆に検証手段がないと、間違いに気づく役割がすべて人に残ります。テストを先に用意するTDDは、この自走ループの前提条件を最初から満たします。

テスト駆動開発とAIが噛み合わない2つの理由

TDDとAIは相性が良さそうに見えますが、素直に組み合わせると検証として機能しなくなることがあります。

実装とテストを同じAIに書かせる

同じAIに実装とテストの両方を書かせると、テストが実装の写しになります。実装が間違っていても、その間違いを前提にしたテストが書かれるので、当然通ります。テストは通るのにバグは残る、という状態です。

避けるには、テストの根拠を実装とは別のところに置きます。要件やユーザーストーリー、受け入れ基準といった上流の成果物からテストを起こし、実装はその後に生成させる。仕様駆動開発（SDD）が仕様を一次情報として先に固めるのは、同じ問題への対処です。前掲のClaude Code公式ドキュメントも、一方のセッションにテストを書かせ、別のセッションにそれを通すコードを書かせる分担を挙げています。

KDDIアイレットのAIDDスキームでは、これを運用に落とすために、受け入れ条件をGherkin形式で事前に合意し、E2Eテストの自動生成にはその受け入れ条件を入力として使います。テストの根拠が実装コードではなく、合意済みの仕様に固定される形です。

テストを先に一括生成する

「TDDだから先にテストを書く」と考えて、AIにテストをまとめて全部書かせるケースがあります。これはTDDのサイクルとは別物です。Beck自身、Canon TDDでよくある誤解の筆頭に「テストを事前に全部書くこと」を挙げ、テストは開発を進めながら1件ずつ起こすものだと明示しています。

TDDが機能するのは、小さく書いて小さく通し、そのたびに設計を見直すからです。最初に大量のテストを生成すると、見直しの機会が消え、後から大量の修正が必要になります。テストの量が増えること自体は品質の向上を意味しません。

一括生成に使いどころがないわけではありません。仕様が確定している既存機能に回帰テストを後付けする場面では、まとめて生成して人がレビューする進め方が現実的です。ただしそれは既存の振る舞いを固定する作業であって、これから作るものの設計を駆動するTDDとは目的が違います。両者を混同せず、別の作業として扱うことが判断の起点になります。

テスト駆動開発をAIと進める4つの手順

Canon TDDの流れを、AIとの分業に置き直すと次の4手順になります。どの手順を人が持ち、どこからAIに渡すかがポイントです。

手順1：テストリストを人が作る

最初に、確かめたい振る舞いを箇条書きのリストにします。ここは要件の理解そのものなので、人が主導します。AIに叩き台を出させるのは有効ですが、どのケースを検証対象とするかの取捨選択は要件を知っている人にしかできません。前述のとおり、リストの根拠は実装ではなく要件や受け入れ基準に置きます。

手順2：失敗するテストを1件だけ書く

リストから1件を選び、実行可能なテストにします（Red）。AIに書かせる場合は、期待する入力と出力を明示して生成させます。書いたら必ず実行し、意図したとおりに失敗することを確かめます。実装がまだ無いのに通ってしまうテストは、何も検証していないテストだからです。

手順3：テストを通す実装をAIに任せる

テストが失敗する状態を確認したら、それを通す実装をAIに生成させます（Green）。このとき、テストコードの変更は許可しない、と明示的に指示します。テスト実行がコマンド一発で回る環境になっていれば、AIは通るまで実装の修正を自走できます。

手順4：リファクタリングして次のテストへ進む

テストが通ったら、テストが通る状態を保ったまま実装を整理します（Refactor）。終わったらリストの次の項目に戻り、リストが空になるまで繰り返します。

この4手順は、毎回チャットで指示するのではなく、リポジトリのルールファイル（CLAUDE.mdやAGENTS.mdなど）に明文化しておくと、セッションが変わっても同じ規律で回せます。

AI駆動開発におけるテストの4種別

TDDは単体テストの領域の話です。受託開発では、その外側に結合・総合・受入の工程があり、どこをAIで自動化し、どこを人が見るかを工程ごとに決めておく必要があります。

KDDIアイレットのAIDDスキームでは、テストを4種別で定義しています。

対象範囲が広がるにつれて、自動化の比重が下がり人の判断の比重が上がる、という並びになっています。

単体テスト：実装と同時に書く

TDDが直接あてはまるのはここです。コンポーネント単位で、実装しながら書きます。AIによるテストケース生成が最も効く領域ですが、前節のとおり実装と同じ根拠でテストを起こさないことが前提になります。

結合テスト：E2Eで自動実行する

devブランチへマージする前に、機能間の連携をE2Eテストで自動確認します。PRレビューのタイミングで自動実行されるため、人の判断を待たずに壊れたことがわかります。

総合テスト：自動と人的を組み合わせる

EPIC横断のユーザーシナリオ全体を見ます。自動E2Eだけでは拾えない挙動があるため、QAチームによる人的テストと併用します。この工程は「余裕があれば」ではなく、フェーズとして計画に組み込みます。

受入テスト：業務シナリオで人が見る

全EPIC完了後、業務シナリオベースで横断検証し、リリース可否を判定します。ここは自動化の対象外です。業務として成立しているかは、仕様の充足とは別の観点だからです。

テスト駆動開発をAIで回すときの判断基準

どこまでAIに任せるかは、感覚ではなくタスクの性質で決められます。AIDDスキームでは適用対象を次のように分類しています。

テストケースの生成は★★☆で、最上位ではありません。実行基盤が無いままケースだけ増やしても、回らないテストが積み上がるだけだからです。CIでの自動実行が先、生成の自動化は後という順序になります。

受入テストが自動化の対象外になるのも、同じ考え方の延長です。リリース可否の判定は上表の「意思決定・判断」にあたり、人が持ちます。

対象の性質による向き不向きもあります。入出力が明確に定義できるロジックや、仕様が固まっている機能はTDDに向きます。一方、何が正解かを先に言語化できない探索的なプロトタイピングでは、まず動くものを作って方向性を確かめるバイブコーディング的な進め方のほうが合う場面があります。捨てる前提の検証コードにテストを先行させるのは過剰です。

導入するときは、いきなり全工程に広げないことも判断のうちです。AIDDスキームでは、AIの動作確認、小規模テスト、本格運用の3段階で検証を進めることを標準としています。小さな機能でRed・Green・Refactorのサイクルを一巡させ、チームで手応えを確かめてから適用範囲を広げます。

AIとのTDDで起こりやすいアンチパターン

手順どおりに始めても、運用が崩れるパターンには型があります。事前に知っておけば、レビューで検知する仕組みを用意できます。

テストを通すことだけを目的にした実装を許す

AIは「テストを通す」という指示に忠実なあまり、テスト側を書き換えて通したり、テストで使われる入力だけに反応する条件分岐や期待値のハードコードで通したりすることがあります。テストは緑でも、仕様は満たしていない状態です。対策は、実装フェーズでテストコードの変更を禁止すること、そしてレビューでテストの差分と実装の差分を分けて確認することです。テストリストに無い入力を人が数件試すだけでも、ハードコードの多くは露見します。

実装の内部構造に依存したテストを書かせる

実装コードを見せてテストを生成させると、内部のメソッド呼び出しや画面の構造といった「作り」に密結合したテストができがちです。この種のテストは、振る舞いが変わっていないリファクタリングでも壊れ、修正のたびにテストの保守作業が発生します。テストは内部構造ではなく、外から見た振る舞い（入力と出力）に対して書かせます。実装ではなく仕様からテストを起こす原則は、ここでも効きます。

実行のたびに結果が変わるテストを放置する

現在時刻、乱数、外部APIの応答、並行処理のタイミングに依存したテストは、コードを変えていないのに落ちたり通ったりします。AIはテストを量産できるため、この種の不安定なテストも混入しやすくなります。合否が信用できなくなると、AIの自走ループも人の判断も成り立ちません。時刻や乱数は固定値を注入し、外部依存はモックに置き換え、不安定なテストが見つかったら隔離して原因を潰してから戻します。

バグ対応の流れを先に決めておく

テスト設計と同時に決めておきたいのが、バグが出たあとの流れです。ここが曖昧だと、テストで見つけても直るまでの時間が読めません。

ポイントは、起票とレビューをテスト実施者が持ち、調査と修正を開発担当者が持つという分離です。バグ種別（仕様通り／仕様変更／環境問題）はラベルで管理し、修正のリリース予定日はマイルストーンで追います。

AIが実装量を増やすと、比例してバグの流量も増えます。フローが決まっていないと、そこが詰まります。

テスト駆動開発とAIに関するよくある質問

テスト駆動開発とAIの組み合わせについて、よく聞かれる質問をまとめました。

テスト駆動開発でテストの作成をAIに任せるにはどうすればいいですか？

要件やユーザーストーリー、受け入れ基準といった上流の成果物を入力にして、期待する入出力を明示して生成させます。実装コードだけを見せて書かせると、実装の写しになって検証になりません。生成したテストは実行して、実装前に意図どおり失敗することを確かめます。あわせて、CIでテストが自動実行される状態を先に用意しておくことをおすすめします。

テスト駆動開発とアジャイルの違いは何ですか？

アジャイルは開発の進め方全体を指す考え方で、TDDはその中で使われる実装の技法です。対立する概念ではなく、TDDはアジャイルの反復サイクルの中で機能します。

AIがテストを書けるなら、テスト駆動開発は不要になりませんか？

テストを書く作業はAIが代替できても、「何が正しいか」を実装より先に決める判断は残ります。むしろAIが書くコードの量が増えるほど、合否を機械的に判定できる基準を先に持つことの価値は上がります。不要になるのではなく、人の役割がテストの記述からテストリストの設計へ移る、と捉えるのが実態に近いです。

テスト駆動開発をAIに任せると品質は下がりませんか？

任せる範囲によります。テストケースの生成やドキュメント化のような定型作業は効果が出やすい一方、業務として妥当かの判断は人が持つ必要があります。テストと実装の根拠を分ける、テスト実行を自動化するといった前提を整え、工程ごとに担当を決めておけば、量が増えても品質を保てます。

AI駆動開発の事例はありますか？

要件定義の手戻りを約66%削減したお客様事例などをAI駆動開発の事例で工程別に紹介しています。記載の数値はいずれも個別のお客様環境での実績であり、同じ効果を保証するものではありません。

まとめ

テスト駆動開発とAIを組み合わせるときの要点は2つです。実装とテストの根拠を分けること、そしてテストを小さく回す性質を壊さないこと。この2つを外すと、テストは通るのに品質は上がらない状態になります。

進め方としては、テストリストを人が作り、失敗するテストを1件ずつ書き、テストの変更を禁止したうえで実装をAIに任せ、リファクタリングして次へ進む。この規律をルールファイルに明文化すれば、AIの自走ループとして機能します。

そのうえで、TDDが扱うのは単体テストの領域だと理解しておくと、設計しやすくなります。結合はE2Eで自動化し、総合は自動と人的を併用し、受入は人が業務シナリオで見る。工程ごとに担当と環境を決めておけば、AIで実装量が増えても検証が追いつきます。実装からテストまでを一気通貫で運用する体制づくりは、AIDD MVPでも支援しています。

テスト工程を含めた開発プロセスの設計を相談したい方は、お気軽にKDDIアイレットへお問い合わせください。