Cursor Projectsの使い方｜長期開発と自動化

こんにちは。AIあれこれ散歩道、運営者のもっちゃんです。

Cursorに「Projects」が加わり、数か月続く機能開発や移行、アプリ全体の構築を、複数のAIエージェントへ分けて進められるようになりました。いつものAgentと何が違うのか、どこから始めるのか、料金やコードの扱いは大丈夫なのか。気になる点が一気に増えますよね。

先に結論を言うと、Cursor Projectsは長期の目標を計画し、実装担当へ委任し、結果を人へ戻す司令塔です。ただし、2026年9月14日時点ではbetaで、Cloud Agentの課金、リポジトリ権限、外部通信、保存期間を先に決める必要があります。最初は一つのリポジトリと一つの定期処理だけで試し、マージは人が判断するのが現実的です。

Cursor Projectsの使い方と特徴

まず、Projectsが何を担い、通常のAgentとどう分けるのかを見ていきます。入口は左navigationですが、本当に大切なのは、coordinatorへ渡す長期目標、共有contextへ残す情報、subscriptionsで自動化する範囲です。

ここで扱う機能はCursor Projectsの公式発表とCloud Agentの公式文書を基にしています。私はProjectsを実際のリポジトリへ導入していないため、処理速度、完成度、費用対効果を実体験のようには書きません。

Projectsは長期開発の司令塔

Cursorは2026年9月10日、Projectsをbetaとして発表しました。対象として挙げているのは、一つの短い修正ではなく、機能開発、移行、アプリ全体の構築といった大きな仕事です。数か月にわたるcontextを維持し、必要に応じて数千のsubagentへ仕事を任せ、promptを待たずに定期作業も行うと説明しています。

ただし、「数千のsubagent」という言葉を、いつでも数千体が同時に動いて短時間で終わる約束だと受け取るのは危険です。実際の並列数、速度、費用は仕事の分け方、model、環境、repositoryの大きさで変わるでしょう。公式の能力説明と、あなたの開発で得られる結果は分けて考えます。

成果物を一文で書いてみてください。「この関数を直す」なら通常Agent、「この移行を完了し、複数serviceのtestと手順書まで更新する」ならProjectsが候補です。同じ目標と知識を何度も引き継ぐかで決めると分かりやすいですよ。

左ナビから始める手順

公式発表では、ProjectsはCursorの左側navigationから利用します。betaは全userへ順次展開とされているため、同じ日に全accountへ同時表示されるとは限りません。表示されているなら、新しいProjectを作る前に、対象repositoryと最初の成果物を一つずつ決めましょう。

最初の指示には、目標、対象外、完了条件、確認の単位を入れます。たとえば「このrepositoryのdependency更新を毎週確認し、互換性testが通った変更だけdraft PRで返す。本番deployはしない」のように書けば、やってほしいことと止まる場所が伝わります。

逆に、「このprojectを全部よくして」のような広い依頼では、coordinatorが何を優先し、いつ完了とするか決めにくくなります。期限、対象branch、触れてよいdirectory、必須test、禁止する外部変更まで、分かる範囲で具体的にするとよいでしょう。

repositoryの置き場所を考えるときは、Cursor OriginとGitHub同期を扱ったCursor Originの使い方も参考になります。Originを使う場合と外部Git providerを接続する場合では、正本となるrepositoryと権限の考え方が変わるためです。

coordinatorの役割

Projectの中心にいるcoordinator agentは、自分でcodeを書きません。公式説明では、仕事を計画し、実装するagentへ委任し、完成した成果物をあなたの確認へ戻します。さらに、作業に必要なagentを作成・管理し、必要な数を並列で動かします。

つまり、coordinatorへは細かな一行修正より、分解の基準と優先順位を渡すのが合っています。「先に互換性を調べる」「認証部分は別PRにする」「schema変更より前にrollback手順を作る」といった順番です。実装担当へ直接すべてを詰め込むより、誰へ何を任せるかを決める入口になります。

一方で、coordinatorが返した計画を必ず正解だとみなしてはいけません。依存関係を見落としたり、同じfileを複数agentが触ったり、目的が近いtaskを重ねたりする可能性があります。最初の計画、PRの分割、完了条件を人が一度見ることで、後戻りを減らせます。

共有contextの育て方

各Projectは、agentが使うcloud machineとlocal machineの間で同期されるfile群を持ちます。そこへresearchやartifactだけでなく、codebaseで学んだこと、あなたが好む進め方も蓄積されます。一度見つけたtest手順を、後のagentが再利用できるのが大きな特徴です。

共有contextへ残したいのは、繰り返し使う短い事実です。起動方法、必須test、service間の関係、命名規約、変更してはいけないdirectory、既知の制約などが向いています。会話の途中でしか分からない判断をfileにしておくと、新しいagentへ毎回説明する手間が減ります。

ただし、contextは増やせば増やすほど良いわけではありません。古い手順や誤った前提も引き継がれるからです。更新日、対象version、確認方法を書き、不要になった説明は削除する。共有contextは倉庫ではなく、次の担当が迷わず読める作業台として保つのがおすすめです。

password、API key、tokenを共有contextの通常fileへ直接書かないことも重要です。秘密情報は後で説明するRuntime SecretやBuild Secretなど、目的に合う仕組みで渡します。便利な記憶場所とcredential保管場所は分けましょう。

subscriptionsで定期化

Subscriptionsは、coordinatorが人のpromptを待たず、見つけたsignalから動くための仕組みです。公式発表では、Slack channelを監視する、scheduleで実行する、すべてのPRを追跡するといった例が示されています。

Slackのbug報告channelを指定すれば、報告が届くたびに作業を委任し始める例もあります。人がissueへ転記してagentへ頼む工程を短くできそうです。ただし、自然文の報告には再現手順不足、重複、機密情報、誤報が混ざることがあります。検知しただけで本番変更まで進めない境界が欠かせません。

初回は一つのtriggerへ絞ります。たとえば「毎週月曜にdependencyを確認し、更新候補とtest結果をdraft PRで返す」だけにする。実行回数、agent利用量、通知、誤った起動が読めたら、SlackやPR追跡を追加します。複数triggerを同時に始めると、どれが費用や重複作業を生んだか分かりにくくなるからです。

Cloud Agentの一般的な自動化はCursorのAutomations公式文書でも確認できます。ProjectsのSubscriptionsと既存automationの画面や条件が変わる可能性があるため、beta中は表示される設定を一つずつ読み、同じtriggerを二重登録しないようにしてください。

cloudとlocalの使い分け

Projectはcloud上の専用computerで動くため、laptopを閉じても処理が止まらないと説明されています。一方、手元のmachineでtestが必要になると、coordinatorがlocal agentを起動します。すべてをcloudだけ、またはlocalだけで完結させる仕組みではなく、仕事に応じて境界をまたぎます。

Cloud Agentsの公式overviewによると、agentはisolated VMでrepositoryをcloneし、dependenciesやstartup commandを使える開発環境で動きます。別branchで変更し、pushしてhandoffする流れです。source control接続には、対象repositoryや必要なsubmoduleへread-write権限が求められます。

local testが必要な理由には、社内network、特定hardware、local database、まだcloudへ用意していないfixtureなどが考えられます。どのtestをcloudで実行し、どれをlocalへ回すかを最初に決めると、未確認のまま成果物が戻る事態を防ぎやすくなります。

スマホからCloud Agentを開始・管理する入口もあります。外出先での使い分けはCursor for iOSの料金と使える範囲で解説しています。ただし、スマホで開始できることと、重要なdiffを小さな画面だけで承認してよいことは別です。影響の大きい変更は、十分な画面とtest結果で確認しましょう。

Cursor Projectsの使い方と注意点

ここからは、導入前に止まって確認したい項目を見ていきます。betaの表示、planと利用量、repository権限、secret、network、保存期間は、あとで慌てて直すより、最初のProjectを作る前に決めるほうが安全です。

beta表示がないときの確認

2026年9月10日の発表では、Projectsはbetaとして全userへ順次展開されます。「全userへ展開」と「すべてのaccountで今すぐ利用可能」は同じ意味ではありません。左navigationに見当たらなくても、故障やplan不足とすぐ断定せず、段階rolloutの途中という可能性を残します。

最初に、Cursorへ正しいaccountで入っているか、webとdesktopで同じaccountか、左navigationにProjectsがあるかを確認します。team環境なら、source control接続や管理者側の設定も関係するかもしれません。Projects固有の詳細なtroubleshootingは公式発表だけでは示されていないため、見えていないUIを想像で説明しないのが大切です。

betaでは、menu名、開始手順、利用条件、上限が変わることがあります。この記事の画面名を固定仕様として覚えるより、公式changelogの日付と現在の画面を対にして見るほうが確実です。特にteamへ展開する前は、一人のaccountで表示と権限を確認してから対象を広げるとよいでしょう。

料金と利用上限の考え方

2026年9月14日時点のCursor公式料金表では、Hobbyは無料でlimited Agent requestsとComposerを含みます。Individual Proは月20米ドルでCloud agentsを含み、Teamsはuserあたり月40米ドルでCloud agents、automations、shared team contextを含みます。税や為替は別に変わり得ます。

Cloud AgentsのBillingでは、選択modelのAPI pricingで課金され、初回利用時にspend limitを設定すると案内されています。大きなcontext windowはtoken利用量と費用を増やす可能性があります。さらに、Cloud Agentが開始しない場合の項目にはpaid Cursor planが必要と書かれています。

ここで注意したいのは、月額planだけ見れば終わりではない点です。plan内のmodel利用量、on-demandの超過利用、選んだmodel、context window、agent数、subscriptionの起動回数が重なります。長期Projectでは、一回の料金より、毎日・毎週の継続量が効いてきます。

月額plan、従量分、定期起動の三つを別々に見ると、費用の増え方を追いやすくなります。最初の一週間は、Projectが動いた回数、作成したagent、選択model、完了した成果物を短く記録し、予算と釣り合うか確かめるのがおすすめです。

repository権限を絞る

Cloud Agentは、開始したdeveloperが持つGit accessを基に対象repositoryへ接続します。公式security文書では、developerがアクセスできないrepositoryへAgentが勝手に広がることはなく、管理者は許可するrepositoryを制御できると説明しています。

それでも、最初からorganization全体へ広いread-write権限を渡す必要はありません。対象Projectで編集するrepository、参照だけ必要なrepository、触れないrepositoryを分けます。submoduleやdependent repositoryが必要なら、その理由を確認してから追加する。最小権限なら、誤った変更やprompt injectionが起きたときの影響を小さくできます。

Cloud Agentは変更を別branchへpushし、draft PRを人へ渡します。draft PRは安全の保証ではなく、人が止めて確認するhandoff地点です。diff、test、artifact、設定file、dependency、外部通信を見てからmergeします。

AIへ渡す権限の決め方は、サイト内のAIエージェントの権限管理でも詳しく扱っています。Git provider側のbranch protection、必須review、protected scopeと組み合わせ、agentだけで本番へ届く経路を作らないようにしましょう。

secretとnetworkの設定

Secrets and Networkの公式文書では、secretをEnvironment Variable、Runtime Secret、Build Secretに分けています。通常のEnvironment Variableはagentから見えるため、公開URLやflagなど機密性の低い設定向けです。

Runtime Secretは環境変数として動作しながら、tool callの結果、chat transcript、commit、commit messageで値を伏せます。ただし、agent環境のTerminalを操作するuserには見えるとされています。万能な不可視化ではないので、閲覧者と利用目的を考えて使います。

Build SecretはDocker build processだけへ渡す仕組みです。private packageの取得など、実行中agentへ渡す必要がないcredentialに向きます。AWS、GCP、Azureなどのcloud roleには、長期keyを保存するより、短時間だけ有効なOIDC tokenを使う方法も用意されています。

networkはdefaultでinternet accessが有効です。便利ですが、悪意ある文書やissueがagentを誘導し、codeやsecretを外部へ送らせるriskがあります。必要なdomainだけのallowlist、Runtime Secret、`.cursorignore`、短期token、最小権限を重ねてください。

AIの提案をそのままmergeしない考え方は、別製品でも共通します。PRでの人の確認例はGitHub Copilotコードレビューの使い方も参考にしてください。製品は違っても、差分とtestを人が見る役割は変わりません。

保存期間と削除方法

Cloud Agentでは、「学習に使わない」と「保存されない」を混同しないことが大切です。Cloud Agent security overviewによると、Privacy ModeではCloud Agentが扱うcode、prompt、responseをCursorのtrainingへ使いません。一方、作業を再開できるように複数種類のdataを保存します。

runtime workspaceはrunがidleになった後にrecycleされます。VM snapshotは最後のstartやresumeから90日間使われないと自動削除。conversation stateはdefaultで期限を定めず保持され、Cloud Agent用のsecretとtokenはuserが削除するまで保存されます。

Delete Agent APIはconversation transcriptとartifactを削除できますが、snapshotをその場で消すものではありません。snapshotは90日の非activity windowに従います。また、archiveはdashboardから隠す操作であり、削除と同じではありません。

そのため、Projectを始める前に、共有してよいcode、conversationへ残してよい内容、終了後に消すagent、credentialの期限を決めます。機密性の高いrepositoryなら、cloudへ載せる前提そのものが合うかも検討してください。Enterpriseではconversation保持期間を制限する機能がありますが、planによる差を確認する必要があります。

Cursor Projectsのよくある質問

Q1. 無料のHobby planでProjectsを使えますか？

A. 公式発表ではProjectsをbetaとして全userへ順次展開するとしていますが、Projects固有の無料範囲は示していません。料金表のHobbyはlimited Agent requests、Cloud Agent文書はpaid planが必要と案内しているため、無料で長期cloud実行できるとは断定できません。

Q2. coordinatorは自分でcodeを書きますか？

A. 公式説明では、coordinator自身はcodeを書きません。仕事を計画し、実装担当のagentを作成・管理して委任し、完成した成果物を人の確認へ戻します。委任先の変更が正しいかは、draft PR、diff、testで人が確認します。

Q3. laptopを閉じても作業は続きますか？

A. Projectはcloud上の専用computerで動くため、laptopを閉じても止まらないと説明されています。ただし、手元machineでtestが必要になるとlocal agentを起動します。local環境が必要な工程まで常に完了するとは限りません。

Q4. 共有contextへsecretを保存してよいですか？

A. passwordやAPI keyを通常fileへ直接保存するのは避けます。Environment Variable、Runtime Secret、Build Secretを用途で分け、cloud roleには短期OIDC tokenも検討します。network egressとrepository権限も必要最小限にします。

Q5. 通常AgentとProjectsはどう選びますか？

A. 一つの会話で終わる短い修正は通常Agent、複数issueやPRへ分かれ、同じ知識を数日以上引き継ぐ仕事はProjectsが候補です。迷うなら通常Agentで小さく試し、長期contextと定期triggerが必要になった時点でProjectsへ広げます。

Cursor Projectsの使い方まとめ

Cursor Projectsは、長期の目標をcoordinatorが計画し、必要なagentへ実装を任せ、成果物を人へ戻すbeta機能です。共有contextへtest手順やcodebase知識を積み重ね、Slack、schedule、PRを合図に継続作業できる点が、単発のAgentとの大きな違いです。

一方で、便利さはcloud実行、source control接続、保存、外部通信の上に成り立ちます。Cloud Agentはpaid planが必要と案内され、選択modelのAPI pricingで課金されます。Projects固有の無料範囲は明記されていないため、plan名だけで判断せず、spend limitと実際の利用量を見てください。

最初の成功条件は、多数のagentを動かすことではなく、一つの小さな仕事を安全に人へ戻せることです。そこまで確認できたら、共有contextを少しずつ育て、定期作業を一つずつ追加する。この順番なら、Projectsの便利さを試しながら、費用と権限の広がりも追いやすいですよ。