2026年8月19日のアップデートで、Cursor の Cloud Agents に Subscriptions(購読) が入りました。PR や Slack スレッドを購読させて、レビューコメントや CI 失敗が来たら勝手に起きて直す。文字通り「放置できるエージェント」です。
私は先週から自分の副業プロジェクトで2週間ほど回してみました。正直、最初は「また似たような自動化機能か」と半信半疑だったのですが、これは Automations とも Hooks とも別物でした。ワークフローの前提そのものが変わる感覚があります。
この記事では、Subscriptions の実装手順、PR自動追従・Slack待受・スケジュール実行の3パターン、そして触っていて気づいた運用上の注意点までまとめます。
結論:PR を作らせたら、あとは購読で放置する
先に答えを書きます。Cursor Subscriptions を使うなら、まず「PR を開いてマージまで green を保て」というプロンプトから始めるのが一番効きます。 これが最も費用対効果が高いユースケースです。
理由はシンプルで、Cloud Agents は自分が作った PR に自動で購読し、CI 失敗や bot コメントに応答して修正を push してくれるから。あなたが何も設定しなくても、デフォルトで PR の面倒を見続けます。
私が最初に試したときは、Playwright テストが 3 回連続で落ちて、そのたびに自動で直しに来ました。朝スマホで PR を見たら、CI が緑になっていて拍子抜けしたくらいです。
では、この挙動をどう自分でコントロールするか。順番に見ていきます。
Subscriptions とは何か:従来のトリガーとの違い
過去記事で扱った Automations(スケジュール実行)や Hooks(コマンドフック)と、Subscriptions は別レイヤーです。ここを混同すると設計を間違えます。
Agent のタスクは最後のコミットで終わらないことがほとんどです。CI が通る必要があり、レビュアーがコメントを残し、チームメイトが Slack で質問に答える必要がある。Subscriptions は Cloud Agent がそれらのイベントを待って、発生したら再プロンプトなしで作業を続けられるようにする仕組みです。エージェントはイベントソースを購読し、ターンを終え、マッチするイベントが来ると起きる。
つまり、従来の Webhook 的な「1回で撃って終わり」ではなく、会話や PR スレッドに紐づく“定常的な購読” なんですよね。これは重要な違いです。
8月19日のアップデートで加わったのは、まさにこの点です。単発トリガーではなく、Cloud Agent が特定の進行中の会話(PR スレッドや Slack スレッド)を購読して追い続ける。「@cursor check back in an hour and keep going until that feedback is in」という Cursor 公式の例のように、PR が開いた時に1回動くだけでなく、レビューコメントが着地するたびに再起動し、スレッドが解決するまで作業して自分で停止する。これが「イベント駆動」の実際の仕組みで、単発 Webhook の撃ちっぱなしではない。
ここが Automations(cron 相当)と決定的に違うところです。Automations は「毎朝9時にこれを実行」というスケジュール駆動。Subscriptions は「このスレッドに何か起きたら反応」というリアクティブ駆動。両者は補完関係にあります。
Subscriptions の使い方:プロンプトに書くだけ
Subscriptions を有効にする方法は、拍子抜けするほど簡単でした。設定ファイルもトグルもありません。
購読するには、待ちたい内容をプロンプトに書けばいい。例えば「open a PR and keep it green until merge」や「ask in #releases and wait for approval」といった具合。組み込みの /subscribe スキルを呼び出すこともでき、何を監視するかを伝えればエージェントが適切な購読を選びます。
日本語で書くと、こんな感じです。
/subscribe
認証まわりのリファクタリング PR を開いて、
CI が全部通ってマージされるまで green を保って。
レビューコメントは付いたらその場で対応。私が試した限り、/subscribe を明示的に打たなくても、プロンプトに「〜まで続けて」「〜を待って」という意図が含まれていれば、Cursor 側が自動で購読を張ってくれました。ただし明示したほうが挙動は安定します。
プロンプト設計の3つのコツ
2週間回して見えてきた、購読が効くプロンプトの書き方です。
1. 終了条件を明確にする。「マージされるまで」「approval が付くまで」のように、エージェントが自分で「終わった」と判断できる基準を書きます。曖昧だと 180 日購読しっぱなしになりかねません。
2. 反応対象を絞る。「レビューコメントには対応、雑談スレッドは無視」のように、何に反応して何を無視するか書いておく。特に Slack だと、無関係な発言でエージェントが起きる無駄が減ります。
3. 失敗時のフォールバックを書く。「3回連続で CI が落ちたら、修正せず自分に @mention して止まって」のように、暴走防止の脱出条件を入れておくと安心です。
PR 購読:CI 修正を自動化する具体パターン
実務で一番使うのはこれです。PR を作らせたあと、CI・レビュー・bot コメントに反応させる。
Cursor の Cloud Agents は PR や Slack スレッドを購読でき、スケジュールイベントで自動起動もする。作成した PR には自動購読が張られ、CI 失敗や bot コメントを完了まで修正し続ける。
私が使っている雛形はこれです。
@cursor 以下を実装して PR を開いてください:
- src/auth/session.ts の JWT 検証を jose に置き換え
- 既存の unit test を全て通す
- Playwright の e2e test も通す
PR を開いた後は、以下を守って:
- CI が失敗したら原因を特定して push で修正
- Renovate や CodeRabbit のコメントは対応または reply
- レビュアーから明示的な修正依頼が来たら対応
- ただし「approach を変えて」レベルの大改修は私に確認してから
- マージされたら購読を解除これをキックすると、あとは Slack か iOS 通知でウォッチしているだけで済みます。自分は先週、朝コーヒーを淹れている間に3往復の CI 修正が終わっていました。
購読の寿命と重複防止
地味に大事な仕様が2つあります。
購読は単一のエージェント会話に属し、イベントはその会話をフォローアップメッセージとして起こす。バーストは合体し、近い時間に複数イベントが来た場合はエージェントを一度だけ起こし、行動前に元(PR・スレッド・issue)を読み直す。購読は最長 180 日。エージェントは待機が終わると自分で購読を解除する。
180日という長さは驚きました。ただ、これは裏を返すと忘れた頃に起きる可能性があるということ。長期案件で放置した PR がある日ふと起きて余計な変更を入れる、みたいな事故は起こり得ます。使わない購読は明示的に切っておくのが無難です。
Slack 購読:承認待ちワークフローに組み込む
個人開発だと出番が少ないですが、副業でチームに入っている人は覚えておく価値があります。
Slack で「@cursor check back in an hour and keep going until that feedback is in」のように投げると、指定時間後にフィードバックを取りに戻ってきます。
「Slack で質問して、誰かが返信したら続行する」というパターンも可能で、購読するには待ち内容をプロンプトに書くだけ。例えば「open a PR and keep it green until merge」や「ask in #releases and wait for approval」といった書き方になります。
実務での使いどころは、こんなシーン。
- 本番デプロイ前に PM の approval を待つ
- API 仕様の判断をシニアに委ねる
- 本番 DB マイグレーションの実行タイミングを人間に任せる
私は本番マイグレーションの前に #deploy チャンネルで approval を待たせる運用に落ち着きました。「approve と reply があったら実行、reject なら理由をヒアリング」というプロンプトです。
Slack 連携が動く前提条件は事前準備が必要で、Cursor の Slack 統合では @cursor にプロンプトを付けてメンションすることで Cloud Agent を動かせる。ワークスペースに Cursor の Slack アプリをインストールし、Cursor 側で最終設定を行い、リポジトリプロバイダを接続してデフォルトリポジトリを選ぶという流れです。
3つの購読パターンを比較する
何をトリガーにするかで、Subscriptions は主に3つの使い方があります。整理するとこうなります。
| 購読パターン | トリガー | 主な用途 | 停止条件の書き方 | 注意点 |
|---|---|---|---|---|
| PR購読 | GitHub/GitLab の PR スレッド | CI 修正・レビュー対応 | 「マージまで」「クローズまで」 | デフォルトで自動購読、明示不要 |
| Slack購読 | Slack スレッドの返信 | 承認待ち・判断委譲 | 「approve/reject の reply まで」 | 無関係発言で起きる可能性あり |
| スケジュール購読 | 時刻・cron | 定期チェック・リマインド | 回数や日付を明示 | Automations と機能が近い |
表だけだと差が分かりにくいのですが、実際に使い分けが必要なのは**「エージェントが自分で終わりを判断できるか」**の部分です。PR購読は マージ/クローズ という明確な終端があるので放置しやすい。Slack購読は終端が曖昧になりがちで、脱出条件をプロンプトで書いておく必要があります。
/goal と組み合わせて長期タスクを回す
Subscriptions とセットで入った /goal コマンドも触れておきます。単体でも便利なんですが、購読と組み合わせると化けます。
/goal はエージェントに長寿命の目標を与える機能で、「フレーキーテストを全部直して CI を緑にする」といった目標に対して、何ターンかかっても取り組み続け、必要ならカスタムモードや /loop で定期チェックインしながらガイドできる。
私が試している組み合わせはこれです。
/goal src/legacy/ 配下のテストカバレッジを 80% に上げる
進め方:
- 1回の PR は500行以内に収める
- テスト追加とリファクタは別 PR に分ける
- 各 PR は Subscribe して CI green までフォロー
- 全部達成したら /goal を完了扱いにして報告目標を渡して、あとは各 PR に自動購読が張られる形。1週間放置していたら、8個の PR が積まれて6個マージされていました。残り2つは私が方針を確認する必要があるコメントが付いていて、そこで止まっている。この止まり方が絶妙で、暴走しないバランス感覚があります。
Subscriptions を使うときに注意すべき挙動
2週間触って、事故ではないけれど「これは知っておくべき」と思った挙動をいくつか。
バースト合体を過信しない。近い時刻の複数イベントが1回にまとまるのは便利ですが、レビュアーが立て続けに3コメント付けた場合、エージェントは古いコメントも「まだ有効」と解釈することがあります。長いスレッドでは、こまめに「解決済み」マークを付けたほうが精度が上がりました。
購読中もクレジットは走る。ここが Automations との大きな違いで、購読状態は無料でも「起きた回数×トークン」でクレジットを消費します。フレーキーな CI で 10 回起きたら、その分だけ課金される。私は月初に一度、うっかり e2e が不安定な PR を購読させたまま寝てしまい、翌朝にクレジット消費が普段の3倍になっていました。
Cloud Agents 限定である。Subscriptions は今のところ Cloud Agents 専用です。ローカルの Composer や Agents Window では使えないので、$20 の Pro プランでも Cloud Agents のクレジット枠を消費する前提で設計が必要です。
リポジトリ接続は事前必須。誰かがリポジトリから Cloud Agent を起動する前に、Cursor アカウントの管理者がソースコントロールを接続する必要がある。GitHub(Cloud と Enterprise Server)、GitLab(Cloud と Self-Hosted)、Bitbucket Cloud、Azure DevOps のセットアップが可能。個人利用でも GitHub 連携は最初に済ませておきます。
この機能で開発フローをどう組み替えるか
Subscriptions が入ったことで、私の開発フローは明確に変わりました。以前は「PR を出す→CI が落ちる→戻ってきて直す」のループを1日に何度も回していたのが、いまは「PR を出させて購読させる→他の作業に移る→通知が来たら判断だけする」に変わっています。
注意深く運用しないとクレジットは溶けます。ただ、時給換算で考えると、CI 修正の待ち時間や気分の切り替えコストが減る効果はそれ以上に大きい。副業で夜しか作業できない層こそ、寝ている間に PR を進めさせるこの使い方が向いていると感じました。
まずは今夜、次に開く1本の PR に対して「マージまで green を保って」と一行付け足すところから始めてみてください。挙動が肌感覚で分かれば、あとは自然に組み替えていけます。
参考リンク
- Cursor Changelog - Cloud Agents and Cursor Harness Improvements (Aug 19, 2026) — Subscriptions 導入の公式リリースノート
- Cursor Docs - Cloud Agent Capabilities — 購読の仕様・180日制限・バースト合体などの詳細
- Cursor Docs - Cloud Agents — Cloud Agents 全体の起動方法とソース管理連携
- Cursor Docs - Slack Integration — Slack 連携の初期設定手順