先に結論
Cursor Automations の今回の更新は、単なる機能追加ではありません。automation をどこで管理するか と どの仕事を repo ありで回すか の整理が一気に進みました。
先に押さえるべき変化は4つです。
- Agents Window で automation を作成、管理できるようになった
- 複数 repo を 1 つの automation に付けられるようになった
- repo なし automation を正式に組めるようになった
- 新規 automation の agent run が 7日間 50% off になった
いま Cursor を使っているチームは、既存の定期実行をそのまま延長するより、仕事を 単一 repo、複数 repo、repo なし の3つに棚卸ししたほうが早いです。
定期実行そのものの比較を先に見たいなら AIコーディングの定期実行比較｜Claude Code、Codex、Copilot、Agents Window 全体の位置づけを見たいなら Cursor 3 vs Claude Code subagents vs GitHub Copilot を比較 を先に読むとつながります。
なぜ今この更新が重要か
Cursor はこれまで、cloud agent、development environments、Agents Window と、agent の仕事場を少しずつ広げてきました。今回の更新で、その流れが automation にまでつながりました。
大きいのは、automation が cursor.com 側の機能ではなく、普段 agent を触る画面に入ったことです。これで「手で使う agent」と「定期的に回す automation」が同じ導線で見えるようになりました。
もう1つ大きいのは、automation の前提が単一 repo ではなくなったことです。複数 repo を横断する保守、Slack や webhook 起点の routine work、軽い分析レポートまで、1つの考え方で並べ直しやすくなりました。
何が変わったか
Agents Window で automation を管理できるようになった
今回のいちばん分かりやすい変化はここです。Cursor の changelog では、Automations が Agents Window に入ったと明記されています。
これで agent の単発実行と automation の継続実行が別々の場所に分かれにくくなりました。普段から Agents Window を使っているチームほど恩恵が大きいです。
特に効くのは、次のような場面です。
- まず単発の agent run で試す
- うまく回った作業だけ automation にする
- 同じ workspace で見直し、修正、停止まで行う
要するに、試作から定期運用への移行が短くなった ということです。
multi-repo automation が正式に使える
複数 repo をまたぐ仕事は珍しくありません。フロントエンドと API、アプリ本体と docs、サービス本体と運用 repo など、実務では最初から複数 repo です。
今回の更新で、Cursor Automations は複数 repo を 1 つの automation に付けられるようになりました。docs でも multi-repo environment を選べると説明されています。
この変化で向いている仕事はかなり明確です。
- PR ごとに別 repo の設定や docs も確認したい
- 定期保守を複数 codebase でまとめて回したい
- 依存更新や review を repo ごとに分断したくない
単一 repo の job を増やすより、横断前提の仕事を multi-repo に寄せる ほうが今回の更新を活かせます。
no-repo automation で routine work を切り出せる
今回いちばん運用の幅が広がるのは、repo なし automation です。Cursor の changelog では Slack digest、product analytics、product FAQ、finance、customer health monitor のテンプレートが追加されました。
これは「コードを書かない automation」も同じ製品で回せる、という意味です。Slack や webhook、Linear、PagerDuty 由来の仕事を、無理に repo に寄せなくてよくなりました。
向いているのは次のような仕事です。
- 毎朝の Slack 要約
- 週次の product metrics まとめ
- 問い合わせや FAQ の初動整理
- 請求や売上の定期レポート
- 顧客ヘルスの変化監視
ただし、repo なし automation では Open pull request などコード前提のツールは使えません。コード変更までさせたい仕事は、repo あり automation に分ける必要があります。
7日間 50% off は試行の後押しになる
今回の changelog では、新規 automation の agent run が 7日間 50% off と案内されています。期間限定ですが、導入判断の温度が高いチームには効きます。
理由はシンプルです。multi-repo と no-repo は、どちらも机上比較より実運用で差が出やすいからです。短期間でも本番に近い job を試しやすいのは大きいです。
価格だけで決める話ではありませんが、まず回して学ぶコストが下がった のは事実です。
導入前に見るべき3つの論点
1. 仕事を「単一 repo、複数 repo、repo なし」に分ける
今回の更新を活かすなら、最初にやるべきは棚卸しです。既存の scheduled task や review job を、そのまま新画面に移すだけではもったいないです。
たとえば次の分け方が分かりやすいです。
- 単一 repo: 1つの codebase だけで完結する review、lint、定期修正
- 複数 repo: アプリ本体と docs、複数サービス、複数ライブラリを横断する作業
- repo なし: Slack、webhook、Linear、分析、レポートのようなコード外タスク
この切り分けができると、automation ごとの scope がはっきりします。
2. billing と permission scope を先に決める
Cursor の docs では、Automations の課金は cloud agent usage ベースです。しかも課金先は permission scope で変わります。
- Team Owned はチーム課金で、shared service account で動く
- Private は作成者本人の課金になる
- Team Visible も課金は作成者本人に乗る
ここを曖昧にすると、「みんな見えているのに支払いは誰のものか」がぶれます。チーム導入なら、まず Team Owned にすべき job と、個人の試行で十分な job を分けるべきです。
3. identity の違いを軽く見ない
Automations は、外部サービス上で誰として動くかも重要です。Cursor の docs では、GitHub comments や reviewer requests は cursor、team-scoped automation の PR も cursor、Private automation の PR は作成者本人の GitHub account と整理されています。
これは便利ですが、監査や説明責任ではかなり大事です。レビューコメントや PR の見え方が、job ごとに同じではありません。
チームで使うなら、誰の名前で外部に痕跡が残るか を先に確認しておいたほうが安全です。
どのチームが今すぐ試すべきか
今回の更新が特に刺さるのは、Cursor をすでに daily use していて、agent の役割を広げたいチームです。
- 複数 repo をまたぐ保守や review が多い
- Slack や webhook 起点の routine work が増えている
- 単発 run から定期実行へ昇格する仕事が見えてきた
- Agents Window を team standard に寄せたい
逆に、単一 repo の軽い job しかなく、コード外タスクもほぼないなら、すぐに構成を変える必要はありません。その場合は既存の scheduled task を維持しつつ、まず 1 本だけ no-repo automation を試すくらいで十分です。
まず試す順番
最初の1本は、失敗しても困らない job が向いています。
- Slack digest や weekly summary を no-repo で試す
- docs や運用 repo を含む軽い multi-repo job を作る
- PR や code change を伴う automation を Team Owned で見直す
この順番なら、UI の変化、scope の違い、課金と identity の差まで一通り確認できます。
実行環境まで含めて比較したいなら Cursor cloud agent development environments vs Codex vs GitHub Copilot｜実行環境・監査・複数repo運用で選ぶ も合わせて読むと判断しやすいです。
まとめ
Cursor Automations の 2026-05-20 更新で見逃せないのは、automation が増えたことより 運用の分類が変わったこと です。
見るべき順番は、機能一覧より先に次の3つです。
- その仕事は単一 repo、複数 repo、repo なしのどれか
- その automation は誰の課金で動くか
- PR、コメント、通知は誰の identity で残るか
ここが整理できれば、Agents Window 統合、multi-repo、no-repo の価値がきれいに活きます。逆にここを飛ばすと、便利になったぶんだけ運用が散らばります。