10人規模の制作会社を経営しているあなた、外注で作ったWebサービスが「なぜか動かない」「修正すると別のところが壊れる」という経験はありませんか。あるいは、社内で使っているツールの品質が安定せず、毎週のように小さなバグ対応が発生して困っている管理職の方もいるでしょう。

こうした問題の多くは、テストなしで開発を進めることに起因します。テスト（プログラムが自動で動作を確認するチェック機能）を先に書いてからコードを作る開発手法を、テスト駆動開発（TDD、Test-Driven Developmentの略）と言います。TDDは品質を高める有効な方法ですが、テストを書くのに手間がかかるため、小規模チームでは後回しになりがちです。

ここで役立つのが Claude Code（クロードコード、AnthropicのAI「Claude」を使ってコードを書いたり修正したりするツール）です。Claude CodeはTDDのサポートが得意で、うまく使えばバグの少ないシステムを従来の半分程度の工数で作れるようになります。

この記事では、非エンジニアの経営者・管理職の方でも理解できるよう、Claude CodeとTDDの組み合わせを実務に落とし込んで解説します。

図: TDDとClaude Codeの全体像（画像生成待ち）

テスト駆動開発（TDD）を料理に例えると

テスト駆動開発という言葉は難しく聞こえますが、考え方はシンプルです。

普通の開発では「料理を作る → 味見 → 調整」という順番です。TDDでは「先に評価基準を決める（この塩加減、この食感）→ 料理を作る → 基準で確認」という順番になります。

自動テスト（プログラムが自動で動作を確認するチェック機能）を先に書いておくことで、新しい機能を追加したとき「前の機能が壊れていないか」を一瞬で確認できます。

たとえば、社内の受発注システムに新しい割引計算機能を追加したとします。テストがない場合、既存の在庫管理や請求書発行が壊れていないか、担当者が手動で全部確認しなければなりません。1回の確認に30分かかるとして、月に15回の改修があれば月7.5時間の手作業です。テストがあれば、コマンドを1つ実行するだけで1分以内に確認できます。

年間換算では80時間以上の削減。時給3,000円のエンジニアなら年間24万円以上のコスト効果になります。

ただし、テストを書くのには手間がかかります。これをClaude Codeが肩代わりしてくれます。

Claude CodeがTDDをどう変えるか

Claude Codeはテストコードの生成が特に得意です。ただし、何も指示しないとClaude Codeは「先に機能を作ってから後でテストを追加する」という動きをしがちです。これを防ぐためのコツが3つあります。

コツ1: CLAUDE.mdにルールを書いておく

CLAUDE.mdとは、プロジェクトの指示書ファイルです（Claudeに「このプロジェクトではこう作ってください」と事前に教えておく設定ファイル）。ここにTDDルールを書いておくと、毎回指示しなくても自動的にテストファーストの開発をしてくれます。

CLAUDE.mdに追記する内容の例はこちらです（そのまま貼り付けて使えます）:

## 開発フロー（テスト必須）

- 新機能・バグ修正はすべてテストを先に書いてから実装する
- テストが失敗することを確認してから実装に進む
- 最小限の実装でテストを通す
- その後コードを整理・改善する
- テストファイルは対象ファイルと同じ場所に配置する

これだけで、Claude Codeはテストを後回しにしなくなります。一度書けば、セッションを再開しても有効なルールです。

コツ2: 依頼の仕方を変える

Claude Codeへの指示（プロンプト、AIへの指示文）の書き方で、品質が大きく変わります。

今までの依頼例（テストなし開発になりがち）: 「メールアドレスの入力チェック機能を作ってください」

改善後の依頼例（TDDになる）: 「メールアドレスの入力チェック機能を作りたいです。まず先にテストファイルだけ作成してください。実装ファイルはまだ作らないでください。正常なケース・異常なケース・空白のケースを含めてください」

この2文の違いが、後になって数時間のバグ対応の差を生みます。「まずテストファイルだけ」という一言が重要です。

コツ3: 見落としを洗い出させる

Claude Codeに「このテストで見落としているケースを5つ挙げてください」と聞くだけで、人間では気づきにくい想定外の動作をチェックリストに加えられます。

たとえばメールアドレスのチェックなら:

  • 大文字混じりのアドレス（User@Example.COM）
  • 仕事用のプラスエイリアス（user+work@example.com）
  • スペースが前後に入っている場合
  • 超長いアドレス（254文字制限）
  • 国際化ドメイン（日本語のドメイン名）

これらを全て手動で思いつくのは難しいですが、AIに聞けば数秒で出てきます。「AIに仕様の見落としを発散させ、人間が採用するものを選ぶ」という分業がTDDとうまく噛み合います。

図: Claude CodeでのTDD実践の流れ（画像生成待ち）

実際の依頼の流れ（問い合わせフォームの入力チェックを例に）

社内の問い合わせフォームにメールアドレスの入力チェック機能を追加する例で、実際の流れを見てみましょう。4ステップで完結します。

ステップ1: テストを先に作る依頼

Claude Codeへの指示: 「問い合わせフォームのメールアドレス入力チェック機能を作りたいです。まず最初にテストファイルだけ作成してください。実装ファイルはまだ作らないでください。確認したいケース: 正しいメールアドレス、@マークがない場合、何も入力されていない場合、空白だけの場合」

Claude Codeはテストファイルだけを作成します。このとき実装がないので、テストは必ず失敗します（これをRedフェーズと呼びます）。失敗を確認することで「テストが機能している」ことを検証できます。

ステップ2: 実装を依頼する

Claude Codeへの指示: 「テストが失敗していることを確認しました。テストが全て通る最小限の実装を作成してください。余分な機能は追加しないでください」

Claude Codeはテストを通すための必要最小限のコードだけを書きます（Greenフェーズ）。余計な機能を作らないので、後の変更が楽になります。

ステップ3: コードを整理・改善する

Claude Codeへの指示: 「テストが全て通っています。コードをきれいに整理してください。ただし、テストファイルは変更しないでください」

テストが変わらないので、整理しても動作が変わっていないことが自動で確認できます。テストが「変更してはいけないもの」の基準として機能します。

ステップ4: 見落とし確認

Claude Codeへの指示: 「現在のテストを読んで、見落としているケースを5つ提案してください。実装は変えないでください」

この4ステップを繰り返すことで、バグの少ない機能を確実に積み上げていけます。発注者としてこのフローを知っておくことで、外注先の開発進め方の品質を確認できるようになります。

非エンジニアが得られる具体的なメリット

メリット1: バグ修正コストが下がる

テストなし開発では、バグが本番環境で発生してから修正と動作確認に平均2〜4時間かかります。テストありの開発では開発中に自動検出されるため、30分以内に解決できるケースが増えます。月に3件のバグが出るシステムなら、月6〜9時間の工数削減になります。

メリット2: 引き継ぎが楽になる

テストはドキュメント（説明書）としても機能します。「このシステムは何をするのか」がテストを見るだけでわかります。外注先が変わるときや、社内のシステム担当者が変わるときに、テストがあると新担当者の学習コストが大幅に下がります。

メリット3: 機能追加が安心して進められる

テストがないシステムに機能を追加するのは、地雷原を歩くようなものです。「どこかを変えると別のところが壊れるかも」という不安から、改修の提案が出にくくなります。テストがあれば変更後に全チェックを自動実行できるので、改善提案が出やすくなります。

メリット4: Claude Codeが仕様を正確に理解する

テストは要件定義（何を作るかの取り決め）の具体化でもあります。「メールアドレスをチェックする」という曖昧な指示より、テスト形式で書かれた仕様の方がClaude Codeに正確に伝わります。認識のズレが減り、作り直しが少なくなります。

図: TDDあり・なしの開発比較（画像生成待ち）

TDDを導入すべき場面・そうでない場面

全てのシステムにTDDが必要なわけではありません。費用対効果を考えて判断する選択肢があります。

特に効果が出やすい場面

受発注システム、請求書処理、在庫管理など、計算や条件分岐が多い業務ロジックでは効果が高くなります。具体的には、金額計算（1円でもずれると問題になる）、複雑な条件で変わる割引計算、複数の承認フローを持つワークフローなどです。また長期間使い続けるシステム（3年以上の運用想定）や、複数人が関わるプロジェクトでも恩恵が大きくなります。

無理に使わなくてよい場面

1〜2週間の使い捨てスクリプト（データ移行作業のような一回きりの処理）や、表示だけでロジックのないシンプルな画面、プロトタイプ・試作品には、テストを書くコストが見合わないことがあります。何でもTDDにすれば良いわけではなく、目的に応じた使い分けが現実的です。

まず今日からできる3ステップ

Claude Code×TDDを始めるための最初のステップを3つ提案します。

第一歩として、今開発中のシステムのCLAUDE.mdに「新機能はテストを先に書いてから実装すること」という一行を追加してみてください。これだけで効果が出始めます。

第二歩として、次に何か機能を追加するときに、依頼文の冒頭に「まずテストファイルだけ作成してください。実装はまだ作らないでください」という文を加えてみてください。

第三歩として、テストが書けたら「見落としているケースを5つ提案してください」と聞いてみてください。想定外のケースが必ず出てきます。

この3ステップを試すだけで、品質への意識が変わります。システム開発の発注者として「テストが書かれているか」を確認する習慣が身につくと、外注管理の質も上がります。バグが少ないシステムは、長期的に見て開発コストを大幅に下げる投資になります。