朝起きたら、Slackに2件のメッセージが届いていた。1件はPagerDutyのアラート。もう1件は、Cursorのエージェントが作ったPRだった。
2026年3月5日、CursorはAutomationsを正式発表した。スケジュールや外部イベントをトリガーに、エージェントが自律稼働し続ける仕組みだ。Cursor社内ではすでに毎時数百のAutomationが実行されている。
「呼んだら動く」の終わり
AIコーディングツールの使い方はこれまで、基本的に「人間が起動する」ものだった。Cursorを開いて、「この機能を追加して」とプロンプトを書く。エージェントが動く。返事を待つ。これを繰り返す。
TechCrunchはこれを「prompt-and-monitor（プロンプトして監視する）ダイナミクス」と表現した。人間がプロンプトを書き、エージェントが動き、人間が結果を見る。このループに人間は常に関わり続けなければならない。
CursorのAutomationsは、このダイナミクスを変える試みだ。トリガーは外部イベント——SlackのメッセージでもPagerDutyのアラートでも、GitHubへのプッシュでも、毎朝9時でも——何かが起きたとき、人間が何もしなくてもエージェントが動き始める。
守衛の比喩が近い。従来は「何か問題があったら電話してください」と頼んで、後は自分で見回るしかなかった。Automationsは、コードベースの入口に常に誰かが立って見張っている状態を作る。問題が起きたら、勝手に調べて報告書を出してくれる。
対応しているトリガー
Cursor公式の変更ログとhelpnetsecurity.comによれば、2026年3月時点で対応しているトリガーはこのとおりだ。
- Slack（メッセージやメンション）
- Linear（Issue作成・更新）
- GitHub（プッシュ・PR作成など）
- PagerDuty（インシデント発生）
- Webhook（任意の外部サービスからのHTTPリクエスト）
- cron（タイマー。「毎朝9時に実行」など）
トリガーが発火するとクラウドサンドボックスが初期化され、MCP設定と指定したモデルでエージェントが実行される。エージェントはメモリツールを持ち、過去の実行から学習する。最大8つのエージェントがgit worktreesを使って並列実行される。
MCPとは「Model Context Protocol」の略で、エージェントが外部ツール（Datadog、Linear、Slackなど）と会話するための共通規格だ。エージェントがDatadogのログを「読む」ことも、Slackに「書く」ことも、MCPを通じて行う。
Cursor社内の実例
抽象的な説明より実例のほうがわかりやすい。Cursor社内で実際に動いているユースケースを公式変更ログとhelpnetsecurity.comからまとめる。
インシデントレスポンス
PagerDutyでインシデントが検知される。エージェントが即座に起動し、MCPでサーバーログをクエリし、最近のコード変更と相関を分析し、診断レポートをSlackに送り、修正のPRを作成する。「エンジニアがラップトップを開く前に完了」するのがゴールだ。
テストカバレッジ
毎朝、マージ済みのコードを自動でスキャンし、テストが不足している箇所をレビューする。テスト追加のPRが自動で作成される。テストを書くかどうかは人間が判断するが、何が不足しているかを調べる作業は自動化される。
PRリスクスコアリング
PRが作成されるたびに、エージェントが「ブラストラジウス（変更の影響範囲）」「複雑度」「インフラへの影響」の3軸で評価する。低リスクなPRは自動承認、高リスクなPRは貢献履歴に基づいて最適なレビュアーにルーティングされる。
BugBot
コードが追加されるたびに、バグ・ロジックエラー・スタイルの問題を自動でレビューする機能だ。TechCrunchはこれを特に取り上げている。PRをブロックせず、高リスクな問題はSlackで通知するノンブロッキング設計になっている。
週次ダイジェスト
毎週、リポジトリの活動サマリーを自動でSlackに送信する。何がマージされたか、どのファイルが最も変更されたか、テストカバレッジはどう変化したか——cronで定期実行されるだけだが、チームの状況把握コストが下がる。
セキュリティレビュー
mainへのプッシュごとに自動でセキュリティ審査が走る。脆弱性が見つかっても自動でPRをブロックするのではなく、高リスクな問題だけをSlackで通知する設計だ。開発の流れを止めずに、見落としを減らす。
従来のワークフローとの対比
インシデントレスポンスで、従来のやり方とAutomationsありを並べてみる。
❌ 従来（prompt-and-monitor）
1. PagerDutyのアラートが鳴る（深夜3時）
2. エンジニアが起き上がってラップトップを開く
3. Datadogでログを手動確認
4. Gitのコミット履歴を確認
5. 原因を特定してPRを作成
→ 深夜の呼び出しから1〜2時間かかる
✅ Automationsあり
1. PagerDutyのアラートが発生
2. エージェントが自動起動（トリガー）
3. MCPでDatadogにアクセスしてログを取得
4. Gitの最近のコミットと相関を分析
5. Slackに診断レポート + 修正PRを送信
→ エンジニアが起き上がった頃には初期調査が完了している
次はバグトリアージのユースケースだ。Linear（タスク管理ツール）にバグのIssueが作成されたとき、エージェントが重複確認・原因調査・要約投稿を自動で行い、PRを作成する。
❌ 従来（バグトリアージ）
1. Linearにバグレポートが届く
2. 担当者が気づく（翌朝かもしれない）
3. 重複Issueを手動で検索
4. コードベースを調べて原因を特定
5. 調査結果をIssueに書き込む
→ 「調べる」だけで30分〜1時間
✅ Automationsあり（バグトリアージ）
トリガー: linear_issue_created（label == "bug"）
エージェント:
- 既存Issueと重複確認
- コードベースで関連箇所を検索
- 最近の変更と照合して原因を特定
- LinearのIssueに調査結果を投稿
- 修正のPRを作成
→ 担当者が気づいたときには調査済み
PRリスクスコアリングの判断フロー
helpnetsecurity.comによれば、レビュアーの割り当ても「貢献履歴に基づく」自動判断になる。誰がどのファイルを最もよく知っているかをエージェントが判断し、適切な人に通知する。
「人間はコンベアベルトの外に出るわけではない」
Cursor社で非同期エージェントを担当するエンジニアリングチーフのJonas Nelleは、Dataconomyのインタビューでこう語っている。
「人間が完全に外に出るわけではない。このコンベアベルトの適切なポイントで呼び出される」
AIが処理を流し続けるコンベアベルトがある。人間は毎回操作する必要はないが、重要な判断ポイントには呼び出される。AIに丸投げするのではなく、AIが流れを管理し、人間が節目で判断する構造だ。
信頼できる秘書に仕事を任せることに近い。毎回指示を出して返事を待つのが「prompt-and-monitor」だとすれば、「重要な判断だけ持ってきて、あとはよろしく」というのがAutomationsの目指す姿だ。
Cursor公式はhelpnetsecurity.comでこうコメントしている。「Automationsはコードのレビューが得意だ。スタイルの細かいニュアンスや不整合から、セキュリティの脆弱性やパフォーマンスのリグレッションまで修正できる」
Cloud Agentsとの違い
CursorにはCloud Agentsという別の機能もある。似ているようで、根本的に違う。
Cloud Agentsは「呼んだら動く」。Automationsは「何かが起きたら勝手に動く」。どちらが優れているという話ではなく、用途が違う。タスクを一つこなすならCloud Agents、コードベースを常時監視するならAutomationsが向いている。
Automationsが意味すること
Cursor社の2026年3月時点のデータをまとめる。ARR（年間経常収益）は20億ドルに達し、3ヶ月で倍増している。DAUは100万人以上、有料ユーザーは36万人以上、エンタープライズチームは5万以上。企業評価額は293億ドル（2025年11月の資金調達時）だ。
Cursor Automationsの料金は2026年3月時点で公式サイトに非掲載（ログイン必須）。利用前にcursor.com/automationsで最新情報を確認すること。
コードを書く割合がAIに移るにつれ、開発者の役割は「実装する」から「定義する」に変わりつつある。何のトリガーで、何をエージェントに任せるかを決める仕事だ。
これはエンジニアだけの話ではない。どのルールでコードを自動レビューするか、どのインシデントにどう対応するかを決める判断は、プロダクトの方向性を知っている人間にしかできない。「常時稼働エージェント」が広がるとき、非エンジニアにも「自動化を定義する」役割が生まれる可能性がある。
AIが「常時稼働」になるとき、人間に残るのは「何を自動化するかを決める」という上流の仕事だ。朝起きて、Slackにエージェントからのレポートが届いている世界では、それが問われる。
