CursorのProjects、数千エージェントを統括

Cursorは9月10日、新機能「Projects」をベータ版として全ユーザー向けに公開した。狙いは複数のプルリクエスト(PR)にまたがり、数週間から数カ月続くような作業だ。新機能の開発、フレームワークの移行、あるいはアプリをゼロから構築するといった場面を想定している。

仕組みは二層構造になっている。上位には自らコードを書かない「調整役エージェント」がおり、下位のエージェントに作業を割り振るだけの役割を担う。Cursorによれば、調整役は委任だけを行い実行はしないため、特定のタスクで詰まることがなく、いつでも新しい指示を受け付けられるという。下位には実際にコードを書くサブエージェントが並び、公式発表では1つのプロジェクトで数千体を指揮できるとしている。

"It doesn't write code itself but directs other agents that do."

(自らコードは書かず、コードを書く他のエージェントに指示を出すだけだ。)

土台となる3つの機能

Projectsは次の3つの機能に支えられている。

  • クラウドファースト:プロジェクトは専用サーバー上で動くため、ノートPCを閉じても処理は止まらない。
  • コンテキスト共有:ファイルはクラウドとローカルマシンの間で同期され、先に動いたエージェントが把握した内容を後続のエージェントがそのまま再利用できる。
  • サブスクリプション:プロジェクトはSlackチャンネルを監視したり、スケジュールに沿って定期実行したり、PRの状態に応じて自動的に反応したりできる。

Cursorは3つの典型的な使い方を挙げている。新機能開発では、複数のエージェントがまず既存システムを並行して調査し、その後コンポーネントごとに分かれて実装する。移行作業では、チームはこれを使って数百件のPRにわたってフレームワークやスタイルシステムを段階的に置き換えていく。保守作業では、調整役がコード品質と回帰の監視を続ける。

デザインシステムの具体例

Cursorのブログで最も具体的に語られているのはデザインシステムの保守だ。調整役が新しいPRを1件ずつスキャンし、デザインシステムに組み込むべきコンポーネントを抜き出し、同じミスを2回目に見つけた時点でlintルールを追加する。Cursorの見積もりでは、この種のプロジェクトは1日あたり20件から100件のPRを処理するという。

この量を人間の作業量に置き換えて考えてみる。中規模のPRを丁寧にレビューするのに15分から30分かかると仮定すると、1日20件なら5時間から10時間で、1人でどうにか対応できる範囲だ。だが1日100件になると25時間から50時間となり、1人1日8時間換算でレビュー担当者が3人から6人専任で必要になる。機械側の生産速度が上がるほど、ボトルネックはレビュー工程に移る。チームが「自動チェックだけを通れば一部のPRはマージされる」という状態を受け入れない限りは。Projectsが生み出すPRのうち、人間のレビューを経てからマージされる割合がどれくらいかについて、Cursorは説明していない。

「6倍」の根拠

Cursorが示した成果指標は2つある。社内では新規ユーザーがマージするPR数が30%増加し、Projectsを主に使うユーザーではマージ数が従来の6倍になったという。ただしこの2つの数字はいずれもCursor社員自身によるもので、測定しているのはマージされたPR数だけだ。PRの規模、手戻り、差し戻しについては触れられておらず、30%という数字の比較基準が何かも明記されていない。社外チームによるデータは現時点で得られていない。

料金については、Projectsが単独課金の対象になるのか、数千体のサブエージェントの稼働をどう計測して課金するのかについて、ブログ記事は言及していない。クラウド上で数百から数千のエージェントを長時間稼働させ続けるコストが小さいはずはなく、この点はCursorの続報を待つ必要がある。

2つの布石がつながった

ここ半年のCursorの動きに重ねてみると、Projectsはその延長線上にある一手だ。4月にバージョン3.0を出した際、CursorはIDEをエージェント管理のためのインターフェースへと位置づけ直した。9月初めには、クラウド上のエージェントを企業自身のマシン上で動かせるようにした。Projectsはこの2つをつなぐ存在で、人が調整役を管理し、調整役が実行役のエージェントを管理し、実行役はクラウド上でも自社サーバー上でも動かせる。

同日にOpenAIが公開した「Agents API」も、主エージェントがタスクをサブエージェントに分割する仕組みを備えているが、両社が売っているものは異なる。OpenAIが開発者に売るのは自前のエージェントを組み立てるための基盤であり、Cursorが売るのはチームの作業を直接代行する完成品だ。Projectsの入り口は左側のサイドバーにあり、複数のPRにまたがる、あるいは長期間続く作業にのみ使うようCursorは推奨している。

参考資料:Cursor公式ブログ、CocoLoop、MarkTechPost。サブエージェントの規模、PRマージ増加率の基準、事例の詳細はCursorのブログ記事で確認した。