AIタスクは並列で回せ：Git Worktree × Agent Teams

AI アシスタントは非常に便利ですが、使い方によっては意外と「遅く」感じることがあります。

応答そのものが遅いわけではなく、単に使い方の問題です。

例えば、複数の機能を実装する必要があるとします。一般的な流れは以下のようなものです。

作業を整理 → タスクを AI に説明 → 完了を待つ → 結果をレビュー → フィードバック → 次の機能へ

タスク同士が完全に独立していても、結局は順番に処理してしまいます。

つまり、かなりの時間を「待つこと」に費やしていることになります。

そこで疑問に思いました。なぜ私は一度に一つのタスクしか実行していないのだろうか？

もし Feature A と Feature B が互いに依存していないのであれば、片方が終わるのを待つ必要はありません。

つまり、

Feature A → 待つ → Feature B → 待つ → Feature C

ではなく、

すべて同時に実行できるはずです。

このアイデアの本質は、AI を高速化することではなく、「単一タスクにブロックされる状態」をなくすことです。

Agent Teams とは

Agent Teams は、Anthropic が Opus 4.6 とともにリリースした機能で、複数のエージェントが協調して複雑な問題に取り組むためのものです。基本的には、エージェント同士でやり取りしたり、コンテキストを共有しながら、アプリケーションの複数レイヤーにまたがる変更を進めるようなケースで使われます。

ただ、この記事では少し違った使い方をしています。複数の独立したタスクを、1 つのセッションからまとめて動かすための仕組みとして使っています。

Git Worktree の出番

タスクを並列で進めると、すぐに問題が出てきます。複数のエージェントが同じブランチで同時に作業すると、変更がぶつかったりファイルが上書きされたりして、どの変更がどのタスクのものなのか分かりづらくなります。従来のブランチ運用もこのやり方にはあまり向いておらず、同じ作業環境で動くことで、お互いの変更に干渉してしまいます。

ここで役に立つのが git worktree です。

git worktree を使うと、同じリポジトリを共有しながら、複数の作業ディレクトリを持つことができます。それぞれ異なるブランチにチェックアウトされるため、Feature A、Feature B、Feature C を同時に開いて作業できます。

git worktree add .worktrees/feature-a -b feature-a
git worktree add .worktrees/feature-b -b feature-b

これにより：

• .worktrees/feature-a → Feature A
• .worktrees/feature-b → Feature B

それぞれ完全に分離された状態になります。

その結果、複数の AI タスクを安全に並列実行できるようになります。

.worktrees/

Agent Teams — 真価を発揮する部分

タスクを並列実行する最もシンプルな方法は、AI セッションを複数立ち上げることです。

Agent Teams はこのワークフローを簡略化する機能です。1 つの Claude セッションが複数のセッションを起動し、それぞれにタスクを割り当てて管理します。いわば「チームリーダー」が「メンバー」に作業を割り振るイメージです。

実際には、1 つのプロンプトで複数の機能を定義すると、Claude がそれらを分割して並列で処理します。

公式ドキュメントでは、以下のような役割ベースの使い方も紹介されています：

• UX を担当するエージェント
• 技術設計を担当するエージェント
• 問題点を指摘するエージェント

このような構成では、エージェントがそれぞれ異なる視点から同じ課題に取り組み、最終的にチームリードが全体をまとめて結果を出します。例えば、UI のコンポーネントを更新しつつ、API を調整し、さらにデータベースや他のバックエンド側にも変更を加えるような、複数レイヤーにまたがる機能開発がイメージしやすいと思います。

ただし本記事では、よりシンプルな使い方を紹介します。

各エージェントが 1 つの機能を担当し、完全に独立して並列実行します。

各エージェントは個別に設定でき、使用するモデルも指定可能です。作業が終わると、チームリーダーが結果をまとめて返します。

実際には、1 つのプロンプトの中で各機能を個別のタスクとして定義し、それをチームリードに割り振らせる形になります。各エージェントはそれぞれ割り当てられた機能を独立して進めるため、エージェント同士でやり取りする必要はありません。この構成では、チームという仕組みはエージェント同士の連携というよりも、複数のタスクを 1 か所からまとめて起動・管理するための手段として機能しています。

全体の流れ

Agent Teams と git worktree を組み合わせると、ワークフローは次のようになります：

• Claude を起動
• プロンプトを記述
• チームを構築
• Feature A を定義
• Feature B を定義
• コーヒーを取りに行く
• 並列で処理されるのを待つ
• 結果をレビューしてマージ

重要なのは、「1 つずつ待つ」のではなく、「まとめて待つ」点です。

プロンプト例

以下は簡略化した例です：

Create a team with two teammates to work on the following features in parallel.
Each feature must be implemented in its own git worktree under .worktrees/.
Feature A: WebSocket handshake in Go
...

이 방법은, 작업이 독립적인 경우에 특히 효과를 발휘합니다. 반대로 공통 부분이 많은 경우에는, 복잡성이 merge 과정으로만 이릅니다.

하지만, 동일한 컨텍스트에서 생성된 코드라면, Claude 는 충돌의 해소도 잘 해줄 것이라는 인상을 줍니다.

기타 활용 사례

PR 리뷰에도 응용할 수 있습니다.

예를 들어:

• 보안 관점
• UX 관점
• 테스트 커버리지

각각 다른 에이전트에 할당할 수 있습니다. 하지만, 이 용도는 약간 과잉 엔지니어링 기운이 있고, 토큰 소비도 늘어날 가능성이 큽니다.

세션 관리

터미널 중심의 개발 스타일이라면, 세션マネ저의 이용을 추천합니다. 저자는 tmux 를 사용하지만, 터미널 탭에서도 문제가 없습니다.

중요한 것은, 각 에이전트에 독립적인 쉼터를 주고, 출력을 확인하면서 직접 조작할 수 있는 것입니다.

비용 및 기타 제약

"토큰 엄청나게 쓸 것 같네"라고 생각했을 수도 있습니다. 실제로 그通り입니다.

토큰을 억제하는 데 가장 효과적인 것은, 에이전트별 모델 선택입니다. 모든 작업에 고성능 모델을 사용하는 것은 필요 없습니다. 복잡한 작업에서는 Opus 를 쓰는 것도アリ이지만, 그분 토큰은 상당히 소비합니다. 실제로, 수 분 만에 1 세션분을 모두 써버린 경우도 있었습니다.

평범에는 경량인 Sonnet 을 기반으로 하고, 제대로 생각하게 해야 할 곳만 무거운 모델을 사용하는, 이런 사용법이 잘 맞습니다.

아직 이 오버헤드를 어떻게 줄이는지는 시행착오 중입니다. 몇 가지 명확한 포인트로는, 작업별 스코프를 최대한 작게 하는 것이나, 첫 번째 프롬프트를 조금 더 구체적으로 만들어, 에이전트가 저장소를 무용하게 탐색하지 않도록 하는 것이 있습니다.

또한, 작업이 너무 작다면,そもそも 여러 에이전트를 시작하는 비용이 더 커져버릴 수도 있습니다.

또한, 인지 부하도 늘어납니다.

병렬 처리되어도, 최종적으로 결과를 이해하는 것은 인간입니다. 작업이 늘어날수록, 정신적인 부담도 커집니다.

요약

실제로 시도해본 후 가장 크게 변한 것은, 속도보다는 작업의 진행 방식이었습니다. 하나씩 끝내지는 않고, "무엇을 병렬로 진행할 수 있는가"를 생각하기 시작했습니다.

Agent Teams 와 git worktree 를 조합함으로써, 이 방식이 현실적입니다. Agent Teams 는 여러 작업의 시작·관리를 한꺼번에 수행하고, git worktrees 는 각 작업을 분리하여 간섭을 방지합니다.

물론 단점도 있습니다. 여러 에이전트를 움직이면 토큰 소비가 늘어납니다. 병렬로 나온 결과를 통합하여 리뷰하는 것은, 하나씩 순차적으로 진행하는 것보다 부담이 커질 가능성이 큽니다.

나의 감각으로는, 이 방식은 작업이 작고, 깔끔하게 분할될 경우에 가장 효과를 발휘합니다. 잘 맞는 곳에서 사용하면, 대기 시간을 줄여 원활하게 작업을 진행할 수 있는 방법이라고 생각합니다.

복잡한 작업이나 PR 리뷰처럼, 조정과 여러 관점이 중요한 장면에서는, Agent Teams 는 계속 유효합니다. 하지만, 그분 토큰은 적잖이 소비하므로, 그 점은 각오해 두어야 합니다.