Cursor Projectsのマルチプレイヤー共同作業ガイド（2026年ベータ）

2026年11月10日、CursorはProjectsを、個人向けのオーケストレーション機能からチーム共同作業のためのワークスペースへと刷新しました。各メンバーのコーディネーターエージェントは、チームメイトのコーディネーターと直接やり取りし、コード変更の重複を検出し、未完了のプルリクエストを引き継げます。ただし、安全に運用するにはTeamsアカウントとCursor 3.26.13以降が必要です。共有コンテキストファイルの扱いも明確に決めておかないと、あるエージェントの未承認の前提がリポジトリ内の他のエンジニア向け計画を上書きしかねません。

11月10日に変わったこと：1人用Projectsからチーム共同作業へ

Cursor Multiplayer Projectsは、2026年9月10日に提供された単独ユーザー向けのProjectsベータを、複数人で使えるワークスペースへ拡張したものです。各メンバーは独立した1対1のコーディネーターチャットを操作しつつ、1つのTask Boardと1つのProject Agent Store（/cursor/stores/self）を共有します。Cursor Projects公式ドキュメントによると、11月10日の更新では、個人の実行レーンとチーム共有状態が次の8つの観点で分離されました。

利用条件・招待・ワークスペース作成の2段階

Cursor Projectsドキュメントによれば、マルチプレイヤーProjectを共有するには、Cursor TeamsまたはEnterpriseアカウント、クライアントの3.26.13以降、さらに招待される各参加者に個別のリポジトリアクセス権が必要です。Free、Plus、Legacy Hobbyプランではマルチプレイヤー共有を利用できません。Privacy Mode (Legacy)が有効な場合、Projectがself-hosted machines上で動作している場合、またはProjectがアーカイブ済みの場合も、チームメイトを招待できません。

フェーズ1：ベースとなるProjectを作成する4ステップ

共同作業者を招待する前に、ProjectオーナーがCursorのAgents Windowでワークスペースを初期化します。

1. 左ナビゲーションからProjectsを開く：Agents Windowを開き、サイドバーのProjectsセクションでNew Projectを選択します。
2. Projectに名前を付ける：アイコンを選び、対象範囲と成果物が明確な名前を入力します。未入力の場合の既定値はNew Projectです。リポジトリごとに巨大なProjectを1つ作るのではなく、スキーマ移行、複数PRにまたがる機能、継続的なCI保守といった成果物単位で分けるのが適しています。
3. Workspaceとコーディネーターモデルを選ぶ：Workspaceで対象のGitHubリポジトリを選びます。GitHubを連携していない場合は、Connect GitHubをクリックします。続いてModelから、コーディネーターとして動かすモデルを選択します。
4. Create Projectをクリックする：CursorがProject用のクラウドコンピューターをプロビジョニングし、コーディネーターエージェントとの1対1スレッドを開きます。

対象となるトップレベルのCloud Agentチャットですでに作業範囲を検討していた場合、そのチャットをサイドバーからProject行へドラッグするか、サイドバーメニューでAdd to Projectを選ぶと、コーディネーターが既存の会話履歴を取り込めます。ローカルチャットでこの操作を行うと、Cursorは追加前にそのチャットをRemote Controlへ変換します。

フェーズ2：チームメイトを招待する3ステップ

Projectがアクティブになり、リポジトリへ接続できたら、オーナーまたは既存のProjectメンバーは、ドキュメントに定められた次の3ステップでチームメイトを招待できます。

1. Inviteメニューを開く：Project上部のInviteを選択します。最初の招待後、この操作部は顔アイコンの列に変わります。
2. メンバーを招待するか共有リンクをコピーする：Invite teammates to this projectで名前またはメールアドレスからチームメイトを検索して招待を送るか、Copy linkを選び、Project URLをSlackやLinearで共有します。
3. 招待先が承諾し、専用チャットを受け取る：招待されたメンバーはProjectの招待カードでAccept Inviteをクリックします。専用のProjectチャット、自身のコーディネーターエージェント、共有Projectコンテキストへの読み書き権限が付与されます。

メンバー管理と共有リンクの制御

アクセス境界は、CursorのチームレベルとGitリポジトリレベルの両方で適用されます。

• 同じチームかつリポジトリアクセスが必須：個人アカウントのユーザーや外部Cursorチームの開発者は参加できません。招待されるチームメイトは、Projectのリポジトリに対する独立したアクセス権も持っている必要があります。
• 漏えいしたリンクを無効化する：招待リンクをコピーできるのは既存のProjectメンバーだけです。リンクの共有範囲が広がりすぎた場合、Projectオーナーは招待メニューからReset Share Linkを選び、既存のすべてのコピーを無効化できます。
• 退出とメンバー削除：参加者は誰でもサイドバーメニューのLeave Projectを選んで退出でき、有効な招待またはリンクがあれば後から再参加できます。Projectオーナーは、招待メニューのRemoveで参加者を削除できます。

共有コンテキスト（/cursor/stores/self）と個人ストア（/cursor/stores/user）の使い分け

Cursor ProjectsのContextおよびPersonal Storeドキュメントでは、開発者個人の設定とチーム全体の知識を分けるため、各エージェント環境に2つの異なるファイルシステムパスをマウントすると説明されています。共有Projectコンテキストは/cursor/stores/self、個人用ユーザーストアは/cursor/stores/userです。公式のストアルールでは、チームメイトが共有Projectに参加した際、コーディネーターは/cursor/stores/userから関連する作業設定をProjectルールへコピーするよう提案する場合があります。ただし、コピーされるのはユーザーが明示的に承認した項目だけです。

信頼されないサイドチャットを介したコーディネーター間メッセージ

あるコーディネーターがチームメイトの作業に関する情報を必要とした場合、Cursor Projectsのマルチプレイヤー仕様では、相手の通常チャットからChat with {name}'s agentというサイドチャットをフォークし、そのチームメイトのコーディネーターへ直接メッセージを送れます。受信クエリによって相手の作業中スレッドが中断されたり、秘密情報が流出したりしないよう、Cursorはフォークされたサイドチャットで実行できる操作を制限しています。

Cursorの2026年11月10日のマルチプレイヤー発表で、プロダクトマネージャーのAryaman Khandelwalは、エージェント間連携の主な利用例として次の2つを挙げています。

• UIと機能の変更が重なる場合：あるエンジニアが商品ページへカスタマーレビューを追加し、デザイナーが同じページを再設計しているとします。両者のコーディネーターは早い段階で重複を検出し、後でリファクタリングするのではなく、レビューコンポーネントを新レイアウトに組み込みます。
• スキーマ変更と読み取り側の順序調整：ある開発者がデータベーススキーマを変更する一方、別のチームメイトがそのデータベースを読む機能を構築している場合、エージェント同士が事前に作業順序を合意し、マージ時の統合競合を回避します。

Cursor Projects公式ドキュメントのHow coordinators message each otherで説明されている通り、このやり取りには4つの厳格なルールがあります。

1. 送信側からの問い合わせ：チームメイトAのコーディネーターが、チームメイトBの作業への依存関係を検出し、チームメイトBのコーディネーターへ直接メッセージを送ります。
2. フォークされたサイドチャットの作成：受信メッセージにより、チームメイトBの通常チャットからフォークされたChat with {Teammate A}'s agentというサイドチャットが作成されます。
3. 信頼しない入力として評価：受信したコーディネーターメッセージはエージェント入力としてラベル付けされ、受信側にはどのチームメイトのエージェントが送ったものか示されます。受信エージェントは、そのメッセージを自身のユーザーからの直接指示ではなく、評価すべき信頼されない素材として扱います。
4. メインチャットの知識で回答し、次ターンで通知：サイドチャットは受信者のメインチャットが持つ知識を使って回答し、その内容を送信側コーディネーターへ返します。チームメイトBのメインチャットは即座には中断されず、次のターンでこのやり取りに関する通知を受け取ります。

Cursor Projectsドキュメントでは、フォークされた各Chat with {name}'s agentサイドチャットの権限境界を次のように定義しています。

理想の進行フローとベータ版の現実：共有された判断が崩れる箇所

Cursor公式の例では、着任したオンコール担当者のコーディネーターが、進行中インシデント、Linearボード、Slackスレッドを引き継ぐケースが紹介されています。しかし、単独Projectsベータの報告からは、プロジェクトライフサイクル4段階にまたがる4つの運用上の失敗パターンが見えてきます。チームで使うなら、事前のガードレールが必要です。

可変のProject Notesが生む「共有された誤り」

Cursor Community Forumに掲載されたCursor Projectsベータの3日間の単独フィールドテストで、開発者のLutz Leonhardtは同期済みコンテキストフォルダとオーケストレーターの会話履歴を調査しました。テストは5セッション、約14時間、20エージェント、32タスク、49エージェントターン、5件のプルリクエスト（うち4件をマージ）に及びました。Codex review botによる18件の指摘はすべて修正され、委任と納品は成功しましたが、プロジェクトメモリ層には、共有マルチプレイヤーストアではさらに大きなリスクになり得る2つの失敗パターンがありました。

• 明示的な読み取り1回に対し、ノートの書き換えは111回：3日間のテストでコーディネーターはProject Notesファイルを全体置換で111回書き換えた一方、明示的にそのファイルを読んだのは1回だけでした。Milestone 1は2日目にアーカイブが始まる前にノートから消え、podcast LLM analysisに対する明示的な承認も、2回の書き換え後には"done"へ圧縮されました。その結果、翌日には同じ承認待ちでコーディネーターが止まりました。
• 未承認の既定値を決定事項として記録：コーディネーターが5つのキーワードと3つの未解決事項を列挙した後、開発者はAPIキーについて質問し、Milestone 2を開始できるかを尋ねました。コーディネーターは未確認の既定値を"accepted for the start"として扱い、常時稼働するcron adapterを実装するエージェントを起動しました。これはコーディネーター自身の以前の助言と矛盾していました。別のやり取りでは、コーディネーターはすでに実行済みのワーカー引き継ぎを受け取っていないと否定し、その誤った履歴をワークフロールールとしてコンテキストフォルダへ書き込みました。

Leonhardtの報告は単独Projectsを対象にしたものですが、マルチプレイヤーでは全チームメイトのエージェントが/cursor/stores/selfを読み書きします。つまり、汚染されたノートや未検証のエージェント既定値は、後から共有ストアを読む任意のチームメイトのエージェントへ影響し得ます。マルチプレイヤー公開後、開発者の@avisinghdotdevはXで次のように述べています。

"正直、自分のエージェントがチームメイトのエージェントと話すという考えは好きではない。ルールやスキルのセットが別々ならなおさらだ。1つの雑な出力で品質が落ちる可能性がある。" — @avisinghdotdev

マルチプレイヤーProject向けの推奨ガードレール：コーディネーターに、/cursor/stores/self内の単一の可変Markdownファイルを、作業用メモと決定記録の両方として使わせないでください。Projectルールで状態を次の2ファイルに分けます。

1. タスク状態とアクティブなブランチポインター用の、可変なplan.md。
2. Gitにコミットするdecisions.md。追記専用のエージェントルールで管理し、厳格な強制が必要な場合はGit差分レビューまたはブランチ保護で裏付けます。date、decided_by（human:@handleまたはagent:proposed）、status（proposed、accepted、superseded）、applies_to（ファイルパスglob）、1行のrationaleを記録します。

古いチェックアウト、クラウドMCPの不一致、ローカルworktreeへの引き継ぎ

ベータ版における2つ目の問題群は、Cursorのクラウド優先実行アーキテクチャに由来します。Day 7 Cursor Projects receiptとr/cursorスレッドで検証されたユーザー報告によると、Projectsを導入するチームには次の4つの運用上の落とし穴があります。

1. 長期間存続するProjectでGitチェックアウトが古くなる：長期間存続するクラウドProjectは、マージ済みのmain変更を自動でpullしません（Day 7 Report R1。Cursorスタッフもこれが想定された挙動だと確認し、コーディネーターにpullを依頼するよう案内しています）。マルチプレイヤーでは、新しいタスクを委任する前に必ずコーディネーターへgit pullを指示してください。
2. クラウドで構成したMCPサーバーしか読み込まれない：コーディネーターはCloud Agentとして動作するため、Cursorのクラウド設定で構成されたModel Context Protocol（MCP）サーバーしか読み込みません（Day 7 Report R6）。ローカルのデスクトップエディターだけで設定したMCPサーバーは、Projectコーディネーターには読み込まれません。
3. 「No self-hosted workers available」トグルの罠：クラウドProjectからローカルテストを実行するには、Settings > AgentsでRemote Control（ローカルのself-hosted workers）を有効にし、リポジトリルートでagent login、続いてagent worker startを実行します。しかし、Remote Controlを有効にすると、Self-hosted Machinesもオンになり、チームダッシュボードのRequire Self-hosted Machines and Personal Machinesが有効になることがあります。これによりCloud AgentsとProjectsはCursorのクラウド上で実行できなくなります。クラウドとローカルを併用するには、チーム管理者がこのRequireトグルを無効にすべきです。
4. クラウドトークンの消費：10～20個のクラウドサブエージェントを並列実行すると、プランの利用枠を急速に消費します。r/cursorのユーザーu/ShircはRedditで次のように報告しています。

"Projectsには可能性があるが、現時点では少し混乱していて、間違いなくトークンを大量に消費する。" — r/cursorのu/Shirc

同じr/cursorスレッドで、開発者のu/dryu12は、トークン消費を抑えるためにComposerをコーディネーターモデルに設定し、委任するタスクごとにどのモデルを使うか明示するルールを書くことを勧めています。さらに、Cursor組み込みの請求外で外部CIレビューbotやカスタムエージェントスクリプトも使うチームでは、そのAPI呼び出しをAIReiter経由にすると、DeepSeek V4.1 Flashのような低コストモデルと、Claude Opus 5.5のようなレビュー担当モデルを、単一の従量課金残高で組み合わせられます。

PRレビューの衝突：すべてのPull Requestに所有者が必要な理由

Cursor Projectsのsubscriptionsドキュメントによれば、Slackチャンネル、PRアクティビティ、ブランチ上のCI実行、every day at 8:00 AMのようなスケジュールのいずれかを監視するサブスクリプションが少なくとも1つ存在すると、チャット入力欄の上にListeningピルが表示されます。

Leonhardtの3日間の単独テストでも、コーディネーター、実装を担当した元のワーカー、新規作成された修正エージェントのいずれもがレビューイベントへ反応できるため、PRレビューの処理はすでに曖昧でした。あるPRでは、元のエージェントがすでに修正中だったにもかかわらず、コーディネーターが作成者へ修正について2回質問しました。別のPRでは3つのエージェントが同じステータスファイルを書き換え、誤った作成者が記録されました。

同じリポジトリ内で複数のチームメイトがコーディネーターを動かす場合、複数のコーディネーターをリポジトリ全体の広範なPRイベントへ購読させると、重複した修正コミットや無駄なクラウドターンのリスクが高まります。開発者の@LabubuNoBBはXで次のように指摘しています。

"難しいのはエージェント同士に話をさせることではなかった。2つのエージェントが同じファイルを欲しがったとき、誰が何を所有するかを決めることだ。" — @LabubuNoBB

推奨するPR所有ルール：共有Task Board上で、PRごとに人間の所有者1人と指定エージェント1つを割り当てます。そのブランチ上のすべてのレビューコメントへの対応責任も含めます。各チームメイトのコーディネーターのサブスクリプションはリポジトリ全体のワイルドカードではなく、自身のPRに限定してください。

チーム導入の判断表：共有Projectにするべきケース、別チャットを維持すべきケース

チームのワークフローを共有Cursor Projectへ移す前に、3.26.13+ベータで確認されている制約と、タスク構造を照らし合わせてください。