■ 1. クラウド中心の開発実情
- 退勤直前のタスク投入:
- PCを閉じて帰宅し、寝ている間にテストとAIによるレビュー修正まで回ってPRが上がる
- 翌朝は上がってきたPRをレビューする
- 人間の操作は2つのみ:
- 止まったエージェントを起こすこと
- 承認が必要なものの確認と許可
- 海外での定着:
- grill-meで知られるMatt Pocockはローカルの開発環境から離れつつあるとポスト
- SpaceXAIのLauren Tanはworktreeは死んだ、クラウドエージェントが未来だとポスト
- Cursorの実績値:
- マージ済みPRのうちクラウドエージェント由来が昨年12月の10%から2026年7月末には56%まで伸びている
- 自身の運用比率:
- ローカル作業がゼロになったわけではないが、8割以上のタスクをクラウドエージェントで行っている
■ 2. クラウドエージェントの定義
- 専用実行環境上のエージェント:
- 手元のPCではなくCursorやCloud側がクラウド上に用意する専用の実行環境にエージェントを配置し開発を進める仕組み
- 本記事ではCursorのCloud AgentsとClaude Code on the webをまとめてクラウドエージェントと呼ぶ
- ローカルとの違い:
- リポジトリのclone、依存のインストール、ビルド、テスト、アプリの起動までを自分の環境の中で完結させる
- 1台まるごと自分の環境を持っているということ
- セッションの永続:
- PCを閉じても保持されるため、スマホアプリから閲覧も指示も可能
■ 3. 専用VMがすべて
- 成立の根拠:
- エージェントが自分専用のVMを持っていることが回答
- クラウドエージェントで得られる恩恵のほとんどはこの専用VMの結果に過ぎない
- 隔離による許可待ちの排除:
- エージェントがコマンドを打ち間違えても壊れるのはVMだけで、自分のPCに被害はない
- rmコマンドをルートで実行されMacが骨抜きにされるといった事故の被害に遭わずに済む
- 許可の確認なしで走らせるYOLOモードでも、手元のマシンを壊す可能性はない
- 切り分けが必要なリスク:
- 壊れるのはVMだけというのは自分のPCに限った話で、リポジトリのコードやシークレットをVMに渡す場合は注意が必要
- プロンプトインジェクションによる持ち出しリスクが残る
- Cursor自身も、攻撃者がエージェントをだまし悪意のあるWebサイトにコードをアップロードさせるデータ流出リスクがあると述べている
- PCが壊れないことと、資産が外に出ないことは切り分けて理解する必要がある
- 検証まで完結:
- 書いたコードを実際に動かし、テストを回し、アプリを起動して確認するところまで自分で行う
- 「書いた」ではなく実際に「動いた」まで確認してからPRが作られる
- 止まるコストが大きい前提の設計:
- Cursorはより自律的に動くよう促している、止まってしまうことのコストがはるかに大きいため
- ローカルでは許可待ちが見えるが、クラウドでは確認しに戻るまで何時間もそのまま待ち続けることがある
- 人間が隣にいない前提で、なるべく人間に聞かずに進むよう作られている
- 操作が起動と最小限の承認の2つまで減ったのはこの設計のおかげ
■ 4. クラウドエージェントのメリット
- ローカルに落とさずマージ:
- Cursorのcomputer useはブラウザを触れること以上に、検証結果などの証拠がPRに付いてくることが大きい
- 多くのタスクでエンジニアはブランチをローカルにチェックアウトすることなく、生成されたコードを安心してマージ・デプロイできる
- 通知が来たらスマホやPCで録画を見て、意図通りならそのままマージする
- 複数リポジトリの同居:
- Cursorにある機能で、フロントとバックとインフラが別リポジトリでも環境作成時に複数選択できる
- 選んだリポジトリがVMにcloneされ、参照や横断的な変更、変更した側へのPR作成が可能
- 仕事の単位がPR:
- 各VMが独立した環境のため、手元のworktree管理や編集ファイルのコンフリクトを意識する必要がなくなる
- PRにだけ集中できる状態が作れる
- PCを閉じても継続:
- 処理はクラウド環境上のVMで走るため、PCを閉じてもタスクが止まらない
- 移動前や休憩、退勤の直前にタスクを投げてから中断・退勤する
- 移動中は通知があればスマホからエージェントを起動し、許可があれば承認する
- 一旦走り出せばスマホさえあればよいという状態が作れる
- 並列実行でも手元は静か:
- エージェント1体につきVM1台で、何本並列で行ってもメモリやCPUを占有しない
- ローカルでの並列はworktreeでのディレクトリ分割やポート衝突の回避が必要で、管理コストや消し忘れのリスクも付き物だった
- メモリが逼迫しないためPCファンは回らず、熱も出ない
- 高負荷なビルドとテストとファイルの読み書きはVMが引き受けるのでPCの寿命も削らない
- PCのスペックに依存しない点も魅力の1つ
- worktreeごと不要になることが、worktreeは死んだという発言の意味
- セキュアな環境:
- コマンドを打ち間違えても壊れるのはVMのみで、自分のPCには何も影響がない
- 各社が用意したサンドボックス環境で行うため、環境によっては自分のPCより安全なケースも多い
- 許可待ちなしの実行:
- Cursorのcloud agentsは公式ドキュメント上もローカルのRun Modesを使わず、VM内のコマンドを自動実行する
- すべてのコマンドで承認が必要なフォアグラウンドエージェントと異なり、テストを繰り返し実行できる
- 細かい確認を省略できるため長時間の実行も容易
- 長時間実行への適性:
- 並行して作業でき、ユーザーの操作なしで実行でき、ノートPC上のローカルエージェントより長時間のタスクを担える
- 就寝前などに数時間かかるタスクを投げられるのはこの設計ゆえ
- 最近は起動も最大3倍速くなり、より長時間向けになっている
- トークン効率の良さ:
- Cursorはクラウドエージェントではトークン効率が20〜30%良いとポストしている
- MCP、skills、computer useの扱いを改善したという内容だが、詳細な要因は不明
- Claude Code on the webでも体感としてトークン効率は良い
- ローカルは環境ごとにインストール済みツールが異なり、探索コストがかかることが要因と推測される
- チームの環境構築の消滅:
- 開発環境をコードで定義してリポジトリに置ける、Cursorでは .cursor/environment.json が該当
- 新しいメンバーもエージェントも同じ定義から同じ環境を組み立てられる
- 開発環境もそれ自体がプロダクトであり、そのユーザーはエージェントである
■ 5. 最推しはUIテスト
- computer useによるUI検証:
- Cursorに限った話だが、エージェントがブラウザを実際に操作してクリックする
- スクリーンショットと録画を撮ってPRやセッション内に添付する
- ローカルでの環境構築やブランチのチェックアウトが不要になり、一定の安心感のもとPRをマージできる
- 環境に投資する理由:
- エージェントの能力は、それが実行される環境の能力に左右される
- 自分たちが作成しているソフトウェアを実際に使えなければ、エージェントの能力はすぐ限界がくる
- 体験の不可逆性:
- 一度体験すると戻れない
■ 6. 開発フローの再設計
- 本命はフローの再設計:
- クラウドエージェントの本命は個人に帰属するものではなく開発フローの再設計にある
- その兆候は現時点で2つある
- Stacked PR:
- エージェントを並列に走らせると最後にまとめて巨大なPRが作られる
- レビューおよびPRとレビューの依存関係の管理が大きなボトルネックになる
- GitHubはstacked pull requestsを2026年7月に全ユーザー向けに提供している
- 公式ドキュメントのone pull request per taskは、AIエージェント時代のPR管理方法としての用途を示す
- gh stack sync を打てばfetch、rebase、push、PR状態の同期まで一発で済む
- gh skill install github/gh-stack でエージェント用スキルを入れると自然言語で操作でき、量産されたPRをエージェント自身に積ませられる
- feedback-agent:
- CursorのEric Zakariassonが公開しており、さらに一歩先の未来の開発手法
- アプリ内のフィードバックとファーストパーティのセッション記録をサーバー側で受け取り、Cursorのcloud agentを起動する
- ファーストパーティのセッション記録とは、外部SaaSではなくアプリ自身が録った直近の操作履歴
- feedback-agentのフロー:
- ユーザーがアプリ内でフィードバックを送る
- 操作のタイムラインと、必要なら画像がサーバーに集まる
- cloud agentがその文脈を持って修正に着手する
- 検証できるところまで進み、テスト付きのPRを開く
- 開発者はスマホで通知を受けてレビューする
- 人間の役割の縮小:
- 人間がエディタを開かないままバグ修正が回り始め、PRまで作られる
- 人間が行うのはAIが出した検証結果とPRのレビューのみ
■ 7. ローカルに残す作業
- 意図的にローカルに残す2つ:
- UI周りの作業と計画
- UI周りの作業:
- 余白を2px空けるなど細かい作業がどうしても発生し、人間の手もそれなりに入れる必要がある
- 秒単位で確認したほうが効率が良いためローカルで行う
- CursorのDesign Modeは画面の要素を指して直す機能で、開発体験は他のツールを数段上回る
- 計画:
- 複雑なタスクや仕様を決めてから進めたいタスクは、計画だけローカルで作ってからクラウドに投げる
- Claude Codeの公式ドキュメントも、ローカルのプランモードで計画を作りリポジトリにコミットしクラウドで実行する手順を推奨
- claude --permission-mode plan で計画を作り、claude --cloud で計画ファイルを指して実行する