CursorがTeamsに現れた — @メンション1つでPRが飛んでくる世界

5月11日、CursorがMicrosoft Teamsとの連携を発表した。

やることはシンプルだ。Teamsの任意のチャンネルで @Cursor とメンションし、やりたいことを自然言語で伝える。するとCursorのクラウドエージェントがリポジトリを読み込み、スレッドの文脈を汲み取り、コードを書いて、PRを作成する。

IDEを開く必要がない。コードを読む必要すらない。

何ができるのか

Teams連携で動くのは、Cursorのフルスペックなクラウドエージェントだ。コードベースのインデックス、MCPサーバー、スキル、フック、サブエージェント — デスクトップアプリ版と同じ機能がバックエンドで動く。

メンションされたエージェントは、プロンプトの内容と直近のアクティビティからリポジトリとモデルを自動で選択する。ユーザーが「どのリポジトリの」「どのブランチで」と指定する必要がない。スレッド内の会話も読み取って文脈に含めるため、「さっき話してたあの機能」のような曖昧な指示にも対応できる。

処理が終わると、PRが生成される。あとはチームでレビューすればいい。

これはSDKやSelf-hostedとは全く別の話

4月末に出たCursor SDKは、開発者がCursorのエージェントランタイムをプログラムから呼び出すためのもの。3月のSelf-hosted Cloud Agentsは、コードを社外に出さない企業のためのもの。

Teams連携がターゲットにしているのは、もっと手前の層だ。PMがバグ報告のスレッドで「@Cursor このスタイル崩れ、修正PR出して」と書く。デザイナーがモックアップを共有したスレッドで「@Cursor この通りに実装して」と頼む。そういう世界。

エンジニアリングの知識がゼロでも、チャットさえ打てれば、コードに対するアクションを起こせるようになった。

5月の他のアップデートも見逃せない

Teams連携と前後して、Cursorは5月前半に大量のアップデートを出している。

PR Reviewの全面刷新（5月7日）。Reviews・Commits・Changesの3タブ構成になり、ファイルツリーで大きなPRをナビゲートできるようになった。PR作成からマージまでエディタ内で完結する。

Build in Parallel（5月7日）。プランの中から独立した部分を特定し、複数のサブエージェントで同時に実行する機能。/multitask コマンドでも手動起動できる。さらにSplit PRs機能で、大きな変更を論理的な単位に分割してPRを作れる。

Context Usage Breakdown（5月6日）。エージェントのコンテキストリングをクリックすると、ルール・スキル・MCP・サブエージェントごとのコンテキスト消費量が見える。どこがコンテキストを食っているか一目で分かる。

Bugbot従量課金化（5月11日）。月額$40/席のサブスクから、使った分だけ課金に変更。1レビューあたり平均$1.00〜$1.50。effort levelも選べるようになり、「High」にすると通常より35%多くバグを発見する。既存ユーザーへの適用は次回更新日（6月8日以降）から。

正直な感想

Teams連携のコンセプトは面白い。「AIコーディングをエンジニア以外にも開放する」という方向性は、CursorがIDE → SDK → Teams と着実にレイヤーを広げていることの延長線上にある。

ただし気になる点もある。

Teamsのスレッドという限られたコンテキストで、どこまで複雑なタスクを正確にこなせるのか。IDEの中なら開いているファイル、カーソル位置、選択範囲といった暗黙のコンテキストがあるが、Teamsにはそれがない。「この機能を直して」だけで正しいファイルにたどり着けるかは、リポジトリの規模と整理状況に依存しそうだ。

もう一つ。非エンジニアが気軽にPRを作れるようになると、レビュー負荷がエンジニア側に集中する可能性がある。PMが「とりあえずPR出して」を連発する未来は、エンジニアにとって嬉しいかどうか微妙なところだ。

この先に見えるもの

Teams連携が本当に化けるのは、Bugbotと組み合わさったときだろう。非エンジニアが出したPRをBugbotが自動レビューし、指摘を修正したうえでマージ可能な状態にする。人間のエンジニアはアーキテクチャ判断だけに集中する — そんなワークフローが現実的に見えてきた。

セットアップはCursorのダッシュボードからTeams連携をインストールするだけ。まだ使える企業は限られているかもしれないが、動向を追っておく価値はある。