「直してから確認する」は、だいたい遠回りだ。Claude Code にも同じで、まず壊れるテストを作らせてから、その赤を消す形でコードを直すほうが、手戻りが少ない。
このやり方の良さは単純だ。何を満たせばいいかが先に固定される。しかも、Claude Code が勝手に話を広げにくい。いきなり実装をいじらせると、見た目は動いても境界条件を落とすことがある。先に失敗するテストを書かせれば、「何を守るべきか」をコードより先に置ける。
筆者も最初は、仕様を口で説明してそのまま直させていた。すると、動くけれどテストが増えない。次に同じ不具合が出たとき、また同じ説明を繰り返す羽目になる。そこで先にテストを書かせるようにしたら、会話の焦点が一気に締まった。曖昧な依頼が減るし、差分も追いやすい。かなり地味だが、効く。
やり方はこうだ。Claude Code に最初から「壊れているテストだけを作れ」と頼む。実装はまだ触らせない。たとえば Python なら pytest、JavaScript なら既存のテストランナーに合わせて書かせる。非エンジニアが文書整理やファイル整理に使う場合でも同じで、たとえば「重複ファイルを検出する」「指定フォルダの古いファイルだけを拾う」といった振る舞いを、先に検証用のテストに落とす発想だ。
今の実装には手を入れず、まず失敗するテストだけを書いてください。
狙いは次の振る舞いです。
- 〇〇の場合は△△になる
- ××の場合はエラーになる
- 既存の正常系は壊さない
テストが失敗することを確認したら、そのテストが通る最小限の修正だけを行ってください。
最後に、どの変更でテストが通ったかを短く説明してください。
もう少し実務寄りにするなら、対象ファイルや確認ポイントを先に渡すといい。Claude Code は広げようとすることがあるので、範囲を切ったほうが安定する。
対象は src/parser.py と tests/test_parser.py だけです。
まず tests/test_parser.py に失敗するテストを追加してください。
要件は次の2つです。
1. 空の入力は例外にする
2. 末尾に余計な空白があっても、同じ結果になる
テストが赤になるのを確認する前提で進めてください。
その後、src/parser.py を最小限だけ直してください。
ここで大事なのは、「テストを書いて終わり」にしないことだ。失敗するテストを先に書かせる狙いは、実装の正しさを縛ることにある。だから、テストを書いたあとに必ず run tests まで行かせる。Claude Code に実行までさせると、勘違いで終わらない。
pytest tests/test_parser.py
JavaScript なら、プロジェクトの普段のコマンドを使えばいい。
npm test
あるいは、変更対象だけを絞って回す。全部を毎回走らせる必要はない。そこまでやると、ただでさえ長いコンテキストがさらに無駄になる。Claude Code は会話の長さに比例して、細部の優先順位がぼやけやすい。小さく回して、小さく直すのが正解だ。
失敗しやすいのは、テストの中身まで Claude Code に丸投げしてしまうケースだ。ここが雑だと、テストが実装の書き換えに引っ張られる。たとえば「とにかく通るテスト」を先に書かせると、確認したい要件ではなく、今あるコードに都合のいい形に寄ってしまう。筆者は一度これで痛い目を見た。例外メッセージの完全一致まで固定したせいで、後からメッセージ文言を少し変えただけで不要な壊れ方をした。検証したいのは振る舞いであって、文字の細部ではなかったのに、そこを取り違えたわけだ。
だから、先に書くテストは「何が起きるべきか」を表すものに絞る。内部実装を固定しすぎない。戻り値、ファイルの生成有無、エラーの種類、件数、並び順くらいで足りることが多い。逆に、関数の中でどう分岐したかをテストし始めると、急に息苦しくなる。
そのテストは、実装の細部ではなく振る舞いを確認する形にしてください。
たとえば次のようにしてください。
- 戻り値
- 生成されたファイルの有無
- 件数
- エラーの種類
文字列の完全一致や内部関数の呼び出し回数には寄せすぎないでください。
もう一つの落とし穴は、「失敗するテスト」を頼んだのに、Claude Code が先回りして実装まで触ってしまうことだ。これもよくある。そういうときは、指示を分けるといい。まずテストだけ、次に実装だけだ。1 回で全部やらせない。段取りが悪いと、差分が太って追いづらくなる。
第1段階ではテストだけ追加してください。実装は変更しないでください。
第2段階は、追加したテストが失敗するのを確認してから、実装を直してください。
この順番を守ると、レビューも楽になる。テストが先にあるので、「この変更は何を守るためか」が見える。特に複数人で触るコードや、あとで自分が見返す作業では効いてくる。ファイル整理のような作業でも同じで、先に検証の目印を置いてから整理するほうが、あとで「どこをどう変えたか」が追いやすい。いきなり片づけると、再現性がなくなる。
応用するなら、バグ修正だけでなく、仕様確認にも使える。たとえば「この条件なら除外されるはず」「このフォルダ構成なら対象になるはず」という期待をテストにしてから、Claude Code に実装を直させる。文書作成でも、生成した文章のチェック観点を先にテスト化しておくと、見出し漏れや禁止語の混入を見つけやすい。
要するに、Claude Code には「直して」と言うより、「まず失敗を固定してから、それを消せ」と言ったほうが強い。先に赤を作る。そこから青にする。順番をひっくり返さないだけで、手戻りはかなり減る。仕様があいまいなときほど、このやり方が効く。もしテストランナーや書き方の細部が怪しいなら、そこは公式ドキュメントで確認してから進めるのが安全だ。