Git 2.26以上を前提にしたDeepSeek Harnessの開発ガイドは、作業用フックにworktree単位の設定を利用しています。したがって、同じリポジトリの短期タスクなら「1タスク1 Git worktree、1セッション1作業ディレクトリ」を選ぶのが基本です。依存関係、認証情報、ビルドキャッシュまで完全に分ける場合や、顧客ごとの信頼境界が異なる場合は、独立クローン、または独立したMac環境へ切り替えてください。 DeepSeek Harness開発ガイド
個人開発者、複数のAgentで同じリポジトリを改修したい開発者、リモートMacの実行プールを管理するプラットフォーム担当者が対象です。大型ビルドや顧客コードを扱い、単なるファイル分離では足りないチームにも役立ちます。
00まず作業単位を固定してから並列化します
DeepSeek Harnessの公式ベンチマークでは、独立したベンチマークタスクに異なるワークスペースとセッションIDを使うよう指定されています。これは、Harnessが自動的にGit worktreeを作成・紐付け・回収することを意味しません。公式に確認できるのは、タスクと作業場所、セッションを独立させるという運用上の境界です。 BENCHMARK.mdの記載
個人開発者が同一リポジトリの小さな修正を2件並列で進める場合は、次の形にします。
- タスクA：
/path/to/worktree-a、task/a、セッションA - タスクB：
/path/to/worktree-b、task/b、セッションB
Gitのworktreeは、複数のブランチを同じリポジトリから同時にチェックアウトできる仕組みです。各worktreeにはHEADやインデックスなどの個別管理情報がありますが、リポジトリの大部分のオブジェクト、参照、通常の設定は共有されます。つまり、コードの作業場所は分けられても、リポジトリ全体の管理状態まで完全に別物になるわけではありません。 Git公式worktreeマニュアル
実行前には、次のコマンドで専用ブランチ付きの作業場所を作成できます。
git worktree add -b task/a /path/to/worktree-a HEAD
git worktree add -b task/b /path/to/worktree-b HEAD
git worktree list --porcelain
DeepSeek Harnessをソースから動かす場合、公式手順ではリポジトリをクローンし、依存関係を導入してからビルドします。各セッションの起動時には、カレントディレクトリが割り当てたworktreeと一致していることを確認してください。 公式リポジトリの実行手順
01研发チームはディレクトリではなく責任を分離します
チーム利用で起きやすい事故は、作業ディレクトリの重複よりも「誰が何をマージするのか」が曖昧なことです。タスクごとに、少なくとも次の項目を契約として記録します。
- タスク所有者
- 使用するベースブランチ
- 作業ブランチ名
- 変更してよいディレクトリ
- テストとビルドの責任者
- マージまたは破棄の判断者
- 未コミット成果物を残す期限
コードを変更するAgentには専用worktreeが必要です。読み取り専用の分析は共有チェックアウトでも実行できますが、分析中に自動修正、フォーマッター、生成処理が起きる可能性があるなら専用化します。テスト修正は、テストコードだけを変更するのか、製品コードまで変更するのかを先に分け、後者なら通常の改修タスクと同じ扱いにします。
同じファイルを複数のAgentが高頻度で変更する場合、worktreeを増やしても論理的な競合は消えません。共通の型定義、設定ファイル、依存関係ロックファイル、データベーススキーマなどを同時に触る場合は、先行タスクをコミットしてから次のAgentを開始する直列実行へ戻します。
02共有されるものと分けるべきものを確認します
Git worktreeをサンドボックスと考えるのは危険です。分離されるのは主に作業ツリーと一部のGit管理情報であり、プロセス、ポート、認証情報、外部キャッシュ、OSユーザーの権限までは自動で分離されません。
特に注意すべき制限は次の4つです。
-
リポジトリ設定の共有
Gitの通常設定はworktree間で共有されます。worktreeごとに設定を変えたい場合は、extensions.worktreeConfigとgit config --worktreeを検討します。設定の共有範囲は、Git公式のworktree仕様に沿って確認してください。 Git公式の設定説明 -
依存ディレクトリの衝突
node_modules、仮想環境、パッケージ管理ツールのインストール先が同じなら、別worktreeでもファイル更新やロックが競合します。読み取り専用のダウンロードキャッシュだけを共有し、展開先や生成物はタスク単位に分けます。 -
ビルド成果物と外部ディレクトリ
dist、build、target、IDEのインデックス、テスト用データベースなどがリポジトリ外の固定パスを使うと、worktree間で上書きが起きます。ビルド番号ではなく、タスクIDを含むパスを環境変数で渡す構成が安全です。 -
バックグラウンドプロセスとポート
開発サーバー、ファイル監視、テストランナー、エミュレーターは、作業ディレクトリが違っても同じポートや共有ソケットを利用できます。プロセスID、ログパス、ポート番号をセッション契約に含めてください。
DeepSeek Harnessの開発ガイドでも、ルートでの依存導入、ビルド、環境変数によるAPIキー設定が示されています。APIキーは環境変数または.envから読み込まれるため、worktreeを分けただけで認証情報の信頼境界が分離されるわけではありません。 環境変数とビルド手順
注意： worktreeはコードの同時編集を整理する仕組みであり、プロセス隔離や秘密情報の保護を担うサンドボックスではありません。顧客ごとに異なるAPIキーやクラウド権限を使う場合は、独立クローンだけで済ませず、macOSユーザーまたはMac環境そのものを分けます。
03プラットフォーム側は作成から回収までを設計します
自動化する場合は、次の5段階を一つの責任チェーンとして実装します。
1. 作成
ベースコミット、タスクID、作業パス、ブランチ名を確定し、git worktree add -bで作成します。既存ブランチが別worktreeで利用中の場合、強制オプションで上書きせず、タスク契約を修正するか新しいブランチを作ります。
2. 紐付け
DeepSeek HarnessのセッションID、作業パス、ブランチ、担当Agent、開始時刻を記録します。Harness側で自動管理されると仮定せず、実行プール側の台帳に保存してください。
3. 実行
依存関係の展開先、ビルド出力、ログ、テスト用ポートをタスク固有のパスへ向けます。共有するのは、破損時に再取得できる読み取り専用キャッシュに限定します。
4. 検収
git status --short、git diff --check、テスト結果、生成物の一覧、実行中プロセスを確認します。未コミット変更がある場合、その内容を台帳に残さずに回収へ進めてはいけません。
5. 回収
まずセッションとバックグラウンドプロセスを停止し、成果物を保存します。その後、作業ツリーがクリーンであることを確認してから次を実行します。
git worktree remove /path/to/worktree-a
git worktree list --porcelain
git worktree prune --dry-run
作業ディレクトリを先にOSコマンドで削除すると、Git側に管理情報が残る場合があります。Git公式マニュアルでも、手動削除後はgit worktree pruneで古い管理情報を整理できる一方、通常はgit worktree removeを使うよう説明されています。未コミットファイルがあるworktreeは、強制削除ではなく、差分を保全して人手へ引き継ぎます。 削除・prune・repairの公式説明
04信頼境界が違う場合は独立環境へ切り替えます
独立クローンは、Gitオブジェクト、設定、依存関係の導入先、リポジトリ内の補助ファイルを分けやすくします。ただし、同じmacOSユーザーで動かす限り、ホームディレクトリの認証情報、SSHキー、共有キャッシュ、プロセス一覧へのアクセスが残る可能性があります。
次の条件に一つでも該当する場合は、worktreeではなく独立クローンを選び、さらに権限差がある場合は独立したmacOSユーザーまたはMac環境へ移します。
- 顧客ごとにAPIキー、SSHキー、クラウド権限が異なる
- 閲覧可能なリポジトリやブランチの範囲が異なる
- 本番データ、個人情報、契約上の機密情報を扱う
- 一方のタスクが任意のシェルコマンドを実行できる
- 依存関係や生成物を同じパスに置けない
- 回収後に認証情報や一時データを確実に消去する責任がある
DeepSeek Harnessは2026年8月19日時点で開発プレビューであり、公式リポジトリも互換性を壊す変更が起こり得ると明記しています。原生のworktree自動作成、セッション紐付け、回収機能が追加された場合は、実行プールの責任範囲を再確認してください。 公式リポジトリの開発プレビュー表示
053段階の選択表で構成を決めます
| 選択肢 | 向いている作業 | 分離できる範囲 | 主な弱点 | 回収方法 |
|---|---|---|---|---|
| Git worktree | 同一リポジトリの短期改修、レビュー前の試作、読み取り分析 | 作業ツリー、HEAD、インデックス、worktree単位の一部設定 | 依存関係、外部成果物、ポート、認証情報は別途管理が必要 | git worktree remove後に状態確認 |
| 独立クローン | 依存関係やリポジトリ設定も分けたい並列タスク | リポジトリ管理情報、設定、導入先を分離しやすい | ディスク、取得、更新、回収の負担が増える | クリーン確認後にディレクトリと台帳を処理 |
| 独立環境 | 顧客案件、権限差、秘密情報、長時間ビルド | OSユーザー、プロセス、認証情報、作業場所 | Mac資源の割り当てと監査が複雑 | セッション停止、証跡保存、環境廃棄 |
同じMac上で複数の実行を扱う場合は、クラウドMacの並列環境を計画するための案内も確認し、ディスク容量だけでなく、メモリ、ビルド時間、バックグラウンドプロセス、回収担当まで含めて設計します。
062つの破棄可能なブランチで基準タスクを検収します
本番導入前に、次のチェック項目を同じリポジトリで実行します。単純な起動確認だけでなく、変更、ビルド、取消、回収まで一連で通すことが重要です。
- [ ] 2つのタスクに異なるブランチと異なるworktreeを割り当てる
- [ ] 2つのDeepSeek Harnessセッションが別の作業パスを表示することを確認する
- [ ] 同じファイルを変更しないタスクを並列実行する
- [ ] 依存関係の展開先とビルド成果物のパスが重複しないことを確認する
- [ ] APIキー、SSHキー、
.envの参照範囲を確認する - [ ] 各タスクでテストとビルドを実行し、ログを別々に保存する
- [ ] 一方のセッションを途中で取消し、もう一方の作業に影響がないことを確認する
- [ ] 未コミット変更がある状態で回収処理が停止することを確認する
- [ ] 差分とログを保存した後、
git worktree removeが成功することを確認する - [ ]
git worktree list --porcelainに不要な管理情報が残っていないことを確認する
| 基準タスク | 合格条件 | 不合格時の切り替え |
|---|---|---|
| 並列コード変更 | ブランチ、作業パス、差分が相互に混ざらない | 同じファイルの作業を直列化 |
| 並列ビルド | 成果物、ログ、ポートが別である | 独立クローンまたは成果物パスを分離 |
| セッション取消 | 片方の停止で他方のプロセスが停止しない | プロセス管理とセッションIDの紐付けを修正 |
| 未完了作業の回収 | 未コミット変更を残して処理が止まる | 自動削除を禁止し、人手へ引き継ぐ |
| 機密情報の確認 | 顧客間でキー、SSH設定、データが共有されない | 独立macOSユーザーまたは独立Macへ移行 |
07FAQ：長期運用で迷いやすい境界
短期タスクではGit worktreeが最も扱いやすくても、長期運用では依存関係、生成物、ポート、認証情報が増え、コード以外の共有状態が問題になります。2つの破棄可能なブランチで検収し、失敗した項目がコード分離ではなく環境分離を要求しているなら、独立クローンまたは独立環境へ段階的に切り替えてください。
現在のMacだけでは、複数の作業ディレクトリを安定して確保できない、または長時間のビルドで日常作業と競合する場合があります。その場合は、日本向けMacレンタル環境の案内を確認し、必要な期間だけ実行環境を分ける方法も比較対象になります。
既存の方式が単一ディレクトリの共有、固定されたビルド出力、共通の認証情報、手動削除に依存しているなら、修正のたびに競合、再ビルド、秘密情報の確認、残存プロセスの調査が発生します。これらは独立worktreeだけでは解消しません。短期の並列改修はGit worktree、依存関係まで分離する作業は独立クローン、信頼境界や長時間占有まで分ける作業は独立環境という三段階で選ぶと、必要以上にMacを増やさず、回収責任も明確にできます。必要な期間だけ遠隔のMac環境を試す場合は、NUKCLOUDのMacレンタルを候補に入れ、まず2タスクの作成・取消・回収を実際に検証してください。