Cursor Composer 2 ついにリリース。その性能は・・・速いだけじゃない！

🙌 結論からいうと

Composer 2 は「新モデルが出た」以上に、実務で使うと返答の速さと、修正の噛み合い方が前より良くなっていると感じた、というのが私の結論です。 ベンチマークの数字より 「一回で欲しい方向に寄る率が上がったか」 の方が、現場ではずっと効いてきます。
速いだけでズレるモデルだと、結局こちらが言い直して 往復が増える んですよね・・・。そこが減ったのが、いちばんありがたかったです 🙌

公式では 2026年3月19日に Composer 2 を公開し、Terminal-Bench 2.0 で 61.7、SWE-bench Multilingual で 73.7 などのスコアを掲げています。料金は案内どおり 入力 $0.50/M・出力 $2.50/M（標準）という理解で読んでいます。数値や価格はアップデートで変わるので、最新は Cursor 側の表示を優先してください 👀

👀 この記事の前提（Cursor）

Cursor エディタの Composer 周りの話です。他ツールとの横比較ではなく、私が普段の修正タスクで触った感触に絞ります。

話題の背景として、公式が示している CursorBench（コーディング性能を測るベンチマークの一つ）の結果を、Performance vs. Cost の散布図でまとめた図を置きます。縦軸は CursorBench のスコア（%）で上に行くほど高性能、横軸はタスクあたりの中央値コストで、右に行くほど安い（軸の向きに注意）という読み方です。右上に近いほど「安くて精度が高い」ゾーンと捉えるとわかりやすいです。

図では Composer 2 が、高精度側の GPT-5.4 系に近いスコア帯を保ちつつ、コストはかなり低めに寄っているように見えます（対して Composer 1.5 はスコア・コストとも別の位置）。あくまでベンチ上の比較で、私のプロジェクトでの体感や往復の減り方とはイチイチ一致しないので、「公式がどう位置づけているか」の一次資料として見てください 👀

💡 今回なにが話題になったか

大きいのは二つだと思います 💡

• 公式が Composer 2 を「frontier-level coding intelligence」として打ち出したこと。Terminal-Bench 2.0 では、案内されている範囲では Composer 1.5 の 47.9 から 61.7 へ上がった、という説明があります。
• 報道などで一部ベンチでは Claude Opus 4.6 を上回ったといった見出しが流れて、注目が集まったこと。

要するに、「数字が強い」だけじゃなくて 製品として前面に出したのが話題の引き金、という感じです。

✨ 触って、最初に感じた変化

いちばん手応えがあったのは 初手の提案が素直 になったことです。地味に効くやつです ✨

実務だと、

• 既存コードを読ませて改修方針を出す
• バグの原因候補を絞る
• 影響範囲を見ながら直す
• ついでにテストを足す

みたいな流れが多いと思うんですが、以前は 速いけど前提がズレる とか 方向は近いけど肝心のところが外れる がそこそこありました。Composer 2 は、文脈の拾い方が一段良くなったかも・・・ という感触です。

特に 既存ファイルとの整合を保ったまま差分を進める ときに助かった。一発完成の魔法ではないです。正直そこは言い過ぎ。2〜3 往復だったのが 1〜2 往復くらい、は普通に感じました。

💡 実務で効いた使い方

私の仕事だと、**新規より「既存に足す・直す」**の方が多いですよね。そこで効いたのは次の感じ 💡

• 既存実装を壊さずに足す
• 型や命名のルールを崩さない
• 責務の分け方に合わせる
• 小さい差分で出したい

調べ物だと「高性能です」で終わりがちですが、触って分かるのは 大きい一発生成より、小さな修正の精度 だったりします。

私は レビュー前の整形・叩き台 → 差分を見ながら微調整 の流れでよく使います。「この関数の責務は変えずに」「命名は既存に寄せて」「このファイルだけで閉じて」みたいな指示への追従が、前よりストレスが少なかったです。ここ、実務で地味に効く・・・！

そのうえで個人的な話ですが、Pro プランあたりで API 使用量やクォータを気にしながら、あえて Composer だけをメインにしないようにしていた時期もありました。ただ Composer 2 が出てからは、こちらをメインルートとして使っても全然いいかもという感覚に寄ってきています。往復が減って実質の消費の読みやすさもあるし、先に載せた コスト対性能の整理とも雰囲気としては噛み合う、という読み方です（私のダッシュボードの数字は別なので、ここはあくまで感触の話です 👀）。

😅 万能じゃないところ

長めの作業や複数ファイルにまたがる修正でも強くなった感じはありますが、前提がズレたまま進めると普通に危ない のは変わりません 😅

なので私は今でも、

• 要件を短く整理してから投げる
• 触ってほしくないところを先に書く
• 差分は必ず読む

の三つは崩していません。ベンチが強いからといって 「モデルが強い＝全自動で安心」 にはならないので、過信はしない方がいいと思います。チームの書き方・レビュー文化・どこまで任せるかの方が効くことも多いです。

👍 まとめ

Composer 2 は 話題の新モデルというより、日常の修正にちゃんと寄せやすくなったアップデート だと感じました 👍 公式のベンチ改善はインパクトがありますが、現場で刺さるのは 速さより「ズレにくさ」 。そこが改善しているのがよかったです。

私の使い方も、「速いからとりあえず」から 「既存に寄せる作業でも使いやすいから」 に少し変わりました。エンジニア目線だと、そこが大きいかなと。

Cursor を触っていて最新の流れを試したいなら、ベンチの数字だけで決めず、普段の修正タスクに一回当てるのがいちばん早いです・・・！

---

※ 製品名・料金・ベンチスコアは更新で変わります。最新は Cursor の公式情報を確認してください 👀