「頼んで待つ」の前に段取りが返ってくる──CursorがSlack常駐エージェントに足した、計画・複数リポ・チャンネル横断の3手綱

コーディングエージェントを「専用アプリやIDEの中で動かすもの」から「チームが普段いるチャットに常駐させるもの」へ広げる動きが続いています。Cursorは7月17日、Slack連携「Cursor in Slack」を更新し、依頼への着手前に作業計画を返す挙動と、複数リポジトリをまたぐ環境、他チャンネル・スレッドの読み書きという3点を加えました。いずれも派手な新モデルの話ではなく、チャット越しに仕事を任せるときの「取り回し」を詰める改良です。

着手前に計画を見せ、途中で向きを変えられる

これまでの「頼む→しばらく待つ→出てきた結果を見て直す」という流れは、方向性がずれていたときの手戻りが大きくなりがちでした。今回の更新では、Cursorが実装に入る前にまず計画を提示します。公式の説明でも「着手前に計画を返すので、早い段階で割り込んで軌道修正できる」とされ、作業中も各ステップの状況を更新しながら進みます。UIも整理され、表やプルリクエスト、生成物へのリンクはメッセージ内のボタンではなく、コンパクトなフッターのリンクにまとめられました。

ポイントは、レビューのタイミングが「完成後」から「着手前」に前倒しされることです。人が判断を差し込む場所が早まるほど、無駄に生成されるコードは減ります。

加わった3つの改良

「フロントとバックが別リポ」の現場で効く

3点のなかで実務に直結しやすいのは複数リポ環境です。フロントエンド・バックエンド・共有コードがそれぞれ別リポジトリに分かれている構成は珍しくありません。Cursorは依頼文を読み、それらすべてにアクセスできる環境を選んで動くとされます。1つの機能追加がリポをまたぐとき、これまで人が環境を切り替えたり複数の依頼に分けたりしていた手間を、チャット上の1つのやり取りに畳み込める可能性があります。

ビジネス面では、開発の入り口が「IDEを開く」から「Slackで話しかける」に寄ることの意味が大きいと言えます。エンジニア以外のメンバーも要望をスレッドに書きやすくなり、計画の提示によって「何をやろうとしているか」がチャット上で可視化されます。作業の起点が、専用ツールではなくチームの会話の場に移っていく流れです。

読み書きの範囲が広がることの裏側

一方で、エージェントが複数チャンネルやスレッドを横断して読み書きできるということは、それだけアクセスできる情報と発言の範囲が広がるということでもあります。自動で動く相手に対して「どのチャンネルまで見せ、どこへ書き込ませるか」を曖昧にしたまま常駐させると、意図しない情報の参照や誤った投稿につながりかねない、という懸念も一般には指摘されます。導入時には、対象チャンネルや権限を最小限に絞り、着手前プランの段階で人が確認する運用を組み合わせるのが無難でしょう。利便性と、任せる範囲の線引きはセットで考える論点です。

チャットに常駐するコーディングエージェントという形は、Cursorに限らず各社が競って詰めている領域です。今回の更新は新機能というより既存の使い勝手を締める性格が強く、「チャット越しに任せる開発」がどこまで実用の水準に近づいているかを測る材料と言えます。

参照: Improvements to Cursor in Slack（Cursor Changelog） ／ Cursor Changelog ／ Slack | Cursor Docs ／ Cursor Release Notes（Releasebot）