Codexのworktreeとは？並行作業を分ける使い方と変更の取り込み方

ブランチだけ切り替える場合と何が違う？

ブランチは変更履歴の進む道、worktreeはその道のファイルを実際に開く場所です。通常の一つの作業フォルダーでもブランチは切り替えられますが、別の作業を同時に開いておくには、作業フォルダーも分かれている方が扱いやすくなります。

たとえばAでは記事の見出しを直し、Bでは検索機能の不具合を直すとします。worktreeを二つ使えばAの編集中にBが同じファイルを書き換える衝突を避けられます。ただし、最後に両方を取り込む段階で同じ行を変更していれば、どちらを残すか判断が必要です。

• 出典：Codexのworktree（新しいタブ）
• 出典：Git worktree公式（新しいタブ）

新しい作業を始める前に、現在地を確認する

Codexが開いている場所がGitリポジトリか、未保存の編集や未コミットの変更があるかを確認します。コミットは、その時点の変更をGitの履歴として記録する操作です。まだコミットが一つもない空のリポジトリでは、まず作業の出発点を用意します。

Codexが管理するworktreeでは、開始時に選んだGitの状態や、アプリ側で選ぶ開始方法によって引き継ぐ内容が変わります。「いつも未コミットの編集も全部入る」と思い込まず、新しい作業で対象ファイルを開いて確認してください。

読み取りの確認には、git status --short、git branch --show-current、git worktree listが使えます。これらは変更を取り消すコマンドではありません。ブランチ名が空でも、コミットを直接見ている状態の場合があります。慌てて削除せず、Codexの作業表示と照らし合わせます。

二つに分けるのは、依頼の範囲も同じ

作業机が別でも、両方へ「サイト全体をよくして」と頼むと変更が重なりやすくなります。Aには記事ページ、Bには検索のように対象を分け、共通の設定ファイルを変える必要が出たら先に知らせてもらいます。

下の依頼例は、複数のAIを自動起動するための指示ではありません。自分で開始するそれぞれの作業に、担当範囲を伝えるための例です。

フォルダーが別でも共有されるものに注意する

worktreeが主に分けるのは、Gitで扱う作業ファイルです。どちらの開発サーバーも同じポートを使えば起動がぶつかり、同じリモートDBへ接続すればデータを一緒に変更します。この二つは、ファイルを分けただけでは解決しません。

環境変数を入れるファイルや、インストール済みの依存関係が新しい場所にない場合もあります。秘密を含むファイルを何でもコピーするのではなく、必要な設定名と接続先を確認します。開発用のDBを使い、どの作業がどこへ書き込むかを決めてから起動します。

完成したら、一つずつ取り込んで再確認する

まずAの差分を読み、Aの変更だけを取り込みます。その状態でテストしてから、Bを取り込みます。両方単独では動いても、一緒になると画面の余白が崩れるなどの不具合が出るため、最後に組み合わせた状態で確認します。

「競合」は、Gitが自動でどちらの変更を残すか決められない状態です。競合した箇所でAかBの全文を機械的に採用せず、両方の依頼で残すべき条件を見ます。迷ったら統合を止め、作業内容を並べて確認する方が戻しやすくなります。

取り込み前の試作を片づけるときも、必要な変更が残っていないか確認してからにします。worktreeのフォルダーを直接強制削除する操作を、いつもの片づけとして使うのは避けます。Codexの管理画面やGitの正式な管理操作で扱います。

並行作業を増やす前に、一回の流れを覚える

最初は二つの小さな修正で十分です。「作業先を確認→別々に変更→差分を見る→一つずつ取り込む」を一度通せば、どこで作業が混ざるか分かってきます。数を増やすほど速くなるとは限りません。

Codexでの開発全体を順番に学びたいなら、作業ルールや変更の確認も扱う入門書を候補にできます。worktreeのボタンだけを探している方は、まず上の公式手順で十分です。AGENTS.mdの書き方と合わせると、どの机でも守る共通ルールを用意できます。