はじめに：コードが書けない私がTDDと格闘した話
こんにちは。okakenと言います！
普段はClaudeCodeを使ってvibe codingで個人開発をしています。
ClaudeCodeによる開発では、その精度と品質を担保するためにTDD（テスト駆動開発）がAnthropic公式のベストプラクティスとしても紹介されています。
しかし、非エンジニアの私にはこのTDDの効果をなかなか引き出せていませんでした。
従来のTDD失敗するテストを書く(RED) → テストをパスする実装を書く(GREEN) → コードを綺麗にする(REFACTOR)
このサイクルは、コードが書ける・読めるエンジニアにとっては強力な手法です。しかし、非エンジニアの私には、以下のような壁がありました。
これでは、TDDの恩恵を受けるどころか、開発の足かせになってしまい、「TDDなんてやる意味ない！」と感じていました。
提案：AI時代の「TDD✖️vibe coding」
そんな試行錯誤の末にたどり着いたのが、AIと実践する新しいTDDフローです。
要求の言語化 → RED → 仕様書を逆生成 → GREEN → REFACTOR
このフローの最大の特徴は、RED（失敗するテスト）を書いた直後に、そのテストコードから自然言語の仕様書を逆生成するステップを挟むことです。
この「仕様書を逆生成」するステップが、非エンジニアである私とClaudeCodeとの共同開発において、かなり効果的でした。本記事では、このの具体的なフローと、その中心となる「仕様書逆生成テンプレート」について解説したいと思います。
「TDD✖️vibe coding」の具体的な5ステップ
私がClaudeCodeと開発する際は、要求〜テスト作成〜実装〜リファクタリングまで一気に行うのではなく、各ステップごとに指示しています。
具体的には各ステップで行うワークフローをカスタムスラッシュコマンドとして事前に定義して、順番に実行しています。
今回はそのワークフローの要素を抽出して、各ステップで何を行っているかを解説します。
Step 1: 要求の言語化
自分の頭の中にある「こんな機能が欲しい」という曖昧なアイデアを、AIに壁打ちしながら言語化することから始めます。
- やること: AIに対して、作りたい機能のアイデアを投げかけ、対話を通じてユーザーストーリーと受け入れ条件を明確にする。
- AIへの指示例: 「ユーザーがログイン状態を管理できる機能を作りたい。どんな情報が必要？」「この機能のユーザーストーリーと受け入れ条件をマークダウンでまとめて。」
- ゴール: AIがテストコードを書けるレベルまで、要求仕様を具体化し、ドキュメント化すること。
このフェーズは、いわゆる「要件定義」に相当します。非エンジニアでも、AIとの対話を通じて、自然言語で仕様を固めていくことができます。
Step 2: 失敗するテストの作成 （RED）
要求が固まったら、次はいよいよREDフェーズです。しかし、コードを書くのは私ではなくClaudeCodeです。
- やること: Step1で作成した要求仕様をClaudeCodeに渡し、「この仕様を満たすための、失敗するテストコードを書いて」と指示する。
- AIへの指示例: 「先ほどのユーザーストーリーと受け入れ条件に基づいて、テストコードを作成してください。まだ実装はないので、このテストは必ず失敗するようにしてください。」
-
ゴール: 要求仕様のすべての項目をカバーする、失敗するテストコード（
.test.tsなど）が完成すること。
ここでのポイントは、まだ実装コードは一切書かないことです。AIが生成したテストコードが全て赤色（失敗）で表示されることを確認します。
Step 3: 仕様書を逆生成 （最重要）
ここが、このフローのコアな部分です。AIに、先ほど作成したテストコードを解析させ、非エンジニアでも理解できる自然言語の仕様書を生成させます。
- やること: Step2で生成したテストコードをAIに読み込ませ、「このテストコードから、非エンジニアでもわかる仕様書を生成して」と指示する。
- AIへの指示例: 「このテストファイルの内容を解析して、私が提供する仕様書テンプレートに沿って、機能仕様書を作成してください。特に、どんなテストケースがあるのか、日本語で分かりやすく説明してください。」
- ゴール: 生成された仕様書を読み、自分の要求が100%正しくテストに反映されているかを確認・承認すること。もし要求とズレがあれば、テストコードの修正をAIに指示し、再度仕様書を生成させます。
このステップにより、コードが読めなくても、これから作る機能の「振る舞い」が正しいかを、実装前に確定させることができます。
仕様書逆生成テンプレート
実際に私が使用しているテンプレートの抜粋です。テストコードから、これだけの情報を引き出すようにAIに指示しています。
test-to-spec-template.md
# [機能名] 詳細仕様書
*テストファイル `[ファイルパス]` から自動生成*
## 🎯 ビジネス価値
### この機能が提供する価値
- **ユーザー価値**: [ユーザーが得られる具体的な価値]
- **ビジネス価値**: [ビジネスに与える影響]
## 📋 機能概要
**[機能名]**は、[機能の目的・役割を非エンジニア向けに説明]
---
## 🔍 詳細機能仕様
### [機能カテゴリ1]: [機能名]
#### [機能番号].1 基本動作
**動作内容**: [機能の基本的な動作を説明]
**期待される動作:**
- ✅ [テストケース1の説明]
- ✅ [テストケース2の説明]
#### [機能番号].3 エラー処理
**動作内容**: [エラーが発生する条件・状況]
**期待される動作:**
- ✅ [エラー検出の動作]
- ✅ [エラー処理の動作]
---
## 📊 品質指標
### テストカバレッジ
- **総テストケース数**: [総数]件
- **基本機能テスト**: [数]件
- **エラー処理テスト**: [数]件
---
このテンプレートを使うことで、単なる機能リストではなく、ビジネス価値や品質指標まで含んだ、生きたドキュメントが手に入ります。
Step 4: テストをパスする実装 （GREEN）
仕様が確定し、自分の要求がテストに正しく反映されていることを確認できたら、あとは簡単です。
- やること: AIに対して、「このテストをすべてパスさせて」と指示する。
-
AIへの指示例: 「仕様の確認が完了しました。
（ファイル名）.test.tsのテストが全てパスするように、（ファイル名）.tsに最小限の実装を作成してください。」 -
ゴール:
npm run testなどのコマンドを実行し、すべてのテストが緑色（成功）になること。
AIは、仕様書（＝テストコード）という明確なゴールに向かって実装を行うため、手戻りが少なく、精度の高いコードを生成してくれます。
Step 5: コードの改善 （REFACTOR）
最後に、AIによって生成されたコードの品質を向上させます。
- やること: AIに「コードを綺麗にして」と指示する。具体的には、可読性、保守性、パフォーマンスの観点から改善を促します。
- AIへの指示例: 「テストはすべてパスした状態を維持したまま、このコードをリファクタリングしてください。より読みやすく、効率的なコードに改善して。」
- ゴール: 機能は一切変わらずに、コードの内部品質が向上すること。リファクタリング後も、すべてのテストがパスし続けることを確認します。
再現性を担保する「スラッシュコマンド」運用
この一連のフローを毎回正確に、かつ効率的に実行するために、私は各ステップに対応したカスタムスラッシュコマンドを用意しています。
-
/tdd-init: 要求の言語化フェーズを開始 -
/tdd-red: 失敗するテスト&仕様書の作成フェーズを開始 -
/tdd-green: 実装フェーズを開始 -
/tdd-refactor: リファクタリングフェーズを開始
これらのコマンドを実行すると、に読み込まれ、定義された手順に沿ってタスクが自動的に進行します。
このように、開発プロセス自体を事前に定義して、スラッシュコマンドで呼び出すことで、非エンジニアでも一貫した開発ワークフローを維持できるのです。
なぜこのフローが有効なのか？
この「TDD✖️vibe coding」フローは、従来のTDDが持つ本来のメリットを、非エンジニアでも最大限に引き出すことができます。
- バグが減る: 実装前にテストと仕様書で振る舞いを考えることで、仕様の考慮漏れが劇的に減ります。
- 仕様が明確になる: テストコードから生成された仕様書は、常に最新の「正」です。いつでも機能の正しい振るいを確認できます。
- 安心して変更できる: 将来、機能追加や変更を行う際も、既存のテストが「安全網」として機能します。何かを壊してしまっても、テストがすぐに検知してくれます。
- AIとのコミュニケーションが円滑になる: コードではなく、自然言語の「仕様書」を介してAIと対話することで、認識のズレを防ぎ、より精度の高い実装を依頼できます。
まとめ
AIとの協業が当たり前になる時代、開発のやり方も進化していく必要があります。今回ご紹介した「TDD✖️vibe coding」は、コードの読み書き能力への依存を抑えて、自然言語を軸にした開発を実現するための一つの答えだと考えています。
特に、私のような非エンジニアや、TDDに挫折した経験のある方にとって、AIを優秀な「テストエンジニア」兼「仕様書ライター」として活用するこの手法が、参考になれば嬉しいです！
ぜひ、皆さんも試してみてください。
あと、こんな感じでClaudeCodeやvibe codingについて試行錯誤しなたらTipsを発信しているので、よかったらXのフォローもお願いします！
Views: 0
