Claude Code を複数同時に走らせたいけど、お互いのファイルがぶつからないか不安な人向け
Git で管理しているプロジェクト（git init 済み、または GitHub からコピーしてきたフォルダ）の上で、料理ブログのレシピ検索機能を作っている最中にフッターのリンク切れも直したい、みたいに2つの作業を同時に進めたいときに、片方ずつ別フォルダで安全に走らせるため、起動時に「claude --worktree 名前」で叩く。借りてきたOSSを壊さず実験したいときにも本流のきれいな状態から別フォルダを切り出せる。
Claude Code を2つ同時に走らせたいとき、いちばん怖いのが「片方が直したファイルを、もう片方が上書きして壊す」事故です。Git Worktrees はこれを物理的に防ぐ仕組みで、セッションごとに別のフォルダを用意して、お互いのファイルに一切触れないようにします。
同じプロジェクトを「もう1つの机」に広げて作業する、みたいなイメージです。机は別々でも、引き出しの中身、つまり過去の変更履歴やネット上の保存先は1つを共有しています。
噛み砕くと
新しい職場に2人で入って、それぞれ別の会議室をもらった状況を思い浮かべてください。会議室は別なので、相手のホワイトボードを消してしまう心配がありません。でも会社の資料棚（プロジェクトの過去の記録）は共通で、どちらの部屋からも同じものを見ています。
Git Worktrees の「別フォルダ」がこの会議室にあたります。フォルダが分かれているから、片方の Claude が recipe.html を書き換えても、もう片方の Claude が触っている footer.html には何も起きません。これが地味に効きます。
大事な前提：Git で管理しているプロジェクトでしか動かない
最初にいちばん大事な前提を1つ。このコマンドは Git で管理しているプロジェクトでないと動きません。具体的には、フォルダの中で一度 git init をして履歴を持たせてあるか、GitHub などからコピーしてきたフォルダであることが条件です。
ただのファイル置き場（Git の履歴がないフォルダ）で --worktree を叩くと、別フォルダを切り出す土台がないので、エラーで止まります。公式も冒頭で「ここから先の話は、すべて Git で管理されたプロジェクトを前提にしている」と断っています。まずはここを満たしているか確認してください。
大事な前提：worktree は「丸ごとコピー」ではない
ここを最初に押さえないと誤解します。worktree は、プロジェクトをまるごと複製した別物ではありません。あくまで「同じプロジェクトの、別の作業場所」です。
過去の変更の記録も、ネット上の保存先（GitHub など）も、元のプロジェクトと1つを共有しています。だから片方の worktree で保存した変更は、ちゃんと同じプロジェクトの記録に積み上がっていきます。コピーして切り離した別物、ではない。ここが肝です。
「料理ブログで新機能とバグ修正を同時に」を例に、実際の手順を見る
料理ブログのプロジェクトがあって、やりたいことが2つあるとします。1つはレシピ検索機能の新規追加、もう1つはフッターのリンク切れ修正。これを2つの Claude に同時にやってもらいます。前提として、この料理ブログのフォルダは Git で管理されている状態とします。
ステップ1: 1回目は普通に起動して「信頼」を承認する
初めてのフォルダでいきなり worktree を作ろうとすると、エラーで止まります。公式も「あるフォルダで初めて使う前に、一度そのフォルダで claude を起動して信頼ダイアログを承認しておけ」と明記しています。
なので最初の1回は、料理ブログのフォルダで普通に起動します。
$ cd ~/projects/cooking-blog
$ claude起動時に「このフォルダを信頼しますか？」と聞かれるので承認します。これで下準備は完了です。一度承認すれば、次からは聞かれません。
ステップ2: ターミナルを2つ開く
黒い画面を2枚用意します。タブでもウィンドウでも構いません。左で新機能、右でバグ修正、と役割を分けると頭が混乱しません。
ステップ3: 左の画面でレシピ検索用の worktree を起動する
左の画面で、名前を付けて worktree 付き起動します。
$ claude --worktree recipe-searchこれで .claude/worktrees/recipe-search/ という別フォルダが作られ、worktree-recipe-search という新しい作業の枝の上で Claude が立ち上がります。あとは普通に「レシピ名で検索できる機能を作って」と頼むだけです。
ステップ4: 右の画面でバグ修正用の worktree を起動する
右の画面では別の名前で起動します。同じ名前にしないのがコツです。
$ claude --worktree footer-fixこちらは .claude/worktrees/footer-fix/ に作られます。「フッターのリンク切れを直して」と頼みます。左の Claude とはフォルダが別なので、両方が同時にファイルを書いても衝突しません。
ステップ5: ここで初心者がやりがちな勘違い
「別フォルダから始まるなら、いま手元で書きかけの変更も持っていってくれるんだろう」と思いがちですが、逆です。worktree は本流の、ネット上と一致したきれいな状態 origin/HEAD から枝分かれします。つまり、まだ保存していない手元の編集は持っていきません。これは「汚れていないまっさらな状態から始められる」という利点でもあります。
ステップ6: 終わったら本流に取り込む
両方の作業が終わったら、それぞれの枝を本流に合流させます。フォルダが分かれていたぶん、変更がごちゃ混ぜにならず、片方ずつ落ち着いて取り込めます。
つまり Git Worktrees は何をしてくれるのか
- やってくれる: セッションごとに別フォルダを用意して、複数の Claude が同時に走っても互いのファイルを壊さないようにする。本流のきれいな状態から各フォルダを始める
- やってくれない: まだ保存していない手元の編集を新フォルダへ持っていくことはしない。持っていきたい場合は設定で起点を切り替える。プロジェクトを切り離した別物に複製するわけでもない
- 意味が薄い場面: Claude を1つしか走らせない単独作業。フォルダを分ける旨味がほぼ出ません
使いどころ3シナリオ（具体題材で再現）
シナリオ1: 料理ブログで新機能とバグ修正を並行するとき
レシピ検索機能を1時間かけて作っている最中に、読者から「フッターのリンクが切れてる」と連絡が来た。本来なら作りかけを中断して直すところですが、worktree なら別フォルダでもう1つの Claude を立てて、検索機能の手を止めずにリンク切れだけ先に直せます。私はこの「中断しなくていい」が一番ありがたいと感じます。
シナリオ2: 家計簿アプリで2案を見比べたいとき
グラフの見せ方で、円グラフ案と棒グラフ案のどちらがいいか迷ったとします。claude --worktree graph-pie と claude --worktree graph-bar を別々に起動して、両方を同時に作らせて見比べる。片方を作り直すたびにもう片方が消える、みたいな事故が起きません。比較検討がはかどります。
シナリオ3: 借りてきたOSSをいじり始めた直後
GitHub から拾ってきたプロジェクトを自分のパソコンにコピーしてきた直後、いろいろ試したいけど元の状態は壊したくない。worktree を作れば、本流のきれいな状態を保ったまま実験フォルダで好き放題できます。実験が失敗してもフォルダごと捨てれば済む。気楽です。
初心者が踏みやすい落とし穴
- Git で管理していないフォルダで叩いてしまう。このコマンドは Git の履歴があるプロジェクトでないと動きません。
git init済みのフォルダか、GitHub からコピーしてきたフォルダがこれにあたります。ただのファイル置き場で--worktreeを叩くとエラーで止まります - worktree を「丸ごとコピー」だと思い込む。別フォルダではありますが、過去の記録もネット上の保存先も元と共有しています。切り離された別プロジェクトではありません
- worktree を「作業の枝そのもの」と混同する。worktree は場所（フォルダ）で、枝はその場所が乗っている分かれ道です。1つの worktree が1つの枝を持つ、という関係
- 初回の信頼承認を飛ばす。新しいフォルダでいきなり
--worktreeを使うとエラーで止まります。先にそのフォルダで一度claudeを起動して承認してください - 環境ファイルが新フォルダに無くて慌てる。
.envのような秘密設定は、worktree には自動では入りません。持っていきたいなら.worktreeincludeに書き出す必要があります - 「
.worktreeincludeに書けば何でもコピーされる」と勘違いする。コピーされるのは「パターンに一致し、かつ普段は記録から除外している（gitで無視している）ファイルだけ」です。すでにプロジェクトに記録済みのファイルは二重コピーされません - 「
--worktreeで作ったフォルダは全部残る」と思い込む。じつは逆で、変更を何もせずにセッションを終えると、フォルダとその枝は自動で消えます。変更が残っている場合は終了時に「残しますか？」と確認されます。ただし-pという、黒い画面でのやりとり無しに自動で走らせるモードで起動したときだけは確認されず残るので、その時はgit worktree removeで自分で消す必要があります - まっさらな状態から始まることに驚く。worktree は本流のきれいな状態から枝分かれするので、手元の書きかけは引き継ぎません。引き継ぎたい場合は設定で起点を切り替えます
- デスクトップアプリと感覚が違う。デスクトップアプリは新しいセッションごとに自動で worktree を作ります。黒い画面での手動操作に慣れていると、勝手に増えて驚くかもしれません
書き方
claude --worktree <名前>やってみるとこうなる
入力
claude --worktree recipe-search出力例
.claude/worktrees/recipe-search/ に別の作業フォルダが作られ、worktree-recipe-search という新しい作業の枝の上でClaudeが起動する。別の画面で claude --worktree footer-fix を叩けば2つ目が独立して立ち上がり、両者はファイルを共有しないので同時編集しても衝突しない。このページに出てきた言葉
- worktree（ワークツリー）
- 同じプロジェクトを別の場所に広げた「もう1つの作業フォルダ」。独自のファイルと作業の枝を持ちつつ、過去の記録とネット上の保存先は元のプロジェクトと共有する
- Git
- プロジェクトのファイルが「いつ・どう変わったか」を記録して、過去に戻したり枝分かれさせたりできる仕組み。worktree はこの Git で管理しているプロジェクトでのみ使える
- 作業の枝（ブランチ）
- 本流をいじらずに変更を試すための分かれ道。worktree は1つにつき1つの枝を持つ
- origin/HEAD
- ネット上の保存先で「いまの本流の先端」とされている状態。worktree はここから枝分かれするのでまっさらな状態で始まる
- .worktreeinclude
- <code>.env</code> など、新しい worktree に持っていきたい設定ファイルを書き出しておく一覧。普段は記録から外しているファイルだけがコピーされる
- --worktree（-w）
- 起動時に後ろへ足すと、新しい作業フォルダを作ってその中で Claude を立ち上げる指定