Cursor 3はIDEをエージェントの管制塔に作り替えた

Cursor がメジャーアップデート「Cursor 3」を公式ブログで発表した。VS Codeベースの従来UIを捨てて、エージェントの管理を中心に据えたインターフェースをゼロから構築している。Hacker Newsでは302ポイント・257コメントまで伸びた。

前回のComposer 2では基盤モデルにMoonshot AIのKimi K2.5を使っていることが外部開発者に発見されて話題になったが、今回の焦点はモデルではなくプロダクトのアーキテクチャそのものだ。従来のIDEが数十年間守ってきた「開発者がコードを書く」という前提を、Cursor 3は正面から崩しにかかっている。

従来のIDEが前提にしていたもの

VS Code、JetBrains、Xcode。これらのIDEはすべて同じ前提で設計されている。開発者がコードを読み、理解し、自分の手で書き換えるという前提だ。

この前提のもとで、IDEの機能はすべて「開発者の手作業を効率化する」方向に進化してきた。

機能	役割
ファイルツリーとエディタタブ	コードベースを物理的なファイル構造で把握し、必要なファイルを手動で開く
Go to Definition / Find References	AST解析に基づく確定的なコードナビゲーション。開発者が「次にどこを読むか」を判断する
リファクタリングツール	Rename Symbol、Extract Method、Inline Variable。いずれもAST上の変換で、結果が100%予測可能
統合ターミナルとデバッガ	開発者が明示的に起動・操作する受動的なツール群
シングルワークスペース	基本的にひとつのプロジェクトに集中する設計

これらは優れた設計だし、今も多くの開発者にとって最適なワークフローだ。しかしCursor 3は、この前提そのものを書き換えようとしている。

何が変わったのか

Cursor 3の設計思想は「エージェントが主役、人間は監督」に振り切っている。従来のCursorはVS Codeフォークにチャットパネルを足したIDEだったが、Cursor 3ではエージェントの実行状況を俯瞰するダッシュボードが画面の中心になった。

主な新機能は以下の通り。

機能	内容
マルチワークスペース	複数リポジトリをまたいでエージェントを同時に走らせる
クラウドエージェント	隔離されたクラウドVM上で動作。ターミナル・ブラウザ・フルデスクトップ環境を備える
ローカル/クラウド切り替え	ローカルで始めた作業をクラウドに移してオフラインで放置、逆も可能
Agent Tabs	複数のエージェントチャットを並列表示。サイドバイサイドやグリッド配置
Design Mode	ブラウザ上のUI要素にアノテーションを付けてエージェントに直接指示
Cursor Marketplace	MCP・スキル・サブエージェントをプラグインとして配布。チーム用プライベート公開にも対応

これらの機能が、従来のIDEの何を置き換えようとしているのかを対比すると構造が見えてくる。

従来のIDE	Cursor 3	変化の本質
ファイルツリー + エディタタブ	Agent Tabs	操作対象がファイルからエージェントセッションに
シングルワークスペース	マルチワークスペース	複数リポジトリをまたいだ同時作業
ローカル実行のみ	クラウドエージェント + ローカル	実行環境がローカルマシンに縛られない
Rename Symbol等の確定的リファクタリング	LLMベースのコード変更	確定的だが限定的 → 柔軟だが非決定的
DevTools + 手動CSS修正	Design Mode	ブラウザ上で視覚的に指示、エージェントが修正
手動でテスト実行・結果確認	エージェントが自律的にテスト・修正	開発者が「テストを回す」→ エージェントが「回して直す」

クラウドエージェントは特に野心的だ。起動するとクラウド上にサンドボックスVMが立ち上がり、リポジトリをクローンして環境構築からコード変更・テスト・PR作成まで一貫して実行する。開発者がオフラインでもバックグラウンドで動き続け、完了時にはスクリーンショット付きのデモを生成して報告する。ユーザーあたり最大10並列のワーカーが使える。

従来のIDEでは、CIパイプラインが「コミット後のテスト自動化」を担っていた。Cursor 3のクラウドエージェントは、それを「コミット前のコーディング自体の自動化」にまで押し上げたものと言える。

開発ワークフローの構造的な変化

従来のIDEとCursor 3では、開発ループにおける人間の立ち位置が根本的に異なる。

従来のIDEでは開発者がループの中心にいる。

graph TD
    A1[開発者がファイルを開く] --> A2[コードを読んで理解]
    A2 --> A3[手動でコード変更]
    A3 --> A4[ターミナルでテスト実行]
    A4 --> A5{テスト通過?}
    A5 -- No --> A3
    A5 -- Yes --> A6[コミット]

Cursor 3ではエージェントがループの中心に移る。

graph TD
    B1[開発者がタスクを記述] --> B2[エージェントが<br/>コードベース解析]
    B2 --> B3[エージェントが<br/>コード変更]
    B3 --> B4[エージェントが<br/>テスト実行]
    B4 --> B5{テスト通過?}
    B5 -- No --> B3
    B5 -- Yes --> B6[開発者がレビュー・承認]

従来のIDEでは、開発者がコードを書き、テストし、失敗したら自分で直す。IDEはそのサイクルを速く回すための道具だ。

Cursor 3では、開発者はループの外側に立ち、エージェントの成果物をレビューする立場になる。IDEは「コードを書く道具」から「エージェントを監視する管制塔」に変わった。

この変化は、JetBrainsのRename SymbolとCursor 3のエージェントベースの変更を比べると具体的に見える。JetBrainsのRename SymbolはASTを解析して参照箇所を確定的に書き換える。結果は100%予測可能で、意図しない変更は起きない。一方、Cursor 3のエージェントは「この関数名を変更して、関連するテストとドキュメントも全部更新して」という曖昧な指示を受け付ける。文字列リテラル内の参照やコメント中の言及まで拾えるが、LLMの出力は非決定的なので予期しない変更が混入するリスクもある。

確定的で安全だが範囲が限定的な従来のリファクタリングか、柔軟だが検証が必要なエージェントベースの変更か。Cursor 3は後者に賭けた形だ。

Copilot CLIの/fleetとの比較

並列エージェント実行という点では、GitHub Copilot CLIの/fleetコマンドが先行して同様のコンセプトを実装している。ただし両者のアプローチは異なる。

Copilot CLIの/fleetはひとつのプロンプトからオーケストレータがタスクを分解・並列実行する仕組みで、開発者は最初の指示だけ出せばいい。対してCursor 3は開発者自身が複数のエージェントタブを開いてそれぞれに別の指示を出す、いわば「手動オーケストレーション」が基本になる。自動分割の賢さを取るか、人間の判断で粒度をコントロールするか、という思想の違いがある。

もうひとつの違いはクラウド実行だ。Copilotの & キーによるクラウド委任はリポジトリ単位の処理に閉じているが、Cursorのクラウドエージェントは独立したVM環境を丸ごと提供するため、ブラウザでのUI確認やデスクトップ操作まで含めた重い作業に使える。

ちなみに、どちらも従来のIDEにはなかった概念だ。VS CodeやJetBrainsでは「複数の自律的なプロセスが同時にコードを書き換える」という発想自体が存在しなかった。せいぜいLinterやFormatterが保存時に走る程度で、コードの変更主体はあくまで開発者だった。

Design ModeはDevToolsを置き換えるか

Cursor 3に統合されたブラウザ上で、ローカルサーバーのレンダリング結果を直接確認できる。Design Modeを有効にすると、UIコンポーネントをクリックしてアノテーションを付けられるようになり、「このボタンの色を変えて」「この余白を詰めて」といった視覚的なフィードバックをエージェントに渡せる。

従来のフロントエンド開発では、同じことをするのに以下のステップが必要だった。

ブラウザのDevToolsを開いてInspectで要素を選択
CSSセレクタやコンポーネント名を特定する
IDEに戻って該当するファイルを検索する
CSSやJSXを手動で修正する
ブラウザをリロードして結果を確認する
満足するまで3〜5を繰り返す

Design Modeはこのループをショートカットする。ブラウザ上で「ここを直して」と指すだけで、エージェントがDOM構造とソースコードを照合してコードを修正する。DevToolsのInspectで要素を特定する作業も、IDEとブラウザを行き来する手間もなくなる。

ただし、DevToolsが提供するネットワーク解析、パフォーマンスプロファイリング、メモリリーク検出などの機能をDesign Modeが代替するわけではない。Design Modeはあくまで「見た目の修正指示」に特化しており、デバッグツールとしてのDevToolsは引き続き必要になる。

Composer 2の位置づけ

モデル面では引き続きComposer 2を推している。前回の記事で解説した通り、基盤はMoonshot AIのKimi K2.5にコーディング特化の強化学習を適用したモデルで、CursorBenchではGPT-5.4 Thinkingに肉薄する性能を見せていた。Cursor 3ではこのComposer 2が「エージェントタスクに特に適している」と位置づけられており、Claude等の外部モデルとの切り替えも可能だ。

新機能として、ショートカットキーで複数のLLMに同じプロンプトを投げて出力を比較する機能も追加されている。従来のIDEにはモデル選択という概念自体がなかったが、AIコーディングツールでは「どのモデルを使うか」がコード品質に直結するため、比較機能は実用的だ。

HNコミュニティの反応

Hacker Newsのコメント欄は賛否が割れた。

好意的な意見として多かったのは、Cursorのリモートインデキシングがコードベースのナビゲーションを高速化している点、そしてチャットで特定のファイルやコードをタグ付けして参照できるUXの優位性だ。

一方で批判的な意見はいくつかのパターンに分かれた。

まず、従来のIDE体験を手放したくない層。「新しいエージェントのswarmに興味はゼロ。無理やり押し付けるのはやめてほしい」という声は複数あった。並列エージェントの管理に認知コストがかかりすぎる、人間のレビューなしにエージェントが同時にコードを書き換えるのは品質面で危険だ、という懸念がある。この層にとっては従来のIDE + Copilotの補完で十分であり、「コードは自分で書きたい」というスタンスが根底にある。コードベースを深く理解すること自体に価値を置く開発者にとって、エージェントへの委任は生産性向上ではなく理解の放棄に見える。

コスト面の不満も目立った。あるユーザーは「プレミアムモデルで週に2,000ドル使っていた」と報告し、Claude Code Maxに乗り換えたら「10分の1のコスト」になったという。CursorのビジネスモデルがAPIトークンの再販に依存している以上、使い込むほど高くなる構造への不満は根強い。

VS Codeプラグインとの互換性問題も繰り返し指摘されていた。CursorはVS Codeのフォークだが、ライセンスやフォーク時の差分が原因で一部のプラグイン（Python IntelliSenseなど）が正常に動作しない。Cursor 3でUIをゼロから再設計したことで、従来のVS Codeとの距離がさらに広がりそうだ。VS Codeのエコシステムに乗っていることがCursorの強みだったはずだが、エージェントファースト化でその強みを自ら削ぐリスクがある。

Claude Codeとの棲み分けについても議論があった。ターミナルベースのClaude Codeは「安価で自由度が高いが初期セットアップが重い」、Cursorは「統合環境で体験がスムーズだが高コスト」という構図になっている。Claude Code側は既存のIDEを捨てない方向に進んでおり、VS CodeやJetBrainsの拡張としてClaude Codeを使えば、従来のIDEのファイルナビゲーションやリファクタリングツールを維持したままエージェント機能を追加できる。Cursorは逆に、従来のIDE体験を切り捨ててエージェント体験に集中した。既存のIDEを拡張するか、IDEそのものを再定義するか。同じ「AIコーディング」でも路線が分かれている。

AIコーディングエディタの競争構図

AIコーディングツール市場は「IDEにチャットを足す」段階から「エージェントを管理するダッシュボードを作る」段階に移った。Copilot CLIの/fleet、OpenAI Codexのクラウドサンドボックス、Claude Codeのマルチエージェント連携と、各社が「複数エージェントの並列実行」を競っている。ただし、Claude CodeやZedのように従来のIDEの強みを保持する路線と、CursorやCodexのようにIDEを再定義する路線に分かれてきた。

従来のIDEのファイルツリーや確定的リファクタリングは、開発者がコードベースを深く理解するために最適化されてきた。エージェントに委任すれば速くはなるが、コードベースへの理解度は下がる。この「速さ」と「理解」のトレードオフに対して、各ツールが異なる回答を出しているのが現状だ。

Anysphere（Cursor運営）は30億ドル以上を調達済みで、NVIDIAやGoogleが出資者に名を連ねている。ただComposer 2の基盤モデル問題で露呈した通り、独自のプレトレーニングは行っておらず、強化学習レイヤーとプロダクト設計で差別化する路線だ。293億ドルのバリュエーションに見合うかどうかは、Cursor 3がどれだけ使い続けられるかにかかっている。