ブランチを切ってから整理しようとすると、だいたい面倒になる。差分が増え、指示があいまいになり、Claude Code に投げる文面まで雑になるからだ。先に片づける。これを事前整理、着手準備、分割開始の土台づくりとしてやっておくと、変更は小さく始めやすい。
Claude Code は、いきなり「全部直して」と投げるより、対象を絞ったほうが働きやすい。非エンジニアの作業でも同じで、フォルダの山、重複ファイル、長文の資料、散らかったメモを先に整えるだけで、次の一手がかなり軽くなる。ブランチを切る前の整理は、気合いの話ではない。後戻りを減らすための実務だ。
まずやることは単純だ。作業対象を一つに絞る。アプリのコードなら、機能追加なのか、文書修正なのか、不要ファイル削除なのかを分ける。文書作成なら、原稿を整えるのか、章立てを直すのか、語尾をそろえるのかを分ける。ここが混ざると、Claude Code への依頼が一気に濁る。
たとえば、次の順で始めるといい。
コードやファイル整理なら、Claude Code にこう頼める。
このディレクトリを確認して、今回の作業に不要なファイルや重複しそうなものを先に洗い出してください。
変更を大きくしないために、作業対象を小さく分ける案も出してください。
まだ編集はせず、整理の方針だけを返してください。
もう少し実務寄りにするなら、対象をはっきり書く。
docs/ 配下だけを対象にしてください。
やりたいのは内容の修正ではなく、まず章の重複と不要な下書きファイルの整理です。
このあと変更を小さく始められる順番で提案してください。
この段階で大事なのは、Claude Code に「答えを急がせない」ことだ。最初から完成形を求めると、見た目は賢そうでも、差分が膨らみやすい。筆者は以前、文書修正とファイル整理を同時に投げて、結果として修正対象が広がりすぎたことがある。見出しの調整まで頼んだつもりが、構成の見直しに話が飛び、確認コストだけが増えた。小さく始めるつもりが、いちばん大きくなったわけだ。
変更を小さく保ちたいなら、依頼文に「やらないこと」も入れると効く。
今回はリネームだけに絞ってください。
内容の書き換え、構成変更、新規ファイルの追加はしないでください。
まずは名前の揺れと重複だけを整えてください。
この一文があるだけで、無駄な広がりをかなり防げる。Claude Code は指示の範囲内で動くが、曖昧だと広めに解釈する。人間が「このへんで」と思う幅と、ツールが拾う幅は一致しない。ここを放置すると、diff が太る。太った diff はレビューも戻しもだるい。
非エンジニアの作業でも同じだ。たとえば「案件ごとに資料をまとめたい」とき、いきなり全ファイルを触らせると危ない。まずは案件名のついたフォルダだけを見せて、重複書類、古い下書き、名前の似た添付を洗う。次に、残すものだけを決める。順番を逆にすると、片づけたつもりで迷子になる。
このフォルダの中で、同じ内容のファイル名違い、古い下書き、不要な一時ファイルを整理したいです。
削除候補と保留候補を分けて、いきなり消さずに一覧で出してください。
こういう頼み方は、実はかなり効く。先に「候補」を出させると、作業が分割されるからだ。候補確認、確定、実行。この三段階にすると、後で「なんでこれ消した？」が起きにくい。筆者は一度、確認なしで整理を進めて、あとで必要な下書きを探し回った。あれは無駄だった。小さく始めるつもりなら、確認を省かないほうがいい。
もう一つ、ブランチを切る前に見ておきたいのが、作業中のノイズだ。不要なキャッシュ、生成物、バックアップ、テンポラリが残っていると、Claude Code が余計なものまで読みに行きやすい。もちろん全部が悪ではないが、混ざっていると話がややこしい。作業前に捨てられるものは捨てる。置いておくなら理由を決める。これだけで十分だ。
作業前に、今回の変更に関係ない生成ファイルやキャッシュを先に分けてください。
残す理由があるものは残す前提で、削除候補だけを分けてください。
ブランチを切る前の整理でやるべきことは、派手な自動化ではない。対象を狭める。不要物を外す。依頼を短くする。この三つだ。これができると、変更は小さく始まり、レビューも戻しも軽くなる。
小さく始める感覚がつかめたら、次は「一度に何を触らないか」をもっと厳しく決めるといい。コードなら機能単位、文書なら章単位、ファイル整理ならフォルダ単位で切る。Claude Code にも、その粒度をそのまま伝える。大きく直すより、小さく確実に進めるほうが、結局は速い。