ブランチを切ってから考える人は、だいたいあとで自分の差分に殴られる。
変更を小さく始める準備、作業開始前の下ごしらえを飛ばすと、Claude Code に渡す文脈が散らかる。すると指示は長くなるし、余計なファイルまで触るし、diff もでかくなる。手戻りの回数が増えるのは、たいていここだ。
Claude Code は、雑な状態でもそれなりに進めてしまう。そこが便利でもあり、危ないところでもある。
だからブランチを切る前に、作業対象を絞り、不要物を片づけ、今から何をやるかを一度だけ言葉にしておく。これだけで、生成される提案の精度がかなり変わる。非エンジニアのファイル整理でも同じだ。案件フォルダ、請求書、原稿、重複画像がごちゃついたまま頼むと、まず整理にコンテキストを食われる。先に片づけるほうが早い。
ブランチ名を考える前に、Claude Code に見せる範囲を狭める。これが一番効く。
巨大なリポジトリ全体を相手にすると、文脈が薄まる。人間でも、机の上に関係ない紙が山ほどあると集中できない。それと同じだ。
作業前にやるのは、この三つで足りる。
たとえば、機能追加なら「この画面の入力欄だけ直す」。文書整理なら「この案件フォルダの重複原稿を消して版をそろえる」。このくらい雑でいいが、対象は狭く言い切る。
Claude Code に投げる前の依頼文も、最初から長文にしないほうがいい。たとえばこうだ。
このリポジトリの中で、今回の作業に関係するファイルだけを先に洗い出して。
不要な場所には触らない前提で、作業範囲を短く整理してから進めたい。
この一言を先に入れると、いきなり修正案に突っ込まず、対象を絞る流れを作りやすい。
実際、筆者は昔、変更点を言語化せずに「このへん直して」と投げて、関係ない設定ファイルまで候補に出されたことがある。Claude Code が悪いというより、こちらの下ごしらえ不足だ。作業範囲を切らないまま始めると、余計な差分が出る。地味だが、あとで効いてくる。
コードでも文書でも、やることは似ている。
雑に分けると、整理の順番はこうなる。
1. 目的を書き出す
2. いまの変更を確認する
3. 余計なものを退避する
4. Claude Code に作業範囲を絞って依頼する
5. その場で最小差分に寄せる
Git を使っている開発者なら、まず git status で今の汚れ具合を見る。未コミットの変更が山になっているなら、ブランチを切る前に一度区切るべきだ。git stash を使う手もあるが、何を退避したか分からなくなると逆にだるい。大事なのは、差分を見える状態にすることだ。
git status
git diff --stat
ここで「思ったより触っている」と気づいたら、先に分ける。
たとえば、機能修正とフォーマット変更と不要ファイル削除が混ざっているなら、全部いっぺんにやらない。Claude Code に渡す前に、フォーマットだけ別で片づける。ノイズが減るだけで、提案の読みやすさが違う。
文書作業でも同じだ。
契約書、議事録、提案書、参考画像がひとつのフォルダに混ざっていたら、まず分ける。重複ファイル、仮名のファイル、古い版を退避する。Claude Code に「このフォルダを整理して」とだけ頼むと、かなり広く見に行く。だから、対象を先に絞る。これは面倒ではなく、むしろ最短ルートだ。
ブランチを切る前に整理したい場面では、禁止事項を先に書くのが効く。
Claude Code は柔軟だから、曖昧な指示だと余計に動く。そこで「ここには触らない」と先に伝える。
次の作業に入る前に、対象ファイルを整理したい。
- 触るのは src/app/ 配下だけ
- 設定ファイルは今回は変更しない
- ついで修正はしない
- まず整理方針を短く出してから進める
この手の依頼は、地味だが強い。
「ついで修正をしない」と明示するだけで、diff が肥大化しにくい。筆者は一度、整理のつもりでコード整形まで混ざってしまい、レビューで「結局何を変えたのか分かりにくい」と言われた。痛い。ブランチ前に整理していれば避けられた話だ。
非エンジニア向けなら、こう置き換えればいい。
この案件フォルダの中で、納品に関係するファイルだけ残したい。
- 重複している原稿は別フォルダへ移す
- 古い版は削除せず退避する
- 画像と本文を分ける
- まず整理案を出してから実行する
ここでも、いきなり実行させないのがコツだ。
先に整理案を出させれば、迷いどころが見える。フォルダ構成が変な場合も、いきなり壊しにくい。
整理で失敗しやすいのは、作業前に片づけた気になっているケースだ。
たとえば、見た目だけ整えて、実は不要ファイルが残っている。あるいは、別件のメモまで同じフォルダに入っている。こういう状態で Claude Code に頼むと、関係ない情報を拾う。これはかなりもったいない。
特に気をつけたいのは、次の二つだ。
一つ目は、ブランチを切る前に「あとでやる」を増やしすぎることだ。
あとでやる予定の修正が溜まっているなら、今の作業と分ける。混ぜると、あとで戻れない。git diff が太り、レビューも重くなる。
二つ目は、作業フォルダに古いメモや生成物が残っていることだ。
Claude Code はそこまで勝手に善意で除外してくれない。だから、不要なログ、キャッシュ、試作品、古いPDF、重複画像を先にどける。ファイル整理でこれを怠ると、消してはいけないものまで候補に見える。人間もAIも、散らかった場所では判断を誤る。
作業前の下ごしらえは、派手ではない。だが、ここを飛ばすと後工程が全部重くなる。
ブランチを切る前に整理する、というのは、要するに「変更を小さく始める準備」を先に済ませることだ。これはコードでも文書でも変わらない。
整理済みの状態で使うと、Claude Code はかなり扱いやすい。
対象が狭く、余計なファイルがなく、やることが一文で言える。こうなると、指示の往復が減る。提案も読みやすいし、修正の責任範囲も明確だ。
実務で効くのは、派手な自動化より、この地味な段取りだ。
ブランチを切る前に、差分を分ける。不要物を退避する。作業範囲を一行で言う。これで十分強い。
もし次にもう一歩進めるなら、「整理専用の依頼」を最初に挟むといい。
たとえば、いきなり修正を頼む代わりに、こう始める。
これから新しい作業ブランチに入る前提で、今の状態を整理したい。
対象を狭く切り出し、今回の作業に不要なファイルや差分があれば先に指摘して。
そのあと、最小の作業単位に分けて提案してほしい。
この一段を入れるだけで、作業が雑に広がるのをかなり防げる。
次に詰まりやすいのは、整理したつもりでまだ文脈が広いまま始めることだ。そこを越えたければ、「何をしないか」をもっとはっきり書くといい。ブランチ前の整理は、その練習台としてちょうどいい。