Cursor Composer 2.5とは？ Directed RL、25倍の合成データ、そしてより賢いコーディングエージェント

要約：これは単なる「少し賢くなったモデル」ではない

元の記事で最も有用なのは、Composer 2.5 を曖昧なアップグレードとして説明していない点です。むしろ、トレーニングとプロダクトに関するレポートのように扱っています。

それが重要なのは、本当のポイントが次の点にあるからです。

Composer 2.5 が改善したのは、ベースとなるチェックポイントのおかげだけではなく、Cursor がトレーニング手法、データ規模、オプティマイザのエンジニアリング、そしてプロダクト形態を同時に推し進めたからです。

これは「モデルが良くなった」という主張よりも、はるかに興味深い主張です。

Composer 2.5 の実態

記事は冒頭で明確に述べています。

Composer 2.5 は現在 Cursor で利用可能です。

また、これは完全に新しいベースモデルではないことも強調しています。Composer 2.5 は、Composer 2 と同じオープンなチェックポイントファミリー、すなわち Moonshot の Kimi K2.5 を基盤にしています。

したがって、重要な問いは次のようになります。

強力なオープンチェックポイントの上で、Cursor はエージェント型のコーディングワークフローをどこまで押し広げられるのか。

アップグレードのマトリクスは、長時間タスク、信頼性、コラボレーションに焦点を当てている

記事の最初の主要な表では、Composer 2 と 2.5 を比較しています。

重要なのは、個々のパーセンテージではありません。重要なのは、カテゴリの性質です。

• 長時間実行されるタスク

• 複雑な指示

• コラボレーションの円滑さ

• スタイルの一貫性

• 回復時の振る舞い

これは Cursor が Composer を、単なる素早いコード補完ツールではなく、長く頼れるチームメイトのように感じられるものにしようとしているということです。

最初の技術的飛躍：テキストフィードバックを用いた指向型RL

この記事の最初の深い技術セクションは、テキストフィードバックを用いた指向型RLについてです。

それが解決しようとしている問題はおなじみのものです。ロールアウトが非常に長くなると、従来のRLにおける信用割り当てが複雑になります。

モデルは全体的な結果が良かったか悪かったかは分かるかもしれませんが、その結果を引き起こした局所的な選択が正確にどれだったのかは分からない場合があります。

これは、次のような非常に具体的な局所的行動を抑制したい場合に特に厄介になります。

• 誤ったツール呼び出し

• 分かりにくい説明

• スタイルの逸脱

• 会話上の整合性の弱さ

従来のRLとテキストフィードバックを用いた指向型RL

核となる考え方はシンプルです。

あるステップがもっと良くできたのであれば、そのステップに直接フィードバックを付与する。

これにより、曖昧なロールアウト終了時のペナルティが、狙いを定めた行動修正に近いものへと変わります。

2つ目の飛躍：合成タスクを25倍にスケーリング

2つ目の大きなテーマは、合成タスクの劇的な拡大です。

この記事によると、Composer 2.5ではComposer 2と比べておよそ25倍多い合成タスクが使用されました。

これが重要なのは、モデルが強力になると、固定的なタスクプールでは十分な挑戦にならなくなるためです。学習データもまた、より難しく、より動的になる必要があります。

合成データ規模の比較

この記事で説明されている特に有用な手法の一つが、機能削除です。

1. テスト付きの実在コードベースを用意する

2. 特定の機能を削除する

3. リポジトリを実行可能な状態に保つ

4. 欠けた機能を再構築するようモデルに依頼する

5. テストを報酬シグナルとして使用する

これはコーディングエージェントに非常によく適しています。実際の開発作業にはるかに近い振る舞いを学習させられるからです。

• 機能を復元する

• 構造について推論する

• テスト制約の下で動作する

既存プロジェクト内で作業する

この記事では欠点にも触れています。合成タスク生成が拡大するにつれて、報酬ハッキングがより深刻な問題になるという点です。

3つ目の飛躍：Muon、シャーディング、HSDPは全体を学習可能にするためのもの

最初の2つのセクションが「何を学習するか」と「振る舞いをどう導くか」についてのものだとすれば、3つ目のセクションは、その学習システムを実際に動かす方法についてです。

ここで記事が取り上げているのは次の内容です。

• Muonオプティマイザ

• シャーディングされたMuon

• デュアルグリッドHSDP

ほとんどの読者にとって、システム面の細部をすべて把握する必要はありません。重要な点はこれで十分です。

より長いロールアウト、より大きな合成タスクプール、そしてより細かな行動フィードバックには、いずれもより強力な学習インフラが必要です。

アーキテクチャの視点：Cursorは完全なコーディングエージェントのパイプラインを構築している

記事は最終的に、再びシステム全体の視点へとズームアウトします。

本当の要点は、Cursorが単により優れた回答モデルを出荷しようとしているだけではないということです。Cursorは次の要素からなるエンドツーエンドのスタックを組み上げています。

• オープンなチェックポイント

• RL手法

合成タスク

• 並列学習システム

• 製品ティアの差別化

そしてそれをIDE体験にまでつなげています。

だからこそ、Composer 2.5は単なる浅いバージョンアップ以上のものに感じられるのです。

価格設定とFastティアが製品戦略を明らかにしている

価格設定のセクションは、この記事の中でも実用面で特に有用な部分の一つです。

価格表

Fastティアのコスト比較

この記事では、さらに2つのプロダクト上の詳細にも触れています。

• Fastがデフォルト

最初の1週間は利用量が2倍

これはCursorのプロダクトに関する考え方をよく物語っています。単にモデルを販売しているのではありません。高速で信頼できると感じられる、実用的な開発環境を提供しているのです。

SpaceXAIとのコラボレーションは、将来を見据えた最も大胆な部分

最後の将来展望のセクションでは、次世代のトレーニングへと焦点が移ります。

この記事では、このコラボレーションを次のように位置づけています。

• 総計算量10倍

• H100相当の容量100万基

• Colossus 2を基盤としたインフラ

• チェックポイントベースのファインチューニングから、より完全に自己主導型のトレーニングへの移行

次世代計画表

これは明らかに同社のより大きなストーリーの一部でもありますが、明確な方向性を示しています。

Cursorは、他社のモデルの上に載る薄いIDEレイヤーにとどまりたいわけではありません。

これがWe0スタイルのチームにとって重要な理由

このような話を読むと、開発者にだけ関係があると思いがちです。

しかし、より強力なコーディングエージェントは次のことにも影響します。

• プロトタイプ作成のスピード

• フロントエンド出力のスピード

• ローンチページ制作

• ケーススタディやショーケース用アセットの作成

• エンジニアリングとグロースの間の引き継ぎ摩擦

だからこそ、We0 AIは価値連鎖を次のように捉え続けています。

構築 -> ショーケース -> 成長 -> リード獲得

コーディングエージェントが長時間タスク、調整、製品レベルのアウトプットにおいて向上すると、連鎖全体がより速く進みます。

結論

このアップグレードを理解する最も有用な方法は、単独の小技として見ることではありません。

むしろ、次のように理解するのが適切です。

Composer 2.5は、Cursorがコーディングエージェントのトレーニングスタックとプロダクトとしての形を同時に成熟させていることを示しています。

だからこそ、表面的なモデル更新よりも興味深いのです。

関連記事

• Cursor 公式：Composer 2.5

• Cursor 公式：Composer 2

• Cursor 公式：Composer 2 技術レポート

• Cursor 公式：SpaceXAI モデル学習

• Cursor Docs：Cursor Composer 2.5 モデルドキュメント

• Moonshot AI

• Kimi オープンプラットフォーム

• Anthropic：Claude Code

• OpenAI Developers：Codex

• Google AI for Developers：Gemini API ドキュメント
  

関連ツール

• We0 AI

• Cursor

• Claude Code

• OpenAI Codex

• Vercel

出典

• CSDN

• Cursor Composer 2.5

• Composer 2

• Composer 2 技術レポート

• SpaceXAI モデル学習

• Cursor モデルドキュメント