AIREITERCursorのコーディネーターとサブエージェントによる構成は、大規模なコードベースのマイグレーションで確かに役立つ。ただし、放っておけば書き換えが完了する魔法のボタンではない。作業を範囲の明確な検証可能な単位に分割できる場合は強力だが、複数のエージェントが同じ契約やファイル、文書化されていない業務ルールに依存する状況では、リスクが一気に高まる。「Projects」という名称についても注意が必要だ。現時点の公式情報は、単一の製品ページとして一貫して整理されたProjects機能というより、サブエージェント、非同期実行、クラウドエージェント、長時間のコーディングに重点を置いている。
Cursor Projectsベータがマイグレーションチームにもたらすもの
Cursorの現在のサブエージェントのドキュメントでは、親Agentが専門的なタスクを別々のコンテキストウィンドウに委任する仕組みが説明されている。サブエージェントは親に結果を返し、フォアグラウンドまたはバックグラウンドで実行できる。使用するツール、モデル、書き込み権限も個別に設定可能だ。
マイグレーションにおいて、この構成単位は実用的だ。コーディネーターが全体の範囲と判断を管理し、その一方で専門エージェントがリポジトリを調査し、範囲を限定した変更を実装し、テストを実行し、結果をレビューする。Cursorは、専用の仮想マシン、ブランチ、リポジトリのクローンを持つクラウドサブエージェントについても説明している。複数のエージェントに同じチェックアウトを直接編集させるより、こちらのほうが明らかに安全だ。
ただし、ベータ版ならではの注意点がある。2026年2月のCursorのリリース議論では、非同期サブエージェントとネストしたサブエージェントが発表された一方、バックグラウンド実行のトリガーが不安定だというユーザー報告も出ていた。Cursorのスタッフは、is_background: trueに関する問題はCursor 2.6で修正される見込みだと回答している。利用可否や挙動はバージョンに依存するものとして扱い、常に保証された制御基盤だとは考えないほうがいい。
分業の効果が出やすいマイグレーションの進め方
コーディネーターが価値を発揮するのは、すべてのコードを書こうとするときではなく、作業の順序を管理するときだ。フレームワークや言語の移行では、次のように役割を分けるとよい。
| 役割 | 有用な成果物 | 別のコンテキストに分ける理由 |
|---|---|---|
| リポジトリ調査担当 | 依存関係マップ、エントリーポイント、生成コードの境界 | 検索結果がメインスレッドを圧迫しやすい |
| マイグレーション計画担当 | 作業パッケージの順序と不変条件 | リポジトリ全体を見渡した計画が必要 |
| 実装担当 | 1つのモジュール、サービス、またはワークツリーへの変更 | 範囲を絞ることで無関係な編集を減らせる |
| テスト担当 | 対象スライスに対する新規および既存のチェック | テストログは冗長で、独立して処理できる |
| レビュー担当 | リグレッション、セキュリティ、規約に関する指摘 | 新しいコンテキストのほうが実装に肩入れしにくい |
| コーディネーター | 契約のチェック、衝突に関する判断、次の作業ウェーブ | 相容れない成果物を突き合わせる場所が必要 |
Cursorの長時間コーディングに関するレポートでも、プランナー、ワーカー、ジャッジという似た構成が紹介されている。SolidからReactへの実験では、Cursorは3週間超の作業と、約266,000行の追加、193,000行の削除を報告している。ただし、慎重なレビューは依然として必要だったとも述べている。これは、この構成が大規模な取り組みを支えられることを示す材料ではあるが、マイグレーションが初めから本番投入可能になることの証明ではない。
大規模コードベースで構成のメリットが出る場面
1. 棚卸しと依存関係の把握
大規模なマイグレーションは、呼び出し箇所、ビルドスクリプト、生成ファイル、デプロイ時の前提を1つ見落としただけでも、早い段階でつまずく。専任の調査担当にこれらの対象を洗い出させ、その結果をコーディネーターがマイグレーション台帳に落とし込む形が有効だ。
これは、1つのエージェントに「リポジトリを移行して」と依頼するより強い。影響を受けるパッケージ、依存関係のエッジ、公開インターフェース、テストカバレッジ、未解決の前提を確認可能な形で残せるからだ。Cursorのモダナイゼーションのガイダンスでも、Plan Mode、.cursor/plans/、そして.cursor/rules/migration.mdcのようなマイグレーション用ルールの利用を推奨している。
2. 繰り返し実行できる範囲限定の変換
非推奨APIの呼び出し更新、独立性の高いモジュールの変換、インターフェースが安定したサービスの移行などは、サブエージェントと相性がいい。ただし、安全な境界は単なるフォルダー名では決まらない。少なくとも次の条件を満たすスライスに分ける必要がある。
- 担当者と対象ファイルの範囲が明確であること。
- 入力と出力の契約が文書化されていること。
- ビルドとテストのコマンドが決まっていること。
- ブランチまたは分離されたワークツリーを使うこと。
- 完了条件が明確であること。
Cursorのドキュメントは、複数のサブエージェントがデフォルトのチェックアウトを共有すると、互いの変更を上書きする可能性があると警告している。分離されたワークツリーやクラウドブランチを使えば、コーディネーターまたは人間がマージするまで変更を分離しておける。
3. 保守作業とバックグラウンド検証
保守作業には、もともと並列化しやすいものが多い。 flakyなテストの調査、依存関係の警告の確認、ドキュメント更新、プルリクエストのレビューなどは、互いに独立して進められる。バックグラウンド実行なら親エージェントは応答性を保てるし、クラウドエージェントなら専用の仮想マシン上で作業を継続できる。
レビューについては、CursorのAgent ReviewのドキュメントにQuickモードとDeepモードが用意されている。Deepレビューは時間もコストも大きくなるが、Cursorは複雑なロジック、セキュリティ上重要なコード、大規模なリファクタリングに推奨している。ソース管理のワークフローでは、直近の編集だけでなく、ローカルにある変更全体をメインブランチと比較できる。
この構成は保守作業に向いているが、レビューは必ずゲートとして残すべきだ。子エージェントから「成功した」と報告されても、それは統合テストの成功や、承認済みのプルリクエストと同じ意味ではない。
コーディネーターとサブエージェントの運用が破綻するポイント
横断的な契約が安全な並列化を制限する
フロントエンド、バックエンド、データベース、サービスに関する変更は、別のディレクトリにあるからといって、常に並列化できるわけではない。スキーマの変更がAPIを壊し、APIの変更が生成クライアントを壊すこともある。共有ユーティリティの変更によって、一見独立していた2つの編集が衝突する場合もある。
Cursorフォーラムに投稿された「Monorepo Execution Plan」の機能リクエストは、欠けている規律をよく表している。範囲を限定したワーカーに、グローバル要件、API契約、スキーマ変更を渡し、コーディネーターが統合前にルート、型、スキーマを検証するという考え方だ。ただし、これはあくまで機能要望であり、このワークフローのすべてが現時点で最初から整っていることを示すものではない。
マイグレーションでは、実装エージェントを起動する前に契約を固定しよう。契約を変更する必要があるなら、互換性を保つフェーズを設けるか、その変更をコーディネーターが直列に判断する次の作業にするべきだ。
コンテキストを分離すると、情報も失われる
サブエージェントはクリーンなコンテキストで開始され、親との会話を自動的に引き継ぐわけではない。コーディネーターは、必要なルール、目標となるパターン、制約、成果物を明示的に渡す必要がある。短い要約では、6時間後に重要になる細かなエッジケースが抜け落ちることもある。
会話の記憶に頼らず、永続的な成果物を使おう。
migration-plan.md：範囲と作業順序。migration-ledger.csv：パッケージの進捗と例外。contracts/：APIとスキーマのスナップショット。decisions.md：採用しなかった案。- 各実装ブランチに添付するテストレポート。
これは古くなった判断への対策にもなる。永続的なコーディネーターは履歴を保持できるが、履歴が自動的に正しいとは限らない。依存関係のアップグレード、スキーマ変更、新たに見つかったレガシー挙動の後には、前提を改めて検証する必要がある。
エージェントを増やすほどコストと干渉も増える
Cursorのドキュメントでは、5つのサブエージェントを並列実行すると、同程度の単一エージェント作業に比べてトークンをおよそ5倍消費すると見積もっている。同じドキュメントによれば、管理者がモデルをブロックしている場合、プランがそのモデルをサポートしていない場合、またはレガシープランでMax Modeが必要な場合には、モデル選択がフォールバックすることがある。予算は親エージェントのモデルだけを基準にしてはいけない。
実際のユーザーの反応を見ると、明確な制御ループが必要な理由がわかる。
「少なすぎるとメッセージが永遠にキューに残り、多すぎると互いに干渉し始める」 — @siggelabor、X
Redditの議論では、サブエージェントが想定外のモデル使用量を消費していることに気づいたユーザーや、委任を抑止するために.cursorrulesへルールを追加しているユーザーが報告されている。ただし、そのルールが確実に機能するわけではないという指摘もある。並列実行数に上限を設け、調査には安価なモデルを割り当て、計画とレビューにはより強力なモデルを温存し、次の作業ウェーブを広げる前に使用量を確認しよう。
テストが通っても、マイグレーションの成功とは限らない
SWE Refactor Benchのプレプリントは、Cursor Projectsのレビューにおいても有用な警告になる。20件のリポジトリ全体のマイグレーションタスクを対象に520回の実行を行った結果、マイグレーション監査、修正済みの挙動テスト、敵対的検証のすべてを通過したのは、わずか28回、5.4%だった。また、言語の書き換えの平均スコアは5.6/100で、ビルドツールチェーンの書き換えは31.4/100だった。
ここから得られる教訓は、検証方法を分けることだ。置き換えが完了したかどうかと、元の挙動が保たれているかどうかを別々のゲートで確認する。ソースとビルドの依存範囲から旧スタックが消えていることを確認し、そのうえで挙動を比較し、最後に独立した検証で見えにくい差分を探す。「CIがグリーン」は1つのシグナルにすぎず、最終判定ではない。
Cursorをマイグレーションに使う安全な進め方
- 旧システムのベースラインを取る。コードを変更する前に、ビルドコマンド、公開インターフェース、代表的な出力、性能に影響するパス、既知の例外を記録する。
- 読み取り専用の調査担当にリポジトリをマッピングさせる。パッケージ、生成物、設定、デプロイスクリプト、テストの不足箇所を対象に含める。
- マイグレーション計画と台帳を作る。ディレクトリだけでなく、挙動と担当範囲を基準に分割する。
- 範囲を限定した1つのスライスで試す。移行済みのリファレンス実装を用意し、命名、エラーハンドリング、互換性、テストの規約を決める。
- 分離されたブランチで実装担当を起動する。各プロンプトに正確な契約と、変更を禁止するパスを記載する。
- スライスごとにローカル検証を行う。成功を報告する前に、型チェック、ユニットテスト、統合テスト、ビルド結果、差分の概要を必須にする。
- 独立したレビューを実施する。新しいコンテキストのレビュアーを使い、リスクの高い変更や横断的な変更にはDeep Agent Reviewを選ぶ。
- ウェーブ単位で統合する。コーディネーターが契約を調整し、データ、認証、インフラ、公開APIに関わるマージは人間が承認する。
- 差分検証をやり直す。代表的な入力と失敗パスを使い、移行後のシステムをベースラインと比較する。
- 証拠が悪化したら止める。キュー、衝突、リトライ、レビュー指摘が増えているなら、並列化を増やしても前進とはいえない。
作業別に見るCursor Projectsベータの評価
| 作業 | 相性 | 推奨 |
|---|---|---|
| 独立したモジュールに対する反復的な変更 | 高い | 共有ルールを用い、分離されたブランチで実装担当を並列実行する |
| 依存関係またはフレームワークのアップグレード | 中〜高 | まず計画を立て、1つのモジュールで試してからウェーブ単位で広げる |
| テストが弱い大規模な言語書き換え | 中〜低 | 棚卸しと個別スライスにエージェントを使い、挙動の検証は人間主導で行う |
| サービスをまたぐスキーマとAPIのマイグレーション | 中程度 | 契約に関する判断は直列化し、契約が安定してから実装だけを並列化する |
| 継続的なテスト、PR、依存関係の保守 | 高い | 並列実行数とコストに上限を設けて、バックグラウンド／クラウドエージェントを使う |
| 一度きりのフォーマット変更や変更履歴の作成 | 低い | コマンドやスキルを使う。サブエージェントは余計なオーバーヘッドになる |
| テストが充実した決定的な一括リネーム | 中程度 | 機械的で簡単に元へ戻せる変換なら、スクリプトとCIを優先する |
私の判断では、テスト可能な境界があり、チームがブランチ分離を徹底できるなら、Cursorのコーディネーターとサブエージェントによる構成は大規模マイグレーションで試す価値がある。一方、文書化が不十分で挙動のテストカバレッジも弱いシステムでは、コーディネーターを自律的な実装担当ではなく、棚卸しと検証を管理する役割として使うべきだ。
Cursor ProjectsベータのFAQ
Cursor ProjectsベータはCursorのサブエージェントと同じものですか？
Cursorの公式ドキュメントは、サブエージェント、非同期実行、クラウドエージェント、マルチエージェント・コーディングを中心に整理されている。「Projects」はベータ版のラベルであり、その範囲はバージョンやアカウントによって変わる可能性がある。
Cursorのサブエージェントは並列実行できますか？
できる。ただし、独立したタスクであっても、衝突を避けるには明確な範囲、契約、分離されたワークツリーが必要だ。
サブエージェントが別のサブエージェントを起動することはできますか？
Cursorはネストしたサブエージェントをドキュメントで説明している。ただし、階層を深くするほど調整、トークン、検証のオーバーヘッドが増えるため、利用は控えめにしたい。
ノートパソコンを閉じた後もエージェントは作業を続けますか？
クラウドサブエージェントなら、専用の仮想マシン上で作業を続けられる。Cursorの説明によれば、ローカルのMCP設定はクラウドへ自動的に引き継がれない。
サブエージェントごとに特定のモデルを指定できますか？
Cursorでは継承モデルまたは特定モデルを指定できる。ただし、管理者の設定、プラン、レガシープランのルールによってフォールバックが発生することがあるため、実際の使用状況を確認したい。
サブエージェントの起動を止めるにはどうすればよいですか？
タスクの指示とリポジトリのルールを使い、そのうえで自分のプランとバージョンで実際に機能するかを確認する。ユーザー報告を見る限り、これらの制御が常に保証されるわけではない。
スウォームを有効にする前に決めること
まずは1つのマイグレーションスライスを対象に、1週間のパイロットを実施しよう。未発見のリグレッションが増えず、コーディネーターによる手戻り、レビュアーの作業時間、モデル使用量のオーバーヘッドを上回る時間短縮が得られた場合にだけ採用する。そうでなければ、その種類の変更にはスクリプト、CI、または単一のエージェントを使うべきだ。