Claude Code 並行作業の落とし穴｜複数セッションで起きた4つの衝突と止め方

Claude Codeに慣れてくると、1つの作業が終わるのを待つのがもったいなくなります。記事を書かせている間に別の画面で資料を作らせ、夜は定時のタスクに任せる。人を増やさずに手を増やせるのが、AIに仕事を任せるいちばんの魅力です。

ところが、同時に動かす数を増やすと、1本ずつなら起きなかった壊れ方が出てきます。それぞれの作業は正しく終わっているのに、結果として変更が消えたり、書きかけのものが外に出たりする。しかもエラーが出ないことが多く、気づくのが遅れます。

当社は営業・マーケの定型業務をClaude Codeで運用していて、定時タスク84本と、代表が対話しながら進める作業が、同じフォルダで並行して動いています。この記事は、その運用で実際にぶつかった4つの衝突と、並行させる前に決めておくべきことの記録です。

この記事の要点

• 並行作業でぶつかる場所はファイル・台帳・画面・プロセスの4つ。コードの衝突はその1つにすぎない
• いちばん多いのは「終わった作業が、隣の作業の書きかけまで確定させる」事故。当社では書きかけの記事が図解なしで本番に出た
• 共有の台帳ファイルは「後から保存した方が勝つ」。書き手が9本ある台帳を、ロック＋差分マージに切り替えた
• 2026年10月18日、31本が同じ1分に起動して13本が失敗。うち7本は、別の作業が出した1行の停止命令の巻き添えだった
• worktree（作業フォルダの分離）はファイルの衝突には効くが、台帳・ブラウザ・外部アカウントは分けてくれない

Claude Code 並行作業でぶつかる4つの場所

結論：並行作業の衝突は、Gitの衝突だけではありません。 当社で実際に起きたものを分類すると、次の4つになります。

共通しているのは、1本ずつ見るとどれも正常に動いていることです。並行で起きる事故は、作業の中ではなく作業と作業の「間」で起きます。だから、それぞれの手順書をどれだけ丁寧に書いても防げません。

当社の並行の実態｜定時タスク84本と対話が同じフォルダで動く

当社は、作業フォルダを分けずに並行させています。 毎時の顧客データの取り込み、施策の台帳更新、記事の公開、SNSの予約といった定時タスクが84本登録されていて、その合間に代表が対話でClaude Codeに作業を頼みます。

この規模になると、「たまたま重なる」は毎日起きます。変更を自動でGitに残す仕組みの記録（2026年9月14日〜11月7日）では、次のようになっていました。

最後の1,480回は、誰かが編集している途中かもしれないと判断して、コミットを次回に送った回数です。並行で動かすと、これだけの頻度で「他の作業の途中」に出くわします。

衝突1：コミットが隣の作業を巻き込む｜書きかけの記事が本番に出た

最初に起きたのは、2026年8月10日です。 別の作業が最後に「残っている変更を全部コミットする」命令を使ったところ、同じフォルダで書きかけだったこのメディアの記事まで一緒にコミットされ、そのまま公開されました。図解の画像はまだ作っていなかったので、画像が壊れた状態で本番に出ています。

当社のサイトは、コミットしてGitHubに送るとそのまま本番に反映される作りです。つまり、隣の作業の「全部コミット」は、そのまま「隣の書きかけを公開」になります。

直し方は2段でした。

1. 「書く場所」と「出す場所」を分けた。 書き上げた記事はまず公開されない待機フォルダに置き、公開は記事公開のタスクだけが行う
2. 「全部コミット」を禁止した。 自分が触ったファイルだけを名前で指定してコミットする。作業の終わりに機械でコミットする仕組みも、「その作業が編集したファイルはすぐ」「それ以外は5分以上触られていないものだけ」に分けた

2つ目の仕組みの作り方はClaude Codeのフック（hooks）の使い方｜2つの実例と落とし穴に書いています。ここで強調したいのは1つ目のほうです。機械で防ぐ前に、「書きかけが置かれる場所」と「外に出る場所」を物理的に分ける。これだけで、事故が起きても外には出なくなります。

衝突2：台帳ファイルは「後から保存した方が勝つ」

Gitより気づきにくいのが、共有の台帳ファイルです。 当社は商談の一覧や施策の一覧を1つのデータファイルで管理していて、書き換える処理が9本ありました。

それぞれの処理は「ファイルを読む→自分の担当部分を書き換える→ファイルごと保存する」という動きです。2本が少しずれて同時に動くと、こうなります。

1. Aが読む
2. Bが読む
3. Aが商談1件の次の打ち手を書き足して保存
4. Bが別の商談の状態を更新して保存（Bが読んだのはAが書き足す前の版）

4の時点で、Aの書き足しは跡形もなく消えます。 どちらの処理も「保存成功」で終わるので、エラーはどこにも出ません。後から台帳を見て「書いたはずのものが無い」で初めて気づく種類の失敗です。

2026年9月14日に、台帳の読み書きを1つの部品にまとめ、保存の前にロックを取る・読んだ後に他の処理が更新していたら差分だけ混ぜる形に切り替えました。導入前の試験では、8つの処理から25回ずつ同時に書き込ませて、消えた更新は0件でした。

運用後の記録では、「読み込んだ後に他の処理が更新していたので混ぜた」が6回ありました。うち1回は、2つの処理が同じ項目を同時に書き換えていて、後から保存した側を採用しています。6回とも、切り替える前なら片方の更新が黙って消えていた場面です。

一方で、限界も記録に残っています。10月22日には、ロック待ちが60秒を超えてロックなしで書き込んだことが3回ありました。待ち続けて処理全体が止まるよりはましという判断で入れた逃げ道ですが、この3回は守れていません。完全ではないことを前提に、記録を残して後から確かめる作りにしています。

衝突3と4：31本の同時起動と、1行の停止命令で7本が落ちた日

2026年10月18日、ノートパソコンの電池が0時すぎに切れ、朝9時すぎに電源をつないだ瞬間、寝ている間に予定されていた31本の定時タスクが同じ1分に起動しました。

結果は、途中で落ちた8本・目的を達成できなかった4本・時間切れ1本の計13本。原因は2つ重なっていました。

1つ目は、画面とCPUの取り合いです。31本のうち多くがブラウザを使う作業で、同じブラウザを同時に操作しようとして、準備の段階で20分固まったものもありました。

2つ目のほうが深刻でした。ある作業が、固まった補助プログラムを止めるために「この名前を含むプロセスを全部止める」命令を実行しました。当時、当社の定時タスクは指示文をそのまま起動時の引数に載せていたため、指示文の中にその名前が書かれていた別の7本まで「該当する」と判定されて止められたのです。止めた側の作業から見れば、自分の補助プログラムを止めただけでした。

直したことは4つです。

1. 同時に動く数に上限を付けた。 遅れて起動する作業は全体で4本まで、ブラウザを使う作業は常に3本まで。超えた分は順番待ちにし、待っている間はAIを起動しない
2. 指示文を起動時の引数に載せないようにした。 名前で検索されても、指示文の中身では引っかからない
3. 「名前を含むものを全部止める」命令を機械で止めた。 止めてよいのは自分が起動したものだけで、番号を確かめてから個別に止める
4. 電源が落ちていた間の失敗は、故障として扱わない。 1日1通の通知にまとめ、本当に壊れていれば翌日の定刻で分かる

ここから学んだのは、並行させる数は「CPUが持つか」ではなく「共有しているものの数」で決めるということです。ブラウザが1つしかないなら、ブラウザを使う作業はいくら並べても実質1本ずつしか進みません。

反論：「worktreeで作業フォルダを分ければ、全部解決では？」

正直に言うと、ファイルの衝突だけならworktreeでほぼ解決します。 worktreeは、同じGitの履歴から作業フォルダを複数作る仕組みで、Claude Codeの公式ドキュメントでも並行作業の方法として紹介されています（［Common workflows］https://docs.claude.com/en/docs/claude-code/common-workflows ）。セッションごとにフォルダが分かれるので、隣の書きかけを巻き込むことは起きません。

ただ、当社の4つの衝突のうち、worktreeで消えるのは1つ目だけです。

当社も9月の時点で古いworktreeが5つ残っていましたが、業務の台帳は毎時の取り込みが書き込む1か所に集める必要があるため、整理して1つのフォルダに戻しています。コードを書く作業ならworktree、業務データと外部のアカウントを触る作業なら1つのフォルダで書き方のルールを揃える。並行させている作業の中身で選ぶのがよいと考えています。

Claude Codeを並行させる前に決める4つ

並行させる数を増やす前に、次の4つを決めておけば、当社が踏んだ事故の大半は避けられます。

1. 書きかけの置き場所と、外に出る場所を分ける。 公開・送信・投稿につながる場所には、確定したものだけを置く
2. 共有の台帳は、書き方を1つにする。 各作業がそれぞれ読んで丸ごと保存するのをやめ、ロックと差分の取り込みを持った1つの部品を通す
3. 同時に動かす数は、共有しているもので決める。 ブラウザ・ログイン中のアカウント・外部サービスの利用枠が1つなら、それを使う作業は順番待ちにする
4. 止めてよいのは、自分が起動したものだけ。 名前で一括に止める命令は使わない。番号を確かめて個別に止める

この4つは、営業組織で人を増やすときに決めることと同じです。誰がどこに下書きを置くか、顧客台帳を誰がどう更新するか、同じ顧客に2人で電話しないか。AIの手を増やすときも、手の数より先に、共有物の扱いを決めるのが順番です。並行で浮いた時間が事故の後始末に消えないようにすることが、結局いちばん商談や顧客対応に時間を残します。

定時タスクの設計そのものはClaude Codeのスケジュール実行｜毎朝の定型作業を無人で実行する設計に、事故を機械で止める考え方はClaude Codeは危険か｜実際に起きた4つの事故と、機械で止める設計にまとめています。

よくある質問

Q. Claude Codeは複数のセッションを同時に動かせますか？

動かせます。ターミナルを複数開く、デスクトップアプリで複数の会話を開く、定時実行と対話を併用する、などの方法があります。ただし、同じフォルダ・同じ台帳・同じブラウザを共有している場合は、作業同士がぶつかる前提で、書き込み方と同時に動かす数を先に決めてください。

Q. 複数セッションで同じファイルを編集するとどうなりますか？

後から保存した側の内容が残り、先に保存した側の変更は消えます。どちらの作業もエラーにはならないので、気づくのは後から内容を確かめたときです。共有するデータファイルは、ロックを取ってから書き、読んだ後に他の作業が更新していれば差分だけを取り込む形にするのが安全です。

Q. worktreeを使えば並行作業の衝突はなくなりますか？

ファイル（Git）の衝突はほぼなくなります。ただし、共有の台帳、ブラウザやログイン中のアカウント、同じパソコン上のプロセスは分かれないので、そちらの衝突は残ります。コードを書く作業はworktree、業務データや外部アカウントを触る作業は1つのフォルダでルールを揃える、と使い分けるのがおすすめです。

Q. 同時に何本まで動かしてよいですか？

決め手はパソコンの性能より、共有しているものの数です。当社はブラウザを使う作業を常に3本まで、遅れて起動する作業を全体で4本までにしています。ブラウザや外部サービスの利用枠が1つしかない作業は、何本並べても実質1本ずつしか進まないので、順番待ちにしたほうが失敗が減ります。

Q. 並行作業の事故に早く気づくにはどうすればいいですか？

「失敗した」だけでなく「見送った」「混ぜた」「待ちすぎて飛ばした」も記録に残し、週に1回それだけを数えることです。並行の事故はエラーにならないことが多く、記録を数えに行かないと見つかりません。当社の台帳の差分取り込み6回も、ロックなしの書き込み3回も、記録を見て初めて分かったものです。

---

執筆・監修：佐々木 優希（AIリモートワーカー代表／上場企業 営業統括 兼 AI責任者）

自社の営業・マーケ業務をClaude Codeで運用しており、本記事の本数・回数・日付はすべて自社の運用記録（自動コミットの記録ファイル・台帳の取り込み記録・定時タスクの登録一覧と実行記録）に基づいています。