Cursor「Automations」が Agents Window に統合 + 新規 Automation 7日間50%オフ — 3月発表の機能を3.5アップデートで本格運用フェーズへ

Cursor のアプリ内に出ている告知3行 — 「Automations are now available in the Agents Window」「7日間50%オフ」 — は、2026年5月20日付の Cursor 3.5 リリース に対応します。Automations 機能自体は 2026年3月5日に公式ブログで発表済み（Build agents that run automatically）。今回はそれを [Agents Window](../columns/claude-code-agent-view-parallel-orchestration-2026) 内の UI へ統合し、機能拡張と販促を同時投入したアップデート です。

公式 changelog（cursor.com/changelog）の5月20日エントリにある主な変更:

1. Agents Window 統合 — Automations の作成・管理を agent run と同じワークスペース内で実施可能に 2. Multi-repo support — 1つの Automation に複数リポジトリを紐付け可能 3. No-repo automations — リポジトリ不要、監視・ツール連携専用 Automation 4. Marketplace テンプレート5種追加 — Slack digest / product analytics / FAQ / finance / customer health 5. 販促キャンペーン — 新規 Automation の agent runs が 7日間50%オフ

Cursor Automations は 「常時稼働（always-on）の cloud agent をスケジュール／イベントで自動起動する仕組み」 です（公式 docs）。クラウドサンドボックス上で Cursor の cloud agent が実行され、設定された MCP・モデル・ツールを用いて指示を遂行し、出力を検証します。

公式発表は 2026年3月5日（Cursor Blog / TechCrunch）。当初は Web ダッシュボード（cursor.com/automate）が管理 UI で、5月の今回アップデートで Agents Window 統合により 「同じ画面で対話エージェントと自動化エージェントを管理できる」 ようになりました。

Cursor を継続的に使っている方が混同しがちなので明示的に整理します。

つまり Automations は Background Agents の トリガー層であり別物ではありません。公式ドキュメントも Automations を「cloud agents running in the background」と説明しています。ただし「Background Agents が Automations にリネーム統合された」と明示する公式記載はなく、両者の境界は公式上やや曖昧 な点に注意（第三者観測）。

ツール側では PR 作成、コメント投稿、レビュアー指定、Slack 通知、MCP 連携、永続メモリ書き込みが可能。出典: docs/cloud-agent/automations

Automation の課金は agent run 単位の usage-based。Cursor の Pricing に基づく Pro / Pro+ / Ultra / Teams / Enterprise プラン枠を消費します。

Cursor 独自に重要なのが 「Automation のスコープによって誰のプールが食われるか」 の整理です。

Team Owned は共有サービスアカウント実行 のため、人事異動・退職時のオーナーシップ棚卸しが運用上必須です。逆に Private/Team Visible は 個人 Cursor アカウントの請求枠を食うので、無人運用の Automation を入れすぎると個人の上限に当たります。

公式 changelog 原文: 「For the next 7 days, all agent runs for newly created automations are 50% off.」

- 期間: 告知から 7日間（≒ 2026年5月20日〜5月27日。終了日時の明示は未確認） - 対象: 新規作成した Automation の agent run のみ。既存 Automation の run や通常の手動 agent run は対象外と読める - プラン別扱い（Pro / Pro+ / Ultra / Teams / Enterprise）の差分は公式記載なし — 個別請求で確認してください

公式・第三者の事例から、業務でハマるパターン:

- メインブランチへの push 時のセキュリティレビュー — Snyk / npm audit 系を Automation 側でも二重化 - Agentic codeowners — PR 自動評価・自動承認（特定ファイルパターン限定） - インシデント初動調査 — Sentry / PagerDuty トリガで関連コミット差分とスタックトレースを要約 → Slack 投稿 - 週次変更サマリー — 毎週金曜に repo の merge 一覧を要約して Slack へ - テストカバレッジ底上げ — 定期実行で低カバレッジファイルにテスト追加 PR を起票 - Linear バグレポートのトリアージ — Issue 作成イベントで自動分類・優先度ラベル付け - 5月追加テンプレート — Slack digest / product analytics / FAQ / finance / customer health（no-repo 型、純粋なツール連携で動く）

オブライトでは AI コンサルティング の中で、Automation の設計を Forward Deployed Engineer 型の現場伴走と組み合わせ、運用ガードレール込みで導入支援しています。

選定軸は 「既存 Cursor 導入の有無」 と 「どの SaaS トリガを業務で多用するか」。Slack / Linear / Sentry / PagerDuty を主軸にしているチームには Cursor Automations が刺さりやすく、GitHub だけで完結するチームは GitHub Actions と Claude Code Routines も検討余地があります。

1. コスト管理 — usage-based のため、cron 高頻度や暴走時の過課金リスク。Team Owned スコープは特に注意。Pro+ / Ultra の利用枠でも、複数 Automation を並列で走らせると簡単に枠到達 2. 暴走防止 — 失敗時の自動停止・上限設定の公式詳細は changelog / docs で限定的（公式詳細記載なし）。ダッシュボード側の制御に依存 3. 権限スコープ — Private / Team Visible / Team Owned の3段階。Team Owned は共有サービスアカウント実行となるため、退職時のオーナー棚卸しを SOP 化 4. 本人アカウント実行 — Private/Team Visible では作成者の個人アカウントとして PR / コメントが行われる。監査ログ要件の厳しい業界（金融・医療等）では追加設計が必要 5. MCP 連携の認可境界 — Slack/Linear/PagerDuty 等の MCP トークン管理は組織ポリシーで一元化推奨。個人連携をそのまま無人実行に流すと事故りやすい

ハマる場面:

- 常時稼働の AI レビュワー／ファーストレスポンダ を、自社で基盤を組まずに導入可能。GitHub Actions ＋自作 LLM スクリプトに比べ、Slack/Linear/PagerDuty 統合が即利用できる点で初期コストが低い - 夜間バッチでの依存関係更新・テスト追加・脆弱性スキャン といった「人が寝ている時間に進む開発」を実装しやすい。日本国内勤務時間外に米国時間で agent が稼働できる - Slack / Linear を業務基盤にしているチーム との相性が抜群

ハマらない場面:

- 完全オンプレ要件、金融機関の厳格な監査ログ要件 - リポジトリ単位で承認フローを細かく設計したい大企業 — Cursor 側のスコープ管理だけでは粒度が足りないケースあり - 非エンジニア部門での導入 — 設計には依然エンジニアスキルが必要

Enterprise プランは pooled usage / SCIM / 監査ログを備えるため、本格採用時はこの階層を前提に設計してください。

Q1. Automations と Background Agents は別機能ですか？ A. 別物ではなく、Automations は Background Agents（公式 docs では cloud agents 表記に統一中）の 自動起動レイヤ です。Cursor の Web ダッシュボードや Agents Window から作成すると、裏で Background Agents が動きます。 Q2. 50%オフは今から作る Automation だけ対象？既存のもダメ？ A. 公式文言は「newly created automations の agent runs」が対象。5月20日以降に新規作成した Automation で7日間50%オフという読みが妥当です。既存 Automation の通常 run は対象外と推定。 Q3. GitHub Actions と置き換えるべき？ A. 用途次第。決定的なビルド/テスト/デプロイは Actions のほうが堅牢。LLM 推論が必要な「文脈に応じた判断」（PR 内容の評価、コードレビュー、ドキュメント生成）は Automations が圧倒的に楽です。両者併用が現実的。 Q4. Claude Code Routines とどっち使うべき？ A. 既に Cursor を IDE として使っているチームは Cursor Automations、CLI ベースで Claude エコシステムに寄せているチームは Routines が摩擦最小。SaaS トリガ（Slack/Linear/Sentry 等）の網羅性は Cursor のほうが現時点で豊富です。 Q5. 日本語で UI を使えますか？ A. Cursor 自体は基本的に英語 UI。日本語対応の公式アナウンスは確認できません（公式記載なし）。実用上は英語 UI のまま運用しているチームがほとんどです。 Q6. オンプレで動かせますか？ A. いいえ。Automations は Cursor 管理のクラウドサンドボックスで実行されます。完全オンプレ要件のある案件には不向きです。Enterprise プランでも実行基盤は Cursor 側です。 Q7. Team Owned スコープで実行されたコミットの作者は？ A. チーム共有サービスアカウントとして記録されます。個人帰属は付きません。逆に Private / Team Visible では作成者個人として記録される点に注意。

Cursor の今回のアップデートは「Automations が3月公開のクラウド側機能から、実際の開発ワークフローに統合された運用フェーズへ移行した」というシグナルです。Agents Window 統合により対話エージェントと自動化エージェントを同一画面で扱えるようになり、Multi-repo / No-repo 対応で適用範囲も広がりました。

50%オフは7日間限定のため、SRE / QA / ドキュメント自動化など「型化できる夜間業務」を持っているチームは、この期間に PoC を1本走らせる価値があります。一方で Team Owned スコープのオーナーシップ、本人アカウント実行、コスト上限の3点は導入前に必ず社内 SOP に組み込んでください。

公式（一次ソース）: - Cursor Blog — Build agents that run automatically（2026-03-05） - Cursor Docs — Cloud Agent Automations - Cursor Changelog - Cursor — Automate ランディング - Cursor Pricing 第三者報道・解説: - TechCrunch — Cursor is rolling out a new kind of agentic coding tool（2026-03-05） - Dataconomy — Cursor's New Automations Launch（2026-03-06） - InfoQ — Cursor 3 Agent-First Interface - Digital Applied — Cursor 3 Agents Window 解説 - Tessl — Cursor launches Automations - Releasebot — Cursor Release Notes May 2026 関連コラム: - Claude Code Agent View 徹底解説 - OpenAI Symphony — チケット駆動 Codex オーケストレーション - Forward Deployed Engineer（FDE）徹底解説 注記: 「Background Agents が Automations にリネーム統合された」と明示する公式記載は確認できず、両者の境界は公式上やや曖昧です。Cursor の最新仕様は changelog / docs で再確認してください。