Cursorが2026年5月18日、自社開発のコーディングエージェント向けAIモデル「Composer 2.5」を発表しました。前モデルComposer 2と比較して知能・挙動の両面で大幅に向上し、ベンチマークによってはGPT-5.5を上回る数値を記録。さらに初週は新モデルの利用枠が2倍になるキャンペーンも実施中です。本記事ではリリース速報にとどまらず、ベンチマーク数値の実務的な意味、Opus 4.7/GPT-5.5/Claude Codeとの使い分け、Kimi K2.5ベース問題のリスク評価、Cursor内での具体的な切り替え手順まで、エンジニアが導入判断するために必要な情報を網羅して解説します。
- Composer 2.5の核心：何が変わったのか、なぜ騒がれているのか
- SWE-Bench Multilingual 79.8%・Terminal-Bench 69.3%・CursorBench 63.2%の実務的な意味
- Opus 4.7 / GPT-5.5 / Composer 2.5 / Claude Codeの用途別使い分けフロー
- 料金体系の徹底解説とコスト試算（標準版 / 高速版 / 2倍キャンペーン）
- Cursor内での切り替え手順とおすすめ設定（Fast mode / Standard mode）
- Kimi K2.5ベース問題：日本企業の調達観点・米国規制動向からのリスク評価
- SpaceXAI共同開発の次世代モデル（10倍計算量）の見通し
- 初週2倍キャンペーンを最大活用する具体的な使い方
- 導入すべきケース / 見送るべきケースの判断基準
Composer 2.5とは何か：3分で核心を理解する
Composer 2.5は、AIコードエディタ「Cursor」を開発するAnysphere社が2026年5月18日にリリースした、自社開発のエージェント型コーディングAIモデルです。公式アナウンスでは「これまでで最も強力なモデル」と位置付けられています。
最初に押さえるべき要点は次の4つです。
- 位置付け：Cursor専用のエージェント型コーディングモデル。汎用チャットボットではなく、長時間のタスク継続・複数ファイル編集・ツール呼び出しといった「エージェント的なソフトウェア開発作業」に特化
- 性能：SWE-Bench Multilingualで79.8%を記録し、Claude Opus 4.7（80.5%）に肉薄、GPT-5.5（77.8%）を上回る。Terminal-Bench 2.0でも69.3%とOpus 4.7（69.4%）と同水準
- 価格：標準版が入力100万トークン$0.50・出力$2.50。Opus 4.7やGPT-5.5の約10分の1のコストでフロンティアモデル級の性能を実現
- キャンペーン：リリースから初週はComposer 2.5の含まれる利用量が2倍に
ベースモデルは、北京のスタートアップ企業Moonshot AIが開発したオープンソース重みのMoEモデル「Kimi K2.5」です。これはComposer 2と同じ基盤ですが、Composer 2.5では計算予算の85%が独自の事後学習と強化学習に投入されており、合成タスクは前モデルの25倍に拡大されています。
背景にはAnthropicのClaude Codeの急成長があります。Claude Codeは年換算売上25億ドル・導入企業30万社超の規模に達しており、Cursorは他社推論APIへの依存というコスト構造を脱却する必要に迫られていました。Composer 2.5は独自エコシステム構築の布石として位置付けられます。
ベンチマーク詳細：数値が実務で何を意味するのか
Cursorが公開した主要ベンチマーク評価を、競合モデルと並べて整理します。
主要ベンチマーク比較表
| ベンチマーク | Composer 2.5 | Composer 2 | Opus 4.7 | GPT-5.5 |
|---|---|---|---|---|
| SWE-Bench Multilingual | 79.8% | 73.7% | 80.5% | 77.8% |
| Terminal-Bench 2.0 | 69.3% | 61.7% | 69.4% | 82.7% |
| CursorBench v3.1 | 63.2% | 52.2% | 64.8%(max) / 61.6%(default) | 59.2% |
| 1タスク平均コスト | 約$0.50 | — | 約$7 | 約$2.20 |
SWE-Bench Multilingualの79.8%が示すもの
SWE-Bench Multilingualは、GitHub上の実際のIssue解決能力を多言語のリポジトリで測定するベンチマークです。79.8%という数値は、実際のバグレポートやFeature Requestを与えた際に約8割を解決できる水準を意味します。前モデルComposer 2の73.7%から6ポイント以上の改善で、Opus 4.7（80.5%）にわずか0.7ポイント差まで肉薄しました。
実務的には、レガシーフレームワークやドキュメントが乏しい古いリポジトリでのIssue修正タスクにおいて、Opus 4.7とほぼ同等の問題解決力を期待できる水準と捉えてよいでしょう。
Terminal-Bench 2.0の69.3%の解釈
Terminal-Bench 2.0は、シェル中心のエージェント作業（コマンド実行、環境構築、ビルドシステム操作など）を評価します。Composer 2.5はOpus 4.7とほぼ同水準（69.3% vs 69.4%）を達成しましたが、GPT-5.5（82.7%）には約13ポイントの差を付けられています。
CI/CDパイプラインの構築、複雑なシェルスクリプトの自動生成、依存関係の解決など、ターミナル操作が主体のワークフローではGPT-5.5を選ぶ方が良い結果を得られる可能性が高いです。Composer 2.5はあくまで「Opus 4.7と同等の安定したターミナル操作性能」と理解してください。
CursorBench v3.1の63.2%が最も重要な理由
CursorBench v3.1は、実際のCursorエージェントの軌跡を反映した内部ベンチマークです。仕様が曖昧で複数ファイルに跨る現実的なIDE作業を再現しており、整理されたパズル的なプロンプトではなく「実際の開発現場のメッセージ」を想定しています。
このベンチマークでComposer 2.5は63.2%を記録。Opus 4.7のデフォルト設定（xhigh）の61.6%を上回り、最大設定の64.8%にも肉薄しています。GPT-5.5のデフォルト59.2%を明確に上回る数値です。
つまり「Cursorのエージェント機能を実際に使う前提なら、Composer 2.5はOpus 4.7のデフォルト設定よりも実用的」という解釈ができます。ただしこれはCursor自身が設計したベンチマークである点には留保が必要です。
コスト効率：1タスクあたり約$0.50という破壊力
最も衝撃的なのは、CursorBench v3.1で1タスクあたり約$0.50という低コストを実現している点です。同等のスコアを出すためにOpus 4.7のxhighモードでは約$7、GPT-5.5のxhighでは約$2.20以上が必要とされます。
長時間のリファクタリングや大規模デバッグなど、トークン消費が極めて多いエージェントタスクで運用コストを劇的に引き下げられます。「とりあえずエージェントを走らせて結果を見る」という試行錯誤的な使い方が、コスト面で現実的になった意味は大きいです。
料金体系を完全解説：標準版と高速版の使い分け
Composer 2.5には、価格と速度のトレードオフが異なる2つのバリアントが用意されています。
標準版（Standard）と高速版（Fast）の比較
| 項目 | 標準版（Standard） | 高速版（Fast） |
|---|---|---|
| 入力料金（100万トークンあたり） | $0.50（約80円） | $3.00（約477円） |
| 出力料金（100万トークンあたり） | $2.50（約400円） | $15.00（約2,380円） |
| 知能レベル | 同等 | 同等 |
| 応答速度 | 通常 | 高速 |
| デフォルト選択 | — | ○（インタラクティブ用途） |
| 適した用途 | バッチ処理、長時間タスク、コスト最適化 | 対話的なコーディング、即応性重視 |
知能（モデルの性能）は両者で同等です。違いは応答速度と料金のみ。Cursorのデフォルトは高速版になっているため、コストを抑えたい場合は明示的に標準版を選択する必要があります。
具体的なコスト試算（100万トークン消費した場合）
| シナリオ | Composer 2.5標準版 | Opus 4.7 | GPT-5.5 |
|---|---|---|---|
| 入力50万 + 出力50万トークン | 約$1.50 | 約$10〜15 | 約$5〜8 |
| 入力80万 + 出力20万トークン | 約$0.90 | 約$8〜12 | 約$4〜6 |
| 1ヶ月100M入力 + 30M出力 | 約$125 | 約$1,000〜1,500 | 約$500〜800 |
※Opus 4.7・GPT-5.5の数値は2026年5月時点の公開API料金からの概算です。
初週2倍キャンペーンを最大活用する方法
Cursor個人プラン契約者は、リリース後1週間（2026年5月18日〜25日頃まで）、Composer 2.5の含まれる利用量が2倍になります。普段Opus 4.7やGPT-5.5を使っているユーザーも、この期間中にComposer 2.5を試して自社コードベースとの相性を検証する絶好の機会です。
2倍キャンペーン期間中におすすめの検証タスク：
- 大規模リファクタリング：複数ファイルにまたがるリファクタリングをComposer 2.5に任せ、Opus 4.7と結果を比較
- 長時間デバッグ：再現性の低いバグの原因究明をエージェントに任せて思考過程を観察
- レガシーコード解析：ドキュメントが乏しい古いコードベースでの理解度をテスト
- テストコード生成：既存コードに対するユニットテストの自動生成品質を評価
- 多言語プロジェクトでの作業：SWE-Bench Multilingualで強かった多言語対応力を実プロジェクトで検証
Cursorでの切り替え手順とおすすめ設定
Composer 2.5への切り替えは数クリックで完了します。具体的な手順を解説します。
ステップ1：モデルピッカーから選択
右下のモデル名（例：claude-opus-4-7）をクリックし、モデル一覧を表示します。
リストの上部に新しく「Composer 2.5」が追加されています。デフォルトは高速版（Fast）です。
Settings → Models → Composer 2.5 → Mode設定で「Standard」を選択。コストを優先する長時間タスクではこちらを推奨します。
ステップ2：プロジェクト固有のルールを設定
Composer 2.5の性能を最大限引き出すには、.cursorrulesファイルでプロジェクト固有のコンテキストを与えることが重要です。これはGemini CLIでのGEMINI.mdやClaude CodeでのCLAUDE.mdに相当する仕組みです。
# プロジェクトルートに.cursorrulesを作成
$ touch .cursorrules記述例：
# プロジェクト概要
このプロジェクトはNext.js 14 + TypeScript + Prismaを使用しています。
# コーディング規約
- 関数はarrow functionで書く
- 型はinterfaceを使う（typeは使わない）
- コンポーネントはPascalCase、関数はcamelCase
- anyは原則禁止
# ディレクトリ構造
- コンポーネント: src/components/
- API: src/app/api/
- 型定義: src/types/
# Composer 2.5への追加指示
- 長時間タスクでは作業ログを200トークンごとにサマリーすること
- ツール呼び出しの前に必ず利用可能なツール名を確認すること
- テストが失敗した場合は3回までリトライ、それ以降は人間に判断を仰ぐステップ3：Cursor CLIでの活用
Composer 2.5はCursorのIDE版だけでなく、Cursor CLI（ターミナル版）でも利用可能です。長時間のバックグラウンドタスクを走らせる場合に有効です。
# Cursor CLIのインストール（未導入の場合）
$ curl -fsSL https://cursor.com/install.sh | sh
# Composer 2.5を指定して実行
$ cursor agent --model composer-2.5 \
"テスト失敗箇所を特定して修正してください"Opus 4.7 / GPT-5.5 / Composer 2.5 用途別使い分けフロー
ベンチマーク数値だけでは判断できない、実務での使い分けを体系化します。
判断フローチャート（テキスト版）
Q1：そのタスクは「コスト効率最優先」か？（長時間・反復・試行錯誤的）
→ Yes → Composer 2.5（標準版）を推奨
→ No → Q2へ
Q2：そのタスクは「ターミナル操作中心」か？（CI/CD、シェルスクリプト、環境構築）
→ Yes → GPT-5.5を推奨（Terminal-Bench 82.7%の圧倒的優位）
→ No → Q3へ
Q3：そのタスクは「真実性・正確性が最重要」か？（本番DB操作、セキュリティ、金融計算）
→ Yes → Opus 4.7（max設定）を推奨（CursorBench max 64.8%が依然首位）
→ No → Q4へ
Q4：そのタスクは「日常的な複数ファイル編集」か？
→ Yes → Composer 2.5（高速版）を推奨（コスト性能比が圧倒的）
→ No → Q5へ
Q5：そのタスクは「規制業界・サプライチェーン監査が厳しい環境」か？
→ Yes → Composer 2.5は避ける（Kimi K2.5ベース問題、次項で詳述）
→ No → Composer 2.5を試す価値あり
タスクタイプ別の推奨モデル一覧
| タスクタイプ | 第1推奨 | 第2推奨 | 避けるべき |
|---|---|---|---|
| 大規模リファクタリング | Composer 2.5標準版 | Opus 4.7 | — |
| 新機能のスクラッチ実装 | Composer 2.5高速版 | Opus 4.7 | — |
| バグの原因究明 | Opus 4.7 max | Composer 2.5 | — |
| ターミナル作業・CI構築 | GPT-5.5 | Opus 4.7 | Composer 2.5 |
| テストコード生成 | Composer 2.5標準版 | GPT-5.5 | — |
| 多言語プロジェクト | Composer 2.5 | Opus 4.7 | — |
| 認証・バックエンドロジック | Opus 4.7 | GPT-5.5 | Composer 2.5（コミュニティで品質低下報告あり） |
| 規制業界・金融・防衛 | Opus 4.7 | GPT-5.5 | Composer 2.5 |
| 個人開発・サイドプロジェクト | Composer 2.5標準版 | — | — |
| セキュリティ監査・脆弱性調査 | Opus 4.7 max | GPT-5.5 | — |
Composer 2.5 vs Claude Code：どちらを選ぶべきか
多くの開発者が悩むのが、CursorのComposer 2.5とAnthropicのClaude Codeのどちらをメインに据えるかという選択です。
機能・特徴の比較
| 項目 | Cursor + Composer 2.5 | Claude Code（Opus 4.7ベース） |
|---|---|---|
| 提供形態 | IDE + CLI + Web | CLI主体 |
| ベースモデル | Kimi K2.5（Moonshot AI） | Claude Opus 4.7（Anthropic） |
| SWE-Bench Multilingual | 79.8% | 80.5% |
| Terminal-Bench 2.0 | 69.3% | 69.4% |
| 1タスクあたりコスト | 約$0.50 | 約$7 |
| GUI操作の手厚さ | ◎（VSCodeベース） | △（CLI中心） |
| 長時間タスク安定性 | ○（改善されたが認証系で報告あり） | ◎ |
| サプライチェーン透明性 | △（中国系ベースモデル） | ◎（米国系） |
| 外部API経由での利用 | ×（Cursor専用） | ○ |
| 企業導入数（参考） | Cursor全体で大規模 | 30万社超 |
使い分けの結論
✓ Cursor + Composer 2.5を選ぶべきケース
- GUI主体で日常的にコーディングするフロントエンド・フルスタック開発者
- 個人開発・スタートアップでコストを抑えながら高速に試行錯誤したい
- VSCode系のIDE体験を捨てたくない
- 複数ファイル編集が頻繁に発生するプロジェクト
- 2倍キャンペーン期間中の検証目的
✓ Claude Codeを選ぶべきケース
- ターミナル中心の開発スタイル（DevOps、SREなど）
- 規制業界・金融・防衛など、サプライチェーン監査が厳格
- 外部APIから自社パイプラインに組み込む必要がある
- 長時間の自律的タスク実行で高い安定性が必須
- 真実性・正確性が極めて重要なミッションクリティカル業務
Kimi K2.5ベース問題：日本企業の調達観点からのリスク評価
Composer 2.5の最大のリスク要因は、ベースモデルが北京のスタートアップMoonshot AIが開発したKimi K2.5である点です。これは技術的な問題ではなく、調達・コンプライアンス・サプライチェーン監査の観点で重要になります。
過去の経緯：Composer 2でのKimi開示問題
2026年3月のComposer 2リリース時、Cursorは当初Kimi K2.5をベースに使っている事実を公表していませんでした。コミュニティからの指摘を受けて初めて開示され、Cursor共同創業者のAman Sanger氏が公式に「最初のブログでKimiベースに言及しなかったのは抜け落ち。次のモデルでは修正する」と表明。
続く2026年4月には米国議会がCursorのKimi連携について審査を行うなど、政治的な注目度も高まりました。Composer 2.5では、リリース時点でKimi K2.5ベースであることが明示されています。
日本企業として考慮すべきリスク
- サプライチェーン監査要件：日本の防衛・金融・重要インフラ業界では、米国の規制動向に追随する形でAIモデルのサプライチェーン監査が厳格化する可能性
- 政府調達ガイドライン：経済安全保障推進法や政府調達基準に基づく、特定国由来技術の利用制限
- 顧客企業からの要求：米国系大手企業（特に金融・医療・防衛分野）との取引で、開発環境におけるAIモデルの出自を問われるケース
- セキュリティ監査での説明責任：内部監査・外部監査で「なぜ中国系ベースモデルを使ったか」を説明する必要
リスク軽減のアプローチ
- 用途を限定する：機密性の低いプロトタイピング・個人開発・OSSコントリビューションに限ってComposer 2.5を使用し、本番コードベース・顧客機密データを扱う作業ではOpus 4.7に切り替える
- 業務分離：チーム単位でCursor利用ポリシーを策定し、規制対象業務に関わるエンジニアにはClaude Codeを支給する
- 監査ログの整備：Cursorのチーム管理機能を使い、誰がどのモデルでどのコードを編集したかを記録
- 次世代モデルへの移行準備：CursorはSpaceXAIと共同で10倍規模の独自モデル（Kimiベースではない）を開発中。これがリリースされればKimi依存問題は解消される見込み
Cursorは、Colossus 2の100万H100相当の計算リソースを使って、Composer 2.5の10倍の計算量でゼロから訓練する次世代モデルをSpaceXAIと共同開発中と公表しています。これがリリースされれば、Kimiベースモデル依存の問題は構造的に解消される可能性が高いです。リリース時期は未公表ですが、規制業界の方は次世代モデルを待つ判断もアリでしょう。
Composer 2.5の技術的な核心：何が性能向上を生んだのか
Cursorは公式ブログで、Composer 2.5の性能向上を支える3つの技術的革新を明らかにしています。技術的に踏み込みたい読者向けに解説します。
1. テキストフィードバックを用いたターゲット型強化学習
長時間のエージェントタスクでは、数十万トークンに及ぶロールアウト（モデルの一連の行動）が発生します。従来の強化学習では「最終的に成功したか失敗したか」という単一の報酬しか与えられず、どの判断が成功/失敗を決めたのかを特定できないという問題がありました。
Composer 2.5では、ロールアウト内の特定の地点で局所的なヒントを挿入し、ヒントありモデルの出力分布を教師信号としてヒントなしモデルを訓練します。たとえば「利用できないツール名を呼び出した」場合、その地点に「利用可能なツールはRead、Write、Shell、StrReplaceです」というヒントを挿入。これにより、誤ったツール呼び出しの確率を局所的に下げられます。
2. Sharded Muon：1兆パラメータ規模での高速最適化
Sharded Muonは、巨大モデルのパラメータ更新を効率化する独自の最適化手法です。Cursorによれば、1兆パラメータ規模のモデルでオプティマイザのステップ時間を0.2秒に短縮することに成功しました。
これは強化学習の試行回数を増やせることを意味し、結果として25倍の合成タスクで訓練できた背景になっています。
3. Dual Mesh HSDP：通信コストを抑えた分散学習
MoE（Mixture of Experts）モデルでは、通常の重みと専門家モデル部分の重みを別々に管理する必要があります。Dual Mesh HSDPは、これら2種類の重みに別々の分散配置を使うことで通信コストを抑えながら大規模学習を進める仕組みです。
合成データの25倍拡大：特に「機能削除」が革新的
Composer 2.5は前モデルの25倍の合成タスクで訓練されました。注目すべきは「機能削除（Feature Deletion）」という手法です。動作するコードベースから特定の機能を削除し、モデルに再実装させ、既存のテストを使って成功/失敗を判定します。これにより、現実的なソフトウェア開発タスクを大量に生成できました。
Composer 2.5の弱点・注意すべき点
過度な期待を抱かないために、現時点で報告されている弱点・制限を整理します。
1. Cursor専用：外部API提供なし
Composer 2.5はCursorのインフラに完全に囲い込まれており、外部からAPI経由でアクセスできません。Hugging Faceミラーも、サードパーティゲートウェイも存在しません。「複数モデルを統一APIで切り替える」前提のインフラを構築している企業にとっては、Composer 2.5は事実上「存在しない」モデルです。
2. 認証・バックエンドロジックでの品質低下報告
コミュニティからは、認証セットアップやバックエンドロジックの長時間タスクで品質が落ちるという報告が継続的に上がっています。これはComposer 2から引き継がれた弱点で、Composer 2.5でも完全には解消されていないようです。
3. システムカードが未公開
Anthropicが公開しているような詳細なシステムカード（モデルの能力範囲・限界・安全性評価）がリリース時点で公開されていません。これは企業導入の判断材料が不足することを意味します。
4. ベンチマークの一部はCursor自社製
CursorBench v3.1はCursor自身が設計したベンチマークです。第三者検証が不足しているため、実際の自社コードベースで検証してから本格採用することを強く推奨します。
5. GPT-5.5のTerminal-Bench優位は残る
前述の通り、Terminal-Bench 2.0ではGPT-5.5（82.7%）がComposer 2.5（69.3%）を13ポイント以上引き離しています。シェル中心の自動化ワークフローでは、引き続きGPT-5.5を選ぶべきです。
導入判断チェックリスト
最後に、Composer 2.5を導入すべきかの判断を整理します。
✓ Composer 2.5を即導入すべき人
- すでにCursor有料プラン契約者で、開発コストを30〜80%削減したい
- 個人開発者・スタートアップで、AIエージェントへの月額支出が痛い
- 複数ファイル編集が中心の現実的なIDE作業を多くやる
- OSS開発、サイドプロジェクト、プロトタイピングでの利用
- 多言語プロジェクト（日本語・英語混在のコメントやドキュメント）
✗ Composer 2.5の導入を見送るべき人
- 規制業界（金融・防衛・医療・重要インフラ）で機密コードを扱う
- 米国系大手企業との取引で開発環境の監査が厳しい
- ターミナル中心の自動化ワークフロー（GPT-5.5を継続）
- 外部API経由で複数モデルを統一管理する必要がある
- 認証・決済バックエンドなど、品質が極めて重要なコア部分の長時間タスク
△ まず試してから判断すべき人（推奨）
- Opus 4.7またはGPT-5.5を主に使っている開発者全般
- 初週2倍キャンペーン期間中（2026年5月18〜25日頃）に自社コードで検証
- 3〜5個の代表的なタスクをComposer 2.5・Opus 4.7・GPT-5.5で実行し、品質・コスト・速度を比較
よくある質問（FAQ）
cursor agent --model composer-2.5で指定できます。バックグラウンドの長時間タスクや、ターミナル中心のワークフローに組み込む用途に向いています。まとめ：Composer 2.5は「コスト性能比の革命」
Composer 2.5は単なるバージョンアップではなく、AIコーディングモデルのコスト性能比の前提を塗り替えるリリースです。フロンティアモデルと同等の性能を約10分の1のコストで実現したことで、エージェント型コーディングの経済性が根本から変わります。
- 性能：SWE-Bench Multilingual 79.8%でOpus 4.7に肉薄、GPT-5.5を上回る
- 料金：標準版$0.50/$2.50で他モデルの約10分の1
- 初週キャンペーン：2倍利用枠で自社コードベースでの検証に絶好の機会
- リスク：Kimi K2.5ベース問題により規制業界では慎重判断が必要
- 使い分け：ターミナル作業はGPT-5.5、正確性最優先はOpus 4.7 max、それ以外はComposer 2.5が有力
まずは初週2倍キャンペーン中に自社の代表的なタスクで検証し、Opus 4.7・GPT-5.5との実測比較を行ってから本格採用を判断することを強く推奨します。
