【結論】最も効果的なのは調査・再現・小さな修正・検証の一連化
Claude Codeはゼロから大量生成させるだけでなく、既存コードの理解、バグ再現、テスト追加、限定的なリファクタリング、差分レビューで高い効果を発揮します。
おすすめの流れは、Planモードで調査し、失敗を再現し、最小修正を行い、対象テストと全体テストを順に実行する方法です。
対象と完了条件を限定すれば、不要な変更と利用量を抑えられます。
cd my-project
git status --short
claude
# セッション内
/plan
具体的な手順・設定方法
-
コード理解では、主要な入口、データフロー、依存関係をファイル参照付きで説明させます。
推測と確認済み事実を分けて出力させてください。
-
バグ修正では、先に失敗を再現するテストを追加し、その後に実装を直します。
再現できない場合は変更を止める条件を入れます。
-
リファクタリングでは動作変更を禁止し、対象テストの前後結果とgit diffを比較します。
大規模変更は複数コミットへ分割してください。
git diff --check npm test
実践プロンプト / 活用テクニック
テスト生成を丸投げするより、公開API、境界値、失敗条件、モック禁止範囲を指定すると実用的になります。
PRレビューは読み取り専用サブエージェントへ委譲し、実装修正と役割を分けると安全です。
src/services/order-service.tsの不具合を修正してください。
最初に関連テストと呼び出し元を調査し、現在の失敗を再現するテストを1件追加してください。
再現できた場合だけ、公開APIを変えずに最小修正を行ってください。
正常系、空配列、null入力、外部API失敗のケースを確認してください。
変更後は対象テスト、型チェック、全体テストの順で実行し、変更ファイルと残るリスクを報告してください。
注意点・よくあるエラーと対処法
-
AIが生成したテストが実装の誤りをそのまま正解として固定する場合があります。
仕様書や既存の利用側から期待動作を確認し、テストだけを根拠にしないでください。
-
「テストが通るまで直して」だけでは、テスト削除や弱体化で成功させる危険があります。
既存テストの削除、skip、期待値変更を禁止してください。
-
同じファイルを人間とClaudeが同時編集すると競合します。
依頼前に未保存変更を整理し、作業後は差分とコミット単位を確認してください。
git status --short git diff