昔はCursorに大きな機能を頼むと、作業が終わる間にコーヒーを2杯淹れる時間があった。それが変わるかもしれない。
Cursorが本日2つの機能をリリースしたが、単体で見るより一緒に見た方が面白い。
パラレルサブエージェント：「Build in Parallel」
「Build in Parallel」をクリックすると、Cursorがタスクを分析し、どのサブタスクが独立しているかを特定して、すべて同時に実行する。キューイングではない。実際の並列処理だ。
想像してみてほしい。APIのエンドポイントを3つ追加し、対応するユニットテストを書き、フロントエンドの呼び出しを更新するよう頼む。以前は一つずつやっていた。今は3つのサブエージェントが同時に作業する。
これはリファクタリングに特に効果的だ。モジュールAの変更がモジュールBに影響しない場合、並列実行は時間節約が線形的になる。
PR自動分割：混沌からクリーンなGitヒストリーへ
並列処理が終わった後、どうマージするか？Cursorは論理的に独立した変更ブロックを特定し、分割案を提示して承認を得た後、複数の小さなPRを自動作成できる。
「47ファイル変更、コミットメッセージはupdate」というタイプのPRより遥かに文明的だ。各PRは一つのことだけを行う。レビュー担当者の脳細胞が少なくて済む。
もう一つの兆候：/orchestrate
同日、Cursorは/orchestrateスキルも公開した。再帰的にサブエージェントを生成して複雑なタスクを処理できる。社内では自社のスキルを自動リサーチするのに使い、トークン使用量を20%削減しながら評価スコアを向上させた。内部バックエンドのウォームスタート時間は80%短縮。
再帰的エージェント生成自体は新しいが、Cursorがこれをすぐに使えるスキルとしてパッケージ化したことで、ハードルが下がった。
所感
これらの機能を合わせると、Cursorは「コードを書くアシスタント」から「タスクを委任できるエンジニアチーム」へ近づいている。
誰かがうまくまとめていた：Claude Codeは短い寿命のコーディングエージェントで、単一非同期ループ。Cursorの道はマルチタスク並列エンジニアリング環境の構築だ。
実践で重要になるポイント：
- サブエージェント間のコンテキスト分離 —— お互いに干渉するなら、シリアルの方がいい
- PR分割ロジック —— 細かすぎるとPRの津波、粗すぎると分割の意味がない
- トークンコスト —— 複数のサブエージェントが同時実行、使用量は爆発しないか
私の直感では、小規模プロジェクトでは恩恵は限定的だが、中規模以上のリファクタリングでは、この機能は実質的な時間を節約できるだろう。
次の大きな変更の前に「Build in Parallel」を試す価値はある。
主な情報源：