Claude CodeとCodexの並列作業|git worktreeの使い方とコピー範囲
このトピックを深掘りする
SaaSの導入・連携
AIに仕事の続きを渡すために、会議の原文、未完了の宿題、確認できない項目をどう残すか。導入判断と連携実装を掘り下げる。
全14本中 9 本目。
次に読む記事
Dub conversion tracking:lead・sale APIとStripeの顧客対応
クリックIDを登録・売上へ対応させるDubの実装ガイド。Businessの利用条件、leadとsaleの必須項目、USD・JPYの金額、invoiceId、Stripe metadataを公式資料と資格情報なしのJSON生成例で確認する。
Dub webhook署名検証:raw bodyと再送の境界をNode.jsで確認する
Dub-Signatureを受信本文のHMAC-SHA256で検証。Node.js/BunのRequestで6本文×6署名、二度読みのTypeError、UTF-8 BOMの限界を実測し、次のAI作業へ残す情報と未検証の実配信を整理します。
Slackのhuddleを録り、毎晩22時にAIへ渡す:Circlebackの設定6か所
AIに仕事の続きを渡すためのCircleback運用記録。Slack huddle、22時の同期、元の発言と未完了ToDo、採用する条件を具体化。運用経験・公式仕様・ローカル試験の根拠も示す。
シリーズ全体の流れを見ながら、次に読む記事へ進めます。 初めての方はホームへ →
Claude CodeとCodexを同じリポジトリで同時に使うときは、git worktreeを使ってAIごとに作業ディレクトリとブランチを分けます。Codexには git worktree add で作った場所を codex --cd で渡し、Claude Codeには claude --worktree で自分の場所を作らせます。
確認日: 2026-10-31。対象: Claude Code 2.1.312 / Codex CLI 0.163.0 / Git 2.56.0。
要点: worktreeごとに作業場所とブランチを分けます。gitignoreされた未管理ファイルのコピーは別に設定します。ポートやDB、権限の分離も別に扱います。
同じフォルダで2つのAIを動かすと何が起きるか
1つの作業ディレクトリには、チェックアウト中のブランチ(HEAD)とファイルが1組しかありません。片方のAIによる git switch が成功すると、もう片方が編集しているファイルも切り替わります。未コミットの変更も同じ場所で混ざります。git worktree を使うと、HEADとファイルを別に持つ作業ディレクトリをリポジトリに追加できます。
originのない検証用リポジトリでGitコマンドを実行して確かめました。追加したworktreeで編集した内容は、元の作業ディレクトリには現れませんでした。2つの作業ディレクトリは同じ共通Gitディレクトリを使うため、ブランチとコミットは共有されます。あるworktreeでチェックアウト中のブランチを別のworktreeでも使おうとすると、Gitは拒否しました。gitignore対象のファイルは、追加したworktreeにはありませんでした。両方を同じパスに向けるようにわざと壊した手順も、検査で検出できました。
3つの方法の違い
| 方法 | 作るもの | gitignore対象のコピー | 今回の確認 |
|---|---|---|---|
Git: git worktree add |
指定したパスとブランチ | しない | 実測 |
Claude: claude --worktree |
.claude/worktrees/<name>/ と worktree-<name> |
.worktreeinclude に一致したもの |
-p で作成とコピーまで実測 |
Codex: codex --cd |
作らない(既存の場所を指定する) | 該当なし | helpと公式資料のみ |
手順
以下は実用例です。今回実際に実行したのは、Gitでの分離の確認と claude -p --worktree だけです。codex --cd は実行しておらず、helpとCodex CLIリファレンスの記載に基づいて書いています。
cd /path/to/repo
git status --short
git worktree add -b codex-task ../repo-codex HEADHEAD から作ったworktreeには、未コミットの変更は入りません。git status --short で変更が表示されたら、先にコミットするか、元の場所に残しておくかを決めます。続いて別のターミナルを開き、元のリポジトリのディレクトリでCodexを起動します。--cd は作業ディレクトリを指定するオプションです。
cd /path/to/repo
codex --cd ../repo-codex両者を同じ起点にする場合は、先に下の「基にするブランチ」の worktree.baseRef: "head" をプロジェクト設定へ追加します。省略すると、originがある環境のClaude側はリモートの既定ブランチから作られ、Codex側の HEAD とずれる場合があります。初めてのディレクトリで対話起動する場合は、先に claude でworkspace trustを承認します。
元のターミナルでClaude Codeを専用のworktreeで起動します。
claude --worktree claude-taskCodexを非対話で実行する方法はcodex execの記事で説明しています。Claude Codeがどの指示ファイルを読むかは指示ファイル探索の記事で説明しています。
claude -wは何を作るか
公式資料によると、Claude Codeはリポジトリ直下の .claude/worktrees/<name>/ に作業場所を作り、worktree-<name> という新しいブランチをチェックアウトします。名前を省くと自動で付けられます。公式資料は .claude/worktrees/ を .gitignore に入れることも勧めています。対話起動ではworkspace trustの承認が必要で、-p ではこの確認が省かれます。
実測では、claude -p --worktree with-include がこの規則どおりに作業場所とブランチを作りました。git worktree list には、Claudeのセッションによるロックが表示されました。その後、ログインしていないという表示が出て終了コード1で終わり、モデルからの回答はありませんでした。コミットが1つもないリポジトリでは、Failed to resolve base branch "HEAD" と表示され、worktreeを作る前に失敗しました。対話起動、終了時の後片付け、2つのモデルを実際に並列で動かす作業は検証していません。
基にするブランチ
公式仕様では、worktreeは既定でリモートの既定ブランチ(通常は main)から作られます。リモートがない場合や、origin/HEAD を取得できない場合は、現在のHEADから作られます。今回の検証用リポジトリにはoriginがないため、確かめられたのは現在のHEADから作る動作だけです。作業中のブランチから分岐させたい場合は、worktree.baseRef を "head" に設定します。次の例はプロジェクト設定 .claude/settings.json に書く場合の説明用です。今回の検証ではこの設定を使っていません。
{
"worktree": {
"baseRef": "head"
}
}.envやnode_modulesはコピーされるか
これらがgitignoreされた未管理のファイルなら、Gitでworktreeを作るだけではコピーされません。公式仕様では、通常のGit作成処理でClaude Codeがコピーするのは .worktreeinclude のパターンに一致し、かつgitignore対象でもあるファイルだけです。今回は無害な文字列だけを入れた local-fixture.txt で確かめました。.worktreeinclude がないとコピーされず、あるとコピーされました。秘密の .env の実際の値はコピーしていません。
.gitignore の例:
.claude/worktrees/
local-fixture.txt.worktreeinclude の例:
local-fixture.txtカスタムの WorktreeCreate hookを使う場合は、このコピー処理は適用されません。hookを使う場合の動作は今回未検証です。
パターンには必要なファイル名だけを書きます。.env を含めると、秘密値を置く場所がworktreeの数だけ増えます。node_modules は各worktreeでインストールします。ポートやデータベースも、worktreeごとに設定します。作業場所を分けても、実行権限や秘密値の分離は保証されません。
後片付けはいつ行うか
後片付けは成果をコミットして統合するか、別の場所に保存してから行います。その前に、未コミットの変更が残っていないかを確認します。基にしたブランチが main の場合は、まだ統合していないコミットも確認します。
git worktree list
git -C ../repo-codex status --short
git -C ../repo-codex diff
git log --oneline main..codex-task公式仕様では、対話セッションを終了するとき、Claudeがworktree内の変更や新しいコミットを調べます。変更がない場合は自動で削除することがあり、変更がある場合は残すか削除するかを尋ねます。今回は検証していません。公式資料では、-p に終了時の確認はなく、worktreeと作成時のロックが残るとされています。ロックは後のstale-lock sweepで解放されることがあります。今回の実行でも、ロックが残っていることを確認しました。削除の手順は公式資料に従ってください。
FAQ
同じフォルダでブランチを切り替えると、他のセッションにも影響しますか?
はい、影響します。1つの作業ディレクトリのHEADとファイルは、そこで動くすべてのセッションに共通だからです。worktreeを分けるとHEADとファイルは分かれますが、ブランチとコミットは共有されます。
ClaudeとCodexの編集はぶつかりますか?
別々のworktreeで作業していれば、片方の編集はもう片方の作業ディレクトリに現れません(Gitでの実測)。統合するときのコンフリクトは起こりえます。2つのモデルを同時に実行した場合の動作は検証していません。
claude -wは何を作りますか?
.claude/worktrees/<name>/ の作業場所と、worktree-<name> ブランチを作ります。今回の -p での実行でも作成を確認しましたが、ログインしていなかったため終了コード1で終わりました。
.envやnode_modulesはコピーされますか?
gitignoreされた未管理のファイルなら、Gitでworktreeを作るだけではコピーされません。通常のGit作成処理でClaude Codeは、.worktreeinclude に一致し、かつgitignore対象でもあるファイルだけをコピーします。node_modules は各worktreeでインストールします。
後片付けはいつ行いますか?
成果を統合するか、保存してから行います。その前に git worktree list、status、diff で残っている作業を確認します。-p は終了時にworktreeを片付けず、今回も終了直後はロックが残りました。
よくある質問
- Q. 同じフォルダでブランチを切り替えると、他のセッションにも影響しますか?
- はい、影響します。1つの作業ディレクトリのHEADとファイルは、そこで動くすべてのセッションに共通だからです。worktreeを分けるとHEADとファイルは分かれますが、ブランチとコミットは共有されます。
- Q. ClaudeとCodexの編集はぶつかりますか?
- 別々のworktreeで作業していれば、片方の編集はもう片方の作業ディレクトリに現れません(Gitでの実測)。統合するときのコンフリクトは起こりえます。2つのモデルを同時に実行した場合の動作は検証していません。
- Q. claude -wは何を作りますか?
- `.claude/worktrees/<name>/` の作業場所と、`worktree-<name>` ブランチを作ります。今回の `-p` での実行でも作成を確認しましたが、ログインしていなかったため終了コード1で終わりました。
- Q. .envやnode_modulesはコピーされますか?
- gitignoreされた未管理のファイルなら、Gitでworktreeを作るだけではコピーされません。通常のGit作成処理でClaude Codeは、`.worktreeinclude` に一致し、かつgitignore対象でもあるファイルだけをコピーします。`node_modules` は各worktreeでインストールします。
- Q. 後片付けはいつ行いますか?
- 成果を統合するか、保存してから行います。その前に `git worktree list`、`status`、`diff` で残っている作業を確認します。`-p` は終了時にworktreeを片付けず、今回も終了直後はロックが残りました。