• Cursorが数千のサブエージェントを指揮する新機能「Projects」を発表した
• コーディネーターAIは自らコードを書かず、実装を複数のエージェントへ割り振る
• 「PRが6倍」の数字は算出条件が非公開で、独立検証も未確認な点に注意が必要

AIエージェントに、いま何体を同時に動かしていますか。

多くの人はまだ、一体のエージェントに一つずつタスクを渡し、終わるまで待つという使い方をしています。

コーディングツールのCursorが発表した新機能は、その前提を崩し、数千体のエージェントを同時に指揮するという段階へ引き上げようとしています。

「指示する」から「任せる」への転換

Cursorが発表した新機能「Projects」は、機能開発やマイグレーション（既存システムの移行作業）、アプリ全体の構築といった、数か月がかりの大規模な開発を任せるための仕組みです。beta版として、すでに全ユーザーへ順次提供が始まっています。

これまでのAIエージェントは、基本的に「人が一つ指示を出し、エージェントがそのタスクをこなす」の繰り返しでした。Projectsが変えようとしているのは、この単位そのものです。

一つのタスクではなく、一つのプロジェクトを丸ごと預ける。この発想の転換こそが、今回の発表の核心です。

コードを書かない「コーディネーター」という発想

Projectsの中心にいるのは、「コーディネーター」と呼ばれるエージェントです。

面白いのは、コーディネーター自身はコードを一行も書かないという点です。人間はこのコーディネーターとチャットで方針をやり取りするだけで、実際の実装は別の複数のエージェントに割り振られます。

現場監督が自分ではハンマーを握らず、大工や配管工に指示を出して現場全体を管理するのに近いイメージです。開発者は個々の作業を逐一チェックする代わりに、「この方針で進めていいか」という節目の判断に集中できます。

クラウド常駐×必要な時だけローカル、という設計

Projectは基本的に、専用のクラウドコンピュータ上で実行されます。だからパソコンを閉じても作業は止まりません。

ローカル実行に切り替わるのは、手元のマシンでしか確認・実行できない作業が発生したときです。何かが自分のマシンでのテストを必要とするとき、コーディネーターがそこでローカルエージェントを立ち上げる、とCursorは説明しています。具体的にどんな作業が対象になるかは公式には抽象的な表現にとどまっており、ローカルDBに依存するテストやブラウザでの手動確認といった例は外部メディアによる解釈であって、Cursor自身が明言したものではない点には注意が必要です。

さらに、各Projectにはクラウドとローカルの間で同期される共有ファイル群があり、エージェントが学んだコードベースの癖や作業の進め方がそこに蓄積されていきます。毎回イチから背景を説明し直す必要がなくなる、という設計です。

社内活用の3パターン

Cursorは自社の開発で、Projectsを大きく3つの使い方で運用していると説明しています。

• 機能開発:調査→プラン作成→並列実装という順序で進め、人はプランの承認に集中する
• マイグレーション:数百件のPR規模になる新フレームワーク移行などを、最初は1件ずつ細かく確認し、信頼が積み上がるにつれて自律実行の範囲を広げる
• ガーデニング:デザインシステムの品質維持のように、1日20〜100件のPRをコーディネーターがスキャンし、同じ間違いが2回見つかるとlintルール（コードの誤りを自動検出する規則）を追加していく

この3パターンに共通するのは、最初は人がしっかり関与し、実績が積み上がるほどレビューの手間を減らすという段階設計です。いきなり全自動に任せるのではなく、信頼を積み上げてから手を離すという順番になっています。

僕自身はCursorのIDEを普段使っていません。ただ、この「コーディネーターが複数のエージェントを指揮し、クラウド上で作業を継続させる」という設計思想自体は、他のツールでも十分に再現できる汎用的な考え方だと感じています。実際、Claude Codeでも一つのAIが複数のサブエージェントを並列で起動する使い方はすでに広がっており、この方向性はCursor固有の話ではなさそうです。

▶︎ あわせて読みたい：並列サブエージェントの実行コストが「ほぼ無料」という話

エージェントを増やせば開発は本当に速くなるのか

ここで一つ、立ち止まって考えたい論点があります。サブエージェントを増やせば増やすほど、開発は比例して速くなるのでしょうか。

並列化がそのまま速さにつながるのは、各エージェントの担当作業が互いに独立していて、依存関係や統合が不要な場合です。ガーデニングのように1日20〜100件の小さな修正を並列でさばく用途は、この条件に近いといえます。

一方、複数のエージェントが同じコードベースの関連部分を同時に触ると、統合時のコンフリクト解消や整合性チェックという直列の工程が残ります。高速道路の車線を何本増やしても、最後の料金所が一つしかなければ渋滞は解消しません。エージェントを増やすことは車線を増やすことに近く、統合やレビューという「料金所」を増やさない限り、全体の流れは変わらないのです。

つまり、PRの件数が増えることと、価値ある変更が完成することは別物です。この違いを踏まえたうえで、次の「6倍」という数字を見てみます。

「6倍」という数字をどう読むか

Cursorは、新規ユーザーはマージするPRの数が30%増え、主にProjectsを使うユーザーに限ると6倍のPRをマージしたと発表しています。

インパクトのある数字ですが、算出期間や比較条件、対象ユーザーの絞り込み方は公表されていません。しかも「PRがマージされた数」は、コードの質や本番での安定稼働までは測っていない指標です。件数を増やすこと自体が目的化すれば、小さな変更を大量に出すだけでも数字は積み上がってしまいます。

第三者による独立した検証も、今のところ確認できていません。あくまで発表企業自身の主張として受け止め、自社で試したときの実感と照らし合わせる姿勢が必要そうです。

結論:自分の現場で試す前に持っておきたい視点

Projectsのコーディネーターという設計が効くのは、作業同士が独立していて、繰り返す誤りをルール化しやすい領域です。ガーデニングのような定型修正はこの条件に近く、自律性を上げやすいと考えられます。

一方で、統合作業や依存関係の調整、仕様判断が毎回変わる機能開発では、エージェントの数を増やしても、レビューや統合という直列の工程がボトルネックのまま残ります。

導入を検討するなら、公表された数字をそのまま信じるのではなく、まず自分たちの作業のうちどの部分が「独立して切り出せる定型作業」なのかを洗い出すところから始めるのが近道です。料金体系や利用制限もまだ本文だけでは分からないため、そこは実際に触って確かめる必要があります。

よくある質問（FAQ）

Q1. CursorのProjectsとは何か？

機能開発やマイグレーション、アプリ全体の構築といった数か月がかりの大規模な開発を丸ごと任せられる、Cursorの新機能。「コーディネーター」と呼ばれるAIが人間から方針を受け取り、実際の実装は複数のサブエージェントに割り振る。beta版として全ユーザーへ順次提供が始まっている。

Q2. コーディネーターは実際にコードを書くのか？

書かない。コーディネーター自身はコードを一行も書かず、人間とチャットで方針をやり取りするだけの役割に専念する。実装は別の複数のエージェントが担当する。現場監督が自分ではハンマーを握らず、大工や配管工に指示を出して現場を管理するイメージに近い。

Q3. 「PRが6倍」という数字はそのまま信じてよいか？

慎重に見る必要がある。Cursorは主にProjectsを使うユーザーのPRマージ数が6倍になったと発表しているが、算出期間や比較条件は公表されておらず、第三者による独立検証も確認できていない。PRの件数はコードの質や本番の安定稼働までは測っていない指標でもある。

---

新著（7/27発売）『Claude 最強のAI自動化術』：https://amzn.to/4eTUVG1

Claude Codeでエージェント基盤を組み立てる実践は、いけともハンズオンでも扱っています：https://handson.workstyle-evolution.co.jp/

Podcast『いけとも尾原DeepなAIニュース』：https://open.spotify.com/show/3hGAbKZI5oo9PsbFI1IxTr

■合わせて読みたい

■関連記事