Codexへ「この修正も、調査も、テストも全部やって」と1つの大きな依頼を渡すより、独立した仕事を複数エージェントへ分けた方が速く進む場面があります。ただし、同じファイルを同時に触らせると統合コストが増えます。Codexでは、独立したチャットをworktreeで分離して並列に進める方法と、1つの作業からsubagentを分岐させる方法があります。まずはこの2つを分けて考えるのがポイントです。
まず結論：独立作業はworktree、分業調査はsubagent
| 方式 | 向いている仕事 | 分離の考え方 |
|---|---|---|
| 複数チャット + worktree | 別機能、別Issue、独立した修正案 | Git checkoutを分離して変更衝突を減らす |
| subagent | 調査、レビュー、コード探索、並行する小タスク | 親Agentが専門Agentへ仕事を分け、結果を集約する |
Codexアプリでは複数エージェントを別スレッドで並行実行でき、worktreeを使うと同じRepositoryでも各チャットが独立したcheckoutで作業できます。一方、subagentは親の仕事の中から専門的な役割を切り出す仕組みです。
用語解説：Git worktree
1つのGit Repositoryから複数の作業ツリーを持てる仕組みです。Codexでは並列チャットを別worktreeへ置くことで、各Agentが同じ作業ディレクトリを直接書き換える状況を避けられます。
並列化しやすい仕事を先に切り出す
並列化の効果は、Agent数よりタスクの独立性で決まります。依存関係が少ない仕事ほど同時に進めやすく、最後の統合も小さくなります。
| 並列化しやすい | 並列化しにくい |
|---|---|
| frontendとbackendで担当ファイルが分かれている | 同じコンポーネントを2Agentが同時修正 |
| 調査と実装を分ける | 調査結果が出ないと実装方針を決められない |
| 実装と独立したテスト追加 | 実装途中のAPI仕様をテスト側が推測する |
| 複数の代替案を別worktreeで試す | 1つのmigrationを同時に書き換える |
- 各Agentの完了条件を1つに絞る
- 担当ディレクトリやファイル境界を明記する
- 共有インターフェースを変更するAgentを1つに決める
- 他Agentの未完了変更を前提にしない仕事から並行化する
同じRepoならworktreeで変更を分離する
Codexのworktreeは、複数の独立したチャットを同じGit Projectで干渉させずに進めるための仕組みです。各チャットは別checkoutで動くため、ローカルの作業状態を直接上書きせずに別機能や別案を試せます。
- 新しいCodexチャットでWorktreeを選ぶ
- 基準にするbranchを選ぶ
- Agentごとに独立したタスクを依頼する
- 各threadのdiffを確認する
- 必要な変更だけbranch化・Handoff・PRなどで統合する
worktreeを使っても、論理的な競合が消えるわけではありません。2つのAgentが同じAPI契約を別々に変更すれば、Git上は分離されていても最終統合時に設計判断が必要です。
subagentは役割を狭くすると機能する
現在のCodexではsubagentワークフローが標準で有効になっており、必要に応じて専門Agentを並列に動かせます。公式ドキュメントでも、custom agentは狭く明確な役割と、その仕事に合ったツール面を持たせることが推奨されています。
| 役割例 | 担当 |
|---|---|
| code_mapper | 対象機能の入口、状態遷移、関連ファイルを読み取り専用で特定 |
| reviewer | 正しさ、セキュリティ、テスト不足をレビュー |
| docs_researcher | フレームワークやAPIの一次情報を確認 |
| implementer | 調査結果を受けて最小変更を実装 |
「全員が何でもできるAgent」にすると作業が重複しやすくなります。読むAgent、判断するAgent、書くAgentのように責任を分ける方が結果を比較しやすくなります。
同時実行数は設定できる
Codexのsubagent設定は`[agents]`で管理できます。現在の公式仕様ではmulti-agent toolsはデフォルトで有効で、同時に開けるsubagent thread数は`agents.max_concurrent_threads_per_session`で上限を設定できます。
[agents]
enabled = true
max_concurrent_threads_per_session = 4上限を大きくすれば常に速くなるわけではありません。各subagentはそれぞれモデル・ツール処理を行うため、トークン消費も増えます。最初は独立性の高い2〜4タスク程度に分け、統合コストを確認しながら増やす方が管理しやすいです。
レビュー役を最後に1つ置く
並列Agentの成果をそのまま全部mergeするのではなく、最終的な整合性を確認する担当を1つ決めます。Codexアプリでは各threadの変更をdiffで確認し、コメントや手動修正もできます。
- 重複実装がないか
- 共有型・API・DB schemaの前提が一致しているか
- 同じテストを別々の意図で変更していないか
- 一方の変更で他方の前提が壊れていないか
- 各Agentのテスト結果だけでなく統合後テストも通るか
役割としては「最終reviewer」または親Agentを統合責任者にすると、誰が最終判断するかが曖昧になりにくくなります。
並列化しない方がよいケース
- 要件がまだ曖昧で、全Agentが別の前提を持ちそうなとき
- 1つの小さな関数や設定ファイルだけを修正するとき
- migrationや認証基盤など、変更順序が強く依存するとき
- 最初の調査結果で後続タスクの内容が大きく変わるとき
- 統合テスト環境が1つしかなく、並列成果を独立検証できないとき
こうした仕事では、先に1Agentで問題を理解し、タスク境界が見えた後で分業する方が安全です。マルチエージェントは人数を増やす機能ではなく、依存関係を切れる仕事を同時に進めるための設計として使います。
Codex自体の使い分けも整理したい場合
（CodexとCopilotの役割差から整理したい場合については『CopilotとCodexの違いと使い分け10選｜VS Codeで効率化するAI開発ガイド』をご参照ください）
まとめ：分離・責任・統合の3点で設計する
- 独立した実装タスクはworktreeで作業環境を分離する
- 調査・レビュー・探索などはsubagentへ専門分担させる
- 同じファイルや同じ設計判断を複数Agentへ重複して持たせない
- subagentの同時thread数は設定できるが、多いほど良いわけではない
- 最後に1つのreviewer/親Agentで統合後の整合性とテストを確認する
最初は、コード探索・実装・レビューの3役に分けて試してください。担当範囲と完了条件を明確にしてから並列化すると、Agent数を増やすより効果を確認しやすくなります。
