Claude Codeの並行作業のやり方｜変更が混ざる事故3回で決めたgit worktreeと3つのGitルール
Claude Codeに任せる仕事が増えてくると、次に欲しくなるのは複数の仕事を同時に走らせる体制——いわゆる並行作業（並行処理・並行実行）です。ところが同じ作業フォルダでセッションを2つ開くと、別の作業の変更が自分のコミットに混ざる、気づいたらブランチが切り替わっている、という事故が起きます。みやっち🧑💻の環境でも実際に3回、巻き込み事故が起きました。結論から書くと、並行作業の答えはブランチではなくgit worktree、そして同じフォルダを触るときの3つのGitルールです。
Claude Codeの並行作業のやり方: 同じ作業フォルダで複数のClaude Codeセッションを同時に動かすときは、git worktreeで作業フォルダをもう一式別の場所に展開し、セッションごとに別のフォルダを担当させます。ブランチの切り替えは同じフォルダの中身を差し替える仕組みのため、作業場所を分けたことにはなりません。
前提は、仕事のファイルをGit・GitHubで管理していることです。まだの方は、ファイル置き場をGitに一本化した実録「AI時代のファイル管理」から読むのがおすすめです。Gitの基本はこの記事では繰り返しません。
並行作業で実際に何が起きたか — ブランチの切り替えに他のセッションが巻き込まれた
みやっち🧑💻の環境では、同じ作業フォルダを複数のClaude Codeセッションが触るのが日常です。人と対話しながら進めるセッションの横で、自動の定期実行も回っています。あるとき、Codex（Claude Codeとの違いはこちら）に任せたタスクの途中で、エージェントがブランチを切り替えて作業を始めました。ブランチが変わると、同じフォルダを見ている他のセッションから見える世界も一緒に変わります。お互いの動きが見えなくなり、かなりややこしい状態になりました。
実害が出たのは定期実行です。パソコン上で動かす定期実行は、いまローカルにある作業フォルダをそのまま参照して回ります。つまりブランチが切り替わったままだと、毎朝のルーティンが切り替わった先のブランチに対して回ってしまう。本来と違う内容を前提に、自動処理が走ってしまうわけです。
なぜブランチを切っても解決しないのか
ブランチは並行作業の道具に見えますが、実態は「同じ机の上で、台帳だけを差し替える」仕組みです。机＝作業フォルダは1つのまま。誰かが台帳をめくれば、同じ机に着いている全員の目の前が変わります。セッションを2つ開いてブランチを2本用意しても、触っているフォルダが同じなら、作業場所は分かれていません。
よく考えたらブランチを切ったとしても、結局同じフォルダを触っているんですよね——事故のあとにみやっち🧑💻がたどり着いたのは、この単純な事実でした。必要なのは台帳の差し替えではなく、机そのものを増やすこと。それがgit worktreeです。
git worktreeとは — 机（作業フォルダ）をもう1つ用意する
git worktreeは、Gitに標準で備わっている機能で、作業フォルダをまるっともう一式、別の場所に展開するものです。仕様の正確なところはGit公式ドキュメントにありますが、押さえておく点は4つだけです。
git worktree add <置き場所>を実行すると、指定した場所に新しい作業フォルダが作られます。フォルダ名と同じ名前の新しいブランチも自動で作られ、そのフォルダで開かれます（同名のブランチが既にあれば、他のフォルダで開かれていない限り、それが開かれます）- 新しいフォルダは元のリポジトリと変更履歴を共有します。リポジトリのコピーではないので、正本が2つに分岐する心配はありません
- どのブランチを開いているかは、フォルダごとに別々に記録されます。片方のフォルダでブランチが切り替わっても、もう片方の世界は変わりません
- 同じブランチを2つのフォルダで同時に開こうとすると、標準では拒否されます。変更が混ざる事故を防ぐ安全装置です
使い方も最小限で足ります。ターミナル（CLI）で使うのは、実質2つのコマンドだけです。
git worktree add ../mysite-kijiのように実行する——隣に作業フォルダがもう1つでき、2つ目の机が使える状態になる- 新しいフォルダで2つ目のClaude Codeセッションを開き、仕事を任せる
- 変更の合流（マージ）が済んだら、
git worktree remove ../mysite-kijiで片付ける
なお、未コミットの変更や新規ファイルが残った机は git worktree remove が拒否します。片付けの操作で作業中の変更を失わないよう、ここにもGit側の安全装置が入っています。
コマンドを覚えてから始める必要はありません。「worktreeで作業フォルダを分けて、この作業はそっちで進めて」とClaude Codeに日本語で頼めば、作成から片付けまで任せられます。詰まった箇所だけその場で仕組みを質問して、必要な分だけ理解すれば十分です。
Claude Code自体にも、この仕組みは組み込まれています。デスクトップアプリでは新しいセッションごとに自動でworktreeが用意され、定期実行にも作成時に「worktreeで実行する」設定があります。机を分けるという考え方を知っていれば、こうした設定の意味も読めるようになります。
使いどころの目安は、他のセッションと作業が同じ時間帯に重なるかどうかです。数分で終わる小さな修正のたびに机を増やす必要はありません。長く走る作業を任せるとき、ブランチの切り替えを伴う作業を任せるとき、定期実行が参照するフォルダに影響させたくないとき——そこがworktreeの出番です。
それでも同じフォルダを触る場面のために — 事故3回から決めた3つのGitルール
worktreeで机を分けても、同じフォルダを複数のセッションが触る場面はゼロになりません。みやっち🧑💻の環境で実際に起きた巻き込み事故と、そこから明文化したルールがこの3つです。
- git addは、自分が触ったファイルだけを名指しで指定する。「まとめて全部」の指定（
git add -Aなど）を使っていたところ、並行セッションが作業中だったブログの変更まで、別の作業のコミットに同梱されました（事故1・2026年6月） - コミットの直前に
git diff --cached --statで、何をコミットしようとしているかを確認する。ファイルを名指しで追加していても、素のgit commitはコミット待ち一覧（ステージ）の全体をコミットします。並行セッションがコミット待ちに置いていた多数のファイル削除を、巻き込んだままpushしてしまいました（事故2・2026年7月） - 自分の変更だけをステージし、他セッションの変更は巻き込まない・消さない。逆のパターンもありました。並行セッションのコミットに、自分が準備していた別の3ファイルが相乗りしたのです（事故3・2026年7月）
3つとも、AIの精度の問題ではありません。複数の作業者が同じフォルダを共有すれば人間のチームでも起きる、Gitの仕組みの話です。だからこそ対策はルール化に尽きます。Claude Codeが毎回読む指示書（CLAUDE.md）に明文化しておけば、以後はセッション自身がこのルールを守って作業します。
この体制ができてから、みやっち🧑💻の仕事は「1人と1つのAIが順番に進める直列作業」ではなくなりました。毎朝の定期実行が回る横で、対話のセッションが別の仕事を進める。複数の仕事が同時に、しかも安全に進む状態です。最近の例では、講座の教材を一式書き上げたあと、その教材をもとに「月次ライブのスライド」と「会社サイトに載せるコラム10本」を同時並行で依頼しました。どちらも大仕事なので、夜に頼んで翌朝までに進めておいてもらう。並行して任せる仕事が大きくなるほど、作業場所の分け方とGitのルールが決まっていることが効いてきます。並行作業の設計はスピードの話であると同時に、自分が手を離しても仕事が流れる体制づくりの話でもあります。
よくある質問
git worktreeで作業フォルダを増やすと、二重管理になりませんか？
なりません。git worktreeで作った作業フォルダは、元のリポジトリと変更履歴を共有する「同じリポジトリの別の机」であり、コピーではありません。作業中のファイル一式はフォルダごとに展開されますが、合流（マージ）すれば1本の履歴にまとまり、git worktree remove で片付ければ元の1フォルダ体制に戻ります。
同じブランチを2つの作業フォルダで同時に開けますか？
標準では開けません。git worktreeは、あるブランチが別の作業フォルダですでに開かれている場合、同じブランチを重ねて開くことを拒否します。不便な制限に見えますが、同じブランチへの変更が2か所から入って混ざる事故を防ぐ安全装置です。
ブランチはもう使わなくてよいのですか？
いいえ、ブランチは引き続き使います。ブランチは変更の歴史を分岐・合流させる仕組み、git worktreeは「どの机でどのブランチを開くか」という場所の仕組みで、役割が違います。worktreeで新しい机を作るとブランチが1本開かれるとおり、2つは対立ではなく組み合わせて使うものです。
Codexで並行作業しても同じ事故は起きますか？
起きます。この記事の巻き込み事故はClaude Code固有の問題ではなく、複数の作業者が同じフォルダを触るというGit側の構造の話なので、git worktreeと3つのルールはCodexにもそのまま効きます。Claude CodeとCodexを組み合わせる役割分担は「Claude CodeとCodexの併用」で扱っています。
まとめ — 並行作業の悩みは、業務基盤を持てた人の悩み
振り返ると、「変更が混ざって困る」という悩みは、誰にでも生じるものではありません。仕事のファイルを自分のリポジトリで持ち、そこに複数のAIセッションが出入りする体制を作った人にだけ生じる、次の段階の悩みです。チャット画面の中だけでAIを使っている限り、この問題には出会いません。裏を返せば、並行作業でつまずいたのは、業務の基盤が自分の手元に育っている証拠です。
AI Crewでは、プログラミング未経験の経営者・個人事業主・士業の方が、Gitでのファイル管理・作業場所づくりからClaude Code・Codexによる業務の自動化までを一緒に進めています。まず無料セミナーでお会いしましょう。
