はじめに
Cursorを「AIが賢いVS Code」だと思って使っていました。補完が速くて、チャットで書き直してくれる、便利なエディタ。その認識のまま2026年のCursorを触ると、たぶん半分も使えていません。
きっかけは、久しぶりに大きめの改修をCursorに頼んだときでした。いつものようにチャットに指示を書いて、コードを眺めながら差分を待つつもりでいたら、返ってきたのは差分ではなくPull Requestでした。しかもその間、私は別のタスクの指示をもう一つ投げていて、そっちも並行で進んでいる。気づいたら、自分がコードを書いている時間より、エージェントに投げて、返ってきたものをレビューしている時間のほうが長くなっていました。
これはもうエディタの使い方ではありません。2026年4月のCursor 3で、Cursorは「開発者がコードを書き、AIが手伝う道具」から「エージェントがコードを書き、開発者が指揮する場所」に、はっきり軸足を移していました。今回は、その変化が具体的にどこに出ているのか、そして「エディタのつもり」で使うと何を取りこぼすのかを、触ってみた実感ベースで整理します。
先に3行でまとめると
- Cursor 3（2026年4月2日）は、公式が「エージェントを中心に据えた」新インターフェースとして公開した。複数のエージェントを束ねるAgents Windowが画面の中心になる
- 旧Background Agent（現Cloud Agent）は、手元のエディタではなくクラウドのVMで動く。Slackやgithubのコメントからも起動でき、作業を終えるとPull Requestで返ってくる
- 「速いエディタ」として使うと真価は出ない。投げて放置し、返ってきたPRをレビューする、という指揮官側の使い方に切り替えると景色が変わる
この記事に出てくる用語の位置づけ
Cursor独自の呼び名と、AIエージェント界隈で一般に使う言葉が混ざります。迷ったらここに戻ってきてください。
| 用語 | 位置づけ | ざっくりの意味 |
|---|---|---|
| Cursor 3 | Cursor独自 | 2026年4月2日リリースの大型版。エージェント中心に舵を切った |
| Agents Window | Cursor独自 | 複数のエージェントを1画面で束ねて指揮する新UI |
| Cloud Agent（旧Background Agent） | Cursor独自 | クラウドのVMで非同期に動くエージェント |
| Composer | Cursor独自 | 複数ファイルをまたいで編集する対話エージェント |
| worktree | 一般用語（Git） | 同じリポジトリを複数の作業ツリーに分けて並行作業する仕組み |
/best-of-n |
Cursor独自 | 同じタスクを複数モデルで並行実行し、結果を見比べるコマンド |
| Design Mode | Cursor独自 | 画面のUI要素を直接指し示してエージェントに指示するモード |
「エディタじゃない」という言い方は記事の便宜です。テキストエディタとしての機能はもちろん残っています。ただ、設計の重心がそこから移った、という意味で使っています。
まず、何が入れ替わったのか
Cursor 3の変化を一言でいうと、画面の真ん中に座るものが変わりました。従来はコードエディタが主役で、AIチャットは脇に控える補助でした。Cursor 3では、複数のエージェントを束ねるAgents Windowが主役の位置に来て、コードや差分はそれを確認するための場所に下がります。
この配置換えは、見た目の模様替えではありません。公式はこの新インターフェースを「よりシンプルで強力、そしてエージェントを中心に据えつつ、開発環境としての深さは保つ」ものだと説明しています。ここから読み取れるのは、開発者の役割が「自分で書く」ことから「複数のエージェントをオーケストレーション（指揮）する」ことへ寄っていく、という設計思想です。実際、Agents Windowは、ローカル・クラウド・SSH先・Gitのworktreeで動く複数のエージェントを、1つの画面でまとめて管理するために用意されています。エージェントを1体ずつ順番に回すのではなく、何体も同時に走らせて束ねる、という発想が土台にあります。
その象徴が /best-of-n です。同じタスクを複数のモデルに別々のworktreeで並行実行させて、出てきた実装を見比べていちばん良いものを選ぶ。1つの答えを待つのではなく、複数の答えを競わせて選ぶ、というやり方が正式なコマンドになっています。「どのモデルが一番いいか」で消耗する代わりに、迷ったら全部走らせればいい、という割り切りです。
Cloud Agentは、手元のエディタの外で動く
「エディタじゃない」といちばん強く感じたのは、Cloud Agent（旧Background Agent）を使ったときでした。これは名前のとおり、あなたの手元のマシンではなく、クラウド上の隔離されたVM（仮想マシン）で動くエージェントです。フル装備の開発環境を持っていて、そこでコードを編集し、実行し、テストまで回します。
起動の入り口が、エディタの中だけじゃないのも効いています。Cursorのデスクトップやweb、iOSアプリからはもちろん、Slackで @cursor と話しかけたり、GitHubやBitbucketのIssue・PRに @cursor とコメントしたり、Linearから呼び出したりできます。つまり、エディタを開いていない時間にも仕事を投げられる。通勤中にSlackから「このバグ直しといて」と投げて、席についたらPRが返っている、という流れが成立します。
そして作業が終わると、Cloud Agentは変更をリポジトリにpushして、Pull Requestを開いて返してきます。並列で何個でも走らせられるので、Aのバグ修正とBの機能追加とCのリファクタを同時に投げて、返ってきた3本のPRを順にレビューする、という進め方になります。この時点で、私はもうコードを「書いて」いません。指示して、返ってきたものを「読んで」います。
動かすには準備がひとつ要ります。Cloud AgentはVM上に開発環境を組む必要があるので、.cursor/environment.json（Dockerfileで環境を定義するファイル）を置くか、セットアップ済みのスナップショットを保存しておくか、エージェント主導でセットアップさせるか、のいずれかで環境を用意します。公式ドキュメントが「クラウドエージェントに開発環境を用意しないのは、エンジニアにPCを渡さないようなものだ」と書いているとおり、ここを飛ばすと本領は出ません。
「エディタのつもり」で使うと取りこぼすもの
ここまでを踏まえると、Cursorを「速いエディタ」として使うのは、機能の一部しか触っていないことになります。私が実際に切り替えて感じた、使い方の違いを並べておきます。
| エディタのつもりの使い方 | 指揮官側の使い方 |
|---|---|
| チャットで書き直させ、差分をその場で眺める | タスクを投げて放置し、返ってきたPRをレビューする |
| エージェントは1体、終わるまで待つ | 複数エージェントを並行で走らせ、Agents Windowで束ねる |
| どのモデルがいいか毎回悩む | 迷ったら /best-of-n で競わせて選ぶ |
| Cursorを開いている間だけ作業が進む | Slackやgithub経由で、開いていない間も進む |
右側に寄せるほど、Cursorは「エディタ」から遠ざかります。自分の手を動かす速さを上げる道具ではなく、自分の代わりに動くものを何体そろえて、どう配るかを考える道具になる。この切り替えができるかどうかが、Cursor 3を使いこなせるかの分かれ目だと感じました。
じゃあ、いつローカルで、いつクラウドに投げるか
とはいえ、何でもかんでもCloud Agentに投げればいいわけではありません。手元で見ながら直したほうが速いこともあります。私が使い分けている基準を図にするとこうなります。
分かれ目は「その場で見て直したいか」です。UIの細かい調整のように、目で見て即座にフィードバックしたい作業は、ローカルで対話しながら進めるほうが速い（このときDesign Modeで画面の要素を直接指し示すと指示が通りやすい）。逆に、テストを含めて独立して完結させられるまとまった作業は、Cloud Agentに投げて放置し、PRで受け取るのが向いています。作り方そのものに迷いがあるなら、/best-of-n で複数の案を出させて選ぶ。この3つを使い分けると、無駄な待ち時間がかなり減りました。
使ってみて、ここは気をつけたい
良いことばかりではありません。指揮官側にまわると、別の負担が出てきます。
ひとつは、レビューが仕事の中心になることです。並列で3本4本とPRが返ってくると、こんどはそれを読んでマージ可否を判断する時間が要ります。書く時間が減っても、読む時間が増える。中身を理解しないまま雰囲気でマージすると、あとで自分の首が締まります。エージェントに任せた量に比例して、レビューの目が問われるようになりました。
もうひとつは、権限と環境の準備です。Cloud Agentはリポジトリへのread-write権限を必要とします（PRを開くため、書き込み権限が要る）。会社のリポジトリで使うなら、どこまでの権限を渡すかは事前に整理しておいたほうがいいです。それと、前述の環境定義。ここを用意しないと、クラウドに投げても環境が組めずに空回りします。「投げれば動く」の手前に、地味なお膳立てが要ることは知っておいて損はありません。
おわりに
Cursorを触り直して感じたのは、「エディタが賢くなった」のではなく「エディタという枠が主役から降りた」ということでした。自分の手の速さを上げる話から、自分の代わりに動くものを何体そろえてどう配るか、という話に、道具の設計そのものが移っている。
この方向は、Devinがもともと立っていた場所でもあります。Devinは最初から「タスクを投げると、クラウドでエージェントが自律的に進めてPRで返す」という前提の道具でした。手元のエディタを起点にしていたCursorが、Cloud Agentとオーケストレーションに寄っていくのを見ると、エディタ側とエージェント側の両方が、真ん中で出会おうとしているように見えます。「開発者はコードを書く人」から「エージェントを指揮する人」へ。その移行を、どの道具で、どこまで自分の手に馴染ませるか。次は同じタスクをCursorのCloud AgentとDevinの両方に投げて、返ってきたPRの質と、任せられる範囲の違いを見比べてみるつもりです。
🚀 Devin専門の解説メディア「StartDevin」を運営中！
Devinの導入・使い方・最新アップデート・活用事例を、日本語でまとめています。
👉 StartDevin をチェックする（startdevin.jp）
この記事にぜひ いいね（LGTM） していただけると励みになります 🙌
参考リンク
- Cursor Docs（公式ドキュメント）（一次情報。Cloud Agentの実行環境・トリガー・PR連携）