Git Worktreeでコーディングエージェントを並列化する | ブログ

この記事では、AIコーディングエージェントを使った開発を並列化する4つのアプローチを整理したうえで、なかでも扱いやすい git worktree による並列開発の具体的な進め方と、運用してみて気をつけたいポイントをまとめます。

やりたいこと・前提

AIDD（AI駆動開発）が進むと、コードを書く主体は人間からコーディングエージェントへと移っていきます。これまでの開発では「1人につき1つの実装」が基本でしたが、実装そのものをエージェントに任せられるようになったことで、この制約は薄れつつあります。1人が複数のセッションを同時に走らせ、人間はそれぞれの進行を管理する役割へと変わっていく、というのがここでの前提です。

並列実行の4つのアプローチ

コーディングエージェントを並列に走らせる方法は、大きく4つに整理できます。

複数ターミナル：ターミナルのタブやウィンドウを増やし、それぞれで別々のセッションを起動する
tmux 等でのペイン分割：1画面を分割し、複数セッションをまとめて操作する
複数チェックアウト：同じリポジトリを複数の場所にクローンし、それぞれで作業する
git worktree：1つのリポジトリから作業ツリーだけを分離し、履歴を共有したまま並列に作業する

1と2は手軽に始められますが、並列数が増えるとどのセッションが何をしているか把握しづらくなりがちです。3の複数チェックアウトはブランチ間の衝突を避けられる一方、リポジトリを丸ごと複製するためディスクを圧迫します。

これらに対し4の git worktree は、履歴（オブジェクト）を共有しながら作業ツリーだけを分離できるため、軽量かつ安全に並列作業を進められます。以降ではこの git worktree を使った並列開発を掘り下げます。

git worktreeのメリット

軽量・低ディスク消費：履歴オブジェクトを共有し、作業ツリーだけを分離するため、リポジトリを丸ごと複製するより省スペースです
ビルド成果物が混在しない：node_modules やビルド生成物がツリーごとに独立するため、ブランチ間で汚染が起きません
安全に試行錯誤できる：実装がうまくいかなければ、そのツリーごと捨てるだけで済みます
コンテキストが混線しない：ツリーごとに独立したコーディングエージェントのセッションを持てるため、会話の文脈が別ブランチの内容と混ざりません
レビュー中ブランチと新規実装の並行が可能：レビュー待ちのブランチに触れずに、別ツリーで次の実装を進められます

運用：worktree作成からセッション起動までを1操作に

worktree を使った並列開発では、①作業ツリーの作成 → ②そのツリー用にエディタのウィンドウを新規に開く → ③コーディングエージェントのセッションを起動する、という3ステップを毎回繰り返すことになります。この流れは定型化しやすいため、社内では「worktree を作ってセッションを立ち上げる」操作をスキルとして用意し、1回の指示で①〜③までをまとめて実行できるようにしています。

並列実行の使いどころ

worktree による並列実行が活きる典型的なケースは、次の3つです。

複数PRDの同時実装：2つの機能を並行して実装する
役割ごとのセッション分離：実装・レビュー・テスト・ドキュメント作成などを、それぞれ専門のエージェントに担当させる
長時間タスクの隔離：時間のかかるタスクを他の作業から切り離して走らせる

並列度が上がれば、これまで1人が1機能ずつ着手していたところを、2機能・4機能と同時に着手できるようになる可能性があります。スクラムに例えるなら、1人が同時に複数チケットを消化していくようなイメージです。

並列実行時のワークフロー：プランを固めてから実装する

並列にセッションを走らせるほど、実装後にまとめてレビューし直すコストは大きくなります。そこで有効なのが、実装前のプランニングに時間をかけるやり方です。

実装計画（プラン）を作成する
別の視点を持つサブエージェントにプランをレビューさせる
納得がいくまで1・2を繰り返し、プランを固める
プランが固まってから実装に入る

このループを回すことで、並列実行中に人間が都度レビューしなくても済む範囲を広げられます。人間の判断が必要になるのは、主に難易度の高い箇所の見極めに絞られていきます。

ハマったポイント・注意点

コストは並列度に比例して増える

並列にセッションを走らせる分だけ、トークンの消費量も増えます。安価なモデルで下書き・叩き台を作ってから本実装に移る、プランの精度を上げて手戻りを減らす、といったコストを意識した開発プロセスの設計が必要です。

セッションが行方不明になったら

複数ターミナルで作業していると、どのタブでどのセッションを動かしていたか分からなくなることがあります。Claude Code には会話を再開する仕組みが用意されており、claude --continue（短縮形 -c）でカレントディレクトリの直近のセッションに自動で戻れます。特定のセッションを選び直したい場合は、claude --resume（短縮形 -r）でセッション一覧のピッカーから選択できます。

プランの質がそのまま実装の質になる

プランを作る人と実装する人を分けるワークフローでは、プランが不完全だとその不完全さがそのまま実装に持ち込まれてしまいます。プランを渡す側は、レビューを重ねて固めたと言える状態まで作り込むことが前提になります。

プラン主導ワークフローが広げる可能性

プランを固める役割と実装する役割を分けられると、実装経験の浅いメンバーであっても、経験者が作り込んだプランをもとに実装を進められるようになります。特に新しく加わったメンバーのオンボーディングでは、質の高いプランを渡すことで、立ち上がりの速度と実装の質を両立できる可能性があります。

もちろん、経験豊富なメンバーに対してまでプラン作成を分離すべきかはチームやタスクの状況次第です。それでも「プランを作って渡す」という選択肢を持っておくことは、並列実行の体制を組むうえで有効なカードになりそうです。

まとめ

コーディングエージェントの並列実行には、複数ターミナル・tmux・複数チェックアウト・git worktreeの4つのアプローチがある
git worktreeは履歴を共有しつつ作業ツリーだけを分離できるため、軽量・安全に並列作業を進められる
worktreeの作成からセッション起動までを1つの操作にまとめておくと、並列実行のハードルを下げられる
並列実行を活かすには、実装前にプランを固めるワークフローと組み合わせるのが効果的
コストは並列度に比例して増えるため、モデル選択やプラン精度でコントロールする意識が欠かせない

並列実行できるセッション数が増えるほど、1人あたりが同時に進められる実装の幅は広がっていきます。社内でも運用方法のアップデートを続けており、今後もナレッジを発信していく予定です。