「毎朝の依存関係アップデート」「PRレビューコメントの自動対応」「失敗したGitHub Actionsのトリアージ」——こういう定型作業、あなたも溜め込んでませんか。
私も先週まで、Renovateの通知を朝イチで一つずつ処理するのに30分は使っていました。それが Cursor Automations を組んでからは、朝コーヒーを淹れて戻ってくると PR が2〜3本、下書き済みで待っている状態になっています。
この記事では、Cursor Automations を2週間運用した実体験から、スケジュールとトリガーで定型作業を寝ている間に片付ける具体的な手順を紹介します。
結論:Automationsは「Cloud Agentを予約実行するタイマー」
端的に言うと、Cursor Automations は Cloud Agents をスケジュール(cron的な定期実行)や GitHub イベント(PR作成、Actions失敗など)をトリガーに自動起動する仕組みです。
Background Agents が「今すぐ非同期でやらせる」だったのに対し、Automations は「条件に合致したら勝手に走る」。この違いが実務ではかなり効きます。
2026年6月22日の Cursor 3.9 アップデートで Automations 周りが大きく強化され、GitHub Actions のワークフロー完了をトリガーにできるようになり、Marketplace に「失敗した Actions のトリアージ」「PRレビューコメントの自動対応」といったテンプレートが追加されました。同時に Cloud Agent が computer use ツール(ブラウザ操作など)をデフォルトで使えるようになっているので、UIを触るデモや検証まで自動化できます。
Automationsを使うべき3つのシーン
私が2週間試して「これは効く」と感じたのは、次の3パターンでした。逆に言うと、これ以外は Background Agents で十分な場合が多いです。
1. 定期的な「掃除系」タスク
依存関係のマイナーアップデート、Lintルールの追加対応、TODOコメントの棚卸し。人間がやると「今日じゃなくてもいいか」で先送りされる系です。
私は毎週月曜9時に「先週マージされた PR を読み、CHANGELOG.md を更新する」オートメーションを回しています。金曜夜に走らせるとレビューできないので、月曜の朝一に置くのがコツでした。
2. GitHub Actions 失敗のトリアージ
CI が落ちたときの「まず何が起きたか調べる」の初動を Automation に任せます。Cursor 公式の Marketplace には失敗した GitHub Actions をトリアージするテンプレートが用意されているので、これをベースにカスタマイズすると早いです。
落ちた原因の1次分析、関連する最近のコミット、修正案の PR ドラフト——ここまで自動で上がってきます。もちろん精度は100%ではないので、私は「修正案は必ずドラフトPR止まりにする」ルールを入れています。
3. PR レビューコメントへの応答
チームレビューで付いたコメントを自動で拾い、対応PR を上げる。ただしこれは「明らかに機械的な指摘」に限定した方がいい。ロジックの議論が絡むコメントは人間が返した方が早いです。
Cursor Automations のセットアップ手順
最短ルートで動かす手順です。前提として、Pro プラン以上(Cloud Agent が使えるプラン)と GitHub 連携済みのリポジトリが必要になります。
ステップ1:Cursor を最新版に更新
Automations の新機能は 3.9 以降が前提です。Settings > Application > Auto Update が有効なら勝手に上がりますが、Cmd+Shift+P → About でバージョンを確認しておきましょう。
ステップ2:cursor.com/agents にアクセス
Automation は現状 Web ダッシュボード側で作成します。IDE内から直接作れないのはちょっと面倒ですが、まあ設定は1回きりです。
ステップ3:トリガーを選ぶ
選択肢は大きく分けて3つ。
- Schedule: cron 形式または「毎日9時」のようなプリセット
- GitHub イベント: PR作成、コメント追加、Actions完了 など
- Manual: 手動起動(テスト用)
まずは Manual でプロンプトの精度を詰めてから、Schedule に切り替えるのが安全です。私は最初 GitHub イベントでいきなり動かしてクレジットをまあまあ溶かしました。
ステップ4:プロンプトを書く
ここが一番大事。Automation は人間が横で監視しないので、曖昧なプロンプトは事故のもとです。
私が使っている雛形はこんな感じ:
## Task
先週マージされた PR (base: main) を GitHub API で取得し、
CHANGELOG.md の [Unreleased] セクションに追記する。
## Constraints
- 破壊的変更は必ず "BREAKING:" プレフィックスをつける
- PR番号とタイトルを必ず含める
- 既存のフォーマット(Keep a Changelog形式)を厳守
## Output
- draft PR を base=main で作成
- Reviewer に @handa-yasuyuki を指定
- ラベル "changelog" を付与「制約」と「成果物のフォーマット」を明示すると事故が減ります。逆に「よしなにやって」系のプロンプトは Automation とは相性が悪いです。
ステップ5:PRを必ず経由させる
これは公式のベストプラクティスというより、私の運用ルールです。Automation がmain に直接コミットする権限は絶対に渡さない。3.9からは Automation はデフォルトでPRを開ける仕様になったので、ここは素直にその流れに乗ります。
クレジットを溶かさないための線引き
Cloud Agent は seat 料金に加えてメータリング課金です。Automation は「勝手に走る」ので、放置すると月末に請求を見て青ざめることになります。
私が引いている線はこれ:
実行頻度は最低でも1時間以上空ける。イベント駆動で毎PRに走らせると、コメント1つで1回起動してしまい、月100回超えは普通に起きます。debounce の仕組みは自前で入れるしかないので、なるべく Schedule 型にまとめる方が安全でした。
Composer 2 / Auto モードを基本に。Opus 4.7 や GPT-5.5 を Automation に固定すると、単価が3〜5倍変わります。Automation の用途(定型作業)なら Composer 2 で十分な体感です。
「computer use」は明示的に必要なときだけ。3.9で Automation の Cloud Agent がデフォルトで computer use を使えるようになりましたが、ブラウザ検証が要らないタスクではプロンプトで「computer useは使うな」と書いた方がクレジットが持ちます。
Background AgentsやMemoriesとの使い分け
Cursor には似た機能が並んでいて混乱しがちなので、私の中の整理を書いておきます。
Background Agents: 今このタスクを非同期で回したい。トリガーは「あなたの指示」。
Automations: 条件に合致したら走らせたい。トリガーは「時間 or GitHub イベント」。
Memories: プロジェクト固有の暗黙知を永続化する記憶層。Automation からも参照される。
.cursor/rules/*.mdc: コーディング規約など、リポジトリと一緒に版管理したいルール。
Automation は Memories と .mdc ルールを継承して動くので、事前にこの2つを整備しておくと Automation の精度が跳ね上がります。逆にここが未整備のまま Automation を組むと、毎回「うちのプロジェクトではこうする」を再説明する羽目になります。
ハマったポイントと回避策
2週間で踏んだ地雷を共有します。
認証切れ: MCP サーバー経由で外部サービスを触る Automation は、認証トークンの期限切れで無言で失敗することがありました。3.9で「MCP認証の途中でも Automation を保存できる」機能が入ったので、認証設定は最初にきっちりやっておく。
通知が来ない: 失敗しても Slack や メールに飛ばない設定だと、気づかず放置します。Cursor Dashboard の Notifications で「Automation失敗時」を有効にしておくと安心です。
同時実行の衝突: 同じリポジトリに複数の Automation が同時に走ると、worktree なしだとブランチが衝突します。私は Automation ごとに automation/{name} プレフィックスのブランチを切るルールにしました。
まとめ:今日からやる3つのアクション
ここまで長かったので、明日の朝から動かすための最小アクションだけ抜き出します。
- Cursor を3.9以降に更新して、cursor.com/agents で Automations タブを開く
- Marketplace の「Failed GitHub Actions triage」テンプレートを Manual トリガーで一度動かす。プロンプトの感覚を掴む
- 一番地味で退屈な週次作業を1つ選び、Schedule型で Automation化する。私の場合はCHANGELOG更新でした
この3ステップで、ざっくり週1〜2時間は返ってきます。Automation は「AIに指示するのは1回きり、あとは勝手に働く」という発想の転換なので、最初の1本を組むまでが一番重い。逆に言えば、1本組んでしまえば2本目からは30分で作れます。
寝ている間にPRが上がっている開発スタイル、想像以上に体に馴染みます。
参考リンク
- Cursor Changelog — Automations と Team Marketplace の最新アップデート(3.9/3.10)
- Cursor 公式ドキュメント — Agent、Rules、MCP、Skills、CLI の一次情報
- Meet the new Cursor(公式ブログ) — Cursor 3のエージェント中心設計の背景