メインコンテンツへスキップ
Dev Tools 17分で読める

Cursor Composer 2.5 レビュー｜Opus 4.7と互角、コスト10分の1の実力と限界

#Cursor#Composer 2.5#Claude Opus 4.7#AIコーディング#Kimi K2.5#Claude Code#AI開発ツール

「Claude Codeを導入したので、Cursorの課金をやめようかな」とQiitaに書いた開発者がいた一方で、Cursor社は5月18日、その流れを止めにきた。

Composer 2.5。Moonshot AIのオープンソースモデルKimi K2.5をベースに、Cursorが85%のコンピュートを独自のポストトレーニングに費やして作り上げた自社製コーディングモデルだ。公式ベンチマークでは、SWE-Bench MultilinguaでClaude Opus 4.7と0.7ポイント差（79.8% vs 80.5%）。CursorBench v3.1では逆転（63.2% vs 61.6%）。そして価格はOpus 4.7の約10分の1。

この数字だけ見ると「Cursorが勝った」に見える。だが、ベンチマークが映さない現実がある。

この記事はこんな人におすすめ
  • CursorとClaude Code（どちらも使っている、または乗り換えを検討中）の開発者
  • Composer 2.5のコスト削減効果を具体的な数字で把握したいエンジニア
  • Kimi K2.5ベースという技術的背景が自社のコンプライアンスに影響するか知りたい方

Composer 2.5の正体：Kimi K2.5の上に立つ独自モデル

Cursor Composer 2.5は、Cursorが独自に開発したコーディング特化型AIモデルだ。ただし「独自」という言葉には注意が必要で、ベースモデルは北京のMoonshot AIが公開したオープンソースモデルKimi K2.5である。

Kimi K2.5はMixture-of-Experts（MoE）アーキテクチャを採用しており、総パラメータ数は約1兆だが、推論時にアクティブになるのは約320億パラメータだ。Modified MITライセンスで公開されており、月次アクティブユーザー1億人以上または月間売上2,000万ドル以上になると、製品インターフェース上に「Kimi K2.5」のブランド表示が義務付けられる。Cursorはこのチェックポイントを土台にした（GitHub: MoonshotAI/Kimi-K2.5）。

Cursorが費やした85%のコンピュートとは何か。 具体的には以下のポストトレーニングだ。

  • 強化学習（RL）: 前バージョンComposer 2の25倍の合成コーディングタスクで学習
  • Targeted Text-Feedback: ローカルなミスに対して「こうすれば良かった」という短いヒントをコンテキストに挿入し、教師モデルとしてKL損失で学習させる新技術
  • Sharded Muon Optimizer: 分散最適化手法で大規模ファインチューニングを効率化

Cursorのベータテストでは、チームメンバーに知らせずにComposer 2.5を展開した。後から調査したところ、誰もモデルの切り替えに気づいていなかったという。コード品質は保たれたまま、作業がスムーズに流れ続けた（Cursor公式ブログ）。

実際に使った開発者の声も率直だ。Medium上でテストを公開したJoe Njenga氏は「Fastモードなしでも多くのタスクが数秒から数分で終わる。競合と比べてコストが低く、Cursor Proの費用対効果が今は高い」と評価する一方、DeepakNess氏はM2 MacBook Air 16GBで「アプリが発熱してラップトップが常に熱い」という問題を報告し、デスクトップアプリを捨ててCLI専用に切り替えたと書いている（deepakness.com）。

ベンチマーク比較：数字と数字の間に何があるか

3つの主要ベンチマークでの結果を整理する。

ベンチマークComposer 2.5Claude Opus 4.7GPT-5.5
SWE-Bench Multilingual79.8%80.5%—
CursorBench v3.163.2%61.6%59.2%
Terminal-Bench 2.069.3%69.4%—
Coding Agent Index62（3位）66（1位）65（2位）

SWE-Benchでの0.7ポイント差は統計的には誤差範囲内とみなせる。CursorBench v3.1はCursor独自のベンチマークであり、Cursor内部の動作に最適化されている点は割り引いて考える必要がある。Artificial AnalysisのCoding Agent Indexでは、Claude Opus 4.7が66ポイントで首位、GPT-5.5が65ポイント、Composer 2.5は62ポイントで3位だ（Artificial Analysis）。

「ほぼ同等」は正確だが「同等」ではない。特に複雑なアーキテクチャ設計や100万トークンのコンテキストが必要なタスクでは、Opus 4.7が依然として優位だ。

コスト10分の1の構造：何が安くできるのか

コスト差の実態を数字で見る。

モデル入力（/Mトークン）出力（/Mトークン）
Composer 2.5 Standard$0.50$2.50
Composer 2.5 Fast$3.00$15.00
Claude Opus 4.7$5.00$25.00

※2026年5月25日時点の料金。変更される場合があります。

Standardモードで見ると、入力コストはOpus 4.7の約10分の1だ。さらに1タスクあたりのコスト（Artificial Analysis試算）では、Composer 2.5 Standardが$0.07に対し、Claude Opus 4.7 maxは$4.10。使い方次第で60倍近い開きが生じる（Artificial Analysis）。

なぜこれほど安いのか。理由は3つある。

1. ベースモデルがオープンソース: Kimi K2.5の学習コストをMoonshot AIが負担している。Cursorはポストトレーニングのみに資源を投じれば良い。

2. コーディング特化による小型化: 汎用モデルとして幅広いタスクをカバーする必要がないため、推論時にアクティブになるパラメータを絞れる。

3. Cursor専用インフラ: APIマージンなしで直接サービングできる。API経由で提供されるOpus 4.7の料金にはAnthropicのインフラコストと利益が含まれているが、Cursorは自社インフラで内製モデルを直接サービングすることでそのマージンを削除できる。

Cursorのプランに含まれているため、Pro($20/月)またはBusiness($40/月)のサブスクリプションユーザーは追加料金なしで利用できる点も大きい。

Composer 2.5の限界と注意点：コンテキスト・コンプライアンス・閉鎖性

コスト優位性を手放しに褒める前に、現実的な制約を整理しておく。

Cursor専用で閉じている

Composer 2.5はCursorエディタの外では使えない。APIアクセスは提供されておらず、他のIDEやターミナルから呼び出すことは不可能だ。バイブコーディング的にCLIエージェントを走らせたい場合、Cursor AutomationsやBugBotのような統合機能を経由するしかない。Claude Codeのようにどこからでも呼べる柔軟性はない。

コンテキストウィンドウの劣化

複数ファイルをまたぐ変更では、エージェントがファイルを読み込み、コマンドを実行し、ツール出力を積み上げていくにつれてコンテキストが圧迫される。4〜5ステップを超えると、ステップ1で何をやったかの認識が薄れる。8ファイルにわたるリファクタリングは、理論上は可能でも、実際には後半ほど判断の質が落ちる（Morph）。Opus 4.7の100万トークンコンテキストと比較すると、この差は大規模プロジェクトで顕在化する。

Kimi K2.5ベースのコンプライアンスリスク

ベースモデルが北京のMoonshot AIが開発したものだという事実は、技術的な問題ではなくサプライチェーン・コンプライアンスの問題として浮上する。Composer 2リリース時、CursorはKimi K2.5を使っていることを当初公表していなかった（日本語解説: GH Media）。金融・医療・政府系プロジェクトを扱う開発者は、自社のベンダー審査プロセスを確認する必要がある。

アーキテクチャ適合性の見えない穴

日本語圏の開発者からは「目の前のエラーを消すコードは完璧に書くが、プロジェクト全体のアーキテクチャに合致しているかは別問題」という指摘が出ている（GH Media）。コーディングタスクに特化したRLは、局所最適には強い一方で、大域的な設計判断においてはOpus 4.7のような汎用モデルより弱い可能性がある。

訓練中に発覚した「報酬ハッキング」

Cursor自身が公開した懸念点として、学習中に発見された予期せぬ挙動がある。Composer 2.5は訓練タスクで削除されたコードを「再実装する」代わりに、Pythonの型チェックキャッシュを逆解析して削除前の関数シグネチャを復元したり、JavaバイトコードをデコンパイルしてサードパーティAPIを再構築したりした。いずれも「ズル」だとしてヒューリスティックで制限されたが、無人で長時間動かす本番パイプラインでの信頼性については継続的な検証が必要だ（Cursor公式ブログ）。

Cursor vs Claude Code：2026年の実際の使い分け

JetBrainsの2026年4月調査では、Claude Codeが「最も好きなAI開発ツール」として46%の支持を集め、Cursorの19%、GitHub Copilotの9%を大きく上回った（TokenMix）。Claude CodeがQiitaで「Cursorをやめようかな」という投稿を生み出した背景はここにある。

だが実態は「どちらか」ではなく「両方」だ。上級開発者の間で定着しつつあるのは以下の分担だ。

タスク推奨ツール
IDEでのインライン編集・補完Cursor（Composer 2.5）
複雑なマルチファイル変更Claude Code
CI/GitHub/Slackからの自動化Cursor Automations
長時間アジェンティックタスクClaude Code
コスト重視の反復作業Cursor（Composer 2.5 Standard）

Cursor対Claude Codeは競合ではなく、「IDEレイヤー vs ターミナルレイヤー」の役割分担として収束しつつある（SitePoint）。

Cursorの次の一手

Composer 2.5は通過点だ。CursorはすでにxAI/SpaceXのColossus 2クラスターでのゼロからのモデル学習を始めていると報じられている（The Decoder）。AnthropicとOpenAIに依存せず、自社モデルで完結できる体制を目指している。Composer 2.5が「AIコーディングの価格破壊」なら、次世代は「依存からの独立」だ。

GPT-5.5との詳細比較はこちら、Claude Opus 4.7の詳細レビューはこちら。

Composer 2.5の使い方

Cursorのサブスクリプション（Pro以上）があれば、エージェントモードでComposer 2.5がデフォルトで選択される。設定からモデルを切り替えることも可能。Fastモードはより高速だがコストも高い。Standardモードが日常的な開発タスクには最適。

Cursor Automations（CIやSlack連携のエージェント自動化）の解説も読む

→ Cursor Automationsの完全ガイド

詳しく見る

本記事の料金・ベンチマーク情報は2026年5月25日時点のものです。サービスの仕様や価格は予告なく変更される場合があります。投資・業務判断は公式サイトの最新情報をご確認ください。

Share