指示したあと、何が起きる？

この図が伝えたいこと

図は上から下へ、3幕だけで追えます。公式の Cloud Agent の動きはそのままに、骨格だけを次のように整理しています。

Desktop の Local Agent と同じ Agent の基本（依頼 → 道具で調べる・直す → 成果を返す）ですが、作業場は手元 PC ではなくクラウド上の隔離された VM です。開発環境（clone、依存の install、Secrets、起動コマンド）も、ノート PC に近い形で VM に用意されます（公式 Cloud Agent）。

• ACT 1: あなたが依頼する
• ACT 2: クラウド側の Agent が、隔離された作業用コンピュータで直し、Pull Request（変更提案）を出す
• ACT 3: あなたが確認し、反映・やり直し・中止を決める

ACT 1：頼む（あなた）

スタートは依頼文です。ブラウザやスマホから、『何を・どこまで・完了条件』を送ります。慣れてきたら Slack、Microsoft Teams の @Cursor、GitHub / Bitbucket の @cursor コメント、Linear の @cursor からも同じ幕を開けます。GitLab / Azure DevOps チームは PR コメントの @cursor ではなく、cursor.com/agents や Desktop の Cloud から起動します（accounts-setup の GitLab / Azure DevOps 節）。Slack なら `repo=` で保管庫を明示したり、調査だけのとき `autopr=false` を付けたりできます。Microsoft Teams でも `repo=` / `env=` は使えますが、公式に `autopr=false` 相当は無いので調査だけなら本文に書きます。コードを書かなくてよい代わりに、成功の定義はあなたが持ちます。

端末をまたぐときは、どこで始めても inbox や cursor.com/agents に同じ Agent が並びます。Desktop で Local を続けたいなら Remote Control、クラウド VM に丸ごと移したいなら Move to Cloud を選びます（when-desktop）。起動時には Cloud machine / Team Pool / My Machines から作業場を選ぶこともあります（first-cloud-agent）。1回のチャットで終わらない機能づくり・移行・日常の手入れは、左ナビの Projects からコーディネーターに計画と振り分けを任せられます（when-desktop の Projects 節。ベータ）。

ACT 2：クラウドで進む（Agent）

Cursor はクラウド上に隔離された仮想マシン（VM）を用意します。手元の端末とは別の作業場です。端末を閉じても、基本的には作業が続きやすいです。

最初の数ターンは、読み取り専用の探索になることがあります。保管庫を読んで状況を把握する段階で、まだファイルは変わりません。リポジトリの Hooks も、この探索が終わり書き込み可能な環境に切り替わってから動き始めます（rules-and-skills の Hooks 節）。『起動したのに何も変わらない』と感じたら、少し待つか、会話の進みを見てください。

Agent は GitHub や Origin などからコードをコピーし、main（本番に近い本線ブランチ）を直接いじらず別ブランチで直します。公式では、作業対象の保管庫に加え、依存する別リポジトリやサブモジュールにも読み書きできる権限が必要です。権限が足りないと clone や push の段階で止まります。フロントと API など複数の保管庫にまたがる仕事では、multi-repo 環境を選ぶと1つの Agent がまとめて直し、触った保管庫ごとに PR を出せます。ただし multi-repo では長期実行（Long running agents）は公式にまだ使えません。いちばん長いのは『調べる → 直す → 試す』の繰り返しで、途中の追加指示もここで受けます。作業中の追加は、いまの一手を途中で止めずに次の道具呼び出しで届けることもできます（follow-up-loop の作業中の追加指示節）。会話に Explore / Bash / Browser のカードが出ることがあります。設定不要のビルトインサブエージェントで、途中のノイズを親の会話から外します。大きな仕事を小分けにした子は、既定では親と同じ作業コピーを共有します。衝突を避けたいときや新鮮な環境で試したいときは『それぞれ別環境で』と頼むと、隔離コピー（別 VM や worktree）で動けます（公式 Subagents）。

画面が絡む仕事では、開発サーバーを起動してブラウザで画面を開き、クリックして動作を確かめることもあります。コンピュータ操作（computer use）でその確認を Agent が代わりに行い、スクショや短い動画などの成果物を PR に添えてくれることもあります。チーム設定でオフになっている場合もあります。

ここがうまくいくかは、仕事場（実行環境）の質に大きく左右されます。公式も、環境を渡さないことは『エンジニアに PC を渡さない』ことに近い、と表現しています。Cloud Agent Builds が有効な環境では、依存の install などを起動前に済ませた型から始められるので、ACT 2 に入るまでが速くなります（詳しくは第4章の実行環境レッスン）。道具がそろうほど、『書いたつもり』ではなく『動かして確認した』状態まで届きます。

一区切りつくと Pull Request（変更提案）が出ます。『こう直しました』という提案書であり、まだ本番反映ではありません。

PR を出したあとも、レビューコメントや CI の結果、Slack の返信などを待って同じ会話で自動再開させたいときは Subscriptions（サブスクライブ）を使います。依頼文に待ち条件を書くか `/subscribe` スキルで伝えます（詳しくは第2章の追加指示レッスン）。

ACT 3：確かめて決める（あなた）

差分・プレビュー・成果物（スクショや動画）を見て、次の3択です。OK なら反映（マージ）。ずれていれば追加指示で ACT 2 の作業ループへ戻す。危険や不明ならやめる・相談する。

文言だけでは足りないときは、Agent 画面からクラウド上のデスクトップを一時的に操作して自分で触って試す（リモートデスクトップ操作。公式表記は remote desktop control）こともできます。試し終わったら操作を返し、続きは Agent に任せます。

同僚に途中経過を見せたいときは、Agent の URL を送れば会話・差分・成果物を同じ画面で見せられます。公式では、Agent は起動した Cursor チームのメンバーに見えます。ただし、チームのメンバーであるだけでは開けません。相手も Integrations で GitHub などを Connect し、そのリポジトリを開ける必要があります。開いたときに Cursor が閲覧者ごとのリポジトリ権限も確認します。複数の Cursor チームにいるときは、起動時のチームと相手のワークスペースが一致しているかも確認しましょう（詳しくは第1章の初回起動レッスン）。

URL 共有は既定で閲覧のみです。同僚に追記指示まで送ってもらうには、Cloud Agents の team follow-ups 設定が別途必要です。閲覧だけなら URL 共有で足りるチームも多いです（初回起動レッスンの follow-ups 節）。

『Agent が終わった＝本番に入った』ではありません。反映を決めるまでが、あなたの役目です。焦らず確認して大丈夫です。

マージまで任せたいときは、GitHub の auto-merge（条件が揃ったら自動反映）・Agent の Subscriptions（レビューや CI を待って再開）・`@cursor autofix`（Agent 作成 PR の CI 自動修正）の3道具を組み合わせられます。くわしくは review-and-merge のマージまで任せるレシピ節へ。