DEV Community

Cover image for カーソルコンポーザー2.5：機能、使い方、アクセス方法
Akira
Akira

Posted on • Originally published at apidog.com

カーソルコンポーザー2.5：機能、使い方、アクセス方法

Cursorは2026年5月18日にComposer 2.5を出荷しました。注目点は明確です。Opus 4.7およびGPT-5.5と実際のソフトウェアベンチマークで匹敵しながら、タスクあたりのコストは1ドル未満に収まるコーディングモデルです。コードを書くことで生計を立てている開発者にとって、この価格対品質比は日々の実装計画に影響します。

今すぐApidogを試す

このガイドでは、開発者が実務で知りたいポイントに絞って説明します。Composer 2.5が何か、Cursor内でどう有効化するか、そして本番コードでどう使うかです。ベンチマーク、価格、実装時の使い分けに加えて、Composer 2.5とApidogを組み合わせ、生成されたAPIコードを実行前提で検証するワークフローも紹介します。

Cursor Composer 2.5とは？

Composer 2.5は、Cursor独自のエージェント型コーディングモデルです。Cursorエディタ内で計画を立て、ファイルを編集し、ターミナルコマンドを実行し、自分の作業を検証する用途に最適化されています。

以前のComposer 2は高速な自動補完パートナーに近い存在でした。Composer 2.5では、より長いタスクを文脈を失わずに完了させるエージェントとしての性質が強くなっています。

Cursor Composer 2.5

主な特徴は次の通りです。

  • オープンソースのMoonshot Kimi K2.5チェックポイントを基盤としている
  • おおよそ1兆パラメータ規模の基盤を持つ
  • Cursorはトレーニング計算予算の約85%を、ベースモデルではなくポストトレーニングと強化学習に使用した
  • Composer 2よりも25倍多い合成タスクでトレーニングされた
  • Cursorが機能を削除し、モデルがテストに合格するまで再構築するような演習も含まれている

実務上の違いは、長いセッションでの安定性です。Composer 2は高速でしたが、複数ステップの作業では意図からずれることがありました。Composer 2.5は、より長いタスクで文脈を保持し、複雑な指示を継続的に実行しやすくなっています。

モデルファミリーの背景を確認したい場合は、Composer 2ガイドで、2.5の前提となるアーキテクチャを確認できます。

内部で何が変わったのか

Composer 2.5の改善は、主に3つのトレーニング方針に基づいています。

  1. テキストフィードバックによるターゲットRL

    タスクの最後に単一の報酬を与えるだけでなく、Cursorは修正内容を短いヒントとして記述し、そのヒントをローカルコンテキストに入れ、モデルへ蒸留しています。これにより、利用できないツールを呼び出すような挙動を減らしています。

  2. 大規模な合成データ

    合成タスクが25倍に増えたことで、モデルは実際のリポジトリ作業に近いタスクをより多く経験しています。感覚的なコード生成ではなく、テストで検証される作業を多く学習しています。

  3. デュアルメッシュHSDPを備えたシャードMuonオプティマイザ

    これはユーザーが直接操作する機能ではなく、トレーニングインフラです。Cursorが1兆パラメータ規模のモデルを高速な最適化ステップでトレーニングできた理由の一つです。

これらを暗記する必要はありません。重要なのは、Composer 2.5が以前のエージェントよりも長く複雑なタスクで安定しやすい、という点です。

Composer 2.5のベンチマーク：実際どのくらい優れているのか？

Cursorは3つのベンチマークでスコアを報告し、Opus 4.7およびGPT-5.5と比較しています。

ベンチマーク Composer 2.5 Opus 4.7 GPT-5.5
SWE-bench Multilingual 79.8% 80.5% 77.8%
Terminal-Bench 2.0 69.3% 69.4% 82.7%
CursorBench v3.1 63.2% 64.8%（最大） / 61.6%（デフォルト） 59.2%（デフォルト）

読み方はシンプルです。

  • SWE-bench Multilingualでは、Composer 2.5は79.8%
  • Opus 4.7との差は1ポイント未満
  • GPT-5.5は上回っている
  • Composer 2の73.7%から大きく改善している
  • CursorBenchでは、Opus 4.7のデフォルト設定をわずかに上回っている

一方で、Terminal-Bench 2.0ではGPT-5.5が82.7%で明確にリードしています。長いターミナル操作やCLI中心の作業が多い場合は、この差を考慮する必要があります。

ただし、最も重要なのはコストです。Cursorは、CursorBenchで約63%のスコアを出しながら、タスクあたりの平均コストが1ドル未満であると報告しています。一方、Opus 4.7やGPT-5.5は、同等またはそれ以下の結果でもタスクあたり数ドルかかります。一部の比較では、競合モデルのコストが最大11ドルに達するとされています。

The Decoderによる独立した報道も、Composer 2.5が最先端に近い品質を低コストで提供しているという同様の結論に達しています。

つまり、Composer 2.5はすべてのベンチマークで常にトップのモデルではありません。しかし、多くの実務チームにとって重要な「十分に高い品質を、継続利用できるコストで使える」モデルです。

Composer 2.5のコストはいくらですか？

Cursorは、Composer 2.5に2つのバリアントを提供しています。

バリアント 入力 出力 使う場面
スタンダード $0.50 / 100万トークン $2.50 / 100万トークン ほとんどのエージェント作業のデフォルト。費用対効果を重視する場合。
高速 $3.00 / 100万トークン $15.00 / 100万トークン レイテンシが重要な作業。待ち時間を短くしたい場合。

高速バリアントは、同等のモデル品質をより低いレイテンシで提供し、製品上のデフォルトになっています。それでも、他の最先端モデルの高速ティアより安価です。

Composer 2.5 pricing

請求方法はプランによって異なります。

  • 個人プラン

    Proなどの個人プランには、Composer用の使用量プールがあります。多くのソロ開発者は、日常利用では細かなトークン単価を意識せずに使えます。

  • チームおよびエンタープライズプラン

    APIレートで直接課金されます。

  • ローンチプロモーション

    Cursorはリリース後最初の1週間、Composer 2.5の使用量を2倍にしました。早期導入者はテストしやすい期間を得られます。

Cursorがモデル使用量をどう測定するかは、Cursor Composer価格ガイドで確認できます。費用を抑えて試したい場合は、Composer無料利用のチュートリアルも参考になります。

Cursor Composer 2.5へのアクセス方法

Composer 2.5は、Cursor内から数ステップで使えます。

  1. Cursorをアップデートする

    Composer 2.5には最近のビルドが必要です。Cursorを開き、アップデートを確認します。macOSではCursorメニュー、その他の環境ではヘルプメニューから確認できます。更新後は再起動します。

  2. 対応プランのアカウントでサインインする

    ProおよびBusinessプランにはComposer使用量が含まれます。無料アカウントでも含まれる使用量で試せますが、大量に使う場合は有料プランが必要です。

  3. モデルピッカーを開く

    チャットまたはエージェントセッションを開始し、モデルのドロップダウンを開きます。composer-2.5を選択します。通常は高速バリアントがデフォルトで選ばれています。

  4. エージェントモードを使う

    Composer 2.5はエージェント作業向けです。ファイル編集、ターミナルアクセス、ツール使用を使うには、通常のチャットではなくエージェントモードを使います。

セットアップはこれだけです。モデルは、Cursorが公開するファイル読み取り、編集、ターミナル実行、ツール呼び出しなどのエージェント機能にアクセスできます。最新のデフォルト設定は、公式のComposer 2.5モデルドキュメントで確認できます。

Cursorを使ったことはあるがエージェント機能を使っていない場合は、Cursor 2.0の概要を読むと、エージェントインターフェースの基本を把握できます。

Composer 2.5を効果的に使う方法

Composer 2.5は、短い補完よりも「完了条件が明確な実装タスク」で力を発揮します。

1. 長いタスクを任せる

Composer 2.5の主な改善点は、持続的なパフォーマンスです。1行ずつ指示するのではなく、実装単位で依頼します。

例：

注文一覧APIにページネーションを追加してください。
既存のレスポンス形式を壊さず、limitとcursorを受け取れるようにしてください。
関連するユニットテストとAPIテストも更新し、既存テストがすべて通る状態にしてください。
Enter fullscreen mode Exit fullscreen mode

このように終了条件を明確にすると、Composer 2.5は複数ファイルを横断して作業しやすくなります。

2. 成功条件をプロンプトに書く

Composer 2.5はテスト検証を前提とする作業に向いています。完了条件を曖昧にしないでください。

例：

以下を満たすまで修正してください。

- 既存テストはすべてグリーンを維持する
- 新しい注文作成APIは無効な入力に対して422を返す
- 認証されていないリクエストは401を返す
- OpenAPIスキーマと実装のフィールド名が一致する
Enter fullscreen mode Exit fullscreen mode

「何をもって完了とするか」を与えることで、モデルが自己修正しやすくなります。

3. 標準と高速を使い分ける

品質は同じなので、判断軸はコストとレイテンシです。

  • 標準

    バッチ的な修正、大きめのリファクタリング、急がない作業

  • 高速

    ライブでやり取りしながら実装する作業、応答待ち時間を減らしたい作業

チームで使う場合は、日常の大半を標準に寄せ、ペアプロ的に使う場面だけ高速を選ぶとコストを管理しやすくなります。

4. コンテキストを正確に渡す

エージェントモデルは強力ですが、APIの実際の仕様を知らない場合は推測します。推測で生成されたコードは、見た目は正しくても実行時に失敗します。

特にAPIクライアント、DTO、認証、エラーハンドリング、テストコードでは、実際の仕様を渡してから生成させる方が安全です。

Composer 2.5とAPIワークフロー

実際のコーディングタスクの多くはAPIに触れます。たとえばComposer 2.5に「支払いサービスのクライアントを作成して」と依頼すると、見た目の良いコードは生成されます。

しかし、次のようなズレが起きる可能性があります。

  • エンドポイントのパスが実際と違う
  • リクエストフィールド名が違う
  • 認証方式が違う
  • エラーレスポンスの形式が違う
  • 必須フィールドと任意フィールドの扱いが違う

この失敗を避けるには、生成と検証を分けて考えます。

手順1：実際のAPI仕様をCursorに渡す

モデルに推測させるのではなく、実際のAPI仕様を参照させます。

Apidog MCPサーバーを使うと、ApidogのAPI仕様をCursorに接続できます。これにより、Composer 2.5は実際のスキーマに基づいて以下を生成できます。

  • リクエストコード
  • 型定義
  • APIクライアント
  • テストコード
  • エラーハンドリング

他のエージェントも併用している場合は、Cursor向けの最高のMCPサーバーのまとめも参考になります。

手順2：生成されたAPI呼び出しをApidogで検証する

Composer 2.5が書いたエンドポイント呼び出しは、チームメイトのブランチに入る前に検証します。

実務では次の流れが有効です。

  1. Composer 2.5でAPIクライアントやテストを生成する
  2. 生成されたリクエストをApidogに入れる
  3. 実際のリクエストを送信する
  4. ステータスコードを確認する
  5. レスポンス形状を確認する
  6. 動作する呼び出しを自動テストやモックサーバーに変換する

このループにより、エージェントの速度を維持しながら、API仕様とのズレを早期に潰せます。

ポイントは次の通りです。

実際の仕様に基づいて生成する
→ 実際のサーバーに対して検証する
→ 検証済みの呼び出しをテストとモックに固定する
Enter fullscreen mode Exit fullscreen mode

これにより、速く生成されたコードがデバッグ負債になるのを防げます。

Composer 2.5 vs 競合製品

日常のメインツールとして選ぶ場合の比較です。

  • vs Opus 4.7

    SWE-bench MultilingualとCursorBenchではほぼ同等です。タスクあたりのコストはComposer 2.5の方が大幅に安価です。ただし、Opus 4.7はCursorBenchの最大設定では依然として上位です。

  • vs GPT-5.5

    Composer 2.5はSWE-bench MultilingualとCursorBenchでGPT-5.5を上回っています。一方、Terminal-Bench 2.0ではGPT-5.5が明確にリードしています。

  • vs Claude Code

    ツールとしての形が異なります。Composer 2.5はCursorエディタ内で動作するエージェントで、Claude Codeはターミナルエージェントです。Claude Code vs Cursorの比較では、どちらがどのワークフローに向くかを整理しています。

  • vs GitHub Copilot

    Copilotはインライン補完に強いツールです。Composer 2.5は、複数ファイルにまたがるエージェントタスクに向いています。詳細はCursor vs GitHub Copilotガイドで確認できます。

Cursorはまた、xAIと協力し、約10倍の計算量を使ってより大きなモデルをトレーニングしているとも述べています。Composer 2.5は到達点ではなく、より急な改善曲線上のチェックポイントと見るべきです。

よくある質問

Composer 2.5は無料ですか？

完全に無料のティアはありません。ただし、個人プランには通常の日常業務をカバーするComposer使用量プールが含まれています。また、Cursorはローンチ週に使用量を2倍にしました。

含まれる使用量の範囲は、Composer無料利用ガイドで確認できます。

Composer 2.5はComposer 2より優れていますか？

はい。測定可能に改善しています。SWE-bench Multilingualは73.7%から79.8%に上昇し、長いタスクでのコンテキスト保持も改善されています。

Composer 2ガイドは、改善前のベースラインを理解するのに役立ちます。

Composer 2.5は何のモデルに基づいていますか？

MoonshotのオープンソースKimi K2.5チェックポイントに基づいて構築されています。その後、Cursorによって強化学習と合成タスクを使った集中的なポストトレーニングが行われています。

標準と高速のどちらを選ぶべきですか？

知能は同じです。違いはレイテンシと価格です。

  • コスト効率を重視するバッチ作業には標準
  • ライブで反復する作業には高速

という使い分けが基本です。

Composer 2.5はAPI仕様やMCPと連携できますか？

はい。Cursorのエージェントツールセットをサポートしており、MCPも利用できます。

Apidog MCPサーバーを通じてAPI仕様を接続すれば、Composer 2.5は実際のスキーマに基づいてコードを生成できます。

結論

Composer 2.5は、「最先端品質のコーディング」と「高コスト」が切り離されつつあることを示すモデルです。Cursor内で、Opus 4.7に近い実ソフトウェアタスクの結果を、タスクあたり1ドル未満のコストで狙えます。

使い始める手順は簡単です。

  1. Cursorをアップデートする
  2. モデルドロップダウンでcomposer-2.5を選ぶ
  3. 通常チャットではなくエージェントモードを使う
  4. 1行修正ではなく、明確な完了条件を持つマルチステップタスクを渡す

さらに、API開発では検証ループを組み合わせることで効果が上がります。実際の仕様に基づいてAPIコードを生成し、Apidogをダウンロードしてライブリクエストを送信し、レスポンスを確認し、動作する呼び出しを自動テストとモックに固定します。

高速に生成されたコードより、検証済みで高速に生成されたコードの方が価値があります。

Top comments (0)