🕛 2026.4.25 17:23 文:かみくだきりく

Cursor、エージェント並列実行に対応。worktreesとマルチリポも同時投入

Cursorに「並行サブエージェント」と「ワークツリー」「マルチルートWS」が一気に着地
X はてブ LINE Feedly

Cursor の changelog に「Multitask, Worktrees, and Multi-root Workspaces」が並んで来ました(2026-04-24 公式)。要はこういうことですね、エディタの中で 複数のサブエージェントを非同期で走らせる、ワークツリーをまっとうに扱える、複数のリポジトリにまたがる変更を 1 ウィンドウでさばける、この 3 つが同じリリースに乗っています。

Cursor 3 が 4 月頭にエージェント中心の編集環境を発表したばかりですが、そこからわずか 2 週間ちょっとで「複数エージェントの並列化」と「リポジトリ横断」に踏み込んできた格好です。

何が変わるかというと

ざっくり言うと、エージェント駆動の開発は「1 タスクを丁寧に投げて待つ」段階から「複数タスクを同時に泳がせる」段階に移った、ということです。

  • Multitask: async なサブエージェントを複数立てて、同時並行で別々の改修を進められる。これまでは 1 本のエージェントセッションが終わるまで次の作業を始めにくかった
  • Worktrees: Git の worktree を Cursor 側がちゃんと意識する形に。ブランチごとにディレクトリを切って並行作業する人にとって、エージェントとブランチの取り違えが起きにくくなる
  • Multi-root Workspaces: 複数のローカルリポジトリを 1 ワークスペースとして開ける。フロントとバックエンドが別リポジトリのチームには、これが地味にきいてきます

ちなみに「複数エージェントの並列」自体は他の AI コーディングツールでも実装され始めている領域です。Claude Code もサブエージェント設計を打ち出してきていて、各社の方向性が見えてきました。

エージェントを並列化する、という設計

並列のサブエージェントを走らせるとき、面白いのは コンテキストの分離 です。1 本のセッションに全部押し込むと、トークンを食うわりに集中力がぼやける。サブエージェントを切ると、それぞれが自分の関心領域だけに最適化されたコンテキストを持てる。

要はこういうことですね、長時間のリファクタとちょっとしたバグ修正を、同じ部屋に詰め込まず別の机でやらせる、というイメージです。Multitask が async である意味も、ここに乗ります。1 本目を待たずに 2 本目を立ち上げられる。

実装側の影響として、エージェントごとのトークン消費・実行ログ・差分を、開発者が後追いで読む手段が要ります(ちなみに、Cursor の changelog 本体にはサブエージェントの監視 UI の詳細までは書かれていないので、実機で触る人はそこを見たいところ)。

Worktrees と Multi-root が地味にうれしい層

ここから先は実務よりの話。Worktrees の改善で恩恵を受けるのは、長期開発ブランチと hotfix を行き来する チームです。Git 上ではブランチ切り替えで済むけれど、ローカルのビルドキャッシュやエディタの開いているファイルが行ったり来たりするのが不便だった。worktree なら物理的に別ディレクトリに切れる。それを Cursor が混乱せず追従してくれる、というのが今回の更新の意味です。

Multi-root Workspaces は、フロント / バック / インフラを別リポジトリで管理しているチーム に効きます。VS Code 系では昔から欲しかった機能ですが、AI エージェントが複数リポにまたがって変更を提案できる、というのはこれまで弱かった部分。コミットの単位を分けつつ、変更の意図を 1 ウィンドウで追える、というのは、レビュー前の脳内モデル構築コストをぐっと下げます。

「3 機能を同じリリースに乗せた」という意味

ここで立ち止まって考えると、3 つを同じ日に出した、という設計判断もちょっと面白い。Multitask だけ出しても、worktree が雑だと並列の意味が薄い。Multi-root が無いと、フロント・バックを別エージェントに任せたいときに片方しか触れない。3 つを同時に整えて、ようやく「複数エージェントが複数ブランチ・複数リポを並走する」絵が成立する。逆に言えば、Cursor がいま狙っているユースケースは、「規模感のあるプロダクトで、複数の AI エージェントを使い分ける開発体制」だ、ということになります。

個人的には腑に落ちる話で、エージェントの中身を磨くのと同じくらい、「エージェントを束ねる外側の構造」を作り込むのが、今年いちばん効くテーマな気がしています。続報待ちですね、特に並列実行時のエージェント監視 UI と、料金プラン側の扱いがどう整理されるか。

Cursor Changelog — Multitask, Worktrees, and Multi-root Workspaces

みんなの反応

ぬるぽ
(システムエンジニア・30代男性)

multi-root workspaces はチームで待ってた人が多い機能。フロントとバック別リポを跨いで PR の整合性をエージェントが見てくれるなら、レビュー前の準備工数がだいぶ削れる。worktree 連携も、案件並走時の「ローカルビルド汚染」事故が減る方向で効く。
島ぐらしCTO
(リモートCTO・40代男性)

async サブエージェントを動かす前提だと、料金体系がまだ追い付いていない。同時実行数とトークン消費を可視化する管理 UI が無いと、月末に請求が爆発するケースが出る。プラン側のメーター設計が次の論点。
学生コーディングラボ
(情報系大学院生・20代男性)

研究室のコードはモジュール別にリポを分けてるので、multi-root 対応は普通にうれしい。ただ、サブエージェントを並列で走らせるとローカルマシンの GPU がちょっと厳しくなる。クラウド側で動かす派と、ローカル派でワークフローが分かれていきそう。
情シスの中の人
(事業会社情シス・30代男性)

うちは社内開発者 50 人いるけど、サブエージェントの並列化をどこまで許可するかはガバナンス側の判断が要る。エージェントが複数リポを横断するなら、ソース流出と権限管理を見直さないとセキュリティ部門の OK が出にくい。
M
ML基盤の中の人
(ML プラットフォームエンジニア・30代女性)

並列エージェントは魅力的ですが、それぞれが prompt をどう保持するか、設定の継承ルールがどうなるかが運用上の地雷ポイント。Cursor 3 のエージェント設計と今回の Multitask の関係を、ドキュメントで早めに整理してほしいところ。
X はてブ LINE Feedly