Desktop / Local が必要になるとき

Cloud だけでかなり行ける

文言、構成、多くのサイト改修、調査、PR 作成、レビュー、Automations。ここまでをブラウザ / スマホ中心で学べるのが、このパスの意図です。

自前の作業場（Team Pool / Self-Hosted など）を検討するチームもありますが、公式も多くのチームはまず Cursor が用意するクラウドの VM から始めることを勧めています。はじめての方は、環境の整備さえ進めば Cloud だけで一周を回す方が早いことが多いです。

会社がすでにサンドボックスを持っているときだけ、Team Pool の実体をその上に置けます。公式 Self-Hosted integrations の例は AWS Lambda、Cloudflare、Namespace、Modal、Daytona、E2B、Vercel、Tensorlake、Coder です。Kubernetes の新規は anysphere/k8s-workers で、古い operator は非推奨です。待たせたくないときは `--warm-idle` で空き Pod を温めておけます（詳しい人向け）。ガイドは参考アーキテクチャで、本番の検証は会社側が持ちます。

Team Pool の作業場は、使っていないあいだ休眠（hibernate）し、次の依頼で戻せる公式の動きがあります。高いマシンをずっと温めておかなくてよい、という説明です。

Self-Hosted Machines で画面確認（コンピュータ操作）を使うときは、ワーカー起動時に `--computer-use` が必要です。macOS は Cursor Computer Use ヘルパーアプリにアクセシビリティと画面収録を許可します（Terminal や Cursor 本体ではありません）。Linux は X11。画面の共有（`--share-desktop`）は Linux だけです。見るだけ（view）か、マウスとキーボードも渡す（view_and_control、既定）を選べます。共有されるのはワーカーが作った隔離デスクトップで、クリップボードは渡りません（公式 computer use）。

macOS 15 以降は、画面収録の許可を定期的に聞き直すことがあります。スクショが止まったら、ログイン画面の『1か月許可』を確認してください。

会話に Browser と出たら、画面操作の途中を子に任せているだけです。Desktop の `@browser`（エディタ内のブラウザ枠）は別物で、ページ確認・クリック・入力ができます。Cloud Agent の画面確認はコンピュータ操作です（公式 Browser / Subagents）。

自前ワーカー（My Machines / Team Pool）では、未同期の個人用 Skill は届きません。手順を揃えるならリポジトリの `.cursor/skills/` に置くか、ワーカーのイメージへ焼き込みます（公式 Agent Skills。rules-and-skills）。

Desktop が効いてくる合図

次のような気持ちが出てきたら、Desktop を足すタイミングです。Desktop でも Cloud を選べるので、『全部 Local に切り替える』必要はありません。手元の作業をクラウドへ移す『Move to Cloud』もあります。

• 手元の未保存作業や、ローカルだけの設定をまたいで試したい
• 細かい編集を自分の目でファイルツリーを見ながらやりたい
• Tab 補完や Inline Edit など、エディタ一体の速度が欲しい
• Remote Control で『自分の PC の環境』を使いながらスマホから指示したい
• チームが IntelliJ / PyCharm / WebStorm を使っていて、Cursor Desktop に移さず Agent に頼みたい
• ターミナル（CLI）で会話していて、席を離れてクラウドに続けたい

Remote Control の要点

Remote Control は、『自分のコンピュータ上で動いている Agent を、スマホからも続けて指示する』仕組みです。会話の指揮はクラウド側に移りますが、ファイル編集やテストなどの道具は手元の PC 上で動きます。リポジトリや秘密情報は手元に残り、モデルに渡す文脈だけがクラウドへ行きます。

使い方の骨格: Desktop を 3.9.8 以降にする → Agents Window の Settings → Agents で Remote Control をオン → 入力で `/remote-control` を実行して次のメッセージを送る → スマホの inbox から続きを指示。Remote Control の設定とコマンドは Agents Window が公式の入口です（エディタ画面だけでは出ないことがあります）。Teams / Enterprise では、管理者が Dashboard → Cloud Agents → Self-Hosted で Remote Control を許可している必要があります。管理者がオンにすると、チームの self-hosted worker 利用も一緒に有効になります。オフのときはメンバーは Remote Control も手元セッションの引き継ぎもできません（公式 Mobile）。PC は起きていてオンラインである必要があり、Settings → Agents の『Keep this computer awake』も併用できます。

公式では、ローカルワークスペースだけでなく Remote SSH ワークスペースでも使えます。Git remote が無いプロジェクトでも問題ありません（公式 Mobile / capabilities）。手元 PC 上のワーカーは Cursor が自動で用意するため、別途セットアップは不要です。

セッションはあなたのアカウントと手元のコンピュータに紐づき、自分が所有する Agent だけ操作できます（公式 Mobile）。他人が同じ URL を開いても、あなたの Remote Control セッションを乗っ取ることはできません。

Move to Cloud と Remote Control のちがい

端末をまたいで続ける方法は、公式には大きく2つあります。混同しやすいので、目的で選び分けましょう。

• Move to Cloud: Desktop や Local で始めた作業を、クラウド VM 上の Agent へ移す。以降、実装もテストもクラウド側で動き、手元 PC を閉じても続きやすい
• Remote Control: 会話の指揮だけクラウドへ移し、ファイル編集・テスト・git などの道具は手元 PC（または Remote SSH）で動かし続ける。リポジトリや秘密情報は手元に残る

Agents Window との関係

Desktop には Agents Window があります。複数の Agent を一覧し、Remote Control のオン／オフや Automations 作成の入口にもなる指揮台です。Web の cursor.com/agents と同じ系統の仕事を、Desktop からも回せます。

『Desktop を入れる＝全部 Local になる』ではありません。指揮は Desktop、実装は Cloud、という分け方もよく使います。

ターミナルの Cursor CLI でも同じ系統の Agent を動かせます。会話の途中でメッセージの先頭に `&` を付けると Cloud Agent へ引き継ぎ、cursor.com/agents やスマホから続きを見られます（公式 CLI。first-cloud-agent）。調べるだけは `/ask`、先に計画は `/plan`、再現できるのに原因が分からないときは `/debug` です。使い分けは prompting の Ask / Plan 節と Debug 節。手元で続けるときの sandbox / persist / worktree は、このレッスン末尾の CLI 安全な作業場節です。昨日の会話を履歴から開くのはその次の resume 節。コマンドをどこまで確認なしで任せるか（Run Modes）は、Settings → Agents → Approvals & Execution です。

大きな仕事は Projects（コーディネーター）

1つの Cloud Agent や `/goal` は、1本の仕事を終わるまで追う向きです。1回のチャットでは終わらない仕事——機能追加、移行、アプリ全体、品質の手入れ——は、公式ブログ（2026-09-10）の Projects が入口です。左ナビから開きます（ベータ。段階公開のため、すぐ出ないこともあります）。

Projects の中心はコーディネーターです。自分ではコードを書かず、計画して複数の Agent に振り分け、仕上がりをあなたに返します。実装を人に渡すので、コーディネーター自身は止まりにくく、途中の指示にも答えやすい、というのが公式の説明です。実体は Cloud Agent なので、ノート PC を閉じても進みます。手元のテストが必要なときだけ、コーディネーターが Local Agent を起動します。

共有のファイルに、調査結果や『このサービスはこう試す』といった学びが残ります。1人が見つけたやり方を、次の Agent も使えます。Slack のバグ報告チャンネルを見る、予定で動く、PR をフォローする、といった待ちもコーディネーターに頼めます。これは1つの Agent の Subscriptions や、決まったきっかけで同じ型を起動する Automations とは別物です。

• 機能づくり: 調べて共有メモに残し、計画して並列で実装・テストする。手元で触りたくなったら Local Agent。出したあとも、同じ Project がログやバグ報告を追える
• 移行: 安全なやり方を先に決めてから、少しずつ PR を重ねる。最初は1件ずつよく見て、安定してきたら見る間隔を広げてよい（公式ブログ）
• 日常の手入れ: 終わらない仕事（品質、デザインの揃え、回帰の監視）。新しい PR や Slack のバグ報告、予定に合わせて動かす

ここから先の伸ばし方

公式ドキュメントの Cloud Agents / Automations / Integrations / Mobile を、必要になった節だけ読んでみましょう。成長は、短いループを繰り返すことで起きていきます。

• 週1: 影響の小さい文言や FAQ の改善を1件、Cloud Agent に依頼して PR まで出す
• 週1: 他人または自分の PR を、成果物 → Deployments（あれば）→ プレビュー → Files changed → behind / コンフリクト確認の順でレビューする
• 隔週: 繰り返している依頼を Skill か Automations（`/automate`）の下書きにする
• 大きな仕事が出てきたら: 左ナビの Projects を開き、コーディネーターに計画と振り分けを頼む（出なければ1つの Agent のまま）

手元の変更を読む Agent Review

Desktop で手元のファイルを直しているとき、PR を出す前に『いまの変更だけ』を読んでもらう機能が Agent Review です。PR が出てから動く Bugbot や、チャットの `/review` / `/review-bugbot` / `/review-security`（Cloud Agent 向けに先に読む）とは別物です（公式 Agent Review）。

起動の仕方は公式に3つあります。① 設定でオンにすると、コミットのたびに自動で走る ② チャットで `/agent-review` ③ Source Control（ソース管理）タブから、本線との差分全体を読む。③は『直近の一手』だけでなく、手元に溜まった変更の全体を見る向きです。

設定場所は Cursor Settings → Agents → Agent Review です。Cursor 3.11 以降は Git & PRs → Pull Requests に移ります。深さは Quick（速さ優先・小さな差分）と Deep（時間と利用量は増えるが、複雑な変更向き）の2段階です。

Agent Review も `.cursor/BUGBOT.md` を読みます。プロジェクト Rules（*.mdc）はここでも効きません。PR 側の Bugbot と同じ約束ファイルです。

まちがえたときの戻し方（Checkpoints）

Desktop の Agent が変な方向に進んだとき、会話を消さずにファイルだけ前の状態へ戻せる仕組みが Checkpoints です。大きな変更の前に自動で残ります（公式 Agent overview）。

チャットのタイムラインで戻り地点を開き、中身を見てから Restore します。直前の依頼の Restore Checkpoint、またはメッセージにカーソルを載せた + からも戻せます。戻るのはファイルだけです。会話のメッセージは消えません。

Checkpoints は手元に保存され、Git のコミットとは別物です。一時的な『いまの Agent 作業を取り消す』用です。残したい履歴は、これまでどおりブランチと PR です。

Cloud Agent ではこの画面は出ません。クラウド側で外れたときは follow-up-loop のとおり『残す / 戻す』を追記するか、PR を閉じます。

• 見る: チャットのタイムラインの Checkpoints
• 戻す: Restore Checkpoint。会話は残る
• 残す: よければ Git / PR。Checkpoints は一時的な戻り地点

Agent / Plan / Ask は Desktop でも同じ

Desktop と CLI では、入力の Shift+Tab で Agent（実装）・Plan（計画してから）・Ask（調べるだけ）を切り替えます。再現できるのに原因が分からないときは Debug Mode（モード選択または `/debug`）です。詳しい使い分けは prompting の Ask / Plan 節と Debug 節です。

計画どおりに作れなかったときは、追記で継ぎ足すより、Checkpoints でファイルを戻して計画を直してから作り直す方がきれいな結果になりやすい、というのが公式 Plan Mode の案内です。

CLI の安全な作業場（sandbox / persist / worktree）

ターミナルの Cursor CLI（コマンド agent）は、Desktop と同じ Agent の入口です。席を離れてクラウドへ渡す `&` は first-cloud-agent で触れました。手元のターミナルで続けるときの安全装置が、あと3つあります（公式 CLI overview / using / changelog）。

まず sandbox です。Agent が打つコマンドを、作業場の外まで届きにくい箱の中で走らせます。`/sandbox` でメニューが開き、`--sandbox enabled` か `disabled` でも切り替えられます。設定は次の起動にも残ります。箱の中のネットワークは、許可した先以外には出にくい公式の動きです。

sudo（管理者権限）が必要なコマンドでは、伏せ字のパスワード入力が出ます。パスワードは sudo へ直接渡り、AI のモデルには見えません（公式 CLI overview）。

ターミナルを閉じても同じパソコン上で続けたいときは `agent persist` です。途中で離れるなら `/detach`。戻るときは `agent persist attach`。一覧と停止は `agent persist list` / `stop`。persist の実行の中で前の会話を続けるなら `agent persist --resume`。これは Cloud Agent への `&` とは別です。persist は手元のマシン、`&` はクラウドの作業場です。ターミナルを閉じて終わった会話を履歴から開くのは次の節の `agent resume` です。

• sandbox: `/sandbox` または `--sandbox enabled`。コマンドを箱の中で走らせる
• sudo: 伏せ字の入力。パスワードはモデルに見えない
• persist: 手元で切断しても続ける。クラウドへ渡すなら `&`
• worktree: 手元の枝を直接触らず、別コピーで作業する

CLI の会話を続きから開く（resume）

ターミナルを閉じてから、昨日の会話をまた開きたいときは persist（動かしたまま離れる）ではなく resume（履歴から再開）です（公式 CLI using / changelog）。

いちばん新しい会話は `agent resume`、起動時の `--continue`、チャットの `/resume` です。一覧から選ぶなら `agent ls`。既定はすべての作業場のチャットで、Left/Right で『この作業場』に切り替えられます。別フォルダの会話にはフォルダ名が付きます。特定の会話は `--resume チャットID` です。

persist は同じ実行を切断しても続ける起動です。resume は一度終わった／閉じた会話を履歴から開き直します。persist の実行の中で前の会話を続けるなら `agent persist --resume` です。クラウドへ渡す `&` はどちらとも別です。

会話が長くて重くなったら `/summarize`（別名 `/compress` / `/compact`）でこれまでのやり取りを要約して空きを作ります。別の方針を試したいときは `/fork`（別名 `/branch` `/duplicate`）で会話のコピーを作ります（公式 CLI slash commands）。

CLI はプロジェクト直下の AGENTS.md に加え、CLAUDE.md も Rules として読みます（公式 CLI using）。Claude Code から来たチーム向けです。はじめての約束は AGENTS.md か `.cursor/rules` で十分です。

• いちばん新しい会話: `agent resume` / `--continue` / `/resume`
• 一覧から選ぶ: `agent ls`（Left/Right でこの作業場）
• 長くなった会話: `/summarize`。別方針: `/fork`

コマンドをどこまで任せるか（Run Modes）

Desktop の手元 Agent は、ターミナルのコマンドや MCP、Web 取得の前に『あなたに確認するか』を Run Modes で決めます。設定場所は Cursor Settings → Agents → Approvals & Execution です（公式 Run Modes）。

公式が多くの人に勧めるのは Auto-review です。許可リストにある操作はすぐ走り、箱の中で走らせられるコマンドは sandbox に入れ、箱に入らないものだけ短い確認を挟みます。確認が減りつつ、危ない操作は止まりやすい、という位置づけです。分類を間違えることもある、と公式も書いています。セキュリティの壁そのものではありません。

Allowlist は、許可した操作だけ自動です。sandbox をオンにすれば、対応するコマンドは箱の中でも走れます。許可リストを空にすると、ほぼ毎回聞かれます。以前の Ask Every Time（毎回聞く）は Cursor 3.5 で廃止され、新規では選べません。同じ動きが欲しければ空の Allowlist です。

Run Everything は、すべての道具を確認なしで走らせます。sandbox も分類も使いません。確認ゼロを優先し、リスクを承知したときだけです。

ブラウザやスマホの Cloud Agent は専用の作業用コンピュータの中で動くので、Run Modes は使いません。コマンドごとに聞いてこないのは正常です。確認は終わったあとの要約・差分・成果物です（first-cloud-agent）。

• Auto-review: はじめての公式おすすめ。安全そうなものは進め、危ないものは確認
• Allowlist: 決めた操作だけ自動。空ならほぼ毎回聞く（旧 Ask Every Time の代わり）
• Run Everything: 全部自動。確認ゼロ
• Cloud Agent: 専用 VM なので Run Modes なし。コマンド承認は出ない

手元からクラウドの子へ（/in-cloud）

Desktop や CLI で手元の会話を続けたまま、次の仕事だけクラウドの子 Agent に渡したいことがあります。公式 Subagents の入口は `/in-cloud` です。打ったあとの次の依頼が、別の仮想マシンと別の枝で動くクラウドの子になります。手元の作業場は汚れにくく、長い調査や CI 直しを横で進められます。

会話ごとクラウドへ移す `&`（first-cloud-agent）や、セッションごとクラウド VM へ移す Move to Cloud とは別です。`/in-cloud` は『いまの会話は手元、次の一手だけクラウドの子』です。開いた PR をクラウド側で見守る `/autopilot` も、クラウドの子として動くことがあります。

クラウドの子が使う MCP は cursor.com/agents のチーム設定です。手元セッションの MCP ではありません。環境は保管庫に設定したものに従います（公式 Subagents）。

• `/in-cloud`: 次の依頼だけクラウドの子（別 VM・別枝）
• `&`: 会話ごと Cloud Agent へ引き継ぐ
• Move to Cloud: セッションごとクラウド VM へ移す
• `/autopilot`: 開いた PR をクラウドの子が見守る