「差分が悪い」のではない。たいていは、同じ場所を同時に触らせた運用が雑だ。
Claude Code でコンフリクトを減らしたいなら、まずやることは派手な自動化ではない。同じファイルを同時に触らせない。これだけでかなり効く。別名でいうなら、コンフリクトの芽を摘む、あるいは編集箇所の分離だ。
筆者も最初は、1 つの大きい指示にまとめて投げていた。すると Claude Code はちゃんと仕事をするのに、最後に差分を合わせる段階で疲れる。README、設定ファイル、サンプル、文書本文を一気にいじると、修正の意図は合っていても、競合の処理だけで手戻りが出る。そこで分けた。すると、見た目は地味だが、衝突は目に見えて減った。
要は、Claude Code に「何を直すか」だけでなく、「何を同時に直さないか」まで渡すのがコツだ。
この話は開発だけでなく、ファイル整理や文書作成にもそのまま使える。たとえば案件ごとのフォルダを分けて書面を作る、原稿本文と参考資料を切り分ける、不要ファイルを掃除するときに対象を一塊にしない。そういう地味な分離が、あとで効いてくる。
まず、Claude Code に投げる前に、編集の単位を切る。
「この作業で触るファイルはこれだけ」と先に決めるのが先だ。人間なら当然だと思うかもしれないが、雑に「この機能を直して」と丸投げすると、Claude Code は広めに見に行く。広く見れば見落としは減るが、編集範囲まで広がるとコンフリクトの床になる。
たとえば、設定の修正、説明文の修正、サンプルコードの修正を同時にやらせない。順番に分ける。
こういう感じで指示する。
まず docs/usage.md だけを直して。
本文の説明を整理して、手順の順番だけ見直してほしい。
コード例や設定ファイルは触らないで。
次に、別の依頼でコード側を直す。
次に src/config.ts だけを直して。
README は触らないで。
設定の既定値を調整したい。
この切り方は、Claude Code が賢くないから必要なのではない。逆だ。賢いからこそ、広い文脈を持って動く。広い文脈は役に立つが、編集先まで広げると衝突しやすい。
「説明を直す回」と「実装を直す回」を分けるだけで、レビューも diff も読みやすくなる。差分が小さくなるので、どこで何を変えたかが追いやすい。後から見返したときに、仕事がきれいだ。
非エンジニア向けの使い方でも同じだ。
たとえば、フォルダ内の文書を整えるなら、「ファイル名の整理」「本文の要約」「重複の除去」を一度にやらせない。まず名前だけ、次に本文だけ、最後に重複チェックだけ。混ぜると、どこで内容が変わったのか見失う。文書作成でも、契約書の体裁修正と本文の加筆を同時にやると、あとで確認が面倒になる。分けておけば、事故が起きても範囲が狭い。
実際の頼み方は、こんな書き方がしっくりくる。
この作業は編集箇所を分離して進めてください。
1. まず README.md だけを更新する
- 使い方の説明をわかりやすくする
- コードブロックは変更しない
2. 次に src/main.ts だけを更新する
- README.md には触れない
- 既存の公開 API は変えない
3. 最後に差分を見て、同じ内容を別ファイルに二重で書いていないか確認する
この「最後に差分を見て」という一言も大事だ。分けただけで終わると、今度は内容の食い違いが残る。README と実装の説明がズレる、設定例が本体と違う、文書の版が合わない。そこは Claude Code に検査させればいい。分離したうえで整合性を見る。この順番が崩れると、ただ仕事を遅くするだけになる。
つまずきやすいのは、「分けたつもり」になっていることだ。
実はこれがいちばん多い。ファイルを分けた気になっていても、同じ関数、同じ段落、同じ見出しを別の依頼でいじっていれば、結局は同じ場所を触っている。名称が違うだけで、中身の争点は同じだ。
筆者は一度、設定ファイルの整理と説明文の更新を同時に頼んで、あとでかなり面倒を見たことがある。設定名を変えたのに、説明文側に古い名前が残った。Claude Code は嘘をついたわけではない。依頼が悪くて、片方だけが先に進んだだけだ。こういう手戻りは、機能の大きさより依頼の切り方で起きる。
だから、同じファイルだけでなく、同じ意味の変更も分ける。たとえば次の組み合わせは危ない。
こういうときは、順番を切る。まず名前を変える、そのあと説明を合わせる。まず移動する、そのあと参照先を直す。ひと呼吸置くのがだるいように見えて、結局は早い。コンフリクトはもちろん、理解コストも減る。
Claude Code への指示でも、ここははっきり書いていい。
今回は名前の変更だけに絞ってください。
動作の変更はしないでください。
参照箇所の更新まで終えたら、そこで止めてください。
この「止めてください」は効く。
勝手に先回りして、関連ファイルまで広げるのを防げる。広げないこと自体が、実はかなり強い制御だ。
もう一段うまくやるなら、作業前に置き場を分ける。
Claude Code に大きく触らせる前に、作業用ディレクトリやブランチを切るのは王道だが、地味に効く。複数人で触るならなおさらだ。誰かが同じファイルを編集している状態で AI にも触らせると、差分の衝突は増える。これはツールの問題ではない。単純に、同じ机を同時に使っているから散らかる。
非エンジニアの文書仕事でも同じ発想でいい。
案件ごと、版ごと、用途ごとにフォルダを分ける。たとえば「提出用」「下書き」「参考資料」を混ぜない。Claude Code に資料整理を任せるなら、まずは提出用だけを整える。そのあとで参考資料を要約する。全部を同じ箱に入れると、要らないものまで触る。結果として、どこが変わったか分からなくなる。
実務では、こんなふうに頼むと扱いやすい。
作業対象をこのフォルダだけに限定してください。
./drafts/project-a/
この外にあるファイルは参照だけで、編集はしないでください。
そして、作業の最後に確認する。
変更したファイル一覧を出して。
同じ内容の修正が複数ファイルに重複していないか確認して。
ここで大事なのは、Claude Code に「全部まとめて」ではなく、「範囲を絞って、最後に見直す」という流れを固定することだ。これを毎回やると、編集箇所の分離が癖になる。癖になると強い。コンフリクトは、かなりの割合で未然に止められる。
最後に、覚えておくといい線引きがある。
分離は、仕事を細切れにするためではない。衝突しやすい要素を同時に動かさないためにやる。だから、何でも分ければいいわけではない。分けすぎると、逆に全体像が見えなくなる。そこはバランスだ。
目安は単純で、同じファイル、同じ意味、同じ確認ポイントを一度に増やしすぎないこと。
Claude Code は広く見てくれるが、広く見ている最中に同じ場所を何度も触らせると、差分は汚れる。なら最初から同時に触らせない。これがいちばん手堅い。派手な裏技ではないが、毎回効く。コンフリクトを減らしたいなら、まずここから始めればいい。