# 小規模チームのマルチエージェント開発ワークフロー：Worktree、役割、レビュー門番

> 複数の coding agent は、責任範囲、作業場所、handoff、review 余力が明確なときだけ効きます。まず実装 agent と検証 agent の二段構えから始めます。

- URL: https://blog.laozhang.ai/ja/posts/multi-agent-coding-workflow-small-team
- Published: 2026-05-24
- Updated: 2026-05-24
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ja/about)
- Topic: 開発ツールとエージェント
- Tags: AI コーディングエージェント, マルチエージェント, Codex, Claude Code, Git Worktree

---
複数の coding agent を使うのは、次の変更が独立した範囲に分かれ、契約が安定し、作業場所が隔離され、チームに review 余力があるときだけです。二つの agent が同じファイルを必要とする、インターフェースがまだ動いている、複数の diff を人間が確認できない。そういう状態なら、単一 agent で順番に進めた方が早く安全です。

小規模チームの安全な初期形は、自律的な agent swarm ではありません。人間の lead、隔離された実装 agent、検証 agent から始めます。各タスクには owner、worktree または branch、allowed files、forbidden files、handoff、検証コマンド、merge gate が必要です。

| ルート | 使う場面 | 最低限の門番 |
| --- | --- | --- |
| 単一 agent | ファイルが重なる、契約が動く、review 余力が少ない | 一つの diff を人間が確認 |
| 二段構え | 一つが実装し、もう一つが同じファイルを触らず検証 | handoff とテスト証拠 |
| 三分割 | 二つの範囲が安定した契約でつながる | インターフェース owner と順次 merge |
| agent team | 独立流が多く reviewer が追いつく | ownership、CI、merge queue、stop rule |

まずルートボード、task brief、worktree、handoff、検証ゲート、merge 順序、review-hour 指標を通します。agent 数を増やすのは、その最小形が review しやすい成果を出したあとです。

## agent 数より先にルートを決める

マルチエージェント開発が効くのは、作業の所有権を分けられるときです。「frontend agent と backend agent」を同時に走らせても、API を同時に決めているなら安全な分担ではありません。「bug 修正」と「テスト追加」も、テスト側が修正内容を推測しなければならないなら独立検証ではありません。

![小規模チーム向けのルートボード](https://blog.laozhang.ai/posts/ja/multi-agent-coding-workflow-small-team/img/cover.webp)

小規模チームは四つのルートを見ます。単一 agent は密結合の bug、migration、security、repo-wide refactor に向きます。二段構えは実装者と検証者を分けます。三分割は API などの契約が固定された後に使います。agent team は強い CI、merge queue、review 余力があるときだけです。

| ルート | チーム形 | 最初の仕事 | stop signal |
| --- | --- | --- | --- |
| 単一 agent | 一人が一つの agent を監督 | 狭い bugfix、hot file、動く refactor | 同じファイルで何度も軌道修正が必要 |
| 二段構え | lead、実装 agent、検証 agent | scoped change と独立検証 | 検証者が diff を説明できない |
| 三分割 | lead と二つの独立実装 | API 固定後の frontend/backend | agent が interface shape で争う |
| agent team | lead、specialist、verifier | 多数の独立流 | review queue が accepted work より速く伸びる |

ルートは一週間の中で変えて構いません。最初は二段構えで、review しやすい diff が出るか測ります。ownership が見えない段階で agent を増やすと、成果より調整負荷が先に増えます。

## 複数 agent が本当に効く条件

相性がよいのは、境界が見える横展開の仕事です。一つの agent が UI state を実装し、別の agent が integration test を書く。一つが failing path を調査し、別の agent が regression coverage を確認する。shared type や API contract が固定された後で、二つの module を別々に直す。どの例でも agent は相手の未完成コードを待たずに完了できます。

五つの条件を同時に満たしてください。scope が一、二個の fileset で説明できる。shared contract が渡せる程度に安定している。agent ごとに branch または worktree がある。人間が chat transcript ではなく diff と証拠を見られる。CI と reviewer が順次 merge に耐えられる。

最後の条件が小規模チームの落とし穴です。二つの agent は一人の reviewer より速くコードを生成できます。lead が一日中 conflict resolver になるなら、それは高速化ではなく bottleneck の移動です。

## 単一 agent に戻すべき場面

密結合の作業は単一 agent が向いています。database migration、auth middleware、billing flow、public API、weak tests、dependency update、全体 rename、security-sensitive edit は一つの制御線に置きます。ここでは並列よりも、判断の一貫性が重要です。

実用的な stop rule は明快です。ある agent が別 agent の unfinished code を待たないと次を判断できないなら、並列にしません。lead が contract を書き、一つの agent が最初の diff を作り、verifier または人間が確認し、次の agent は更新後の main から始めます。

小規模チームでは、この順番の方が早く終わることがよくあります。後続の作業には実在する base があり、推測した interface が残りません。review 面も狭く、rollback も安く済みます。

## 初日に動かす workflow

一週間目から全工程を変えないでください。低リスク issue を一つ選びます。human lead が issue brief を書いてルートを選ぶ。実装 agent は個別 branch または worktree で作業する。検証 agent は brief、changed files、handoff だけを読む。human reviewer は semantic diff と merge risk を確認する。main には一度に一つだけ merge する。残った worktree は続行前に main を取り込みます。

全 backlog を agent に渡すのは避けます。各 agent には、終わらせ、説明し、返せる仕事だけを渡します。成果物は branch と written artifact であり、由来の分からない編集の集合ではありません。

最初の運用票には、なぜこのタスクが separable なのか、誰が shared contract を owns するのか、禁止ファイルは何か、検証コマンドは何か、失敗したら誰に戻すのか、merge の順序はどうするのかを書きます。これが書けないなら、まだ並列化の準備ができていません。

## overlap を止める task brief

task brief は workflow の中心です。二つの agent が別々の問題を解かないようにし、reviewer が会話履歴を掘らずに contract を確認できるようにします。

~~~md
Agent Task Brief

owner: agent-a
workspace: ../agent-a
branch: agent/a-checkout-state
goal: 注文サマリーに checkout state を追加する。
non_goals:
- payment provider code を変更しない。
- database schema を変更しない。
allowed_files:
- src/features/checkout/**
- tests/checkout/**
forbidden_files:
- src/lib/payments/**
- db/migrations/**
- package-lock.json
interface_contract:
- 既存の OrderStatus を使う。
- 新しい status が必要なら停止して human lead に確認する。
shared_state:
- local database migration はしない。
- test fixtures だけを使う。
required_checks:
- pnpm lint
- pnpm test tests/checkout
handoff_required:
- changed files
- commands run
- proof or failing output
- known risks
- review focus
done_means:
- verifier が checks を再現し diff を説明できる。
~~~

forbidden files は事務処理ではありません。schema、route map、lock file、env、public API、shared configuration を守るための boundary です。禁止範囲を書けないタスクは、並列化するには広すぎます。

![task brief と handoff のボード](https://blog.laozhang.ai/posts/ja/multi-agent-coding-workflow-small-team/img/task-brief-handoff.webp)

## worktree または branch で隔離する

Git worktree は同じ repository に複数の working tree を持たせます。一つの agent がテストを走らせてファイルを変更しても、別の agent の checkout を汚しません。公式ドキュメントは仕組みを説明していますが、小規模チームで重要なのは、どの directory、どの branch、どの command、どの merge plan かです。

~~~bash
git switch main
git pull --ff-only
git worktree add ../agent-a -b agent/a-checkout-state
git worktree add ../agent-b -b agent/b-profile-copy
git worktree add ../verify -b verify/checkout-state
git worktree list
~~~

worktree は source files を隔離しますが、すべての状態を隔離しません。database、ports、local services、secrets、package lock、CI runners、feature flags、public contracts は single owner を決めます。

| 共有リソース | ownership rule |
| --- | --- |
| schema と migrations | 一人の human owner、並列編集なし |
| ports と local services | brief で予約 |
| secrets と env files | approval なしでは read-only |
| package lock と dependencies | 一つの branch が dependency change を owns |
| CI queue | 容量が少ないなら一つずつ merge |
| public API と feature flags | contract を freeze してから並列化 |

worktree が使えないなら、clean checkout や branch でも構いません。必要なのは workspace boundary と merge plan です。

![worktree ownership map](https://blog.laozhang.ai/posts/ja/multi-agent-coding-workflow-small-team/img/worktree-ownership-map.webp)

## handoff はチャット外で残す

chat summary は handoff ではありません。verifier と reviewer には、pull request、issue comment、または branch 内の短い handoff.md として残る artifact が必要です。changed files、commands、proof、risks、review focus を書きます。

~~~md
Agent Handoff

task: checkout state in order summary
owner: agent-a
branch: agent/a-checkout-state
changed_files:
- src/features/checkout/OrderSummary.tsx
- tests/checkout/order-summary.test.ts
commands_run:
- pnpm lint
- pnpm test tests/checkout
proof:
- checkout tests pass locally
known_risks:
- empty order state still uses existing fallback copy
review_focus:
- confirm OrderStatus mapping is complete
next_owner:
- verifier
~~~

verifier はデフォルトでは実装を続けません。まず brief が守られたかを確認します。allowed files、tests、interface contract、proof、risks。verifier が同じ feature files を書き直すなら、最初の task brief が粗かったという signal です。

## 役割は負荷を下げるときだけ増やす

小規模チームに大きな role taxonomy は不要です。human lead、implementer、verifier、human reviewer から始めます。specialist は docs、tests、migration、investigation など独立した流れがあるときだけ追加します。

| 役割 | 仕事 | 追加する時 | 外す時 |
| --- | --- | --- | --- |
| human lead | scope、contract、merge order、risk | 常に必要 | 完全には外さない |
| implementer | scoped diff | brief に allowed と forbidden files がある | タスクが境界を越え続ける |
| verifier | tests、review、challenge | output が separable | 同じ diff を書き直す |
| reviewer | semantic review と merge decision | production code が出る時 | skip しない |
| specialist | docs、tests、migration、investigation | independent stream がある | handoff cost が高い |

lead は全ての行を書く必要はありませんが、contract を owns します。人間が contract を owns しない場合、agent はそれぞれ別の contract を作り、後で conflict になります。

## 検証ゲートと merge queue

parallel work は merge queue に入って初めて product work になります。branch は順番に merge し、checks を再実行し、残りの worktree を更新します。半完成の branch を同時に main へ押し込まないでください。

~~~bash
git switch main
git pull --ff-only
git merge --no-ff agent/a-checkout-state
pnpm lint
pnpm test
git push

cd ../agent-b
git fetch origin
git rebase origin/main
~~~

verification gate は五つを確認します。diff が allowed files だけを変えている。required checks が記録されている。interface contract が壊れていない。handoff が risks と review focus を示している。人間が semantic change を理解している。AI review は補助になりますが、semantics、security、data handling、merge responsibility は人間が持ちます。

![検証ゲートと merge queue](https://blog.laozhang.ai/posts/ja/multi-agent-coding-workflow-small-team/img/verification-merge-gate.webp)

## Codex、Claude Code、Cursor、framework の位置

workflow の shape を決めてから tool を選びます。Codex は reviewable diffs、CLI、IDE、cloud tasks、PR-oriented flow に向きます。Claude Code は supervised local sessions、複雑な context、細かい permission rules に向きます。Cursor background agents、worktree wrappers、orchestration frameworks は同じ process を実装する surface です。

Codex と Claude Code の選択が主題なら、別の [Claude Code vs Codex](https://blog.laozhang.ai/ja/posts/claude-code-vs-codex) を見ます。Codex の usage や quota が問題なら [OpenAI Codex usage limits](https://blog.laozhang.ai/ja/posts/openai-codex-usage-limits) を見ます。この workflow の主人は brand ではなく、brief、workspace isolation、handoff、diff、verification、human merge です。

良い tool は brief を残し、workspace を分け、diff を見せ、proof を記録し、reviewer が merge を止められます。これができない tool は、小規模チームにとって危険な並列化を増やします。

## agent 数ではなく review hour で測る

agent 数は弱い指標です。commit 数も弱い指標です。大きな diff は作れても、reviewer が怖くて merge できないなら意味がありません。小規模チームでは accepted diff per review hour を見ます。

| 指標 | 意味 | stop threshold |
| --- | --- | --- |
| accepted diff per review hour | 最も希少な review 時間に対する成果 | single-agent baseline 未満 |
| rework rate | agent が contract を推測していないか | 一タスク一回以上の大幅手戻り |
| CI failure rate | parallel branch の安定性 | 同じ理由で失敗が繰り返される |
| merge conflict minutes | hidden overlap の検出 | 同じファイルで競合が続く |
| cost per accepted change | token や plan cost と結果の接続 | cost だけ上がり accepted work が横ばい |

標準化する前に二、三個の issue で試します。単一 agent の良い baseline と比べます。二段構えが cleaner tests、faster review、more accepted work per lead hour を出すなら残します。coordination cost が上なら縮めます。

## 一週間の導入計画

Day 1 は low-risk issue と一つの implementer branch。Day 2 は verifier を追加するが implementation edits はさせない。Day 3 は sequential merge と review minutes の記録。Day 4 は stable contract の時だけ二人目の implementer。Day 5 は accepted work、rework、conflicts、CI、review time を比較します。

| 日 | 動作 | output |
| --- | --- | --- |
| Day 1 | low-risk issue を選ぶ | task brief と一つの branch |
| Day 2 | verifier を追加 | handoff と verification notes |
| Day 3 | sequential merge | merge queue baseline |
| Day 4 | 二つ目の independent implementer | 二つの isolated branches |
| Day 5 | 成果と衝突を比較 | keep、shrink、stop |

目的は agent team の迫力を示すことではありません。小規模チームが少ない lead time と少ない rework で reviewable code を ship できる最小 process を見つけることです。

## よくある質問

### 最小の安全な workflow は何ですか？

human lead、one implementer agent、one verifier agent です。implementer は isolated workspace で scoped diff を作り、verifier は brief、tests、allowed files、risks を確認し、human reviewer が merge します。

### 二人チームでも複数 agent を使うべきですか？

separable work なら使えます。ただし大きな agent team ではなく two-agent pipeline からです。lead が diff と handoff を読む時間を持てることが条件です。

### Git worktree は必須ですか？

必須ではありません。worktree は強い default ですが、clean checkout や separate branch でも動きます。本当の要件は workspace isolation と merge plan です。

### single-owner にすべきファイルは？

schemas、migrations、package locks、env files、auth middleware、feature flags、public API contracts、shared route maps は single owner にします。例外は human lead が contract を変えた時だけです。

### AI review は human review を置き換えますか？

置き換えません。AI review は syntax、tests、style、consistency を助けます。semantics、product risk、security、data handling、merge responsibility は人間が持ちます。

### いつ複数 agent を止めますか？

同じ files が必要、interface が動く、reviewer が追いつかない、CI が同じ理由で落ちる、accepted diff per review hour が single-agent baseline を下回る時です。

### Codex と Claude Code はどこで使いますか？

Codex、Claude Code、Cursor、worktree wrappers、orchestration frameworks は同じ workflow の実装 surface です。brief、workspace、diff、proof、review gate を保てるものを選びます。

### 小規模チームはいくつ agent を同時に走らせますか？

まず one implementer plus one verifier を証明します。三つの agent は scopes が independent の時だけです。大きな agent team には ownership、CI、merge queue、review capacity が必要です。