ソフトウェア開発ツールの歴史を振り返ると、大きな転換は「書き方」の変化によって起きてきた。テキストエディタからIDE（統合開発環境）へ、そしてIDEにコード補完が組み込まれ、GitHub Copilotに代表されるAI補完が当たり前になった。Cursor（正式名称：Anysphere Inc.）が2026年4月2日に公開したCursor 3は、この系譜に並ぶような段階的な進化ではない。コードエディタという概念そのものを、エージェントの管理コンソールへと作り替えようとしている。
同社はこの変化を「ソフトウェア開発の第三の時代」と位置づける。第一の時代が人間がすべてのコードを手動で書く時代、第二の時代がAIが補助的に提案を出す時代だとすれば、第三の時代とは「多数のエージェントが自律的に動いて改善をリリースする」時代だ。Cursor 3はその第三の時代を前提に設計された最初のプロダクトである。
「エージェントファースト」へのゼロからの再設計
Cursor 3が従来のバージョンと根本的に異なるのは、UIを追加・拡張した結果ではなく、ゼロから作り直した点にある。同社の発表によれば、VS Codeをフォークして独自環境を構築してきた経緯から一歩踏み込み、今回はエージェントを中心に据えた新しいインターフェースを一から設計した。
最も目に見える変化がサイドバーの構造だ。ローカルで動作するエージェントも、クラウド上で動作するエージェントも、すべてが単一のサイドバーに集約される。モバイル、Web、デスクトップアプリ、Slack、GitHub、Linearといった多様な起点から起動されたエージェントが、一元的に把握できる形で並ぶ。これは単なる視認性の改善ではない。エンジニアが「どのエージェントが今どのリポジトリで何をしているか」を俯瞰しながら管理できる体制を、インターフェースの次元で実現したものだ。
従来の開発フローでは、複数の会話ウィンドウを切り替えながら、ターミナルとブラウザを行き来し、各エージェントの進捗を追うために相当な認知負荷がかかっていた。この問題に対してCursor 3が提示した解答が、エージェント統合ビューだ。クラウドエージェントは自分の作業内容のデモ映像やスクリーンショットを自動生成し、開発者がいつでも検証できるようにする。「エージェントが何をしているか分からない」という不透明性の問題を、UIの設計で解消しようとしている点は注目に値する。
クラウドとローカルの境界を越える引き継ぎ機能
Cursor 3が技術的に最も踏み込んでいるのが、クラウドとローカルの環境をまたいだエージェントセッションの移動機能だ。
クラウドエージェントは、手元のワークステーションよりも豊富なハードウェアリソースを活用できるため、多数のタスクを並列実行できる。たとえば複数のリポジトリにまたがる横断的な変更や、10時間を超えるような長時間のバグ解析も、クラウドエージェントが得意とする領域だ。一方でローカルエージェントは、生成されたコードをその場で開いて手作業で編集したり、テストをローカル環境で実行したりするという、細かな精度が求められる作業に向いている。
Cursor 3はこの二つのモードを固定的に分離せず、セッションを動的に移動させる仕組みを設けた。クラウドで大量のコードを生成したあと、そのセッションをローカルに移して確認・修正するという流れも、逆に作業途中のローカルセッションをクラウドに送り出してノートPCを閉じたまま処理を継続させるという流れも、どちらも可能だ。
この機能を支える内製モデルがComposer 2だ。先月（2026年3月）に公開されたこのモデルは、Cursorが開発したコーディング特化型LLMで、高い使用量上限と反復作業での速度を両立させている。同社によれば、Claude等の汎用LLMと比べてコスト効率でも優位があるという。
Gitワークフローの統合と設計モードの追加
Cursor 3が持ち込んだ実務的な改善のうち、見落とされがちなのがGit操作の内包だ。ステージング、コミット、プルリクエストの管理が、エディタを離れることなくCursor 3のインターフェース内で完結する。これにより開発者は「コードを書く→コードを確認する→変更をコミットする→PRを作る」という一連のワークフローを、コンテキストの切り替えなしに進められる。
UIの開発に特化した機能も加わった。Design Modeを有効にすると、画面上のUI要素を選択して自然言語でどう変更したいかを記述するだけで、AIエージェントが実装を行う。フロントエンド開発においてデザインの意図をコードに落とし込む手間を大幅に省く仕組みで、ビジュアルのプロトタイピングとコード生成を同一の作業流で行える点が特徴的だ。
また、複数のLLMに同時にリクエストを送り、最良の回答を選択するショートカット機能も追加された。CursorはClaude、GPTシリーズをはじめとする外部LLMに加え、内製のComposer 2も選択肢として提供しており、タスクとコンテキストに応じて最適なモデルを使い分けられる。
Anthropic・OpenAIとの競争構造から読み解くCursor 3の意味
Cursor 3が登場したタイミングは、AI開発ツール市場における競争構造の変化と切り離して考えることはできない。
Anthropicが提供するClaude Codeは、CLIベースのエージェント開発環境として実務での採用が広がっている。OpenAIもCodexをAnthropicのClaude Code内でプラグインとして動作させる形でリリースした。LLM各社がコーディング支援ツールを直接展開し始める中、CursorはIDEというハードウェアレイヤーに近い位置を守りながら、そこにエージェントオーケストレーションの機能を加える戦略を採った。
この構図は、クラウドインフラとアプリケーションレイヤーの距離が詰まる際に繰り返されてきたパターンと重なる。インフラ提供者がアプリレイヤーに進出することで既存のアプリベンダーが圧迫される展開だ。Anthropic、OpenAIというLLM提供者がコーディングツールを提供し始めた今、Cursorはより上位の抽象レイヤー——エージェントを管理する「コントロールプレーン」——に居場所を見つけようとしている。
Cursorのバックには既にNvidiaとGoogleから合計30億ドル超の資金が集まっている。この支援がある種の保険であることは間違いないが、それ以上に意味があるのは、NvidiaもGoogleも自社のクラウドGPUインフラやAIサービスとCursorの統合に関心を持っているという構造的な関係だ。エージェントを大量に並列実行する需要は、そのままGPUクラウドの需要と直結する。
開発者コミュニティが問う「エージェント化」の副作用
Cursorのアプローチに対して、開発者コミュニティでは賛否が分かれる。エージェントが自律的にコードを書く速度は確かに上がったとしても、そのコードの品質や保守性を誰が責任を持つのかという問いは、Cursor 3が登場してもなお解消されていない。
生成されたコードのレビューにかかるコストが、コードを書くコストより大きくなるシナリオも現実的だ。Cursor 3が導入した差分ビュー（diff view）の改善や、エージェントが作業ログを自動生成する仕組みは、このレビューコストを下げることを意識した機能と読める。しかし、コードが爆発的に増え、書かれた意図が失われていく「技術的負債のエージェント化」という問題は、ツールの改善だけで解決できるものではない。
開発者が「指示を出す人」として上流に移行する一方で、エージェントが生成したコードの品質を担保するためのスキルセット——アーキテクチャ設計能力、テスト戦略の設計力、プロンプトエンジニアリングの知識——の重要性は高まっている。Cursor 3は開発の効率化ツールである前に、エンジニアに役割の再定義を迫るシステムでもある。
Cursor 3のデスクトップアプリを更新し、Cmd+Shift+P → Agents Window で新しいインターフェースにアクセスできる。同社は今後も、自律的なエージェントの能力向上とチーム間のコラボレーション機能強化を継続すると明言しており、Cursor IDEそのものへの投資も並行して続けるとしている。AIがコードの大半を書くようになったとしても、人間がどの場所で、どの粒度で関与するかを選べる設計を保つ——そのバランスの取り方こそが、今後のAI開発ツール競争で最も問われる問いになるはずだ。
Sources
- Cursor: Meet the new Cursor
