開発をより効率化するCursorの新機能 [Cursor Projects]を試してみた

こんにちは、せーのです。

2026年9月10日、Cursor から新機能 Projects が Beta として発表されました。公式ブログ（日本語） と Changelog が同時に出ていて、公式Xの発表投稿も公開直後からかなり伸びていましたね。

「数千エージェント」というコピーは目立ちますが、業務に組み込むときに地味に効くのは、たぶん別のところです。1チャット1タスクをやめて、仕事ごとまとめて預けられる単位ができた、という話です。今日は公式情報を整理したうえで、発表翌日に手元で確認した内容まで書きます。

細部は公式を正としてください。製品としての説明は Projects の紹介 にまとまっていて、実行基盤にあたる部分は Cloud Agents と Automations のドキュメントで補う、という読み方をしています。

先に切り分けておく

Cursor には、昔から「プロジェクト」という言葉がいくつかあります。今回の機能は、そのどれとも違うので、最初に整理しておきます。

DevelopersIO にも Rust の CLI を AI Project で作る記事 がありますが、あちらは足場生成の話です。今回の発表とは別物なので、検索するときは気をつけてください。

何ができるようになったか

公式の一文が、いちばんわかりやすいです。

Rather than creating a chat for every task, you work with a coordinator agent in a single, persistent thread.

出典: 公式X（2026-09-10）

Projects を開くと、相手は実装するエージェントではありません。コードを書かないコーディネーターです。計画を立て、実装するエージェントへ委任し、できあがったものを確認用に戻す、という役回りです。公式ブログの言い方だと、実行ではなく委任に徹しているぶん処理待ちで止まらず、常に指示に応答できる、とのことです。Changelog の表現では、実行基盤は Powered by Cloud Agents と書かれています。

公式ブログは、次の3つをコア能力として挙げています。

1. デフォルトはクラウド、必要なときはローカル
   Project は専用のコンピュータ上で動くので、ノートPCを閉じても止まりません。手元のマシンでは処理しきれない数のサブエージェントを並列で動かせる、というのが公式の狙いのようです。手元で試したいときだけ、コーディネーターがローカルエージェントを起動します。
2. 共有コンテキスト
   プロジェクト固有のファイル一式が、クラウドとローカルの全エージェントで同期します。リサーチ内容や成果物、コードベースについて学んだこと、好みの進め方まで残るので、次のエージェントに毎回オンボーディングしなくてよくなります。公式の例では、あるエージェントがサービスのテスト方法を突き止めれば、以降のエージェントもその手順をそのまま使えるそうです。
3. Subscriptions
   Slack チャネルの監視やスケジュール実行、自分が出した PR の追跡まで任せられます。CI 修正や open / merge への反応を、プロンプトを待たずに行う、というのがポイントです。Changelog の例では、バグ報告チャンネルを指しておくと、報告が来るたびに委任が始まるとのことでした。

2026年2月に出た third era 論は、ソフトウェア開発を3つの時代に分けて説明していました。

1. 第一の時代（Tab） — 1キーストロークずつ書いていたコードを、Tab の自動補完が肩代わりした時代。低エントロピーで繰り返しの多い作業を見つけて自動化する、という段階です
2. 第二の時代（同期エージェント） — チャットでエージェントに指示し、応答を待ってまた指示する、同期のプロンプト応答ループの時代。Tab より上流の、文脈と判断が必要な作業まで任せられるようになりましたが、リアルタイムでのやり取りが前提なので、人がずっと張り付く必要があり、同時に見られるエージェントも数個が限界でした
3. 第三の時代（フリート） — より長い時間軸で、より大きな仕事を、より少ない人の指示で進められるエージェント群の時代。Cursor 自身、社内でマージする PR の3分の1以上がクラウド上で自律的に動くエージェント発のものになっていて、この時代では開発者は「コードを書く人」ではなく、自分のソフトウェアを作る工場（fleets of agents）を構築し、運用する人になる、という言い方をしています

Projects の発表ブログは、この third era 論を直接引いて、**「Projects is the concrete implementation of that vision（Projects は、そのビジョンの具体的な実装である）」**と書いています。抽象度をひとつ上げた製品化、というのはこの一文のことです。開発者はエージェントを1つずつ管理する作業から離れて、コーディネーターに仕事そのものを指揮させる側に回れる、という位置づけです。

Chat / Cloud Agent / Automation / Project

Cursor 3.0 の記事では、Agent Tabs や Automations を試しました。Self-Hosted Machines は、Cloud Agent の手足をどこに置くかという話でした。Projects は、そのさらに上に乗る層です。

違いを整理すると、Cloud Agent は手足、Automation は起動装置、Project は記憶と編成を持ったプロジェクトマネージャー、というイメージです。

Subscriptions の実体は、既存の Automations にかなり近そうです。Automations の公式ドキュメントを見ると、トリガーには cron、GitHub / GitLab / Bitbucket の PR、Slack（公開チャンネルのみ）、webhook、Linear、Sentry、PagerDuty まで用意されています。fork 由来の PR では発火しない、という制限もここに書かれています。ただ、Projects の発表単体では、画面が Automations と同一かどうかまでは触れられていません。

Cursor 社内の使い方

公式ブログは、用途を3つに限定して説明しています。ここが、実際に自分たちで使うかどうかを決める判断材料になりそうです。

機能開発

まとまった規模の仕事ごとに Project を作る、というのが公式の想定です。まずエージェントが調査して共有コンテキストへ書き、コーディネーターが計画を立てて、実装とテストを並列で委任します。フィードバックを重ねるたびにアーキテクチャや好みを学習していき、試せる段階になったら手元のコンピュータでエージェントを起動します。出荷したあとも、同じ Project がログ監視とバグ対応を、当時の判断文脈ごと引き続き担当してくれる、とのことです。

マイグレーション

「着手は簡単でも、完了させるのが難しい」タイプの仕事に向いています。社内では、新フレームワークの導入やスタイリング置き換えを、数百PR規模で進めたと書かれています。まずコーディネーターと安全な進め方を決め、それをコードベース全体へ段階的に適用していく流れです。最初は PR を厚くレビューし、安定してきたらレビューを薄くして、以降はコーディネーターに消化させる、という進め方をしているようです。

ガーデニング

こちらは終わらない仕事です。品質維持や回帰監視がこれに当たります。コーディネーターに新しい PR を追わせたり、Slack のバグ報告を待ち受けさせたり、スケジュールで動かしたりできます。社内のデザインシステム Project では、同じミスが2回出たら lint ルールを足す、という運用まで進んでいて、1日 20〜100 PR に触れる想定だと書かれていました。エンジニアが実際に見るのは、注意が必要な箇所だけ、というのが公式の説明です。

公式ブログ共著者の Fredrika Lindh さん は、もう少し具体的な数字を出しています。virtualization プロジェクトで約50 PR をマージ済み、実装とテストはクラウド側にまかせて自分は最終デモとコードだけ見る、毎日 slop や重複をスキャンする長期エージェントがあり、朝には10〜30 PR が待っている、とのことです。ご自身のマージ数は3倍に増えた、とも書いていました。

公式ブログ側にある「新規ユーザーは PR マージが30%増、Projects を主に使うユーザーは6倍」という数字は、あくまでベンダーの自己申告です。参考にはなりますが、自チームの実測と混ぜて考えないほうがよさそうです。

料金とレビュー責任

Projects 単体の定価は、発表資料のどこにも見当たりません。実行は Cloud Agents なので、課金もそちらに従う、というのが今のところ一番堅い整理だと思います。

• Cloud Agents は選択したモデルの API 料金がかかります。初回に spend limit を求められます
• Subagents の公式説明によると、5並列はおおよそ5倍のトークンを消費します。単純作業ではむしろ遅くなることもある、とまで書かれています
• Automations は Cloud Agent 従量で、モデルは最大コンテキスト固定です
• Cloud Agents 自体が有料プラン前提の機能です

「thousands of subagents」は必須の数ではなく、天井を示す言い方だと捉えたほうがよさそうです。小さな機能なら少数でも十分足ります。並列にするほどコストは乗数で増えていくので、ガーデニングを毎日回す前に、まずは limit を置いておいたほうが安心です。

セキュリティについても、Projects 専用のドキュメントはまだありません。実行が Cloud Agents である以上、Cloud Agent security が当面の正になりそうです。成果は draft PR として出て、マージは人間が行い、Privacy Mode は必須、というのが要点です。コーディネーターが委任するほど、1行1行を実際に書いた人間はいなくなっていきます。だからこそ、レビュー規律そのものが機能の一部になってくる、という印象です。

Self-Hosted Machines の上で Projects が動くかどうかは、発表時点では触れられていません。データ主権の要件がある場合は、先にそちらを確認しておいたほうがよいと思います。

やってみた

ここからは、実際に Project を1つ作り、最初の1手からdraft PR、共有コンテキスト、Subscriptionsまで、公式が挙げていた確認ポイントを一通り試した記録です。

発表翌日（2026-09-11）の状態

手元の構成は次のとおりでした。

Agents Window のアクセシビリティツリーからも、Projects という項目は拾えませんでした。表示が無いこと自体を不具合と決めつけないほうがよさそうで、Changelog にも rolling out と明記されていました。

2026-09-14、実際に Project を1つ作ってみた

左ナビに Projects セクションが現れ、+ から New Project を作れるようになっていました。

検証用に、標準ライブラリのみで動く最小構成のタスク管理CLI（cursor-projects-verify）を新規に用意し、これをワークスペースとして指定しました。

Create Project を押すと、まず Setting up environment という表示に変わり、少し待つと「Tracks the decisions, agent work, and follow-through needed to move New Project forward.」という説明文と、View Project Page へのリンクが出てきました。チャットを1本開いた、というより、そのプロジェクト専用のダッシュボードを1枚作っている、という見え方です。

最初の依頼は、次のように送りました。

task_cli に remove <id> コマンドを追加してください。指定した id のタスクを tasks.json から削除します。存在しない id を渡した場合は "Task not found" とエラー終了してください。テストも1つ追加してください。

12秒後に返ってきたのは、diff ではなく計画の要約でした。

remove <id> を task_cli に足します。指定 id を tasks.json から消し、無いときは Task not found でエラー終了。テストも1つ追加します。

その直後、ステータスは 1 Working · Planning next moves に変わり、下部には Working 1 というチップが表示されました。コーディネーターが自分でコードを書き始めるのではなく、依頼を1文で言い換えたうえで、実装は別の1体（サブエージェント）に投げている、というのが画面から読み取れます。公式ブログの「コーディネーターはコードを書かず、書くエージェントへ委任する」という説明と、動き自体は一致していました。

画面の上のほうには、薄い文字で「Anytime you want this to run differently, say so and I'll remember.」という一文も出ていました。これは、公式が言う共有コンテキスト（好みの進め方を学習して残す仕組み）の入り口だと思われます。

2分45秒後、draft PR が上がってきた

放っておくと、Worked 2m 45s の表示のあと、こんな返答が来ました。

remove <id> を追加しました。指定 id を tasks.json から消し、無いときは Task not found でエラー終了します。テストも1つ追加して、既存テストと合わせて通過しています。

PR #1 を見てください。レビューや CI の結果が来たらこちらで拾います。

下部のタブは Agents / PRs 1 / Listening 2 に増えていました。特に Listening 2 は、Subscriptions を自分では何も設定していないのに出てきた表示で、Project がこの PR 自体の動き（open / CI / merge あたり）を、何らかの形で勝手に見に行っていることを示しているように見えます。公式ブログにある「CI 修正や open / merge への反応をプロンプトを待たずに行う」という Subscriptions の説明と重なる部分です。ただ、これが Subscriptions と同じ仕組みなのか、Project 標準の付随機能なのかは、この画面だけでは判断できませんでした。

右側には GitHub の PR 画面がそのまま埋め込まれていました。

gh pr diff で実体を確認したところ、task_cli/main.py に cmd_remove が追加され、tests/test_main.py にも成功パターンと Task not found の異常系を両方カバーするテストが追加されていました。依頼した内容（削除・存在しないidのエラー処理・テスト追加）は、そのとおりに実装されています。CI は元のリポジトリに何も設定していないので、Checks タブは空のままでした。

Mark as Ready を押すかどうかは、まだこちらで判断していません。 公式の言う「レビューは人間」の境界線を、まさにここで人が引くことになります。

共有コンテキストのファイルを覗いてみる

チャット画面上部の View Project Page（または右上の Project アイコン）を開くと、All Files という一覧が出てきました。

公式の言う共有コンテキストは、単なる1枚のファイルというより、Project 用（全エージェント共有）と User 用（人間の好み）でフォルダが分かれている構造でした。notes.md を開くと、中身はチェックリストの1行だけでした。

☑ remove command ready to review

リサーチの積み重ねというよりは、「何をやったか／レビュー待ちかどうか」を追うタスクログ、という見え方です。公式ブログは「コードベースについて学んだこと」まで残ると書いていましたが、今回はタスクが1件だけなので、そこまで育った状態はまだ見られていません。

2件目を依頼して、notes.md の増え方を見る

同じ Project のスレッドに、続けて2つ目の依頼を送ってみました。

add / list に --priority を足します。指定なしは medium、list は指定優先度だけ表示。テストも既存パターンで追加します。

11秒後にまず計画の要約が返ってきて（1件目と同じ流れです）、2分41秒後に完了報告が来ました。

優先度オプションを入れました。add --priority は high / medium / low（省略時は medium）で tasks.json に保存し、list --priority <level> で絞り込みます。テストは既存含めて4件通過しています。

PR #2 です。remove の PR #1 とは別ブランチです。

「remove の PR #1 とは別ブランチです」とわざわざ言ってくれるあたり、1件目の作業を認識したうえで今回の作業を進めている、というのが伝わってきます。下部のタブも PRs 2 / Listening 4 に増えていました（1件目終了時は PRs 1 / Listening 2 だったので、PRごとに2つ分の Listening が積まれていくようです）。

notes.md を開くと、こうなっていました。

☑ priority options ready to review
☑ remove command ready to review

1件目の行がそのまま残り、2件目が上に積まれる形でした。書き足す方向は「新しい方が上」で、消えたり要約し直されたりはしない、というのが今回わかったことです。

gh pr diff で PR #2 の実体も確認しました。テストコードを見ると、1件目の test_remove で使っていた run() ヘルパー、try / finally で tasks.json を後始末する書き方が、今回追加された3つのテスト（優先度の保存確認・不正な値の拒否・list --priority の絞り込み）でもそのまま使われていました。同じセッション内の会話履歴から拾っているだけなのか、notes.md のような共有ファイル経由で学習しているのか、外からは区別できませんが、少なくとも「1件目のやり方を2件目が引き継ぐ」という公式の説明どおりの結果にはなっています。

Listening の中身は、そのまま Subscriptions だった

Listening 4 のチップをクリックすると、開いたパネルのタイトルがそのまま Subscriptions でした。中身は次の4件です。

PR を1つ作るごとに、「そのPRへのコメント」と「そのブランチのCI実行」の2件が自動で Subscriptions に積まれていました。つまり、自分で何か設定しなくても、Project が作った draft PR は最初から Subscriptions の監視対象に入る、というのが実際の動きです。公式ブログの「自分の全PRを追跡し、CI修正やopen/mergeに反応する」という説明は、ここに書いてあったとおりでした。

ただし、これはあくまでProjectが自分で作ったPRに対する自動購読です。公式が挙げている「Slackチャネルの監視」や「スケジュール実行」のように、PRと無関係な起点を自分から明示的に追加するところまでは、まだ試せていません。

スケジュール実行を明示的に頼んでみる

「毎朝9時」だと結果が翌日までわからないので、まずは短い間隔で検証しました。

5分ごとに、このリポジトリで新しく作られたPRやIssueをチェックして、対応が必要そうなものがあれば報告してください。

18秒後に受理の返事、37秒後にこう返ってきました。

いま見えている新規はなく、既知は PR #1 と PR #2 だけです。Issue は API 権限がなく読めないので、PR側だけ5分ごとに見ます。

依頼そのものは受理され、GitHub の権限的な制約（Issue が読めない）まで自分で確認して、スコープをPRだけに絞ってくれました。 ここは委任先としてかなり律儀な対応です。

返答が来た直後は Listening の数字がまだ 4 のままで、一瞬「口約束で終わったのか」と思ったのですが、1分ほど待って Subscriptions パネルを開き直すと、5 に増えていました。 一覧の一番上に、他の項目とはアイコンが違う（GitHubマークではなく時計マーク）新しい行が増えています。

Repo PR issue watch every 5 minutes — 1m

自然文でお願いしただけで、スケジュール実行の Subscription がひとつ、ちゃんと作られていました。 GitHubのイベント起点（Comments / CI runs）と、時間起点（every 5 minutes）が同じ Subscriptions パネルに並ぶ、というのも今回わかったことです。反映に少し遅延があったので、依頼直後にパネルを見て「増えていない」と判断するのは早計、というのも実測の教訓でした。

ここまでの進捗

1. ✅ 左ナビから Project を1つ作る
2. ✅ 最初の応答が実装ではなく計画・委任になっているかを見る
3. ✅ 共有コンテキストのファイルを覗く → notes.md にタスクごとの1行ログ。2件目を依頼したら2行に増え、1件目のテストの書き方も引き継がれた
4. ✅ 戻ってきた draft PR を、マージせずレビューする
5. ✅ Subscriptions を1本足す → Listening = Subscriptions。PRごとの自動購読（Comments / CI runs）に加えて、「5分ごとにチェックして」と自然文で頼んだだけでスケジュール実行の購読も1本追加できた

公式の5ステップは、これで一通り実測できました。題材は、チャット1本で終わるような修正ではなく、公式の言う「1回の chat では終わらない仕事」に寄せて選びました。もちろん顧客リポやシークレットは使わず、今回のために新規で作った検証用リポジトリだけで進めています。

Project と Grok Bot の使い分け

発表を読んでいて、頭の中ではちょうど似たようなスキームを組んでいたところでした。常駐する司令塔を Grok Bot で作り、Slack やスケジュールでの起動を Automations で足す、というイメージです。Projects は、それを一つの入口にまとめたサービスなのか、それとも別の仕組みなのか、というのが気になったので考えてみます。

公式の書き方を見る限り、Grok Bot と Automation を束ねた包み、というわけではなさそうです。起動のしかたが似ているだけで、中身はかなり違います。

Grok Bot は、自分で手を動かす同僚に近い存在です。公式 も、目的・道具・進め方・承認の境界が違うなら Bot を分けたほうがいい、と書いています。一方の Project のコーディネーターは実装しません。委任先は Cloud Agent で、公式が想定する成果はあくまで draft PR です。Subscriptions が Automations と同一の画面なのかどうかは、今の発表資料からは判断できませんでした。

以前、NEC の「AI部署」を読んだ記事 で、性格を持った「AI社員」を増やすより、仕事が終わっても責任が残る役割だけを Owner として残す、という考え方を書きました。この考え方を Grok Bot に当てはめるなら、残しておくべきアイデンティティは Owner だけで十分です。今回の仕事だけ手を動かす Worker のほうには、社員証は必要ないと思います。

違いを整理すると、こうなります。

• コードを書いて実装・運用する仕事は、Project のコーディネーターを背骨にする
• 調べて、上司や取引先へ出す文章を作る仕事は、Grok Bot の Owner を背骨にする
• 文章側の結論をリポにも落とすときだけ、既にあるコード用 Project へ渡す。通知や議事のたびに Project を新規で立てたりはしない

Worker の実体も、ここで自然と分かれます。実装とテストは Cursor の Agent（Cloud Agent や、Project が委任するサブエージェント）が担当します。調査や下書きのほうは、同じ Grok Bot の中で一回作業させるか、承認の境界が違うときだけ別の常設 Bot へ手渡す、という形になりそうです。Grok Bot を作業のたびに作って消す、でも、Grok Bot から Cursor CLI で艦隊を組む、でもありません。後者については、公式の連携としてはまだ書かれていません。

リサーチをコード用 Project にそのまま投げると、調べた結果を「直せる」と見て PR を切り始めたり、共有コンテキストに実装前提の学びが残ったりしやすくなります。これはコーディネーター本人がコードを書くからではなく、委任先が実装する Cloud Agent であり、公式が想定する成功例そのものが draft PR だからです。

人が介在すべきなのも、実は入口ではありません。会議の場で「何を直すか」「何を返すか」は、もう決まっています。同じ判断をもう一度人間がやり直すのは、原則として無駄です。公式のバグ報告チャンネルの例と同じで、議事録や通知をシグナルにしてタスク化し、そのまま委任してしまってよいはずです。人が見るべきなのは、あくまで出口だけです。コードならマージ、文章なら上司や取引先へ出す許可、というところですね。Issue を残すなら、人が押すボタンというより、自動で切った仕事の単位、くらいの位置づけで十分だと思います。

ちなみに、フォルダに議事録を置いただけでは、公式の Subscriptions のトリガーには引っかかりません。Slack に「置いた」と流すか、スケジュールで見に行く仕組みを別に用意する必要があります。

実際に Project を動かしてみた今回の検証は、コード側（remove コマンド追加、優先度オプション追加）の切り分けだけでした。次に試すとしたら、Grok Bot 側の Owner を主役にした、文章を返す仕事のほうです。

まとめ

• Cursor Projects は、実装者ではなくコーディネーターに、仕事ごと預ける機能です。公式の言い方では、1回の chat では終わらない仕事向きだそうです
• 実行は Cloud Agents、起動は Subscriptions（Automations に近い）、記憶はプロジェクトの共有ファイル、という3層構造になっています
• 向いているのは機能開発 / マイグレーション / ガーデニングです。今すぐの小さな修正には、普通のチャットのほうが安く済みます
• 独立した定価はなく、並列にするほどトークンが増えていきます
• コードの実装・運用は Project、調べて文章を返す仕事は Grok Bot、という使い分けが、今のところの自分の整理です。リサーチをコード用 Project に預けると、どうしても実装に寄りやすくなります
• 2026年9月11日時点では左ナビに Projects が無く、2026年9月14日には現れていました。Project を1つ作って依頼を送ったところ、コーディネーターはコードを書かず計画を要約してサブエージェントに委任し、2分45秒後には draft PR まで戻ってきました。公式の説明どおりの動きです
• Mark as Ready を押すかどうかは人間の判断です。ここが、公式の言う「レビューは人間」の境界線そのものでした
• 共有コンテキストは notes.md という1ファイルで、タスクごとに1行ずつ積まれていく作りでした。2件目を依頼すると、1件目のテストの書き方をそのまま引き継いだ実装が返ってきたので、「次のエージェントも同じ手順を使える」という説明とは一致する動きでした
• Subscriptions は Listening タブの中に実在し、Project が作った draft PR ごとに「Comments」「CI runs」が自動で登録されていました。何も設定しなくても、この範囲は最初から購読対象に入るようです
• 「5分ごとにチェックして」と自然文で頼むだけで、スケジュール実行の Subscription も1本追加できました。反映には1分ほどの遅延があったので、即座に確認して「増えていない」と結論づけるのは早計でした

公式が挙げていた5つの確認ポイントは、これで一通り実測できました。あとはSlackチャネル監視のような、GitHub以外のトリガーも試せると、より網羅的になりそうです。

参考資料

• Projects の紹介（公式ブログ・日本語）
• Introducing Projects（公式ブログ・英語）
• Cursor Projects（Changelog）
• 公式X（2026-09-10）
• Fredrika Lindh さんの運用スレッド
• AIソフトウェア開発の第三の時代
• Grok Bot
• Cloud Agents
• Automations
• NECの「AI部署」についてまる一日真剣に考えてみた
• Subagents
• Cloud Agent security
• Models & Pricing
• Cursor 3.0の主要新機能5つを試してみた