AIでTDD：Claude Codeとレッド・グリーン・リファクタでテストを書く（2026）

AIでTDDとは何か？

TDD（テスト駆動開発）とは、まずテストを書き——失敗させ——次にそれを通すのに十分なだけのコードを書き、最後にテストを再びレッドにすることなくコードを整理（リファクタ）する、というコードの書き方です。これが「クラシックな」TDDであり、何年も前から存在しています。「AIでTDD」とは、要件の定義と結果の検証はあなたが担いつつ、テストを書く仕事とそれを満たす実装を書く仕事の両方をClaude Code（または同様のAIアシスタント）に任せる、というだけのことです。

「AIにコードを書かせてから後付けでテストを追加させる」やり方との決定的な違いは順序です。TDDでは、最初に書くテストは実行可能な仕様書です。本物のコードが1行も存在しないうちに、正確な入力・出力・エッジケースを記述します。そうすることでClaude Codeは、好き勝手にコードを書いて自分の宿題を自分で採点するのではなく、そのテストをグリーンにするためのコードを書くようになります。

AIと一緒にプロセスを進めることにまだ慣れていないなら、まずバイブコーディングとは何か、そして規律あるワークフローとどう違うのかを読んで、TDDが全体像のどこに位置づけられるかを確認してください。TDDは、バイブコーディングが誰にも制御できないコードの山に変わってしまうのを防ぐ規律の1つです。

なぜTDDはClaude Codeにこれほど合うのか？

Claude Codeは、「完了の定義」が実行可能で自己検証できるものであるときに最も力を発揮します——そしてテストはまさにそれです。「この関数を正しく動かして」と言うと、AIはあなたの意図を推測しなければなりません。しかし「この8つのテストを通して」と言えば、レッドかグリーンかという明確な二値の目標があり、AIが「完了したはずだ」と思い込めるグレーゾーンはありません。

この組み合わせがうまくかみ合う理由は3つあります：

• テストは仕様書であると同時にセーフティネットでもあります。要件を記述すると同時に、AIが誤って別の箇所を変更した瞬間に、その破損を検出します。AIが絶えず編集するコードベースでは、このセーフティネットこそが「1つ直して3つ壊す」事態を防いでくれます。
• 緊密なフィードバックループ。テストを書く -> 実行する -> エラーを読む -> グリーンになるまで修正する。Claude Codeはターミナルでテストを実行し、実際の出力を読めるので、あなたが手作業でエラーをコピー＆ペーストしなくても、何度も反復して進めてくれます。
• AIが要件を取り違えるのを防ぐガード。これはあまり口に出して語られない点ですが、テストを先に書くことで、あなた（とAI）はコーディングの前に要件を固めざるを得なくなります。要件がテストとして凍結されると、「技術的には正しいが意図が違う」バグの多くが消えてなくなります。

Anthropic自身も、Claude Codeのベストプラクティス（Anthropic, 2025）の中で、Claude Codeを使う際の推奨ワークフローとしてTDDを挙げています。テストを書き、それが失敗することを確認し、そのあと通るまでコードを書く、というものです。これは誰かがでっち上げた小技ではなく、ツールの作り手自身が勧める使い方なのです。

Claude Codeによるレッド・グリーン・リファクタのサイクル

TDDのすべては3つのステップに収まり、機能の小さな一切れごとに繰り返します。Claude Codeでは、各ステップが1つのプロンプトと1つの明確な出力期待に対応します。

ステップ1 - レッド：失敗するテストを書く（まだコードは書かない）

望ましい挙動に対するテスト、そしてテストだけをClaudeに書いてもらいます。実装がまだ存在しないので、実行結果は必ずレッドになるはずです。

Write a unit test for validate_email(email) in src/validators.py using pytest.
Cover these cases: valid email, missing @, missing domain, empty string, None.
The test MUST fail because the function does not exist yet. Do NOT write any code for validate_email.

期待される結果：いくつかのケースを含むtest_validators.pyファイルができ、pytestを実行するとImportErrorまたはレッドのテストが報告されます。ここでのレッドは正しい状態です——テストが、まだ存在しないものを実際にチェックしていることの証明になります。

ステップ2 - グリーン：通すための最小限のコードを書く

ここで初めてAIに実装を書かせます。余計な機能を付け足さないよう、「最小限」を強調します。

Write the MINIMAL implementation of validate_email so every test in
test_validators.py passes. Run `pytest -q` and paste the real results back to me.
Do not add features beyond what the tests cover.

期待される結果：必要十分なだけのコードができ、pytestの出力がグリーンに変わります。AIには実際の実行出力を貼り付けさせてください。ただ「通ります」という言葉だけを信用してはいけません。

ステップ3 - リファクタ：コードを整理し、グリーンを保つ

いったんグリーンになれば、自由に整理するためのセーフティネットが手に入ります。

Refactor validate_email for readability (extract the regex into a constant, use clear names).
Do NOT change behavior. Re-run `pytest -q` after editing to prove it is still green.

期待される結果：よりきれいなコードになり、テストは依然としてすべてグリーンのままです。リファクタ中にテストがレッドになったら、それはうっかり挙動を変えてしまったというサインです——すぐに直しましょう。

Claude Codeでの実際のテストファースト・セッション（ステップ・バイ・ステップ）

ここまでは理論です。ここからは小さな機能での実際のセッションを紹介します。整数1299000を返す関数parse_price("1.299.000d")です。これは入力と出力が明確な純粋なロジックであり——TDDに理想的な題材です。

ステップ1 - レッドのテストを依頼する。プロジェクトフォルダでClaude Codeを開き、次のように入力します：

Write pytest for parse_price(s) in src/pricing.py:
- "1.299.000d" -> 1299000
- "50.000 d" -> 50000
- "0d" -> 0
- a string with no digits -> raise ValueError
Write only the test. The function does not exist yet, so the test must fail.

ステップ2 - グリーンにするための最小限のコードを依頼する。テストが期待どおりレッドであることを確認したあとで：

Write the minimal implementation of parse_price so all 4 tests pass.
Run `pytest -q` and paste the output. Do not handle cases outside the tests.

Claudeは、数字以外の文字を取り除き、intにキャストし、空のときはValueErrorを送出する関数を書きます。自分でテストを実行し、グリーンの結果を返してきます。

ステップ3 - リファクタ。私はClaudeに、数字抽出のロジックをヘルパーに切り出してdocstringを追加し、挙動が変わっていないことを証明するためにテストを再実行するよう指示します。相変わらず4つともグリーンです。セッション全体で数分しかかからず、肝心なのは「完了した」を鵜呑みにする必要が一度もなかったことです——どの主張にも実際のpytestの出力が添えられていました。

Claude Codeにテストを必ず先に書かせる方法（コードを先に書かせないために）

これは最大の悩みの種であり、多くのチームが数日でTDDをやめてしまう理由でもあります。Claude Codeは、ほとんどのAIアシスタントと同様に、いきなり実装に飛びつき、テストは体裁だけ後付けする傾向があります。「問題を解決する」ように訓練されており、AIにとってはテストを書くよりコードを書くほうが問題解決らしく見えるのです。これを効果的に強制する仕組みが3つあります：

1. フェーズを分けたプロンプト。「関数Xとそのテストを書いて」を1文にまとめてはいけません——それはAIに先にコードを書かせる誘い水です。きっぱり分割しましょう。レッドのステップでは「Xの失敗するテストを書いて、まだコードは書かないで」とだけ伝え、テストがレッドになって初めてグリーンへ進みます。「まだコードは書かないで」を大文字や太字にすると、順守の度合いが目に見えて良くなります。

2. CLAUDE.md内のテストファースト・ルール。これが最も長持ちする方法です——ルールを一度書けば、すべてのセッションに適用されます。プロジェクトのCLAUDE.mdファイルに次のブロックを追加してください：

## TDD rules (mandatory)
- Always write tests BEFORE the implementation for any new logic/function.
- Order: (1) write a failing test, (2) run `pytest -q` to confirm red,
 (3) write the minimal code to pass, (4) refactor while staying green.
- Do NOT write any implementation during the Red step.
- Do NOT edit tests just to make existing code pass.
- After every change, run the REAL tests and paste the output; never claim "it passes" on faith.

このファイルを一度も設定したことがなければ、しっかりしたCLAUDE.mdの書き方ガイド（テストファーストの徹底）を参照してください——プロジェクト全体の規律のオン／オフのスイッチになります。

3. subagentによるフェーズゲート。上級者向けの一手：テスト作成専用のsubagentを使い、実装計画を見せないことです。「テストの書き手」がコードがどうなるかを知らなければ、テストはあなたが書こうとしているコードではなく望ましい挙動に忠実になります——これにより、都合よく形を合わせて「グリーンにする」ためのテストを避けられます。複数のエージェントをフェーズごとに編成する方法は、brainstorm -> plan -> cook -> shipのワークフローにあります。

AIでTDDにありがちな失敗（アンチパターン）

AIでのTDDは、とても予測しやすい形で失敗します。「TDDをやっている」と自分をだまさないよう、早めに見抜きましょう：

この中で最も危険なのは、静かに進行する検証ギャップです。テストがレッドのまま行き詰まったり、AIが堂々巡りしていたりするとき、テストを緩めて「グリーンにする」ことを許してはいけません——地道なデバッグに切り替え（AIでデバッグを参照）、コミットする前にAIコードレビューを一度回して変更の品質を確認しましょう。

TDDを自動化する：フェーズゲートを強制するhookとskill

手動の規律は簡単に崩れます。フェーズゲートがあなたの記憶頼みにならないよう、自動化する方法が2つあります：

テストを自動実行するhook。Claude Codeは、ファイル編集のたびに実行されるhookをサポートしています。編集のたびにpytest -q（またはnpm test、vitest run）を実行するhookを設定すれば、テストがレッドになった瞬間にhookが知らせてくれるので、AIは次に進む前に直さざるを得ません。これにより、「テストの実行を忘れないようにする」が「テストの実行を忘れられない」に変わります。

プロセスが組み込まれたskill／subagent。プロジェクトごとにテストファーストの規約を書き直す代わりに、既製のキットを使うこともできます。

既製のキットで加速する：hookや規約をゼロから作りたくないなら、Claude Code向けAgentKitキット（リンク経由で20%オフ）（agentkit.best、akのCLI——OpenAIのAgentKitとは別物）には、コードレビューのワークフローを含む60以上のskillと30以上のワークフローがエンジニア向けに同梱されています。これらをあなたのレッド・グリーン・リファクタのループと組み合わせれば、手動セットアップなしで自動のフェーズゲートとレビューが手に入ります。詳しくはEngineer Kitレビューをご覧ください。Engineer Kitは現在99ドルです（サイトに継続課金の記載はありません）。

自分で作るにせよキットを使うにせよ、原則は変わりません。テストを実行して結果を報告するのは機械でなければならない——AIが自分で宣言するのではなく。

AIでTDDを使うべき場合と使うべきでない場合

AIでのTDDは万能薬ではありません。どこで輝き、どこで邪魔になるのか、正直に見極めましょう：

使うべき場合：ビジネスロジック、純粋関数（入力 -> 出力が明確なもの）、データ処理、バックエンドAPI、そしてとりわけバグ修正です——バグを再現するテストを書いて（レッド）、それをグリーンに直す、というのは最もすっきりしたバグ修正のワークフローです。Claude CodeでバックエンドAPIを構築するときにもTDDが最も効くのはここです。エンドポイントの契約はテストとして凍結しやすいからです。

あまり向かない場合：要件がまだあいまいな探索・プロトタイプの段階（書いたテストは絶えず捨てられます）、UIのスタイリングや見た目の感触（テストは高くつくうえ「見栄えが良い／悪い」は捉えられません）、あるいは使い捨てのスクリプトです。要件がまだ漠然としているときにテストファーストを強制しても、遅くなるだけです——自由にプロトタイプを作り、挙動が固まったら戻ってきて、残す価値のある部分にテストをかぶせましょう。

よくある質問（FAQ）

AIでのTDDは手動のTDDに取って代わりますか？

原則に取って代わるわけではなく、変わるのは「誰がタイプするか」だけです。テストが何を検証するかを決め、そのテストに意味があるかを判断するのは依然としてあなたの仕事で、AIは書くことと実行することを担います。レッド・グリーン・リファクタの規律は、やはりあなたのものです。

Claudeが書くテストは正確で網羅的ですか？

基本的なケースはたいてい正確ですが、エッジケース（空、null、負の値、unicode、ネットワークエラー）を見落とすことがよくあります。信用する前に、AIが書いたテストを読み、エッジケースを追加するよう頼みましょう。テストは仕様書なので、その仕様書を承認するのはあなたです。

どのフレームワーク——pytest、Jest、Vitest？

プロジェクトですでに使っているものを使いましょう。Claude Codeはpytest（Python）、Jest、Vitest（JS/TS）を使いこなせます。大事なのは、AIがランダムに選ばないよう、プロンプトやCLAUDE.mdでフレームワークを明示的に指定することです。

AIでTDDをやる前に、テストの書き方を知っておく必要がありますか？

基本は知っておくべきです。テストを書くのが得意である必要はありませんが、AIが書いたテストを読んで判断できる程度の力は必要です——さもないと、無意味なテストにゴーサインを出してしまいます。TDDは、作業しながら自分のテストスキルを底上げする手段だと捉えましょう。

AIが書いたテストは、リグレッションを防げるほど信頼できますか？

2つの条件のもとで信頼できます。あなたがテストをレビューしたこと、そしてテストが実際に実行されたこと（AIが自分で合格を宣言したのではないこと）です。AIが早すぎるタイミングで「完了」と報告しがちな傾向を補うために、lint -> unit -> e2eの層を追加しましょう。

レガシープロジェクトにAIでのTDDを適用できますか？

できますが、順序が異なります。レガシーコードでは、まず現在の挙動を固定する「特性テスト（characterization tests）」を書き、そのうえで安全にリファクタします。古いプロジェクトに追加する新機能については、いつもどおりテストファーストのままで構いません。

まとめと次のステップ

AIでのTDDは、結局1つのループに行き着きます。レッドのテストを書く -> Claude Codeにそれをグリーンにさせる -> グリーンを保ったままリファクタする、そしてAIの言葉を信じる代わりに、必ず機械に本物のテストを実行させることです。鍵となるのは、より強力なツールではなく、フェーズを分けたプロンプトとCLAUDE.mdのルールでAIにテストを先に書かせられることです。次のステップ：brainstorm -> plan -> cook -> shipのワークフローでTDDを完全なプロセスに組み込み、正しいやり方のバイブコーディングを通じてプロセスの土台を固めましょう。