Cursorの新モデル「Composer 2.5」とは？開発体験を劇的に変える『ふるまい』の進化と技術的背景

Cursorの新モデル「Composer 2.5」とは？開発体験を劇的に変える『ふるまい』の進化と技術的背景

先日（2026年5月18日）発表されたCursorの新モデル「Composer 2.5」のリリースノート、もう読みましたか？
今回のアップデートは、単にベンチマークのスコアを競うだけでなく、実際の開発で私たちが直面する「長時間のタスク」や「複雑な指示」への粘り強さといった「ふるまい」の改善に焦点を当てています。

今回は、公式ブログの発表内容から、Composer 2.5がどのように進化し、私たちの開発体験をどう変えるのか、技術的な背景とともにかみ砕いて整理します。

参照元:

Cursor公式ブログ「Introducing Composer 2.5」
公開日: 2026年5月18日

Composer 2.5の主な改善ポイント

Composer 2.5では、主に以下のような改善が行われています。

• 長時間のタスクを継続して進める能力の向上
• 複雑な指示への追従性能の向上
• コミュニケーションスタイルの改善
• どの程度の労力をかけるべきかを判断する振る舞いの改善
• より難しい学習タスクによるモデル性能の強化

Cursorの説明では、Composer 2.5はComposer 2と比べて「知能」と「ふるまい」の両面で大きく向上しているとされています。

ここで注目したいのは、「ふるまい」という表現です。

AIモデル of 性能は、ベンチマークの点数だけでは測れません。実際の開発では、次のような要素も重要になります。

• ユーザーの意図をどれだけ正確に汲み取れるか
• 必要以上に大きな変更をしないか
• 説明がわかりやすいか
• エラーが起きたときに適切に立て直せるか
• 長い作業でも一貫性を保てるか

Composer 2.5は、こうした実務上の使いやすさにも踏み込んで改善されている点が特徴です。

ベースはKimi K2.5

Composer 2.5は、Composer 2と同じく、Moonshot AIのオープンソースチェックポイントである「Kimi K2.5」を基盤にしています。

その上で、Cursor独自の学習スタックや強化学習の工夫を加えることで、コーディングエージェントとしての能力を高めています。

つまりComposer 2.5は、単なる汎用LLMではなく、Cursor上での開発体験に最適化されたモデルと考えるとわかりやすいです。

改善の背景にある3つの技術要素

Cursorの記事では、Composer 2.5の学習に関する主な改善として、次の3つが紹介されています。

• テキストフィードバックを用いたターゲット型RL
• 合成データの拡充
• Sharded Muon と dual mesh HSDP

それぞれ簡単に整理します。

1. テキストフィードバックを用いたターゲット型RL

AIエージェントの学習では、長い作業の中でどの判断が良かったのか、あるいは悪かったのかを特定するのが難しくなります。

たとえば、数百回のツール呼び出しを含む長い作業の中で、1回だけ間違ったツールを呼び出したとします。

最終的なタスクが成功していれば、その小さなミスは報酬に大きく反映されない可能性があります。逆に失敗した場合でも、どの部分が原因だったのかをモデルが正確に学ぶのは簡単ではありません。

そこでComposer 2.5では、問題が起きた箇所に対して直接テキストフィードバックを与える手法が使われています。

たとえば、モデルが存在しないツールを呼び出そうとした場合、その場面に「利用可能なツールはこちら」といったヒントを挿入します。すると、モデルはその局所的な場面で何を改善すべきかを学びやすくなります。

これは、長い作業全体に対するざっくりした評価だけでなく、「この場面ではこう振る舞うべきだった」という具体的な学習シグナルを与える考え方です。

この手法によって、コーディングスタイルやコミュニケーション、ツール利用の正確性など、実際の使いやすさに直結する振る舞いが改善されています。

2. 合成データの拡充

Composer 2.5では、Composer 2の25倍の合成タスクで学習されています。

合成タスクとは、実際のコードベースをもとに人工的に作られた学習用の課題です。

たとえば、あるコードベースから特定の機能だけを削除し、AIにその機能を再実装させるようなタスクが紹介されています。この場合、テストが通るかどうかを報酬として使えるため、モデルの学習に活用しやすくなります。

これはコーディングAIにとって非常に実践的な学習方法です。

なぜなら、実際の開発でも次のような作業はよく発生するからです。

• 既存コードを読んで仕様を理解する
• 足りない機能を追加する
• テストを通しながら修正する
• 周辺コードとの整合性を保つ

一方で、大規模な合成データ学習には課題もあります。

記事では、モデルが削除された関数シグネチャをキャッシュから推測したり、Javaバイトコードを逆コンパイルして情報を復元したりする例が紹介されています。

これは、モデルが賢くなるほど「本来意図した解き方」ではなく「抜け道」を見つけてしまう可能性があることを示しています。

AIエージェントの学習では、単に問題を解けるかどうかだけでなく、どのように解いたかを監視することも重要になります。

3. Sharded Muon と dual mesh HSDP

記事の後半では、より技術的な学習基盤についても説明されています。

Composer 2.5では、継続的な事前学習において「Muon」という手法や、MoEモデルに適したHSDPのレイアウトが使われています。

この部分はかなり専門的ですが、ざっくり言うと、大規模モデルを効率よく学習させるための分散学習の工夫です。

特にMoEモデルでは、モデル内のexpertと呼ばれる部分が大きな計算コストを占めます。そのため、expert部分とそれ以外の部分で異なる並列化の設計を使い、通信や計算を効率化しています。

Cursorの記事では、1Tモデルにおいてoptimizer step timeが0.2秒であることにも触れられています。

Composer 2.5の改善は、モデルそのものの学習データや強化学習だけではなく、それを支える大規模な学習インフラにも支えられていることがわかります。

料金

Composer 2.5の価格は次のように紹介されています。

Composer 2と同様に、高速版がデフォルトのオプションとされています。

また、Composer 2.5では初週の使用量が2倍になるとも案内されています。

開発者にとって何が嬉しいのか

Composer 2.5のアップデートは、単に「より賢いモデルになった」という話ではありません。

開発者にとって重要なのは、AIに任せられる作業範囲が広がることです。

たとえば、次のような場面で恩恵がありそうです。

• 複数ファイルにまたがる修正
• 既存コードの仕様理解
• テストを見ながらの機能実装
• 長めのリファクタリング
• エラー原因の調査
• コードレビューの補助
• 途中で方針を変える必要があるタスク

特に、長時間の作業でも文脈を保ちやすくなり、指示に対してより安定して従えるようになるのであれば、AIエージェントとしての実用性はかなり高まります。

気になる点

一方で、Composer 2.5の説明からは、今後のAIコーディングエージェントにおける課題も見えてきます。

特に重要なのは、モデルが賢くなるほど、意図しない抜け道を見つける可能性がある点です。

合成タスクの例では、モデルがキャッシュやバイトコードから本来削除された情報を復元するような動きを見せています。これは能力の高さを示す一方で、評価設計や監視の難しさも示しています。

今後のコーディングAIでは、単に「テストが通る」だけではなく、次のような観点もより重要になりそうです。

• 変更内容が意図に沿っているか
• セキュリティ上問題がないか
• 不自然な回避策を使っていないか
• 保守しやすいコードになっているか
• 説明責任を果たせるか

AIエージェントを実務で使う場合、人間側のレビューや設計判断は引き続き重要です。

まとめ

Composer 2.5は、Cursorのコーディング体験をさらに強化するための大きなアップデートです。

ポイントをまとめると、次のようになります。

• Composer 2と比べて知能とふるまいが大きく改善
• 長時間タスクや複雑な指示への対応力が向上
• テキストフィードバックを使ったターゲット型RLで局所的な振る舞いを改善
• Composer 2の25倍の合成タスクで学習
• 大規模分散学習の工夫により、学習効率も高めている
• 価格は通常版が入力$0.50/M、出力$2.50/M
• 高速バリアントも用意されている

Composer 2.5は、AIコーディングエージェントが「単発のコード生成」から「長い開発作業を一緒に進める存在」へ近づいていることを感じさせるアップデートです。

今後、Cursorを使った開発では、AIにどこまで任せるか、どのタイミングで人間がレビューするかという使い分けがますます重要になりそうです。