Cursorは2026年9月10日にProjectsを公開しました。タスクごとに新しいチャットを開く代わりに、1つの永続的なスレッドでコーディネーターエージェントと作業します。コーディネーターは大規模な作業を計画し、実際のコーディングを、主にクラウド上で並列に動くサブエージェント群に任せます。
注目すべきは「エージェントが増えること」ではありません。あなたの仕事の中身が変わることです。1つのエージェントを見張るのをやめ、より高い視点で作業を指揮し、コードが打たれるのを眺める代わりに完成した成果をレビューします。Cursorはこれを「ソフトウェア開発の第三の時代」と呼び、社内では主にProjectsで作業するユーザーは6倍のPRをマージしていると述べています。
1回のチャットより長く続く作業、つまり大型の機能開発、長期の移行、終わりのないメンテナンスには本当に役立ちます。一方で、コストと制御の現実的な問題もあります。多数のクラウドサブエージェントを起動するコーディネーターはAPI料金で課金され、最後にコードを読んだ人間とあなたの間に、より多くのコード行が挟まるからです。私はeeselでエージェントシステムを作る仕事をしているので、以下でProjectsの仕組み、料金、懐疑派の言い分が正しい点、そして「あなたが指揮し、エージェントが作業する」モデルがコード以外でどう見えるかを具体的に説明します。
Cursor Projectsとは何か
Projectは大きな仕事のためのコンテナです。Cursor自身の説明では、「機能、移行、アプリ全体といった、より大きな作業に取り組める」ものです。チャットは閉じた瞬間にすべてを忘れますが、Projectは数か月にわたってコンテキストを保持し、多数のエージェントに委任でき、さらに繰り返しの作業に指示なしで対応することもできます。
左側のナビゲーションから開始し、作りたいものを説明すれば、あとはコーディネーターが引き継ぎます。ベータ版で、公開日から全ユーザーに順次提供されています。
Cursorをオートコンプリートとチャットのツールとして使ってきた人にとって、これは変更履歴の印象より大きな飛躍です。作業の単位は「メッセージ」から「プロジェクト」へ、管理する対象は「コード」から「エージェント」へと移ります。
本当の変化：1つのエージェントからコーディネーターへ
Cursorはしばらく前からこの方向に進んできました。2026年2月の時点で、「エージェント群が作業全体を引き受ける」「第三の時代」を描き、開発者は個々のエージェントではなく作業そのものを指揮するとしていました。Projectsはそのビジョンの実現です。
何が変わったかは、流れを見るのが最も分かりやすいです。
第一の時代では、あなたがコードを書き、AIが次の1行を提案しました。第二の時代（多くのエージェント型コーディングツールは今もここにあります）では、タスクごとに1つのエージェントにプロンプトを送り、作業を見守ります。Projectsは第三の時代への賭けです。あなたはコーディネーターを指揮し、コーディネーターがフリートを動かします。コーディネーターは自分ではコードを書きません。実行ではなく委任するため、「ブロックされることがなく、常に指示に応答できます」。
この最後の点は見た目以上に重要です。1つのエージェントがもどかしいのは、集中して作業に入り込み、あなたが待たされるからです。コーディネーターはサブエージェントが作業している間もあなたと話せる状態を保ち、それが「見張らずに指揮する」という感覚を実際に変えます。
Projectの内部の仕組み
宣伝文句の裏側で、Projectsはすでにあった4つの要素、つまりコーディネーター、サブエージェント、クラウド実行、自動化トリガーの上にある薄いオーケストレーション層です。それらがどう組み合わさるかを見てみましょう。
コーディネーターが計画して委任する
Projectはコーディネーターエージェントとチャットすることで管理します。コーディネーターは「作業を計画し、実装するエージェントに委任し、完了した作業をあなたの確認用に戻します」。あなたに代わってエージェントを作成・管理し、作業に必要なだけ並列で実行します。内部では、各サブエージェントは自分のコンテキストウィンドウで動作し、自律的に実行して、結果を親に返します。Cursor 2.5以降、サブエージェントは自分の子サブエージェントを起動することもできますが、階層は1段までです。
ドキュメントが率直に述べている注意点があります。並列化は無料の高速化ではありません。5つのサブエージェントを並列で動かすと、1つのエージェントの約5倍のトークンを使います。各サブエージェントはクリーンなコンテキストから始まるため、単純なタスクではむしろ遅くなることもあります。得られるのは速度そのものではなく、分離とスケールです。
基本はクラウド、必要ならローカル
ProjectsはCloud Agents（以前はBackground Agentsと呼ばれた分離されたクラウドVM）上で動きます。Projectは「自分専用のコンピューターで動くので、ノートPCを閉じても止まらない」ため、手元のマシンより遥かに多くのサブエージェントを並列で動かせます。手元のマシンで実行すべきものがあるときは、コーディネーターがそのためのローカルエージェントを起動します。
ここで本当に重要なのは環境です。Cursorの言葉では、「クラウドエージェントの開発環境を整えないのは、エンジニアにコンピューターを渡さないようなもの」です。環境はエージェント主導のセットアップ、保存したスナップショット、Dockerfileのいずれかで定義し、クラウドエージェントはGitHub、GitLab、Azure DevOps、Bitbucketからクローンして、引き渡しのためにブランチへプッシュします。Claude CodeのGitHub連携などを設定したことがあれば、形はおなじみのはずです。
積み上がる共有コンテキスト
ここが最も過小評価されていると私が感じる部分です。Cursorの言葉は「タスクを始めるたびにエージェントをオンボーディングする必要はないはずです」。各Projectは、エージェントが使うすべてのクラウドとローカルのマシンで同期されるファイル群を保持し、エージェントはそこに調査、成果物、コードベースについて学んだことを書き込みます。例として、「あるエージェントがサービスのテスト方法を見つければ、以降のすべてのエージェントがその手順を使えます」。
その結果、コンテキストはProjectとともに成長し、コーディネーターは時間とともに有能になります。これは、毎回セッションごとに製品を説明し直す代わりに、AIサポートエージェントに本物のナレッジベースを与えるのと同じ原則を、コードベースに向けたものです。
サブスクリプションでプロンプトなしに動く
コーディネーターはSlackチャンネルを監視したり、スケジュールで実行したり、すべてのPRを追ってCIを修正し、PRが開かれたりマージされたりしたときに動いたりできます。Cursorはこれを「サブスクリプション」として打ち出していますが、ドキュメント上はAutomationsシステムで、スケジュールやGitHub、GitLab、Slack、Webhook、Linear、Sentry、PagerDutyのイベントでクラウドエージェントを起動します。バグ報告チャンネルに向けておけば、バグが入るたびに委任を始めます。これはProjectsを「開くツール」から「動き続けるもの」に変える自動化の層であり、新しいメッセージに反応して動くSlack AIチャットボットやAIヘルプデスクチャットボットと同じトリガー駆動の考え方です。
Projectsが想定する3種類の作業
Cursorはどこに向いているかについて、すがすがしいほど具体的で、それは3つのパターンに対応します。Projectsは5分で終わる修正向けではまったくないので、ここは押さえておく価値があります。
- 機能開発。 エージェントがシステムを調べ、学んだことを共有コンテキストとして記録し、コーディネーターが計画し、サブエージェントが各部分を並列で構築・テストします。リリース後も、同じProjectがログを監視し、当初の判断の背景にある完全なコンテキストを持ってバグ報告に対応できます。
- 移行。 Cursorの表現では「始めるのは簡単で、終えるのは難しい」作業です。コーディネーターと安全な方法に合意すると、コーディネーターがその方法をコードベース全体に段階的に適用します。最初は各PRを念入りにレビューし、パターンが安定したら緩めていきます。
- ガーデニング。 コード品質や回帰など、終わりのない作業です。Cursor自身の例は、デザインシステムのProjectで、コーディネーターが新しいPRをすべてスキャンし、コンポーネントを抽出し、同じミスを2回見たらlintルールを追加し、1日に20〜100件のPRに関わるペースです。
共通点は、その作業が「1回のチャットより長く続く」場合に効果が出ることです。手早いバグ修正には、通常のエージェントの方が速くて安上がりです。
自分の作業がどれに当たるか迷うなら、Projectを立ち上げる前に次の簡単なチェックを試してください。
相性は良好です。まずエージェントに調査させ、コーディネーターに計画させ、各部分を並列で構築・テストし、後のバグ対応のためにProjectを残しておきましょう。
Projectsの典型例で、始めるのは簡単、終えるのは難しい作業です。コーディネーターと安全な方法を固め、最初のPRを念入りにレビューし、パターンが確かめられたら緩めていきます。
サブスクリプションを設定して、コーディネーターにすべての新しいPRを監視させ、パターンを抽出し、lintルールを追加させましょう。「あなたなしで動く」の最適な使いどころです。
代わりに通常のCursorエージェントを使いましょう。1回限りの修正にコーディネーター、共有コンテキスト、クラウドVMは不要で、Projectでは得るものなしにトークンだけが余計にかかります。
Cursor Projectsの料金
Projectsに定価はなく、それが正直な結論です。ProjectsはCloud Agents上で動き、Cloud Agentsは選択したモデルのAPI料金で課金されます。クラウドエージェントを実行するには有料のCursorプランが必須で、まず管理者がソース管理を接続する必要があります。費用の全体像を分かりやすくまとめます。
| 項目 | 仕組み | 注意点 |
|---|---|---|
| プラン要件 | クラウドエージェントの実行には有料のCursorプランが必要 | 無料プランではクラウドでProjectsを実行できない |
| 課金単位 | クラウドエージェントは選択したモデルのAPI料金で課金 | 費用は月額定額ではなく、使用トークンに比例 |
| 並列実行 | コーディネーターは作業に必要なだけサブエージェントを実行 | 5つのサブエージェントを並列 ≈ 5倍のトークン |
| 支出管理 | 初回利用時に支出上限を設定 | 上限が唯一のガードレールで、デフォルトでは固定の上限なし |
| Automations | サブスクリプションはクラウドエージェントの使用量で課金され、各モデルの最大コンテキストウィンドウを使用 | コンテキストの切り替えがないため、バックグラウンド実行はトークンを大量に消費しうる |
具体例で考えてみましょう。Cursorが述べるデザインシステムの「ガーデニング」Projectは、1日に20〜100件のPRに関わるペースです。その1回1回の実行がクラウドエージェント（しばしば複数のサブエージェント）で、モデルのAPI料金で、見ていてもいなくても一日中課金されます。エンジニアの人件費と比べれば素晴らしい取引にも、驚きの請求にもなり得ます。それは完全に、支出上限とモデルの出力量次第です。だからこそProjectsではCursorの料金の全体像がこれまで以上に重要で、使用量ベースの費用への不安がコミュニティの反応で繰り返し出てくるテーマになっています。そこで、興味深い話題に移りましょう。
「エージェントフリートのコックピット」は開発者が本当に求めているものか
ここは公平でありたいところです。公開当日の反応は拍手だけではなかったからです。公開時の投稿は5,861件のいいねを集めましたが、最も目立った初期の返信は感嘆ではなく疲労感でした。
"can you pls just merge the subscriptions instead of just adding extra features?"
これは告知投稿そのものへの最上位コメントです。実際の懸念を捉えています。Projectsは、すでに盛りだくさんの製品の上に、さらに有料でクラウド従量課金のサーフェスを積み重ねているというものです。また2026年4月には、プロダクトライターのAakash Guptaが戦略上の賭けを的確に表現しました（今回の公開ではなく、Cursorの方向性について書いたものです）。
"Cursor's move is to go vertical on the orchestration layer... 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."
この2文が議論のすべてです。レビューしやすく構造化されたサーフェスを好む開発者もいます。2026年7月に書いたElliot Arledgeは、賛成の立場をうまく述べています。
"for most important dev and contracts I've been doing, cursor is my go-to and its not even close... being able to inspect code and ensure that production systems don't get slopified is super important to me."
同じスレッドへの返信にある反対側の不安が、私が最も真剣に受け止めるべきだと思うものです。「I really fear losing control over my codebase」（コードベースの制御を失うのが本当に怖い）。コーディネーターが委任するほど、1人のレビュアーが実際に読む行は減ります。これはProjectsを避ける理由ではありません。初日のレビューの規律を保つ理由です。特にパターンが「安定してきて」流し読みしたくなるときこそそうです。他のツールと比較検討するなら、Cursorの代替ツールやCursorとWindsurfの比較の記事で、それぞれの立ち位置が分かります。
コード以外での「フリートを指揮する」モデル
eeselでエージェントシステムを作っていて最も印象的だったのは、Cursor Projectsがあちこちに現れつつあるパターンのコーディング版の実例だということです。計画して委任するコーディネーター、作業を行うサブエージェント、積み上がる共有コンテキスト、プロンプトなしに動かすトリガー。「コードベース」を「サポートキュー」や「コンテンツパイプライン」に置き換えれば、アーキテクチャは同じです。
eeselはまさにそう作られていて、向ける仕事が違うだけです。eeselはAIチームメイトのプラットフォームで、万能ボットではなく、特定の役割ですぐに働けるチームメイトを採用します。現在のラインナップはAIヘルプデスクチームメイトとAIブログライターで、それぞれが仕事に必要なスキル、連携、会社のコンテキストを備えて加わります。ヘルプデスクのチームメイトは既存のキューに参加してチケットを下書きまたは解決し、ブログライターはこの記事が作られたのと同じ方法で長文コンテンツを調査して書きます。Cursorが売る「あなたが指揮し、エージェントが作業する」という同じ変化を、プルリクエストではなくカスタマーサービスの自動化とSEOコンテンツチームに向けたものです。
この記事は本質的にエージェント型でターミナル主導のワークフローの話なので、CLIの対比も説明しておく価値があります。Cursorでは、エディターから/in-cloudや/autopilotなどのコマンドでクラウドのサブエージェントを操作できます。eeselはチームメイトに対して同種のプログラム可能なサーフェスを提供しています。eesel CLI（@eesel/cli）は実際のnpmバイナリで、そのドキュメントには文字通り「everything on this site can be done from the terminal」と書かれています。eesel integrations connectで連携し、eesel instructionsでエージェントの常設ルールを編集し、eesel approvalsでリスクのある操作を制御し、eesel activityですべての実行を新しい順に確認できます。すべてのコマンドはJSONを出力して--dry-runに対応するのでCIにそのまま組み込め、各ワークスペースはMCPサーバーでもあり、他のMCP連携と同じように接続できます。つまり、Cursor、Claude Code、Codexのようなコーディングエージェントが、サポートやコンテンツのチームメイトを直接操作できます。このeesel activityのオブザーバビリティ画面は、Cursorの「bring the finished work back to you to check」とほぼ一対一で対応します。
サポートやコンテンツのチームメイトが、コーディングのコーディネーターより踏み込まなければならない点が1つあります。エージェントが実際の顧客と話しているときは「PRを1件ずつレビューする」ことができません。だからeeselは、返信する前に実際の過去のチケットでチームメイトをシミュレーションでき、信頼できるまでアクションを承認の後ろに置けます。これはCursorの懐疑派が指摘しているのと同じ教訓を、人に直接届く仕事に当てはめたものです。
eeselを試す
Cursor Projectsで「エージェントのフリートを見張らずに指揮する」モデルに納得し、サポートやコンテンツのチームを運営しているなら、それがまさにeeselがそれらの仕事のために行っていることです。AIヘルプデスクチームメイトをZendesk、Freshdesk、Gorgias、Slackに接続すれば、履歴とヘルプセンターを学習してチケットの下書きと解決を始めます。あるいは、別々のAIライティングツールをつなぎ合わせる代わりに、AIブログライターをコンテンツパイプラインに向けられます。ダッシュボードからも、eesel CLIとMCPサーバーを使ってターミナルだけでも操作でき、公開前に実データでシミュレーションできます。無料で試せます。
よくある質問
Cursor Projectsの料金はいくらですか？
Projects専用の料金はありません。ProjectsはCursorのCloud Agents上で動き、選択したモデルのAPI料金で課金されます。クラウドエージェントを実行するには有料プランが必要です。コーディネーターは多数のサブエージェントを同時に起動できるため、費用は定額ではなく使用量に比例します。プランの詳細は、Cursorの料金の詳しい解説をご覧ください。
コーディネーターエージェントは通常のCursorチャットとどう違いますか？
通常のチャットは目の前で作業を行います。コーディネーターは自分ではコードを書きません。計画し、サブエージェントに委任し、完了した作業をレビュー用に戻してくれます。これはOpenAI CodexやGitHub Copilotなどのツールにも見られる、エージェント型コーディングへの同じ流れです。
Cursor Projectsは見ていなくても動きますか？
はい。Projectsは「サブスクリプション」を使い、コーディネーターがプロンプトなしでSlackチャンネルを監視したり、スケジュールで実行したり、PRを追ってCIを修正したりできます。他のツールの自動化されたエージェントワークフローと同じ考え方です。サポート業務では、eeselのAIカスタマーサービスワークフローが同じトリガー駆動のモデルで動きます。
Cursor Projectsは本番のコードベースで安全に使えますか？
人間が確認する体制を保てば使えます。サブエージェントは分離されたブランチや専用のクラウドVMで作業でき、コーディネーターはマージ前に完了した作業をレビューに回します。本当のリスクは、信頼が増すほどレビューが減ってしまうことです。顧客対応の業務でエージェントを動かすなら、eeselのようなツールで、実際の履歴に対してシミュレーションし、アクションを承認の後ろに置いてから始められます。