Cursor 3 クラウド→ローカル ハンドオフ実践ガイド：長時間コーディングタスクの分割法

まず結論

Cursor 3 を短い編集以上に活用したいなら、タスクの時間のかかる中盤をクラウドエージェントに任せ、リスクの高い最後の仕上げをローカルマシンで行う。

実践的な分け方：

1. 時間・並列作業・サンドボックス探索が必要なとき、Cursor 3 でタスクを開始する。
2. クラウドエージェントが頻繁な軌道修正なしで完了できる程度にプロンプトを絞る。
3. 結果を信頼する前に、エージェントのスクリーンショット・デモ・diff を確認する。
4. 手動編集・ローカルシークレット・ハードウェア固有のテスト・最終レビューが必要なら、セッションをローカルに移す。
5. 自分のマシンでチェックを再実行してからのみコミットする。

Cursor は 2026-04-02 に Cursor 3 を発表した。エージェントファーストの統一ワークスペースで、ローカルとクラウドのエージェント間で明示的なハンドオフが可能になった。プロダクトのアップデートは注目に値するが、開発者にとってより実用的な問いは単純だ：コーディングタスクはいつクラウドに残し、いつラップトップに引き戻すべきか？

クラウドエージェントは Pro プラン（$20/月）以上で利用可能。Pro+（$60/月）と Ultra（$200/月）はフロンティアモデルの使用量上限が高い。

誰向けか

このチュートリアルは、すでに Cursor を実際のリポジトリで使っていて、すべてのタスクを同じ扱いにするのをやめたいチームやソロ開発者向けだ。

以下の作業が多い場合に有効：

• 複数ファイルにまたがるリファクタリング
• ラップトップを閉じた後も実行し続ける必要があるタスク
• スクリーンショットやデモで出力を検証するレビュー重視の作業
• マージ前にローカルでの最終パスが必要なコード変更

2 行の小さなパッチならこのワークフローは不要。ごく小さな編集では、ハンドオフのオーバーヘッドのほうが節約できる時間より大きい。

Cursor 3 で何が変わったか

Cursor 3 は見た目の刷新ではない。公式アナウンスは、エージェントベースのソフトウェア開発に向けた統一ワークスペースとして位置付けている。マルチワークスペースレイアウト、ローカルとクラウドのエージェントを一箇所で確認、環境間のより速いハンドオフを備える。

新インターフェースを開くには、Cursor で Cmd+Shift+P → Agents Window を実行する。サイドバーに、すべてのワークスペースで実行中のエージェント——ローカルもクラウドも——が表示される。

本質的な変化：ローカルとクラウドは別々の習慣を持つ別々のモードではなく、1 つのタスクの 2 つのステージになった。

Cursor 3 は Composer 2 も導入している。Cursor 自社製のコーディングモデルで、使用量上限が高い。クラウドセッションをローカルに移すと、Composer 2 が高速イテレーション——編集、テスト再実行、最終的な引き締め——を担い、フロンティアモデルのクォータを消費しない。

この組み合わせが Cursor 3 を以下のようなタスクでより有用にする：

• クラウドエージェントがバグを調査し、複数ファイルを編集し、修正のドラフトを準備
• あなたがセッションをローカルに引き戻してプロジェクト固有のチェックを実行し、最終 diff を引き締める
• 長時間の変更がクラウドで進行し続ける間、あなたは別のタスクに移る
• 複数のターミナルやタブを切り替える代わりに、1 つの場所で出力を確認

始める前に

ハンドオフに頼る前に以下を準備：

• 自分のマシンですでに正常にインストール・テストできるリポジトリ
• 明確な境界を持つタスク。曖昧な「コードベースを改善して」ではなく
• 短い受入ルール。例えば「この 3 ファイルを更新し、テストを 1 つ追加し、デプロイ設定には触れずに止める」
• すべての生成 diff に対するレビュー習慣

この準備を飛ばした場合、問題はたいていハンドオフにあるのではない。エージェントが最初から境界のあるタスクを持っていなかったことが問題だ。

ステップ 1：Cursor 3 で開始し、クラウド向けの部分を定義する

エージェントワークスペース（Cmd+Shift+P → Agents Window）を開き、タスクのどの部分をラップトップから離れた場所で実行すべきか決める。

タスクがデバイスよりも時間を必要とする場合、クラウドエージェントがより良い出発点だ。適した例：

• 多くのファイルにわたるバグの追跡
• 初回パスのリファクタリング準備
• 最近マージされたコードのテスト生成
• 広い diff のリスクパターンレビュー

悪いクラウドファーストプロンプトの典型：

Clean up this project and make it better.

良いプロンプトの典型：

Refactor the authentication retry logic in the billing worker.
Touch only the retry helper, the worker entrypoint, and the related tests.
Keep behavior unchanged except for duplicate retry suppression.
Run the relevant test target before stopping.
Do not edit deployment files.

重要なのは、クラウド部分を 10 回のフォローアップ修正なしで完了可能にすることだ。

ステップ 2：長時間タスクをクラウドに残す

Cursor 3 のアナウンスは、クラウド→ローカルおよびローカル→クラウドのハンドオフをプロダクトのコア機能としている。直接的なユースケースは、ラップトップを閉じたりコンテキストを切り替えたりすると止まってしまう長時間の作業だ。モバイル・Slack・GitHub・Linear からもクラウドエージェントを起動でき、すべて同じサイドバーに表示される。

クラウド側を使うメリット：

• タスクがコードベースを読んで複数ファイルの変更を提案するのに時間がかかる
• エージェントを動かしたまま、自分は別のタスクに移りたい
• サンドボックス実行でレビュー成果物を作ってから、ローカルで結果に触れたい
• 1 台のマシンでの直列編集ではなく、複数のエージェントを並列で使いたい

ここでスコープを厳格にする。ローカル限定のシークレット、マシン固有のサービス、ラップトップにしか存在しないツールに依存するタスクは、環境の処理方法を把握済みでない限り、クラウドエージェントに渡さない。

シンプルなルール：

• クラウドは探索、ドラフト変更、広範な調査に使う
• ローカルは最終検証、センシティブなコンテキスト、承認に使う

ステップ 3：ローカルに引き戻す前にエージェント出力をレビューする

Cursor 3 のクラウドエージェントはデモとスクリーンショットを生成する——cursor.com/agents で見れるのと同じ成果物が、デスクトップアプリにインラインで表示される。これらをレビューのショートカットとして扱い、タスク完了の証明とは見なさない。

セッションをローカルに移す前に 4 つ確認：

1. エージェントは指定したファイルとスコープ内に留まったか？
2. リスクやトレードオフをすばやくレビューできるほど明確に説明したか？
3. スクリーンショットやデモは実際の受入基準と一致したか？
4. diff は問題を解決し、無関係なクリーンアップを紛れ込ませていないか？

いずれかが不合格なら、乱雑なセッションをローカルに持ち帰って手動修正するのではなく、先にタスクを引き締めてからハンドオフする。

ステップ 4：最後の仕上げのためにセッションをローカルに移す

Cursor 3 のハンドオフは、エージェントが重い作業を終えたが最終変更にはローカル制御が必要、という場面でもっとも価値がある。

ローカルに移すタイミング：

• 自分のエディタ設定のほうが手動コード編集が速い
• ローカルテストが実環境に依存している
• クラウド実行では保証されないハードウェア・ブラウザ・サービスへのアクセスが必要
• コミットや PR の前に慎重な最終 diff レビューが必要

この段階でタスクをゼロから書き直さない。同じセッションを続け、安全に完了するために必要な最小限のローカルアクションだけを行う。ローカルに移ったら、Composer 2 が高速イテレーションを担う——使用量上限が高く、小さな編集でフロンティアモデルのクォータを消費しない。

良いローカルフォローアッププロンプト：

Keep the current plan. Re-run the failing tests locally, remove any unrelated diff noise, and stop after the smallest passing patch.

エージェントのコンテキストを保持しつつ、最終検証がしやすい場所に実行を移している。

ステップ 5：タスクを再びクラウドに戻すべきか判断する

ハンドオフは常に片道ではない。もっとも速いワークフローがクラウド→ローカル→再びクラウドになることもある。

例：

• クラウドエージェントが広範なリファクタリングを準備
• あなたがローカルに引き戻して環境固有の問題を 1 つ修正
• 別の作業をしながら、長いフォローアップタスクを続行するためにクラウドに送り返す

このループは境界がまだ明確なときだけ使う。タスクが曖昧になったら、自動化を止めて通常のレビュー付きコード変更として仕上げる。

クラウド vs ローカル対照表

もっともよくあるハンドオフの失敗

早すぎるローカル移行

クラウドエージェントが安定したドラフトに到達する前にローカルに引き戻すと、メリットの大部分を失う。まずクラウド側に遅い調査と広範な編集を完了させる。

遅すぎるローカル移行

diff がすでにリスキー、ローカル依存、または環境の仮定だらけなら、クラウドエージェントの自力回復を待たない。ローカルに引き戻してパッチを引き締める。

実行中にプロンプトが膨張する

タスクが「リトライロジックを修正」から「ついでにキューワーカーもモダン化して可観測性も改善」に静かに変わると、ハンドオフが機能しなくなる。可能な限り 1 セッション 1 タスクを維持する。

スクリーンショットを検証扱いにする

スクリーンショットは何かがレンダリングされたことを証明できる。ロジック・テスト・エッジケースが正しいことは証明できない。

コピーして使えるシンプルなワークフロー

再現可能なデフォルトが欲しいなら、以下の手順：

1. Cursor 3 で境界のあるプロンプトでタスクを開始する。
2. クラウドエージェントに広範な読み取り、ドラフト、初回検証を任せる。
3. デモ、スクリーンショット、diff をレビューする。
4. 最終テストとクリーンアップのためにセッションをローカルに移す。
5. ローカルパスがクリーンな場合のみコミットする。

Cursor 3 のハンドオフモデルから価値を得る、もっとも安全な方法だ。すべてのコード変更をエージェントオーケストレーション実験にする必要はない。

FAQ

Cursor 3 のハンドオフはソロ開発者にも有用か、チーム限定か？

両方に有効だ。チームは並列作業と共有レビュー習慣からより多くの価値を得るが、ソロ開発者もコンテキスト切り替え時やラップトップを閉じる際にタスクをクラウドで実行し続けられるメリットがある。

すべてのタスクをクラウドから始めるべきか？

いいえ。Cursor 3 はハンドオフを容易にするが、小さな編集は依然としてローカルが適している。時間・並列性・長時間実行が即時の手動制御より重要な場合にクラウドを使う。

クラウド→ローカルのハンドオフを避けるべきときは？

タスクがローカル限定のシークレット、マシン固有の挙動に依存する場合、または diff が小さく自分で完了したほうが速い場合。

Cursor 3 でコードレビューは不要になるか？

なっていない。Cursor 3 はエージェント周りのワークフローを改善するが、レビューは引き続きあなたの仕事だ。主なメリットは、レビューステップを後回しにでき、かつより良い成果物を伴うことだ。

検証メモ

検証日：2026-04-07、公式ソースのみ使用。

主要ソース：

• Cursor 3 アナウンス（2026-04-02 公開）——マルチワークスペースレイアウト、ローカル/クラウドエージェントサイドバー、クラウドデモとスクリーンショット、クラウドとローカル間のセッションハンドオフ、Composer 2 統合
• Composer 2 アナウンス——自社製コーディングモデル、高い使用量上限、ローカル高速イテレーション向け
• Cursor 料金ページ（2026-04-07 確認）——Pro $20/月（クラウドエージェント、MCP、スキル、フック含む）、Pro+ $60/月（3 倍使用量）、Ultra $200/月（20 倍使用量）、Teams $40/ユーザー/月

検証項目：

• Cursor 3 リリース日、エージェントワークスペースの入口（Cmd+Shift+P → Agents Window）、クラウドエージェントの起動面（モバイル、Slack、GitHub、Linear）、デモ/スクリーンショット成果物
• クラウドエージェントが Pro ティア以上に含まれること
• Composer 2 がローカル高速イテレーションモデルであること