「思い出したら頼む」をやめる──Cursorの/automateが、エージェントを“仕事の発生場所”に常駐させる

コーディングエージェントの使い方が、また一段変わろうとしています。Cursorは2026年6月18日、自動化機能「Automations」を拡張し、新しいスラッシュコマンド /automate、GitHub・Slack向けの新しいトリガー、そしてクラウドエージェントによる「コンピュータ操作（computer use）」への対応を追加しました。チャットでその都度頼む使い方から、あらかじめ仕事の発生場所にエージェントを待機させておく使い方への移行を後押しする更新です。

会話で自動化を組み立てる

これまで自動化の設定は、トリガー・指示・使うツールを個別に登録する作業でした。/automate は、その手間を会話に置き換えます。ローカルのエージェントセッションでコマンドを呼び出し、やりたいことを普通の言葉で書くだけで、Cursorがトリガー・指示文・必要なツールを組み立ててくれます。「失敗したCIを調べて直す」「PRレビューの指摘を反映する」といった依頼を、その場で常駐タスクに変えられるイメージです。

自動化が起動するのは、手元のPCではなくクラウド上のエージェントです。サンドボックス環境が立ち上がり、設定したモデルとMCP連携に従って作業し、自分の出力を検証します。ノートPCを開きっぱなしにしておく必要はありません。

“仕事が現れる場所”に紐づくトリガー

今回の目玉は、エージェントを起動する入り口が増えたことです。とくにSlackとGitHubの拡充が実務的です。

Slack：絵文字リアクションで起動

任意のSlackメッセージに決めておいた絵文字でリアクションすると、そのメッセージを起点に自動化が走ります。Cursor社内でも、Slackから特定の自動化を直接呼び出すのに使っているとのことです。バグ報告に絵文字を付けるだけで、チケット作成や下書きPRの作成までつなげられます。

GitHub：5種類のイベントを追加

反応できるGitHubイベントが5つ増えました。レビューのやり取りやCIの結果を、人手を挟まずに次の作業へ渡せます。

• PR以外のIssueへのコメント
• プルリクエストのインラインレビューコメント
• レビューの提出（submission）
• レビュースレッドの解決・未解決の切り替え
• GitHub Actionsのワークフロー実行の完了

あわせて、失敗したワークフローのトリアージやPRレビュー指摘の自動修正を行うマーケットプレイス用テンプレートも用意されました。ゼロから組まなくても、典型的な雑務はひな形から始められます。

成果物を“見せる”ところまで自動化する

もう一つの追加が computer use への対応です。自動化から起動したクラウドエージェントが、自分のコンピュータを操作してデモや成果物を作れるようになりました。フロントエンドの変更をスクリーンショットや録画で見せる、といった使い方が想定されており、初期設定で有効になっています。利用者は「作業サンプルを添えて」と指示するだけで済みます。コードを直すだけでなく、レビュー担当者が変化を一目で把握できる材料まで、エージェント側が用意するわけです。

「頼む」から「配線する」へ

Automationsはもともと、Cursorのレビュー機能Bugbotを源流とする仕組みで、スケジュール（cron）やWebhook（Slack・GitHub・Linear・PagerDutyなど）をきっかけに常駐エージェントを動かすものでした。今回の更新でその入り口が広がり、対話的なツールからイベント駆動の働き手へと性格が一段はっきりしました。

外部の解説は、この変化を「思い出したときにエージェントへ頼む」のではなく「すでに仕事が現れている場所にエージェントを配線する」発想だと整理しています。CIの失敗診断、PR指摘の反映、Slackからのバグトリアージ、マージ内容の週次ダイジェスト、画面変更のデモ取得──こうした繰り返し作業を、依頼と確認の往復から背景処理へ移すのが狙いです。

便利さの裏で、注意すべきこと

常駐エージェントは強力ですが、無防備に広げると事故の入り口にもなります。解説記事は「最初の一手は自動化しても、最終判断は人が握る（automate the first pass, not the final authority）」という線引きを勧め、いくつかのリスクを挙げています。煽る話ではなく、運用設計の前提として押さえておきたい点です。

• 権限の広すぎ：無関係なシステムにまで手が届くツール権限を与えてしまう。
• 指示の曖昧さ：プロンプトが漠然としていると、必要以上にコードを書き換える。
• untrustedな入力：Slackメッセージなど外部入力が、隠れた指示（プロンプトインジェクション）として働く恐れ。
• 検証環境の不備：テストを実行できない環境では、エージェントが自分の出力を確かめられない。
• 想定外の課金：トリガーが頻発すると、自動化の起動コストが膨らむ。

記事は、本番デプロイ・データベース移行・課金変更・顧客向けメッセージなどはレビューなしで自動化しないよう促し、「自動化プロンプトは設定の小道具ではなく本番コードとして扱う」ことを通底のメッセージとしています。導入する側は、まず低リスクな雑務（CIトリアージやレビュー指摘の下書き）から配線し、権限とトリガー頻度を絞って始めるのが現実的でしょう。

開発現場への含意

コーディングエージェントは、対話の相手から「現場の配管に組み込む部品」へと位置づけが移りつつあります。/automate のように自然言語で常駐タスクを組める仕組みは、その敷居をさらに下げます。一方で、入り口が増えるほど「誰が・何を・どこまで」自動で動かしてよいかの設計と監督が、品質と安全を左右します。手軽さと統制の両立をどう設計するかが、これからのチームの腕の見せどころになりそうです。

参照: Improvements to Cursor Automations（Cursor 公式チェンジログ, 2026-06-18） ／ Build agents that run automatically（Cursor） ／ Cursor /automate Explained: What the New Automation Skill Means for AI Coding Agents（Kingy AI）