変更しない挙動を列挙する
例えば料金計算の重複を整理するなら、入力、丸め方、割引の適用順、表示する通貨を先に確認します。現在のコードだけでなく、仕様書や担当者が確認した例を根拠にしてください。現行コードに不具合がある場合も、今回直すのか維持するのかを決め、整理と仕様変更が混ざらないようにします。
調査だけを先に頼む
関数の呼び出し元、状態の変更、外部へのアクセスを説明してもらいます。どの処理が共通で、どこに例外があるかを確認してから、新しい共通関数を作るかを判断します。名前が似ている二つの処理でも、返す値やエラー時の動作が違うなら、安易に一つへまとめない方が維持しやすいことがあります。
一つの変更で一つの目的にする
変数名の変更、共通処理の抽出、ライブラリの置き換えを同時に行うと、失敗した原因を探しにくくなります。まず一つの呼び出し元で抽出結果を確認し、次に他の呼び出し元へ適用します。各段階で差分と確認結果を保存すると、想定外の変化が出た地点へ戻れます。
テストは人が期待値を確認する
生成されたテストが、新しい実装の結果をそのまま正解にしていないかを読みます。正常値に加えて、空入力、上限、無効な値、既存の例外を含めます。UIの変更なら、画面を開いたときの状態や操作後の保存も確かめます。テストが多いことより、守るべき条件が実際に検証されていることが重要です。
例:共通関数へ移す順序
同じ計算が三つの画面にある場合、まず一つの画面だけを共通関数へ置き換えます。事前に用意した入力例で結果を確かめ、差分がその画面に限定されていることを確認してから、残りへ適用します。三画面をまとめて変更するより、どの段階で挙動が変わったかを追いやすく、採用する範囲も選びやすくなります。
ツールは採用しやすさで選ぶ
Claude Code、Aider、Cursorなどを試すときは、同じ小さな整理を課題にします。採用した差分を説明できるか、不要な変更を取り除けるか、別の担当者が続きを修正できるかで判断します。全面的な書き換えを短時間で生成したことより、既存コードを壊さず少しずつ改善できることを重視しましょう。
参照した公式情報
料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。
- Claude Code overview情報確認日: 2026-10-27
- Aider usage情報確認日: 2026-10-27
- Cursor Agent overview情報確認日: 2026-10-26
- Claude Code costs情報確認日: 2026-10-27
- Claude Code permissions情報確認日: 2026-10-27
- Aider chat modes情報確認日: 2026-10-27
- Aider models and keys情報確認日: 2026-10-27
- Cursor pricing情報確認日: 2026-10-26
- Cursor models and pricing情報確認日: 2026-10-26