「自動化したいけれど、トリガーやツールの設定が面倒」——開発現場では、この壁がエージェント活用の足かせになっていました。Cursorは2026年6月18日のバージョン3.8で、自然言語だけで自動化ワークフローを組み立てる「/automate」スキルを追加しました。アイデアを一文で伝えるだけで、トリガー・指示・ツールが自動設定されます。
この記事でわかること
- /automateスキルで何が変わったか
- 対応トリガーと利用できるツールの範囲
- 実際の使い方と料金の考え方
- 手動設定との違いと注意点
何が変わったか
Cursor Automationsは、クラウド上で常時稼働するエージェントを動かす機能です。スケジュール実行やGitHub・Slackなどのイベントをきっかけに、コードレビューやバグ調査、週次レポート作成といった反復作業を自動化します。
これまで自動化を作るには、トリガーの選択、プロンプトの記述、ツールの有効化を手作業で行う必要がありました。3.8で追加された/automateスキルは、この組み立て工程を省略します。ローカルのエージェントセッションで/automateと入力し、やりたいことを自然言語で書くだけで、Cursorがトリガー・指示・ツール一式を提案します。
Cursor公式のチェンジログでは「常駐エージェントによる反復タスクの自動化を時間短縮する」と位置づけられています。6月19日にはCursor公式Xアカウントでも「アイデアと稼働するワークフローの間が一文になった」と紹介され、開発者コミュニティで注目を集めました。
なぜ今この機能が必要か
コーディングエージェントの普及で、コードの生産速度は上がりました。一方、レビュー・監視・保守の処理能力は同じペースでは伸びていません。Cursor公式ブログでも、エンジニア一人あたりのコード量は増えたが、レビューやメンテナンスは追いついていないと指摘されています。
Automationsはこのギャップを埋める設計です。起動するとクラウドサンドボックス上でエージェントが動き、設定したMCPやモデルに従って作業し、出力を自己検証します。メモリツールで過去の実行結果を記憶し、繰り返しのたびに精度を上げることもできます。
/automateは、この仕組みへの入口を下げる更新です。トリガーの種類やMCP連携を熟知していなくても、まず動く自動化のたたき台を作れるようになりました。
主な変更点
自然言語での自動設定
/automateの核心は、設定画面の各項目を人間が埋める手間を減らす点です。例えば「PRが開かれたらセキュリティレビューをしてSlackに報告して」と書けば、GitHubのPRオープントリガー、レビュー用プロンプト、Slack送信ツールが組み合わされます。
自動化の作成方法は3通りあります。Agents Window、Webのcursor.com/automations、ローカルセッションの/automateです。Cursor Marketplaceのテンプレートから始める選択肢もあります。
新トリガーとComputer Use
3.8ではGitHub向けに5種類のトリガーが追加されました。Issueコメント、PRレビューコメント、PRレビュー提出、レビュースレッドの解決/未解決、GitHub Actionsのワークフロー完了です。CI失敗時に修正PRを自動作成する、といったフローが組みやすくなります。
Slackでは、指定した絵文字リアクションで自動化を起動できるトリガーが新設されました。Cursor社内でもSlack上から特定の自動化を起動する用途で使われています。
さらにComputer Useが全自動化でデフォルト有効になりました。クラウドエージェントがブラウザ操作やスクリーンショット取得を行い、作業結果のデモや成果物を残せます。指示文に「変更後の画面録画を添付して」と書くだけで利用できます。
その他の改善
未完成の状態でも自動化を保存できるようになり、MCP認証の設定中に作業を中断しても進捗が失われません。PR作成ツールはデフォルトで有効化され、UI上で毎回指定する必要がなくなりました。メモリファイルの削除もUIまたはプロンプトから行えます。
使い方
https://cursor.com/automations
最新版のCursorをインストールしたうえで、ローカルのエージェントセッションに/automateと入力します。自動化したいタスクを日本語または英語で具体的に書きます。生成された設定を確認し、必要ならトリガーやツールを微調整して保存・有効化します。
手動で作る場合の流れは次のとおりです。
- トリガーを選ぶ（毎時実行、PRオープン、Slackメッセージなど）
- エージェントへの指示プロンプトを書く
- 使わせるツールを選ぶ（Slack送信、PRコメント、MCPなど）
- リポジトリの要否を決める（なし・単一・複数）
- 保存して有効化する
リポジトリ設定には3パターンがあります。コードを触らないSlack通知だけなら「リポジトリなし」、単一コードベースの修正なら「単一リポジトリ」、複数リポジトリをまたぐ作業なら「マルチリポジトリ環境」を選びます。GitHubやGitLabトリガーではリポジトリ指定が必須です。
対応トリガーとツール
トリガーはスケジュール、GitHub/GitLab、Slack、Webhook、Linear、PagerDuty、Sentryに対応しています。複数トリガーを1つの自動化に設定でき、いずれかが発火すれば実行されます。
ツール面では、PR作成・PRコメント・レビュアー指定、Slack送受信、MCPサーバー連携、メモリ（MEMORIES.md）が用意されています。MCPを接続すると、そのサーバーが公開する全ツールにエージェントがアクセスできるため、信頼できるサーバーだけを選ぶ必要があります。
Cursor社内の活用例として、mainへのpush時セキュリティレビュー、PRのリスク分類と自動承認、PagerDutyインシデント時のログ調査と修正PR作成が公式ブログで紹介されています。Ripplingのエンジニアは、Slackに投げたメモやGitHub PRを2時間ごとに整理する個人アシスタント自動化を構築したと報告されています。
料金と既存機能との違い
Automationsはクラウドエージェントの利用量に応じて課金されます。常にMax Modeで動作するため、オフにする設定はありません。作成者の権限スコープによって請求先が変わり、Team Ownedはチームの利用プール、Privateは作成者個人に計上されます。
ローカルエージェントとの違いは「常時待機してイベント駆動で動く」点です。IDEを開いていなくても、PRのマージやSlackメッセージをきっかけにクラウド上で作業が走ります。BugbotもPRオープン時に動く自動化の一種であり、Cursorでは1日数千回トリガーされ、数百万件のバグを検出してきたとされています。Automationsはこの仕組みをカスタマイズ可能にした拡張です。
手動設定との違いは設定速度です。/automateは初回のたたき台を秒単位で用意し、細部は人間が調整するハイブリッド運用が現実的です。一方、メモリ機能は信頼できない入力を処理する自動化では悪意ある記憶が将来の実行に影響するリスクがあるため、公式ドキュメントでも注意喚起されています。
始めるときのポイント
まずは負荷の小さいタスクから試すのが安全です。週次の変更サマリーをSlackに投稿する、といった読み取り中心の自動化なら、本番コードへの影響が限定的です。CI失敗の自動修正やインシデント対応のように書き込みを伴うフローは、PRの品質基準や承認ルールをプロンプトに明記してください。
Cursor 3.8へのアップデートと/automateの登場で、エージェント自動化の設定コストは大きく下がりました。開発パイプラインのレビュー・監視・雑務をクラウドエージェントに任せる入口が、一文の指示で開かれた——その変化が今回のリリースの本質です。