CursorのComposer 2.5に関する主張は率直です。フロンティアレベルのコーディング品質を約10分の1の価格で提供するというものです。開発者全員が疑問に思っているのは、これが比較対象であるClaude Opus 4.7とGPT-5.5に対して通用するのかという点です。この投稿では、ベンチマーク、速度、コスト、そして日常的な利用判断の観点から、この3つを並べて比較します。
モデル自体に関する詳しい情報が必要な場合は、まずCursor Composer 2.5ガイドをご覧ください。ここでは一つの質問に焦点を当てます。つまり、実際のコードベースと予算が与えられた場合、どのモデルが優れているかという点です。
簡潔な回答
Composer 2.5は、すべての指標で単独で最高のモデルではありません。しかし、実際のソフトウェアタスクにおいてOpus 4.7と1、2ポイント差に迫る性能を持ちながら、1タスクあたり数ドルかかるOpus 4.7に対し、1ドル未満で済むモデルです。日常的にプロダクションコードを出荷しているほとんどのチームにとって、このトレードオフが決定打となるでしょう。Opus 4.7は依然として絶対的なトップエンドでリードしており、GPT-5.5はターミナルを多用する作業で明確な優位性を保っています。
それでは証拠をご覧ください。
ベンチマーク比較
Cursorは3つのスイートのレポートを公開しています。参考としてComposer 2の古い数値も加えた直接比較は以下の通りです。
| ベンチマーク | Composer 2.5 | Opus 4.7 | GPT-5.5 | Composer 2 |
|---|---|---|---|---|
| SWE-bench Multilingual | 79.8% | 80.5% | 77.8% | 73.7% |
| Terminal-bench 2.0 | 69.3% | 69.4% | 82.7% | n/a |
| CursorBench v3.1 | 63.2% | 64.8% (最大) / 61.6% (デフォルト) | 59.2% (デフォルト) | n/a |
3つの点が際立っています。
SWE-bench Multilingualはほぼ互角です。このスイートは、様々な言語における実際のGitHubイシューの修正をテストします。Composer 2.5は79.8%で、Opus 4.7に1ポイント以内の差に迫り、GPT-5.5を上回っています。Composer 2の73.7%からの飛躍が注目すべき点で、これは前身とは異なるクラスのモデルであることを示しています。Composer 2ガイドでその出発点をご確認ください。
CursorBenchでは、デフォルト設定でComposer 2.5が有利です。Cursor独自のタスクスイートにおいて、Composer 2.5 (63.2%) はOpus 4.7のデフォルト構成 (61.6%) をわずかに上回り、GPT-5.5のデフォルト (59.2%) を打ち負かしています。Opus 4.7が優位に立つのは、より高価で実行速度が遅くなる最大設定にまで上げた場合のみです。
GPT-5.5はTerminal-benchを制しています。Composer 2.5の69.3%に対し、GPT-5.5は82.7%と、長いターミナルコマンドシーケンスにおいて明らかに強力です。もしあなたの仕事がシェルを多用する自動化であれば、この点を重視すべきです。
これらの数値の独立した確認については、The Decoderの記事および公式のCursor Composer 2.5発表をご覧ください。
コスト：大きな差があるところ
請求額を見ると、1、2ポイントの差しかないベンチマークはもはや見出しになりません。
| モデル | 入力 / Mトークン | 出力 / Mトークン | 1タスクあたりの概算コスト |
|---|---|---|---|
| Composer 2.5 (標準) | $0.50 | $2.50 | 1ドル未満 |
| Composer 2.5 (高速) | $3.00 | $15.00 | 1桁台の低価格 |
| Opus 4.7 / GPT-5.5 | フロンティアティア | フロンティアティア | 数ドル、最大約11ドル |
Cursorの報告によると、CursorBenchで約63%のスコアを達成し、1タスクあたりの平均コストは1ドル未満です。Opus 4.7とGPT-5.5は、同等かそれ以下の結果に対して1タスクあたり数ドルかかり、一部の比較では競合モデルのコストが同じ作業で最大11ドルにもなるとされています。月に1000個のエージェントタスクを実行する場合、この差は予算項目となり、誤差では済まされません。
おおよその数字を当てはめてみましょう。小規模チームが月に2,000個のエージェントタスクを実行する場合、Composer 2.5では1タスクあたり約1ドルで約2,000ドルになります。フロンティアモデルで1タスクあたり5ドルの同じボリュームでは約10,000ドル、上限の11ドルでは22,000ドルです。同じ作業、同じ月。ベンチマークの差は1ポイントですが、請求額の差は桁違いです。だからこそ、リーダーボードよりもデフォルトモデルの決定が重要になります。
Cursorがこれをどのように計測しているかの詳細については、Cursor Composer料金ガイドをご覧ください。フロンティアモデル側については、GPT-5.5の料金に関する投稿とClaude Opus 4.7ガイドで料金表を解説しています。
速度と各モデルの挙動
品質と価格だけが評価軸ではありません。
- Composer 2.5は、Cursor内での持続的で長時間実行されるエージェントタスクのために構築されています。複数ステップの作業でコンテキストを保持し、要求に応じて努力を調整し、過不足なく実行します。高速バリアントは、同じ知能をより低いレイテンシーで維持します。
- Opus 4.7は、特に最大設定において、難しい推論タスクの最上部で最も強力であり、その分、価格とレイテンシーが高くなります。
- GPT-5.5は、ターミナル駆動のワークフローや長いコマンドチェーンで最も安定しています。
Composer 2.5はオープンソースのMoonshot Kimi K2.5チェックポイントをベースに構築され、Cursorによって大幅に後処理されています。Opus 4.7とGPT-5.5は、コードに強い汎用フロンティアモデルです。この違いは挙動に表れており、Composer 2.5は特にエディターエージェントループのためにチューニングされています。
どちらを選ぶべきか？
リーダーボードとしてではなく、意思決定ガイドとしてこれを利用してください。
Composer 2.5を選ぶべき場合：
- 日常的にコードを出荷しており、大量のタスクあたりのコストが重要である。
- Cursor内で作業しており、マルチファイルタスクで緊密なエージェントループを求めている。
- フロンティア品質の約95%を約10%の価格で得たい。
Opus 4.7を選ぶべき場合：
- 最も難しい推論タスクで絶対的なトップスコアが必要であり、予算は二の次である。
- すでにClaude中心のワークフローを実行している。Claude Code vs Cursorの比較でその経路を解説しています。
GPT-5.5を選ぶべき場合：
- Terminal-benchでのリードが活かせる、ターミナルを多用する自動化作業である。
- コーディングモデルとしても機能する汎用モデルが欲しい。
多くのチームはハイブリッド運用をしています。つまり、大部分のエージェントタスクにはComposer 2.5を使用し、本当にさらなる天井が必要な少数の問題にフロンティアモデルを予約しています。ツールの選択に迷っている場合は、Codex vs Claude Code vs Cursor vs Copilotのまとめでより広い分野が紹介されています。
自身のコードで比較を実行する
公開ベンチマークは平均を教えてくれます。あなたのコードベースは平均ではないので、実際にあなたがやっている作業で3つのモデルを20分間テストしてみてください。
- 通常エージェントに任せるような実際のタスクを1つ選びます。再現性のあるバグ修正、小さな機能追加、テスト付きのリファクタリングなどです。
- Cursorでそれを3回実行し、モデルピッカーを
composer-2.5、Opus 4.7、GPT-5.5の間で切り替えます。プロンプトは同じに保ちます。 - 各実行を3つの軸で評価します。テストに合格したか、どれくらい時間がかかったか、Cursorの利用状況ビューでどれくらいコストがかかったかです。
- もしタスクがAPIに触れる場合、「テストに合格したか」が「単体テストがグリーンだった」だけでなく、「エンドポイントが実際にコードが期待するものを返した」という意味になるように、生成されたリクエストをApidogを通して送信します。
通常、ベンチマークの物語が成り立つことがわかるでしょう。Composer 2.5は品質で近く、コストで大きく先行し、たまに発生する難しい問題のためにフロンティアモデルを保持しておく価値があるということです。しかし、あなたはリーダーボードではなく、あなたの仕事に基づいて決定することになります。
ベンチマークが見落としているベンチマーク
リーダーボードがスコア付けしない失敗モードがあります。それは、既存のエンドポイントではなく、モデルが仮定したエンドポイントに対して、自信に満ちた、見た目はきれいなAPIコードを生成することです。Opus 4.7、GPT-5.5、Composer 2.5のすべてが、実際のAPIコントラクトを欠いている場合にこれを実行します。間違っているが自信満々なコードは、間違っていることが誰かに発見されなければならないため、コードがないよりも遅いです。
どのモデルが比較で勝っても修正方法は同じです。モデルを実際のAPI仕様に基づかせ、生成されたものを検証することです。MCPサーバーを介してCursorに仕様をフィードし、モデルが実際のスキーマに基づいてコードを生成するようにします。そして、生成されたリクエストをApidogで実行し、コードがチームメイトに到達する前にステータスコード、ペイロード、認証を確認します。CursorでのAPI仕様ウォークスルーでセットアップ方法を紹介しています。選ぶモデルは速度と請求額を変えますが、検証ループこそがその速度をデバッグ負債に変えないようにするものです。
よくある質問
Composer 2.5はOpus 4.7より優れていますか？ SWE-bench Multilingualでは1ポイント差以内（79.8% vs 80.5%）、CursorBenchのデフォルトではわずかに上回っています。Opus 4.7がリードするのは最大設定時のみです。コストがはるかに安いことを考えると、Composer 2.5はほとんどのワークロードで価値比較において優れています。
Composer 2.5はGPT-5.5より優れていますか？ SWE-bench MultilingualとCursorBenchではGPT-5.5を上回っています。GPT-5.5はTerminal-bench 2.0で明確に勝利しています。どちらの作業をより多く行うかで選択してください。
Composer 2.5はなぜこんなに安いのですか？ オープンソースのKimi K2.5ベースで構築され、Cursorエージェントループのために特別にチューニングされているため、Cursorが経済性を制御しています。フロンティア汎用モデルはフロンティア価格を伴います。
Cursorで3つすべてを使用できますか？ はい、可能です。Cursorのモデルピッカーを使えばタスクごとに切り替えることができ、これがハイブリッド戦略を実用的なものにしています。セットアップについてはCursor Composer 2.5ガイドをご覧ください。
結論
ベンチマークのピークだけを見るなら、Opus 4.7とGPT-5.5はそれぞれ誇れるチャートを持っています。しかし、実際のソフトウェアタスクにおける1ドルあたりの品質を見るなら、Composer 2.5がほとんどのチームがデフォルトで実行すべきモデルであり、フロンティアモデルは例外的なケースのために予約すべきです。どちらを選択するにしても、実際のAPIコントラクトに基づかせ、出力を検証してください。Apidogをダウンロードして、生成されたエンドポイントに対してライブリクエストを送信し、動作する呼び出しを自動テストに組み込みましょう。