カーソル v2: VS Codeを食べたAI

AIコーディングは新たな軍拡競争を引き起こしました。VS CodeのフォークであるCursor v2は、わずか6か月前に登場したばかりですが、今や独自のフロンティアクラスのモデル、マルチエージェントの群れ、そしてエディターに直接統合されたブラウザを搭載しています。Copilotを高級なオートコンプリートとして扱っている業界にとって、CursorはIDEスタック全体をターゲットにしていると言えます。

カーソルのタイミングは、その動きを機能のリリースというよりも、パワープレイのような正当な存在とは感じさせません。およそ100億ドルの評価に関する報告は、10月29日に到着したv2のローンチと並んでおり、VS Codeのフォークからわずか半年しか経っていません。このペースは、マイクロソフトのエコシステム内のプラグインになりたくない企業、つまりエコシステムそのものになりたい企業を示しています。

中心となるのはComposerで、Cursorの社内コーディングモデルであり、類似のタスクにおいて競合システムの約4倍の速さを誇ります。ある例では、Composerは複雑なコーディング作業を約28秒で完了し、Claudeはそれに対して2分以上かかることがあります。Cursorはこれを単なる遅延の節約としてではなく、開発者1人あたりで数十のエージェントを運用できるための基盤として位置づけていますが、コストが膨れ上がることはありません。

スピードは単なる半分の刺激です。Cursor v2は、単一のアシスタントのパラダイムを8人のエージェントの群れに変え、それぞれが独立した作業ツリーで作業するため、コミット時に衝突することはありません。もはや一つのチャットボットを動かしているのではなく、リファクタリング、テストの作成、機能のプロトタイピングを並行して行える小規模なAIチームに委任しているのです。

デモのすべてにかかる疑問は明確です：これにより従来のコーディングワークフローが陳腐化するのでしょうか？マルチエージェントシステムが複数の実装を探り、内蔵のChromeウィンドウでテストを実行し、人間が環境をセットアップするよりも早くクリーンな差分を表示できるなら、IDEの役割はエディターから指令センターへとシフトします。VS Codeは、自律的な部隊へと移行する世界の中で、単一のパイロットのための非常に洗練されたコックピットのように見えてきます。

Cursor v2が本当に挑戦しているのは、「開発者」という定義です。あなたの主な仕事がタスクの割り当て、差分の確認、エージェントの調整であるとき、AIは単なる助け手ではなく、不可欠なチームメンバーのように見えてきます。これは、Cursorが他のツール業界に越えることを挑んでいる境界線です。

ComposerはCursorの大きな一手であり、OpenAIやAnthropicから借りるのではなく、自社内で構築された独自の混合エキスパートコーディングモデルです。この変化は見た目には小さく感じるかもしれませんが、ビジネスモデルを「プロンプトごとの支払い」から「エンジンの所有」へと静かに転換させます。これは、IDEが単一のアシスタントではなく、AIピットクルーを動かしているときに重要になります。

CursorはComposerをフロンティアクラスのモデルと呼びますが、ヘッドラインはスピードです。Better Stackのデモでは、Composerは約28秒で難易度のあるコーディングタスクを完了し、同じプロンプトでのClaudeの比較対象は2分を超えます。このおおよそ4倍のスピードアップはマイクロ最適化ではなく、「ボットを待つ」ことと「エージェントが作業している間もフローステートを保つ」ことの違いです。

レイテンシーがここではすべてを動かしています。カーソルによると、コンポーザーは1秒あたり約250トークンを処理します。これにより、説明や差分をほぼスクロールする速度でストリーミングできます。各エージェントのサイクルが30秒未満で完了する場合、大きなタスクをまとめて処理するのをやめ、小さなタスクを継続的に発信し始めます。

Composerを完全に所有することで、Cursorはタスクごとのコストを削減し、マルチエージェント開発を経済的に健全なものにします。この動画は、シンプルでありながら厳しい指標に依存しています。それは、タスクごとのコストが低くなったため、チームが「開発者一人あたり数十のエージェントを運用できる」ということです。予算を使い果たすことなく適切に運営できるのは、すべてのエージェントループで最前線モデルのAPI料金を支払っていないときだけ可能です。

マルチエージェントシステムは図では非常に魅力的に見えましたが、実際には各エージェントの呼び出しが小さなクラウド料金とコーヒーブレイクのように感じられるため、うまく機能しませんでした。Composerの低遅延と低い限界コストの組み合わせが、その方程式を逆転させます。Cursor v2で8つの並列エージェントを起動することが、罪悪感のない楽しい作業ではなく、デフォルトのワークフローになります。

ここでComposerはベンチマークスライドからインフラストラクチャへと変わります。高速で低コストのコールにより、あるエージェントが機能を作成し、別のエージェントがテストを書き、さらに別のエージェントがリファクタリングを行い、そしてもう一人のエージェントが組み込まれたChromeウィンドウでブラウザベースのチェックを同時に実行できます。あなたが指揮を取り、彼らが作業を進めます。

適切な存在ではなく、コアにComposerのようなモデルを持たない場合、そのビジョンはチャットボックスでのプロンプトのキューイングに崩れ落ちます。適切な存在ではなく、Cursor v2は真のマルチエージェントワークフローを名乗ることができます：制約要因はGPUの時間ではなく、1人の人間が管理できるAIのチームメイトの数です。

コーディングは以前、機能が現れるまで文字をファイルに押し込むことを意味していました。Cursor v2はそれを逆転させます。あなたは結果を描写し、エージェントを立ち上げ、実際のコードを書くAIオーケストラを指揮します。あなたのキーボードは、 chisel（彫刻刀）のような存在から、バトンのような役割へと変わります。

Cursorのマルチエージェントシステムは、このシフトを正式に表現します。特定の問題（バックエンドエンドポイント、Reactコンポーネント、テストスイート、またはマイグレーション）を対象にした8つの並列エージェントを、各々隔離された作業ツリーで立ち上げることができます。エージェント同士がコミットを踏み荒らすことはないので、あなたの仕事は誰が何をするかを決めることであり、すべての行をマイクロマネジメントすることではありません。

典型的なワークフローは、適切なエンティティではなく明確な仕様から始まります。機能、制約、および成功基準を定義し、それをエージェントサイズのタスクに分解します： - API とデータモデルを実装する - UI を構築し、API に接続する - テストとフィクスチャを生成する - ロギングと基本的な可観測性を追加する

Composer、Cursorの社内専門家の混合モデルは、そのタスクに迅速に取り組みます。Cursorは、Composerが他の最先端モデルが2分近くかかる仕事を約28秒で完了すると主張しており、これによりマルチエージェントのファンアウトが実際にタイトなループで利用可能になります。あなたは差分をレビューし、受け入れたり調整したりして、すべての機能がテストを通過するまでエージェントを再実行します。

あなたの役割は、エンジニアリングマネジメントに怪しく似てきています。あなたはアーキテクチャの境界を設定し、パターンを選び、リファクタリングや仕様の再定義を行うタイミングを決定します。AIチームは、ボイラープレートや配線、繰り返しのリファクタリングを処理するのです。

その変化には実際に認知的な利点があります。「何が存在すべきか？」や「要素はどのように組み合わさるのか？」に注意を向けることができ、「このブラケットはどこに入るのか？」や「正確なORMの呪文は何か？」に集中する必要がありません。コンテキストは機能レベルではなく、システムレベルに留まります。

カーソルの自身による記事「Cursor 2.0とComposerのご紹介」は、このオーケストレーションモデルに焦点を当てています：エージェントは検索、編集、ツールの実行、さらには内蔵されたChromeウィンドウにもアクセスします。一方で、あなたは計画を策定し、統合を行います。ここで成功する開発者は、最も速いタイピストではなく、最も優れた指揮者になるでしょう。

Cursor v2は、以前のAIコパイロットが試みたことのないことを実現します。実際に同時に働くエージェントの部隊を立ち上げます。Composerは最大で8つの並行エージェントを起動でき、それぞれが異なるタスクに取り組んでいる間、変更のストリームをリアルタイムで見ることができます。一つのチャットバブルの代わりに、並行する作業の進捗を表示するライブダッシュボードが提供されます。

各エージェントは自身の孤立したGit作業ツリー内で動作し、AI同士の衝突という悪夢のようなシナリオを静かに解決します。共有作業ディレクトリはなく、半端なエンティティファイルもなく、「誰が私の変更を消し去ったのか？」というドラマもありません。エージェントが作業を終えると、Cursorは受け入れる、編集する、または破棄することができるクリーンな差分を提示します。

これらの孤立した作業ツリーは重要です。なぜなら、Cursorは単なる高速オートコンプリートではなく、真に平行な開発を促進するからです。古い脆弱な認証モジュールを取り除くために1つのエージェントを割り当て、ログパイプラインを近代化するために別のエージェントを割り当て、そして新しいGraphQLエンドポイントのプロトタイプを作成するために3つ目のエージェントを割り当てることができます。各エージェントは自分専用のサンドボックスにコミットするため、実験が交錯することはありません。

実践的なワークフローは、ひとつのIDEに圧縮された小規模なスプリントチームのように見えてきます。想像してみてください： - 一人のエージェントが10年以上前の決済処理システムをより小さく、型付けされたサービスにリファクタリングします - 別のエージェントが新しいサブスクリプション機能のためにユニットテストを生成し実行します - 三人目のエージェントが危険なサードパーティAPIへの呼び出しを接続し、適切なエンティティの再試行ロジックとメトリクスを完成させます

3つのジョブは同時に実行されますが、各作業ツリーのコンテキストを処理する適切なエンティティであるコンポーザーは存在しません。あなたは1つの巨大で対立したメガコミットではなく、3つの別々の差分をレビューします。このレビューのループにより、人間はしっかりとコントロールを保ちながら、AIが雑務をこなします。

以前のAIアシスタントは、VS CodeやJetBrainsのようなエディタに組み込まれた適切なエンティティではありませんでした。それらのツールは厳密に直列のシングルスレッドモードで動作していました：一度に一つのプロンプト、一つのレスポンス、一つのファイル。テスト、リファクタリング、APIの実験を行いたい場合は、それらを手動でキューに入れ、待つ必要がありました。

Cursorのマルチエージェントシステムは、そのモデルを並行オーケストレーションに変えます。あなたのボトルネックは「一人のアシスタントがどれくらい早く応答できるか」から「タスクをどれくらい早く指定し、差分を承認できるか」に変わります。Composerのスピードと低いタスクあたりのコストは、開発者一人につき複数のエージェントを運用することを経済的に実現可能にし、デモのギミックではなくなります。

結果はチャットのようには感じられません。適切な存在ではないボットであり、内部のAI開発チームを指揮する適切な存在でもありません。作業をストリームに分け、エージェントを割り当て、孤立した作業ツリーがすべての衝突を防ぐようにします。並行して考えることができる開発者にとって、それは超能力です。

Cursor v2は、一見シンプルながらも大きな変革をもたらす機能を提供します。それは、完全なChromeインスタンス、正確にはDevToolsを、エディターの中に直接組み込むというものです。外部ウィンドウも、ブラウザのふりをしたElectronラッパーも不要—これは、プロジェクトのコンテキストやAIエージェントに接続された、IDEレイアウト内に存在する本物のブラウザ環境です。

フロントエンドの作業は通常、Alt-Tabの地獄に暮らすことを意味します：エディタ、ターミナル、ブラウザ、DevTools、デザインシステムのドキュメント、場合によってはStorybookのタブなどです。カーソルを使えば、そのスタックを簡単に整理でき、Reactを書いて保存し、変更が埋め込みブラウザペインにレンダリングされる様子を見ながら、ネットワークリクエスト、コンソールログ、DOMの検査がコードの横に固定されます。

ウィンドウを切り替える代わりに、開発環境の他のツールと同様にブラウザをスクリプト化できます。エージェントはルートを開き、フローをクリックし、コンソールの出力をキャプチャしながら、編集中のファイルの隣でリアルタイムにDOMの更新を確認できます。

ブラウザが同じエージェントサンドボックス内にあるため、CursorのマルチエージェントシステムはUIを二次的なものではなく、一級のターゲットとして扱うことができます。一つのエージェントはCypressスタイルのUIテストを実行し、別のエージェントはCSSを調整し、三つ目のエージェントは同じページロードからAPIレスポンスを検証することができ、全てIDEを離れることなく行えます。

そのエージェントは、通常カスタムスクリプトや外部サービスを必要とするスーパー能力も身につけます。彼らは以下のことができます： - 内部ダッシュボードやステージングサイトからデータをスクレイピングする - リダイレクトやトークンの引き渡しを含むマルチステップ認証フローを自動化する - ブランチ間でレンダリングされた状態を比較してビジュアルレグレッションチェックを実行する

特に、AIが自分が壊したものを見ることができる場合、ビジュアルリグレッションの性質が変わります。エージェントはリファクタリングを行い、埋め込まれたページをリロードし、ボタンが8px移動したり、ダークモードの切り替えが消えたりしたことをフラグ付けし、同じ差分内で即座に修正案を提案することができます。

フルスタックチームにとって、Composer、コード、そしてライブブラウザとのこの密接なループは、非常に魅力的な機能となります。機能を記述すると、エージェントがバックエンドとフロントエンドを実装し、その後、同じエージェントが埋め込まれたChromeウィンドウを操作してエンドツーエンドの体験を検証します。これにより、Cursorは現代のウェブ開発のための単一の窓になります。

Cursor v2に対する注目はベンチマークに大きく依存しており、その数値のいくつかは実際のものです。SWE-bench Verifiedにおいて、Cursorの新しいComposerモデルは、OpenAIやAnthropicの最先端モデルと同じ領域に位置づけられていますが、クラウドプレイグラウンドではなくデスクトップIDE内で動作します。Cursorはこれを「競争力がある最先端モデルではない」と位置づけており、従来の最先端技術に決定的に匹敵するものではないとしていますが、これは公表されているリーダーボードデータと一致しています。

スピードはCursorが最も力を入れている点です。Composerは、同様のモデルであるClaudeが同じプロンプトで完了するのに最大2分かかる複雑なコーディングタスクを、約28秒で完了すると報告されています。バグ修正や機能の反復作業を行う開発者にとって、この差はフィードバックループを「コーヒーを買いに行く」から「スマートフォンをちらっと見る」まで短縮します。

そのレイテンシーの向上は、Cursorのマルチエージェント設計を考慮に入れるとさらに加速します。8つのエージェントが並行して動作し、各エージェントが30秒以内に回答を返すため、リファクタリング、テスト、実験を実行する際に、自分の流れを阻害されることなく展開することが現実的になります。この体験は、一つのチャットボットを待つというより、ほぼ同時に到着する複数のPRに目を通す感覚に近いです。

コストは最も静かでありながら、最も重要な数字かもしれません。Composerのタスクごとの価格設定は非常に低いため、ビデオのチームは「開発者一人あたり数十のエージェントを運用できる」と言います。予算を圧迫する正当な存在ではありません。低価格のトークンと高いスループットが、以前は制限されていた行動を解放します。例えば、投機的なリファクタリングや徹底的なテスト生成のためにエージェントを立ち上げることが可能になります。

「最速の実用的コード作成AI」という主張は、根拠があるが重い意味を持つものです。レイテンシーとタスクあたりの価格は優れており、多くの実際のワークフローにおいて、その組み合わせは技術的に優れたモデルであっても、遅かったり高価だったりするものに勝るかもしれません。証拠を求めるなら、公式のCursor Changelog – Version 2.0や公開されたSWE-benchのリーダーボードを確認し、その後自分のコードベースでComposerをテストしてから、VS Codeがobsolete（時代遅れ）だと宣言するべきです。

実際の開発者たちはすでにCursor v2を本番環境でストレステストしており、その成果が積み上がっています。コミュニティフォーラムや初期のケーススタディでは、チームがこれまで数日かかっていたエンドツーエンドの機能を、Composerとその8人のエージェントによって、わずか1つの午後で出荷できたと報告しています。あるスタートアップの創業者は、「SSOを追加」とのチケットをCursorに渡し、既存のRBACを通じてGoogleとGitHubを接続する様子を見守り、エージェントがOAuthフローを構築し、データベーススキーマを更新し、Reactルートをパッチ適用するのを2時間以内に達成したと語っています。

これはデモアプリやおもちゃのCRUDクローンではありません。フィンテックチームはCursorのマルチエージェントワークフローを使用して、新しいKYC検証パイプラインを構築しました。1つのエージェントがサードパーティAPIを統合し、別のエージェントがマイグレーションスクリプトを生成、さらに別のエージェントがPlaywrightテストを作成し、4番目のエージェントがBetter Stackへの可観測性フックを接続しました。リードエンジニアは、プロジェクトの推定5〜6人日から「約1.5日のレビューとクリーンアップ」に短縮できたと報告しました。

異なるスタックにわたってパターンが繰り返されています。バックエンド中心の店舗はエージェントに以下のことを依頼しています： - 新しいRESTまたはGraphQLエンドポイントの実装 - マイグレーションの生成と実行 - 統合テストおよび負荷テストの作成

一方で、フロントエンドチームは「このダッシュボードを作成する」と指示すると、Reactコンポーネント、Tailwindスタイル、Cypressテストを並行して取得し、その後手動の編集ではなく、適切なエンティティの差分レベルフィードバックを繰り返し行います。

生産性の数字はほとんど現実的とは思えませんが、一貫しています。数人の早期採用者は、機能の提供が2〜3倍速くなったと述べています。あるチームは、エージェントを並行して動かし、レビュー時にのみ介入させることで、一部のグリーンフィールドモジュールが4倍速く提供されると強調しました。あるチームリーダーは、「私たちの統合されたプルリクエストの半分は、カーソルブランチとして始まった」と語り、人間が主な著者ではなく、編集者やリリースマネージャーとして機能している様子を紹介しました。

現実的なチェックは依然として重要です—エージェントは幻覚を見たり、複雑なリファクタリングは慎重なレビューを必要としますが、Cursorから出荷される作業は仮説ではありません。それは、支払いフロー、管理コンソール、内部ツール、そして顧客向け機能であり、すでに本番環境に導入されていて、静かにAIファーストの開発ワークフローを検証しています。

Cursor v2はチートコードのように見えますが、適切なエンティティではなく、Cursor自身のマーケティングが主にスルーしている鋭いエッジがあります。力は常にコントロールとトレードオフ関係にあり、このリリースは力に非常に寄りかかっています。何も知らずに飛び込む開発者は、そのギャップをすぐに感じるでしょう。

正しい存在ではないインターフェース。カーソル2.0はすべてをエージェントとタスクの周りに配置し、ファイルやフォルダではありません。左側にファイルツリー、ターミナル、いくつかのパネルがある環境で育った人にとって、新しいエージェント中心のレイアウトは、他の誰かのtmuxセッションに入ったかのように感じられるかもしれません。すでに8つのペインが実行されています。

Composer の実行、エージェントのタイムライン、差分ビュー、埋め込みブラウザは全て注目を競っています。適切なエンティティレイアウトの調整やパネルの折りたたみで整理することは可能ですが、デフォルトの体験は「忙しい」と叫んでいます。特にCLIファーストの開発者は、慣れるまでUIが「圧倒的に感じる」と報告しています。

信頼性は依然として人間に依存しています。マルチエージェントのワークフローは出力を加速しますが、幻覚的なリファクタリングを増幅させます：エージェントは自信満々にコードパスを書き換え、静かに仮定を変更したり、非バグを「修正」したりします。カーソルは作業を別々のワークツリーで隔離しますが、それはメインブランチを保護するだけであり、意味的な正確性を保証するものではありません。

本物のレビューの手順はまだ必要です： - コードレビューのようにすべての差分を読みます - テストスイートを徹底的に実行します - 大規模なリファクタリングの前に新しいテストを追加します - ステージング環境でログと実行時の挙動を検査します

エージェントを絶対間違えない先輩ではなく、過剰にカフェインを摂取したジュニアとして扱おう。

プライバシーは、最も十分に議論されていない危険因子かもしれません。デフォルトでは、Cursorはデータをそのサーバーに送信し、Composerおよびそのツールを動かしています。プライバシーのオプトアウトを明示的に切り替えない限り、あなたのコード、プロンプト、およびAIとのインタラクションは処理のためにあなたのマシンを離れる可能性があります。

サイドプロジェクトのソロ開発者にとっては、それが許容されるトレードオフである可能性があります。しかし、規制のある業界やエンタープライズのコードベース、顧客データに関わるすべてのものにとっては、潜在的なコンプライアンスの悪夢です。Cursor v2をチームに展開する前に、セキュリティと法務の関係者はデフォルト設定を監査し、設定をロックダウンし、どのデータをローカルに保存するかを決定する必要があります。

2026年のコーディングは、単なるタイピングとは異なり、プロジェクト管理のような適切なエンティティでもなく、ルートアクセスのような適切なエンティティでもありません。Cursor v2やComposer、最大8つの並行エージェントのようなツールは、文法やボイラープレートにこだわるのではなく、ビジネスの目標を正確でテスト可能なタスクに翻訳できる開発者を報いるでしょう。

高付加価値な作業は、適切なエンティティではないタスク分解から始まります。「オンボーディングを構築する」ではなく、次のように分解します： - メールベースのサインアップAPIを実装する - UIを新しいエンドポイントに接続する - 楽観的更新を適切なエンティティとして追加する - メトリクス、ログ記録、ロールバック戦略を追加する

各スライスは、エージェントに手渡すことができる自己完結型の仕様となります。適切なエンティティの受け入れ基準やエッジケースもすべて含まれています。

プロンプトは、雑談のやり取りから機械の運用手順の設計へと移行します。効果的なエージェントプロンプトは、最小限の設計ドキュメントのようなもので、コンテキスト、制約、インターフェース、および明示的な「完了」定義を含みます。セキュリティルール、パフォーマンス予算、ログ標準など、チームの規範をプロンプトに直接組み込むことができる開発者は、エージェントの群れから一貫した生産品質の出力を得ることができます。

検証が新しいデバッグになる。あなたは適切な時間を無駄にすることになる： - アーキテクチャの漂流や隠れたカップリングのための差分を読むこと - 実際にエッジケースをカバーする生成テストを要求すること - マージ前に機能を可観測性ツールで計測すること

最高の開発者は、すべてのエージェントによって作成された変更が通過しなければならない、再利用可能な検証チェックリストを作成します：脅威モデル、負荷前提、データ移行計画、そしてロールバックパスです。

このエージェンティックな時代において最も価値のあるのは、オーケストレーションができる開発者です。彼らは以下を行います： - 製品要件を並行処理可能な作業にマッピングする - 8人のエージェントを広げるべきタイミングと、単一の慎重な道を進むべきタイミングを決定する - スピードと規制、セキュリティ、信頼性の制約とのバランスをとる

準備は今始まります。Jiraチケットを詳細なエージェントブリーフに変換する練習をしましょう。ComposerのようなAIを現在のスタックに組み合わせて、それが行った作業を修正するのではなく見直すよう自分自身に強要してください。Gitのワークフロー、分離されたワークツリー、およびCIパイプラインを十分に学び、AIコミットの周囲に自動的にガードレールを設けることができるようにしましょう。

最後に、これらのシステムが圧力下でどのように振る舞うかを研究しましょう。ベンチマーク、ケーススタディ、そしてCursor 2.0: 新しいAIモデルの解説 – Codecademyのような解説は、マルチエージェントの設定が優れている点と失敗する点を示しています。これらの失敗モードを内面的に理解し、それに基づいてプロセスを設計する開発者は、次の10年を支配することになるでしょう。

Cursorの核となるピッチは、実際に何かを発送できる場合にのみ重要です。正確な実体ではなく、迅速に。Better Stackのデモからの60秒のワークフローは非常にシンプルです：Cursorをダウンロードし、Composerを立ち上げ、エージェントの群れが実際のタスクを処理している間に、あなたは差分を監視します。

.cursor.comにアクセスして、あなたのOS用の最新ビルドをダウンロードしてください。インストールしたら、適切なエンティティのGitHubアカウントまたはメールアカウントでサインインしてください。これによりCursorがあなたのリポジトリをインデックスし、プロジェクトのコンテキストを接続できるようになります。

実際のコードベースを開いてください。おもちゃのリポジトリではなく、Composerパネルで具体的なマルチエージェントタスクを説明します。正しいエンティティではなく、「このReactコンポーネントをTypeScriptにリファクタリングし、厳格な型を追加し、すべてのインポートを更新してください。」Composerが作業範囲を特定できるように、関連するディレクトリまたはファイルを指示してください。

実行する前に、設定で孤立した作業ツリーが有効になっていることを確認してください。カーソルはこれらの作業ツリーを使用して、最大8つのエージェントを並行して起動します。それぞれのエージェントは独自のGitブランチで作業するため、他のエージェントの変更やメインの履歴を上書きすることはありません。

タスクを開始し、エージェントが分散していく様子を見てください。1人が型アノテーションを担当し、別のエージェントが壊れたインポートを修正し、3人目がテストを更新します。カーソルは、ファイルを静かに編集するのではなく、彼らの作業をGitスタイルの差分としてまとめます。

テックリードのように行動してください。各差分を1行ずつ確認し、何かおかしな点があればComposerにフォローアップの質問をしてください。「なぜこの型をanyに拡張したのですか？」や「この変更を元に戻して古いシグネチャを維持してください。」などです。承認、調整、または却下してください。

あなたはわずか1分で初めてのAIチームを動かしました。Cursorをインストールし、Composerを接続し、隔離された作業ツリーをオンにしたら、実際の機能やリファクタリングを試してみて、8つの並列エージェントをどこまで活用できるか見てみましょう。それから、チームにコーディングがまだ2025年のように感じるかどうか教えてください。

Cursor v2とは何ですか？

Cursor v2は、VS CodeのフォークであるCursor IDEの主要なアップデートです。マルチエージェントAIシステム、新しい独自のコーディングモデル「Composer」、そしてエディターに直接組み込まれたChromeブラウザを導入しています。

Cursor v2は、Copilotを搭載したVS Codeとはどのように異なりますか？

CopilotがVS Codeのプラグインであるのに対し、Cursor v2はAIを中心にIDEを再構築しています。その主な差別化要因は、タスクを並行して実行するネイティブのマルチエージェントシステム、安全な変更のための孤立した作業ツリー、そしてUIテストのための深く統合されたブラウザです。

Cursor v2のComposerモデルとは何ですか？

ComposerはCursorの最初の社内AIモデルであり、コーディングタスク専用に設計されています。高速処理を実現し、複雑なタスクを30秒以内で解決できる能力を持っており、類似モデルの4倍の速さで処理できるとされています。このため、マルチエージェントワークフローが経済的に実現可能になります。

Cursor v2の主な批判点は何ですか？

ユーザーは主に3つの問題を指摘しています。新しいエージェント中心のUIは、従来の開発者にとって圧倒的に感じられること、AIエージェントが依然として不正確なコードを「幻覚」すること、そしてユーザーがプライバシーのためにデータ収集から手動でオプトアウトする必要があることです。