/automate スキルで自然言語からワークフローを生成
Cursor 3.8の核心は、エージェントセッション内で直接使える /automate スキルだ。
「PRレビューコメントを自動修正して」「Slackの特定チャンネルに新規メッセージが来たら要約して返信して」といった自然言語の指示だけで、Cursorがトリガー・インストラクション・ツールの設定を自動的に生成する。
従来のオートメーションツールでは、YAMLファイルを書いたりGUI操作で設定を積み上げたりする必要があった。 だがCursor 3.8では、ローカルのエージェントセッション内でそのままワークフローを定義・実行できる。 設定コストが大幅に下がることで、「自動化できたら良いな」という水準のタスクが現実に自動化される範囲が一気に広がる。
ユーザーはCursorのMarketplaceで他者が作ったAutomationテンプレートを選んで使うことも、自分が作ったものを共有することもできる。 このエコシステムの設計は、AIコーディングツールを「個人の生産性向上ツール」から「チームレベルのオーケストレーションプラットフォーム」へと転換させる意図が見える。
GitHub・Slackの新トリガー5種が追加
今回のリリースでGitHubとSlackのトリガーが大幅に拡充された。 GitHubに新たに追加されたトリガーは5種——Issue comment、PR review comment、PR review submitted、Review thread updated、Workflow run completed——だ。
これらにより、PRが提出されるたびにAIエージェントが自動でコードレビューを実施したり、CIが失敗したときに根本原因を調査して修正案を提示したりするワークフローが構築できる。 特に「Workflow run completed」トリガーは、テストスイートが落ちた瞬間に自動デバッグを始めるエージェントの実現に直結する。
Slack連携では、任意のメッセージに対して指定した絵文字でリアクションするだけでオートメーションを起動できる機能が追加された。 「このメッセージのタスクをJiraに登録して」「このバグ報告を調査してGitHub Issueに起票して」といった作業が、Slackを離れることなく実行できるようになる。
AIが書いたコードへの開発者の不信感が指摘されるなか、CursorはGitHubのPRレビューフローに深く統合することで「エージェントの働きを人間が検証しやすい」設計を目指している。
クラウドエージェントがコンピュータを操作する時代へ
今回の目玉のひとつが、クラウドエージェントによるコンピュータ使用の自動化統合だ。 Automationsによって起動されたクラウドエージェントは、自分専用のコンピュータを持つ形で動作する。 成果物のデモを作る、ドキュメントを生成する、スクリーンショットを撮って検証する、といった作業をエージェントが自律的にこなし、その結果を開発者に報告する。
コンピュータ使用ツールはAutomationsが起動したすべてのエージェントでデフォルト有効となっており、追加設定は不要だ。 これはAnthropicのComputer Useや、Operator系エージェントが切り開いてきた「AIがブラウザ・OSを操作する」パラダイムとCursorが本格的に統合された瞬間と言える。
「コードを書く」だけでなく「実際に動作させて確認する」まで、一連のフローをエージェントが担う。 開発者の役割が「コードを書く人」から「エージェントをレビューする人」へとシフトしていく流れが、Cursor 3.8でさらに加速した。
エンジニア視点で読む「Automation First」の意味
エンジニアの目線でCursor 3.8を見ると、最も重要な変化は「自動化の民主化」だ。
従来、GitHub Actionsや各種CI/CDツールの設定は専門的な知識を要し、インフラエンジニアやDevOpsエンジニアの担当領域だった。
しかし /automate スキルによって、フロントエンドエンジニアでも、データエンジニアでも、「自然言語で要件を伝える」だけで自動化フローを作れるようになる。
GoogleのGemini CLIが廃止されてクローズドソースのAntigravity CLIに置き換えられた出来事は、開発者ツールのオープン性への問いを投げかけた。 CursorはMarketplaceでコミュニティのAutomationを共有できる仕組みを設けており、この点でオープン性を保つ姿勢を見せている。
その先にあるのは、エンジニアが「コードを直接書く」ことより「エージェントへの指示とレビュー」に多くの時間を使うという職能の変容だ。 Cursor 3.8は、その未来を一歩具体化した。
常時稼働エージェントのガバナンス課題
Automationsが本格化すると、必然的に浮上するのがガバナンスの問題だ。 常時稼働のエージェントが誤操作をした場合の責任はどこにあるか。 意図しない変更がマージされた場合の検知・ロールバック機能は十分か。 AIエージェントがSlackやGitHubを自律的に操作することのセキュリティリスクはどう管理するか。
CursorはComputer Useのサンドボックス分離や、コンテナレベルの実行環境を整えることで対応しようとしている。 だが、企業の本番環境での採用が本格化するには、監査ログの充実やRBAC（ロールベースアクセス制御）の整備など、さらなる安全装置が求められるだろう。
AIコーディングツールの信頼ギャップは、単なる「精度」の話ではなく、セキュリティ・コンプライアンス・組織ガバナンスと直結した問いへと進化している。 2026年下半期、「AIエージェントに常時稼働権限を与えること」の意味を組織として問い直す時が来ている。
あなたのチームは、AIエージェントに「常時稼働権限」を与える準備ができているだろうか。
ソース:
