大きな作業を一気に投げると、だいたいロクなことにならない。Claude Code でも同じで、広い範囲をまとめて触らせるほど、意図しない変更が混ざるし、あとから差分を読むのも地獄になる。
ここでやるべきなのは、仕事を小さく切ることだ。Claude Code に「全部やって」で渡すのではなく、変更の境界を先に決める。そうすると、差分が読みやすくなるだけではない。途中で止めて確認しやすいし、手戻りしても被害が小さい。ファイル整理でも、文章修正でも、コード修正でも、この考え方が効く。
筆者は最初、ひとまとまりの依頼をそのまま投げて、関係ないファイルまで巻き込まれたことがある。修正点そのものは合っているのに、差分が太りすぎてレビューで疲れるやつだ。あれはかなりだるい。以後は「どこまでやるか」を先に決めてから頼むようにしている。
差分を小さくするコツは、作業を結果で分けるのではなく、工程で分けることだ。
たとえば、ひとつの大きな改修があったとする。いきなり完成版を作らせるより、こう分ける。
Claude Code には、この順番で順に依頼する。いきなり「全部まとめて直して」ではなく、「まず対象箇所を洗い出して」「この範囲だけ触って」と段階を踏ませると、変更の暴発がかなり減る。
たとえば文章ファイルの整理なら、次のように切る。
このフォルダ内の文書を確認して、重複しているファイル名候補と不要そうな下書き候補だけを挙げてください。
実際の削除はまだしないでください。
次に、対象を絞る。
この一覧のうち、A案とB案は残し、C案以降は触らずに、削除候補だけを整理してください。
ファイルの移動はまだしないでください。
最後に実行する。
削除候補のうち、更新日が古く、本文も重複しているものだけを削除してください。
削除前に最終確認の一覧を出してください。
この切り方だと、間違っていても途中で止められる。差分も一段ずつ小さい。
Claude Code に大きな変更をさせるときは、まず計画だけ出させるのがいい。これはコーディングでも文書でも変わらない。
この変更をいきなり実行せず、まず作業を3段階に分けた計画を出してください。
各段階で触るファイルと、増える差分の方向性も書いてください。
ここで大事なのは、計画の粒度だ。「全体を修正する」みたいなふわっとした計画は意味がない。実際にどのファイルを触るか、どの文書を先に直すか、どの作業を後回しにするか、そこまで落とす。計画の時点で範囲が膨らみすぎていたら、その場で止める。
筆者は、これを飛ばして実行まで一気に進めたせいで、関係ない説明文の整形まで混ざったことがある。見た目はきれいだが、差分がでかい。レビュー対象としては最悪だ。先に計画を出させるだけで、そういう無駄がかなり減る。
差分を小さくしたいなら、単にファイル数を減らすだけでは足りない。ひとつの依頼文に別目的を混ぜると、Claude Code はそれなりに頑張ってしまう。結果、ひとつの差分に複数の意図が入り込む。
悪い例はこうだ。
この資料を読みやすくして、ついでに古い内容を整理して、名前もわかりやすく変更してください。
これだと、読みやすさの改善、内容整理、ファイル名変更が混ざる。変更の理由が追いにくいし、戻すときも面倒だ。
こういうときは、目的ごとに分ける。
まず本文の読みやすさだけを改善してください。内容は変えないでください。
次に、別の依頼で。
次に、古くなった記述だけを洗い出してください。修正はまだしないでください。
さらに必要なら。
最後に、ファイル名を見直してください。内容変更とは分けて進めてください。
この分け方だと、差分の意味がはっきりする。あとで見返したとき、「何のための変更か」が一目でわかる。これは地味だが強い。
区切り方で特に効くのが、やってほしくないことを先に伝えるやり方だ。Claude Code は余計な親切をしてくることがある。だから境界線を引く。
この修正では、次の3つはしないでください。
- ファイルの移動
- 変数名の変更
- 書式だけの整形
内容の誤り修正だけに絞ってください。
この手の指定は、差分を小さく保つのにかなり効く。変更の意図がぶれにくいからだ。
非エンジニアの作業でも同じで、たとえば書類の整理ならこう言える。
このフォルダでは、名前の変更だけしてください。
中身の書き換え、フォルダ移動、削除はしないでください。
この一文があるだけで、事故の確率がかなり下がる。中身まで触られたら困る案件は多い。契約書のドラフトや提出前の文書なんて、特にそうだ。
Claude Code に大きな作業をさせるとき、よくある失敗は「作業の中身」だけ指定して、「触っていい範囲」を指定しないことだ。これをやると、モデルは関連しそうな場所まで見に行く。たしかに理にかなっているが、差分は太る。
なので、最初から対象を限定する。
この変更は、src/main.ts と src/utils.ts だけで完結させてください。
それ以外のファイルには触らないでください。
文書整理でも同じだ。
この作業は、2024年分の請求書フォルダだけを対象にしてください。
他の年のフォルダは見ないでください。
対象を狭くすると、確認もしやすい。広い範囲を一度にいじるより、あとで「ここだけ見る」ができるほうが強い。
差分を小さく保つなら、確認の回数を増やすのはケチらないほうがいい。途中確認は面倒に見えるが、実際は逆だ。でかい差分を後で直すほうが、ずっと面倒になる。
たとえば、こんなふうに進める。
まず変更案を出してください。
私が確認したら、最小限の修正だけ入れてください。
あるいは、実行後にすぐ点検させる。
修正後の差分を見て、今回の目的に関係ない変更があれば列挙してください。
ここでのポイントは、Claude Code に自分で差分を点検させることだ。もちろん完全ではないが、雑な変更を炙り出すには十分役立つ。
筆者はこの確認を飛ばして、説明文の修正だけのつもりが、関連セクションの言い回しまで全部変わってしまったことがある。意味は通るが、差分の意図がぼやける。こういうのはレビューで嫌われる。小さな確認を挟んでおけばよかった話だ。
実務で扱いやすいのは、ひとつの大きな完成形を目指すやり方ではない。小さく完成させて、そのたびに止めるほうだ。
たとえばコード修正なら、こう進める。
まず影響範囲を洗い出してください。
次に、その中で最小の修正案だけを出してください。
最後に、その修正案を実装してください。
文書作成なら、こうなる。
まず見出しだけ整えてください。
次に、各段落の重複を削ってください。
最後に、表現を整えてください。
この順番にすると、各段階の差分が小さい。どこでおかしくなったかも追いやすい。
差分を小さくするというのは、単に変更量を減らす話ではない。見直しやすさ、戻しやすさ、説明しやすさを全部まとめてよくする話だ。Claude Code は強いが、強いからこそ、区切り方が雑だと一気に崩れる。逆に言えば、区切り方さえうまければ、かなり安全に使える。
大きな変更を扱うときは、まず「何をやるか」より「どこで止めるか」を決める。そこを先に決めるだけで、作業の質が目に見えて変わる。