CursorのAutomationsで常時稼働エージェントを作ったら、朝イチの作業が勝手に片づいていた話

👀 結論から

Cursor の Automations は、ざっくり言うとエディタを開いていない時間もエージェントを働かせておく機能です。

私はこのブログの自動化をリモートエージェントで組んでいるので、「Cursor 側でも同じことができるのか」が気になって触ってみました。

結論から言うと、トリガーの種類が多くて作るのも簡単なので、定型作業を持っている人ならかなり刺さると思います。

ただ、これは課金と権限の設計を先にやっておかないと怖いタイプの機能でもありました(・_・;)

💡 Automations とはなにか

Automations は、あらかじめ決めたトリガーと指示にもとづいて常時稼働するエージェントを作る機能です。

トリガーとして使えるのは、こんな種類でした。

スケジュール（毎朝6時など）
GitHub（PR review comment、PR review submitted など）
Slack
Linear
PagerDuty
Webhook

「毎朝6時にバックログからissueを1件取ってPRを作る」「PRごとにセキュリティレビューを走らせる」といった例が公式でも紹介されていて、定型作業をそのまま置き換えられる構成になっています。

作成場所も複数あって、Agents Window から・cursor.com/automations から・ローカルセッションの /automate スキルから・Marketplace のテンプレートから、と選べます。

🔧 /automate スキルで作るのが一番早かった

いくつか試した中で、一番ラクだったのは /automate スキルでした。

やることは、やりたいワークフローを自然言語で説明するだけです。

そうすると Cursor 側がトリガー・指示・使うツールを自動で組んでくれるので、設定画面でポチポチする必要がありません。

私は「毎朝、前日にマージされたPRを見て、READMEと実装がズレていたら指摘だけしてほしい」と書いて投げてみました。

返ってきた設定を見ると、スケジュールトリガーと読み取り中心のツール構成になっていて、こちらが意識していなかった「書き込みをさせない」部分まで拾っていたのは正直ありがたかったです(・∀・)

とはいえ生成された設定はそのまま信じずに、トリガーの時刻と対象リポジトリだけは自分で確認しました。

✨ 実際に組んだ2つの自動化

今のところ、実際に動かしているのは2つです。

1. 毎朝のドキュメント差分チェック

前日のマージ内容とドキュメントのズレを指摘するだけの、読み取り専用の自動化です。

あえてPRを作らせず、指摘だけにしているのがポイントで、朝に結果を見て「直す価値があるか」を自分で判断しています。

2. PRが来たときの観点チェック

GitHub のイベントをトリガーに、PRの内容に対して決めた観点のチェックリストだけを走らせています。

こちらも承認や自動マージはさせていません。人間のレビュー前に観点の抜けだけ拾ってもらう位置づけです。

どちらも「勝手に直す」ではなく「気づいて教える」までに絞ったのですが、これが自分の運用にはちょうどよかったですね。

🔒 暴走させないための線引き

常時稼働する仕組みなので、入れる前に決めておいたほうがいいことが2つありました。

1つ目は課金です。

スケジュールやイベントで勝手に走る分だけ実行回数が増えるので、トリガーの頻度は最初はゆるめにしておくのが安全です。

私は最初「1時間ごと」で組みかけて、冷静に考えて「1日1回で足りるな」と直しました(´･ω･`)

2つ目は権限です。

自動化にコードを書き換える権限まで渡すかどうかは、作業の可逆性で決めるのがよさそうです。

指摘だけなら失敗しても読み流すだけですが、PRの作成やマージまで任せると、間違ったときの後片付けが一気に重くなります。

「まず読み取りだけで組んで、信用できたら書き込みを足す」という順番にしておくと、事故が起きにくいと感じました🤔

🔧 最初の1本におすすめの自動化

Automations を初めて組むなら、「読むだけ・報告するだけ」の自動化から始めるのがおすすめです(^^)

最初の1本に向いているのは、こんなものです。

朝のPRまとめ: レビュー待ちのPRを一覧にして、変更の要点を3行ずつまとめる
依存パッケージの更新チェック: アップデートがあるパッケージを報告するだけ（更新はしない）
落ちたCIの要約: 夜のうちに落ちたテストを集めて、原因の候補を書き出す

どれもコードを書き換えないし、外に何も送らないので、多少うまく動かなくても困りません👀

いきなり「自動で修正してPRを出す」ところから始めると、権限や課金の設計を詰める前に動いてしまって怖いです(・_・;)

まず報告だけの自動化を1〜2週間動かして、内容が信頼できると分かってから、書き換える自動化に進むのが、失敗しにくい順番だと思います✨

パパ系Webエンジニア〜愛用ガジェット一覧 🛍️

AI開発・執筆に使っている作業デスク環境を楽天ROOMにまとめています ✨ デスク周りの参考にどうぞ 🙌

🙌 まとめ

Cursor の Automations は、トリガーと指示で常時稼働エージェントを組める機能でした。

スケジュール / GitHub / Slack / Linear / PagerDuty / Webhook がトリガーになる
/automate スキルに自然言語で伝えるのが一番早い
「勝手に直す」より「気づいて教える」に絞ると運用が安定する
トリガー頻度と権限は先に決める。読み取りから始めるのが安全

定型作業を抱えている人にとっては、エディタを開く時間そのものを減らせるタイプの機能だと思います🙌

※ トリガーの種類や作成手順は今後も変わる可能性があります。最新情報は Cursor 公式ドキュメントをご確認ください👀