同じファイルを何人にも同時編集させて、あとでコンフリクト地獄に落ちる。これ、かなりありがちな失敗だ。Claude Code を使うときも同じで、便利だからこそ雑に並列化すると、差分が膨らみ、直す側がだるくなる。
競合回避、同時編集、衝突防止。この手の話は、結局「同じファイルに手を入れる人数を絞る」に尽きる。Claude Code に仕事を振るなら、最初からファイルの担当範囲を切っておくほうが早い。あとで diff を追いかけるより、最初の分け方に少し気を遣ったほうが、全体の時間は確実に減る。
筆者も最初は、複数のタスクを雑に並べて投げていた。結果、同じ README と設定ファイルを別々の指示でいじらせて、手戻りした。Claude Code 自体が悪いわけではない。指示の切り方が雑だと、当然こうなる。
Claude Code に頼むときは、タスクの粒度を「機能」ではなく「触るファイル」で考えると事故が減る。たとえば、ドキュメント整理なら「このフォルダ配下の Markdown だけ」「不要ファイルの洗い出しだけ」と切る。コード修正なら「このモジュールだけ」「この設定ファイルは触らない」と明示する。
たとえば、こういう頼み方が効く。
この作業では docs/ 配下の Markdown ファイルだけを扱ってください。
README.md は触らないでください。
内容の重複を整理し、見出しの順序を整えてください。
変更前に、どのファイルを触るつもりか先に列挙してください。
これだけで、勝手に別ファイルへ広がるのをかなり抑えられる。Claude Code は指示された範囲でかなり素直に動くが、範囲が曖昧だと、整理のつもりで別の関連ファイルまで手を伸ばしがちだ。そこが地味に危ない。
ファイル整理やディスク削減の用途でも同じだ。たとえば不要ファイルの候補を洗い出すなら、削除対象と報告対象を分ける。
/tmp の中身を確認して、削除候補を列挙してください。
実際の削除はしないでください。
まずはファイル名、サイズ、最後に更新された日付を一覧にしてください。
いきなり消させない。まず見せる。これで衝突防止になる。人間の確認を挟めば、同じファイルを別の作業が触っていた、という事故も減る。
並列に回したい気持ちはわかる。だが、並列化していいのは、ファイルがちゃんと分かれているときだけだ。そうでないなら、順番待ちにしたほうがいい。
たとえば、文書作成で「本文」「要約」「見出し案」を別々に作らせるのはやりやすい。逆に、本文の修正と見出しの修正を別タスクで同時に走らせると、同じファイルをまたぐので、あとで整合が崩れやすい。Claude Code に渡す前に、どのファイルを誰が触るかを決めておくといい。
実務では、こんな分け方が効く。
この分け方なら、同じファイルを同時に触らせないまま進められる。
開発なら、もっと露骨に切る。たとえば「UI の文言修正」と「API のロジック修正」を同時にさせない。見た目と中身が混ざると、差分が読みにくくなるからだ。筆者はここで欲張って、設定ファイルと実装ファイルを別タスクに割り振り、最後に import まわりで混線したことがある。仕事が増えただけだった。
Claude Code は、最初のひと言が曖昧だと広く動く。だから、依頼文の先頭で「触っていいもの」と「触らないもの」を先に固定するのが効く。
この作業では以下だけを変更してください。
- src/parser.ts
- src/utils/date.ts
それ以外のファイルは変更しないでください。
必要なら、変更案だけ先に出してください。
非エンジニア向けの作業でも同じだ。たとえば契約書や提案書のフォルダ整理で、特定の案件フォルダだけを扱わせたいなら、明確に書く。
案件A フォルダの中だけを整理してください。
案件B フォルダには触らないでください。
重複している PDF があれば候補として挙げてください。
削除はまだしないでください。
この「先に範囲を書く」だけで、同時編集の事故はかなり減る。Claude Code に限らず、誰かに仕事を振るときの基本だが、CLI だとつい省きやすい。省くと痛い目を見る。
いきなり修正に入らせない。どのファイルに手を入れるつもりか、先に一覧を出させる。これで、同じファイルを別タスクが触っていないか確認できる。
修正に入る前に、変更予定のファイルを列挙してください。
そのうえで、今回の作業がどのファイルに集中するかを説明してください。
変更範囲が広がりそうなら、そこで止まって確認を取ってください。
このやり方は地味だが強い。とくに、複数の Claude Code セッションを開いているときに効く。片方が README を直し、もう片方も README を直し始める、みたいな事故は、最初に止めれば避けられる。
筆者は以前、ドキュメント整理を並列で進めたとき、片方が目次を整え、もう片方が本文の見出しをいじって、最後にリンク切れが出た。どちらも「正しい」修正だったのに、同時編集のせいで面倒になった。ここで必要なのは器用さじゃなく、順番だ。
同じファイルを長時間握らせるほど、コンフリクトは増える。だから、1 回の依頼で終わる単位に切るのがいい。大きなファイルをずっと触るより、短く区切って、確認しながら進める。
たとえば、長文の編集ならこう分ける。
まずは第1章だけを整えてください。
第2章以降は触らないでください。
変更点を出したら止まってください。
そのあとに次の章へ進める。こうすると、修正のたびに全体が揺れるのを防げる。ディスク削減の作業でも、全フォルダを一気に動かすより、1 フォルダずつ確認したほうが安全だ。まとめてやると、あとで何を消したのか追えなくなる。
もし作業を並行したいなら、同じファイルを触らせるのではなく、別の成果物に分岐させる。たとえば、片方は下書き、もう片方はレビュー案。片方はコード、もう片方は変更理由のメモ。ファイルが分かれていれば、コンフリクトは起きにくい。
Claude Code にこう頼むと整理しやすい。
本文の修正案は article-draft.md にだけ出してください。
見出し案は headig-notes.md に別で出してください。
既存の本文ファイルは直接編集しないでください。
もちろん、最後に人間が統合する必要はある。だが、統合先をひとつに絞れるだけで、ずいぶん楽になる。雑に同じ場所へ同時投入するより、はるかにマシだ。
最後に大事なことを言うと、Claude Code は「同時にたくさん動かすほど速い道具」ではない。むしろ、担当範囲を絞って、同じファイルを同時に触らせないほうが速い。見た目の並列より、衝突の少なさのほうが効く。ここを外すと、作業は増えるし、差分は読みにくいし、地味に疲れる。