Cursor 3まとめ：VS Code脱却、エージェントが98%書く時代のIDEはこう変わった

コードを書かないAIエンジニア@もるふぉです。

AIエージェントでコーディングしていて、「このインターフェース、なんか違うな」って感じたことありませんか？

チャットがサイドパネルに追いやられていて、コードと並べて見られない。

ショートカットが効かない。

フォーカスが勝手に移動する。

「エージェントが主役なのに、UIがエージェントファーストじゃない」という微妙なズレ、地味にストレスたまりますよね。

2026年4月2日（米国時間）、Cursor 3が正式にリリースされました。

これ、ただのバージョンアップじゃないんですよ。

VS Codeのフォークをやめて、エージェントファーストでゼロから作り直した新しいインターフェースです。

自分はClaude Codeをメインで使っている立場ですが、Cursor 3のアプローチには正直「おっ」と声が出ました。

この記事では、Cursor 3で何が変わったのか、なぜVS Codeを捨てたのか、そして2026年のAIコーディングツールをどう選ぶべきかを、エンジニア目線で整理していきます。

Cursor 3とは何か――なぜ今、VS Codeをやめたのか

VS Codeフォークの限界とエージェント時代の要請

CursorはもともとVS Codeをフォークして、そこにAI機能を載せる形で開発されていました。

多くのユーザーにとって、VS Codeの操作感をそのまま使えるのは大きなメリットだったはずです。

じゃあなぜやめたのか。

CursorのHead of AI EducationであるLee Robinsonは、リリースに合わせた投稿でこう語っています。

「Opus 4.5以降、エージェントでコーディングしていたが、気に入るインターフェースがなかった。自社のものも含めて」

これ、かなり正直な告白ですよね。

自分たちが作ったツールを使っていて、「気に入らない」と気づいてしまった。

VS Codeベースの拡張という制約の中では、「すべてのピクセルをコントロールする」ことができない。

エージェントが中心になる開発体験を本気で追求しようとしたとき、フォークの延長線上には答えがなかったということです。

具体的には、エージェントチャットのレイアウト自由度、マルチエージェントの並列実行、クラウドとローカルの統合UI――こうした機能をVS Codeの枠組みで実現するには限界がありました。

「ちゃんと作りたい。だからゼロから作り直す」。

その決断がCursor 3です。

12月からのゼロベース再構築という決断

Lee Robinsonによると、2025年12月に「ゼロからやり直す」決断をしたそうです。

ここがポイントなんですが、最初は「伝統的なIDEから完全に離れる」方向を検討したらしいんですよ。

ところが社内テストで、エディターの一部を手放すのが想像以上に難しいことがわかった。

エージェントが98%のコードを書いたとしても、残り2%――ファイル閲覧、デバッグ、小さな編集、go to definition、LSP――は開発者にとって本当に重要だったんです。

そこで@ryolu\_氏と12月末からプロトタイピングを開始。

「シンプルで禅のようなUIから始めて、必要に応じて深く掘り下げられる」というコンセプトで新UIが形になっていきました。

この「全部捨てようとしたけど、捨てちゃいけないものが見えた」というプロセスが、Cursor 3の設計思想そのものだと思います。

では、その新UIが具体的にどう変わったのか。

ここからが本題です。

Cursor 3 新インターフェースの全容：エージェントファーストUIとは

エージェントサイドバーとマルチワークスペース

Cursor 3で最初に目に入るのは、統一エージェントサイドバーです。

ローカルで動いているエージェントもクラウドで動いているエージェントも、すべて一覧で確認できます。

複数のリポジトリで同時に作業するマルチワークスペースにも対応していて、「フロントのリポジトリでエージェントAを動かしながら、バックエンドのリポジトリではエージェントBがテストを書いている」みたいな使い方ができるようになりました。

つまり、複数のタスクを並列で走らせながら、IDE一つで全部監視できる。

今まで複数ターミナルやウィンドウを行き来していたのが、一画面に集約されるわけです。

さらに驚いたのが、エージェントの起動手段の多さです。

デスクトップアプリだけでなく、ウェブ、モバイル、Slack、GitHub、Linearからもエージェントを起動できます。

通勤中にスマホからエージェントにタスクを投げて、オフィスに着いたらデスクトップで結果を確認する――そんなワークフローが現実になったわけです。

エージェントチャットが「タブ」になった意味

これが地味に大きい変更なんですよ。

従来のCursorでは、エージェントとのチャットはサイドパネルやオーバーレイとして表示されていました。

Cursor 3では、エージェントチャットが通常のタブとして動作します。

何が嬉しいかというと、ファイルタブと同じようにスプリットビューやペイン操作ができるんです。

左ペインにコードを表示して、右ペインでエージェントチャットを開く。

あるいは3ペイン構成で、コード・チャット・diffビューを並べる。

「コードを見ながら会話する」が、ようやく一等席になった感じです。

キーボードショートカットも安定して動作するので、マウスに手を伸ばす回数が減ります。

VS Codeの拡張として動いていた頃は、こういうUIの細かい部分で「ガタつき」がありました。

フォーカスが意図せず移動したり、ショートカットが効かなかったり。

Cursor 3ではすべてのピクセルを自前でコントロールしているので、こうした小さなストレスが解消されています。

React Compiler採用によるパフォーマンス改善

技術的に面白いのが、Cursor 3のUIにReact Compilerが採用されている点です（Lee Robinsonの投稿より）。

React Compilerはメモ化を自動で最適化してくれるので、手動でuseMemoやuseCallbackを書き散らす必要がなくなります。

結果として、UIのレンダリングパフォーマンスが向上し、Lee Robinsonも「速くて信頼性が高く、UIのガタつきが少ない」と評しています。

エディタのパフォーマンスって、意識しないレベルで快適さに直結するので、この改善は毎日使うツールとしてかなり重要ですね。

新UIの全容が見えたところで、次はCursor 3の設計哲学のコアに触れていきます。

個人的にはここが一番アツいポイントです。

「エージェントが98%書く」時代に残る2%の重要性

ファイル閲覧・デバッグ・LSPは削れなかった

ここが自分にとって一番刺さったポイントです。

Lee Robinsonの「エージェントが98%のコードを書いても、残り2%は本当に重要」という話。

具体的には以下の機能です。

• ファイル閲覧（コードベース全体の把握）
• デバッグ（ブレークポイント設定、変数の中身の確認）
• 小さな編集（エージェントに頼むほどでもない1行修正）
• go to definition（定義元へのジャンプ）
• LSP（言語サーバーによるリアルタイムエラー検知、補完）

「エージェントに頼むには細かすぎるが、ないと開発が止まる」機能ですよね。

Cursorチームが最初に「伝統的IDEから完全に離れる」方向を検討して、結局戻ってきた理由がここにあります。

自分もClaude Codeで日常的に開発していますが、コードレビューやデバッグの局面では結局エディタを開きますからね。

「あ、自分も同じことしてる」って思いませんでした？

Cursor 3はこの現実をちゃんと受け止めた上で、エージェントファーストのUIを設計しています。

再設計されたdiffsビューやGit統合（ステージング、コミット、PR管理）も組み込まれていて、「エージェントの出力を検証する」ワークフローが一通りIDE内で完結するようになっています。

開発者の役割はコーダーからオーケストレーターへ

98%をエージェントが書くなら、開発者の仕事は何になるのか。

自分の実感では「オーケストレーター」という表現がしっくりきます。

いわばPM（プロジェクトマネージャー）がチームを仕切るような構造です。

要件を整理してエージェントに伝える。

エージェントの出力をレビューする。

複数のエージェントを並列で走らせて、全体の整合性を取る。

アーキテクチャの判断を下す。

これ、実はシニアエンジニアが元々やっていたことに近いんですよ。

ジュニアメンバーにタスクを振って、コードレビューして、設計判断をする。

その「ジュニアメンバー」がAIエージェントに置き換わっただけで、求められるスキルセットは変わっていない。

Cursor 3の並列エージェント実行は、まさにこのオーケストレーション体験を強化する機能です。

エージェントのオーケストレーションという観点では、Gemini CLIをマルチエージェントで動かすフレームワーク「oh-my-gemini」も同じ方向性を持っています。複数エージェントの協調動作に興味がある方はこちらも参考にしてみてください。

では、そのエージェントがローカルとクラウドでどう統一されたのか、次で見ていきましょう。

クラウドエージェントとローカルの統一アーキテクチャ

ローカル⇔クラウドのシームレスな切り替え

Cursor 3の設計で技術的に最も興味深いのが、ローカルとクラウドの統一です。

これ、エンジニアとして「わかる、その辛さ」ってなる話なんですよ。

自分も以前、Claude CodeとローカルのVS Code拡張を行き来していた時期がありました。

「あれ、このコンテキストどっちで持ってたっけ」「ローカルで変更したファイル、クラウド側に反映されてない」みたいな地味なズレが積み重なって、気づくと無駄な確認作業に時間を取られている。

従来のCursorでも、ローカルエージェントとクラウドエージェントは別々のコードパスで実装されていたそうです。

これがCursor 3では、コアのエージェントハーネスがデスクトップ、ウェブ、CLI共通になっています。

実用面で何が嬉しいかというと、たとえばオフライン環境（飛行機の中とか）でローカルエージェントとして作業していたセッションを、ネットに繋がったらそのままクラウドに移行できます。

逆に、クラウドエージェントの作業結果をローカルに引き取って手元で検証することも可能です。

「今どの環境にいるか」を気にせず作業を続けられる。

環境の切り替えでコンテキストが途切れるストレスが消えます。

Cursorチームによると、クラウドエージェントの使用量は大幅に増加しており、2026年の大きな部分になるとのこと。

統合ブラウザツールも組み込まれていて、クラウドエージェントが何をしているかをデモやスクリーンショットで確認できる可視化機能も備わっています。

if (local) else if (cloud) を消す設計思想

エンジニアとして一番共感したのがこの部分です。

Lee Robinsonは「if (local) { ... } else if (cloud) { ... } のような二重コードパスを解消した」と語っています。

コードベースに条件分岐がハードコードされている状態って、開発者なら誰でも身に覚えがあると思います。

「また環境差分のバグか」「テストを2箇所管理するのがしんどい」「機能追加のたびにここも直さないといけない」――このループ、本当に消耗しますよね。

自分も昔、ローカル用のフォールバック処理があちこちに散らばったコードベースを引き継いだことがあって、その見通しの悪さに苦労した経験があります。

Cursor 3はこの技術的負債に正面から取り組んで、統一されたアーキテクチャを実現しました。

ユーザーから見ると「ローカルかクラウドかを意識しなくていい」というシンプルな体験になるわけですが、その裏には大規模なリファクタリングがあったはずです。

Cursor MarketplaceとMCPプラグイン

もう一つの大きな追加が、Cursor Marketplaceです。

MCPサーバー、スキル、サブエージェントをマーケットプレイスからインストールして使えるようになりました。

チーム向けには、プライベートなプラグインリポジトリ（チームマーケットプレイス）も用意されています。

自社専用のMCPサーバーやカスタムスキルを、チームメンバーだけが使える形で配布できるわけです。

また、Cursorが独自開発したコーディング特化モデル「Composer 2」（2026年3月リリース）も統合されており、エージェントの生成精度が底上げされています。

エコシステムの広がりという点では、VS Code Marketplaceに代わる独自の拡張基盤を築こうとしている意志が見えますね。

AIエージェントにコマンド一つでスキルを追加するという発想は、Cursor Marketplaceと方向性が重なります。画像生成系のエージェントスキルに興味があれば「Krea Skillsとは？AIエージェントにコマンド1つで画像生成を追加する方法」も参考になるはずです。

アーキテクチャの全体像が見えたところで、コミュニティがこのリリースをどう受け止めているか、見ていきましょう。

Cursor 3への開発者コミュニティの反応

Cursor 3のリリースは、Hacker Newsや各種開発者フォーラムで活発な議論を呼んでいます。

賛否がくっきり分かれていて、読んでいると「わかる、どっちの気持ちも」となるんですよ。

期待派の声は明快です。

「エージェントファーストは正しい方向。VS Code拡張という制約の中で無理やりやっていた時代は終わった」「UIの自由度を手に入れたことで、これから本当のエージェント体験が作れる」。

VS Code拡張の限界を感じていたユーザーほど、この決断を歓迎しています。

一方、懸念派の声も無視できません。

「VS Codeエコシステムから離れるリスクが大きい」「使っていた拡張機能が全部使えなくなる」「Cursorに依存する度合いが高くなる、ロックインが怖い」。

特に職場や既存プロジェクトでVS Code前提の環境が整っている人にとって、これは小さくない問題です。

自分はどう思うか、正直に言うと――両方の気持ちがよくわかります。

自分もVS Codeの拡張に依存していた時期があって、「これが全部消えるのか」と考えたら確かに怖い。

でも、エージェントが開発の主軸になっている今のタイミングで、「全部コントロールできる土台」を作るという決断は、長期的に見て正しいと思っています。

VS Code拡張として載せ続けていたら、次の3年でも同じ「ガタつき」と戦い続けることになる。

どこかで踏み切らないといけないタイミングだったし、Cursorはそれを今やったということです。

では、こうした背景を踏まえた上で、実際のツール選びはどうすればいいのか。比較表で整理していきます。

Cursor 3 vs Claude Code vs GitHub Copilot：2026年の選び方

3ツールの比較表

2026年4月時点で、AIコーディングツールの主要な選択肢を整理しました。

※ 料金は2026年4月時点の情報です。

各ツールに明確な強みがあるので、「どれが最強か」ではなく「自分のスタイルに何が合うか」で選ぶのが正解です。

自分の使い分けを正直に言うと、こうです。

メインはClaude Code。

ターミナルとエディタを行き来するワークフローが染み付いていて、CLAUDE.mdでプロジェクトごとのルールを細かく設定できるのが自分のやり方に合っている。

ただ、Cursor 3のクラウドエージェント可視化や並列エージェント管理は正直うらやましい。

「複数エージェントを並列で監視しながら大きなタスクをさばく」という用途なら、今すぐCursor 3に切り替えるレベルの差があると思っています。

GitHub Copilotは、チームの標準ツールがVS Code+GitHubで統一されている組織では最も導入摩擦が低い。

個人の好みで選ぶ局面と、チームの現実に合わせる局面は別物なので、そこは切り分けて考えるのが現実的です。

どんな開発スタイルに何が合うか

Cursor 3が向いている人

• GUIでエージェントの動きを視覚的に確認したい
• 複数のエージェントを並列で走らせたい
• クラウドエージェントを多用する（外出先からもタスクを投げたい）
• チームでプラグインやMCPを共有して使いたい

Claude Codeが向いている人

• ターミナル中心のワークフローが好き
• 深いコンテキスト理解が必要な大規模リファクタリングが多い
• CLAUDE.mdでプロジェクト固有のルールを細かく設定したい
• 既存のエディタ（Vim、Neovim、VS Code）を手放したくない

GitHub Copilotが向いている人

• VS CodeやJetBrainsから離れたくない
• インライン補完（タブ補完）を中心に使いたい
• GitHub Actionsなど既存のGitHubエコシステムとの連携を重視する
• チーム導入のしやすさ（管理画面、ライセンス管理）を重視する

まとめ：Cursor 3は「IDEの終わり」ではなく「IDEの進化」

Cursor 3のリリースは、「エージェントファースト時代のIDEはどうあるべきか」という問いに対する一つの回答です。

整理すると、Cursor 3の核心は以下の3点です。

• VS Codeフォークを脱却し、すべてのピクセルをコントロールする独自UIへ移行した
• エージェントが98%書く現実を前提に、残り2%（ファイル閲覧、デバッグ、LSP）を大切にした設計
• ローカルとクラウドの統一アーキテクチャで、環境を意識しないシームレスな体験を実現

「IDEは終わる」という極端な意見もありますが、Cursor 3が証明したのはむしろ逆です。

エージェントが主役になるからこそ、「エージェントの出力を検証し、方向を修正する場所」としてのIDEの価値が増している。

Cursor 3は従来のIDEを壊したのではなく、エージェント時代に合わせて進化させたんですね。

まだ触っていない方は、公式ブログ（cursor.com/blog/cursor-3）で新UIの全容をチェックしてみてください。

既存のCursorユーザーであればアップデートするだけで試せるので、移行のハードルはかなり低いです。

「まずアップデートして5分だけ触ってみる」、それだけでいいと思います。

エージェントファーストの開発体験がどんなものか、実際に手を動かしてみると「ああ、こういうことか」と腹落ちすると思いますよ。