CursorがTeamsに来た — @メンションだけでPRが届くチーム開発

「あのバグ、Cursorに直してもらって」。

チームのSlackやTeamsでこういう会話は日常的にある。ただ、これまでは誰かがIDEを開き、Cursorを起動し、コードを修正し、PRを作る必要があった。5月11日にリリースされたCursor in Microsoft Teamsは、この流れを丸ごと変える。

Teamsのチャンネルで @Cursor とメンションし、やりたいことを書く。それだけで、クラウドエージェントがリポジトリに対してタスクを実行し、PRを作成してくれる。

どう動くのか

仕組みはシンプルだ。

Teamsのチャンネルやスレッドで @Cursor fix the login bug in my-repo のようにメンションすると、Cursorはプロンプトとスレッドの文脈からどのリポジトリを対象にすべきか、どのモデルを使うべきかを自動判断する。直近のエージェントアクティビティも参照するため、「さっきのやつの続き」のような曖昧な指示にも対応できる。

エージェントはスレッド全体を読み込んでからコードの実装に入り、完了するとPRを作成する。スレッドに返信すればエージェントの方向を修正できるし、追加の作業を指示することもできる。

つまり、IDEを一度も開かずに、チャットの流れの中でコード修正が完了する。

何が変わるか

この統合の本質は「コーディングの民主化」ではない。エンジニアが日常的にコードを書く環境の話だ。

変わるのは、タスクの「起動コスト」だ。これまでは小さなバグ修正や設定変更でも、ローカル環境を立ち上げ、ブランチを切り、変更し、テストし、PRを作る一連の手順が必要だった。Teamsで「これ直して」と書くだけで済むなら、コードレビュー中に見つけた軽微な問題をその場で解決できる。ミーティング中に出た「あの設定、変えておいて」がそのまま実行に移る。

チームリーダーやPMにとっても意味がある。技術的な判断はCursorのエージェントに任せつつ、チャット上で進捗を追い、必要に応じて方向修正できる。「エンジニアの手を止めずにタスクを振る」手段が1つ増えた。

正直な懸念

便利さの裏には注意点もある。

まず、Teamsという開かれた場所でコーディングエージェントを走らせることへのセキュリティ上の考慮が必要だ。リポジトリへのアクセス権限がTeamsのメンション経由で発動する以上、誰がどのリポジトリに対してエージェントを動かせるのか、権限管理は慎重に設計する必要がある。

もう1つは品質だ。IDE上でのCursorなら、エンジニアがリアルタイムで生成されるコードを見ながら修正できる。Teamsからの非同期実行では、PR完成後にはじめて中身を確認することになる。小さなタスクなら問題ないが、複雑な修正を丸投げするにはまだ早いだろう。

同時に発表された「Bugbotのeffortレベル」カスタマイズも興味深い。チーム管理者やIndividualプランのユーザーが、PRレビューの精度レベルを「High」に設定できるようになった。Highモードでは推論に時間をかけ、より深いバグ検出を行う。Teams統合と合わせて、「PRを作るのもレビューするのもAI」という開発フローが現実味を帯びてきた。

IDEを開かない開発の始まり

CursorのTeams統合は、単体で見れば「チャットからPRを作れる」というシンプルな機能だ。だが文脈を広げると、これはIDEの位置づけそのものが変わる兆候に見える。

Roo Codeの開発元が「IDEは未来じゃない」と宣言してVS Code拡張を終了したのが、つい先日のこと。Cursorも自社のクラウドエージェントをIDE外に展開し始めた。GitHub Copilotもモバイルからクラウドエージェントを起動できるようになっている。

コードを書く場所が「IDE」から「どこでも」に移行しつつある。Teamsでの@メンションはその一歩にすぎないが、この方向の不可逆さは感じる。インストールはCursorのダッシュボードから行える。