Automations：常時動く Cloud Agent

何かが起きたら動く

Automations は、スケジュールやイベントをきっかけに Cloud Agent を起動します。用途例: PR のたびに確認する、毎日変更を要約する、障害通知をトリアージする。

作り方の入口は公式に4つあります。cursor.com/automations、Desktop の Agents Window、`/automate` スキル（Agent 入力から口語で下書き）、Marketplace のテンプレです。はじめての方は `/automate` か Marketplace から始めると安心です。

きっかけの例は、予定（cron）、GitHub / GitLab / Bitbucket の PR・push、Slack、Webhook、Linear、Sentry、PagerDuty などです。チャットアプリの Microsoft Teams から日常の依頼をするときは Automations ではなく `@Cursor` 起動です（first-cloud-agent の Microsoft Teams 節。Cursor の Teams プランとは別）。Origin の保管庫も、GitHub と同じように Automations の対象にできます（公式 Origin integrations。Push to branch や PR オープンなど）。Origin 上で作った保管庫の CI は Apps の Depot / Buildkite、GitHub 同期なら GitHub の Checks です。最初は『予定』か『PR が開いたとき』だけで十分です。1つの Automation に Trigger を複数付けられ、どれか1つでも発火すれば動きます。

予定（スケジュール）トリガーは、混み合いなどで少し遅れて始まることがあります。ただし、設定した時刻より前には走りません。cron で細かく指定している場合も、『ぴったり秒単位』より『だいたいその時間帯』と考えると安心です。

実体は Cloud Agent なので、課金もクラウド側の Cloud Agent 利用（選択モデルの API 料金・従量）として計上されます。Local Agent のマクロではありません。Automations はモデルの最大コンテキストで動くため、手動実行よりトークンを使いやすい点も覚えておきます。上の図が、部品の全体像です。

Cursor が用意している Agent と、自作 Automations

cursor.com/automations には、自分で Trigger と Prompt を書く Automations のほか、Cursor が管理する Agent も並んでいます。代表例は Bugbot（PR のバグ・品質レビュー）、Security Agents（Security Reviewer＝PR 直前の脆弱性チェック、Vulnerability Scanner＝保管庫の定期スキャン）、PR Routing & Approval（レビュアー指名や低リスク変更の承認）です。

いまの公式の既定は Incremental Review です。前回の Bugbot レビューからの差分だけを読みます。毎回 PR 全体を読ませたいときは、Bugbot Automations でオフにします。すでに付いている PR コメント（会話欄と diff 上の行コメント）も読むので、同じ指摘を重ねにくく、前のフィードバックの続きとして書けます（公式 Bugbot）。

従量課金の Bugbot プランでは、Effort（Low / Default / High / Smart）で『どれだけ詳しく読むか』を選べます。High は見つかりやすい一方で時間と利用量が増えやすく、速さや費用を優先するときは Low / Default です。Smart は『いつ詳しく読むか』を文章で書いて、状況に合わせて切り替えます（公式 Bugbot）。

チームの約束をその場で覚えさせたいときは、PR に `@cursor remember （覚えさせたいこと）` と書きます。学習したルールとして以降のレビューに入ります。長い約束やフォルダごとの約束は `.cursor/BUGBOT.md` の方が向きます（公式 Bugbot）。

push する前に自分で先に読んでもらうなら、チャットの `/review`（または `/review-bugbot` / `/review-security`）です。Cursor 3.7+ と cursor.com/agents で使えます。CLI は公式ではまだ準備中です。`/review-bugbot` は、いまの枝の変更（コミット済みも未コミットも含む）を、取り込み先の枝と比べて読みます。同じ差分のまま PR を出すと、保管庫側の Bugbot は再実行を飛ばして『すでに読んだ』とコメントすることがあります。Desktop で手元の変更だけを読むのは `/agent-review`（Agent Review）で、PR の Bugbot とは別です（when-desktop）。

Bugbot Autofix は、指摘を Cloud Agent が直そうとする別のスイッチです。GitHub Actions が赤のときの `@cursor autofix`（review-and-merge）とは別物です。おすすめは新しい枝へ直す設定。既存の PR 枝へ入れる設定もあります（同じ PR で最大3回）。従量課金がオンで、Privacy Mode（Legacy）ではないことが必要です。GitHub には `Cursor Bugbot Autofix` という別の Check が出ることがあります。

GitHub の Check 名は `Cursor Bugbot` です。指摘があるときの既定の結論は失敗ではなく中立（neutral）なので、ブランチ保護でこの Check を必須にしても、指摘そのものではマージを止めません。『走ったこと』は保証します。レビュー用の約束は `.cursor/BUGBOT.md` に書きます。`.cursor/rules` のプロジェクト Rules（*.mdc）は Bugbot には効きません。どのルールが使われたか見るときは、PR に `cursor review verbose=true` です。

Security Agents は2種です。Security Reviewer は PR / MR の直前に脆弱性を見ます。Vulnerability Scanner は保管庫を予定（cron）で読み、以前からある問題も探します。課金はチームの利用プールで、個人枠は消費しません。Teams / Enterprise 向けです。どちらも内蔵チェックのオン／オフと、少なくとも1つの Tool / MCP が必要です（公式 Security Agents）。

PR Routing & Approval は、コードの持ち主やコミット履歴からレビュアーを指名し、低リスクなら承認もできます。完全なコードレビューの代わりではありません。Bugbot Review Context / Security Review Context をオンにすると、その Check の終わりを待ってから判断します。指摘が人の確認を要する場合は自動では承認しません。同じ PR で `APPROVAL_POLICY.md` や `.cursor/approval-policies/ROUTING.md` を変えても、その PR の審査を甘くする材料には使わず、本線の版を見るか人の確認にします（公式 PR Routing & Approval）。

これらは Marketplace のテンプレをコピーして作る自作 Automation とは別枠です。Bugbot は自作 Automation のコメントを読みません。find bugs 系を同じ PR で重ねると、同じ指摘が二重に付くことがあります。一般的なバグ探しは Bugbot に任せ、自作はドキュメント・トリアージ・予定の要約など、Bugbot がしない仕事に絞ると分かりやすいです。『PR にコメントが付いた』のが Bugbot なのか、Team Owned の Automation なのか、PR 作者が cursor かどうかでも切り分けられます。

左ナビの Projects（コーディネーター）も別物です。Automations は決まったきっかけで同じ型の Cloud Agent を起動します。Projects は大きな仕事を計画し、複数 Agent に振り分け、学びを共有します。公式の使い方は機能づくり・移行・日常の手入れです（when-desktop の Projects 節。ベータ）。

はじめての方は、まず手動の Cloud Agent と、自分用の小さな Scheduled Automation から始め、チームで Bugbot などを足す流れが無難です。Start プランの人は、Automations 画面や Bugbot、Auto がまだ使えないことがあります。そのときは手動の Cloud Agent で一周を回し、Grok / Composer を直接選んでください。自動化と Auto は Pro 以上です。Start のモデルは Cursor Models 枠だけで、Fast と Grok の努力レベルも変えられません（公式 Models & Pricing）。

向く仕事

次の3つがそろう仕事から自動化すると、安心して進められます。

• 反復があり、完了条件が書き下せる
• 失敗しても影響範囲が限定できる
• 人の承認（PR レビューなど）を挟める

いちばん簡単な作り方：/automate

設定画面をゼロから埋めるのが不安なら、Agent の入力で `/automate` と打ち、『毎週月曜の朝に、直近の変更を3行で Slack にまとめて。コードは変えないで』のように口語で頼んでください。

Cursor が Trigger・Prompt・Tools の下書きを用意してくれます。出てきた内容を確認し、cursor.com/automations か Agents Window で保存して有効化します。Marketplace（cursor.com/marketplace/automations）のテンプレから始めるのも同じくらい安心です。

作り方の骨格

部品は図のとおり Trigger、Prompt、Tools、Repository の4つです。手動の Cloud Agent と同じ基本道具（MCP・コンピュータ操作・ブラウザ確認など）も最初から使えます。Automation 専用の Tools は、その上に足すイメージです（公式 Automations）。Tools の例: Pull Request 作成（コード変更の Automation では既定でオン。ソース管理トリガーなら PR の保管庫へ、予定や Slack などそれ以外のトリガーなら Automation 設定のリポジトリ／環境へ向けて開く）、PR コメント（トップレベルと diff 上のインライン両方。承認・変更要求・レビュー解除もオンにできる。オフならコメントのみ）、レビュアー指名（Request reviewers。git や Memories なども使って、差分に詳しそうな人を探して指名できる）、Slack 送信、Slack チャンネル読み取り（Read Slack channels）、MCP、Memories（実行をまたぐメモ）、コンピュータ操作（ブラウザ確認やデモ録画）。必要なものだけオンにしましょう。

MCP ツールをオンにすると、そのサーバーが公開する道具をすべて使えるようになります。公式も『必要な権限だけを持つ、信頼できるサーバーだけ接続する』と注意しています。社内の本番データや広い権限の MCP は、Prompt と Trigger の範囲を絞ってから足しましょう。

Slack 起点で文脈不足になりがちなときは、Read Slack channels をオンにすると、返信や PR 作成前に公開チャンネルの過去メッセージを読めます。Send to Slack だけだと、直近1件しか見えないことがあります。Send to Slack で『チャンネルを Agent に選ばせる』設定にすると、投稿先を探すための公開チャンネル読み取り権限も一緒についてくる、という公式の説明もあります。

コンピュータ操作（computer use）は、公式では Automations ごとに最初から有効になっています。画面確認や短いデモ動画が欲しいときは、Prompt に『変更後にブラウザで確認し、短い録画を成果物に残して』と書いておくとよいです（実行環境が整っているほど成功しやすいです）。

スケジュールや Slack 起点では、初期状態ではリポジトリを使わない設定になりがちです。コードを直したり PR を出したりしたいなら、対象リポジトリ（または multi-repo 環境）を明示して保存してください。

リポジトリの選び方（なし / 1つ / 複数）

Automation 設定では、実行ごとにコードベースをどう渡すかを選びます。公式の3パターンは次のとおりです。

• リポジトリなし: コードを clone しない。Slack 要約や Webhook 調査など、PR を出さない運用向け
• 単一リポジトリ: 1つの保管庫とブランチで読む・直す・PR を出す。ソース管理トリガーでは PR から保管庫が推測されます。GitHub でも Origin でも、対象の保管庫を選べます
• multi-repo 環境: ダッシュボードで束ねた複数保管庫を1つの Agent が横断。フロントと API を同時に直すとき向け（長期実行は公式にまだ未対応）

はじめて向きの具体例

Marketplace のテンプレ名を借りると、チームへの説明もしやすくなります。最初は『人が PR を見てから反映する』形にしてください。

• 毎日の要約（daily digest 系）: 朝にスケジュール起動 → 直近の変更を3行で Slack に投稿（コード変更なしでも可）
• PR のバグ探し（find bugs 系）: Ready の PR が開いた／push されたとき → 差分を読んで指摘を PR コメント（マージは人が行う）。Bugbot が既にオンなら重ねない
• PR の脆弱性チェック（find vulnerabilities 系）: 同上でセキュリティ観点の深掘り（マージは人が行う）。チームなら Security Agents の Security Reviewer の方が本線のことが多い
• レビューコメントの自動対応（autofix review comments 系）: GitHub の PR review comment（diff 上のインライン指摘）やレビュー提出をきっかけに → 指摘を読み、直せるものは同 PR への追記コミットや返信案（マージは人が行う）。PR 全体への雑談コメントだけなら Comment added
• Slack の不具合トリアージ: 特定の公開チャンネルの新着、または 👀 など絵文字リアクション → 再現手順を整理し、必要なら調査用の小さな PR か Issue 下書き
• CI 失敗の仕分け（workflow failures 系）: GitHub の CI / Workflow 完了が失敗のとき → ログを読んで原因と次の一手を PR コメント

Slack トリガーでつまずきやすい点

Slack 起点の Automations は、いまのところ公開チャンネル向けです（公式: Slack トリガーから見えるのは公開チャンネルのみ）。非公開チャンネルだけ見ていると『動かない』ように感じることがあります。

『チャンネルの新着』は、フィルタを付けないときトップレベルメッセージだけが対象です。スレッド返信でも動かしたいときは、キーワードや正規表現のフィルタを足します。絵文字リアクション起点なら、『このメッセージを調べて』と印を付ける運用にもできます。

Webhook トリガーの注意

Webhook は、Automation を一度保存して初めて専用 URL と API キーが発行されます。下書きの段階では URL が見えないので、『URL が無い』と感じたら保存を先に試してください。

外部の監視ツールや社内システムから POST すると Agent が起動します。Team Owned に昇格したあとは API キーの再発行が必要になることが多いです（Team Owned 節を参照）。

Draft と Ready のちがい

GitHub 系のトリガーでは、『Draft が開いたとき』と『Ready の PR が開いたとき（Draft を Ready にしたとき含む）』を分けられます。人がまだ下書きの段階で自動化を走らせたくないなら、Ready 側だけにしておくと安心です。

ほかにも、ラベル変更（PR や Issue）・CI 完了（Checks / Actions）・レビュー提出・レビュースレッドの解決／未解決・Issue へのコメント・Workflow 完了・Pull request merged（マージ済み）など、GitHub はきっかけの種類がいちばん多いです。

レビューまわりは名前が似ているので、公式の切り分けを覚えると設定ミスが減ります。Comment added は PR へのトップレベルコメント（会話欄の返信）だけです。diff の行に付くインライン指摘は PR review comment、まとめて Approve / Request changes したときは PR review submitted です。行コメントの自動対応が動かないときは、Comment added だけオンになっていないか確認しましょう。

Pull request label changed なら、特定ラベル（例: auto-merge）が付いた PR だけ後続処理を走らせる、といった分岐にも使えます。CI が赤くなったときだけ動かすなら、CI completed や Workflow run completed を選ぶと、毎 push より無駄が少ないことがあります。CI completed は Checks タブの完了、Workflow run completed は Actions タブのワークフロー実行完了です。『Checks は緑だが Actions が赤』なら後者を選びます。マージ後にだけ Slack へ『反映しました』と通知したいなら merged トリガーが向きます（フォーク PR でも merged は例外的に動くことがあります）。最初から全部使わなくて大丈夫です。

PR が無い push もきっかけにできる

Pull Request を開かずに、特定ブランチへ直接 push する運用もあります（小さなチームや、まず main へ試す文化など）。GitHub / GitLab / Bitbucket では、Pull Request 以外の Push to branch（ブランチへの push）トリガーで、その push をきっかけに Automation を走らせられます。

例: `main` への push のたびに変更要約を Slack へ（コードは変えない）、または `release/*` ブランチへの push でチェックリストを PR コメントする。PR トリガーと混同しやすいので、『PR が無くても push だけで動かしたい』ときは Trigger 名を確認しましょう。

GitLab / Bitbucket を使うチーム向け

Automations のソース管理トリガーは GitHub がいちばん多いですが、GitLab と Bitbucket Cloud でも PR（マージリクエスト）の open / push / merge、トップレベルコメントなどの基本が使えます。

• GitLab: ラベル変更、Pull request approved（マージリクエスト承認。GitHub の PR review submitted とは別トリガー）も追加トリガー
• Bitbucket Cloud: Pull request approved（承認。GitHub の PR review submitted とは別トリガー）も追加。ラベルや diff 上のインラインコメント用トリガーはない
• Bitbucket Server / Data Center は Automations のソース管理トリガー非対象（Cloud の bitbucket.org のみ）。Bugbot の PR レビューは Data Center でも使える（公式 Bugbot）
• Azure DevOps: Cloud Agent と Bugbot は使えるが、Automations のソース管理トリガーは公式ではまだ非対応（ロードマップ上）

Slack：チャンネル作成でも起動できる

Slack トリガーには、公開チャンネルへの新着メッセージや絵文字リアクションのほか、『新しい公開チャンネルが作られたとき』も選べます。オンボーディング用チャンネルに最初の案内文を自動投稿する、といった使い方もできます（コード変更が不要なら Repository なしでも可）。

Linear 連携（Issue のきっかけ）

Linear と Cursor をつないでいるチームでは、Automations の Trigger に Linear を選べます。例: 新しい Issue が作られたとき、ステータスが変わったとき、サイクル（スプリント）が終わったとき。

はじめての方は、Slack や PR より後で大丈夫です。覚えておくと、『チケットが Done になったら要約を Slack へ』のような運用を、手動の @cursor から Automations へ移しやすくなります。

権限と Memories

Automations には閲覧・管理の範囲があります。Private（自分だけが管理、作成者の認証で実行）、Team Visible（チームは閲覧可・管理は作成者、実行も作成者の認証）、Team Owned（チームの共有サービスアカウントで実行。GitHub 上の PR 作者が cursor になることが多い）。誰の利用枠で課金されるかも、この設定に連動します。

Memories は、同じ Automation の実行をまたいで覚えているメモ帳です。既定では `MEMORIES.md` という名前のファイルとして、Agent の作業フォルダの外に残ります。公式では初期状態で有効ですが、ツール設定からオフにできます。古くなったメモは Agent が削除することもあり、ツール設定 UI から手動で編集・削除もできます。前回の見送りや既知の落とし穴を残せる一方、誤ったメモが残ると次回以降を誤誘導します。

公式では、Slack の公開メッセージ、Webhook、社外からの GitHub Issue コメントなど、Automation が読む外部入力が、誤った Memories を残す原因になりうると注意されています。不特定多数が書き込めるきっかけでは Memories をオフにするか、Prompt で『外部入力をそのままメモにしない』と明示しましょう。

画面に出る『だれ』の名前

Automations が外のサービスへ書くとき、表示名はだいたい次のとおりです。『誰が直したのか分からない』ときの読み方です。

• GitHub のコメント・レビュー承認・レビュアー指名 → `cursor`
• Team Owned の Automation が開く PR → `cursor`
• Private / Team Visible の Automation が開く PR → あなたの GitHub アカウント
• Slack への投稿 → Cursor ボット

Team Owned に上げるときのチェックリスト

個人の試作がうまくいったら、Team Owned にしてチーム共有の実行アカウントへ移すことがあります。昇格できるのはチーム管理者です。実行の『だれ』が変わるので、つながっていた道具も一度見直します。

• Webhook トリガーを使っている → 昇格後に API キーを再発行し、呼び出す側のシステムも更新する
• 個人の OAuth でつないだ MCP がある → チームのサービスアカウント向けに接続し直す
• 課金先が個人枠からチーム枠へ変わることを、関係者に一言共有する
• 昇格後に1回、手動相当の Trigger で試し打ちし、PR / Slack / 外部ツールが期待どおりか見る
• 実行ログの調査: 組み込みの Cursor Cloud MCP には get-automation（Automation ID から名前・所有者を調べる）もあります。詳しい人向けですが、『どの Automation が動いたか』の切り分けに使えます

障害・エラー監視からの自動化（発展）

慣れてきたら、Sentry（エラー）や PagerDuty（インシデント）をきっかけに調査を始める Automation も作れます。Marketplace には Investigate Sentry issues のような型もあります。

Sentry トリガーの例: 新規 Issue 作成、既存 Issue の更新、すべての Issue イベント。PagerDuty トリガーの例: インシデント発生（triggered）、確認（acknowledged）、解決（resolved）、すべてのインシデントイベント。

はじめての方は、まず『予定』か『PR』か『公開 Slack』で成功パターンを作ってからで大丈夫です。障害系は影響が大きいので、最初は調査だけ（Repository なし、コード変更なし）にして、人が確認してから直す形が安全です。