AI時代にこそTDDが問われる理由——「書く速さ」から「検証の速さ」への逆転

TDDは「遅い」というのが、これまでの相場観だった

テスト駆動開発（TDD）には、長年ついて回る批判があります。 「テストを先に書くのは丁寧だが、遅い」というものです。 Red-Green-Refactorのサイクルを回すには時間がかかり、 納期に追われる現場では真っ先に省略される儀式でした。

この相場観は、ある前提の上に成り立っていました。 コードを書くこと自体が、時間のかかる希少なリソースだったという前提です。 だからこそ「先にテストを書く余裕なんてない、まず動くものを書け」という判断が、 多くの現場で合理的に見えていたのです。

AIによるコード生成は、この前提を静かに壊しました。

コストが逆転した：書くのはタダ、確かめるのが高くつく

AIコーディングエージェントに指示を出せば、数百行のコードが数秒で出てきます。 「実装」というボトルネックは、劇的に安くなりました。 一方で、そのコードが本当に意図通りかを確かめる作業—— 検証——は、以前とほとんど変わらない人間の時間がかかります。 むしろ、AIが生成した大量のコードを一つひとつ読んで妥当性を判断する分、 レビューの負荷はむしろ増えているとさえ言えます。

ボトルネックが移動したなら、投資すべき場所も移動するはずです。 「先にテストを書く」というTDDの規律は、 贅沢な儀式から、ボトルネックを直接攻める合理的な戦略へと意味が変わりました。

テストは、AIへの「契約書」になる

もう一つ、TDDの位置づけを変えている事実があります。 多くのAIコーディングエージェント（Claude Codeもその一つです）は、 実際にテストを実行し、失敗を見て、コードを修正し、また実行する というループを自律的に回します。

ここでテストが曖昧だったり存在しなかったりすると、AIは何を基準に 「完了した」と判断すればいいか分かりません。逆に、意図を正確に表現したテストがあれば、 AIはそれに向かって自己修正を繰り返し、人間が逐一レビューしなくても 品質を一定水準に保てます。つまりテストは、単なる品質保証の手段ではなく、 人間の意図をAIに伝える、実行可能な契約書になっているのです。

これは前回の記事で触れた 「Verification-First」原則、そしてトヨタ生産方式の自働化（じどうか）と同じ思想です。 品質を工程の最後（人間によるコードレビュー）で確かめるのではなく、 工程の中に——つまりAIが手を動かすその瞬間に——埋め込んでしまう。 テストが先にあるからこそ、AIというラインは異常を自分で検知し、 不良を後工程（本番環境）に流さずに済みます。

ただし、テストの「質」がそのまま仕様の「質」になる

ここに新しい落とし穴があります。 AIはテストに合格することを目的に最適化します。 テストが浅ければ、AIはテストには合格するが、意図とはズレたコードを 平然と生成します。これは教育の世界で言う「テスト対策のための勉強」と同じ構造です。 評価基準が目的化した瞬間、その評価基準は良い指標ではなくなる—— いわゆるグッドハートの法則が、AIコーディングの現場でもそのまま起こります。

つまりAI時代のTDDでは、次のようなスキルの重心移動が起きます。

• 「実装できるか」より「意図を正確にテストへ落とし込めるか」が問われる
• 境界値・異常系・「やってはいけないこと」まで含めた網羅性が、以前より重くなる
• テストコードそのものが、レビューすべき最重要の成果物になる（コードレビューよりテストレビュー）

雑なテストの上にAIが積み上げたコードは、一見動いているように見えて、 実は「テストという小さな穴」だけを正確に通り抜けた、 意図とは違う実装であることが珍しくありません。

現場で何が変わるべきか

おわりに：TDDは「遅くする規律」から「意図を伝える手段」へ

TDDはこれまで、人間が焦って雑なコードを書かないための 「あえて遅くする規律」として語られることが多くありました。 しかしAIが実装を高速化した今、TDDの役割は変わりつつあります。 それはもはやブレーキではなく、 人間の意図とAIの実行をつなぐハンドルです。

AIが何をどれだけ速く作れるかは、もはや競争優位の源泉ではありません。 何を作るべきかを、AIが誤解しようのない形で表現できるか—— その能力こそが、これからの開発者の腕の見せどころになりそうです。