見出し画像

「ITニュース」｜Cursor — Automations が「コードを触らないエージェント」まで広げる

まるしょー｜ITニュース分析配信

はじめに

Cursor は 2026年5月20日、Automations（定期実行や GitHub・Slack などのイベントで Cloud Agents をバックグラウンド起動する機能）を Agents Window に統合したと Changelog で公開しました。

これまでも cursor.com/automations から Automations は使えましたが、今回の更新では Agents Window（エージェントをまとめて扱う UI）と同じ場所で作成・管理できるほか、複数リポジトリを 1 本の自動化に載せられる マルチリポ と、リポジトリを付けない no-repo 構成が Changelog で前面に出ています。Marketplace には Slack 朝刊、Stripe 収益レポート、顧客ヘルス監視など コードを触らない 向けテンプレが 5 件追加されています。新規作成した Automations のエージェント実行は 7 日間 50% オフ、とも説明されています。

読みどころは、2026年5月19日の Jira 連携 の翌日に、「チケットからの単発依頼」に加えて 定期・イベント駆動の自動化 と 非エンジニア向けワークフロー が公式に足された点です。ただし Jira は Automations のトリガー一覧には載っていません（執筆時点の 公式 docs）。Jira 連携と Automations は 別の入口 として並存します。

※本記事は Cursor の公開情報（Changelog、ドキュメント、Marketplace）をもとにした一般的な整理です。契約、法務、セキュリティ、監査、課金の判断は、最新の公式ドキュメント、自社の契約・管理画面、専門家・担当部門の確認に従ってください。Cursor への取材は行っていません。

この記事での用語


1. 何が起きたのか

先に結論です。

  • 2026年5月20日、Cursor が Automations の更新を Changelog で公開

  • Agents Window から Automations を作成・管理できる（従来の cursor.com/automations に加えて）

  • マルチリポジトリを 1 本の Automation に載せられる

  • リポジトリなし（no-repo） の Automation が公式に前面化。Slack ダイジェスト、Product finance（Stripe 等）、Customer health などのテンプレ追加

  • 新規作成 Automations の agent runs が 7 日間 50% オフ（Changelog 明記）

  • Automations は Cloud Agent 利用量課金（公式 docs）

忙しい方向けに一言でいうと、
Cursor の Cloud Agents が「IDE や Jira からの単発依頼」だけでなく、スケジュールと SaaS イベントで回る自動化プラットフォームに近づいた、というニュースです。

2. 公式情報ベースの要点

2-1. Automations とは何か

Cursor Docs — Automations では、Automations は Cloud Agents をバックグラウンドで動かす仕組みと説明されています。例として、PR のバグレビュー、脆弱性の深掘り、Slack でのバグトリアージ、コードベースの定期ダイジェストなどが挙げられています。

作成の流れ（docs の要約）は次のとおりです。

  1. トリガーを選ぶ（毎時、cron、PR が開いたとき、Slack にメッセージが来たとき、など）

  2. エージェントへの プロンプト（指示文）を書く

  3. 使える ツールを選ぶ（Slack 送信、PR コメント、MCP など）

  4. リポジトリが必要か、複数か、不要かを選ぶ

  5. Automation を作成して実行を確認する

2-2. 今回の Changelog で新しく強調された 3 点

Changelog（May 20, 2026） の中心は次の 3 つです。

Agents Window 統合 — Automations を Agents Window と cursor.com/automations の両方から扱える。エージェントと自動化を同じワークスペースで管理する、という UI 上の整理です。

マルチリポジトリ — 1 つの Automation に複数 repo を載せ、エージェントが 横断して 実装・テスト・検証する、という説明です。2026年5月13日の クラウドエージェント開発環境 で整備されたマルチリポ環境と方向性が揃います。

no-repo（リポジトリなし） — コードを clone しない Automation。Slack、MCP、webhook、Linear、PagerDuty など コード外のシグナルだけで動かす用途向け、と docs が説明しています。Open pull request などコード変更が必要なツールは リポジトリ必須（docs 明記）。

Changelog で紹介された no-repo 向け Marketplace テンプレ（5 件）の例:

2-3. トリガーとツール — 何に反応し、何ができるか

docs に載る トリガーの例（執筆時点）:

  • スケジュール（cron）

  • GitHub / GitLab（PR 作成・push・マージ・ラベル変更・CI 完了など）

  • Slack（チャンネルへの新規メッセージ、チャンネル作成。public チャンネルのみ）

  • webhook（HTTP POST で外部システムから起動）

  • Linear（Issue 作成、ステータス変更、サイクル終了）

  • Sentry（Issue 作成・更新）

  • PagerDuty（インシデント発生・確認・解決）

ツールの例:

  • PR の 作成・コメント・レビュアー依頼

  • Slack 送信・チャンネル読取

  • MCP サーバー接続（接続先の全ツールに Agent が触れうる — docs は信頼できるサーバーだけ接続するよう注意）

  • Memories（run 間で永続メモ。不正入力によるメモ汚染のリスクを docs が明記）

Jira は Automations のトリガー一覧にない一方、Linear は載っています。2026年5月19日公開の Jira 連携 は、チケット assign や `@Cursor` による 別ルートの Cloud Agent 起動です。混同しないことが重要です。

2-4. 課金と権限 — Private と Team Owned

Automations は Cloud Agent 利用量に従って課金されます（cloud agent pricing 参照）。

Team Owned に昇格すると、Automation は 作成者の個人 auth ではなくチームのサービスアカウントで動きます。docs では、webhook API キーの再生成、MCP の OAuth をサービスアカウント向けに再設定が必要になる場合がある、と明記されています。

GitHub 上の 身份も docs で整理されています。

  • Team スコープの Automation が開く PR → `cursor` として表示

  • Private の Automation が開く PR → 作成者の GitHub アカウント

  • GitHub コメント・レビュー → `cursor`

2-5. 7 日間 50% オフの範囲

Changelog では、新規作成した Automations の agent runs が 7 日間 50% オフ、とだけ書かれています。

  • 対象: 新規 Automations の実行（Changelog 文言）

  • 対象外の可能性が高いもの: 既存 Automations、IDE 内の通常 Agent、Jira／Teams 経由の単発 Cloud Agent（Changelog 上は Automations プロモと切り分けて読む）

試用 PoC を組むなら、作成日から 7 日以内に試すのが無駄が少ない、という実務メモになります。

3. 直近の Cursor と並べて読む

Automations だけを切り取ると、「また機能が増えた」以上の文脈が見えにくくなります。直近 2 週間の公式発表は、入口・環境・モデル・自動化の四層で進んでいます。

関連する note 記事

組織で Cursor を本格利用するなら、「どこから起動するか（Teams／Jira／Automation）」「どの環境で動かすか」「定期か単発か」「誰の利用プールに載るか」をセットで方針化したほうが、単機能の試用より事故が少ない、という読み方ができます。

4. 誰に関係する話か

特に no-repo はエンジニア以外も触りやすい反面、Slack・Stripe・Databricks など本番データに近い系統に接続しうるため、DLP と承認フローを機能デモより先に決めるほうが安全です。

5. 混同しやすい点

6. 短期・中期・長期の整理

時間軸は次のとおりです。

  • 短期: 0〜3か月

  • 中期: 3か月〜1年

  • 長期: 1年以上

6-1. 短期（0〜3か月）

予想される動き — Agents Window 統合で Automations 作成が増える。no-repo テンプレが PM／CS の PoC 入口に。PR opened → レビュー Bot 型が増えやすい。

不確実性 — 50% オフ終了後の継続率。Enterprise の監査・データ所在要件。Slack public 限定で社内運用が合わないケース。

効果が出にくい条件 — 組織が Cloud Agent 従量課金や MCP 接続を禁止。cron 頻度を抑えられずコストだけ先行。

6-2. 中期（3か月〜1年）

予想される動き — Teams（会話）／Jira（チケット）／Automations（定期・イベント） の三層運用がチーム標準に。Team Owned Automation が共有 bot として定着。Sentry／PagerDuty 連携が SRE フローに載る。

不確実性 — Jira が Automations トリガーに統合されるか。Memories 汚染インシデント。GitHub/GitLab 以外の VCS 要求。

効果が出にくい条件 — Linear 未使用で Linear トリガーが死蔵。IDE 手動文化が続き Automation が少数の実験止まり。

6-3. 長期（1年以上）

予想される動き — 「監視・チケット・会話・コード」が同一 Cloud Agent 課金・ポリシー下に整理される。Marketplace テンプレが社内標準パッケージ化。

不確実性 — 汎用エージェント（ChatGPT、Copilot 等）の SaaS ネイティブ自動化との差の縮小。自動 PR・自動 Slack 返信の責任分界・規制。

効果が出にくい条件 — BYOK 固定で Cursor Cloud 依存を避ける組織では主流にならない可能性。

7. まず確認したいチェックリスト

  1. 試す Automation は 単発依頼（Jira/Teams） か 定期・イベント（Automations） かを分けたか

  2. リポ必須か no-repo かを用途に合わせて選んだか

  3. Team Owned / Private を決め、課金の載り方を関係者に共有したか

  4. 7 日 50% オフの終了日をカレンダーに置いたか（新規 Automation のみ）

  5. MCP 接続先を信頼リストで制限したか

  6. webhook を使う場合、認証キーの保管・ローテーション担当を決めたか

  7. Memories を使う Automation で 信頼できない入力が混ざらないか

  8. Slack トリガーが public チャンネル前提で足りるか

  9. cron 頻度 × モデルで月次上限を試算したか

  10. PR 自動作成の Automation に 人間レビュー必須を CI／ブランチ保護で縛ったか

  11. Jira 連携記事 と併せ、入口ごとの社内ルールを書いたか

8. まとめ

今回の Cursor Automations 更新は、Cloud Agents を 「都度依頼」から「回し続ける」 方向へ広げるニュースです。

Agents Window 統合、マルチリポ、no-repo、Marketplace テンプレ 5 件、新規 Automation 7 日間 50% オフ——見出しは多いですが、芯は コードを触らない運用自動化 と イベント駆動のエージェント が公式に載った、という一点に集約できます。

一方で Jira 連携（前日） とは 別ルート です。Jira はチケットからの単発起動、Automations は cron・PR・Slack・Linear・Sentry などの トリガー駆動——役割を分けて設計しないと、入口が増えただけでガバナンスが追いつきません。

最初の一歩としては、PR opened → 軽いレビュー か Slack digest のどちらか 1 本を 7 日以内に PoC し、Team Owned か Private かと 月次上限を一緒に決めるのが現実的です。

主な参照

免責

本記事は公開情報をもとにした一般的な整理です。契約、法務、セキュリティ、監査、調達、課金の判断は、Cursor の最新ドキュメント、自社の契約・設定画面、社内規程、専門家・担当部門の確認に従ってください。投資判断の材料ではありません。

【PR】
私も転職エージェントを利用して転職しました。


いいなと思ったら応援しよう！