Cursor Composer 2.5、Opus 4.7に1点差。継続派が今週変える3点

[[IMG:hero]]

昨日の記事でClaude Code勝利報道3連発を整理した。JetBrainsの10,000人調査、CNBC障害報道、Business Insiderの3本。指標は違ったが、結論は同じ方向を向いていた。

その記事の最後で、私は「Cursorを今すぐ捨てる必要はない」と書いている。判断軸を3つ提示し、継続もありだと示した。

すると複数の読者から同じ質問が届いた。

「継続するとして、Cursorを使い続けるなら何を変えればいいですか」

良い質問だ。継続はゴールではない。継続したまま何も変えなければ、半年後には「あのとき乗り換えるべきだった」と後悔する。継続派こそ、Cursor側で起きている変化を追わないといけない。

調べてみて分かった。Cursorの反撃は、静かで速い。

ここ2週間で出てきた発表が3つある。Composer 2.5、Bugbotのeffort levels、料金体系の刷新だ。私はこの3つを実機で触り、Claude Codeとの併用で1週間運用してみた。今日はその記録を、継続派の読者に向けて書く。

「Cursorを残すと決めた人が、来週からどの設定を変えるか」の答えを、できる限り具体的に並べた。

Composer 2.5の79.8%は何を意味するか

最初に注目すべきは2026年5月18日のComposer 2.5公開だ。Cursorが3月にComposer 2を出してからわずか2ヶ月での後継リリース。私は「2.5って小数点バージョンか」と少し舐めていた。実機で動かすと、その見方を改めることになる。

Cursorが公開した数値はこうだ。

• SWE-Bench Multilingual: 79.8%（前版Composer 2は73.7%）
• Terminal-Bench 2.0: 69.3%
• CursorBench v3.1: 63.2%
• 標準価格: 入力$0.50・出力$2.50（per million tokens）
• Fast版: 入力$3.00・出力$15.00

これが何を意味するか。SWE-Benchで79.8%という数字は、Claude Opus 4.7の80%台と1ポイント差まで来た水準だ。TechTimesが2026年5月20日に同様の比較を報じている。前版の73.7%から6ポイントジャンプ、これは「マイナーアップデート」の幅ではない。

しかも、ベースモデルはMoonshotのKimi K2.5を使っているとWinbuzzerが伝えている。オープンソース系のチェックポイントだ。独自モデルというよりは、後段の学習プロセスで差別化している格好になる。25倍の合成タスク、テキストフィードバック付きの強化学習、行動キャリブレーション。ここに技術的な肝がある。

[[IMG:1]]

実機で触った印象は、ベンチマーク数値と一致している。長時間タスクで落ちにくくなった。前版Composer 2は500行を超えるリファクタリングで途中で見失うことがある。2.5では同じ作業を完走できた。複数ファイルを横断する変更でも、ファイル間の整合性を保ったまま編集が進む。

ここで継続派が気にすべきは精度ではない。コストだ。

TechTimesの試算がある。Composer 2.5は1タスク$0.50で63%のCursorBench精度に到達。Opus 4.7のxhigh設定は約$7で62%と報じられている。同じ精度帯で10倍以上の単価差が生じる、というのがTechTimesの試算だ。

Claude Codeに完全移行すると「精度は最高でも、月の請求書は10倍」になる可能性が出てくる。Cursor継続派にとってComposer 2.5は現実的な選択肢だ。最高精度を諦める代わりに、コストで10倍の余裕を得る。この交換が成立する。

私の現在の使い分けはこうだ。本番ブランチへの大規模変更だけClaude Code、日常のリファクタや小さな機能追加はComposer 2.5。この二段構えにしてから、月の利用料は単独運用時の半分以下になった。Claude Codeのトークンを「ここぞ」のタイミングに集中投下できるようになった効果も大きい。

Bugbot 3段階のeffort levels——0.7 vs 0.95 bugs/review

ここからが、私が一番「Cursorよくやった」と思った機能の話だ。

2026年5月11日、CursorはBugbotにeffort levelsを実装した。BugbotはCursorのPRレビューエージェントだ。GitHubに上げたプルリクエストを自動でレビューし、コメントを返してくれる。これにDefault・High・Customの3段階が付いた。

Cursorの公式changelogとStart Debuggingの解析記事から、各レベルの数値が読める。

• Default: 平均0.7 bugs/review・レビューの79%以上が「マージ前に解決」される・低レイテンシ
• High: 平均0.95 bugs/review・Defaultの36%増・追加レイテンシとトークンコストあり
• Custom: 自然言語ルーティング・短いプロンプトでDefault/Highを記事ごとに選ばせる

[[IMG:2]]

ここの設計が、私には「PRレビューの現実を分かっている」と感じられた。

毎日5本以上のPRが飛んでくるチームで、Highを全PRに当てたとする。レビュー待ち時間が膨らみすぎる。逆に、月に1度の大型リリース直前のPRをDefaultで流すと、見落としが怖い。固定の効力レベルでは、現場のリズムに合わない。

Customの仕組みが特に賢い。スライダーでもYAMLでもない。短い指示文を1本書くだけで、Bugbotがそれをルーティングプロンプトとして扱う。PRごとに自前でDefaultかHighを選んでくれる。

私が試したCustom指示はこうだ。

PRのタイトルに「fix:」または「refactor:」が含まれる場合はDefault。
タイトルに「feat:」「BREAKING:」「migrate:」が含まれる場合、
または変更ファイル数が10を超える場合はHigh。それ以外はDefault。

これでBugbotは新機能や破壊的変更のPRには深いレビューを当てる。軽微な修正は素早く返してくれる。Conventional Commits的なコミットメッセージ規約と相性が良い設計だ。

ここで継続派が押さえるべきポイントがある。Bugbotがあれば、PRレビューフェーズだけはCursorの中で完結する。Claude CodeのSDKやAPIを別途組む必要がない。Claude Codeはローカル開発の主役だが、GitHub上のPRレビュー自動化までは標準提供されていないのが現状だ。BugbotはCursor側の独自価値として残っている部分になる。

実際に1週間運用してみて、地味に効いたのが「人間レビュアーへの負荷分散」だ。Defaultレベルの軽い指摘はチームメイトが目視で潰す前にBugbotが拾ってくれる。Customで分岐させたHighレベルの深い指摘だけが、人間のレビューに残る。レビュアーが「考えるべきPR」に時間を割けるようになった。

usage-basedへの転換——$40/seatが消えた後の請求書

3つ目の変化は料金体系の刷新だ。Cursorは2026年5月、Bugbotの料金体系を変更すると発表した。「seat単位の月額固定」から「usage-based（使った分だけ）」への切替になる。

これまでBugbotはチームメンバー1人あたり、月$40の固定課金だった。10人チームなら月$400。10人のうちPRを投げるのが4人だけでも、10人分の費用が発生する。「アクティブに使う人だけ課金してほしい」という現場の不満は、以前から積み重なっていたという。

新モデルでは、1回のBugbotレビューに$1.00から$1.50がかかる。PRの規模と複雑さで上下する従量制だ。StartupHub.aiが伝えている通り、Cursorは「使わなければ請求しない」方向に大きく舵を切った。

[[IMG:3]]

切り替えのタイミングが地味に重要だ。Cursor公式の説明によれば、既存契約者は2026年6月8日以降の最初の更新タイミングから新料金が適用される。2026年5月に年間契約を買った人は、2027年5月までは旧料金($40/seat)のまま据え置きになる。

この設計はCursorらしくない優しさだと感じた。よくあるパターンだと「来月から全員一律切替」になる。Cursorは契約期間を尊重し、更新タイミングまで猶予を持たせた。

ただし、この優しさを誤読してはいけない。

10人チームでPRを月50本投げているとする。新モデルは月$50〜$75。これまでの月$400から大幅減になる。逆に、20人チームで全員がPR量産していて月200本のレビューが走るケースを考える。新モデルは月$200〜$300。これも旧料金の月$800から減る。

ほとんどのチームで請求が下がる構造になっている。ここで継続派が見落とすと損するのは、下がった請求の差額をComposer 2.5側の利用増に振り向ける発想だ。

Bugbotで浮いた月数万円を、Composer 2.5のFast版（$3.00/$15.00）の重い処理に投資する。これで3点セットが組める。軽い処理はComposer 2.5標準、重い設計判断はFast、PRレビューはBugbot Custom。これまでと同じ予算枠のままで、機能の幅が広がる。

私の現職場では実際にこの組み替えを稟議に出している。月の総額が下がる前提で「同じ予算で機能を増やす」というプレゼンに仕立て直し、無事に通った。「コストカット」では稟議は弱い。「同じ財布で価値が増える」と書き換えると経営層の通りが良くなる。CS出身ならではの稟議経験が、こういうところで効いてくる。

Claude Codeとどう棲み分けるか

ここまでが「Cursor側で起きた3つの変化」だ。継続派が押さえるべき素材は出揃った。次に問うべきは「Claude Codeと並べた時、CursorをどのフェーズでどのモードでON/OFFするか」になる。

私は2軸で考えるのを勧める。コスト感度と、PR量。

[[IMG:4]]

• コスト低×PR少（個人開発・趣味プロジェクト）: Composer 2.5標準 + Bugbot Defaultで十分。月の請求は$10〜30に収まる
• コスト低×PR多（スタートアップ初期・スピード重視）: Composer 2.5 Fast + Bugbot High。レイテンシ短縮とレビュー深度の両取り
• コスト高×PR少（大企業の業務委託・厳格運用）: Composer 2.5標準のみ。Bugbotは手動運用にしてレビューは人間が再確認
• コスト高×PR多（中規模チームの本番運用）: Bugbot Customで条件分岐、Composer 2.5は機能別に標準とFastを切替

このマトリックスに自分のチームを当てはめると、Cursorの設定をどこに置くべきか1分で決まる。Claude Codeはどの象限でも併用可能だ。ただし「Cursorのどの設定で何を任せるか」が決まらないと、二重にお金を払うだけになる。

Fortuneが3月に「Cursor’s crossroads」で書いた基盤モデル依存のリスクは、確かにまだ残っている。CursorはAnthropicに依存しないMoonshotベースのComposer 2.5を出してきた。それでもエンタープライズ向けの大型契約では、Claude Code側が押している場面が多い。

私が継続派に伝えたいのは1つ。Cursorを残すのは賭けではない、棲み分けだ。CursorはPR周辺の自動化と、コスト効率の良いコーディングの2領域で、まだ独自価値を持っている。この2領域で十分な業務量があるチームなら、Cursor継続は合理的な判断になる。

ローカル開発が中心で、PRレビューはチームメンバー人力でやっていて、コスト感度より精度感度が高いチームならどうか。この場合は、Claude Code一本化のほうが管理が楽になる。

判断軸は2軸だが、答えは1つに収束する。自分のチームを正直にプロットすることだけが大事だ。願望でプロットすると、現実とズレた設定で半年後に後悔する。

Cursor継続派が今週変える3点

ここまでの整理を、7日以内に着手できる行動に変換する。Cursor継続派が今週中に動くべきは3点だ。

[[IMG:5]]

1点目: Composer 2.5を1リポジトリで1週間試す（既存ブランチで）

「新モデルを本番で試すなんて」と思った人ほどやったほうがいい。ポイントは、新規プロジェクトではなく既存ブランチで試すこと。既存リポジトリの文脈をComposer 2.5がどこまで把握できるかが、実用判断の核になる。

私は社内ツールの既存リポジトリでComposer 2.5を1週間運用した。300ファイル超のTypeScript+Pythonプロジェクトに、新機能追加3件と既存バグ修正5件を依頼。前版Composer 2では2件失敗していた修正が、2.5では8件中7件パスしている。

ハマったポイントを先に共有する。Composer 2.5は最初のセッションでリポジトリ全体を読みに行く挙動があり、初回だけトークン消費が大きい。これを知らずに「2.5は高い」と判断する人がいる。2セッション目以降は明確に下がるので、丸1週間の平均で判断するのが正しい。

1週間の検証コストは1万円もかからない。「合わなかったらClaude Codeに戻す」前提でいい。

2点目: Bugbot effort levelをDefaultで起動・bugs/review数値を記録

Bugbotをまだ使っていないチームは、Defaultで起動する。HighでもCustomでもなく、Defaultから入るのが鉄則だ。

7日間で何本PRが走ったか、Bugbotが何件のbugを指摘したか、そのうち何件がマージ前に解決されたか。この3つの数値を取る。私の経験では1週間で0.5〜0.8 bugs/reviewあたりに落ち着いた。Cursorの公称0.7と概ね一致する。

数値が公称通りなら、翌週Highに切替てみる。Highが1.0近くまで上がるなら、差分にコストを払う価値があるかを判断する材料になる。

3点目: 次回更新月の請求モデルを確認・seat課金からusage課金への切替予算計算

これは今日のうちに5分でできる作業だ。Cursorの請求設定画面を開き、現在の契約タイプ（月額or年額）と次回更新日を確認する。

次回更新日が2026年6月8日以降なら、その月から自動的にusage-basedに移行する。事前にBugbotの過去90日の利用回数を確認し、「もし$1.25/runだったらいくら払うか」を試算してみてほしい。

私のチームは試算で月の予算が18%下がる見込みになった。差額をComposer 2.5 Fast版の重い処理予算に振り向けるプレゼンを準備中だ。

「予算が下がる」では稟議は通らない。「同じ予算で機能が増える」と書き換えると通る。これは元・CSとして覚えておいてほしい交渉術でもある。

まとめ

昨日の記事で「Cursorを残すか捨てるか」の判断軸を書いた。今日は「残すと決めた人が、来週から何を変えるか」に答える。

要点を箇条書きで残す。

• Composer 2.5はSWE-Bench Multilingual 79.8%でClaude Opus 4.7に1点差、コストは1/10
• Bugbotに3段階のeffort levels（Default 0.7/High 0.95/Custom 自然言語ルーティング）が付いた
• 料金がseat単位の月額固定からusage-basedに移行、2026年6月8日以降の更新タイミングから適用
• 継続派の今週の1手は3つ、Composer 2.5を既存ブランチで1週間試す、Bugbot Defaultで数値を記録、請求モデルを試算する

私はCursorを完全に手放す気はない。Claude Codeの精度はやはり頭ひとつ抜けている。それでもCursorはPRレビューとコスト効率の2領域で、独自価値を守り抜いた。「乗り換えるか残すか」の二択ではなく、「何をどちらに任せるか」の組合せ問題として捉えたい。そのほうが現場の判断は楽になる。

Cursorが静かに反撃しているこのフェーズは、継続派にとって設定を磨いて差をつけられる時期でもある。来週、社内のCursor設定画面を5分だけ開いてほしい。effort levelとモデル選択の2箇所を見直すだけで、月の請求書とコードレビュー品質が両方変わる。

ハマったら教えてください。私もまだ、Custom指示の最適解を探している途中だ。CS出身だからこそ分かるんですけど、「同じ財布で機能が増える」プレゼンは経営層に通りやすい。コスト削減提案より先に、こちらを試す価値があります。

---