常時稼働のエージェントを構築できる Cursor Automations を提供開始します。

これらのエージェントは、スケジュールに従って実行することも、送信された Slack メッセージ、新しく作成された Linear の issue、マージされた GitHub の PR、PagerDuty のインシデントなどのイベントをトリガーに実行することもできます。これらの組み込みインテグレーションに加えて、Webhook を使って独自のカスタムイベントを設定することも可能です。

#ソフトウェアエンジニアリングパイプラインの高度化

コーディングエージェントの登場により、エンジニア一人ひとりがこれまでよりはるかに多くのコードを書けるようになりました。しかし、コードレビューやモニタリング、保守のスピードは、まだ同じペースでは向上していません。Cursor では、開発ライフサイクルのこうしたその他の部分を拡張するために、自動化を活用しています。

呼び出されると、自動エージェントはクラウドサンドボックスを立ち上げ、設定済みの MCP とモデルを使って指示に従い、自身の出力を検証します。エージェントはメモリツールにもアクセスでき、過去の実行結果から学習し、繰り返しを通じて精度を高めていきます。

過去数週間にわたり、Cursor の自社コードベース上で多くの自動エージェントを動かしてきた結果、自動化には大きく 2 つのカテゴリがあることが分かってきました。

#レビューとモニタリング

自動化は、変更内容のレビューに非常に役立ちます。細かなスタイルの乱れや一貫性の問題から、セキュリティ脆弱性やパフォーマンスのリグレッションまで、あらゆるものを検出して修正できます。

実際、Bugbot は、多くの意味で最初の自動化機能と言えます。PR が作成・更新されるたびに実行され、1 日に何千回もトリガーされ、リリース以来、何百万ものバグを検出してきました。自動化を使うことで、さまざまな用途に合わせて多様なレビュー用エージェントをカスタマイズできます。ここでは、Cursor で実際に使っている 3 つの例を紹介します。

セキュリティレビュー

main へのプッシュごとにセキュリティレビューの自動化がトリガーされます。これにより、PR をブロックすることなく、エージェントがより長い時間をかけて細かな問題を見つけられます。エージェントは diff を監査してセキュリティ脆弱性を探し、PR 内ですでに議論された問題はスキップし、高リスクの検出結果を Slack に投稿します。この自動化によって、Cursor で複数の脆弱性とクリティカルなバグが見つかっています。

エージェント駆動の codeowners

PR の作成やプッシュのたびに、この自動化が影響範囲、複雑さ、インフラへの影響に基づいてリスクを分類します。低リスクな PR は自動承認されます。高リスクな PR には、コントリビューション履歴に基づいて最大 2 名のレビュアーがアサインされます。判断内容は Slack で要約され、MCP 経由で Notion データベースに記録されるため、エージェントの動作を監査し、指示内容を調整できます。

インシデントレスポンス

PagerDuty のインシデントによってこの自動化がトリガーされると、エージェントが起動し、Datadog MCP を使ってログを調査し、コードベースの最近の変更を確認します。そのうえで、対応するモニターメッセージと、提案された修正を含む PR を添えて、オンコールのエンジニア向けに Slack チャンネルへメッセージを送ります。これにより、インシデントレスポンス時間が大幅に短縮されました。

#日常業務

また、自動化は、さまざまなツール間の情報をつなぎ合わせる必要がある、日常的なタスクやナレッジワークにも有用だと分かっています。

変更のウィークリーサマリー

この自動化は、直近 7 日間でリポジトリに加えられた意味のある変更を要約した Slack 用のウィークリーダイジェストを投稿します。エージェントは、主なマージ済み PR、バグ修正、テクニカルデット、セキュリティや依存関係の更新をハイライトします。

テストカバレッジ

毎朝、自動化されたエージェントが直近でマージされたコードをレビューし、テストカバレッジが必要な箇所を特定します。テストを追加する際は既存の規約に従い、必要な場合にのみプロダクションでの挙動を変更します。その後、エージェントは関連するテストターゲットを実行し、PR を作成します。

バグ報告のトリアージ

Slack チャンネルにバグ報告が届くと、この自動化が重複をチェックし、Linear MCP を使って issue を作成します。その後、エージェントがコードベース内で根本原因を調査し、修正を試み、元のスレッドに要約を返信します。

#Rippling におけるオートメーションの活用方法

Cursor 以外のチームでも、すでにオートメーションの構築が始まっています。Rippling の Abhishek Singh は、パーソナルアシスタントを構築しました。彼は一日を通して、ミーティングメモ、アクションアイテム、TODO、Loom のリンクを Slack チャンネルにどんどん投げ込んでいます。cron エージェントが 2 時間ごとに実行され、彼の GitHub の PR、Jira の課題、Slack のメンションとあわせてすべてを読み込み、ソース間の重複を取り除き、整理されたダッシュボードとして投稿します。

また彼は、スレッドから Jira の課題を作成したり、Confluence でディスカッションを要約したりする Slack トリガー型のオートメーションも実行しています。Singh と Rippling は、インシデントのトリアージ、週間ステータスレポート、オンコールの引き継ぎなどのタスクを処理するためにも、オートメーションの活用範囲を広げています。とくに有用なオートメーションはチーム全体で共有されます。

#あなたのソフトウェアを生み出すファクトリー

これらすべての自動化は、自前のコンピュータを使ってビルド・テスト・デモまで行うクラウドエージェントによって動いています。いまや、エージェントを構成してコードベース全体を継続的に監視・改善させることで、あなたのソフトウェアを生み出すファクトリーを構築できます。

cursor.com/automations でオートメーションを作成してみるか、テンプレートから始めてみてください。詳しくはドキュメントをご覧ください。