Claude Codeで小さな修正を安全に進める

この記事では、調査フェーズで作った方針を使って、最小修正を実装する。
ポイントは「変更範囲を先に固定する」こと。

このステップでやること

• 実装条件を明示して修正を依頼
• 仕様外の変更を防ぐ
• 変更後に git diff を説明させる

前提

• 03. 読んでから直す（Reading & Planning） の調査結果がある
• /contact の email未入力送信バグを修正対象として合意済み
• 修正方針に合意済み

作業前チェック（3分）

cd ~/sandbox/claude-code-practice/form-bug-demo
git switch -c fix/contact-email-required
git status --short

• 作業ブランチを作ってから修正する
• 未コミット差分が多い場合は、対象外変更を混ぜないよう注意する

実装依頼テンプレート

以下をそのまま使える。

先ほどの方針に沿って、/contact の email未入力送信バグを最小修正してください。

条件:
- 既存UIは変更しない
- 仕様外のリファクタはしない
- 変更範囲は必要最小限にする
- email が空なら送信を止め、画面にエラーメッセージを出す
- 変更後に git diff を確認し、変更理由を説明してください
- 変更後に実行したコマンドと結果を箇条書きで報告してください

編集承認ダイアログが出たとき

Claude Codeがファイル編集前に、次のような確認を出すことがある。

• Yes: 今回の1回だけ編集を許可
• Yes, allow all edits during this session: このセッション中の編集をまとめて許可
• No: 編集しない

このハンズオンでは、最初は Yes を選ぶのがおすすめ。
どのファイルが編集対象かを都度確認できるため、安全に進めやすい。

実務での進め方

1. 1回目の修正を実行

まずは最小修正を1回実行し、差分を見る。

git diff --name-only
git diff

2. 差分説明を確認

次を確認する。

• 変更理由が仕様に沿っているか
• 関係ないファイルが混ざっていないか
• 命名や実装スタイルが既存と合っているか

3. 必要なら追加で制約をかける

例:

• ファイル分割はしない
• 既存関数名を変えない
• ログ文言だけ変更しない

ありがちな失敗

一度に広く直させる

品質改善やリファクタ（refactoring、外部の振る舞いを変えずにコードの構造・可読性を改善すること）まで同時に依頼すると、差分が肥大化しやすい。

変更意図の確認を省く

git diff の説明を取らないと、不要変更に気付きにくい。