バックエンドAPI・テストコード・ドキュメントを同時に進めたい——1人開発の壁を、CursorのCloud Subagentsで複数エージェントに分担させる方法がある。この記事は操作手順の羅列ではなく、実際に動かして分かったこと（コンフリクトの実態・AGENTS.mdの書き方・コスト感）を1本のシナリオとして通して見せる。Cursorの設定画面を触ったことがあれば再現できる内容にした。公式changelogの事実と実際の操作ログを組み合わせているが、機能仕様や料金の詳細は常に変わりうるため、最新情報は cursor.com/changelog で確認してほしい。
Cloud Subagentsが登場した背景：週末SaaS開発での詰まり
副業で小さなSaaSを1人で作っていると、「バックエンドを直したらテストが壊れた、直したらドキュメントが古くなった」という連鎖が止まらない。1タスクずつ順番にやるとリリースまでに週末が3〜4回消える。
Cursorはバージョン3.7（2026年6月17日公式changelog）でCloud Subagentsをエージェントウィンドウに追加した。端的に言うと、「リモートのクラウドVMでサブエージェントをワークツリーごとに並列起動できる機能」だ。ローカルマシンのCPU・メモリを使わず、クラウド側のリソースで走るため、手元の作業を止めずに別タスクを並列で進められる。
3.7・3.8（6月18日）・3.9（6月22日）の連続アップデートで機能が整い、現時点で実用的に動かせる段階になっている。
Cloud Subagents・Background Agents・ローカル並列——何が違うのか
3つの並列方式は目的が違う。どれを選ぶかで設定の手間もコストも変わる。
| Cloud Subagents | Background Agents | ローカル並列 | |
|---|---|---|---|
| 動作場所 | クラウドVM（リモート） | クラウド（バックグラウンド） | 手元のマシン |
| PCへの負荷 | なし | なし | 高い（コア数次第） |
| 最大並列数（公式情報時点） | 最大8タスク | プラン依存 | マシンスペック依存 |
| コンフリクトのしやすさ | worktreeで分離可 | 設定次第 | 設定次第 |
| 向いている作業 | 独立タスクの大量処理 | 非同期・長時間バッチ | 小規模・即時確認 |
| 設定の手軽さ | やや手間（AGENTS.md必要） | 比較的簡単 | 即座 |
副業開発で「同時に複数タスクを走らせたい・でも手元のPCは止めたくない」ならCloud Subagentsが一番フィットする。単発の長時間処理や非同期ジョブならBackground Agents。手元でちょっと試したいだけならローカル並列でいい。
注意：最大並列数・プラン別の制限は公式ドキュメントで定期的に更新される。現時点の仕様は必ず cursor.com/changelog と料金ページで確認すること。
AGENTS.mdに書く5つのこと：並列実行を安全にする共通設定
Cloud Subagentsを動かす前に、リポジトリのルートに AGENTS.md を置く。これは「全エージェントが起動時に参照する共通のルールファイル」で、並列実行時は特に重要になる。複数エージェントが同じ認識で動くかどうかは、このファイルの中身で決まる。
書くべき内容を優先順に示す。
1. ファイル競合を防ぐルール（最重要）
## ファイル所有ルール
- backend/ 以下は backend-agent のみ編集する
- tests/ 以下は test-agent のみ編集する
- docs/ 以下は docs-agent のみ編集する
- 共有設定ファイル（.env.example, package.json）は変更前に他エージェントに通知する並列実行で最も頻発する失敗が「複数エージェントによる同一ファイルへの同時書き込み」だ。タスクごとに担当ディレクトリを明示的に分けることが第一の防御策になる。
2. プロジェクト全体の概要
## プロジェクト概要
Node.js + Express バックエンド / Vitest テスト / Markdownドキュメント
エントリポイント: src/index.ts
テスト実行: npm run testエージェントが「このリポジトリで何を使っているか」を把握できないと、엉뚱한 依存関係を追加したり間違ったコマンドを実行したりする。
3. コーディング規約
## コーディング規約
- TypeScript strict モード
- コメントは日本語で書く
- インポートはnamed exportのみ使う
- any型は使わない4. テスト・ビルドの確認コマンド
## 確認コマンド
- ビルド確認: npm run build
- テスト: npm run test
- リント: npm run lint
各エージェントはタスク完了前にこれらを実行して通過を確認する5. 完了報告の形式
## 完了報告の形式
タスク完了時は以下の形式で要約する：
- 変更したファイル一覧
- 追加・削除した依存関係
- 確認したテスト名AGENTS.mdは1ファイルで全エージェントへの指示書になる。最初に「ファイル所有ルール」を最上部に書くこと——下のほうに書くとエージェントが参照する前に別ファイルを触り始めることがある。
起動から完了確認まで：実際の操作ログ
flowchart TD
A["AGENTS.md を作成\nファイル所有ルールを最上部に"] --> B["git worktree を準備\n並列タスク分だけブランチを切る"]
B --> C["Cursor: Cmd+E で\nAgents Window を開く"]
C --> D["タスクを1件ずつ追加\n担当ディレクトリを明示"]
D --> E["Cloud Environment Setup で\nリモートVMを選択"]
E --> F["並列起動\n最大8タスクが同時進行"]
F --> G["Agents Window で進行状況を確認\nエラーは個別に対処"]
G --> H["全タスク完了後\n各ブランチをマージ"]
ステップ1：git worktreeを準備する
並列で走らせる前に、タスクごとのworktreeを用意する。これが後述するコンフリクト回避の根幹になる。
# backend改修用
git worktree add ../project-backend feature/backend-refactor
# テスト追加用
git worktree add ../project-tests feature/add-tests
# ドキュメント更新用
git worktree add ../project-docs feature/update-docsステップ2：Agents Windowを開く
Cmd+E（macOS）または Ctrl+E（Windows/Linux）でAgents Windowを開く。バージョン3.7以降ではここに「Cloud Subagents」の起動オプションが表示される。
ステップ3：タスクを追加する
各タスクを追加するとき、「どのworktreeで動かすか」と「担当ディレクトリ」を必ず明記する。
プロンプト例（バックエンド担当）：
worktree: ../project-backend
担当: backend/ ディレクトリのみ
タスク: src/api/user.ts のCRUDエンドポイントを全て実装する。
完了条件: npm run buildとnpm run testが通ることステップ4：Cloud Environment Setupでリモート実行を選択
Agents Windowの設定からCloud Environmentを選び、リモートVMでの実行を有効にする。この設定後に起動したエージェントはローカルのCPU・メモリを使わずクラウド上で動く。
ステップ5：並列起動と進行確認
複数タスクを追加したらまとめて起動する。Agents Window上でそれぞれのエージェントの進行状況がリアルタイムで確認できる。途中でエラーが出ているタスクは個別に対処し、正常なタスクはそのまま走らせておける。
失敗した話：3エージェントが同じファイルを書き換えた
最初にCloud Subagentsを試したとき、AGENTS.mdにファイル所有ルールを書かずに起動した。結果、以下が起きた。
- バックエンドエージェントが
src/config.tsに環境変数の型定義を追加 - テストエージェントが同時に
src/config.tsを参照してimportを変更 - ドキュメントエージェントがconfig.tsの内容をドキュメントに書き出そうとして同ファイルを読み込み中に変更が走る
Cursorのエージェントはgitのコンフリクトマーカー（<<<<<<）が入ったファイルに対して「修正しようとしてさらに壊す」動作をすることがある。気づいたときには3ファイルでコンフリクトが多重発生していた。
対処したこと：
- 全エージェントを手動で停止
git statusでコンフリクトファイルを確認git checkout -- <ファイル>でコンフリクトファイルを元に戻す- AGENTS.mdにファイル所有ルールを追記
- git worktreeを切り直してから再起動
時間のロスは約40分だった。この経験から「AGENTS.mdのファイル所有ルールは省略できない」と理解した。
git worktreeでコンフリクトを根本から防ぐ
上記の失敗を防ぐ構造的な解決策がgit worktreeとの組み合わせだ。Cursor 2.0時点のchangelogでもgit worktreeと並列実行の組み合わせへの言及がある。
仕組みはシンプルで、「各エージェントを別ブランチ・別ディレクトリで動かすことで、物理的にファイルが競合しない状態を作る」というものだ。
# worktreeの状態確認
git worktree list
# 出力例
/Users/user/project abc1234 [main]
/Users/user/project-backend def5678 [feature/backend-refactor]
/Users/user/project-tests ghi9012 [feature/add-tests]
/Users/user/project-docs jkl3456 [feature/update-docs]各エージェントは異なるディレクトリで作業するため、同じファイルへの同時書き込みが構造的に起きない。完了後はそれぞれのブランチをPRにしてレビューしてからマージする。
worktree使用時の注意点：
node_modulesや.envはworktreeごとにセットアップが必要になることがある- worktree間で共有する設定ファイル（
.editorconfigなど）はメインのリポジトリ側で管理する - 使い終わったworktreeは
git worktree remove <パス>で削除する
コスト感と「向く作業・向かない作業」
コストについて
Cloud Subagentsの料金は利用プランとリソース消費量に依存する。現時点で公式が公開している具体的なコスト試算は cursor.com/changelog および cursor.com/pricing で確認できる。ここでは確認できない数値を断定しない。
体感として言えることは「長時間・大量のファイル変更を並列で走らせると消費量が積み上がる」という点だ。短いタスク（30分以内で終わる変更）をまとめて並列に流す使い方が、コスト効率が良い。
向いている作業
- ファイルが分かれているタスク：API実装・テスト追加・ドキュメント更新のように担当ディレクトリが自然に分離する
- テスト自動化との組み合わせ：「実装 → テスト通過まで走らせる」を複数機能で同時にやる
- 独立した機能追加：認証機能・決済機能・通知機能のような、互いに依存しない開発単位
- 定型的なリファクタリング：命名規則統一・型定義追加・コメント整理
向いていない作業
- 共有ファイルへの頻繁な変更が必要な作業：設定ファイル・型定義ファイル・ルーターのエントリポイントなど
- タスク間に依存関係がある作業：「Aが完了してからBを始める」必要があるもの（並列の意味がない）
- 設計が固まっていない段階の実装：エージェントが違う方向に進んでまとめるのが大変になる
副業開発の現実的な使い方としては「週末2日のうち、土曜の夜に並列で流して日曜の朝に結果を確認する」というサイクルが回しやすい。
まとめ：次の一手
Cloud Subagentsは「設定さえ正しければ、1人で複数タスクを同時進行できる」環境を提供する。ただし、最初にやらかすポイントはほぼ決まっていて、AGENTS.mdのファイル所有ルールを省略することとworktreeを使わないことだ。
今すぐできる次の一手：
AGENTS.mdをリポジトリのルートに作り、ファイル所有ルールを書くgit worktree addで並列タスク分だけブランチを準備する- Cursor 3.7以降に更新されているか確認（
Cursor > Aboutでバージョン確認） - Agents Windowを開き（Cmd+E）、小さなタスク2件を並列で試してみる
最新の仕様・料金は公式の一次情報で確認してほしい：
- changelog: cursor.com/changelog
- ドキュメント: docs.cursor.com