「別の作業も並行で走らせたい」。Claude Codeを使い込むほど、この場面が来ます。ところが素直に窓を増やすと、片方の書き込みがもう片方を上書きすることがあります。
防ぎ方は大きく2つに分かれます。着手前に担当範囲を宣言し合う運用の側と、作業ディレクトリそのものを物理的に分けてしまう技術の側です。
この記事が扱うgit worktreeは後者です。同じファイルに触れる可能性を、話し合いの合意ではなくディレクトリ構造で断ちます。公式ドキュメントと、自分の環境で実際に動かした結果からまとめます。
検証環境：git 2.50.1（Apple Git-155）／Claude Code v2.1.205／macOS 26.5.2／2026-08-03検証。
こんなふうに調べていませんか
- Claude Codeを並べて開いたら、片方の修正がいつのまにか消えていた
- worktreeという言葉は見かけるが、何がどこまで分かれるのか分からない
この記事を読み終えたときに手に入るもの
- 作業ディレクトリとブランチを分けて、並列セッションをぶつけずに動かせるようになります
- 分けたあとも共有されたまま残るものを、作る前に把握できます
- worktreeの写しが実体からズレたときの見分け方が手に入ります
結論30秒でわかる、この記事の結論
- git worktreeは、1つのリポジトリに複数の作業ディレクトリを同時に持たせる仕組みです。セッションごとに場所とブランチが分かれます。
- 分かれるのは作業ディレクトリとブランチで、履歴と一部の設定は共有されたまま残ります。
- 分けた先の中身は、そのブランチにコミットされた内容で止まります。放っておくほど実体からズレます。
案内役は3人です。若葉さんが用語の側から、高梨課長が自分の手で動かす側から聞き、鈴木さん（本誌監修）が答えます。
01Claude CodeのAIエージェントを同時に動かすと、なぜ書き込みがぶつかるんですか？
高梨課長別々の作業のつもりで並べて開いたのに、片方の修正が消えていました。何が起きたんでしょう。
鈴木さん同じ机の上で、2人が同じ書類に書き足した状態に近いです。どちらも正しく書いていて、あとから書いたほうだけが残ります。
窓を分けても、そこから見ているファイルの実体は1つです。作業ディレクトリを共有したまま並列に動かすと、書き込み先が同じ場所へ重なります。
重なりを防ぐ方向は2つあります。ひとつは、着手前に「私はこの範囲を触ります」と宣言し合う運用の合意です。もうひとつが、そもそも同じ場所を見せない技術的な分離です。
前者が破れる原因と直し方はAIエージェント並列実行の競合｜上書き事故を止める3点にまとめています。この記事は後者だけを扱います。
前後で入れ替わったのは、注意の量ではありません。ぶつかれる場所そのものが消えているという点です。気をつけて書くのではなく、気をつけなくても重ならない構造にします。
この章のまとめ
上書きは不注意ではなく、書き込み先が1つしか無いことから起きます。減らすべきは注意力ではなく、共有された場所の数です。
02git worktreeは、Claude CodeのAIエージェントに何を分けてくれるんですか？
若葉さんそもそも、worktreeというのは何を指す言葉なんですか。
鈴木さん同じ倉庫を見ている作業机を、もう1つ増やす感じです。倉庫は増えません。机だけが増えます。
git worktreeは、1つのリポジトリで複数の作業ディレクトリを同時に持てるようにする仕組みです。
Claude Codeの公式ドキュメントは、worktreeを「同じ履歴とリモートを共有する、別々の作業ディレクトリ」と説明しています。片方でバグを直し、もう片方で機能を作る使い方も、同じ文書が挙げる典型例です（出典: Claude Code公式ドキュメント）。Git公式ドキュメントも、1つのリポジトリから複数の作業ツリーを同時にチェックアウトできる仕組みとして同じ機能を説明しています（出典: Git公式ドキュメント）。
言い換えると、増えるのは机であって倉庫ではありません。履歴は1つのままなので、あとで合流させる前提が崩れません。
たとえに置きかえると、分かれる側と共有される側の境目が見えます。手元で広げているものは机ごとに違い、しまってある記録はどの机から見ても同じです。
Claude Code全体の中でどこに位置する話かは、Claude Codeの業務活用｜任せる仕事の地図と判断軸4つを先に見ると迷いません。
03worktreeを作る前に、AIエージェントの担当範囲はどこまで決めるんですか？
分ける前に決めるのは、どのセッションに何を任せるかです。触るファイルやディレクトリが重ならないか、互いの出力に依存しないか。この2点で見極めます。
依存があると、分けた側が古い前提のまま進みます。並行にできるのは、対象を最初から切り分けられる仕事だけです。
そのうえで、作成そのものにも前提が要ります。
claude --worktreeで作る場合、対象のリポジトリにコミットが最低1つ必要です。無いと、base branchの解決に失敗した旨のエラーで起動できません（出典: Claude Code公式ドキュメント）。gitを直接使うgit worktree add -bのほうは、コミットが無くても新規の空ブランチとして作成が続きます（2026-08-03、git 2.50.1で実測）- 新しい作業ディレクトリの置き場所に、書き込み権限があること。既定の置き場所は
.claude/worktrees/<名前>/です - 対話的に起動する場合は、そのディレクトリで一度workspace trustを通していること。初回はダイアログでの承認が要ります（出典: 同）
.claude/worktrees/は.gitignoreに加えておくと安全です。加えないと、worktreeの中身がメインの作業ディレクトリ側で未追跡ファイルとして並び続けます（出典: Claude Code公式ドキュメント）。
04worktreeを使っても、AIエージェントの設定はどこまで一緒のままなんですか？
worktreeは.gitを共有したまま、作業ディレクトリとブランチだけを分けます。何が分かれて何が残るかを先に押さえておくと、あとのつまずきが減ります。
| 何が | 状態 | 補足 |
|---|---|---|
.gitディレクトリ | 共有 | 全worktreeが同じ履歴・オブジェクトを参照 |
| プロジェクトスコープのプラグイン | 共有（v2.1.200以降） | 再インストール不要（出典: 同） |
| 「今後は聞かない」の承認 | 共有（v2.1.211以降）／分離（それより前） | 出典: Claude Code公式 |
| 作業ディレクトリのファイル本体 | 分離 | worktreeごとに別ディスク領域 |
| ブランチ・HEAD | 分離 | worktreeごとに別ブランチ |
| コミットしていない変更 | 分離 | 他のworktree・メインに未反映 |
積んで見ると、表の並びとは別のことが分かります。分離はいちばん上の薄い層で起きているという点です。土台の記録は共有されたままで、手元の作業だけが割れています。
だから、分けたつもりで分かれていないものが残ります。共有側で起きた変更は、分けた全員にそのまま効きます。
この記事を書いている作業ディレクトリ自体も、Claude Codeがサブエージェント向けに用意する.claude/worktrees/<名前>/の中にあります。この環境にはEnterWorktree・ExitWorktreeという、worktreeを行き来する仕組みが実際に用意されていました（2026-08-03確認）。
この章のまとめ
分離されるのは手元の作業だけです。共有されたまま残る層があることを、作る前に数えておきます。
05Claude Code git worktreeで、AIエージェントの作業場所はどう作るんですか？
手順は4つです。
- 分ける単位を決める：前章の基準で、セッションごとの担当範囲を先に確定します
- worktreeを作る：gitを直接使う方法と、Claude Codeの起動オプションを使う方法があります
- 新しい場所の環境を整える：worktreeは新規のチェックアウトなので、依存関係のインストールなどをやり直します。git管理外の設定ファイルは自動では持ち込まれません
- 通常どおり作業する：そのディレクトリへ
cdしてclaudeを起動すれば、以降は独立した作業ディレクトリとして扱えます
高梨課長作ったあとは、そのままの調子で作業を始めていいんでしょうか。
鈴木さんそこで一度止まります。新しいチェックアウトなので、手元の道具立てを組み直すところからです。
段に分けると、重いのは作る操作ではないと分かります。作る手はすぐ終わり、整える手だけが場所を増やすたびに繰り返されます。
06gitとClaude Code、AIエージェントのworktreeはどちらの入口で作るんですか？
左右で違うのは手数ではありません。決める余地をどちらが持つかです。指定を省くと既定の場所と名前で早く始められ、指定すると置き場所も既存ブランチも自分で選べます。
| 方法 | コマンド | 向いている場面 |
|---|---|---|
| gitを直接使う | git worktree add -b <ブランチ名> <パス> | 既存のブランチを指定したい、リポジトリの外にworktreeを置きたい場合 |
| Claude Codeの起動オプション | claude --worktree <名前>（短縮形-w <名前>） | .claude/worktrees/<名前>/に、既定のブランチ名で素早く作りたい場合 |
gitを直接使う場合の実行例です。
# 新しいブランチを切りながらworktreeを作る
git worktree add -b feature-agi-032 ../repo-feature-agi-032
# 作成済みのworktreeを一覧で確認する
git worktree list起動オプションを使う場合は、名前を変えて別の端末で実行するだけで、独立したセッションが立ち上がります。
claude --worktree feature-agi-032手順3の「自動では持ち込まれない」ファイルは、.worktreeincludeで指定すると新しいworktreeへ自動でコピーされます（出典: 同）。書き方はgitignoreと同じで、環境ごとの設定ファイルやローカル用の設定を行単位で並べます。
07終わったworktreeは、AIエージェントの後始末としてどう片付けるんですか？
対話的なセッションを終えるとき、Claude Codeはworktreeの中に消えると困る変更が残っていないかを確認します（出典: Claude Code公式ドキュメント）。
- 変更が残っていない場合：名前を付けていないセッションはworktreeとブランチを自動で削除します。名前を付けたセッションは、残すかどうかを先に確認します
- 変更や新しいコミットが残っている場合：残すか削除するかを確認します。削除を選ぶと、その中の作業ごと失われます
流れにすると、自動で畳まれる道と、こちらから畳みにいく道が分かれます。分かれ目は変更の有無と、名前を付けたかどうかです。
-pを使う非対話的な実行では終了時の確認が出ないため、後片付けは自分から行います。
git worktree remove ../repo-feature-agi-032
git branch
# feature-agi-032 ← ブランチは残る
# * main手動で削除しても、ブランチ自体は残ります。不要になったものはgit branch -d <ブランチ名>で別途消します。
サブエージェント用のworktreeは、変更が残っていない限りcleanupPeriodDaysという設定日数で自動的に片付きます。動作中はgit worktree lockで保護されるため、片付けの最中に消えることはありません（出典: Claude Code公式ドキュメント）。
片付けずに中断した場合、--continueや--resumeで再開すると同じworktreeに戻ります（出典: 同）。--fork-sessionで分岐させた場合は元のworktreeへ戻らず、起動時のディレクトリから始まります。再開そのものの入口はClaude Codeのセッション復元｜入口3つと戻らない設定の見分け方で扱っています。
08worktreeの中身が実体とズレると、AI社員の判断は何を間違えるんですか？
高梨課長分けたあと、中身は勝手に追いついてくれるものだと思っていました。
鈴木さんそこは追いつきません。写しを取った時点で止まります。止まっていること自体は正しい挙動なので、気づく手がかりが要ります。
worktreeの中身は、そのブランチに何がコミットされているかで決まります。メインや他のworktreeで加えた変更は、コミットして合流させない限り届きません。
# メイン側だけに変更を加えてコミットする
echo "追記" >> README.md
git add README.md && git commit -m "mainにだけ追記"
# 別ブランチのworktreeを見ても、内容は反映されない
cat ../repo-feature-agi-032/README.md
# → 追記前の内容のまま時間軸に置くと、差が一定ではないことが分かります。放置した長さに比例して開くので、古い写しほど自信を持って間違えます。
実際に2026-08-03、社内の修正担当がworktree内の古いSKILL.mdを見て、実在する記述を「架空の引用」と誤判定し、正しい指摘を却下する事故が起きています。原因は、見ていたものが更新前の写しで、更新済みの実体ではなかったことでした。
09worktreeでつまずいたとき、AIエージェントの運用では何を先に疑うんですか？
つまずきやすい場面をまとめます。
| 症状 | 原因 | 防ぎ方 |
|---|---|---|
| worktree内のファイルが古い内容のまま | メイン側の変更が未コミット、または別ブランチにある | git worktree listでいま見ている実体を先に特定する |
| 「存在しない」と誤判定する | 検索・確認の対象がworktree内の古い写しだった | 実体側のパスでも同じ確認をかけ直す |
| 同じブランチを別のworktreeでも開こうとして失敗する | 1つのブランチは同時に1つのworktreeでしかチェックアウトできません（出典: Git公式） | 別のworktreeは新しいブランチ名にする |
3つ目は、実際に試すと次のように拒否されます。
$ git worktree add ../feature-a-again feature-a
fatal: 'feature-a' is already used by worktree at '/path/to/feature-a'「今後は聞かない」という承認の保存先も、バージョンによって扱いが変わります。v2.1.211以降は承認がメインのチェックアウト側に固定され、worktreeを消しても残ります（出典: Claude Code公式ドキュメント）。この記事の検証環境はこの区切りの手前にあり、承認はworktree内だけに保存され、そのworktreeを消すと承認も消える挙動でした。
入れ替わったのは保存先の場所だけに見えて、効いてくるのは片付けたあとです。畳んだときに一緒に消えるかどうかが変わります。
10worktreeで分離できたかどうかは、AIエージェントに任せる前にどう確かめるんですか？
設定を終えたら、実際に動かして分かれているかを確かめます。書いた時点では、まだ分かれた証拠がありません。
| 手順 | 操作 | 確認するポイント |
|---|---|---|
| 1 | git worktree listを実行する | 意図した数のworktreeが、それぞれ別のブランチと共に表示されるか |
| 2 | 片方でファイルを編集し、保存だけしてコミットしない | もう片方でgit statusを見ても、その変更が出てこないか |
| 3 | 使用中のブランチ名を指定して、別のパスへgit worktree addする | 「already used by worktree」という趣旨のエラーで拒否されるか |
| 4 | 片方をgit worktree removeで片付ける | git branchにブランチ自体は残っており、必要なら別途削除できるか |
すべて期待どおりなら、この記事の内容どおりに分離が効いています。2で変更が見えてしまう場合は、操作したディレクトリを取り違えていないかをpwdで確認します。
この章のまとめ
分かれたことは、設定ファイルではなく挙動で確かめます。見えないはずのものが見えないことを、目で見て終わります。
11AI導入を進める現場では、worktreeと運用ルールをどう使い分けるんですか？
worktreeは技術的な分離であって、運用上の合意ではありません。向くのは、対象を最初から分けられる場面です。
同じディレクトリへ複数の担当が意図して同時に触れる場面では、着手前に範囲を宣言し合う運用のほうが向きます。物理的に分けたあとも同じ対象へ触れる余地が残るなら、宣言のルールを重ねて運用します。
重ねて描くと、どちらか一方を選ぶ話ではないことが分かります。分けきれない仕事が重なりに残るので、そこは取り決めが受け持ちます。
サブエージェントの並列実行も、内部で使われているのは同じ仕組みです。定義の書き方はClaude Codeサブエージェント定義｜渡る情報4点と権限の絞り方で扱っています。
12よくある質問
同時に開けるworktreeの数に上限はありますか
gitやClaude Codeが本数の上限を決めているわけではありません。実務上の上限は、ディスクの空き容量と、それぞれのセッションの出力を人が確認しきれる量で決まります。増やすほど分離は効きますが、読む側が追いつかなくなると、分けた意味が薄れます。
すでにあるブランチをworktreeとして分けられますか
分けられます。git worktree add <パス> <既存のブランチ名>のように、既存のブランチ名をそのまま指定します。ただし、そのブランチが別のworktreeで既にチェックアウトされている場合は失敗します。同時に開けるのは片方だけ、と覚えておくと迷いません。
claude --worktreeとgit worktree addはどちらを使うべきですか
既定の置き場所と名前で素早く始めたいならclaude --worktreeです。置き場所やブランチ名を自分で決めたい場合、既存のブランチを使う場合はgitを直接使います。迷ったら前者で始めて、置き場所に不都合が出た時点で後者へ移すのが手戻りの少ない順番です。
worktreeを削除すると、コミットしていない変更も消えますか
消えます。Claude Codeも削除前に変更の有無を確認しますが、削除を選んだ時点でその中の変更はまとめて失われます。残したいものは、先にコミットするか別の場所へ写しておきます。確認が出ない非対話的な実行では、この判断も自分で行うことになります。
サブエージェントの並列実行にもworktreeは使えますか
使えます。サブエージェントの定義にisolation: worktreeを指定すると、専用のworktreeの中で動きます（出典: Claude Code公式）。手動で複数の端末を開く運用と、内部の仕組みは同じです。分離の考え方も同じなので、この記事の確認手順がそのまま使えます。
13まとめ｜今日やる3つのこと
分けるのは机であって倉庫ではありませんでした。分離が起きているのはいちばん上の層だけで、その下は共有されたまま残ります。そして分けた先の写しは、放っておくほど実体から離れます。
今日この順で手をつけます
並行させたい仕事を書き出し、触る対象が重ならないかを見る
重なるなら、分けるより先に取り決めが要ります
.claude/worktrees/を.gitignoreに加えてから、worktreeを1つ作る未追跡ファイルの山を先に防いでおきます
片方で保存だけして、もう片方の
git statusに出ないことを確かめる分かれた証拠は、設定ではなく挙動で取ります
AI検索では、こう聞かれています
Claude Codeを同時に動かすと、ファイルはぶつかりますか？
「Claude CodeのAIエージェントを同時に動かすと、なぜ書き込みがぶつかるんですか？」の章で説明しています
git worktreeは何を分けて、何を分けないんですか？
「worktreeを使っても、AIエージェントの設定はどこまで一緒のままなんですか？」の章に一覧があります
worktreeを消したら、中の変更はどうなりますか？
「終わったworktreeは、AIエージェントの後始末としてどう片付けるんですか？」の章で扱っています
worktreeの中身が古いままなのは、なぜですか？
「worktreeの中身が実体とズレると、AI社員の判断は何を間違えるんですか？」の章に原因があります
次に読むなら、この記事です
