「テスト書いて」と「テスト駆動で実装して」は全く別物 — AI×TDD で品質が劇的に変わる構造的理由
「テスト書いて」と「テスト駆動で実装して」は全く別物 — AI×TDD で品質が劇的に変わる構造的理由 @neurostack_0001 氏のポストが、AI にテストを書かせる際の決定的な違いを指摘し、大きな反響を呼んでいます（いいね 267、ブックマーク 222）。 3ヶ月AIにテストコード書かせてわかったこと。 「テスト書いて」と「テスト駆動で実装して」は全く別物だった。 3ヶ月間の実体験から導き出された結論は明快です。AI に「テストを書いて」と頼むのと「テスト駆動で実装して」と頼むのでは、出力されるテストの品質が根本的に異なる。本記事では、なぜこの違いが生まれるのか、その構造的な理由と実践的なワークフローを解説します。 「テスト書いて」が失敗する構造 テスト後付けバイアス ポスト主が最初に経験した失敗パターンは、多くの開発者に共通するものです。 最初はClaude Codeに「この関数のテスト書いて」と頼んでた。構文は完璧。でも実行すると半分以上落ちる。テスト対象もモックしてたり、存在しないメソッド呼んでたり。「テストっぽいもの」を量産してただけ。 この問題はテスト後付けバイアスと呼ばれる LLM の構造的な弱点に起因します。LLM が実装コードを見てからテストを生成する場合、テストは「コードが何をすべきか」ではなく「コードが何をしているか」を検証するものになりがちです。 具体的に発生する問題は以下の通りです。 問題 説明 テスト対象のモック化 テストすべき関数自体をモックしてしまい、実際のロジックを検証していない 存在しないメソッド呼び出し LLM のハルシネーションにより、実在しない API やメソッドをテストで使用する 実装への密結合 内部実装の詳細に依存するテストが生成され、リファクタリングで壊れる 網羅性の欠如 エッジケースや異常系のテストが不足し、正常系のみカバーする なぜ LLM は「テストっぽいもの」を量産するのか Codemanship の記事が、この問題の本質を指摘しています。 The more things we ask models to pay attention to, the less able they are to pay attention to any of them. LLM は「次の最も確率の高いトークン」を予測する仕組みです。既存の実装コードをコンテキストに含めてテストを生成すると、モデルは実装の構造を模倣したテストを生成します。テストとしての妥当性ではなく、「テストとして見た目がそれらしいもの」を出力するのです。 これは LLM の根本的な限界であり、プロンプトの工夫だけでは解決できません。 「テスト駆動で実装して」が品質を変える理由 テストファーストが生む構造的な違い ポスト主が発見した転機は、TDD のループを AI 自身にやらせることでした。 ...