「直しました」で終わらせると、たいていどこかがまだ死んでいる。見た目は直っていても、テストは別の場所で赤いまま、あるいは差分だけ眺めると肝心の修正が抜けている。そこで効くのが、検証と照合だ。テスト結果と git diff を突き合わせる。これだけで「直したつもり」のまま次に進む事故がかなり減る。
Claude Code でも同じで、修正依頼を出して、返ってきた変更をそのまま信じるのは雑すぎる。AI はちゃんと直すこともあるが、関係ない箇所を触ったり、テストの失敗原因を外したまま別方向をいじったりもする。だから最後は、人間が「テストが指している場所」と「差分で実際に変わった場所」を重ねて見る。ここをサボると、手戻りが増える。かなり露骨に増える。
たとえば、こんな流れだ。
git diff
で変更点を見てから、
npm test
# あるいは
pytest
# あるいは
go test ./...
でテストを走らせる。失敗したら、そのエラーメッセージと diff を同時に見る。Claude Code に頼むときも、ただ「直して」では弱い。こう投げるといい。
テスト結果を確認し、失敗箇所に対応する差分だけを見て、直したつもりの変更が残っていないか照合してください。
関係ない箇所を広く触らず、失敗しているテストと変更内容の対応関係を説明したうえで修正してください。
もう少し実務っぽくするなら、失敗したテストの断片も一緒に渡す。
以下のテストが失敗しています。
<エラーメッセージや失敗したテスト名>
この失敗内容と現在の差分を突き合わせて、原因になっている変更だけを修正してください。
修正後は、変更箇所がテストの期待と一致しているかを短く説明してください。
ここで大事なのは、「テスト結果」と「差分」を別々に読ませないことだ。別々だと、Claude Code はどちらもそれなりに理解して見せるが、最後のつなぎが甘くなることがある。つまり、テストは落ちているのに、差分は見た目だけきれい、という状態だ。これが一番だるい。直った気分だけが先に来るからだ。
筆者が一度やらかしたのは、文書生成のテンプレートを直したつもりで、実は失敗テストが見ていた出力ラベルを一行ずらしただけだった件だ。差分だけ見ると「それっぽく」修正されている。けれどテストは古い文言を探して落ち続ける。あの手の事故は、変更行数が少ないほど見つけにくい。だからこそ、失敗したテスト名や期待値と、実際の差分をその場で照合する癖が効く。
照合のやり方は、むずかしくない。順番を固定すればいい。
まずテストの失敗文を見る。次に、どのファイルのどの行が怪しいかを確かめる。最後に、その修正がテストの期待と一致しているかを見る。ここで「一致しているか」を雑に済ませない。たとえば、エラー文が「一覧に A が出るべき」と言っているのに、差分では B の説明文だけを直している。そういうのは直っていない。派手に外している。
Claude Code に確認役をやらせるなら、こういう頼み方が実用的だ。
このテスト失敗の内容と、現在の git diff を照合してください。
- 失敗しているテスト名
- 失敗メッセージ
- 変更されたファイル
- その変更が失敗原因に対応しているか
対応していない変更があれば、それも指摘してください。
この聞き方のいいところは、AI に「直す」だけでなく「対応関係を説明させる」点だ。説明が破綻していたら、たいてい修正も甘い。逆に、対応関係を言葉で示せるなら、変更の筋は通っていることが多い。
注意したいのは、テストが全部通ったからといって終わりにしないことだ。通っても、意図とズレた修正は普通にある。たとえば、削除したはずの表示が別の条件分岐に残っていたり、ファイル整理で重複を消したつもりが、別フォルダの参照だけ変えていたりする。テストが見ていない場所は平気で残る。だから差分を見る。逆に、差分がきれいでもテストが落ちているなら、その修正はまだ半端だ。
非エンジニア寄りの作業でも同じだ。たとえば、フォルダを整理して不要ファイルを減らすとき、Claude Code に「重複を消して」とだけ頼むと、見た目は整っても、実は重要な類似ファイルまで触っていることがある。そこで、削除候補の一覧と実際の変更差分を照合する。何を消したのか、なぜ消していいのか、戻せるのか。この三つが噛み合っていれば安心できる。雑に片付けると、あとで「あれ、必要だった」となる。あれは地味に痛い。
一歩進めるなら、修正ごとに「どのテストが何を保証しているか」を頭の中でひも付けておくといい。Claude Code に渡す指示も、そこに寄せる。たとえば、入力のバリデーションを直したなら、そのテストが境界値を見ているかまで確認する。文書作成なら、出力の見出しやファイル名が期待どおりかを見る。ディスク整理なら、削除対象の判定条件が「サイズが大きい」だけなのか、「バックアップでない」ことも含むのかをはっきりさせる。テストと差分が同じ話をしていないなら、その修正はまだ薄い。
最後に、Claude Code への頼み方を少しだけ研ぎ澄ますと効きが変わる。
修正を入れる前に、今あるテスト失敗と現在の差分を照合し、
「どの失敗に対して、どの変更が対応しているか」を先に箇条書きで出してください。
対応が曖昧な変更は入れず、必要最小限の修正だけに絞ってください。
これで、ただの修正屋ではなく、検証と照合を踏んだ確認係として働かせやすくなる。直したつもりを潰すには、勢いで直さないことだ。テストが何を言っているか、差分が何を変えたか。その二つを必ず重ねる。そこを通せば、手戻りはかなり減る。