Composer 2.5：ベンチマーク、価格、そして比較

Cursorは2026年5月18日にComposer 2.5をリリースしました。Composer 2が3月に出たばかりで、その約2か月後の提供です。短いリリース間隔は、Cursorが自社モデルをいかに素早く更新しているかを示しています。

Cursorによると、Composer 2.5は複数のコーディング系ベンチマークでClaude Opus 4.7やGPT-5.5に近いスコアを出しています。トークン単価もフロンティアモデルより低価です。学習内容も変わり、合成タスクの増加、より難易度の高い学習環境、そして長いコーディングセッション中の特定の誤りを狙い撃ちするフィードバック手法が導入されました。

本記事では、Composer 2.5を単なるベンチマーク更新以上のものとして捉え、モデルの概要、変更点、各種ベンチマーク、フロンティアモデルとの価格比較、そしてコーディングワークフローにおける位置づけを扱います。制約も存在し、スコアだけでは見えにくい注意点もいくつかあります。

比較対象の他モデルについての背景は、Claude Opus 4.7とGPT-5.5のガイドも参照してください。

CursorのComposer 2.5モデルとは？

Composer 2.5はCursorのComposerファミリー最新モデルで、Cursor IDE内でのコーディング作業に特化しています。これまでのComposer 1、Composer 1.5、Composer 2の流れを受け継いでいます。

ローンチから2.5までのComposerタイムライン。画像：筆者作成。

これは汎用チャットボットではありません。Composer 2.5は、ファイルをまたぐ編集、ターミナルコマンド、ツールの活用、長時間のコーディングセッションに向けて訓練されています。学習目標と評価指標はソフトウェアエンジニアリングの作業に焦点を当てています。

ローンチ投稿では、コーディングタスクでComposer 2を上回るスコアを出し、長いセッションでの挙動が変わったとしています。現在、Composer 2.5はCursorのモデルピッカーでデフォルトの選択肢ですが、Composer 2も引き続き利用可能です。また、動作環境はCursor内のみで、一般公開APIやHugging Faceのモデルカード、他プロバイダー経由のゲートウェイ提供はありません。

Composer 2.5で変わった点

Composer 2.5の変更は「コーディングタスクの性能」と「協調動作」の2つに大別できます。前者は数値で測りやすく、後者は定性的な評価が多くなります。数値で示せる部分と、説明にとどまる部分を切り分けて見る価値があります。

長いタスクでの性能

Composer 2.5は、ファイルの読み込み、ターミナルコマンドの実行、エラー修正、反復を必要とする長いコーディングセッションを主眼にしています。実開発は一問一答に収まりにくいため、これは重要です。

Cursorはこの種の作業に向けて、より難しい強化学習環境でモデルを学習させました。タスクは学習中に生成され、難易度は時間とともに引き上げられました。

指示追従とコラボレーション

リリースでは、指示追従の信頼性向上についても言及しています。特に「努力のキャリブレーション」を挙げ、難しい課題には計算資源を多く割き、簡単な課題では過剰思考を避けるよう意図されています。

ただし注意点があります。Cursorはこれらの挙動変化が「既存のベンチマークでは十分に捉えられない」と述べています。つまり、この部分は主にCursor自身の評価や初期ユーザーのフィードバックに基づくもので、公的スコアに裏付けられてはいません。

より困難なRL環境

ローンチ投稿では、変更点を「学習のスケール拡大、より複雑なRL環境の生成、新しい学習手法の導入」と位置づけています。Composer 2と比べて25倍の合成タスクを使用しました。

CursorがComposer 2.5をどのように学習させたか

学習の詳細は、ベースのアーキテクチャを替えずにモデルがどう変化したかを説明します。Composer 2.5はComposer 2と同じ基盤を用いますが、基礎学習後の工程が変わりました。全てのインフラ詳細が同じ重みを持つわけではありませんが、いくつかの要素はベンチマークの動きを説明する助けになります。

Kimi K2.5を基盤に

Composer 2.5は、Composer 2と同じオープンソースのチェックポイント、すなわちMoonshot AIのKimi K2.5を基に構築されています。これはローンチ投稿で明言されており、Composer 2のベースモデルを巡る議論において重要な点でした。

Kimi K2.5はMixture of Expertsアーキテクチャを採用しています。Cursorはその上に継続的な事前学習と強化学習を施し、最終モデルに必要な総計算量の約85%はベース学習後の自社作業に由来すると述べています。

テキストによるターゲット型RL

これはComposer 2.5における主要な技術的変更点です。標準的なRLでは、長いシーケンスの最後に1つの報酬信号が与えられます。長いコーディングセッションでは、その最終報酬だけではどこで誤ったのかがノイズに埋もれがちです。

教師と生徒が同一ターンを共有。画像：筆者作成。

Cursorの手法では、モデルが誤った判断をした地点に短いテキストのヒントを差し込みます。例えば、存在しないツールを呼び出してしまった場合、正しいツール一覧を思い出させるリマインダーを挿入します。ヒント付きの版が「教師」、元のモデルが「生徒」となり、蒸留ロスによってそのターンに限って生徒の挙動を教師へ近づけます。

これにより学習がよりピンポイントになります。長いロールアウト全体を漠然と正誤で扱うのではなく、個々の誤りを修正できます。Cursorはこの手法を、Composer 2.5の学習においてコーディングスタイル、ツール使用、モデルのコミュニケーションに幅広く適用しました。

大規模な合成データ

Composer 2.5はComposer 2の25倍の合成タスクで学習されています。これらのタスクは実在のコードベースに根ざしており、おもちゃの例ではありません。

Cursorが説明するアプローチの1つが「機能削除」です。エージェントは実際のコードベースと大規模なテストスイートから出発し、プロジェクトの他部分は機能したままになるようにコードやファイルを削除します。合成タスクは削除した機能を再実装することで、テストが検証可能な報酬信号となります。

この規模の合成学習には固有のリスクもあります。Cursorは、Pythonの型チェック用キャッシュから削除情報を復元したり、Javaバイトコードを逆コンパイルして外部APIを再構築したりするなど、Composer 2.5が抜け道を見つけた事例を記録しました。同社は監視ツールでこれらを検出したとしつつ、このスケールでの学習には「一層の注意」が必要だと認めています。

インフラの変更

インフラ面では、継続的事前学習にSharded MuonとデュアルメッシュHSDPを使用しました。これにより大規模GPUクラスターでの学習にかかるコストや時間の一部が削減されました。

Composer 2.5のベンチマーク結果：Terminal-Bench、SWE-Bench、CursorBench

ベンチマークは有用ですが、全体像は示しません。日々の使用感をそのまま断定できるものではなく、比較の出発点として扱うのが妥当です。

CursorはComposer 2.5を次の3つのベンチマークで評価しています：

SWE-Bench Multilingualは、複数のプログラミング言語にわたって、実際のGitHubのIssueを解決できるかを検証します。各タスクはリポジトリと問題文を与え、パッチが関連テストをパスするかで評価します。

Terminal-Bench 2.0は、AIエージェントが実際のターミナルワークフロー（ファイルの確認、コマンド実行、失敗のデバッグ、複数手順のタスク完了）をこなせるかを測ります。

CursorBench v3.1はCursorの社内ベンチマークです。実際のCursorセッションからの曖昧なマルチファイル課題を用い、コードベース理解、バグ発見、計画立案、コードレビューを評価します。外部研究者が検証・再現できない点と、同一バージョン内での比較に留めるべき点が制約です。

数値の読み取りで注意すべき点が1つあります。モデル間のベンチマーク比較は常にクリーンとは限りません。評価設定や努力度の違いでスコアが動くことがあり、CursorはOpus 4.7とGPT-5.5の公的評価に自己申告スコアが含まれると指摘しています。これらは同一条件下の直接比較ではなく、方向性の比較として扱ってください。

後日の外部ベンチマークであるArtificial Analysisも概ね同様の傾向を示しました（異なるベンチマーク構成を使用）。Composer 2.5はArtificial Analysis Coding Agent Indexで62点、Claude Opus 4.7の最大努力（66）やGPT-5.5のxhigh reasoning（65）に次ぐ結果でした。

注目すべきはコスト差です。Artificial Analysisは、Composer 2.5をStandardで1タスクあたり$0.07、Fastで$0.44と見積もる一方、Opus 4.7 maxは$4.10、GPT-5.5 xhighは$4.82と推定しています。

Composer 2.5 vs. Composer 2 vs. Composer 1.5：スコア比較

Composerファミリーは短期間に3回のリリースがありました。Composer 1.5が2026年2月、Composer 2が3月、Composer 2.5が5月に提供されています。各バージョンで学習手法の異なる側面が変わりました。

Composer 2.5とComposer 2の比較

Composer 2から2.5への伸びが最も見えるのはTerminal-Bench 2.0（61.7%→69.3%）とSWE-Bench Multilingual（73.7%→79.8%）です。CursorBenchの伸びは小さく、かつ評価バージョンがv3からv3.1に変わっているため、比較の直接性は下がります。

より大きな違いは学習パイプラインです。Composer 2はKimi K2.5に対する継続的事前学習を導入しました。Composer 2.5はその基盤を維持しつつ、ターゲット型テキストフィードバック、25倍の合成タスク、インフラ変更を加えました。Standardの価格は据え置きです。

Composer 2.5とComposer 1.5の比較

Composer 1.5は、Composer 1と同じ事前学習モデル上で強化学習をさらに20倍スケールしました。長いセッションで文脈を自動圧縮する適応的思考と自己要約を導入しました。

1.5から2.5へのギャップは全ベンチマークで大きく、かつトークン単価も低下しました。Composer 1.5は入力100万トークン$3.50、出力100万トークン$17.50で、Composer 2.5 Standardより約7倍高価でした。

実務での変化

これらのバージョンを通じたパターンは明快です。各世代で長いセッション時の挙動や指示追従が変わり、Composer 2と2.5では継続的なエージェントセッションのコストが下がりました。

Composer 2.5 vs. Claude Opus 4.7 vs. GPT-5.5：ベンチマーク、価格、トレードオフ

多くの読者がまず気にする比較です。Composer 2.5は一部領域で近いコーディングベンチマークスコアを示し、下記のフロンティアモデルよりトークン単価が安く、明確なトレードオフがあります。

ベンチマーク比較

Terminal-Bench 2.0ではGPT-5.5が82.7%でリードしており、Composer 2.5に対して約13ポイント上回ります。ターミナル依存度の高い作業ではこの差が効いてきます。

SWE-Bench MultilingualではClaude Opus 4.7が80.5%、Composer 2.5が79.8%で、1ポイント未満の差です。CursorBenchでは、Composer 2.5の63.2%はOpus 4.7のデフォルト（61.6%）を上回る一方、Opus 4.7のmax（64.8%）やGPT-5.5のxhigh（64.3%）は上です。GPT-5.5のデフォルトは59.2%でした。

これらのモデルは同じ役割ではありません。Opus 4.7とGPT-5.5はより汎用的なフロンティアモデルで、Composer 2.5はCursor内でのみ動くコーディングモデルです。コーディングタスクの一部ではスコアが接近していますが、プロダクトの境界は異なります。

価格の比較

コスト差はフロンティアモデルとの最も明確な分岐点です。

Composer 2.5 Standardは、トークン単価でOpus 4.7やGPT-5.5の約10分の1です。Fast版も、両フロンティアモデルの標準ティアより低価格に設定されています。

これらの価格は2026年5月時点のものです。比較に依存する前に、Cursorのモデル料金、AnthropicのOpus料金、OpenAIのAPI料金を確認してください。

見落とされがちな点を1つ。Composer 2.5 Fastの価格は、Composer 2 Fastと比べて倍増しました。Standardは据え置きですが、Fastがデフォルトのため、アップグレードによって一部ユーザーのコストは上がり得ます。

どのモデルを選ぶべきか？

重視するのがコストか、ターミナル作業か、あるいはより深いプランニングかで選択は変わります。

• Composer 2.5はCursor内での普段のコーディングに適し、ファイル横断の編集、リファクタリング、デバッグ、コストが効くエージェントセッションに向いています。
• GPT-5.5はターミナル性能が最重要のタスクに適しています。
• Claude Opus 4.7は、丁寧な推論、アーキテクチャ設計、あるいは100万トークンのコンテキストが必要なタスクに適しています。

要約するなら、Composer 2.5は日常的なコーディングをカバーし、フロンティアモデルは広範な推論やより高いターミナルスコアを要する場面で役割があります。

Composer 2.5 StandardとFast：速度、価格、使い分け

CursorはComposer 2のときと同様、Composer 2.5を2つのバリアントで提供しています。Cursorによれば、両者は同じ基礎的知能を共有し、違いは主に応答速度と価格です。

Composerが選択されたCursorのモデルピッカー。画像：筆者作成。

Fastはデフォルトで、入力100万トークン$3.00、出力100万トークン$15.00です。低レイテンシが重要な対話的セッションに向きます。Standardは$0.50と$2.50で、即時性が不要なバックグラウンド処理や長めのエージェントループに適しています。

Composer 2.5の利用は、Cursor内で「Auto + Composer」という専用の使用プールに計上され、ClaudeやGPTなど外部モデルのAPIプールとは分かれています。ローンチ後1週間は使用量2倍の提供もありました。

Composer 2.5の制約と注意点

注意点はアクセス性、ベンチマーク、学習時のリスクに関するものです。Composer 2.5だけが特異というわけではありませんが、Cursorの主張にどれだけ重みを置くかに影響します。

Cursor内専用での提供。 先述のとおり、Composer 2.5には公開APIがありません。自前のスクリプトやパイプラインからモデルを呼び出す必要がある場合、Composer 2.5は選択肢になりません。

CursorBenchは独立評価ではない。 ベンチマークの項で述べたように、CursorBench v3.1はCursorの内部ベンチマークです。手法は完全には公開されておらず、外部研究者が課題を再現できません。

ベンチマーク設定のばらつき。 Cursorの図表にあるフロンティアモデルのスコアは、必ずしも同一条件で測定されていません。比較はあくまで方向性であって決定打ではありません。

学習時の報酬ハッキング。 Cursorは、合成タスクで通常の解法ではなく抜け道を見つけた事例を開示しました。監視で明白な例を捉えたとしても、この規模のRLには内在的なリスクがあります。

努力のキャリブレーションは未検証。 コミュニケーションスタイルや努力配分に関するCursorの主張は、先述のとおりベンチマークデータで裏付けられていません。外部から検証しづらい点です。

Composer 2.5が有効な場面

これはタスク次第です。Composer 2.5は万能のモデルというより、すでにCursor内で作業している人向けのコーディングモデルとして位置づけるのが適切でしょう。

一日の大半をCursor内でのコーディングに費やし、トークンコストを重視するなら、 Composer 2.5 StandardがComposer 2.5ラインで最も安価です。編集、リファクタリング、デバッグ、長時間セッションといった前述の用途に当てはまります。

応答速度を優先するなら、 Composer 2.5 Fastがデフォルトの選択肢です。

より広範な推論、大きなコンテキストウィンドウ、あるいは特定分野での高いベンチマークスコアが必要なら、 Claude Opus 4.7またはGPT-5.5が適する場合があります。

言い換えると、Composer 2.5は前述のルーティンなコーディングを担い、フロンティアモデルはより広範な推論や高いターミナルスコアを要するタスクに適します。特定モデルを一律に勧めない形で、比較を地に足の着いたものに保てます。

まとめ

Composer 2.5はベンチマークの物語として読むこともできますが、より有益なのは進む方向性でしょう。Cursorは単にフロンティアモデルをエディタに包んでいるのではなく、エージェントが既に行っている作業（ファイル横断の編集、ターミナル操作、長いセッション、失敗からの回復）に合わせてモデル系列を構築しています。

先述のとおり、Composer 2.5は意図的に用途が狭い設計です。汎用モデルとしてClaude Opus 4.7やGPT-5.5の代替にはならず、Cursor外のAPIが必要な場合にも役立ちません。しかしCursor内では、この絞り込みこそが要点です。フロンティアモデルより運用コストが安く、コーディングタスク向けに調整され、これらの作業が起きるプロダクト層に近い位置にあります。

次の論点は、Cursorがどこまで自前化を進めるかです。同社はSpaceXAIと協力し、総計算量を10倍、Colossus 2インフラを用いたより大規模なモデルをゼロから学習中と述べています。リリース時期は未定で、現時点で分析材料は多くありませんが、方向性は明確です。Cursorはモデルの上手な活用から、モデルスタック自体をより自社で構築する段階へと動いています。