Cursor 2.0で8つのAIエージェントが並列稼働 - Composerモデルの裏側
参照元
Introducing Cursor 2.0 and Composer - Cursor公式ブログ
Composer: Building a fast frontier model with RL - Cursor
Hacker Newsで賛否両論、4倍速を謳うComposerの実力
Cursor 2.0が10月29日にリリースされました。Hacker Newsのスレッドを見ると、注目度は高いものの、コメント欄の反応が興味深いです。「製品を壊している」「安定性を犠牲にしすぎ」という批判と、「革新的」という賞賛が入り混じっています。
で、何がそんなに話題なのか。一言で言うと、AIコーディングエージェントを8つ並列実行できるようになったことと、独自開発のComposerモデルが既存モデルの4倍速を謳っている点です。
Composerの訓練方法が従来と根本的に違う
Composerモデルの技術ブログを読んで驚いたんですけど、訓練方法が通常のLLMと全く異なるんです。
通常のLLMは静的なデータセットで訓練されますが、Composerは実際の開発環境内で強化学習を実施しています。つまり、read file、edit file、codebase search、lint collection、terminal command executionなど、約10個の本番環境ツールにアクセスできる状態で訓練されているということです。
これ、前にChatGPT使ってコード生成したときに、「動かないコードを出力されて手直しに時間かかった」経験があるんですけど、Composerはそもそも実環境で動作確認しながら学習してるから、そういう齟齬が減るのかもしれません。まだ試してないので推測ですが。
Mixture-of-Experts + MXFP8量子化カーネル
アーキテクチャはMixture-of-Experts (MoE)を採用していて、カスタムMXFP8量子化カーネルで訓練されています。んで、ここで気になるのが、ベースモデルが何なのか明記されていない点です。
Cursor研究者のSasha RushがHacker Newsで質問に答えているんですが、ベースモデルについての質問には明確に答えていません。「Cursor is an outlier in sharing so little when proposing a new benchmark」というコメントもあって、透明性に関しては議論の余地がありそうです。
Git Worktreeで並列エージェントを実現
8つのエージェントを並列実行できる仕組み、これはGit Worktreeを使っているそうです。
Gitの「worktree」は、同じリポジトリに複数の作業ディレクトリを持たせる機能です。各worktreeは独立したworking directory、index、HEADを持ちますが、オブジェクトデータベースは共有されています。
つまり、各エージェントが独立したブランチ・独立したファイル編集環境を持つことで、8つのエージェントが同時に動いてもファイル衝突が起きないわけです。で、これってスケーリング時にサーバー負荷が心配なんですけど、そのあたりの実装詳細は公開されていません。
ネイティブブラウザ統合 - Chrome DevToolsで自動テスト
もう一つ、Cursor 2.0で追加されたのがネイティブブラウザ統合です。Chrome DevToolsが統合されていて、AIエージェントが自分の出力をブラウザでテストして、DOM inspectionやデバッグを自動で実行できます。
前にフロントエンド実装して、ブラウザで確認して、修正して...を繰り返すのが面倒だった経験があるんですけど、この機能があれば、エージェントが勝手にテストして修正を繰り返してくれるんですね。ただし、これも「本当に正確にテストできるのか」は実際に使ってみないと分かりません。
30秒で完了、は本当か？
公式ブログでは「most turns in under 30 seconds」と書かれています。ほとんどのタスクが30秒以内で完了する、と。
んで、これは「ほとんど」がどの程度の割合なのか、どのサイズのコードベースなのか、が重要です。前に別のAIコーディングツールで「高速」と謳われていたものが、実際のプロジェクトだと全然遅かった経験があるので、ベンチマーク環境と実環境の差が気になります。
公式のベンチマークでは「frontier coding results」を達成しているそうですが、具体的な数値やベンチマーク内容の詳細が少ない点は、Hacker Newsでも指摘されています。
安定性の懸念 - フォーラムで報告される問題
Cursor Community Forumを見ると、「Performance Degradation and AI Editing Issues」というスレッドがあって、AIとの会話ラウンドが増えるとIDEが重くなる、フリーズする、クラッシュする、という報告があります。
あと、状態管理（ロールバック機能）が「a bit buggy」で、「mass-reapply after a rollback」が実装されていない、というHacker Newsのコメントもありました。
で、これはエンタープライズ環境では致命的かもしれません。大規模コードベースで安定性が求められるチームにとって、現時点のCursor 2.0は慎重に評価すべき段階にあると思います。
エージェント中心設計への転換
Cursor 2.0の設計思想として、「ファイル中心」から「エージェント中心」への転換があります。従来のIDEはファイルベースでしたが、Cursor 2.0では複数のAIエージェントを管理する前提の設計になっています。
これ、慣れるまで時間かかりそうですけど、慣れたら確かに効率的かもしれません。ただ、「Developer to Delegator」（開発者から委譲者へ）というキャッチフレーズを見ると、将来的にはエンジニアの役割が大きく変わっていくのかな、という感じもします。
透明性とセキュリティの課題
セキュリティ面では、過去にprompt injection攻撃、malicious MCP file swaps、malicious npm packagesなど、複数の脆弱性が報告されています。これらは修正されているそうですが、新機能追加のスピードを考えると、今後も同様の問題が出る可能性はあります。
あと、Cursor AI supportボットが自社ポリシーをハルシネーション（幻覚）した事件もあって、ユーザーが間違った情報を信じて解約したケースも報告されています。
スタートアップの実験場として
現時点のCursor 2.0は、「安定した本番環境向け」というより、「実験的なスタートアップ・個人開発向け」という印象です。4倍速のComposerモデル、8つの並列エージェント、ネイティブブラウザ統合、どれも魅力的ですが、安定性やドキュメントの透明性には課題が残っています。
そういえば、Cursor研究者が「sharing so little」と指摘されている点、これはオープンソースコミュニティとしては気になるところですね。ベースモデルの詳細、訓練データの規模、ベンチマーク環境の詳細など、もう少し情報があると評価しやすいんですが。
まだ試してないので、実際の使用感はレビュー記事を待つしかないですね。ただ、AIコーディングツールの進化速度を考えると、数ヶ月後には状況が大きく変わっている可能性もあります。
Discussion