Cursor 使い方ガイド：Projectsでチーム開発をレビューキューへ

Cursor Projectsによって、チームでのCursor 使い方は「1回のプロンプト」から「レビューキューの運用」へと変わります。2026年9月10日、Cursorはコーディネーター、共有プロジェクトコンテキスト、定期トリガーをベータ版に投入しました。これにより、毎回タスクを手動で始めなくても仕事を委任でき、ボトルネックはスコープ設定、検証、マージ判断へ移ります。

この記事は、エンジニアリングリード、技術系の創業者、制作会社の経営者に向けた運用レベルの解説です。重要なのは、Cursorが何体のエージェントを起動できるかではありません。コストと品質の管理を失わず、返ってくる成果物をチームが処理できるかどうかです。

Cursor 使い方ガイド：Projectsの仕組み

Cursor Projectは、機能開発、移行、アプリ全体の構築といった一連の仕事を長期間動かすためのコンテナです。そこには、この仕組みで管理役を担うコーディネーターエージェントがいます。コーディネーターは作業を計画して実装を委任しますが、自らコードを書くわけではありません。

実装エージェントはクラウドマシン上でコーディングします。コーディネーターは複数の実装エージェントを立ち上げ、作業を並列で進め、確認用の結果をまとめて返せます。自分のマシンでテストを実行する必要があれば、その環境でローカルエージェントを起動することもできます。

もう1つの柱が共有コンテキストです。各Projectは、エージェントが使うクラウドマシンとローカルマシンの間で同期されるファイルを保持します。そこには、調査内容、成果物、コードベースの知識、テスト手順、チームが望む仕事の進め方に関するメモを蓄積できます。

これにより、引き継ぎの形が変わります。Projectに保存したコンテキストが正確かつ最新である限り、新しいエージェントが毎回テストコマンドやサービス境界を調べ直す必要はありません。

3つ目はサブスクリプションです。Projectには、Slackチャンネルの監視、スケジュール実行、プルリクエストの追跡を設定できます。条件に合うシグナルを受けると、誰かが新しいプロンプトを書かなくても、委任された作業を開始できます。

定期実行エージェントそのものは、Cursorの新機能ではありません。8月19日のリリース時点で、Cloud Agentsはプルリクエスト、Slackスレッド、スケジュールを監視できました。Projectsは、その定期作業を1体のコーディネーターの下にまとめ、長く続くタスク群でも共有コンテキストを維持できるようにします。

今回のリリースの本質はそこにあります。Cursorが追加したのは、単なる新しいコーディングチャットではありません。委任した仕事のための永続的な拠点です。

なぜレビューキューが事業上の論点になるのか

共有コンテキストは、繰り返し発生する準備作業を減らせる可能性があります。ただしCursorは高速化の数値を公表しておらず、このベータ版も効果を断定できるほど成熟していません。現段階で削減時間を予算に織り込むべきではありません。

測定できる変化は、チームの時間をどこに使うかです。コーディネーターは複数のレーンで実装タスクを並列に走らせられますが、1人のレビュアーは変更を順番に読むことになります。この非対称性により、空だったバックログがプルリクエストで埋まる可能性があります。

タスクの範囲が狭く、テストの信頼性が高く、レビュアーがすぐ判断できるなら、このキューは有効です。反対に、エージェントが広範な差分、重複した作業、意図の分からない変更を返すとコストが膨らみます。並列で生まれた成果物も、誰かが受け入れるまでは在庫にすぎません。

影響の大きさはCursorユーザーごとに異なります。1度に1つの限定的なタスクを扱う個人開発者なら、コーディネーターの恩恵は小さいかもしれません。テストが弱い、あるいは担当レビュアーがいないチームでは、処理量より不確実性が増えかねません。すでにCloud Agentの定期オートメーションを運用しているチームにとって、最大の価値はトリガー自体ではなく、Projectで共有されるコンテキストです。

誰に向くのか、役割ごとに何が変わるのか

移行を進めるSaaSエンジニアリングリード

1つのProjectに、対象を限定した移行を任せます。対象外の項目、テストコマンド、ロールアウト規則、担当範囲も明記します。コーディネーターは機械的な変更を複数の実装エージェントに分け、リードは順序とリスクの高い境界をレビューできます。

効果は、複数のブランチにまたがる継続性です。測るべきなのはエージェントの活動量ではなく、受け入れた変更とレビュー時間です。

クライアント案件を管理する制作会社の技術責任者

クライアントごとのセットアップメモ、コーディング規約、テストパス、納品ルールを、そのクライアント専用Projectの共有コンテキストに置きます。定期的な保守タスクは、毎回新しいオンボーディング用プロンプトを書く代わりに、同じ運用指示から始められます。

効果は、説明の繰り返しを減らせることです。ただしクライアント間の分離は厳守すべき境界です。あるアカウントのコンテキストや認証情報を、別のアカウントと共有するプールに入れてはいけません。

バグ受付を監視するサポートエンジニアリングマネージャー

Slackの公開バグ報告チャンネルを1つ接続し、対象を絞った判定ルールを使います。再現手順がある報告はProjectに取り込み、質問、重複、アカウント固有のインシデントは人が引き続き担当します。

得たい成果は、レビュー用に準備されたブランチと根拠であり、自動マージではありません。CursorのAutomationsの現行ドキュメントでは、Slackトリガーは公開チャンネルに限定されています。また、Projectsの発表にはチャンネル対応状況をまとめた別の表はありません。

定期保守を担うプラットフォームチーム

Projectには、繰り返す保守作業に必要なテスト手順とサービスマップを保持できます。コーディネーターはプルリクエストやスケジュールを追跡し、実装結果を指定された担当者へ返せます。

効果は、安定した運用ループです。規制対象のチームは、クラウド実行環境、同期されるコンテキスト、シークレット、ベータ版の制御機能をセキュリティレビューで確認できるまで待つべきです。

チームで小さくCursor 使い方を検証する

CursorはProjects APIも、Projects専用の詳しいセットアップガイドも公表していません。現時点で誠実なパイロットを行うなら、画面上で確認できるベータ機能と、すでに文書化されている関連Cloud Agent機能を使います。

1. 1

   アクセス権と課金条件を確認する

   Cursorの左側ナビゲーションにProjectsが表示されるか確認します。発表ではベータ版を全ユーザーへ順次提供するとしていますが、Cloud Agentsには引き続き有料プランが必要です。チームで試す前に、実際のアカウントで機能フラグを確認し、シート種別を確かめ、定期トリガーを追加する前にチーム全体の支出上限を設定します。

2. 2

   繰り返せる仕事を1つ選ぶ

   1つのリポジトリと、完了条件が明確でリスクの低い1種類の作業に絞ります。既知のテストコマンドがあり、差分の範囲が小さく、結果を判断できる担当者がいる仕事が適しています。プロダクト上の判断が定まっていない移行、認可の変更、本番インシデントは最初の試行から外します。

3. 3

   共有する運用コンテキストを書く

   リポジトリ構成、セットアップ手順、テストコマンド、完了の定義、変更禁止領域、エスカレーション規則をProjectに渡します。これらのファイルは、保守が必要な運用文書として扱います。誤った共有コンテキストは、同じ間違いをより効率よく繰り返します。

4. 4

   受け付け経路を1つ追加する

   スケジュール、プルリクエストのサブスクリプション、またはSlackチャンネルを1つ選びます。どのシグナルを対象にするか、コーディネーターが何を委任できるか、どんな根拠を返す必要があるか、コードを変更せず停止すべき条件は何かを明記します。

5. 5

   レビューキューに責任者を置く

   シニアレビュアーを1人任命します。変更を先へ進める前に、差分、テスト出力、関連成果物を必須にします。ベータ期間中は、マージ権限をProjectの外に置きます。

6. 6

   レビューを通過した仕事を測る

   開始した作業項目、受け入れた変更、レビュー時間、手戻り、見逃して流出した不具合、モデル使用量を記録します。パイロット前の同種タスクと比較してください。エージェント数を生産性に置き換えてはいけません。

レビュー時間まで含めてパイロット費用を見積もる

基本プランは分かりやすい部分です。Teams Standardは1ユーザー当たり月額$40なので、新規4席なら1回の請求サイクルで$160です。Teams Premiumは1ユーザー当たり月額$120で、Standardの5倍の利用量が含まれます。ただし、パイロット自身の利用データが出る前にPremiumを購入すると、検証の大事な部分を飛ばすことになります。

変動費はもう少し複雑です。Cloud Agentsには、選択したモデルのAPI価格が適用されます。TeamsとEnterpriseでは、対象となるサードパーティーモデルの入力、出力、キャッシュ済みトークンに、百万トークン当たり$0.25のCursor Token Rateが加算されます。Teamsではオンデマンド利用が標準で有効になっており、チーム管理者はチーム全体の月間上限を設定できます。

以下は範囲を限定した試算です。作業量に関する数値はすべて仮定として明記しています。

• 範囲の仮定： 1つのリポジトリ、1つのトリガー、レビューに到達する作業項目は20件以下です。
• 使用量の仮定： コーディネーターと実装エージェントの活動を含む完了済みの各作業項目が、Claude Sonnet 5でキャッシュなし入力100,000トークン、キャッシュ読み取り400,000トークン、出力20,000トークンを消費し、キャッシュ書き込みはないものとします。
• レビューの仮定： シニアレビュアーが、返ってきた1件につき20分を確保し、諸経費込みの人件費を1時間当たり$100とします。

Cursorの現行Claude Sonnet 5料金では、この試算上の作業1件につき入力が$0.20、キャッシュ読み取りが$0.08、出力が$0.20です。520,000の対象トークン全体に対するTeam token rateは$0.13です。したがって、モデル使用料は1件当たり$0.61、20件で$12.20となります。

より大きいのはレビュー費用です。20件を各20分レビューすると400分、つまり6時間40分を確保することになります。仮定した時給$100では、レビュアーの時間は$666.67です。

新規Standard 4席の$160を加え、モデル使用料が超過料金になるかどうかにかかわらず試算に含めると、月間の計画総額は$838.87です。これは請求額の予測ではありません。既存シートを使えば$160の購入費はなくなり、プラン内の利用枠で$12.20を吸収できる場合もあります。また、実際のProjects作業ではコーディネーターが複数のエージェントに委任するため、使用トークンがさらに増える可能性があります。

この試算の要点は、レビュー費用が常に$666.67になるということではありません。レビューにも独立した予算項目が必要だということです。パイロットを安いと判断する前に、タスク数、所要時間、諸経費込みの時給を自社の条件に置き換えてください。

製品全体とサブスクリプションを判断する際は、エディター、Cloud Agents、料金、既存のレビューゲートを扱ったCursorの総合レビューも参照してください。

導入判断で見落とせない現実

第1に、これはベータ版の段階的提供であり、確立された運用標準ではありません。発表では左側ナビゲーションに表示されると説明していますが、Projects固有のアクセス条件表、利用量の内訳、同時実行の制御、サービス保証は示されていません。調達に必要な文書が揃う前に、機能だけ利用可能になることはあり得ます。

第2に、共有コンテキストは良い指示だけでなく、古い指示も運び続けます。先月は正しかったテストメモでも、リポジトリの変更後には将来の全エージェントを誤らせる可能性があります。コンテキストファイルごとに担当者、見直し日、削除ルールを決めてください。

第3に、コーディネーターは確認すべき成果物を返します。これが製品としての前提です。人によるレビュー、実行可能なテスト、セキュリティチェック、マージ責任が不要になるわけではありません。

第4に、エージェントが作業を立証できるかどうかは、依然として環境次第です。Cloud Agentsには、タスクに必要なリポジトリ、依存関係、シークレット、起動コマンド、ネットワークアクセスが必要です。環境のBuildに失敗した場合は最後に成功したBuildが引き続き有効ですが、不完全な環境でも、妥当に見えるコードだけが根拠なしで生成される可能性があります。

最後に、各Projectはクラウドコンピューター上で動き、マシン固有のテストが必要な場合にはローカルエージェントが使われます。プライベートネットワークを要件とするチームは、この境界もレビュー対象に含めるべきです。Cursor Self-Hosted Machinesを使えばツール実行を顧客が管理するワーカーへ移せますが、Cursorのエージェントループとモデル処理は引き続きCursorのクラウド上で行われます。

今、導入すべきチームと待つべきチーム

繰り返し可能でテストできる仕事があり、ベータ版が表示される有料Cursorアカウントを持ち、シニアレビュアーのキューに余裕があるなら、今週動いて構いません。まずStandardシートを使い、対象は1つのリポジトリと1つのトリガーに絞り、厳格な支出上限を設定します。

Projectsが表示されない、Cloud Agent環境でリポジトリのチェックを実行できない、レビュー責任者がいない場合は待つべきです。調達にProjects固有のアクセス文書や課金文書が必要なのに、Cursorがまだ公表していない場合も同様です。

単発作業が中心、エージェントセッションがすでに十分なコンテキストを保持している、ローカル実行が必須という場合、影響はほとんどありません。複数の委任タスクをまたぐ継続性がボトルネックになっているときに限り、コーディネーターを置く価値があります。

月曜日に行うことは単純です。定期作業を1種類選び、パイロットはレビュー可能な20件までに制限し、レビュアーを1人任命します。チームの支出上限を設定し、1回の請求サイクルにわたって、受け入れた変更、レビュー時間、手戻り、不具合、実使用量を記録します。モデル利用料と人がレビューに費やす時間をともに勘定に入れ、それでもワークフローが改善した場合にだけProjectsを継続してください。

実務に直結する次のAIワークフロー解説をニュースレターで受け取る。