Cursor Automations解説 — AIが自分で起動する時代のコーディングとは

Cursor Automations

AIコーディングツールには暗黙の前提があった。人間が指示を出し、AIが応える。プロンプトを書くのは常にこちら側で、AIは呼ばれるまで待っている。

Cursorの新機能「Automations」は、その構図をひっくり返した。

3月5日にリリースされたこの機能は、Slack、GitHub、PagerDuty、Linearといった外部サービスのイベントをトリガーに、AIエージェントがクラウド上で自動的に起動して作業を始める。あなたが寝ている間にPRをレビューし、あなたが会議に出ている間にバグの原因を調査し、あなたが朝コーヒーを淹れている間にテストコードを書いてPRを作成する。

これは「AIアシスタント」ではない。「AIの同僚」に近い。

何がトリガーになるのか

対応しているトリガーは、現時点で以下の通り。

GitHub: PRのマージ、プッシュなどのイベント
Slack: 特定チャネルへの投稿（ただしパブリックチャネルのみ。プライベートチャネルは非対応）
Linear: イシューの作成
PagerDuty: インシデント発生
Webhook: 任意のHTTPリクエスト
Cron: スケジュール実行

トリガーが発火すると、クラウド上にサンドボックス環境が立ち上がり、事前に設定したMCP（Model Context Protocol）接続とモデルを使ってエージェントが指示を実行する。ローカルマシンには一切触れない。

ここが重要だ。Cursor 3のAgents Windowがローカルとクラウドのハイブリッド環境だったのに対し、Automationsは完全にクラウドで完結する。つまり、あなたのPCが閉じていても動く。

実際にどう使われているのか

公式ブログやユーザー事例から見えてくるユースケースは、大きく2つのカテゴリに分かれる。

監視・レビュー系

セキュリティレビュー: mainブランチへのプッシュごとにエージェントが起動し、差分に脆弱性がないか監査する。過去に議論済みの問題はスキップし、発見事項をSlackに投稿する。

自動コードオーナー判定: PRのブラストラディウス、複雑度、インフラへの影響度からリスクを自動分類。低リスクのPRは自動承認し、高リスクのPRにはコントリビューション履歴に基づいてレビュアーを割り当てる。

インシデント対応: PagerDutyのアラートが鳴ると、エージェントがDatadog MCPでログを辿り、直近のコード変更を調査し、オンコール担当が完全に目を覚ますころにはSlackに調査報告と修正案付きのPRが届いている。

定型作業系

テストカバレッジ: 毎朝、直近でマージされたコードをレビューし、テストが不足している箇所を特定。既存の規約に従ってテストを書き、PRを作成する。

バグトリアージ: Slackチャネルにバグ報告が届くと、重複チェック→Linearチケット作成→コードベースでの原因調査→元スレッドへの要約返信、を自動で行う。

週次サマリー: マージされたPR、バグ修正、技術的負債、依存関係の更新をまとめたダイジェストをSlackに投稿する。

面白いのはRippling社の事例だ。エンジニアのAbhishek Singh氏は、ミーティングノート、TODO、Loomリンクなどを2時間おきにSlack・GitHub・Jiraから収集し、Confluenceにまとめるパーソナルアシスタントを構築した。これはもはやコーディングツールの使い方ではなく、業務オペレーション自動化だ。

セットアップは意外とシンプル

cursor.com/automationsにアクセスし、テンプレートを選ぶところから始められる。Marketplaceにはコードレビュー、テスト生成、インシデント対応などの定番パターンがプリセットとして用意されている。

ゼロから作る場合の流れはこうだ。

トリガーを選ぶ（GitHub PRが最も手軽）
実行指示を書く
MCPの接続先とモデルを設定する
手動テストで動作確認
有効化

ひとつ注意点がある。指示は具体的に書かないと使い物にならない。「コードをレビューして」では結果がブレる。「セキュリティ脆弱性を確認し、クリティカルな問題が5件以上あればフラグを立て、なければ自動承認」くらいの粒度が必要だ。エージェントは書かれた通りに動く。人間のように「空気を読む」ことはしない。

エージェントにはメモリ機能があり、過去の実行結果から学習して精度を上げていく。初回はぎこちなくても、回を重ねるごとに改善される設計になっている。

料金 — 安くはない

Automationsを使うにはCursorの有料プランが必要だ。

| プラン | 月額 | 備考 | |--------|------|------| | Pro | $20（約3,000円） | $20分のクレジットプール | | Pro+ | $60（約9,000円） | 3倍のクレジット | | Ultra | $200（約30,000円） | 20倍のクレジット、優先アクセス | | Teams | $40/ユーザー | 共有設定、SSO対応 |

2025年6月にリクエスト制からクレジット制に移行しており、Automationsの実行もクレジットを消費する。ここが落とし穴になりうる。

あるユーザーは半日で4,000万トークンを消費したと報告している。Automationsをcronで高頻度に回したり、複雑なエージェントを複数同時稼働させたりすると、Ultraプランでもクレジットが枯渇する可能性がある。月末に予想外の請求が来ないよう、最初は控えめな頻度から始めるのが賢明だ。

とはいえ、週5時間以上の作業を自動化できるなら$200/月は安い、という声もある。ROIの計算は各チームの状況次第だが、少なくとも「試してから判断できる」$20のProプランから始める選択肢があるのはありがたい。

正直な評価 — すごいが、粗い

Automationsのコンセプトは間違いなく正しい方向を向いている。「人間がAIに聞く」から「AIが勝手に動く」へのシフトは、AIコーディングツールの進化として自然だし、CursorがCI/CDのような開発インフラ寄りのポジションを取りに行っている戦略的意図も明確だ。

セキュリティレビューやテスト生成のような定型タスクでは、すでに実用レベルに達している。「PRが来たら自動でレビュー」は、多くのチームが今すぐ導入して恩恵を受けられるだろう。

ただし、現時点での粗さも目につく。

Slackはパブリックチャネルのみ対応。プライベートチャネルでのやり取りが多い組織ではトリガーの選択肢が狭まる。GitLabやJiraの公式統合がないのも、エンタープライズ環境では痛い。GitHubとLinearがメインのチームには刺さるが、それ以外のツールスタックを使っている組織は、Webhook経由で自前構築する必要がある。

もうひとつ。3月にはCursorがコードの変更を黙って巻き戻すバグが報告され、開発チーム自身が確認している。Automationsがクラウド上で自律的に動く以上、こうした不具合が「見えないところで」起きるリスクは無視できない。人間のレビューなしにPRをマージさせるような設定は、現時点ではまだ怖い。

Cursor 3記事との棲み分け

先日公開したCursor 3の記事では、Agents WindowやDesign Modeなど「IDEとしてのCursor」の進化を取り上げた。Automationsはそれとは別レイヤーの話だ。

Cursor 3が「エンジニアが座っている間の生産性」を上げる機能なら、Automationsは「エンジニアが座っていない間の生産性」を生み出す機能。両者は補完関係にある。

誰に向いているか

GitHubでPRベースの開発をしているチーム: コードレビュー自動化だけでも導入価値がある
オンコール体制があるチーム: PagerDuty→調査→報告のパイプラインが自動化される恩恵は大きい
定型的なコード作業が多いチーム: テスト生成、ドキュメント更新、依存関係チェックなど

逆に、個人開発者やGitHub以外のツールスタックがメインのチームは、まだ様子見でいい。

AIコーディングツールの競争は「補完の速さ」から「文脈の深さ」へ、そして今「自律性」へとフェーズが移っている。Cursor Automationsは、その最前線にある機能だ。粗さはあるが、方向性は明確。2026年後半にどこまで磨かれるかで、Cursorの立ち位置が決まる。