2026年9月10日にリリースされたCursor Projectsは、現実の課題に対するCursorの回答です。通常のAIチャットは、閉じた瞬間にすべてを忘れてしまいます。Projectは1つのコーディネーターエージェントを数週間にわたって動かし続けます。このコーディネーター自身はコードを書きません。作業を計画し、クラウドサブエージェントの群れに委任し、レビュー用のプルリクエストを持ち帰ります。Slackチャンネルや開いているPRを監視して、自律的に動くこともできます。
実務でAIエージェントを作っている立場からの率直な感想はこうです。コーディネーター型はまっとうな発想であり、「成長する共有コンテキスト」こそが本当に重要な部分です。落とし穴はコストモデルです。サブエージェントごとにAPI料金を払うため、多数を並列起動するコーディネーターは、無料の生産性向上ではなく従量課金の問題になります。移行や長期的な保守には最適ですが、ちょっとした修正にはやりすぎです。
読み進める前に押さえておきたい前提があります。Cursorはソフトウェアを作るための基盤であり、仕事をこなすチームメイトではありません。サポートやコンテンツ制作など、役割を最初から担うAIが欲しいなら、それは別のカテゴリです。両者が交わる部分は後で触れます。
Cursor Projectsとは何か
Cursorを使ったことがあれば、セッションの流れはご存じでしょう。チャットを開き、タスクを説明し、エージェントがファイルを編集し、レビューして、次へ進みます。タブを閉じればそのコンテキストは消えます。20分の修正ならそれで十分ですが、3週間の移行となると、新しいエージェントにコードベースを何度も説明し直すことになります。
Projectsは後者のために作られています。Cursorはこれを「機能、移行、アプリ全体といった大きな作業に取り組む」ための仕組みと説明しており、Projectは「数か月にわたる作業のコンテキストを保持」し、「指示がなくても定期的な作業を実行」します。2月にCursorが打ち出した「ソフトウェア開発の第三の時代」というビジョン、つまり1つのチャットに付きっきりになるのではなく、エージェントの群れを指揮するという考え方を具体化した製品です。
Cursorによれば、社内で数か月にわたりProjectsを運用しており、数百PR規模の移行も行い、Projects自体の開発にもProjectを使ったといいます。目玉の数字は次のとおりです。新規ユーザーはPRのマージ数が30%増え、Projectsを多用するユーザーは6倍にのぼります。これは社内の自己申告の数字なので、ベンダー自身の生産性統計として割り引いて見るべきですが、この製品が最適化している対象、つまり入力した行数ではなくマージされた作業のスループットがわかります。
全体はベータ版で、公開初日から全ユーザーに順次展開されています。左のナビゲーションから開始し、作りたいものを説明すれば、あとはコーディネーターが進めます。
コーディネーターエージェント：本当の変化
ここが私が強調したい点です。Projectを開いたとき、あなたが話す相手はコーディングエージェントではなくコーディネーターです。Cursorの変更履歴によれば、「Project内のコーディネーターエージェントは自分ではコードを書きません。作業を計画し、実装するエージェントに委任し、完成した作業を確認用に持ち帰ります」。
小さな違いに聞こえますが、そうではありません。コーディネーターは実行せずに委任するため、Cursorによれば「決して塞がらず、常に指示に反応できます」。長いタスクに取り組む単一のエージェントを見たことがある人なら、あの苛立ちをご存じでしょう。進路を変えたいのに、編集の最中で手が届かないのです。コーディネーターは自分でコードに手を入れないので、それを回避できます。あなたに代わってエージェントを作成・管理し、作業に必要なだけ並列で動かします。Cursorはその上限を「1つのコーディネーターを通じて数千のエージェントを指揮する」と表現しています。
その土台はCursorの既存のサブエージェントシステムで、これを理解しておくと、強みとコストの両方が説明できます。各サブエージェントは「独自のコンテキストウィンドウで動作」し、白紙の状態から始まり、自律的に作業して、「結果を親エージェントに返します」。並列実行が可能で、Cursor 2.5以降はサブエージェントが子サブエージェントを起動することもできますが、そこで打ち止めです。子サブエージェントはさらに起動できません。分離を指定すると、それぞれが専用のGit worktree、またはリポジトリの独自クローンを持つ専用クラウドVMを得るため、並列エージェント同士が上書きし合うことはありません。変更は、親がマージするまで別々のブランチに留まります。
Cursor自身のドキュメントにある、正直なトレードオフがあります。サブエージェントを5つ並列で動かすと、1つのエージェントの約5倍のトークンを使います。単純なタスクでは、各エージェントが白紙から始めるため、むしろ遅くなることもあります。買っているのは速度ではなくコンテキストの分離です。Cursorがこれを率直に述べているのは評価できますし、私ならこの一文に利用額アラートを紐づけます。
クラウドが標準：作業が実際に動く場所
Projectはノートパソコンではなくクラウドで動きます。Cursorの表現では「デフォルトはクラウド、必要なときはローカル」です。Projectは「専用のコンピューター上で動くので、ノートパソコンを閉じても止まらず」、「ノートパソコンでは支えきれない数のサブエージェントを並列実行」できます。本当に手元のマシンが必要な作業では、コーディネーターがローカルエージェントを起動してそこで実行します。
これは、Cursorがかつてバックグラウンドエージェントと呼んでいたCloud Agentsの上に構築されています。完全な開発環境を備えた分離VMが、GitHub、GitLab、Azure DevOps、Bitbucketからリポジトリをクローンし、ブランチで作業し、スクリーンショットやログなどの成果物を添えたマージ可能なPRを返します。ブランチをローカルにチェックアウトしなくても、エージェントのリモートデスクトップを操作して、変更後のソフトウェアを試すこともできます。
見落とされがちな準備手順が環境構築です。Cursorははっきりこう述べています。「クラウドエージェントの開発環境を整えないのは、エンジニアにパソコンを渡さないようなものです」。環境はDockerfileまたは保存済みスナップショットで設定し、これを省くとエージェントは手探りで作業することになります。新人を迎えて、ローカル環境の不具合で1日を無駄にするのを見たことがあれば、なぜ重要かおわかりでしょう。同じ手間を、Projectごとに1回払うわけです。
共有コンテキスト：積み上がる部分
私が本当に過小評価されていると思う機能で、Projectsを「名前が少し良くなったバックグラウンドエージェント」以上のものにしているのがこれです。
Cursorの主張は、「タスクを始めるたびにエージェントを教育する必要はないはずだ」というものです。そこで各Projectは、エージェントが使うすべてのクラウドおよびローカルマシンの間で同期されるファイル群を保持します。エージェントは、調査内容、成果物、そして「コードベースについて学んだこと、あなたが好む作業の進め方」をこの共有コンテキストに書き込みます。Cursorが挙げる例はこうです。あるエージェントがサービスのテスト方法を突き止めれば、今後のすべてのエージェントがその手順を使えます。
これが複利的に効く部分です。コンテキストは「Projectとともに成長し、コーディネーターを時間とともに有能にします」。毎朝あなたのコードベースを忘れる外注先と、1か月チームにいる人との違いです。私は、エージェントに最初から適切な社内コンテキストを与えることがすべてというシステムを作ってきましたが、後者のほうが、発表スライドで見るよりずっと価値があると断言できます。また、発表の中で最も地味な機能でもあり、それはたいてい本命である印です。
Subscriptions：自動運転のCursor Projects
もう1つの目玉は、Projectがあなたなしで動けることです。CursorはこれをSubscriptionsと呼び、コーディネーターは「Slackチャンネルを監視し、スケジュールで実行し、すべてのPRを追跡して、CIを修正し、PRの作成時やマージ時に動作」できます。変更履歴の具体例は、Slackを接続してバグ報告チャンネルに向けると、バグが届くたびにコーディネーターが修正を委任し始める、というものです。
内部ではCursorのAutomationsシステムが動いており、Projectsのブログが示すより高機能です。トリガーは、cronスケジュール、ソース管理のイベント（PRの作成、プッシュ、マージ、CIの完了）、Slackメッセージや絵文字リアクション、POST可能なwebhook、Linear、Sentry、PagerDutyのイベントで発火できます。自動化は、PRの作成、コメント、レビュアーの依頼、Slackへの投稿、MCPサーバーの利用を行い、実行をまたいでMEMORIES.mdファイルに永続的なメモを残せます。
頼りにする前に知っておきたい制限が2つあります。現時点では公開SlackチャンネルのみがSlackトリガーから見え、PRトリガーはフォークからのPRでは動作しません（マージトリガーを除く）。どちらも致命的ではありませんが、ワークフローを組んだ後ではなく、組む前に知っておきたい点です。
Cursor Projectsが想定する3つの仕事
Cursorはどこに適するかを驚くほど具体的に示しており、私が実際に使いたい場面とも重なります。
- 機能開発。 Projectはエージェントによるシステム調査から始まり、学んだことを記録します。その後、コーディネーターが計画を立て、エージェントを送り出して各部分を並列でビルド・テストします。リリース後は、同じProjectがログを監視し、「当初の判断の背景にある全コンテキストとともに」バグ報告に対応できます。この最後の点が共有コンテキストの見返りです。
- 移行。 Cursorはこれを「始めるのは簡単だが、終わらせるのは難しい」と呼んでおり、まさにそのとおりです。コーディネーターと安全な進め方を確立すると、それをコードベース全体に段階的に適用していきます。最初は各PRを念入りにレビューし、修正が安定してきたら緩めていきます。
- ガーデニング。 終わりのない作業、つまりコード品質の維持やリグレッションの監視です。Cursorの実例は、デザインシステムのProjectで、コーディネーターが「新しいPRをすべてスキャンし、デザインシステムに属すべきコンポーネントを抽出し、同じミスを2回見たらlintルールを追加」し、1日20〜100件のPRに関わる見込みだといいます。
作業がこの3つのどれにも当てはまらないなら、Projectはおそらく不向きです。Projectを開く前に私ならやる簡単なチェックを用意しました。
Cursor Projectsの料金
ここは慎重に見たいところです。Projectsに定価はありません。Cursorが隠しているわけではなく、本当に従量課金なのです。ProjectsはCloud Agents上で動き、課金もそれに従います。
| 項目 | 課金方法 | 必要なもの |
|---|---|---|
| Cursor Projects（機能そのもの） | 単独の料金なし。ベータ版 | 有料のCursorプラン |
| クラウドサブエージェント | 選択したモデルのAPI料金。初回利用時に利用上限を設定 | 管理者が接続したソース管理 |
| 並列サブエージェント | 5エージェントで1つの場合の約5倍のトークン | 並列化がコストを増やすという認識 |
| Automations / Subscriptions | 各モデルの最大コンテキストで、クラウドエージェントの利用として課金 | 有料プラン。チーム所有の自動化はチームのプールに課金 |
心に留めておきたいのは次の点です。多数のサブエージェントを並列起動するコーディネーターは、コストの乗数であり、タダ飯ではありません。忙しいProjectでは「数千のエージェント」は宣伝上の上限にすぎませんが、フロンティアモデルの料金で数個のクラウドエージェントを並列に動かすだけでも、費用はすぐに膨らみます。これはコミュニティの反応にも出ていた懸念で、もっともなものです。すでにAIエージェントの解決あたりコストを管理しているチームなら、ここでも同じ規律が必要です。利用上限を設定し、自動化されたSubscriptionsは動き続けるメーターとして扱いましょう。
利用者の声
ローンチのツイートは大きな反響を呼び、初日に5,861件のいいねがつきました。ただ、私が最も示唆的だと感じたのは、その11分後に投稿されたトップのリプライです。
"can you pls just merge the subscriptions instead of just adding extra features?"
ローンチ当日の緊張関係が一行に凝縮されています。Cursorは機能を積み上げていますが、熱心なユーザーの一部は、新しい有料の機能を増やすよりも、既存のものを整理してほしいと考えています。機能への批判というより、コーディネーター、クラウド、Subscriptionsの組み合わせが、一度に増えた新しい面としては大きすぎるというサインです。
より鋭い戦略的な問いを投げかけたのは、プロダクトの実務家Aakash Guptaで、2026年4月にCursorのエージェント群へ向かう方向性について書いていました。
"They're saying: the model is a commodity, the workflow is the moat. The question is whether developers want a dedicated cockpit for managing agent fleets, or whether the terminal where the model lives is enough."
これこそがProjectsの本当の賭けだと思います。モデルはますます入れ替え可能になっているので、Cursorはオーケストレーション層、つまりコーディネーター、共有コンテキスト、トリガーこそが顧客を引き留められる場所だと賭けているのです。コックピットがいいかコマンドラインがいいかは、本当に好みの問題で、分別のあるエンジニアでも意見は分かれます。その判断で迷っているなら、Cursorの代替ツールのまとめとCursor vs Windsurfの比較が「コックピット対ターミナル」の幅を扱っています。OpenAI CodexやClaude Code CLIと比較する方にも役立ちます。
Projectsが合う場面、合わない場面
ドキュメントを読み込んだ上での私の見立てはこうです。Cursor Projectsは、私がこれまで見た中で「エージェントの群れを管理する」という発想を最も一貫した形で実現した製品で、その理由は共有コンテキストの設計にあります。コーディネーター型は現実の悩みを解決し、クラウド実行は理にかなっており、トークンコストやサブエージェントの遅さについてドキュメントが正直であることは信頼につながります。
ブレーキを踏みたい点もあります。ベータ版であること、コストモデルが節度を求めること、そして作業が大規模で長期的であることを前提にしていることです。素早い編集をするソロ開発者にとっては、仕事に対して仕組みが大げさで、普通のチャットのほうが適した道具です。また、ローンチのスレッドのある返信がうまく表現した現実的な不安も強まります。コーディネーターが委任すればするほど、人間がレビューして書いたコードの行は減っていきます。Projectsは、返ってくるPRをあなたが規律をもってレビューすることに大きく依存しています。それは欠陥ではなく仕様ですが、責任はあなたにあります。
そしてもう1つ、カテゴリの話をしておく価値があります。発表を読みながら、ずっとこのことを考えていたからです。
Cursorは基盤であり、チームメイトは別物
Cursor Projectsはエージェント型コーディングの基盤です。ソフトウェアを作ります。決まった仕事を引き受けてくれるチームメイトではなく、そうなろうともしていません。これは批判ではなく、実際の違いです。
これはまさに、私たちがeeselで作っているものについての考え方です。eeselはAIチームメイトのプラットフォームで、特定の仕事のために、すぐ働ける準備済みのチームメイトを採用します。サポートキューに加わるAIヘルプデスクのチームメイトと、AIブログライターです。それぞれが役割に必要なスキル、連携、社内コンテキストを備えて登場し、初日から働きます。Cursorがソフトウェアを作るためのコックピットを提供するのに対し、eeselはすでに仕事をこなす同僚を提供します。
興味深いのは、両者が交わるところです。Cursor ProjectsはCLIとトリガーが大好きで、eeselもそうだからです。eesel CLIは、ダッシュボードから使うのと同じeeselのチームメイトとワークスペースを操作する、エージェントに優しい方法です。人がターミナルから実行でき、スクリプトで自動化でき、Cursor、Claude Code、Codexなどのコーディングエージェントが操作することもできます。つまり、アプリを修正しているCursor Projectが、そのついでにeesel CLIに頼んで、サポート担当チームメイトの指示を確認させ、範囲を絞った変更を提案させ、人が承認する前にテスト応答をレビューさせることができます。共有コンテキストという同じ発想を、コードではなく、顧客に応対するチームメイトに適用するわけです。
Projectsを見て、寝ている間にも本物の仕事をするエージェントを思い浮かべたなら、その直感は正しいです。その仕事のうちサポートとコンテンツの領域は、eeselが埋める空白であり、無料で試せます。
コーディングエージェントがやらない仕事にeeselを
Cursor Projectsは請求フローを喜んで作り直してくれます。しかし、その判断が生む400件の「返金はまだですか？」というチケットには答えてくれません。その仕事のために採用するのが、eeselのAIヘルプデスクのチームメイトです。Zendesk（およびFreshdesk、Gorgias、Slackなど）に数分で接続し、過去のチケットやヘルプセンターから学習し、初日から下書き作成や解決を始めます。キューのために採用されたAIエージェントで、席数ではなくチケット単位の定額料金で課金されます。
ターミナルで作業しているなら、そこから離れる必要はありません。eesel CLIを使えば、コーディングエージェントがダッシュボードと同じeeselのチームメイトを確認・調整できるので、コードを出荷するAIが、顧客をサポートするAIの調整も手伝えます。クレジットカード不要でeeselを無料で試し、実際の過去チケットでシミュレーションしてから、実際の会話に触れさせることができます。
よくある質問
Cursor Projectsとは何ですか？
Cursor Projectsは2026年9月10日に公開された機能で、長期にわたる作業（機能開発、移行、アプリ全体など）を1つのコーディネーターエージェント経由で進められます。タスクごとに新しいチャットを開く代わりに、コーディネーターと対話すると、作業を計画し、クラウドサブエージェントに委任し、完成したプルリクエストを返してくれます。
小規模チームにとってCursor Projectsは価値がありますか？
1回のチャットで終わらない作業、つまり移行、継続的な保守、数週間見守る機能開発で真価を発揮します。単発の修正なら、通常のCursorチャットの方が安く簡単です。チームで導入する前に、Cursorのレビュー記事もご覧ください。
Cursor Projectsは指示なしで動けますか？
はい。Subscriptionsと呼ばれる自動化レイヤーが、公開Slackチャンネルの監視、スケジュール実行、プルリクエストの追跡（作成時やマージ時に動作）を行えます。これはCursorのAutomationsと同じエンジンで、GitHub、GitLab、Linear、Sentry、PagerDutyにも接続できます。
Cursor ProjectsとeeselのようなAIチームメイトの違いは何ですか？
Cursor Projectsはソフトウェアを作るためのエージェント基盤です。eeselは、AIヘルプデスクのチームメイトやAIブログライターのように、決まった仕事のために採用し、すぐに使えるチームメイトです。両者は補完関係にあり、Cursorのようなコーディングエージェントはeesel CLIを通じてeeselのチームメイトを操作することもできます。