Cursorのエージェントが「寝て、起きて」PRを片付ける — クラウドエージェント8月アップデート

これまでのAIコーディングエージェントは、基本的に「呼ばれてから動く」道具だった。プロンプトを打つ。作業する。終わる。次の指示を待つ。人間がボタンを押し続けないと、何も進まない。

Cursorが8月19日から27日にかけて立て続けに出したクラウドエージェントのアップデートは、その前提を静かに崩しにきた。エージェントが自分でPR（プルリクエスト）を見張り、レビューコメントが付いたら勝手に起きて直し、スレッドが片付くまで働き続ける。GitHubに繋いでいなくても、リポジトリすら無くても、プロンプト一発で作り始められる。作ったものはそのままブラウザで確認して、ボタンひとつで公開URLにできる。

Cursor自身はこの方向性を「常時稼働（always-on）エージェント」と表現している。今回は、その言葉が具体的にどこまで実装されたのかを見ていく。

変化その1: 「購読」する — 一発起動から、起きて働き続けるへ

今回の目玉は、クラウドエージェントの「subscriptions（購読）」だ。

Cursorのエージェントは、PRやSlackのスレッド、あるいは定期実行のスケジュールといった「イベントの発生源」を購読できるようになった。エージェントは購読したあと一度眠り、対象に何か動きがあると自分で起きて、同じ会話の文脈を引き継いで作業を再開する。用が済めば自分で止まる。

ここが従来との決定的な違いだ。Cursorは6月のAutomationsアップデートで、GitHub PRのレビューコメントやCIの完了、Slackの絵文字リアクションをトリガーにエージェントを起動する仕組みを整えていた。ただ、あれは基本的に「イベントが来たら一回動く」という単発の引き金だった。

今回の購読は、その一回きりを「継続的な見張り」に変える。たとえばエージェントが自分で作ったPRには自動的に購読が付き、CIが落ちれば直し、ボットのコメントが付けば対応し、レビューのスレッドが解決するまで往復を続ける。人間が「もう一回動いて」と押し直す必要がない。

Slackでの使い方として公式が挙げているのが、@cursor check back in an hour and keep going until that feedback is in（1時間後にまた確認して、フィードバックが揃うまで続けて）というような指示だ。エージェントに「締め切りまで粘れ」と言えるようになった、と言い換えてもいい。

なお現時点では、この購読はクラウドエージェント限定の機能とされている。ローカルのエージェントセッションでは使えない。

変化その2: /goal で「ゴールを握り続ける」

購読と対になるのが、長時間セッションを支える仕組みだ。

新しく入った/goalコマンドは、セッションをまたいで長く生きる「目標」をエージェントに持たせる。公式が例に出しているのは「不安定なテスト（flaky tests）を全部直してCIを緑にする」といった、一回のやり取りでは終わらないタスクだ。エージェントはこの目標を握ったまま、途中で脱線せずに作業を続ける。

裏側の作りも変わった。サブエージェント（親エージェントが呼び出す補助エージェント）は、それぞれ独立したVM（仮想マシン）上で、プロジェクトのクリーンなコピーを持って動くようになった。加えて、作業の途中で人間が方向修正のメッセージを送っても、実行を割り込んで止めるのではなく、キューに積まれて順番に処理される。

地味だが、これは長時間の自律作業では効いてくる改善だと思う。並行して走る複数のサブエージェントが同じ作業ツリーを汚し合わない。人間が横から一言添えても、作業が壊れて最初からやり直しにならない。「長く回すほど破綻する」というエージェントの弱点を、正面から潰しにいっている。

変化その3: GitHubなし、リポジトリなしで作り始められる

もうひとつの大きな更新が、クラウドエージェントの入口の変化だ。

これまでクラウドエージェントを使うには、GitHubなどのソース管理サービスを繋いでおく必要があった。今回、それが不要になった。リポジトリ選択の画面で「Start from scratch（ゼロから始める）」を選び、そのままプロンプトを打てば動き出す。裏側ではCursorが自前のコードホスティング「Origin」にリポジトリを用意してくれる。

作っている最中の環境も、その場で確認できるようになった。Cursorはクラウドエージェントの動いているライブ環境をブラウザに直接ポートフォワードする。開発サーバーの画面をそのまま覗けるし、デザインモードのようなツールも使える。手元にクローンしてnpm run devを叩く、という手順が要らない。

そして、気に入ったものができたら公開まで一直線だ。Vercelアカウントを繋いで「publish」を押すと、作ったものにライブURLが振られる。作業をOriginリポジトリとしてCreate repoボタンで保存し、公開範囲をprivateかinternalで選ぶ。GitHubを開くことなく、思いつき→生成→プレビュー→公開が一本の線でつながる。（なお公開機能を使うにはVercelアカウントが必要だ。）

リポジトリのAppsタブからVercelを繋いでおけば、PRごとにプレビューデプロイが作られ、そこで動作を試してコメントでき、マージすれば本番に出る、という流れも用意されている。

これで何ができるようになるのか

3つの変化を並べると、Cursorが描いている絵が見えてくる。「人間が起動し続けなくても、build（作る）とship（出す）を回し続けるシステム」だ。

現実的に効きそうなのは、まず定型的な保守の自動化だろう。CIが落ちるたびに人間が飛んでいく必要がなくなる。PRに付いたレビュー指摘への対応、依存パッケージの更新に伴う細かい修正、フレーキーテストの掃除。こうした「重要ではないが放置もできない」作業を、エージェントが購読して勝手に片付けてくれるなら、レビュアーの認知的な負担はかなり減る。

もう一段面白いのは、GitHubなしの入口とライブプレビュー、Vercel公開が揃ったことだ。企画のたたき台を「文章で説明する」代わりに「動くURLで見せる」のが、数分でできるようになる。非エンジニアのプロダクトマネージャーが思いつきをその場で形にして共有し、良ければそのままOriginに保存してチームの正式なリポジトリに育てる——そういう使い方が現実味を帯びてくる。プロトタイピングの初速という点では、素直に強い。

さらに購読と/goalを組み合わせれば、「夜のうちにフレーキーテストを全部潰しておいて」と寝る前に頼み、朝には緑になったCIとPRが並んでいる、という運用も理屈の上では成立する。開発者の役割が「書く人」から「目標を渡して結果をレビューする人」に寄っていく、というわけだ。

正直な評価と、留保しておきたい点

ここは素直にすごい、と思う。単発トリガーを継続的な購読に進化させ、そこに「ゴールを握り続ける」仕組みとクリーンなサブエージェントVMを足してきた設計は、常時稼働という言葉に中身を与えている。

一方で、鵜呑みにしない方がいい点もある。

まず、エージェントが自律的にPRを追いかけて直し続けるということは、裏を返せば「人間のレビューが追いつかないうちに変更が積み上がる」リスクと隣り合わせだ。Cursorは以前、社内PRの3割前後がエージェント製だと明かしていたが、それはCursorのコードベースが長年かけてエージェントに優しく整備されてきた結果でもある。整理されていないレガシーなコードベースで同じ自律性を放つと、むしろ後片付けが増える可能性がある。ガバナンスや承認フローをどう挟むかは、導入側が設計しなければならない。

次に、GitHubなしの入口はOriginというCursor自前のホスティングに寄っていく設計だ。手軽さと引き換えに、コードの置き場所がCursor側に寄る意味は理解しておいた方がいい。既存のGitHubワークフローに深く根を張っているチームには、必ずしも最短ルートとは限らない。

そして料金。購読や長時間セッション、サブエージェントを本格的に回せば、その分だけクレジットを消費する。常時稼働を字義通りに走らせ続けたときのコスト感は、実際に運用してみないと読みきれない。ここは「便利そう」で判断せず、小さく試して消費量を見てからスケールさせるのが賢い。

待機から常時稼働へ、という方向

複雑な設計判断や要件の解釈、ビジネスロジックの決定は、当分人間の仕事のままだろう。それでも今回のアップデートで、パターンが明確で反復的な作業を常時稼働のエージェントに任せる——という選択肢は、実験段階からひとつ手前まで来た。

いきなり全部を委ねる必要はない。まずはCIの失敗対応やPRの定型的なレビュー対応あたりで購読を一本設定し、消費クレジットとアウトプットの質を見ながら、任せる範囲を広げていくのが現実的な入口になりそうだ。

詳細な変更点はCursorの公式changelogで確認できる。