Cursorが「Projects」機能を発表——タスクを数千のサブエージェントに委任し、プロンプトなしで数カ月にわたり定期タスクを自律実行

Cursorは、単一の機能追加、コード移行、あるいはアプリケーション全体の開発といった、より大規模な作業を引き受ける機能「Projects」を発表した。数カ月に及ぶ作業を通じてコンテキストを保持し続け、タスクを数千ものサブエージェントに委任できるほか、プロンプトで都度指示しなくても定期タスクを自律実行できる。同機能は現在ベータ版であり、全ユーザーに向けて順次提供されている。

発表動画の中で、Cursor社員のFredrika Lindhは、以前は業務がいくつもの会話（スレッド）に散らばっていたが、現在はコーディネーターエージェントがそれらを一元管理するため、スレッドが1つだけで済むようになったと述べている。別の社員も、一問一答形式のやり取りから脱却し、各エージェントを1つずつ監視・指揮する必要がなくなったことで、自律した同僚と協業している感覚に近くなったと語った。

コーディネーターエージェントは計画と委任に徹し、自身はコードを書かない

左側のナビゲーションバーから「Projects」を開くことができ、メイン画面はコーディネーターエージェントとの対話スレッドとなっている。コーディネーターエージェント自身はコードを書かず、作業の計画立案、実装を担当するエージェントへの委任、そして完了した成果物のユーザーへの確認提出を担当する。ユーザーに代わってエージェントを作成・管理し、必要に応じて任意の数を並行稼働させる。Fredrikaによれば、一部のProjectsでは数千のエージェントを稼働させており、制限を気にせず立ち上げられるという。

Cursorは以前、マルチエージェント実験を公開したことがある。これは、エージェント群に835ページのマニュアル1冊だけを与え、SQLiteデータベースをゼロから再実装させるというものだった。その際、Grok 4.5モデルを使用したグループでは、旧システムで2時間実行したもののテスト通過率はほぼ0%のままで手動停止に至った。だが、同じ課題を「計画担当はタスク分解に専念し、コードは書かない」という新たな役割分担に変更したところ、4時間で約80%のテストに合格した（実験およびデータ集計はCursor独自によるもの）。

委任のプロセスは上記の画面録画で確認できる。ユーザーが「Tabs」という名前のProjectsを新規作成し、デスクトップアプリ（Grok）のタブがどのように実装されているか、またその構造をどう変更できるかを把握するよう指示する。コーディネーターエージェントは進め方の方针を伝えた上で、サブエージェントを派遣してProjectsの説明ドキュメントやコードの調査を開始させた。デモはサブエージェントがコードを調査している途中で終了している。

コーディネーターエージェントがどのように成果物を手元に戻すかは、発表対談で示された別のProjectsで確認できる。パネルには64件のPR（pull request：メインコードへのマージを待つ変更群であり、通常はレビューとチェックを経て取り込まれる）が並んでいる。ユーザーが「変更規模が小さく、すでに安全にマージできるものはどれか」と尋ねると、コーディネーターエージェントは候補をいくつか挙げつつも、現時点では即マージできるものは1つもないと回答した。メインブランチ（main）から大きく遅れていて更新が必要なものや、マージ前チェックを通過したことがまだ確認できていないものがあるためだ。その上で、最もマージに近い候補から着手することを提案した。また、ユーザーがすべてのアイコンが表示されないスクリーンショットを共有すると、問題を確認した上で調査にあたる旨を伝え、担当の変更タスクに修正を割り振り、修正が完了するまではマージ可能状態にマークしない方針を示した。

マージの最終判断を誰が下すかについては、コーディネーターエージェントが完了した作業をユーザーに確認のために戻すと原文ページに明記されている。デモに登場した「Browser」という別のProjectsでは、PRのマージはFredrika本人が確認した上で実施される旨が備考欄に記されていた。別の画面では、セキュリティチェック（Security）やコードオーナー承認（codeowners）など一部の承認がすでに自動通過しており、システムがCI（変更ごとに自動実行されるテストとビルド）とBugbot（Cursorの自動コードレビューツール）の結果を待っている状態が確認できる。デモ内には、ユーザーからの「go」という一言を待ってからPRをマージする場面もあった。確認なしでの自律マージや自動マージ設定が可能かどうかについては、原文ページおよび動画のいずれにも記載がない。

クラウド上で稼働し、手元のPC上でもテスト可能

ProjectsはCloud Agentsによって動作する。各Projectsはクラウド上に専用マシンを持っているため、ノートPCを閉じても処理が中断することはない。原文ページによれば、Projects内のエージェントは複数のクラウドマシンと手元のローカルPCを利用する場合があり、共有ファイルはこれら使用マシン間で同期されるという。ただし、サブエージェントが具体的にどのマシン上で動作するかについて、原文に詳細な説明はない。動画内でも複数マシンが連携している様子が窺える。約88秒の応答では、ある仮想マシンでコードのプッシュに失敗したため、プッシュ済みの別のマシンに同じ修正作業を引き継がせたと説明されている。

特定のタスクで手元のマシンを使ったテストが必要な場合、コーディネーターエージェントはローカルエージェントを立ち上げてユーザーのPC上で実行する。発表動画では、マージ済みのUI変更（「Align More with titles」：「More」という要素を項目のタイトルと揃える変更）をテストするため、ユーザーが手元のPCでアプリを起動するよう求めた。コーディネーターエージェントは、タイトルに対して「More」の位置を確認できるよう、彼女のマシン上でGlass（画面から察するに開発中のアプリ）を起動すると回答している。

マシン間を同期する共有コンテキスト：「新人のオンボーディング」を繰り返さない

Cursorの主張は、新しいタスクを開始するたびにエージェントへの「オンボーディング」を最初からやり直すべきではない、というものだ。Projectsはその解決策として「共有コンテキスト（Shared context）」ファイル群を保持し、エージェントが利用するすべてのクラウドマシンおよびローカルPC間でこれらを同期させている。

このファイル群には、主に以下の3種類の内容が蓄積される：

• 設計・アーキテクチャの蓄積：たとえば「Browser」Projectsのドキュメントディレクトリ（Project/docs）内には、エージェントによって作成された electron-concepts.md などの設計ドキュメントが保存されている。
• トラブルシューティングやテスト手順の再利用：あるエージェントが特定サービスのテスト方法を確立した場合、後続のすべてのエージェントがその手順を直接利用できる。
• 好みや習慣の記憶：コーディネーターエージェントはユーザーの作業スタイルを記憶する。「Tabs」Projectsの新規作成時、コーディネーターエージェントは冒頭で「やり方を変えたいときはいつでも指示してください、記憶します」と伝えている。また発表対談でFredrikaが明かしたところによると、PRを開いた時点で、すでに2つのスキルが自律実行されていた。1つはコード簡素化（simplification）を行うもので、もう1つはThermos（画面上、レビュー所見を生成するツール）である。ここでのスキルとは、事前定義された再利用可能な一連の操作手順（skill）を指す。これが自律実行されたのは、以前Fredrikaがそう指示していたためだ。後述のサブスクリプション設定デモでも、エージェントが preferences.md を編集している様子が映し出されている。

Cursorは、共有コンテキストはProjectsの進行とともに蓄積され、使い込むほどコーディネーターエージェントの作業効率が向上すると述べている。

サブスクリプション：一度設定すれば、シグナルや計画に従って自律着手

コーディネーターエージェントに監視対象を伝えておけば、検知されたシグナルや事前計画に基づいて自律的に作業を開始し、都度プロンプトを入力する必要がなくなる。原文ページでは、3種類のシグナルが例示されている：

• Slackチャンネル：Slackと連携させてバグ報告チャンネルを指定すると、新しいバグが起票されるたびにタスクの割り振りを自動で開始する。
• 定期スケジュール（cron jobs）：計画に従って定期タスクを実行する。前述のBrowser Projectsでは夜間に継続実行されるタスク（merge-readiness watch）が設定されており、マージ可能な状態にあるPRを毎時チェックし、コンフリクトやCI、Bugbotの問題を発見次第修正にあたる。
• リポジトリのPRステータス：GitHubやCursor独自のコードホスティングプラットフォームOrigin上のPRを含め、すべてのPRを追跡する。

こうしたサブスクリプションや監視はどのように設定するのか。発表対談でこの点を問われた開発メンバーは、チュートリアルも段階的な設定ウィザードもなく、通常の会話と同じ感覚で指示できるにもかかわらず、極めて大規模な運用にまでスケールすると述べている。

上記の録画では、ユーザーが「Design System」Projects内で自然言語による指示を1行入力している。マージされたすべてのPRを監視し、既存コンポーネントへの差し替え、新規バリアントの作成、スタイルの上書きの削除、あるいは新規コンポーネントの追加が必要かどうかなど、デザインシステム違反がないかをチェックするよう求めた。コーディネーターエージェントはマージを監視してこれらの問題を抽出すると応じ、画面上では preferences.md を編集している様子が表示された後、「Design system merge watch」という名称のサブスクリプションが登録され、1時間ごとに実行されるようになった。

社内データと現時点で未公表の事項

発表動画の中で、Cursor社員はいくつかの社内データに言及した。社内での観測として、Projectsを利用するメンバーは週あたりのPRマージ数が約6x（6倍）に増加し、利用開始初週にはマージ率が約30%向上したという。ただし、これらは動画内での社員による口頭での発言であり、原文ページの本文には記載されていない。また動画では、比較対象のベースライン、集計基準、マージ率の具体的な定義、および30%が相対的な伸び率なのかパーセンテージポイントなのかについては説明されていない。

料金体系や利用量の上限については、原文ページおよび動画のいずれでも触れられていない。

Fredrikaは、これこそが彼らが数カ月間にわたって実践してきた働き方であり、Projectsはそれを誰もが容易に利用できるよう初めてパッケージ化したものだと述べている。