Claude CodeのTDDについてお探しですね。
広告
Claude Codeでテストをちゃんと書きながらAIと一緒に開発する方法
AIにコードを書かせるとき、一番困るのが「動くけど、後で見たらめちゃくちゃなコード」が出来上がっちゃうことです。
Anthropic社の「Claude Code」は、ターミナル上で自動的にコードを書いてくれる便利なツールですが、適当に指示を出すだけだと、後で誰も理解できない「スパゲッティコード」になってしまいます。
そこで今回は、AIにちゃんとした規律を持たせる「テスト駆動開発（TDD）」と組み合わせる方法を紹介します。
この方法を使えば、バグが少なくて、後から直しやすいアプリケーションが作れるようになります。
「なんとなくコーディング」の落とし穴
AIを使った開発で最近よく聞くのが「Vibe Coding（ノリでコーディング）」という言葉です。
感覚的に指示を出して、とりあえず動くものをパパッと作るスタイルのことですね。
お試しで何か作るときには便利なんですが、長く使い続けるシステムや、チームで開発するときには危険です。
AIは「とりあえず動くもの」を作るのは得意ですが、既にあるコードにどんな影響が出るかとか、変なケースでも大丈夫かとか、そういう細かいところまで完璧に考えてくれるわけじゃありません。
特にClaude Codeみたいに、ファイルを直接いじれるタイプのAIだと、知らないうちに予想外の変更が加わって、システム全体がガタガタになることもあります。
そこで役立つのが「テスト駆動開発（TDD）」です。
TDDっていうのは、「本番のコードを書く前に、まずテストコードを書く」という開発のやり方です。
これをClaude Codeに使うと、AIに「このテストを通すコードを書いてね」っていう明確なゴールを先に示せるんです。
すると、AIは「なんとなく動けばいいや」じゃなくて、「このテストをクリアしなきゃ」っていう制約の中でコードを書くので、出来上がりの品質がグッと上がります。
さらに、テストコードがあれば、後で機能を追加したり直したりするときにも、「前からある機能を壊してないかな?」って心配しなくて済みます。
テストを走らせるだけで、すぐにチェックできるからです。
つまり、TDDはAIを優秀なプログラマーとして使いこなすための「手綱」みたいなものなんですね。
準備：CLAUDE.mdでAIに「ルール」を覚えさせる
Claude CodeでTDDをうまく使うには、まずAIに「常にテストから始めてね」っていうルールを覚えさせる必要があります。
そのために一番効果的なのが、プロジェクトのフォルダに「CLAUDE.md」っていう設定ファイルを置くことです。
このファイルは、Claude Codeがプロジェクトのルールや背景を理解するための「マニュアル」みたいなものです。
ここにちゃんとした指示を書いておけば、毎回「TDDでやってね」って言わなくても、AIが自動的にそのやり方で動いてくれます。
一貫性のある開発ができるようになるわけです。
具体的には、`CLAUDE.md`の中に「開発の基本方針」とか「会話のルール」みたいなセクションを作って、TDDのルールを書き込みます。
例えば:
– 基本的にテスト駆動開発で進めること
– 期待される動きを考えて、まずテストを作ること
– コードを書く前に必ずテストを実行して、失敗することを確認すること
– 実装中はテストコードをいじらないこと
あと、「常に日本語で答える」っていうルールも入れておくと、説明や確認がスムーズになって、日本人にとってはすごく使いやすくなります。
この初期設定をするだけで、Claude Codeは単なる「コード生成マシン」から、ちゃんとルールを守ってくれる「開発パートナー」に変わります。
実際のTDDの進め方：要件から仕様書まで
では、実際にClaude Codeを使ってTDDで開発するときの流れを見ていきましょう。
大事なのは、AIが書いたテストコードが本当に自分の考えと合ってるかをちゃんと確認することです。
プログラミングがあまり得意じゃない人でも、この流れに沿えば確実に開発できます。
ステップ1：やりたいことを伝えて、テストコードを作る
最初にやるのは、作りたい機能を言葉でAIに伝えて、テストコードだけを作ってもらうことです。
この段階では、実際のコードは一切書きません。
テストファイル（例えば`xxx.test.ts`）だけを作ります。
例えば「ユーザーのログイン状態を管理したい」っていうざっくりした要望から始めて、AIと話しながら「どんな情報が必要?」「成功ってどういう状態?」を具体的にしていきます。
要件が固まったら、「この仕様を満たすテストコードを書いて。
まだ実装がないから失敗するはずだよ」って指示します。
テストを実行して、ちゃんと失敗する（RED状態になる）ことを確認します。
これで、テストがちゃんと機能してることが分かります。
ステップ2：仕様書を逆に作ってもらって、内容を確認する
ここがAI時代ならではの面白いステップです。
作られたテストコードは「実行できる仕様書」みたいなものなんですが、コードだけ見て全部理解するのは大変です。
そこで、Claude Codeに「このテストコードを見て、日本語の仕様書を作って」って頼みます。
テストコードから「どんなパターンをテストしてるか」「どんな動きを期待してるか」を日本語の文書にしてもらうんです。
この逆生成された仕様書を読めば、自分の考えとテストの内容にズレがないか、抜けがないかを、コードを書く前に確認できます。
もしズレがあったら、この段階でテストを直してもらいます。
ステップ3：コードを書いて、きれいにする
仕様（テスト）が確定したら、いよいよ本番のコードを書く段階です。
「このテストを全部通すように、必要最小限のコードを書いて」って指示します。
AIはテストっていう明確な正解があるので、迷わず最短ルートでコード（GREEN状態）を作ってくれます。
テストが全部通ったら、最後に「リファクタリング」をします。
機能は変えずに、コードを読みやすく、直しやすくするようAIに頼みます。
この時もテストがあるから、直したことで機能が壊れてないかをすぐチェックできて、安全にコードをきれいにできます。
もっと効率的に：コマンドで自動化しよう
TDDのサイクルに慣れてきたら、この流れ自体を自動化して、もっと効率よくしましょう。
Claude Codeには、よく使う指示や作業の手順を「カスタムスラッシュコマンド」として登録できる機能があります。
これを使えば、誰がやっても同じ品質で開発できるようになります。
例えば、`/tdd-red`っていうコマンドを作って、「要件を聞いて、テストコードを作って、実行して失敗を確認する」っていう一連の流れをまとめておきます。
同じように、`/spec-gen`でテストから仕様書を作る、`/tdd-green`で実装してテストを通す、みたいにコマンドを登録しておけば、コマンドを打つだけで複雑な作業をAIが自動でやってくれます。
人間は「コマンドを打つ」ことと「出来上がった仕様書や動きをチェックする」ことに集中できて、いちいち長い指示を書く手間が省けます。
もっと進んだ使い方として、GitHub Actionsみたいな自動化ツールや、MCP（Model Context Protocol）で外部ツールと連携させることもできます。
例えば、Issueが作られたら自動的にClaude Codeが要件を読んで、仕様書案とテストコードを作ってPull Requestを送ってくる、なんてこともできちゃいます。
でも、まずはローカル環境でスラッシュコマンドを整えて、自分に合ったTDDのやり方を確立することが大切です。
「AIに振り回される」んじゃなくて、AIを「指揮する」ための土台として、これらの機能を使いこなしていきましょう。
これが、これからのエンジニアに求められるスキルなんです。
広告
