公開日 2026年8月25日・約14分で読めます

git worktreeでAI並列。1人で3人分の仕事を回す体制

git worktreeとは、1つのプロジェクトの資料一式を丸ごと積んだ「独立した机」を増やせるgitの機能です。AIに頼んだ仕事を1件ずつ待つのではなく、机を分けて複数のClaude Codeを同じ時間帯に走らせる。この記事では、僕が2026年6月から毎日回している作業環境の組み方を、机の分け方、並列に向く仕事の線引き、成果物の衝突を避ける運用ルールの順に解説します。

対象読者は、コマンドの解説ではなく「自分の仕事をどう並列にするか」を知りたい経営者・AI実践中級者です。コマンドは末尾の付録にまとめ、本文は「何が起きて、何が変わるか」に絞ります。

git worktreeとは。1人で3人分の仕事を回す「作業場の分け方」

同じ資料一式を積んだ、独立した机を増やす仕組み

git（ギット。ファイルの変更履歴を管理する定番の仕組み）では、通常1つのプロジェクトにつき作業フォルダは1つです。worktree（ワークツリー）は、その作業フォルダを、履歴を共有したまま複数に増やす機能です。

僕の言葉で言い換えると、worktreeとは「同じ資料一式を丸ごと積んだ、独立した机」を増やす仕組みです。机が2つあれば、片方でAIに文章を書かせている間に、もう片方で別のAIに調べ物をさせられる。机が物理的に分かれているので、片方の作業がもう片方の資料を書き換えることはありません。

「1人で3人分」は、この机を3つ同時に開いて回す体制の比喩です。効果測定値ではなく、朝に開く机の数の話だと思ってください。

僕が2026年6月から毎日回している形

僕はAIVESTという会社を経営しながら、X投稿の記事、このブログ、広告のリサーチをそれぞれ自分で組んだ仕組みで回していて、毎日AIに「書かせる」「直させる」「調べさせる」仕事が出ます。2026年6月から、この3種類を別々の机に分けて複数のClaude Codeを同じ時間帯に走らせる形に切り替えました。以下は、その実運用で固まった机の分け方と運用ルールです。

AIを1体ずつ順番に使うと、なぜ午前が溶けるのか

1画面運用は、構造として直列

AIに1つ頼む。返ってくるのを待つ。返ってきたら次を頼む。この使い方が遅いのはAIの性能のせいではなく、人間の判断時間とAIの実行時間が、同じ1本のレールに乗っているからです。AIが走れば人が止まり、人が考えればAIが止まる。

しかも1つの作業フォルダでは、同時に開ける作業の枝は1つだけです。「Aを書かせながらBを直させる」をやろうとした瞬間に切り替えが始まり、途中の状態とAIの文脈が交互に壊れていく。1画面運用の損は待ち時間そのものではなく、並列にできる仕事を、環境の構造が直列に強制していることです。

道具の解説ばかりで、自分の仕事への当てはめを誰も教えない

git worktreeで検索して上位に出るのは、コマンドの解説です。正確ではあるのですが、読んでも「自分の仕事のどれを、どの机に分ければいいのか」は分かりません。必要なのはコマンドの知識ではなく、仕事の切り方と作業環境の組み方です。次の章から、そこを順に置いていきます。

git worktreeで作業場を分けると何が変わるか

ブランチ切替・stash・別cloneとの違い

「git worktree branch 違い」と調べる人が多いので、経営者の言葉で整理します。gitで複数の作業を扱う方法は4つあり、「机が何個あるか」「資料の元が共有されるか」の2軸で見ると違いが分かります。

方法	机の数	履歴と設定の共有	同時にAIを走らせられるか
ブランチ切替（checkout）	1つ	共有	不可。切り替えるたびに机の上が入れ替わる
stash（一時退避）	1つ	共有	不可。途中の作業を棚に上げるだけ
別clone（プロジェクトの複製）	複数	共有されない	可能だが、机ごとに設定や履歴が食い違っていく
git worktree	複数	履歴・設定・ルールを共有	可能。机は独立、資料の元は1つ

ブランチ（枝。作業の系統を分ける単位）の切替とstashは、机が1つしかないので並列にはなりません。別cloneは机が増えますが、設定やルールが机ごとに分かれて後で食い違う。worktreeだけが「机は別、資料の元は1つ」を両立します。 ルールを1回書けば全部の机に効くのが、実務では大きい。

ブランチ切替・stash・別clone・worktreeを「机の数」と「資料の共有」で比較した図

2026年8月時点のClaude Code公式の対応

2026年8月時点のClaude Code公式ドキュメント（code.claude.com/docs/ja/worktrees）で確認できる仕様は次のとおりです。

起動時に --worktree（短縮形 -w）を付けると、プロジェクト直下の .claude/worktrees/ 配下に独立した作業場を作り、その中でセッションが始まる
セッション中に「worktreeで作業して」と頼むと、Claude自身が作業場を作って移動する。デスクトップ版は新しいセッションごとに自動で作業場を作る
画面を開かず裏で1回だけ実行する起動方式（-p）で作った作業場は自動では消えない。片づけは人間がgit worktree removeで行う
.worktreeinclude に書いたファイルは、gitの管理外でも新しい作業場に複製される

机を増やすところまでは、公式が面倒を見てくれる段階です。足りないのは机の増やし方ではなく、どの仕事をどの机に置き、成果物をどう合流させるかの運用です。ここが本記事の主題です。

並列に向く仕事・向かない仕事の線引き

独立した塊に切れる仕事は向く。一本道は向かない

僕の机の割り当ては、性質の違う3種類に固定しています。「書かせる」「直させる」「調べさせる」です。

仕事の型	例	並列に向くか	理由
書かせる	記事の下書き・資料のたたき台・メール文面	向く	ゼロから起こす仕事は、他の机の結果を待たない
直させる	昨日の原稿の修正・道具の不具合取り・指摘の反映	向く	直す対象と触るファイルが決まっている
調べさせる	競合の動き・一次情報の所在・公式仕様の確認	向く	結果を後で読むだけで、途中に人の判断が要らない
一本道の仕事	前の答えを見ないと次を決められない検討	向かない	分けても待ちが生まれるだけ。1つの机で順に進める
小さな単発	5分で終わる調べ物1件	向かない	机を分ける段取りの方が重い。1体で十分

判断は単純です。いま抱えている仕事が、独立した塊に切り分けられて、かつ量がまとまっているか。 イエスなら並列が効く。ノーなら1つの机で淡々とやった方が速い。

検品を飛ばすと、手戻りも並列で積み上がる

複数の机を同時に走らせるということは、間違いも同じ速さで積み上がるということです。僕がやるのは指示と検品だけですが、この「検品」は省けません。見ずに次を渡すと、朝に開いた3つの机が昼には3本の手戻りになって戻ってきます。並列で浮いた時間の一部は、検品に再投資する前提で組んでください。

成果物と台帳の衝突を避ける運用ルール

worktreeが保証するのは「作業中にファイルが混ざらないこと」であって、「マージ（合流。別々の机の変更を1つにまとめること）したときに無事なこと」ではありません。僕が実運用で決めているルールは3つです。

ルール1: 触るファイルが重ならない単位で仕事を切る

1つの机に1つの仕事、AI1体。相乗りさせない。仕事は「触るファイルが重ならない単位」で切ります。記事Aの下書き、道具Bの修正、テーマCの調査はよい組み合わせ。同じ設定ファイルを2つの机で触らせると、合流の瞬間に衝突として全部返ってきます。AIは隣の机の事情を知らないので、発覚するのは人間が統合するときです。切れない仕事は直列でやります。

ルール2: 台帳のマージは片側採用しない（2026年7月29日制定）

これは僕が実際に事故の手前で決めたルールです。僕の仕組みには、日々の計測結果や判断を1行ずつ追記していく「台帳」（記録ファイル）があります。worktreeで計測を走らせるとその机の台帳が育ち、同時に本体の机でも毎日の自動保存で同じ台帳が更新される。両方が育つので、合流させるとき必ず衝突します。

ここで「どちらか片方を採用」で解決すると、もう片方にしか書かれていない実測が消えます。計測結果は取り直しがききません。だから2026年7月29日に、次の原則を運用ルールとして明文化しました。

台帳のマージは片側採用しない。「片側を採用」で解決すると、再取得不能な実測が消える。台帳は追記専用に見えて書き換えも起きるので、単純な合体でも重複する。必ずキーで畳んで無損失に合流させ、出力の行数が入力より減ったら書かずに停止する。

具体的には、記事IDや日時などのキーごとに両方の記録を突き合わせて1レコードに畳む小さな道具を作り、それを通してからでないと合流させません。コードではなく、日々育つ記録こそが並列運用で最初に壊れる成果物です。 ここを守るルールは、上位の解説記事にはまず載っていません。

ルール3: 統合の前だけは自分の目で差分を見る

各机の中の作業はAIに任せます。ただし机をまたぐ統合、つまり「どの変更を生かすか」の判断は渡しません。統合は設計判断そのもので、ここを自動に流すと、壊れたときに誰も全体像を説明できなくなります。

ポイント

実行は自動。各机の中で「書く・直す・調べる」はAIに任せる
統合と責任は人間。机をまたぐ合流の前だけは、自分の目で差分を見る
面数の上限は「自分が検品できる数」。増やせないのはAIではなく人間の確認能力の方

この分担は、AI自動化で人間が握るべきゲートの線引きで書いた原則と同じです。並列にしても、人間の関所の位置は変わりません。

1人で3人分を回す作業環境の組み方5ステップ

2面から始める

いきなり3つに分けない。本体の机の隣に作業場を1つ増やし、2面で回す。面数を増やすほど統合の負担が人間側に積み上がるので、まず2面で「合流が回る」ことを確かめます。

性質の違う仕事を1つずつ渡す

1つ目に「書かせる」、2つ目に「直させる」か「調べさせる」。同じ種類の仕事を2つ渡すと後で混ざります。触るファイルが重ならないことを、渡す前に確認します。

返ってきたものを検品する

1体が走っている間、待たずに別の机を見に行く。返ってきたものを読み、採るか差し戻すかを決める。この往復が「待ち時間」を「別の机を見る時間」に変えます。

統合は自分が握る

合流の前に差分を自分の目で見る。台帳など日々育つ記録は片側採用しない。合流が終わった机は、中身を回収してから閉じます。

回ることを確認してから1面ずつ増やす

2面で1日回せたら3面目を足す。目安は「自分が1日に検品できる数」。検品が追いつかなくなったら、1面戻します。

並列で走らせるほど、AIの利用量は面数に比例して増えます。上限の決め方はAIの従量課金を止めない上限管理に分けて書きました。

git worktreeのよくある質問

git worktreeとは何ですか？

1つのgitプロジェクトに対して、履歴を共有したまま作業フォルダを複数持てる機能です。同じ資料一式を積んだ独立した机を増やす仕組み、と理解すれば十分で、複数のAIを同時に走らせる土台になります。

ブランチとの違いは何ですか？

ブランチは作業の系統を分ける単位で、1つの作業フォルダでは同時に1つしか開けません。worktreeは作業フォルダそのものを増やす機能で、机ごとに別のブランチを同時に開けます。切り替えるのではなく、並べる。この差が並列運用の可否を分けます。

使い終わったworktreeの削除はどうすればいいですか？removeとpruneの違いは？

通常はgit worktree removeで消します。git公式ドキュメント（2026年8月時点で確認）では、未保存の変更が残る作業場はそのままでは消せず、強制するには明示的な指定が必要で、本体の作業場は消せません。pruneは、フォルダを手で消した後に残る管理情報だけを掃除する命令です。Claude Codeの-p実行で作った作業場は自動では消えないので、定期的にremoveで片づけてください。

VSCodeやCursorでも使えますか？

使えます。worktreeはgit側の機能なので、エディタを問いません。作業場ごとに別ウィンドウで開けば、机が分かれた状態で編集できます。ターミナルで机ごとにClaude Codeを起動する運用との組み合わせが、僕の実際の形です。

Claude Codeで並列に使うにはどうすればいいですか？

2026年8月時点の公式仕様では、claude --worktree 名前で起動すると、その名前の作業場が .claude/worktrees/ 配下に作られ、その中でセッションが始まります。別のターミナルで別の名前を付けて同じことをすれば、2つ目の独立したセッションです。やり方より大事なのは、各机に性質の違う仕事を渡し、統合だけは自分が握ることです。

付録: 実際に使っているコマンド一式

本文の主役ではないので末尾に置きます。git公式ドキュメント（git-scm.com/docs/git-worktree）とClaude Code公式ドキュメント（code.claude.com/docs/ja/worktrees）で、2026年8月時点の仕様を確認しています。

机を増やす: git worktree add ../desk-write -b write（「書かせる」机を、本体の隣に新しい枝writeで作る。同じ要領で desk-fix、desk-search を作る）
いま何面開いているか点呼する: git worktree list（毎朝これで開いている机を数える）
机でClaude Codeを起動する: その机のフォルダに移動して claude を起動する（または本体で claude --worktree 名前）
合流する: 本体の机で、終わった枝を取り込む（git merge 枝名）。この直前に差分を自分の目で見る
机を片づける: git worktree remove ../desk-write（未保存の変更が残っていると拒否される安全装置つき）
手で消してしまった残骸の後始末: git worktree prune
本体の見た目を汚さない: .claude/worktrees/ を .gitignore に追加する（公式ドキュメントが推奨）

フォルダ名は枝の名前と揃え、パスを見れば何の机か分かるようにしておきます。3面を見渡す人間のためです。

まとめ: 作業者から采配する側へ

git worktreeは、同じ資料一式を積んだ独立した机を増やす仕組み。机を分ければ複数のClaude Codeが同じ時間帯に走る
並列に向くのは独立した塊に切れる仕事。一本道と小さな単発は1体で十分
触るファイルが重ならない単位で切る。台帳は片側採用しない。統合の前だけは自分の目で差分を見る

机を分けて回し始めると、自分の仕事の中身が「書く・直す・調べる」から「誰に何を渡し、返ってきたどれを採るか」に変わります。作業者から、采配する側へ。これが並列運用の本当の変化です。

Claude Codeをこれから業務に入れる段階の方は、まず1体で何ができるかをこちらで確認してください。

この記事は「同じ時間帯に複数の仕事を並列で進める作業環境」に絞りました。定時に自動で走らせる話はlaunchd自動化、手順を部品化する話はカスタムスキル、回し続ける設計の考え方はループエンジニアリングに分けています。

ポイント

どの仕事を机に載せるかを決める前に、自社の業務を「手順が毎回同じ・成果物がファイルで残る・やり直しがきく」の3条件で棚卸しするワークシートを無料公開しています。並列に向く「独立した塊」を見つける最初の1枚として使ってください。

AI業務棚卸しワークシートを無料で受け取る

出典

worktreeの仕様と、Claude Codeが複数のセッションを別々の作業場で走らせる方法は、下記の公式ドキュメントを下敷きにしています（いずれも2026年8月時点で確認）。「独立した机」という言い換え、「書かせる・直させる・調べさせる」の机の分け方、向く仕事と向かない仕事の線引き、台帳のマージを片側採用しない運用ルールは、僕が2026年6月からの実運用で固めた部分です。