Cursor Composerの衝撃: 「速さ」がすべてを解決する

Cheetahプロトタイプと、本番環境を模倣したRL学習の裏側
AI
LLM
Author

Junichiro Iwasawa

Published

November 11, 2025

Cursorが新たなコーディングモデル「Composer」を発表し、AIコーディング界隈がにわかに活気づいている。

CursorのAI研究者であるSasha Rush氏の講演公式のアナウンスによれば、Composerは「フロンティア級の知性」と「同等モデルの4倍」という圧倒的な速度を両立させたエージェント型LLMであるという。

単なる高速なモデル、あるいは既存モデルの焼き直しと侮ってはいけない。なぜCursorが自社モデル開発に踏み切ったのか。その裏には、Sasha Rush氏が語った「Cheetah」というプロトタイプの存在と、「本番環境を徹底的に模倣する」というユニークな強化学習(RL)戦略が隠されている。本稿では、この2点に焦点を当ててComposerの本質を分析する。

なぜ「速さ」が重要なのか? Cheetahの教訓

Cursorはなぜ、すでに強力なGPT-4oやClaude 3.5 Sonnetなどが存在する中で、あえて自社モデルの開発という茨の道を選んだのか。

その答えは、Cursorで最も人気のある機能の一つ「Cursor Tab」(高速なコード補完)の成功体験にある。Sasha Rush氏は、この機能から「開発者が本当に求めているのは、対話的な使用に耐えうる、最もスマートなモデルである」というインサイトを得たと語る。AIが瞬時に応答することで、開発者は思考の連鎖(chain of thought)を維持し、いわゆる「フロー状態」に留まることができる。

この仮説を検証するため、彼らは「Cheetah」という高速なエージェントモデルのプロトタイプを開発し、アプリ内でリリースした。知性(賢さ)はそこそこだったが、とにかく「速さ」に焦点を当てたモデルだ。

このモデルを使ったユーザーからのフィードバックは強烈だった。「これは何かが違う」「まるでエイリアンの技術のようだ」といった声が寄せられた。

この”Cheetah”の成功が、Cursorチームの確信を強める。コーディングエージェントにおいて、「速さ」は単なる快適さ(nice-to-have)ではなく、ユーザー体験の根幹を成す価値(value)である、と。

エージェントを起動し、その間にTwitterをチェックし、結果が返ってきた頃にエディタに戻る…といった従来の体験では、開発者のフローは断ち切られてしまう。Composerの開発目標は、Cheetahが証明した「圧倒的な効率性(速さ)」を維持したまま、フロンティア級の「知性」を注入することに定められた。

Composerを賢く、速くした「本番環境RL」

では、その「知性」と「速さ」をどう両立させたのか。ComposerはMoE(Mixture-of-Experts)アーキテクチャを採用しているが、その真髄は学習方法にある。

Composerは、強化学習(RL)によって徹底的に鍛え上げられた。ここがSasha Rush氏のトークで最も興味深い点なのだが、Cursorは**「RL学習環境と、本番のCursor製品環境を可能な限り近づける」**というアプローチを取った。

私たちの目標は、本番のCursor製品を通じてトレーニングを行うことでした。RLにおいても、本番の製品とできるだけ近いプロセスを模倣したかったのです。(Sasha Rush氏の講演より)

これは単なるシミュレーションではない。Cursorにはもともと「Cloud Agents」という、ユーザー環境のVM(仮想マシン)をクラウド上にスピンアップし、オフラインでエージェントを動かす機能があった。Cursor開発チームは、なんとこの本番用インフラをそのままRLの学習環境に転用したのだ。

この戦略がもたらすメリットは計り知れない。

  1. 実環境でのツール習熟: 学習中のComposerエージェントは、模擬的なファイルシステムやAPIを叩くのではない。本物のmicroVM内で、本物のターミナルコマンドを実行し、ファイルを編集し、リンターを走らせ、Cursor独自のセマンティック検索(コードベース全体の意味検索)ツールを使う。これにより、ComposerはCursor環境の「パワーユーザー」として訓練される。
  2. 「真の速度」の最適化: RLの報酬設計において、「並列でのツール呼び出し(parallel tool calling)」が強くインセンティブ付けされた。トークン生成速度が速いだけでは意味がない。エージェントが複数のツール(例:ファイル検索とターミナル実行)を同時に呼び出すことを学べば、ユーザーが結果を得るまでの総時間(end-to-end user experience)が劇的に短縮される。Composerが賢く並列処理を行うのは、このRLのおかげである。
  3. インフラの合理性: このRLの学習プロセスは、膨大な数の環境を同時に実行する必要があり、極めて「バースト的(bursty)」な負荷がかかる。Sasha Rush氏も「RLの難しさの多くはインフラ開発にある」と認めている。しかし、Cursorは本番のCloud Agents用インフラを適応させることで、この問題をクリアした。RLと本番環境がシームレスに統合されたのだ。

さらに、彼らはMXFP8という低精度フォーマットを活用したカスタムカーネルを開発。これによりトレーニングを高速化し、さらに学習後の量子化(quantization)が不要になった。つまり、トレーニング時の速度がそのまま本番の推論速度に直結している。このインフラレベルでの速度への執着も、Composerの強さの秘訣だろう。

結論:専門領域に特化するモデルの未来

Sasha Rush氏の講演は、RLが「特定のカスタマイズされた領域において、非常にスマートな特化型モデルを構築するために非常に優れている」という示唆で締めくくられた。

Composerの登場は、汎用的な超知能モデルとは異なる、もう一つのAIの進化の道筋を示している。それは、特定のアプリケーション(この場合はCursor IDE)と、そのインフラに深く統合され、その環境で「最速の体験」を提供することに特化したモデルだ。

CursorがCheetahプロトタイプで得た「速さこそが価値」という確信と、それを「本番環境RL」というエンジニアリングの力技で実現したプロセスは、他の多くの開発ツールにも影響を与えるに違いない。Composerが(Sasha Rush氏の言葉を借りれば)「異なる種類のコーディング」体験を我々にもたらしてくれることを期待したい。