2026年4月2日、Anysphere社がCursor 3をリリースしました。従来のVS Codeフォークベースのコードエディタから、エージェントを中心に据えた統合ワークスペースへの全面再設計です。同時期にPragmatic Engineerの調査では、AIコーディングツールの人気投票でCursorが19%にとどまり、Claude Codeの46%に大差をつけられている現実も明らかになりました。
この記事では、Cursor 3のアーキテクチャ変更の技術的背景と、Claude CodeなどCLI型ツールとの設計思想の違い、そして実務での使い分けを整理します。
VS Codeフォークの限界
Cursorは当初、VS Codeのフォークとして開発されました。VS Codeの成熟したエディタ基盤と拡張エコシステムを活用しつつ、AI機能を独自に追加する戦略です。しかし、このアプローチは時間の経過とともに複数の構造的問題を抱えることになりました。
まず、アップストリーム追従のコストです。VS Codeは月次で更新されますが、Cursorチームはそのたびに手動でマージ作業を行う必要があります。AI関連の独自修正がVS Codeの変更と衝突するケースが頻発し、マージに数日から数週間の遅延が生じていました。
次に、拡張機能の互換性問題です。MicrosoftはVS Code Marketplaceの利用規約を厳格に適用し始め、C/C++拡張などのMicrosoft製拡張機能がCursor上で正常に動作しなくなる事態が発生しました。Extension HostのnavigatoruserAgentにプラットフォーム情報が含まれないといった技術的な非互換も報告されています。
そして最も本質的な問題は、VS Codeの拡張APIがエージェント型ワークフローを前提に設計されていないことです。
VS Codeの拡張APIは「人間の操作を補助する」設計になっており、AIエージェントが自律的にエディタを制御するためのプリミティブが欠けています。具体的には以下のような制約があります。
-
vscode.workspace.fsAPIはファイルの読み書きを提供しますが、エージェントが「プロジェクト全体をスキャンし、依存関係グラフを構築し、影響範囲を特定して複数ファイルを同時に書き換える」といったワークフローを一貫して制御する仕組みがありません。各操作が独立したAPI呼び出しであり、操作間のトランザクション保証やロールバック機構が存在しません -
vscode.window.createTerminalAPIでターミナルを生成できますが、出力のストリーミング取得やプロセスの終了コード監視に制約があります。エージェントが「テストを実行し、失敗したケースを解析し、修正を加えて再実行する」という反復ループを組むには、ターミナルAPIの上に独自の監視レイヤーを構築する必要があります - Git操作についても、VS Codeの内蔵Git拡張はSCM Provider APIを通じてUIと連携していますが、このAPIはステータス表示とdiff表示が主目的です。エージェントがworktreeの作成、ブランチの切り替え、コンフリクトの自動解決を行うには、結局
child_processでgitコマンドを直接叩くしかありません - 最も根本的な制約は、Extension Hostのプロセスモデルです。VS Codeの拡張は単一のExtension Hostプロセス内で動作し、拡張間のメモリ空間は共有されています。8つのエージェントを並列実行し、それぞれが独立したファイルシステム状態を持つといったアーキテクチャは、このプロセスモデルの上では実現困難です
チャットパネルにAI機能を詰め込む形では、ファイルシステム操作、ターミナル実行、Git操作をエージェントが統合的に制御するアーキテクチャを実現できません。VS Codeの設計思想は「人間がエディタを操作し、拡張がそれを補助する」ことが前提であり、「AIエージェントが自律的にコードを書き、人間がそれを監督する」という世界観との間に根本的なギャップがありました。
Cursor 3の設計：Agents Windowという新パラダイム
Cursor 3は、従来のチャットパネルを完全に取り払い、Agents Windowと呼ばれる新しいインターフェースをゼロから構築しました。The New Stackは「IDEがフォールバックに格下げされた」と評しています。
Agents Windowの核心は、開発者がコードを書く人からエージェントを指揮するオーケストレーターへと役割を転換する点にあります。
マルチエージェント並列実行
Cursor 3では複数のAIエージェントを並列実行できます。各エージェントはGit Worktreeによって隔離された環境で動作し、互いのファイル変更が干渉しません。ローカル実行、クラウドVM、リモートSSHなど、実行環境を柔軟に切り替えられます。
Editor側の/worktreeコマンドで個別のWorktreeを作成し、/best-of-nコマンドで同一タスクを複数モデルに同時実行させて結果を比較する機能も用意されています。これらはAgents Window固有の機能ではなく、エディタのコマンドパレットから実行します。Anysphere社自身も、PRの3分の1以上がクラウドエージェント経由で作成されていると公表しています。
統合的なツールアクセスと内部アーキテクチャ
エージェントはファイルシステムの読み書き、ターミナルコマンドの実行、Gitのステージング・コミット・PR作成を一つのインターフェース内で完結させます。権限制御機能によるネットワーク・ファイルシステムポリシーの設定で、エージェントの権限を細かく制御できます。
この統合を支える内部アーキテクチャは、公式には詳細が公開されていませんが、公開情報と技術的な制約から以下のように推測できます。
まず、ファイルシステム層です。各エージェントがGit Worktreeで隔離されているということは、エージェントごとに独立した作業ディレクトリが存在します。ファイルシステムの変更監視には、macOSのFSEventsやLinuxのinotify相当のネイティブウォッチャーが使われていると考えられます。VS CodeのFileSystemWatcherをそのまま使わず、Worktree単位で独立したウォッチャーを立てることで、エージェント間のファイル変更イベントの混線を防いでいるはずです。
次に、LSP（Language Server Protocol）との統合です。複数のWorktreeが同時に存在する場合、各Worktreeに対して個別のLanguage Serverインスタンスを起動するか、あるいはマルチルート対応のLanguage Serverを共有する必要があります。エージェントが型エラーを検出して修正するといったワークフローには、LSPのtextDocument/diagnosticをリアルタイムで購読し、エージェントのツール実行ループにフィードバックする仕組みが不可欠です。
Git操作については、libgit2のようなライブラリを通じてプロセス内で直接操作するか、gitコマンドのラッパーを介して実行していると推測されます。Worktreeの作成・切り替え・マージをエージェントのアクションとして抽象化し、コンフリクト発生時にはエージェントに差分を提示して解決を促す、というフローが/worktreeコマンドの裏側で動いているはずです。
クラウドエージェントの場合は、これらのツールアクセスがリモートVM上で実行され、結果（変更差分、スクリーンショット、テスト結果）がストリーミングでクライアントに返されるアーキテクチャになっています。Anysphere社が「PRの3分の1以上がクラウドエージェント経由」と述べている事実は、このリモート実行基盤がすでに本番レベルで機能していることを示しています。
マルチサーフェス対応
デスクトップアプリだけでなく、モバイル、Web、Slack、GitHub、Linearからもエージェントを起動でき、すべてのエージェントがサイドバーに統合表示されます。クラウドエージェントは作業のスクリーンショットやデモを生成し、レビュー工程を支援します。
なぜVS Codeから離れる判断をしたのか
この決断の背景には、AIコーディングツール市場の急速な変化があります。
Pragmatic Engineerが2026年3月に実施した906人のエンジニアを対象とした調査によると、95%が週に1回以上AIツールを使用し、75%がエンジニアリング業務の半分以上でAIを活用しています。もはやオートコンプリート型の補助は差別化要因ではなく、エージェント型ワークフロー、つまり計画を立て、複数ファイルを横断して実行し、テストを回して反復するツールが求められています。
VS Codeのフレームワーク内でこのレベルのエージェント統合を実現するのは、前述した拡張APIの構造的制約（単一Extension Hostプロセス、トランザクションなしのファイル操作、ターミナル出力監視の制限）により困難です。仮にハックで実現したとしても、VS Codeのアップストリーム更新のたびにそのハックが壊れるリスクを抱え続けることになります。
Cursor 3がゼロからUIを再構築した理由は、技術的負債の解消ではなく、製品カテゴリ自体の変化への対応です。「コードエディタにAIを追加する」のではなく、「エージェントワークスペースにエディタ機能を組み込む」という発想の逆転が必要でした。エージェントが第一級市民であり、エディタはエージェントの出力を人間がレビューするためのビューに過ぎない。この優先順位の逆転を、既存のエディタフレームワークの上で実現するのは、フレームワークの設計意図に反する作業です。
Claude Code（CLI）vs Cursor 3（IDE統合）：設計思想の違い
Cursor 3がIDE統合型のエージェントワークスペースを志向する一方、Anthropic社のClaude Codeはまったく異なるアプローチを採っています。
Claude CodeはターミナルネイティブのCLIツールとして設計されています。React + Ink（ターミナル向けReact）でUIを構築し、Unixの哲学に従ったパイプライン型のアーキテクチャ（ユーザー入力 → CLIパーサー → クエリエンジン → LLM API → ツール実行ループ → ターミナルUI）を採用しています。
この2つのアプローチの違いは、ソフトウェア設計における古典的な対立軸を反映しています。
Cursor 3は「統合環境」の哲学を採っています。エディタ、ターミナル、Git、エージェント管理、デプロイを単一のアプリケーション内に統合し、コンポーネント間の連携を密結合で最適化するアプローチです。IDEの伝統であるEmacsやVisual Studioの延長線上にあり、「すべてを一箇所で」という思想が根底にあります。密結合であるがゆえに、エージェントがエディタの状態を直接参照したり、UIにリアルタイムでフィードバックを返したりする体験を自然に実現できます。
一方、Claude CodeはUNIXの「1つのことをうまくやる」哲学を忠実に体現しています。Claude Code自体は「LLMとの対話を通じてコードを読み書きするツール」であり、それ以上のことをしようとしません。エディタ機能は持たず、ユーザーが好きなエディタと併用します。cat file.py | claude -p "このコードをレビューして" のように標準入出力を通じたパイプライン合成が可能で、--output-format json でJSON出力すれば後続のスクリプトが結果をパースできます。CIパイプラインやGitHubActionsに組み込めるのは、この合成可能性（composability）があるからです。
この設計思想の違いは、拡張性のモデルにも表れています。Cursor 3はプラグインマーケットプレイスという「プラットフォーム側が拡張ポイントを定義する」モデルです。Claude CodeはCLAUDE.md（プロジェクト固有のルール記述）、Hooks（ライフサイクルイベントへのシェルスクリプト挿入）、MCP（外部ツールとの標準プロトコル接続）という「ユーザーが任意のツールを組み合わせる」モデルを採用しています。前者は統制された体験を提供し、後者は柔軟性を最大化します。
両者の具体的な違いは以下の通りです。
| 観点 | Cursor 3 | Claude Code |
|---|---|---|
| インターフェース | GUI（Agents Window） | CLI（ターミナル） |
| 実行モデル | 複数エージェントの並列オーケストレーション | 単一セッションの深い対話 |
| コンテキスト | マルチリポジトリの視覚的管理 | 100万トークンの巨大コンテキストウィンドウ |
| 拡張性 | プラグインマーケットプレイス | MCP、CLAUDE.md、Hooks |
| CI/CD統合 | IDE内完結 | パイプへの組み込み、ヘッドレス実行 |
| セッション持続性 | クラウド/ローカル間のシームレスな移動 | ターミナル・IDE・デスクトップ間で同一エンジン共有 |
Cursor 3は「視覚的にエージェント群を管理する」ことに最適化されており、Claude Codeは「大規模なコードベースに対して深い推論を行う」ことに最適化されています。100万トークンのコンテキストウィンドウは、他のツールが数ファイルで追跡を見失う規模のコードベース分析やアーキテクチャ判断において、決定的な優位性を持ちます。
実務での使い分け：Cursor + Claude Codeの併用ワークフロー
NxCodeの比較記事が指摘するように、2026年のプロ開発者の間で最も一般的な構成は「Cursorで編集 + Claude Codeで複雑なタスク」という併用パターンです。以下に、タスクの性質に応じた判断基準を示します。
Cursor 3が向いているタスク
具体的なシナリオで説明します。
フロントエンドのデザインシステム刷新のように、50以上のコンポーネントを新しいトークン体系に移行する作業では、Cursor 3の並列エージェントが威力を発揮します。Button、Card、Modalなどのコンポーネント群を複数のエージェントに分担させ、それぞれがWorktreeで隔離された環境で同時に作業を進められます。/best-of-nで異なるアプローチを試行し、Agent Tabsで結果を横並び比較して最適な実装を選択する、というワークフローは単一セッションのツールでは再現できません。
また、新機能のプロトタイピングでUIの見た目を確認しながら進めたい場面、PRのレビューでdiffを視覚的に確認しながらコメントを書く場面、あるいはSupermaven補完を活用して定型的なコードを高速に書き上げる場面でも、GUI統合型のCursor 3が自然な選択肢になります。
Claude Codeが向いているタスク
こちらも具体的なシナリオで説明します。
100ファイルにまたがるリファクタリング、たとえばモノレポ全体でのAPIレスポンス型の統一やエラーハンドリングパターンの刷新では、Claude Codeの100万トークンコンテキストウィンドウが決定的な差を生みます。プロジェクト全体の型定義、既存の呼び出し箇所、テストコードを一度にコンテキストに入れた上で、整合性のある変更計画を立てられます。数ファイルずつしか見えないツールでは、変更Aがファイル群Bに波及する影響を見落としがちです。
バグの原因調査も同様です。「本番環境で特定条件下のみ発生するレースコンディション」のような問題では、関連するミドルウェア、DB接続プール、キャッシュレイヤー、非同期処理のコードを横断的に読み解く必要があります。Claude Codeはこれらを一度に保持したまま仮説を立て、検証コードを書き、結果を解釈する反復を深く実行できます。
CI/CDパイプラインへの組み込みでは、claude -p "このPRの変更をレビューして" --output-format json | jq '.issues' のようにシェルパイプラインの一部として機能する合成可能性が活きます。マージ前の自動レビュー、テスト生成、ドキュメント更新チェックなど、人間が介在しないヘッドレス実行が求められる場面ではCLIアプローチ以外の選択肢がありません。
新規プロジェクトのスキャフォールドも得意分野です。CLAUDE.mdにプロジェクトの規約（ディレクトリ構造、命名規則、使用ライブラリ、テスト方針）を記述しておけば、それに準拠した初期コード生成をCLIから一発で実行できます。Hooksと組み合わせれば、コード生成後に自動でlintやテストを走らせる検証ループも構築できます。
併用フローの具体例
- 新機能の設計段階：Claude Codeでコードベース全体を読み込み、影響範囲を分析。アーキテクチャ方針を決定する
- 実装段階：Cursor 3のAgents Windowで複数エージェントを並列起動し、フロントエンド・バックエンド・テストを同時に進行させる
- レビュー段階：各エージェントの出力をCursor 3のAgent Tabsで横並び比較し、採用するコードを選択する
- CI統合：Claude Codeをパイプラインに組み込み、マージ前の自動レビューやテスト生成を実行する
このワークフローでは、Cursorの視覚的な管理能力とClaude Codeの深い推論能力が補完関係にあります。
Cursorが19%にとどまった理由
Pragmatic Engineerの調査で「最も好きなツール」としてCursorを選んだのは19%、Claude Codeの46%の半分以下でした。この差は何を反映しているのでしょうか。
第一に、エージェント型ツールへの需要シフトです。調査対象は中央値11〜15年の経験を持つシニアエンジニアで、単純な補完よりも自律的にタスクを完遂するツールを求めています。Claude Codeは2025年5月のリリースからわずか8ヶ月で最も使用されるAIコーディングツールに成長しており、ターミナルから直接操作できるシンプルさと、巨大なコンテキストウィンドウによる深い理解力がシニア層に支持されています。
第二に、IDE依存というロックインの問題です。CursorはVS Code系のUIに固定されるため、JetBrainsやVimのユーザーには選択肢に入りません。Claude CodeはCLIベースであるがゆえに、どのエディタとも併用できます。
第三に、Cursor 3のリリースタイミングです。調査が2026年3月時点で実施された一方、Cursor 3は4月2日リリースです。つまりAgents Windowという最大の差別化要素が調査に反映されていません。次回調査では数値が変動する可能性があります。
ただし、Cursorの事業規模自体は好調です。年間売上20億ドル、有料ユーザー100万人以上、Fortune 500の半数が導入という数字は、19%という「好感度」とは別の尺度で市場を捉えていることを示しています。「好き」と「使っている」は必ずしも一致しません。
まとめ
Cursor 3のVS Codeフォークからの脱却は、技術的負債の解消以上の意味を持っています。AIコーディングツールの主戦場が「コード補完」から「エージェント・オーケストレーション」へ移行したことへの構造的な対応です。
一方で、Claude CodeのCLIアプローチは「エディタに依存しない」「パイプラインに組み込める」「深いコンテキストで推論する」という独自の価値を提供しており、IDE統合型とは異なる軸で進化を続けています。Menlo VenturesのデータによればClaude Codeが市場の54%を占めている現状は、CLIファーストという設計判断の妥当性を裏付けています。
2026年4月現在、最も実用的な選択は二者択一ではなく、タスクの性質に応じた使い分けです。日常的な編集とマルチエージェント並列作業にはCursor 3、深い分析とCI/CD統合にはClaude Code。それぞれの設計思想を理解した上で組み合わせることが、現時点での最適解と言えます。
参考リンク
- Meet the new Cursor（Cursor公式ブログ）
- New Cursor Interface（Cursor Changelog）
- AI Tooling for Software Engineers in 2026（Pragmatic Engineer）
- Cursor 3 Launches AI Agents: Claude Code vs Codex Battle（byteiota）
- Cursor vs Claude Code vs GitHub Copilot 2026（NxCode）
- Cursor Launches Advanced AI Agent Experience（n1n.ai）
- Cursor AI Review 2026（NxCode）
- Claude Code overview（Anthropic公式ドキュメント）
- Cursor's $2 billion bet: The IDE is now a fallback（The New Stack）
- VS Code extension marketplace wars（DevClass）