テスト駆動開発（TDD）を爆速化する自作AIエージェントを作ってみた

テスト駆動開発（TDD）を効率化するために開発した、自分専用のAIエージェントスキルを公開します。

この記事には日付が必要だね。最近のものに見えるけど（Internet Archiveが最初に取得したのは5月29日）、モデルやエージェントが進化するとすぐに古くなってしまうような内容だし。（最近、Claude CodeやCodexに対してシンプルに「uv run pytestでテストして、red/greenのTDDでやって」と指示するだけでかなりいい結果が出てるよ。）

ここでスキルを使うのは間違ったアプローチだと思う。LLMはオブジェクト指向プログラミングと同じで、TDDが何か、どうやるのかを既に知っているはずだよ。もしこれをスキルとして組み込んだら、LLMが何をするにしてもそのスキルを読み込ませる羽目になる。これはAGENTS.mdを通じて直接指示を出すのがベストな数少ないケースの一つだし、わざわざ強制させるほどの指示は必要ないんじゃないかな。まあ、投稿者が自分のエージェントを特定のやり方で動かしたいだけなら、それでも全然いいんだけどね。> 5. テストを見せて、次に進む前に承認を求めて

全体的に、自分の実装スキルの設定とかなり近い。「汚れたキッチンで夕食は作らない」みたいな例え話は、もっと直接的な表現と比べてどれくらい効果があるんだろう？興味があるんだけど、投稿者さんは何か意見ある？

TDDはエージェント開発において理論上は素晴らしく聞こえるけど、すぐトークンコストが膨れ上がることに気づくはず。機能を作っても、後で構成が変わったり削除されたり、コードがリファクタリングされて移動することも多い。TDDだとそのたびに大きなコストがかかって、開発速度が極端に落ちてしまうんだ。特にマルチエージェント構成だと、ウォーターフォール的なアプローチの方がいいと感じている。それに、書いたコンポーネントを実際にはテストしていない「表面的なハルシネーション」だったり、文脈の不整合で意図しないリファクタリングが誘発されたりして、誤検知することもあるし。

どの投稿も、実際の比較結果が欠けているんだよね。「Xをやるべき」という真逆の意見を毎日見かけるし。もしTDDが本当に優れているなら、とっくにシステムプロンプトに組み込まれているはずだよ。

テストは開発においてめちゃくちゃ重要。エージェントを使ってコーディングする場合はなおさらだね。AIをガードレールの中に留めておくための最大の手段だと思う。（僕の最新刊『Effective Testing』を書いたのもそれが理由だよ。クライアントがテストをまともに扱えていないのを常々痛感しているからね。）

試してはないけど、最近Matt Pocockのスキルがかなり気に入ってる。ワークフローはこんな感じ：/grill-with-docs -> /to-prd -> /to-issue -> /tdd。「ユビキタス言語」を使って「共通認識」ができるまで徹底的にインタビューして、ユーザーーストーリーで要件を仕様化し、イシューを作成して、TDDで実装していくんだ。

別のエージェントを立ち上げて元のア エージェントの実装をレビューさせると、コードの品質が劇的に向上してバグが減るよ。だから、計画プロセス中にサブエージェントによるレビューを2、3回挟むようにしてる。計画を作るエージェントに対して、最後にそのレビュー回数を含めるよう指示するんだ。特に重要なコードの場合は、別のフロンティアラボのエージェントにもう一人見てもらうこともある。もちろんトークンは食うけど、後からバグ修正に戻るよりはずっと安く済むはず。時間はかかるけど、長期的には節約になるよ。

余談だけど、Jasonのポッドキャスト（codewithjason.com）もチェックしてみて。結構いいよ。最新回は「Uncle Bob Martin」が出てて、AIを使ったコーディングについて面白い見解を語ってる。…なんて言えばいいかな、レジェンド的な存在だよね？

もしバグを注入して、そのバグがある時にちゃんとテストが失敗することを確認するステップを踏んでいないなら…それは「テストがパスした」ことを確認しただけで、実際にはほとんど役に立っていない可能性があるよ。