コンフリクトが多い人のやりがちな勘違いは、「Claude Code が賢ければ、同じ場所を複数の作業で触っても勝手にうまくやるはず」だ。そこ、かなり危ない。
実際は、同じファイルを同時に触らせないだけで、競合を避ける、同時編集を避ける、という基本がかなり効く。しかもこれは開発だけの話ではない。文書整理でも、請求書まわりでも、写真の整理でも、ひとつのファイルを別タスクが横取りしないだけで手戻りが目に見えて減る。
筆者も最初は、要約、修正、整形を雑に並列で投げて、最後に diff がぐちゃぐちゃになったことがある。内容は合っているのに、改行だけで戦っているような差分が増える。地味にだるい。Claude Code は便利だが、同じ物を同時に触らせると、賢さより衝突回避の設計がものを言う。
やることは単純だ。タスクをファイル単位、できればディレクトリ単位で分ける。Claude Code に渡す指示も、「この範囲だけ触れ」と明示する。そうすると、出力の見通しがよくなり、あとで人間が確認するときの負担も下がる。
たとえば、リポジトリ内の複数ファイルをいじるときは、こんなふうに分ける。
タスクA: src/api/ 配下だけを修正する
タスクB: docs/ 配下だけを整える
タスクC: tests/ 配下だけを更新する
どのタスクも、他の範囲のファイルは触らないこと。
この書き方のいいところは、Claude Code に「自由に直していい範囲」を先に渡せる点だ。自由に見える範囲が広すぎると、余計なファイルまで巻き込む。巻き込まれると、変更理由がぼやける。あとで見返したときに「なんでここまで直したんだっけ」となる。あれが一番面倒だ。
非エンジニアの使い方でも同じだ。たとえば書類整理なら、ひとつの案件フォルダを複数の目的で同時にいじらない。
「請求書の名前をそろえる」「重複ファイルを洗う」「提出用PDFだけをまとめる」を、同じフォルダに対して一気にやると散らかる。先にフォルダを分ける。作業の入口で分けるのがコツだ。
このフォルダでは「ファイル名の整理」だけを行ってください。
中身の編集、移動、削除はしないでください。
別の作業が必要なら、対象ファイルを列挙してから止まってください。
この一文があるだけで、事故率はかなり下がる。Claude Code は指示された範囲で動くのが得意だから、役割を狭く切ったほうが安定する。
もうひとつ効くのは、作業を「下ごしらえ」と「本処理」に分けることだ。先に対象をリストアップさせ、次にそのリストだけを処理させる。いきなり全部触らせると、どこを直したかの追跡がだるくなる。
まず、変更候補のファイルを列挙してください。
そのあとで、列挙したファイルだけを対象に、重複を減らす形で修正してください。
新しい対象を勝手に増やさないでください。
ここで大事なのは、「勝手に増やさないでください」をちゃんと書くことだ。Claude Code は気を利かせて周辺まで見に行くことがある。見に行くのは悪くないが、複数タスクを並走させていると、その親切がかえってぶつかる。だから入口で止める。
筆者が一度やらかしたのは、同じ設計書を「表記ゆれ修正」と「章立て整理」で別々に触らせたときだ。片方は見出しを動かし、もう片方は文言を直した。結果、どちらも正しいのに、最終版では差分の突き合わせに時間を食った。先に表記ゆれを終えてから章立てを直せばよかっただけだ。順番を守るだけで済む話だった。
順番を決めるときは、こう考えるとよい。
内容を変える作業と、見た目を整える作業を同時に走らせない。
文章の中身を編集している最中に、Claude Code に整形までやらせると、どの変更が本筋なのか見えなくなる。これはコードでも文書でも同じだ。
1. 内容の修正だけを行う
2. その差分を確認する
3. 最後に整形だけを行う
各段階で、次の段階の作業はしないこと。
この「段階を切る」やり方は、ファイルを同時に触らせないのと相性がいい。別のタスクが同じファイルに寄ってくる前に、一区切りをつけるからだ。
ただし、分ければ何でも安全、という話でもない。対象ファイルを狭くしすぎると、今度は周辺との整合性が崩れる。たとえば関数名だけ変えて、呼び出し元を見ないまま止めると、あとで不整合が出る。文書なら、見出しだけ変えて本文の参照を残すと崩れる。だから「触る範囲を狭くする」と「必要な参照先は見る」を両立させる必要がある。
このファイルだけを変更してください。
ただし、参照している箇所があるなら、その箇所は確認して整合性を保ってください。
変更対象以外のファイルは、修正しないでください。
この書き方なら、同時編集を避けつつ、必要な確認は残せる。雑に全部禁止すると、かえって壊れる。ここは切り分けが肝心だ。
ファイル単位で衝突を減らしたいなら、タスク名も分けるといい。人間側の整理だが、かなり効く。
「README整備」と「サンプルコード修正」を同じ依頼に混ぜない。
「請求書整理」と「契約書の要約」を一回でやらせない。
同じフォルダでも、別目的の指示を混ぜると、Claude Code の中でも優先順位がぶれる。ぶれた分だけ、差分が増える。
最後にひとつだけ、地味だが効く運用を置いておく。複数の作業を進めるなら、先に「この作業中は触らないファイル」を決めておくことだ。人間の手作業でも、Claude Code でも、同じファイルを同時に触る場面が減れば、コンフリクトは目に見えて減る。派手な魔法ではない。だが、実務ではこういう地味な制御がいちばん強い。
細かい挙動は、Claude Code の公式ドキュメントも合わせて見ておくと安心だ。特に、どの範囲をどう渡すか、どこで止めるかは、作業の癖が出やすい。雑に広げず、狭く切って、順番に片づける。それだけでかなり違う。