自動化
Cursor Automations は、Cloud Agent をバックグラウンドで実行します。スケジュールに基づく実行のほか、GitHub、GitLab、Slack、Webhook、Linear などからのイベントをトリガーに実行できます。
自動化を使用すると、最近の PR コミットのバグ確認、脆弱性の詳細な確認、Slack でのバグのトリアージ、コードベースの変更の定期的な要約 といったタスクを自動化できます。
はじめに
Agents Window、cursor.com/automations、ローカルエージェントセッションの /automate スキル、または Cursor Marketplace のテンプレートから、新しい自動化を作成できます。
/automate スキルでは、実行したいワークフローを自然言語で説明できます。Cursor が自動化のトリガー、指示、ツールを設定します。
どの方法でも、次の手順に従います。
- 1 時間ごと、またはプルリクエストが作成されたときなど、トリガーを選択します。
- 自動化への指示を含むプロンプトを作成します。
- Slack に送信、プルリクエストにコメントする、MCP のツールなど、エージェントが使用できる任意のツールを選択します。
- 自動化にリポジトリ、複数のリポジトリ、またはリポジトリがまったく不要かを選択します。
- 自動化を保存して有効化します。
自動化ページには、Cursor 管理の次の 3 つのエージェントもあります。
- Bugbot は、プルリクエストのバグとコード品質の問題を確認します。
- セキュリティエージェント は、プルリクエストを確認し、コードベースの脆弱性をスキャンします。
- PR のルーティングと承認 は、プルリクエストをレビュアーに振り分け、低リスクの変更を承認できます。
請求
自動化では Cloud Agent が作成され、Cloud Agent の利用量に応じて請求されます。詳細はCloud Agent の料金を参照してください。
自動化は Cloud Agent として実行されるため、各モデルでサポートされる最大のコンテキストウィンドウを使用します。コンテキストウィンドウを切り替えることはできません。
利用量の請求先は、自動化の権限スコープによって異なります。
- チーム所有: 利用分はチームの利用プールに請求されます。自動化は共有のチームサービスアカウントで実行されるため、個々のユーザーの利用量には影響しません。
- プライベート: 利用分は自動化を作成したユーザーに請求されます。
- チームに表示: 利用分はプライベートと同様に、自動化を作成したユーザーに請求されます。
トリガー
トリガーは、自動化を実行するタイミングを決定します。自動化には複数のトリガーを設定でき、いずれかのトリガーが発火すると実行されます。
Slack や cron スケジュールなどの一部のトリガーでは、Cursor はデフォルトでリポジトリを使用しません。自動化でコードを変更する場合は、エージェントが作業するリポジトリを指定してください。ソース管理トリガーでは、1 つ以上のリポジトリを指定する必要があります。
スケジュールトリガー
スケジュールトリガーは、繰り返し実行されます。プリセットのオプションから選択するか、cron 式を入力して詳細に設定できます。
スケジュールトリガーは遅れて実行される場合がありますが、指定時刻より前に開始されることはありません。
ソース管理トリガー
ソース管理トリガーは、接続済みの Git プロバイダ (GitHub、GitLab、Bitbucket Cloud) で発生するプルリクエストおよびプッシュのイベントに応答します。自動化は、1 つのリポジトリまたはマルチリポジトリ環境に接続できます。
接続済みのすべてのプロバイダで、主要なプルリクエストおよびプッシュトリガーがサポートされています。
- 下書き PR をオープン - 下書きのプルリクエストが作成されたとき。
- プルリクエストをオープン - 下書きでない PR が作成されたとき、または下書き PR が確認可能としてマークされたとき。
- プルリクエストにプッシュ - 既存の PR に新しいコミットがプッシュされたとき。
- プルリクエストをマージ - PR がマージされたとき。
- ブランチにプッシュ - プルリクエスト以外で、特定のブランチにコミットがプッシュされたとき。
- コメントが追加 - プルリクエストにトップレベルのコメントが追加されたとき。
GitHub は最も多くのトリガーをサポートしています。GitLab と Bitbucket は、上記の主要なトリガーに加え、以下の各セクションに記載されている追加のトリガーもサポートしています。
GitHub トリガー
GitHub はリファレンスプロバイダーで、すべてのソース管理トリガーをサポートしています。コアトリガーに加え、以下のトリガーがあります。
- プルリクエストのラベル変更 - 特定のラベルまたは任意のラベルがプルリクエストに追加または削除されたとき。
- Issue のラベル変更 - プルリクエスト以外の Issue にラベルが追加または削除されたとき。
- CI 完了 - GitHub のチェックがプルリクエストまたはブランチで完了したとき。
- Issue コメント - プルリクエスト以外の Issue にコメントが投稿されたとき。
- PR レビューコメント - プルリクエストの diff にインラインコメントが追加されたとき。
- PR レビュー送信 - 承認、変更リクエスト、またはコメントとしてレビューが送信されたとき。
- レビュースレッド更新 - プルリクエストのレビュースレッドが解決済みまたは未解決に設定されたとき。
- ワークフロー実行完了 - GitHub Actions のワークフロー実行がプルリクエストまたはブランチで完了したとき。
Cursor Marketplace には、失敗した GitHub Actions のトリアージやプルリクエストレビューコメントの修正用のテンプレートがあります。
GitLab トリガー
コアトリガーに加えて、GitLab では次のトリガーが追加されます。
- プルリクエストのラベルが変更された - マージリクエストにラベルが追加または削除されたとき。
- プルリクエストが承認された - マージリクエストが承認されたとき。
Bitbucket トリガー
Bitbucket でサポートされているのは Bitbucket Cloud (bitbucket.org) のみです。Bitbucket Server と Data Center はサポートされていません。コアトリガーに加え、以下のトリガーが利用できます。
- プルリクエストが承認された - プルリクエストが承認されたとき。
Bitbucket Cloud では、プルリクエストのラベルやインラインレビューコメントをトリガーにすることはできません。
フォークから作成された PR では、プルリクエストトリガーは実行されません。ブランチがフォークにしか存在せず、リポジトリの権限で外部コードを実行するのは安全ではないため、これらの実行は「Fork pull requests not supported」エラーで失敗します。例外は Pull request merged トリガーです。マージコミットから開始されるため、引き続き実行されます。これを回避するには、ブランチをリポジトリ自体にプッシュし、そこから PR を作成してください。
Slack トリガー
Slack トリガーは、Cursor Slack 連携のイベントに応答します。
現在、Slack トリガーで確認できるのは公開 Slack チャンネルのみです。
- チャンネル内の新規メッセージ - 接続済みの Slack チャンネルにメッセージが送信されたとき。メッセージフィルターを設定しない場合、トリガーが実行されるのはチャンネルのトップレベルメッセージのみです。スレッド内の返信でも実行するには、キーワードまたは正規表現フィルターを追加してください。
- 絵文字リアクション - 誰かが特定の絵文字で Slack メッセージにリアクションしたとき。
- チャンネルの作成 - ワークスペースに新しい公開 Slack チャンネルが作成されたとき。
Webhook トリガー
Webhook トリガーは、自動化用のプライベート HTTP エンドポイントを作成します。このエンドポイントに POST リクエストを送信すると、実行が開始されます。Webhook を使用すると、自動化を内部システム、CI パイプライン、監視ツールなどに接続できます。
Webhook URL を取得するには、まず自動化を保存する必要があります。保存すると、呼び出し用の Webhook URL と認証用の API キーが生成されます。
Linear トリガー
Linear トリガーは、Cursor Linear 連携のイベントに応じて実行されます。
- Issue created - 新しい issue が作成されたとき。
- ステータス変更 - issue のステータスが変更されたとき。
- サイクル終了 - Linear のサイクルが完了したとき。
Sentry トリガー
Sentry トリガーは、Sentry プロジェクトでエラーまたは Issue イベントが発生したときに実行されます。エラーの自動調査、根本原因の特定、修正案の提案に使用できます。すぐに使える例については、マーケットプレイスのテンプレート「Sentry issue の調査」を参照してください。
- Issue created - Sentry で新しい Issue が作成されたとき。
- Issue updated - ステータスや割り当ての更新など、既存の Issue が変更されたとき。
- Any issue event - すべての Issue イベントタイプに一致します。
PagerDuty トリガー
PagerDuty トリガーはインシデントイベントに応じて実行され、インシデントの自動トリアージや解決に役立ちます。
- インシデント発生時 - 新しいインシデントが作成されたとき。
- インシデント確認時 - インシデントが確認されたとき。
- インシデント解決時 - インシデントが解決されたとき。
- すべてのインシデントイベント - すべてのインシデントイベントタイプに一致します。
ツール
Cursor 自動化 では、GitHub、Slack、メモリ、MCP などに関する機能を拡張するツールを有効にできます。自動化 には、他の Cloud Agent と同じ基本ツールセットも含まれています。詳細は Cloud Agent の機能 を参照してください。
プルリクエストの作成
リポジトリに紐づく自動化では、自動化プロンプトで指定されたコード変更を行った後、プルリクエストを作成できます。このツールは、すべての自動化でデフォルトで有効になっています。
プルリクエストは、ソース管理トリガーで指定されたリポジトリに対して作成されます。その他のトリガーでは、環境で指定されたリポジトリが使用されます。
プルリクエストにコメントする
指定したプルリクエストにコメントを投稿します。プルリクエスト全体への確認コメントと、コード内のインラインコメントをサポートします。
承認を有効にすると、エージェントは承認、変更リクエスト、確認の却下も行えます。それ以外の場合は、コメントの投稿のみ可能です。
レビュアーを依頼
対象のプルリクエストのレビュアーを依頼します。エージェントは、git、メモリ、その他のツールを使用して、各分野の専門家を特定できます。
Slack に送信
Slack チャンネルにメッセージを送信します。特定のチャンネルを指定することも、エージェントが任意のチャンネルを動的に選択できるようにすることもできます。
任意のチャンネルを許可すると、Cursor はエージェントが利用可能な公開チャンネルを検出するために必要な読み取り権限も付与します。
エージェントには、メッセージを送信できる公開チャンネルの読み取り権限も付与されます。
Slackチャンネルを読み取る
エージェントが公開Slackチャンネルを一覧表示し、メッセージを読み取れるようにする参照専用アクセスを付与します。
エージェントが返信やプルリクエストの作成前に、より多くのコンテキストを必要とする場合に使用します。
MCP サーバー
エージェントが外部ツールやデータソースを使用できるよう、MCP (Model Context Protocol) サーバーに接続します。
MCP サーバーに接続すると、エージェントはそのサーバーが提供するすべてのツールにアクセスできるようになります。自動化に必要な権限を付与しても問題ない、信頼できるサーバーのみを接続してください。
メモリ
メモリを使用すると、エージェントは同じ自動化の複数の実行にわたって永続的なメモを読み書きできます。これにより、時間の経過とともに記憶し、改善していくエージェントを作れます。各メモリは、エージェントの作業用ファイルシステムの外部にある名前付きエントリ (デフォルトは MEMORIES.md) として保存されます。
メモリはデフォルトで有効ですが、無効にすることもできます。メモリはツール設定 UI から表示・編集できます。
エージェントは、自動化の実行中に古くなったメモリファイルを削除できます。ツール設定 UI からメモリファイルを削除することもできます。
メモリは実行をまたいで保持されるため、自動化で信頼できない入力を処理する場合は慎重に使用してください。入力によって誤解を招くメモリや悪意のあるメモリが作成され、意図せず将来の自動化実行に影響を与える可能性があります。
コンピュータ操作
コンピュータ操作を使うと、自動化によって起動されたCloud Agentが、開発者と同じようにコンピュータを操作できます。つまり、自動化でブラウザを操作したり、スクリーンショットや録画を作成したり、内部サービスを使用したりできます。コンピュータ操作は、すべての自動化でデフォルトで利用できます。
コンピュータ操作を効果的に使用するには、自動化用の開発環境が設定されていることを確認してください。エージェントに作業内容を示させたい場合は、自動化の指示でデモを求めることができます。たとえば、ユーザー向けフローを変更した後に短い画面録画を含めるよう、エージェントに指示します。
自動化の設定
モデル
自動化でCloud Agentが使用するモデルを選択できます。
リポジトリ
自動化でリポジトリを使用しないか、単一のリポジトリを使用するか、マルチリポジトリ環境を使用するかを選択します。
リポジトリの設定は、各実行におけるコードベースのコンテキストを決定します。
- リポジトリなし: エージェントはコードをクローンしません。Slack、MCP、Webhook、Linear、PagerDuty のみを必要とするワークフローに使用します。コードの編集やプルリクエストの作成はできません。
- 単一リポジトリ: エージェントは 1 つのリポジトリとブランチで作業します。自動化で 1 つのコードベース内のコードを読み取り、確認、または変更する場合に使用します。
- マルチリポジトリ環境: エージェントは環境内の複数のリポジトリにまたがって作業します。タスクが複数のコードベースにまたがる場合に使用します。
Slack や cron スケジュールなど、一部のトリガーでは、Cursor はデフォルトでリポジトリを使用しません。自動化でコードを変更する場合は、エージェントが作業するリポジトリを指定してください。
ソース管理トリガーでは、リポジトリまたは複数のリポジトリの指定が必須です。
単一リポジトリの自動化
デフォルトでは、自動化は1つのリポジトリとブランチに対して実行されます。エージェントが単一のコードベース内のコードを読み取り、確認、または変更する場合に適しています。
ソース管理トリガーでは、プルリクエストからリポジトリが特定されます。その他のトリガーでは、自動化の設定でリポジトリとブランチを選択します。
マルチリポジトリ自動化
自動化で複数のリポジトリにまたがって作業する必要がある場合は、マルチリポジトリ環境を使用します。環境の設定時に複数のリポジトリを選択するか、Cloud Agents ダッシュボードで既存の環境を選択します。
権限
自動化を閲覧・管理できるユーザーを設定します。権限スコープによって、利用料金の請求先も決まります。
- プライベート: 自動化を管理できるのは自分だけです。チーム管理者は自動化の閲覧と無効化ができます。
- チームに表示: 自動化を管理できるのは自分だけです。チームメンバーは自動化を閲覧でき、チーム管理者は無効化できます。実行には引き続き自分の認証情報が使用されます。
- チーム所有: チームメンバーは自動化を閲覧できます。自動化を管理できるのはチーム管理者のみです。チームの共有自動化サービスアカウントで実行されます。
自動化をプライベートまたはチームに表示からチーム所有に昇格すると、実行時に使用するIDが変わります。自分の認証情報は使用されなくなり、チームの共有自動化サービスアカウントが使用されます。自動化でWebhookトリガーを使用している場合は、スコープの変更後にWebhook APIキーを再生成してください。個人のOAuth認証情報に依存するMCPやその他の連携を使用している場合は、代わりにチームのサービスアカウント用に設定されていることを確認してください。自動化をチーム所有に昇格できるのはチーム管理者のみです。
ID
自動化が外部サービスでアクションを実行する際は、以下のIDを使用します。
- GitHubのコメント、レビューの承認、レビュアーのリクエストは、
cursorとして実行されます。 - チームスコープの自動化は、
cursorとしてプルリクエストを作成します。 - プライベート自動化は、あなたのGitHubアカウントとしてプルリクエストを作成します。
- Slackメッセージは、Cursor bot として送信されます。
プロンプトの作成
プロンプトは、エージェントに実行させる内容を定義します。Cloud Agent の実行に指示を出す場合と同じように記述してください。
ヒント:
- エージェントに確認、変更、生成させる内容を具体的に指定します。
- 有効にしたアクションを参照します。ツールは @メンションするか、名前で言及できます。
- ケースごとに取るべき対応の判断ルールを含めます。
- エージェントがプルリクエストを作成する、コメントする、または何もしない基準を設定します。
- 必要な出力形式を記述します。