AIコーディングはテストを先に書くと強くなる。TDD-Agentが実装とテストを一緒に育てる仕組み
AIにコードを書かせた後で、AI自身が作ったテストを通す。いかにも堅そうですが、ここには小さな落とし穴があります。
テストが間違っていれば、正しい実装を壊す方向へ修正が進みます。反対に、テストが甘ければ、実装とテストが仲良く同じ勘違いをしたまま終了します。合格の鐘を鳴らしている人も、答案を書いた人も同じなら、少し疑ったほうがよいわけです。
2026年8月17日に公開された論文「TDD-Agent: Test-Driven Reasoning for Code Generation」は、この問題に正面から取り組みます。
発想は明快です。AIに実装を急がせず、まずテストを書かせる。その後、実行結果を見ながら実装だけでなくテストも直す。テストを固定された採点表ではなく、AIが現在どう仕様を理解しているかを表す「実行可能な思考メモ」として扱います。
RepoEvalのPython関数補完455問では、この仕組みがmini-SWE-agentを3モデルすべてで上回りました。ただし、これは「AIが書いたテストを信じれば安全」という論文ではありません。むしろ重要なのは、テストと実装が同じ誤解へ収束する失敗まで、論文自身が示していることです。
後からテストするだけでは、仕様の理解は深まらない
コード生成でよく使われる流れは次のようなものです。
- AIが実装を書く
- AIがテストを書く
- テストを実行する
- 失敗した実装を修正する
この形では、テストは最後に置かれた検査装置です。実装を書いた時点でAIが曖昧に理解していた入力、出力、例外、境界条件は、そのままコードへ埋め込まれます。
さらに、自分で作ったテストには偏りがあります。実装時に見落とした条件は、テストでも見落としやすいからです。
TDD-Agentは順番を変えます。最初にリポジトリを調べ、対象関数が満たすべき振る舞いをpytestとして書きます。ここで、自然言語の要求を実行可能な具体例へ変換します。
テストを書くこと自体が、次の問いへの回答になります。
- 正常な入力は何か
- 境界値はどこか
- 何を返すべきか
- どの例外を許すか
- 周辺コードとどの契約を結ぶか
実装前にこの問いへ答えることで、AIは仕様の曖昧さを先送りしにくくなります。
二本の線を同時に直す
TDD-Agentは二段階で動きます。
最初はテスト先行の仕様化です。ディレクトリ一覧、ファイル構造、コード検索、指定範囲の読み取りを使い、初期テスト群を作ります。
次が実装とテストの同時修正です。AIは初期実装を書き、生成したテストを実行します。失敗したら、原因が実装側かテスト側かを考えます。必要なら両方を修正し、もう一度実行します。
論文の設定では、このループは最大10回です。AIが十分だと判断して終了ツールを呼べば、早く止められます。
ここで大切なのは、テストを神聖な正解として固定しないことです。最初のテストが存在しない要件を想像していたら、そのテストも直します。逆に、実装がテストだけをすり抜けていたら、テストを強くします。
論文は、この二重修正の効果をアブレーションで分けています。
| 方法 | GPT | DeepSeek | Qwen | |—|—:|—:|—:| | Vanilla | 68.35 | 73.63 | 52.97 | | 実装だけを反省 | 72.09 | 81.53 | 54.06 | | テストを固定して修正 | 70.11 | 79.56 | 57.36 | | テスト先行を1回だけ実施 | 69.89 | 76.48 | 54.51 | | TDD-Agent | 78.24 | 90.77 | 59.34 |
表の値はRepoEvalのpass rateです。実装だけの反省でも改善しますが、完全版が3モデルすべてで最も高くなりました。テストを最初に書くだけでも、テストを固定したまま回すだけでも、効果の全部は出ません。
455問で、どれだけ伸びたのか
論文は二つの粒度で評価しています。
一つ目は関数単位のLiveCodeBenchです。テストを先に考える簡易版のTDD-promptを使い、各問題で10サンプルを生成してpass@1を測っています。
| モデル | 最良の比較手法 | TDD-prompt | 差 | |—|—:|—:|—:| | GPT-5-mini | 68.48 | 70.04 | 1.56ポイント | | DeepSeek-V3.2 | 67.46 | 67.86 | 0.40ポイント | | Qwen3-Coder-30B | 42.99 | 44.87 | 1.88ポイント |
改善は一貫していますが、ここだけを見ると大差ではありません。
二つ目がリポジトリ単位のRepoEvalです。8個のPythonリポジトリから、欠けた関数を補う455問を使います。AIは周辺ファイルを調べ、依存関係を理解し、関数を完成させなければなりません。
| モデル | mini-SWE-agent | TDD-Agent 5回 | TDD-Agent 10回 | |—|—:|—:|—:| | GPT-5-mini | 61.31 | 77.36 | 78.24 | | DeepSeek-V3.2 | 84.18 | 88.13 | 90.77 | | Qwen3-Coder-30B | 52.97 | 58.46 | 59.34 |
10回版とmini-SWE-agentの差は、GPTで16.93ポイント、DeepSeekで6.59ポイント、Qwenで6.37ポイントです。
5回でもかなりの改善が出ています。論文の曲線では、6回から7回付近で伸びが緩やかになります。回せるだけ回すのではなく、途中で費用対効果が落ちる点を測る必要があります。
テストの質も、実行しながら変わる
テストが増えたから良くなった、と単純には言えません。間違ったテストを大量に作れば、逆効果です。
そこで論文は、生成テストを三つの指標で調べます。
- 正解実装に対してテストが通るか
- 対象関数の行をどれだけ通るか
- 20個の変異実装をどれだけ検出できるか
最後の指標はmutation scoreです。正しい実装の演算子や条件を少し壊した変異体を作り、生成テストがその壊れ方を見つけられるかを見ます。
3モデルとも、反復に伴ってテストのpass rate、coverage、mutation scoreが概ね改善しました。コードだけでなく、コードを評価する道具も育っていることを示します。
ただし、ここで油断すると話が一回転します。
実装とテストが同じ間違いを信じる
TDD-Agentの最も重要な限界は、論文の失敗分析にあります。
生成テストをすべて通った実装が、リポジトリ本来のテストでは失敗する例がありました。論文はこれをfalse-positive verificationとして扱います。
原因は、実装とテストが同じ仕様理解から生まれることです。テストが重要な条件を見落とせば、その条件を実装が満たしていなくてもループ内では見つかりません。
二人で答え合わせをしているように見えて、実は同じメモを写していた。そんな状態です。
このため、実運用でテストの自由な修正を許すなら、最後の合格判定は別の場所に置く必要があります。
実運用では、内側のテストと外側の合格判定を分ける
AICompanyとして実務へ翻訳するなら、三層に分けます。
第一層は候補テストです。AIは実装前に、要求を具体的なテストへ落とします。このテストはAIの理解を見える形にするためのもので、修正を許します。
第二層は自己修正ループです。隔離環境で候補テストを実行し、実装と候補テストを最大回数つきで直します。変更履歴を残し、テストを弱めた場合は理由を記録します。
第三層は独立した受け入れ判定です。既存テスト、変更できない回帰テスト、型検査、静的解析、人間のレビューを使います。ここは自己修正ループから書き換えられないようにします。
概念的には、次のような制御です。
“`python for round_no in range(7): candidate_tests = agent.revise_tests(context, candidate_tests, report) implementation = agent.revise_code(context, candidate_tests, report) report = run_isolated(candidate_tests, implementation) if report.passed and agent.ready_to_finish(): break
assert run_locked_regression_tests(implementation) assert run_static_checks(implementation) require_human_review_for_high_risk_change() “`
ポイントは、最後の三行をエージェントが書き換えられないことです。
導入するなら、成功率だけでなく費用も測る
TDD-Agentは無料の改善ではありません。テスト作成、実行、反省、再生成が増えるため、トークンとツール呼び出しを使います。
論文では、5回版の平均prompt tokenはmini-SWE-agentと同程度の桁ですが、モデルごとに増減が異なります。GPTでは平均LLM callが11.95回から18.62回へ増えています。一方、DeepSeekでは31.61回から29.39回へ減っています。
自社の課題で見るべきなのは、次の五つです。
- 独立した受け入れテストの通過率
- 生成テストだけ通る偽合格率
- 修正に必要な平均反復回数
- 総トークンと実行時間
- 既存テストを弱めたり削除した割合
成功率だけを上げようとすると、テストを弱くする近道が混ざります。外側の判定と費用を同時に測って、初めて改善かどうかが分かります。
この結果がまだ証明していないこと
評価対象はPythonの関数補完です。複数ファイルをまたぐ機能追加、設計変更、障害修正、JavaScriptやRustでも同じ差が出るとは限りません。
RepoEvalの予測中、エージェントはリポジトリ既存のテストを見たり実行したりできません。自己生成テストの効果を測るためにはきれいな設定ですが、既存テストを普通に使う現場とは条件が違います。
公開されたコードスナップショットは監査時に開けました。ただし、安定した公開commitとlicenseは確認できませんでした。AICompanyも455問の評価を再実行していません。
3モデルで方向がそろったことは強い材料です。一方で、他のモデル、他言語、実際の長期開発へ広げるには追試が必要です。
まとめ
TDD-Agentが示したのは、テストが採点表だけではないということです。
実装前にテストを書くと、AIは曖昧な要求を実行可能な例へ変えます。実装とテストを同時に直すと、誤った初期テストに縛られにくくなります。RepoEval 455問では、その組み合わせが反省だけ、固定テストだけ、1回だけのTDDを上回りました。
ただし、自己生成テストは独立した審判ではありません。実装と同じ誤解へ沈むことがあります。
実務で持ち帰るべき設計は「AIにテストを任せる」ではなく、「AIの理解をテストとして見える化し、内側で育て、外側の変更不能な判定で止める」です。
テストはAIの答えを保証する魔法ではありません。それでも、AIが何を正しいと思っているかを、実行できる形で見せてくれます。そこから先は、別の審判をちゃんと席に座らせましょう。