Cursor、コーディネーターがサブエージェントを指揮する「Projects」をベータ公開

Cursorは2026年9月10日、新機能「Projects」をベータで公開し、同日から全ユーザーへの順次展開を始めた¹。1つの機能、移行作業、アプリ全体といった大きな作業単位を扱うための仕組みで、数か月にわたって文脈を保ち、数千のサブエージェントにタスクを委任し、指示を待たずに定期的な作業もこなす、とCursorは説明している¹。

同社はProjectsを、2月に示した「ソフトウェア開発の第三の時代」の具体的な実装と位置づけている。エージェントの群れが作業単位をまるごと担い、開発者は個々のエージェントを管理する立場から、作業そのものを方向づける立場に移る、という構想だ¹。

コーディネーターは自分では書かない

Projectsの利用者が話す相手は、プロジェクトごとに置かれるコーディネーターエージェントだ。コーディネーターは自分ではコードを書かず、コードを書く別のエージェントを指揮する¹。Cursorは、実行ではなく委任に徹するので手が塞がることがなく、いつでも指示に応じられると説明している。

これを支える機能としてCursorが挙げるのは3つある¹。

1つ目は「クラウドが既定、必要ならローカル」。Projectは専用のコンピュータ上で動くため、ノートPCを閉じても止まらず、手元のマシンより多くのサブエージェントを並列に動かせる。手元での動作確認が必要な場面では、コーディネーターが利用者のマシン上にローカルのエージェントを立ち上げる。2つ目は共有コンテキストで、各Projectは、配下のエージェントが使うすべてのクラウド・ローカルのマシン間で同期されるファイル群を持つ。エージェントは調べた内容や成果物、コードベースについて分かったこと、利用者が好む進め方をそこに書き足していく。あるエージェントがサービスのテスト方法を突き止めれば、以後のエージェントはその手順を使える。3つ目はSubscriptionsで、コーディネーターはSlackのチャンネルを見張り、スケジュールで起動し、利用者のPRをすべて追ってCIを直したり、PRのオープンやマージに合わせて動いたりする。

8月からの更新が、1つの単位にまとまった

Cursorはこの1か月、クラウドエージェントまわりの発表を続けてきた。8月17日にはコードホスティング「Origin」を早期ベータで公開し、8月19日にはクラウドエージェントがPRやSlackを購読して自分で起動するSubscriptionsや、サブエージェントに専用の仮想マシンを与える機能を加えた。8月27日にはGitHub連携なしでクラウドエージェントを始められる導線、9月2日にはツールの実行を自社ネットワーク内に留めるself-hosted machinesが続いた。

8月19日の時点では、Subscriptionsは個々のクラウドエージェントに付く機能だった。Projectsではそれがコーディネーターの機能として組み込まれ、その下に多数のサブエージェントと、全員が読み書きする共有コンテキストが置かれる。個別に出てきた部品が、「プロジェクト」という1つの単位で束ねられた格好だ。なお、Projectsがself-hosted machines上で動かせるかどうかは、今回のブログには書かれていない。

同じ週には、OpenAIもCodexのハーネスをマネージドで提供するAgents APIをパブリックベータで公開している。長く走るエージェントのセッション管理やサブエージェントへの委譲をツール提供側が引き受けるという点では、向いている方向が近い。

社内での使い方と、レビューを減らしていく進め方

Cursorは、社内で数か月前からProjectsを使っており、数百件のPRにわたる移行作業や、デザインシステムの一貫性の維持、Projects自体の出荷に使ってきたとしている¹。社内のエンジニアの使い方は、機能開発、移行作業、そして終わりのない保守作業を指す「ガーデニング」の3パターンに収まるという。

移行作業について示された進め方は、導入を考えるうえで具体的だ。最初はコーディネーターと安全な方針を詰め、PRを1件ずつ詳しくレビューする。修正が安定してきたらレビューを減らし、コーディネーターが自力で移行を進めていく。ガーデニングの例では、あるエンジニアがデザインシステム用のProjectを動かしている。当初は修正を1件ずつ確認して誤りを直していたが、今はコーディネーターが新しいPRをすべて走査し、デザインシステムに入れるべきコンポーネントを切り出し、同じ誤りを2回見つけるとlintルールを足す。このProjectは1日20〜100件のPRに触れる見込みだという¹。

生産性については、新規ユーザーはマージするPRが30%増え、主にProjectsを使うユーザーは6倍マージしている、という社内の数字が示されている¹。ただし比較の基準や期間は書かれておらず、Cursor自身による測定である点は割り引いて読む必要がある。

導入前に決め直すこと

料金は、ブログにもchangelogにも記載がない¹²。多数のサブエージェントを並列に動かす以上、使った分の計算資源がどう課金されるかは自社のプランで確認するほかない。

権限とレビューの設計も、個々のエージェントを使っていた頃より重くなる。コーディネーターがすべてのPRを追ってCIを直しに行くなら、配下のエージェントがどのブランチにpushでき、どこまで人の承認なしにマージできるのかを先に決めておく必要がある。Cursor自身が示した「安定したらレビューを減らす」進め方も、何をもって安定とみなすかの基準を決めておかないと、単に確認が薄れていくだけになりかねない。

多数のエージェントを同じリポジトリで動かすこと自体の難しさも指摘されている。Anthropicが8月に公開した実験では、30体のエージェントのうち18体が同じブランチ名を作るなど、似たエージェント同士が同じ判断に行き着く失敗の型が示された。コーディネーターが作業を割り振り、共有コンテキストで知見を渡すProjectsの設計は、こうした衝突を調整する役割をコーディネーターに負わせるものとも読める。ベータの間に、自社のリポジトリでどこまで任せられるかを小さな移行作業から試すのが現実的だろう。

Sources

1. Introducing Projects - Cursor公式ブログ（2026年9月10日）
2. Cursor Projects - Cursor公式changelog（2026年9月10日）