原題: TDD inside the agent loop - theater or actual value? 著者: Birgitta Böckeler 公開日: 2026-08-10 ソースURL: TDD inside the agent loop - theater or actual value? アーカイブ日: 2026-08-24
ThoughtworksのDistinguished Engineer、Birgitta Böckelerが「エージェントにTDDをさせても、果たして意味があるのか」という疑問に、自作の評価実験で切り込んだ記事。TDDはAI支援コーディングと複数の方法で組み合わせられる。人間がテストを書きAIが実装する方式、AIが書いたテストを人間がレビューするチェックポイント方式、そしてエージェント自身が「まず失敗するテストを書いてから実装し、先ほどのテストがグリーンになることを確認する」という、エージェントのループ内部で完結させる方式。現時点で最も一般的なのは最後の方式だが、著者は「人間にとって良いものが、コーディングエージェントにとっては無関係か有害な、珍しい例の一つではないか」と疑った。
著者は小・中・大の3種類のグリーンフィールド課題を用意し、Sonnet 4.6に解かせ、品質判定はOpus 4.8に委ねる評価環境を構築した。判定者には解法がTDDで作られたか非TDDで作られたかを伏せ、評価ルーブリックもその場で生成させた。結論は率直だ。Opusの品質判定ではTDDと非TDDの間に明確な差は見られず、むしろ非TDDの解法が設計・テスト品質で上位にランクされることが一度ならずあった。突然変異テストのスコアにも有意差はなかった。小・中課題では非TDDの2解が1位と2位、TDDの2解が3位と4位というパターンが繰り返され、TDDプロンプトに明示的なリファクタリング工程を加えた回に初めてTDD解が1位になったが、同じプロンプトのもう一つのTDD解は最下位だった。
そもそも、エージェントはTDDを忠実に実行するのが苦手だ。実装を先に書いて後からテストを生成したり、レッド（失敗）確認を飛ばしたり、現在のテストを超えて先回り実装してしまい「次のテストが一度もレッドにならずに通ってしまう」といった失敗が、どのセッションでもある程度見られた。著者は独立エージェントにセッション記録からTDDの遵守度を判定させ、実質的にTDDをしていないランを誤って評価に混ぜないようにした。
結果を解釈するためOpusにセッション記録を分析させたところ、非TDDおよび「テストファーストのみ」のランは、コードやテストを書く前に必ず完全な設計（アーキテクチャ、データ型、エッジケース、契約）を先に作っていた。これがデータモデルの質の向上や、横断的なエッジケースの網羅、機能の完全性にわずかに効いていた。対照的にTDDの指示は、そうした前倒しの設計を積極的に妨げる。TDD解の設計は、局所的に最小の判断の積み重ねから出現し、ほとんど見直されなかったため、最初のテストがたまたま固定した形に落ち着きやすい。テストを書こうと思わなかった振る舞いは、そもそも実装されなかった。
著者がIvett Ördögと議論した際の説は示唆的だ。「AIエージェントの訓練データには、完成した関数とその説明が大量にあり、実際のステップ・バイ・ステップのTDDの例はごく一部しかない。つまりLLMは、コードを『要求からコードへの直接の変換』として内部表現しており、その表現に至るプロセスとしてではない」というものだ。
続いて著者は、TDDの究極の目的がエージェントループ内でも達成されるかを一つずつ検証する。テストファーストは「トートロジーの回避」に役立つはずだが、実験ではテストファーストにもかかわらず、実装と同じコードを再実行して「期待値」を作る自己言及的なテストが観察された。「レッド・グリーン」によるテスト有効性の証明も、人間がループから外れると意味が薄れる。レッドの確認は「エージェントが実行して失敗を見た」ことの証明にはなっても、「正しい理由で失敗した」ことの証明にはならない。回帰テストの質は突然変異テストで監視・改善すればよく、TDD解が非TDD解より良い突然変異スコアを出す兆候もなかった。
設計改善への寄与も疑わしい。人間がテストファーストで書くときは、実装方法を知る前に振る舞いを指定する摩擦に向き合わされるが、エージェントはその摩擦を経験せず、実装を計画した瞬間にテストを書けてしまう。人間のチェックポイントが間に挟まらなければ、テストファーストに残る目的はない。スモールステップによるYAGNI（不要なものは作らない）や「速く局所的なフィードバック」も、人間中心の利点であり、エージェントには移転しない。Kent BeckがTDD最大の効用として挙げた「恐怖のマネジメント」も、人間の恐怖を和らげ進歩を固定する心理的メカニズムであって、エージェントがループ内でTDDをしても同じ制御と信頼は得られない。
コストは無視できない。TDDワークフローはターン数とツール呼び出しが増えるため、トークン消費は少なくとも3倍、小課題では8.5倍に達した。キャッシュヒットを考慮すれば実際の費用増はこれより小さいが、方向性としては確実に数倍高い。さらにTDDはモデルに自然なプロセスではなく、訓練データに逆らう「上り坂の戦い」であり、プロンプトを何度も反復してようやく大体従うようになる。変数が多い複雑な指示であるため、モデルやリリースを跨ぐとさらに不安定になる。
著者の結論は明快だ。モデルに「どうやるか」を過剰に具体的に指示するアプローチは持続可能ではない。むしろ成果を監視してフィードバックを与える方法をできるだけ多く見つけるべきで、そのフィードバックは可能な限り自動化し、人間がどこで「何が正しく正しいか」の裁定者として介入するかを慎重に考えるべきだ。著者は自分のコーディングエージェントに「テストを先に書け」と言うのをやめ、ましてやTDDをさせることは（正直言って一度もなかったが）今後も、納得できる評価や強い論拠が出るまではやらない、と明言する。代わりに、回帰テストの質は突然変異テストで監視・改善し、リファクタリングは静的コード解析へのアクセス、構造とモジュール性の定期レビュー、変更あたりのファイル数やトークン数の推移の観察といったトリガーでプロセスに組み込み、TDDが与えていた「本番に出す恐怖」への対処としては、Ivett Ördögが提唱する「Approved Scenarios」アプローチ——アプリケーションごとの専用テストランナーで機能シナリオを確認し、徹底検証した期待値を凍結して、将来破られたときに再承認を求める半手動テスト——を試している。いずれにせよ、GenAI以前に比べてTDDの役割は大幅に小さくなっている、と著者は締めくくる。
この記事の価値は、エージェント型コーディングの台頭とともに当然視されつつある「人間に良いプラクティスはエージェントにも良い」という暗黙の前提に、実データで疑いを突きつけた点にある。TDDは数十年にわたりソフトウェア開発の良心として語られてきた。そのTDDをエージェントループ内で行わせることが「芝居」に過ぎないかもしれない——しかも3〜8倍のトークンコストを払って——という指摘は、多くの開発者が漠然と感じながら言語化できなかった事実を、小さなサンプルとはいえ定量データとともに提示した。サンプルサイズの小ささ、品質判定をOpusにほぼ委ねたこと、完全なTDD遵守が一度もなかったことなど、著者自身が挙げる留保は誠実であり、結論を「強い主張」ではなく「探索が生んだ仮説」として抑制している点も信頼性を高めている。
特に重要なのは、TDDの多くの効用が本質的に人間の認知プロセスに依存しているという整理だ。恐怖のマネジメント、仕様を考える摩擦、YAGNIの自制——これらはいずれも「思考の遅さ」から生まれる人間固有の価値であり、即時にテストを書けるエージェントには構造的に移転しない。この「人間中心の利点はループから人間が消えると消える」という洞察は、TDDに限らず、あらゆる既存プラクティスをエージェント時代に再評価する際の汎用的なレンズになる。Ördögの「訓練データは完成形と説明であって、そこに至るプロセスではない」という仮説も、なぜエージェントがTDDを不自然にこなすのかを説明する有力な補助線だ。
5年後を考えたとき、この記事は「エージェントループ内TDDの効果が疑わしい」という命題の初期の実証例として参照され続ける可能性が高い。実践的な示唆も具体的で、突然変異テストによる回帰品質の監視、リファクタリングをトリガー化してプロセスに組み込む方法、Approved Scenariosによる確信の獲得といった代替手段は、いずれもそのまま現場で使える。Thoughtworksという実務現場の最前線にいる著者による、学界ではなく産業側からの探索であることも、このテーマの実践的重要性を示している。
TDD、エージェント型コーディング、AI支援開発、ソフトウェアテスト、Thoughtworks、生成AI