Cursor 3.3 が「Parallel Agents」を正式機能として搭載した。複数のブランチに対して複数のエージェントを同時並行で走らせる、というシンプルな仕組みだ。並列実行と聞くと反射的に「速くなる」と期待してしまうが、過去2年で同種の機能には何度も裏切られてきた。今回も期待値を下げて触ったのが結果的に良かった。先に結論を言えば、たしかに速い。ただし、速くなる条件はかなり限定される。本稿ではParallel Agentsの仕様と、中規模Next.jsプロジェクトで実測した3シナリオの結果を整理する。
Parallel Agents は「Worktree内蔵の並列実行」
Cursor 3.3 のParallel Agentsは、Agents Window内で複数のエージェントを別々のブランチに割り当て、並列に作業させる仕組みだ。Worktreeがネイティブに組み込まれており、各エージェントは独立した作業ディレクトリで動く。準備が整ったブランチはワンクリックでフォアグラウンドに引き上げて、ローカルで挙動を確認できる。Multi-folder Workspacesにも対応していて、フロントエンド・バックエンド・共有ライブラリを横断する変更を1セッションで指示できるのが、従来との大きな違いだ。
3シナリオで実測：独立性で結果が割れる
中規模Next.jsプロジェクト（コミット数約2,300、ファイル413）で、以下3シナリオを各5回実行した。
シナリオA：完全独立タスク3本
- バックエンドのバリデーション追加
- フロントエンドのフォームUI改修
- READMEの英訳
平均完了時間は、単独実行3本の合計が12分44秒に対し、並列実行は4分23秒。短縮率は約66%。Parallel Agentsの「分業が成立する」場面の典型例だ。
シナリオB：半分依存タスク3本
- 共有スキーマ変更
- スキーマを参照するAPI修正
- スキーマを参照するUI修正
単独3本合計9分10秒に対し、並列実行7分38秒。短縮率は約17%。期待外れというほどではないが、爆発的でもない。スキーマ変更が完了するまで他2本が暗黙的に待つため、並列度が十分に活きない。
シナリオC：強い依存タスク3本
- 同一ファイル内の3関数を別々に修正
単独3本合計6分29秒に対し、並列実行8分04秒。並列のほうが「遅い」結果になった。マージ衝突の解消にエージェント自身が時間を使うため、人間が逐次やったほうが早かった。
「速くなる機能」ではなく「分業を可能にする機能」
実測してみて、筆者の言語化はこう変わった。Parallel Agentsは「速度を上げる機能」ではなく「分業を可能にする機能」だ、と。分業が成立する仕事──独立した3つの小タスク──には強い。分業が成立しない仕事──同じ箇所を3角度から触る──には逆効果。同じファイルに触る2本があれば、後で待ちが発生する。この原則はClaude Codeのworktree運用と同じで、Cursorだから違うということはない。
Multi-folder Workspaces は範囲を絞る
Multi-folder Workspacesは、フロント・バック・共有ライブラリの3リポを1セッションで横断できる。確かに便利だ。が、最初の1日で痛感したのは、横断範囲を広げすぎるとエージェントの「考える対象」が爆発し、応答が目に見えて鈍ることだった。筆者は現在、ワークスペースに含めるのは2リポまで、3リポ目は明示的に必要なときだけ追加する運用にしている。共有ライブラリだけ常駐させ、フロントとバックは案件に応じて切り替えるのが現実的な落としどころだ。
デフォルト「3本」というUI設計
Cursor 3.3 のUIは並列度のデフォルトを3に置いている。これはおそらく意図的で、エンジニアが頭の中で並列タスクを同時に追える本数の上限に近い。4本以上にすると、各ブランチの進捗を頭の中で追いきれず、結局1本ずつ確認する羽目になる。筆者はデフォルトの3で運用していて、迷ったら2に下げる派だ。
ワンクリックでフォアグラウンドに引き上げられるUIは確かに快適だが、「人間が確認する責務」は変わらない。レビュー負荷自体は減らず、並列度を上げるほどレビュー時間は単純に積算する。3本同時走行のセッションで、レビューだけで27分かかった日もあった。実装時間の短縮分を、レビュー時間が食ってしまう局面はそれなりにある。
チーム導入で先に詰めたい3点
並列エージェントをチームで導入する場合、少なくとも次の3点は事前に合意しておきたい。
1つ目、レビュー責任の分担。3本同時に走らせるなら、レビュアーは2人以上にしないと現実的に詰まる。
2つ目、ブランチ命名規則。並列実行が増えるとブランチ数が一気に膨らむので、自動命名のルール（例：agent/<date>/<topic>）を最初に決めておくと整理が利く。
3つ目、マージ順序の優先度。依存のあるブランチを並列で走らせた場合、マージ順を誤ると後発のブランチでコンフリクトが連鎖する。地味だが、口頭合意で済ますと後で必ず燃える論点だ。
今回の推奨アクション
- Parallel Agentsを試す前に、投げる3本のタスクが本当に独立しているかを1分でいいから紙に書き出す
- ワークスペースに含めるリポは2つを基本、3つ目は必要時に限定する
- 並列度のデフォルト3を尊重し、迷ったら下げる
- チーム導入時はレビュー分担・ブランチ命名・マージ順序の3点を事前合意する
Parallel Agentsは強力だが、銀の弾丸ではない。むしろ「人間側のタスク分解力」のほうが、ボトルネックになりつつある印象だ。次は、Bugbotの新しいEffort Levels機能と組み合わせたときの体感を測ってみたい。
（本稿は筆者個人の検証に基づくものであり、所属組織の見解を示すものではありません）
