AIツール

直列から並列へ——CursorのSubagentsが叩き出した「9分 vs 17分」の衝撃

2026年1月のCursor 2.4でSubagentsが登場し、エージェントの動き方が根本から変わった。8,000行のNext.jsアプリ移行が17分から9分に短縮された仕組みと、並列化が引き起こす落とし穴を解説する。

公開: 2026年3月10日約13分

作業が直列である限り、速くなるのに限界がある。何百万行のコードがあっても、エージェントが1つのタスクを片付けてから次に進む構造では、速度の天井は「最も遅いタスクの時間」だ。

それを変えたのが、2026年1月22日のCursor 2.4で登場した**Subagents(サブエージェント)**だ。


「順番待ち」から「同時進行」へ

従来のAIコーディングエージェントは、料理で言えば一人のシェフが前菜・メイン・デザートを一品ずつ順番に作る形だった。腕はいい。でも3品同時に食べたければ、順番に完成するのを待つしかない。

コードの作業も同じ構造だった。コードを読む、考える、書く、テストを走らせる——この流れを1つのエージェントが順番にこなす。ファイルが増えるほど、タスクが増えるほど、時間は比例して伸びていく。

Subagentsが変えたのは、この「順番待ち」の構造だ。親エージェントがタスクを分解し、複数の子エージェント(Subagents)が別々のタスクを同時に処理する。3人のシェフが別々のコンロで同時に作業する状態になる。


Subagentsとは何か

Cursor公式の定義を引用する。

"Subagents are independent agents specialized to handle discrete parts of a parent agent's task. They run in parallel, use their own context, and can be configured with custom prompts, tool access, and models."

Cursor Changelog 2.4

日本語に直すと「Subagentsは、親エージェントのタスクを個別のパーツに分けて処理するために特化した、独立したエージェント群だ。並列で動作し、それぞれが独自のコンテキストを持ち、カスタムプロンプト・ツールアクセス・使用モデルを設定できる」となる。

デフォルトでは3種類のSubagentsが用意されている。

  1. コードベース調査専門 — コードを読み、関連箇所を探し、移行計画を立てる
  2. ターミナルコマンド実行専門 — テストの実行、依存関係のインストール、ビルドコマンドなど
  3. 並列作業ストリーム実行専門 — 複数の独立したファイル変更を同時に実行

これらが同時に動くことで、「コードを読みながらテストを走らせながら別ファイルを変更する」という状態が実現する。


実測: 8,000行のNext.jsアプリが17分から9分へ

これが実際にどれだけ速くなるのか。第三者レビュワーが行ったベンチマークが参考になる。

テスト内容は「8,000行規模のNext.jsアプリを、旧来の pages/ ディレクトリから新しい app/ ルーターへ移行する」というタスクだ。

  • 直列エージェント(従来): 17分
  • Subagentsによる並列実行: 9分

約47%の短縮。直列だと「pages/index.tsx → pages/about.tsx → pages/blog/[id].tsx」と順番に処理していたものが、並列では複数のページを同時に変換したため、最も時間のかかるサブタスクが終わるまでの時間(9分)が全体の処理時間になった。

この数値は公式Cursorのベンチマークではなく、第三者レビュワーによる実測値だ(myaiverdict.com — Cursor AI Review 2026)。環境やタスクの構成によって結果は異なる。参考値として見てほしい。

なぜ「最も遅いサブタスクの時間」が全体の時間になるのか。引越しの例えが分かりやすい。4人が別々の部屋を同時に梱包するとき、全体の作業が終わるのは「一番時間がかかった人が終わった瞬間」だ。4人が順番にやれば4倍の時間がかかるが、同時なら最も遅い人の時間だけで済む。


Cursor 2.5でさらに進化: 非同期と「孫エージェント」

2026年2月17日のCursor 2.5では、Subagentsの動作がさらに変わった。

ひとつは非同期実行だ。Cursor公式の言葉を借りると「Subagents can now run asynchronously, allowing the parent to continue working while subagents run in the background(Subagentsが非同期実行できるようになり、親エージェントはSubagentsがバックグラウンドで動いている間も作業を続けられる)」となる。これまでは子エージェントの完了を待って次に進んでいたが、2.5以降は親が作業を続けながら子が並列で動く。

もうひとつはネスト構造だ。「Subagents can also spawn their own subagents, creating a tree of coordinated work(SubagentsがさらにSubagentsを生成でき、協調した作業のツリーを作れる)」。Cursor公式の言葉通り、親→子→孫という階層構造が生まれた。

Plugins, Sandbox Access Controls, and Async Subagents · Cursorcursor.com

大規模なリファクタリングで実際にどう機能するかを図で示す。

直列実行(2.4以前)
親エージェントがタスクを受け取る
Subagent Aが完了するまで待つ
Subagent Bが完了するまで待つ
Subagent Cが完了するまで待つ
親エージェントが結果をまとめる
非同期並列実行(2.5)
親エージェントがタスクを受け取る
Subagent A・B・Cが同時にスタート
親エージェントは別タスクを並行処理
各Subagentが完了次第レポート
親エージェントが結果を統合する

並列化の指示の書き方

SubagentsはCursorが自動で起動するが、どのタスクを並列化するかは指示の構造次第だ。

❌ 直列指示(並列化されにくい)

「Next.jsの pages/ ディレクトリを app/ に移行して」

→ エージェントが1ファイルずつ順番に処理する
✅ 並列指示(Subagentsが活きる)

「Next.jsの pages/ を app/ に移行する。
以下を並列で進めてほしい:
- コードベース調査: 影響を受けるファイルのリストアップと移行計画の作成
- pages/index.tsx と pages/about.tsx の変換
- pages/blog/ 配下のダイナミックルートの変換
各タスクが完了したら結果を報告して」

→ 3つのSubagentsが同時に動き、最長タスクの時間で全体が完了する

「並列で進めてほしい」「同時に実行して」という明示的な指示が、Cursorにタスク分解のヒントを与える。ただし後述するように、どのタスクを並列にするかの設計が重要だ。


落とし穴1: 同じファイルに複数のSubagentsが触ると衝突する

並列化には根本的な制約がある。複数のSubagentsが同じファイルを同時に編集しようとすると衝突(コンフリクト)が起きる。

❌ 衝突する設計

SubagentA: auth.ts を修正(認証ロジック追加)
SubagentB: auth.ts を修正(バリデーション追加)

→ 両方が同じファイルを同時に書き換えようとする → コンフリクト発生
✅ 衝突しない設計

SubagentA: auth.ts を修正(担当範囲を明確に指定)
SubagentB: validation.ts を新規作成(別ファイルで担当)
SubagentC: auth.test.ts を作成(テストのみ)

→ 担当ファイルが重複しない → 干渉なし

aimakers.co の解説でも「2つの機能が同じファイルに触れる場合は直列実行すべきだ」と明言している(参照)。

引越しの例えで言えば、4人が同時に同じ引き出しを開けようとすると衝突する。別々の部屋や別々の引き出しを担当させることが、並列化を機能させる条件だ。

Subagentsを設計するときは、まず「それぞれのSubagentsが触るファイルの範囲に重複がないか」を確認することが先決になる。

第三者レビュワーの実測では、3体以上のSubagentsを同時に動かすと同じファイルへの干渉が起きやすくなる傾向があったという(myaiverdict.com)。安定性を優先するなら、最初は2〜3体から始めて動作を確認しながら増やすとよい。


落とし穴2: Lazy Delete(コードが静かに消える)

Subagentsを使うとき、もうひとつ見落とせない問題がある。「Lazy Delete(怠惰な削除)」と呼ばれるパターンだ。

500行を超えるファイルをリファクタリングさせると、エージェントがコードの塊を書き直す代わりに // ... existing code ... という1行に置き換えることがある。

❌ Lazy Deleteの例

// auth.ts(リファクタリング後)
export function authenticate(user: User) {
  // ... existing code ...  ← ここに500行分のコードがあったはず
  return validateToken(user.token);
}

問題は、この提案を何も考えずにAcceptしてしまうと、// ... existing code ... の部分が文字通り消えることだ。500行のロジックが1行のコメントに置き換わってしまう。

「diffを確認した」という意識があっても、大規模なリファクタリング時はdiffが巨大になりスクロールが面倒になる。その隙間でこのパターンが通過してしまう。

対策はシンプルで、Subagentsが変更を提案したとき、// ... existing code ... というコメントが含まれていないかをdiff確認の際に意識的にチェックすることだ。特にファイルの行数が多い(目安として500行超)場合は要注意だ。

Cursor AI Review 2026: Cloud Agents, Pricing & FeaturesCursor AI Review 2026: We tested the latest Cloud Agents. See how up to 10 parallel workers and the new Pro+ pricing tiers change the game for devs.myaiverdict.com

SubagentsはCloud Agentsとは別物だ

Cursorには「Subagents」と「Cloud Agents」という似た名前の機能が存在するが、これらは別の機能だ。混同しやすいので整理しておく。

Subagents(エディタ内)
IDE(エディタ)の中で動く
親エージェントがタスクを分解して起動
セッションと同じコンテキスト内
コードベースに直接アクセス
2026年1月 Cursor 2.4で導入
Cloud Agents(VM上)
独立したLinux VM上で動く
Issueを渡して自律的に動作
エディタとは独立した環境
PRを証拠付きで自動生成
2026年2月24日に発表

Subagentsは「IDEの中で今やっている作業を並列化する」仕組みだ。Cloud Agentsは「VMを立ち上げてエディタの外でエージェントを自律動作させる」仕組みで、GitHubのIssueを渡してPRを自動生成させるような使い方をする。

Cloud Agents with Computer Use · Cursorcursor.com

他ツールとの並列化の比較

2026年1〜2月は、複数のAIコーディングツールが並列エージェント機能を同時期にリリースした。各ツールのアプローチの違いを整理する。

Cursor Subagents
IDE内でタスクを並列分解
親→子→孫のツリー構造
カスタムSubagentsを設定可能
ファイル衝突のリスクあり
Claude Code Git Worktree
Gitのworktreeで作業場所を分離
独立したコンテキストで並列実行
手動セットアップが必要
コンフリクトリスクが低い
Cursor Cloud Agents
Linux VM上で自律動作
エディタから独立した環境
PR自動生成に強い
Subagentsとは別機能

Cursor SubagentsはIDE内で完結するため設定不要で始められる。Claude CodeのGit Worktreeは作業環境を物理的に分離するため干渉リスクが低いが、セットアップが必要だ。どちらが向いているかは、タスクの性質と好みによる。


速度より「設計」が先になった

SubagentsはCursorのエージェント作業を根本から速くする機能だ。8,000行のNext.js移行が17分から9分になった事実は、並列化の効果を端的に示している。

だが使いこなすには、速さより先に「設計」が問われるようになった。

どのタスクを並列にできるか。どのファイルが干渉し合うか。Subagentsに担当範囲をどう割り振るか。この構造設計なしに「とにかく並列で」と指示しても、ファイル衝突やLazy Deleteによる事故が起きる。

エージェントに作業させる前に、人間が仕事の構造を整理する。それがSubagentsを使いこなす条件だ。「速くなった」という結果は、設計の正しさが生む副産物だ。

Subagents, Skills, and Image Generation · Cursorcursor.com