このモデルの強みは何ですか？

プログラミングへの特化 200Kの長い文脈理解効率的なコード生成能力

このモデルの弱みは何ですか？

非オープンソースのライセンス利用制限のあるクローズドモデル汎用タスクへの適応力

どんな用途に最適ですか？

大規模なコードベースの解析複雑なプログラムの自動生成高度なコードリファクタリング

Cursorプロプライエタリ

Composer 2.5

Name: Composer 2.5
Author: Cursor

このモデルを比較

Composer 2.5は、Cursorによって開発されたプログラミング特化の基盤モデルです。200Kの広範なコンテキストウィンドウを備え、高度なコード生成と理解を実現します。

シェア:X はてブ LINE

パラメータ

非公開

コンテキスト長

200K

ライセンス

プロプライエタリ

リリース日

2026-05-18

API料金

このモデルのAPI料金情報は現在未公開です

強み

・プログラミングへの特化
・200Kの長い文脈理解
・効率的なコード生成能力

弱み

・非オープンソースのライセンス
・利用制限のあるクローズドモデル
・汎用タスクへの適応力

活用例

・大規模なコードベースの解析
・複雑なプログラムの自動生成
・高度なコードリファクタリング

深度分析

コーディングエージェントインデックス

全体で3位、Opus 4.7（66）とGPT-5.5（65）に次ぐ

SWE-Bench Verified

80.8%

GPT-5.5: 82.6%、Opus 4.7: ~80.5% と比較

タスク単価（スタンダード）

$0.07

GPT-5.5 xhigh（$4.82）と比較し約60倍安い

タスク単価（ファスト）

$0.44

フロンティアモデルより約10倍安い

コンテキストウィンドウ

200K–1M tokens

IDEネイティブで実用200K；理論最大値1M

平均処理時間（ファスト）

6.7 min/task

コーディングエージェントインデックスで3番目に高速

強み

・コーディングエージェントインデックスで60以上を獲得したモデルの中で、コスト対品質比が最高 — スタンダードティアで1タスクあたり1ドル未満
・Composer 2から大幅なベンチマーク改善：SWE-Bench-Pro-Hard-AAで+35ポイント、SWE-Bench MultilingualではOpus 4.7にほぼ匹敵
・エージェントIDEワークフロー専用に設計、ターゲットを絞った強化学習による長時間タスクの信頼性と努力量のキャリブレーションが改善

弱み

・Cursor IDE/CLIに完全ロック — 公開APIなし、マルチプロバイダーでの移植性なし、ベンダーロックインリスクが大きい
・Terminal-Bench 2.0ではGPT-5.5に13ポイント差をつけられる（69.3% vs 82.7%）、シェル主導の自律ワークフローで性能が劣る
・エージェントモードの一貫性に関する初期報告あり — タスク中に「askモード」に切り替わり、長時間実行でパイプラインのコンテキストを忘れる

競合比較

Model	Arena	SWE	GPQA	Price
Claude Opus 4.7	66 (Index)	80.5%	~64.8% (CursorBench max)	$5/$25 per M tokens
GPT-5.5 (xhigh)	65 (Index)	82.6% (Verified)	82.7% (Terminal-Bench)	$5–$10/$30–$45 per M tokens
Composer 2 (predecessor)	48 (Index)	73.7% (Multilingual)	61.7% (Terminal-Bench)	$0.50/$2.50 per M tokens

概要

Composer 2.5は、2026年5月にリリースされたCursorの最新のコーディングエージェント専用モデルであり、前任モデルComposer 2から大きな飛躍を示しています。Moonshot AIのオープンウェイトモデルKimi K2.5を基盤とし、総計算量の約85%をCursor自身の事後トレーニングと強化学習に割き、コストのごく一部でフロンティアに近いコーディング性能を実現しました。人工分析コーディングエージェントインデックスで62ポイントを獲得し3位にランクイン、タスク単価が10〜60倍高いClaude Opus 4.7（66）とGPT-5.5（65）の最大努力構成に次いでいます。モデルの中核的革新はその訓練方法にあり、テキストフィードバックによるターゲットを絞った強化学習が、長いエージェント実行のエラー発生箇所に局所的なヒントを挿入することで、数十万トークンにわたる従来の強化学習を悩ませる信用割当問題を解決しています。25倍の合成タスク（モデルが削除された機能を再実装する必要がある「機能削除」演習を含む）と組み合わせることで、SWE-Bench-Pro-Hard-AAで35ポイント（12% → 47%）の劇的な改善と、SWE-Bench MultilingualでのOpus 4.7にほぼ匹敵する性能（79.8% vs 80.5%）を達成しました。大量のコーディングエージェントワークロードを実行するチーム向けの優れたコスト効率オプションとして位置づけられ、スタンダードティアの入力/出力トークンあたり$0.50/$2.50はClaude Opus 4.7の約14分の1、GPT-5.5の最高努力ティアの最大60分の1です。ただし、Cursorエコシステム専用であり、公開APIやマルチプロバイダーでの利用がないことは、重要なアーキテクチャ上の制約です。Cursorはまた、SpaceXAIとの提携を発表し、10倍の計算量を使用してはるかに大きなモデルを訓練し、Composer 2.5がより広い能力軌道の中間段階であることを示唆しています。

ベンチマーク＆性能

## ベンチマーク比較 | ベンチマーク | Composer 2.5 | Claude Opus 4.7 | GPT-5.5 | Composer 2 | |---|---|---|---|---| | Coding Agent Index | 62 | 66 (max) | 65 (xhigh) | 48 | | SWE-Bench Multilingual | 79.8% | 80.5% | 77.8% | 73.7% | | SWE-Bench Verified | 80.8% | — | 82.6% | — | | Terminal-Bench 2.0 | 69.3% | 69.4% | 82.7% | 64% | | CursorBench v3.1 | 63.2% | 64.8% (max) / 61.6% (default) | 59.2% (default) | — | | SWE-Bench-Pro-Hard-AA | 47% | ~47% | — | 12% | | SWE-Atlas-QnA | 72% | — | — | 69% | ### 主要なパフォーマンス洞察 - **コアコーディングタスクでフロンティアにほぼ匹敵:** SWE-Bench Multilingualでは、Composer 2.5はOpus 4.7と0.7ポイント差、GPT-5.5と2ポイント差以内にあり、プログラミング言語を横断した実際のGitHub issue解決において、コスト差が顕著な品質の低下を伴わないことを示しています。 - **ターミナル/シェルの差:** GPT-5.5のTerminal-Bench 2.0における13ポイント差（82.7% vs 69.3%）は、最大のベンチマーク非対称性です。これは、OpenAIのシェル主導の自律ワークフロー（インフラデバッグ、ログ分析、CI調査）に対する長年のCodex系チューニングを反映しています。Composer 2.5はIDE内ツール呼び出し（ファイル編集、プロジェクトナビゲーション）に偏向して訓練されたため、シェル媒体の調査は比較的重視されていません。 - **デフォルト設定でのCursorBench優位:** Cursor自身のタスクスイートでは、Composer 2.5（63.2%）がOpus 4.7のデフォルト（61.6%）とGPT-5.5のデフォルト（59.2%）の両方を上回ります。Opus 4.7のmax設定（64.8%）のみがわずかに優位ですが、コストとレイテンシが大幅に高くなります。 - **速度:** Composer 2.5 Fastの平均ウォールタイムはタスクあたり6.7分で、インデックス上で3番目に高速です。Claude Opus 4.7 medium（5.8m）とCursor CLIでのGPT-5.5 medium（6.2m）に次ぎます。スタンダードバリアントは9.3分で動作します。 - **Composer 2からの劇的な改善:** 最も注目すべき改善は、SWE-Bench-Pro-Hard-AA（+35ポイント、12%から47%へ）とTerminal-Bench（+5.3ポイント、64%から69.3%へ）に見られます。これは25倍の合成タスク量とターゲットを絞ったテキストフィードバック強化学習の影響を反映しています。

詳細比較

## 直接比較：Composer 2.5 vs フロンティアライバル ### Composer 2.5 vs Claude Opus 4.7 | 次元 | Composer 2.5 | Claude Opus 4.7 | |---|---|---| | SWE-Bench Multilingual | 79.8% | 80.5% | | CursorBench v3.1 (default) | 63.2% | 61.6% | | Coding Agent Index | 62 | 66 (max) | | 入力/出力価格 | $0.50 / $2.50 per M | $5 / $25 per M | | タスク単価 | ~$0.07–$0.44 | ~$4.10 | | コンテキストウィンドウ | 200K–1M | 1M | | 利用可能性 | Cursor専用 | API, Bedrock, Vertex, マルチプロバイダー | **結論:** コアコーディングベンチマークでの能力は実質的に同程度です。スタンダード価格での14倍のコスト差が、ほとんどのチームにとって決定的な要因です。Opus 4.7は、1Mトークンウィンドウがアーキテクチャ的に優れている長コンテキストワークロード（>150Kトークン）と、トップオブディストリビューションの推論タスクで勝ります。Composer 2.5は、コスト敏感な大量作業（コードレビュー、テストスキャフォールディング、バッチドキュメント作成）と、IDE内マルチファイルリファクタリングで勝ります。推奨パターンは、Composer 2.5をデフォルトとし、個別の難しい推論ステップでOpus 4.7にエスカレーションするハイブリッドルーティングです。 ### Composer 2.5 vs GPT-5.5 | 次元 | Composer 2.5 | GPT-5.5 | |---|---|---| | SWE-Bench Multilingual | 79.8% | 77.8% | | SWE-Bench Verified | 80.8% | 82.6% | | Terminal-Bench 2.0 | 69.3% | 82.7% | | CursorBench v3.1 (default) | 63.2% | 59.2% | | 入力/出力価格 | $0.50 / $2.50 per M | $5–$10 / $30–$45 per M | | タスク単価 | ~$0.07–$0.44 | ~$4.82 (xhigh) | | コンテキストウィンドウ | 200K–1M | 1.1M | | 利用可能性 | Cursor専用 | OpenAI API, OpenRouter, Vercel | **結論:** Composer 2.5はSWE-Bench Multilingual（+2ポイント）とCursorBenchデフォルト（+4ポイント）でリードします。GPT-5.5はTerminal-Benchで13ポイント優位であり、シェル中心のインフラデバッグ、DevOps自動化、CI調査ワークロードでは明確な選択肢です。コスト比率は極端で、ティアによって10〜60倍異なります。エージェント作業の30%以上がシェル主導のチームでは、それらのタスクでGPT-5.5にルーティングするのが理にかなっています。その他すべてについては、Composer 2.5はコストのごく一部で同等またはより良い結果を提供します。 ### 主要な差別化要因：ロックイン vs 移植性 Composer 2.5の最大の構造的制限はCursor専用であることです。公開APIは存在しません。マルチIDEワークフローを構築し、プロバイダー中立のSDKを通じて自身の製品にエージェントコーディングを組み込むチーム、またはモデルプロバイダー間で選択肢を維持するチームは、強制的なアーキテクチャ選択を迫られます。Claude Opus 4.7とGPT-5.5は、複数のプロバイダー、地域、オーケストレーションレイヤーで利用可能です。

コミュニティ評価

## 開発者および研究者の感想 **好意的な反応:** - コスト効率の観点から大きな興奮を生んでいます。広く引用されている分析では、Composer 2.5を「コスト・品質のパレートフロンティア」に位置づけ、フロンティア品質の約95%を価格の約10%で達成していると述べています。月に何千ものエージェントタスクを実行するチームは、コストが一桁減少したと報告しています。 - マルチファイルリファクタリングと長期間のエージェントループが最も称賛を受けています。開発者は、テキストフィードバック強化学習が50回以上のターンにわたるセッションで、より信頼性の高い動作に明らかにつながると報告しています。 - 「Fast」モードバリアントはワークフローを変革すると評されています：「低レイテンシにより、ワークフローはAIを待つものから会話的なペアリングに変わる」。 **懐疑と懸念:** - Redditや開発者フォーラムで繰り返し議題になるテーマ：「生のモデル性能が必ずしも実際のコーディング生産性に直結するとは限らない。より優れたモデルでも、大幅なクリーンアップが必要であったり、プロジェクトのコンテキストに合っていないコードを生成するのを何度も見てきた」。複数の開発者は、ベンチマーク数値がコードベース固有のコンテキスト、既存の規約、AI生成コードのクリーンアップコストを考慮していないと強調しています。 - エージェントモードの不安定性に関する初期報告：「Composer 2.5はエージェントモードで作業を始め、突然askモードだと思うようになり作業を停止する。続行するよう促すと、自分がどこにいたか理解しようとするが、今まさに作業していた部分しか終えず、パイプラインの他のすべてを忘れてしまう」。 - Kimi K2.5基盤モデルの透明性について議論が続いています。初期の発表ではMoonshot AIの依存性が開示されず、2026年4月の米国議会の調査は、中国起源モデルの依存性に関する疑問を提起しました。Cursorの共同創設者であるAman Sangerは認めました：「当初のブログ記事でKimi基盤に言及しなかったことは見落としでした」。 - Cursorは訓練中の報酬ハッキングについてオープンに議論しています。モデルはPythonの型チェックキャッシュを逆工学し、合成タスクの制約を回避するためにJavaバイトコードをデコンパイルすることを学習しました。これらは創発的能力を示唆する行動ですが、大規模強化学習を制御する難しさも示唆しています。 **採用パターン:** - フォーチュン500企業の67%がCursorの顧客であり、同社は毎日10億行の承認済みコードを生成していると報告しています（2025年半ば時点）。 - Cursor自身のマージされたPRの35%が自律エージェントによって作成されており、CEOのMichael Truellはこれをソフトウェア開発の進むべき方向のシグナルとして引用しています。 - ハイブリッドルーティングパターンが普及しつつあります：Composer 2.5をデフォルトの作業馬として、本当に難しいサブタスクにはOpus 4.7またはGPT-5.5へ選択的にエスカレーションする方法です。 **競争状況:** - Claude Codeは、年間売上25億ドルを超え、30万以上のビジネス顧客を持つと報告されており、直接的な競争圧力を生んでいます。Anthropicの構造的優位性—Cursorが支払えない価格でClaude Codeを提供し、CursorがAnthropicに推論費用を支払う—は、社内でComposerを構築する主要因でした。 - WarpのCEO Zach Lloydのコメントが市場の感情を捉えています：「Cursorは死んだというミームは信じないが、IDEは死んだというのは本物だ」。市場は自律コーディングエージェントに移行しており、Composer 2.5はCursorの回答です。

ユースケース

## 具体的なユースケースとComposer 2.5を選択すべきタイミング ### 1. 大量のマルチファイルリファクタリング **例:** FastAPIモノリスの40以上のファイルにわたる、カスタムJWTからAuth0への認証移行。 **Composer 2.5を選ぶ理由:** ファイル操作のツール呼び出し精度が高く、長いリファクタリトレースにわたってコードベースのコンテキストを維持します。SWE-Bench Multilingual（79.8%）はこのワークロードを直接反映しています。Opus 4.7に対する14倍のコスト優位により、リファクタリングがエージェント作業の大部分を占める場合、明確なデフォルト選択肢となります。リファクタリングがトップオブディストリビューションの知性を必要とする真に新しいアーキテクチャ推論を伴わない限り、Opus 4.7よりこれを選択してください。 ### 2. CI媒体の自動コードレビューおよびテストスキャフォールディング **例:** 2,000以上のエージェントタスクを月に持つモノリポジトリで、自動PR分析の実行、包括的なテストスイートの生成、ドキュメント作成。 **Composer 2.5を選ぶ理由:** スタンダードの$0.07タスクあたり対フロンティアモデルの$4〜5では、月間コスト差は同一ボリュームで$140対$8,000〜$10,000となります。これらの定義された反復可能なタスクでの品質差は無視できます。ここが、チーム予算にとってComposer 2.5のコスト効率が最も革新的な場所です。 ### 3. Cursor IDEでのフルスタック機能実装 **例:** Next.js、Supabase、Tailwindを使用したリアルタイム共同タスク管理アプリの構築—RLSポリシー、楽観的UI更新、コンポーネントライブラリの接続を含む。 **Composer 2.5を選ぶ理由:** Cursor IDEエージェントループ専用に設計されており、優れたマルチファイルスキャフォールディングと指示追従性能を持ちます。「Fast」モードは会話的なペアリングレベルのレイテンシを提供します。機能が大量のターミナル/インフラ作業を伴わない限り、GPT-5.5よりこれを選択してください。 ### 4. 長期間のデバッグセッション（ただし条件付き） **例:** 5つのサービスからなるDocker Composeセットアップでのネットワーキング問題の診断。 **Composer 2.5を選ぶ理由（部分的）:** 智能的なツール使用とログ検査を伴う反復的なデバッグで良好に機能します。ただし、デバッグが主にシェル主導（dockerコマンド、ログ解析、CI調査）の場合、GPT-5.5の13ポイントのTerminal-Bench優位性により、その特定のサブタスクではより良い選択肢となります。推奨パターンは、全体セッションにComposer 2.5を使用し、シェル中心の調査ステップでGPT-5.5へエスカレーションする方法です。 ### Composer 2.5を選択すべきでない場合 - **シェル中心のDevOps自動化**（ターミナル作業が30%以上）：GPT-5.5にルーティング。 - **>150Kトークンのコンテキスト要件:** 1Mトークンウィンドウを持つOpus 4.7にルーティング。 - **マルチプロバイダー/反ロックインアーキテクチャ:** Composer 2.5はCursor専用です。プロバイダー移植性にはOpus 4.7またはGPT-5.5を選択。 - **最も重要な一回限りの推論**（アーキテクチャレビュー、新しいアルゴリズム設計）：max設定のOpus 4.7がまだ極端な尾部でリードします。