本日、Cursor の Projects をリリースします。Projects なら、機能開発、マイグレーション、アプリ全体の構築といった、より大きな規模の仕事に取り組めます。数か月に及ぶ作業のコンテキストを維持し、数千のサブエージェントにタスクを委任し、指示がなくても定期的な作業をこなします。

2月に私たちは、エージェントの群れが仕事全体を担うソフトウェア開発の第三の時代というビジョンを示しました。Projects は、そのビジョンを具体的な形にしたものです。抽象度をひとつ引き上げることで、開発者はエージェントの管理から解放され、作業そのものを指揮できるようになります。

Cursor では数か月にわたって Projects を使い、数百件の PR に及ぶマイグレーションの実行、デザインシステムの一貫性の維持、そして Projects 自体のリリースといった作業を進めてきました。その結果、生産性を大きく押し上げる存在であることがわかりました。新規ユーザーはマージする PR が30%増え、主に Projects を使うユーザーは6倍の PR をマージしています。

#1人のコーディネーターで数千のエージェントを指揮する

Project の監督は、そのコーディネーターエージェントとチャットしながら行います。コーディネーター自身はコードを書かず、実際に書く他のエージェントに指示を出します。実行ではなく委任に徹するため、処理待ちでブロックされることがなく、常に指示に応答できます。

Projects を支えているのは、3つの中核機能です。

デフォルトはクラウド、必要なときはローカル。 Project は専用のコンピュータ上で実行されるため、ノートパソコンを閉じても止まりません。そのため、手元のノートパソコンでは処理しきれない数のサブエージェントを並列で実行できます。自分のマシンでのテストが必要になったときは、コーディネーターがローカルエージェントを立ち上げ、そこで実行します。

共有コンテキスト。 タスクを始めるたびに、エージェントに一から説明する必要はありません。各 Project は、そのエージェントが使うすべてのクラウドおよびローカルマシン間で同期されるファイル群を保持します。エージェントは、リサーチやアーティファクトに加えて、コードベースについて学んだことや、あなたが好む作業の進め方も書き足していきます。たとえば、あるエージェントがサービスのテスト方法を突き止めれば、それ以降のすべてのエージェントがその手順を活用できます。このコンテキストは Project とともに育ち、コーディネーターは時間とともに効果を高めていきます。

Subscriptions。 コーディネーターは、Slack チャネルを監視する、スケジュールに沿って実行する、あなたのすべての PR を追跡して CI を修復し、PR のオープンやマージに合わせて動く、といったことができます。これにより、あなたのプロンプトを待たずに、検知したシグナルに基づいて自ら動けます。

#Cursor 社内での Projects の使い方

私たちのエンジニアが Projects で行っていることの大半は、次の 3 つのパターンに集約されます。

#機能開発

多くのエンジニアは、まとまった規模の作業ごとに Project を作成します。機能開発はたいてい、エージェントがシステムを調査し、わかったことを共有コンテキストとして記録するところから始まります。続いて コーディネーター がプランを作成し、複数のエージェントにその各部分を割り当てて並列に実装・テストさせます。

フィードバックのやり取りを重ねるたびに、Project はあなたのアーキテクチャや好みを学習していきます。機能を試せる状態になったら、コーディネーター はあなたのコンピュータ上でエージェントを起動し、ローカルで実行できます。リリース後も、同じ Project がログを監視し、当初の判断の背景まで含めた完全なコンテキストをもとにバグ報告へ対応できます。

#マイグレーション

Projects は、着手は簡単でも完了させるのが難しいマイグレーションでとりわけ役に立ちます。Cursor でも、新しいフレームワークの採用やスタイリングシステムの置き換えを、数百件の PR にわたって進めるために使ってきました。

まず コーディネーター と一緒に安全なアプローチを決め、あとは コーディネーター がそのアプローチを コードベース 全体に段階的に適用していきます。最初のうちは各 PR を細かくレビューします。修正が問題なく通るようになればレビューを減らし、コーディネーター が自律的にマイグレーションを進め続けます。

#ガーデニング

Projects は、コード品質の維持やリグレッションの監視のように、終わりのない作業を扱うのに最適です。コーディネーターに新しい PR を追跡させたり、Slack のバグ報告を待ち受けさせたり、スケジュールで実行させたりでき、新しい作業が発生するたびに動き出します。

私たちのチームのあるエンジニアは、この方法でデザインシステムの Project を運用しています。当初、そのエンジニアは修正を一つひとつレビューし、誤ったものを直していました。現在では、コーディネーターがすべての新しい PR をスキャンし、デザインシステムに属するコンポーネントを抽出し、同じ間違いを2回見つけるたびに lint ルールを追加します。この Project は1日に20〜100件の PR を扱う見込みで、コーディネーターが作業を整理し、エンジニアは注意が必要な箇所だけを確認します。

#Projectsを使ってみる

Projectsはbeta版として、本日より全ユーザーへ順次提供を開始します。左側のナビゲーションからProjectを開始し、何を作りたいかを伝えれば、あとはコーディネーターが引き継ぎます。複数のPRにまたがる機能開発やマイグレーション、離席中に任せておきたい作業など、1回のchatでは終わらない仕事にこそ真価を発揮します。