Cursor Composerの使い方と選び方：2の仕組みから現行2.5まで

Cursor Composer 2は、要件が明確でレビューしやすいコード変更に取り組む際の有力な選択肢です。ただし、Cursorが現在掲載しているComposerのバージョンはComposer 2.5です。対話しながら実装を進めるならComposerファミリー、システムをどう動かすかという判断が難しいなら、計画立案に強いモデルを選びます。基準になるのは編集するファイル数ではなく、タスクの明確さです。

2026年11月14日確認。 Cursorの公開中のモデルドキュメント、リリース記事、技術レポートを照合しました。Composer 2は後継モデルにつながる学習手法を確立したため、今も理解しておく意味があります。本記事はドキュメントに基づく評価と実用的な選定指針であり、実機ベンチマークではありません。

Cursor Composer 2は何をするモデルですか？

Composer 2は、Cursorのエージェント環境でソフトウェア開発のタスクを進めるように学習されたコーディングモデルです。 エージェントとは、モデルとツールを組み合わせ、リポジトリの調査、ファイルの変更、その結果の確認を行えるようにしたものです。次の操作を決めるのはモデルであり、周囲のソフトウェアがその操作を実行して結果を返します。

モデル選択画面でComposerを見かけたら、この区別が重要です。別のエディターを開いたり、コード補完機能へ切り替えたりするのではありません。エージェントを動かす頭脳を選んでいます。Cursorが作業環境で、その中で使えるモデルのひとつがComposerです。

エンジニアリングの工房を思い浮かべてください。どの接合部を調べるか判断する技術者がモデルに当たります。ファイル検索、編集、ターミナルの各ツールは作業機材です。テストは変更がうまくいったかを確かめる測定に当たります。有能な技術者ほど良い判断ができますが、仕様が欠けたままでは、技術者にも機材にも補える限界があります。

たとえば、既存のアカウント状態フィールドを設定画面に表示する作業では、コンポーネント、データのマッピング、テストの変更が必要かもしれません。複数のファイルにまたがっていても、実現したい動作は明確です。これはComposerに任せる妥当なタスクです。一方、請求、アクセス制御、移行ロジック全体でアカウント状態の意味を再定義するなら話は変わります。実装の前に、決めるべきことがあるからです。

今から評価するならComposer 2.5です

新たに評価する際の対象はComposer 2.5です。 Cursorは2026年3月19日にComposer 2をリリースし、続いて2026年5月18日にComposer 2.5を発表しました。Composer 2.5の発表記事では、継続的な作業能力、複雑な指示に従う確実さ、協働時の振る舞いが改善したと説明しています。

Cursorによると、後継モデルでは回答するまでにどれだけ作業するかという労力の調整が改善され、学習中には具体的な問題に絞ったテキストのフィードバックも加えられています。最終的な成功スコアだけに頼らず、利用できないツールを選ぶといった特定の誤りを学習の対象にできます。また、実際のコードベースから難易度の高い合成タスクも作成しています。機能を削除し、テストを満たすように作り直させるのがその一例です。

開発者にとって、これは実務上の意味があります。目を見張るようなベンチマークの伸びがなくても、不要な操作が減り、やり取りが明確になることで、モデルは使いやすくなります。開発責任者は、正しさと併せてこうした振る舞いも評価すべきです。出力のためにどれだけ確認、修正、レビューの作業が生じたかを数えてください。

Composer 2.5の出発点は、引き続きComposer 2と同じ基盤チェックポイントです。追加学習を施した後継モデルですが、過去のComposerについての主張がすべて現行モデルにも当てはまるという意味ではありません。

Composer 2の技術レポートでわかる学習方法

Cursorは既存モデルをコーディング向けに特化させ、開発者が実際に使う環境でタスクを完了するように学習させました。 Cursorの学習手法の概要では、コードを多く含む混合データで継続事前学習を行った後、提供時と同じツールとエージェント構成を用い、実際に近いCursorセッションで強化学習を行ったと説明しています。

継続事前学習とは、ベースモデルにデータを使ってさらに学習させ、コーディングの知識を深めることです。強化学習ではタスクを試行させ、その結果の質に応じて振る舞いを調整します。前段で知識を増やし、後段でその知識の使い方を磨くわけです。

技術レポート全文には、長いコンテキストを扱う学習、狙いを絞った教師あり学習の事例、コミュニケーションやツール使用を方向づける報酬の詳細があります。簡単な依頼に過剰な労力をかけることを抑えつつ、難しい依頼には十分に取り組めるようにするペナルティも説明されています。対話のテンポを保ちながら、役立つコーディング能力を提供するという製品の狙いが見えてきます。

Composer 2とKimiにはどんな関係がありますか？

Composer 2の出発点は、MoonshotのKimi K2.5チェックポイントです。 Cursor独自のモデルと呼ばれていても、元の基盤モデルをCursorがゼロから事前学習したという意味ではありません。Cursorは出発点を明示したうえで、自社で施した追加学習を説明しています。

逆に、出発点のチェックポイントが共通だからといって、提供されるシステムをそのまま置き換えられるわけでもありません。追加学習によって振る舞いは変わり、エージェント環境によって実行できる操作も変わります。自分のリポジトリで問うべきなのは、システム全体として正しく、レビュー可能な結果を出せるかです。モデルの系譜は技術の説明にはなりますが、それだけで評価は決まりません。

「コードで学習した」という説明だけでは不十分なのも、このためです。Composerの特化には、チャットでそれらしい関数を出力することだけでなく、ツールの選択、結果を受けた立て直し、タスク全体を通して作業を続ける能力も含まれます。

コンテキストとツール使用で、今も残る制約

現行のComposer 2.5の製品リファレンスには、200kトークンのコンテキストウィンドウと記載されています。 トークンはモデルが処理するテキストやコードの単位で、コンテキストは依頼を処理するための作業領域です。現行のComposerモデルのドキュメントには、AgentとThinkingの機能に加え、ファイル検索、ファイルの読み取りと編集、シェルコマンドなどのエージェントツールが挙げられています。

同じページにはブラウザーや画像生成のツールも記載されています。これらはエージェント環境を通じて使えるツールであり、基盤モデル自体があらゆる入力形式に対応している証拠ではありません。特に、汎用的なファイル読み取りの説明では、画像の読み取りは視覚対応モデルであることが条件になっています。共通のツール一覧から、モデル自体に視覚機能があると推測してはいけません。

大規模なリポジトリでも、コードベース全体が作業コンテキストに常駐するわけではありません。必要なファイルを検索し、読み込むことも作業の一部です。大きなウィンドウは多くの根拠を収める助けになりますが、適切な根拠を選ぶ重要性は変わりません。

Composerのレポートでは、長いタスクを継続するために作業履歴を圧縮する自己要約を説明しています。最終的な解決に役立つ要約には報酬を与え、重要な情報を落とす要約にはペナルティを与えて学習します。すべての会話をいつまでも机に並べておくというより、技術者が引き継ぎメモを更新する行為に近いものです。

本当の壁は単なる容量不足ではなく、重要な制約を見失うことです。長いリファクタリングの途中で、古いAPIを動かし続ける必要があると忘れてしまうと、編集を重ねるほど誤りが深まる可能性があります。互換性の要件と受け入れ時の確認項目は、後から参照できるプロジェクト指示やタスク仕様に残してください。会話がそれたら制約を改めて伝え、エージェントに続行させる前に差分を確認します。

Composer 2のベンチマークは何を示していますか？

Cursorの結果は、従来のComposerモデルからコーディング能力が大きく改善したことを裏づけます。ただし、あらゆる最先端モデルに勝つという結果ではありません。 Composer 2のリリース記事では、CursorBenchで61.3、Terminal-Bench 2.0で61.7、SWE-bench Multilingualで73.7と報告しています。いずれもCursorによる測定値であり、本記事で独立に測定した結果ではありません。

CursorBenchはCursorのエンジニアによるコーディングセッションをもとにしています。Terminal-Benchはターミナル環境でのエージェント作業を、SWE-bench Multilingualは複数の言語にまたがるリポジトリの課題解決を評価します。タスク、採点方法、エージェント構成はそれぞれ異なります。これらのスコアを、そのまま次の移行作業が成功する確率には換算できません。

リリース記事は、比較対象ごとにモデルを取り巻くソフトウェア、つまりエージェント構成が異なる場合があるとも説明しています。これは無視できない制約です。ツールや実行方法が異なるとき、モデル単体のスコアとエージェント全体のスコアはきれいに切り分けられません。

Composer 2.5のベンチマークは別の評価として扱います

Composer 2の公開スコアが、Composer 2.5のスコアになるわけではありません。 Cursorは後継モデルの発表で知能と振る舞いの改善をうたい、そのモデル独自の評価資料を示しています。現在のモデル選定では、その根拠と旧リリースの数値を分けて扱ってください。

役に立つ評価は、自分のリポジトリを代表するタスクを、受け入れ条件がわかった状態で試すことです。他の場所で高得点を取っても意図を読み解き直さなければならないモデルより、理解しやすいテストとともに明快な修正を出すモデルのほうが価値があります。これは評価方法の提案であり、本記事でその検証を実施したという主張ではありません。

Composer 2とComposer 2 Fastの違い

Cursorの説明では、Fastは応答の提供速度を選ぶもので、知能が高いモデルではありません。 Composer 2の発表と現行のComposerドキュメントは、どちらも高速版の知能は同じだとしています。やり取りの待ち時間が問題なら選ぶ意味がありますが、返答が速いからといって、弱い推論まで改善するとは期待しないでください。

過去の速度比較は、2026年3月18日時点のCursorのトラフィックを使っています。Cursorは、速度がプロバイダーの処理能力によって変わり、時間とともに変動すると説明しています。リリース当時の毎秒トークン数を、今日のセッションの速度保証にできないのはそのためです。

また、リリース時の「Fastがデフォルト」という説明には、現在の製品上の例外があります。PlusではFastがオフに固定されています。アカウント設定については、古い発表よりもCursorの現行モデル・プランのリファレンスが優先されます。有料プランでは、Composerはプランに含まれるCursorモデルの利用枠を使います。ClaudeとGPTへのアクセスには、対象プランと別の利用ルールが適用されます。

現行アカウントと旧アカウントの違いを含む、アクセス条件のより広い変更は、10月の変更後のCursorモデルで解説しています。すべてのComposerセッションが同じ条件で動くと思い込まず、選択中のバリアントとアカウント側の設定を確認することが大切です。

Composer・Claude・GPTをどう使い分けますか？

変更内容が明確ならComposer、不確定な判断が作業の中心なら計画立案に強いモデルを選びます。 これはCursorのモデル選定ガイドに沿った考え方です。同ガイドはComposerを対話的なコーディング向けと位置づけ、複雑で多段階のタスクにはAnthropic Claude OpusとOpenAI GPT-5.6 Solを推奨しています。

複数ファイルの手早い修正はComposerから始めます

APIがすでに返しているフィールドを画面に表示し、既存のバリデーションを維持しながら関連テストを更新する場面を考えます。Composerには、変える動作、変えない動作、完了をどう確かめるかを伝えてください。すべてのファイル名を自分で推測するより、影響を受けるファイルを探させます。

利点は、短いサイクルでフィードバックできることです。提案された変更を確認し、誤った前提を直して続きを進められます。多数のファイルに触れる作業でも、アーキテクチャに不確実さがあるとは限りません。モデル選定の基準として、ファイル数よりも未解決の判断のほうが適切です。

同じ失敗が繰り返されるなら、プロンプトの指示を強め続けるのはやめましょう。要件が明確なのに依存関係を何度も見落とす場合は、再現手順と現在の差分を別のモデルに引き継ぎます。要件が曖昧なら、モデルを替える前に要件を明確にします。

難しい設計変更はClaude OpusやGPTで計画を立てます

アカウント権限の処理を、各所に散らばったチェックから共通の認可レイヤーへ移す場面を考えます。危険なのはヘルパーを書くこと自体ではありません。どのサービスがどのIDを信頼するのかを把握し、移行中も既存の動作を維持し、ロールバック方法を決める部分です。

編集を始める前に、計画立案に強いモデルで依存関係を整理し、移行設計の弱点を検討します。CursorのClaude Opus 5.5のリファレンスには、コンテキストはデフォルトで300k、最大で1Mと記載され、high-thinkingバリアントが推奨されています。多くの根拠をまとめて比較する必要があるときに検討する理由が、容量面からも示されています。Cursorは複雑な多段階の作業向けにGPT-5.6 Solも挙げています。

こうしたモデルを推奨する理由は、判断を誤った場合のコストが高い不確実性、長い依存関係の連鎖、設計レビューにあります。どちらかがあらゆるリポジトリのタスクで勝つという主張ではありません。計画が固まったら、範囲を区切った実装部分についてはComposerを評価できます。

Cursor内でClaudeモデルを選ぶことと、Claude Codeという製品を選ぶことは別です。ワークフローとしての選択は、Claude CodeとCursorの比較で扱っています。今のエディターで使う頭脳を替えるために、エディターまで替える必要はありません。

速度が速いだけで、作業が完了したとはいえません

速度、長いコンテキスト、ベンチマークでの優位を、そのままマージ可能な変更の証拠にするのは早計です。 Cursor自身も、難しいタスク向けに学習したモデルと説明しています。それでも、自分の具体的な要件を満たしたか確認する必要はなくなりません。

指定し忘れた動作が間違ったままでも、テストは通ることがあります。互換性の要件が長いコンテキスト内に収まっていても、エージェントが一貫して適用するとは限りません。自信に満ちた要約が、失敗したコマンドを省いている可能性もあります。最後の説明だけでなく、実際の変更と根拠を確認してください。

実務上のボトルネックは、コードを書くことから判断をレビューすることへ移りがちです。個人開発者は、結果の差分を自分で説明できる範囲にタスクを絞ります。開発責任者は、完了報告に必要な根拠を定義してください。影響を受ける動作、実行したテスト、未解決の失敗、人による判断が必要な前提です。

次の開発作業から何を変えるべきですか？

開発者は範囲を絞ったチケットで現行のComposerを試し、開発責任者は自社リポジトリで根拠が得られるまでチーム全体の標準化を待つのがよいでしょう。 代表的なタスクから変更の具体的な理由が得られるまでは、うまく動いている環境を維持します。

1. 1

   選択中のモデルを確認します

   Cursorのチャットまたはエージェントパネルでモデル選択画面を開きます。現行のComposerを選んでいることと、使える速度設定を確認してください。選択は会話をまたいで保持されるため、新しいチャットでリセットされるとは限りません。

2. 2

   タスクに完了条件を付けます

   内容が明確なバックログ項目を選びます。期待する動作、互換性を保つべき点、成功を確かめる確認項目を伝えてください。実行できなかった確認があれば報告するよう、エージェントに求めます。

3. 3

   未確定の判断を適切なモデルに引き継ぎます

   作業中に未解決の設計判断が見つかったら、実装を一時停止し、適切な計画立案用モデルでその判断を検討します。「もっと頑張って」と曖昧に指示するのではなく、再現手順、制約、差分を引き継いでください。

4. 4

   受け入れる変更を評価します

   差分とテストの根拠をレビューします。許容できる修正負担で十分な成果が得られる作業では、Composerをデフォルトにします。設計上の判断や繰り返す失敗に応じて、別のモデルへ引き継ぐ経路も確保してください。

よくある質問

CursorのComposerとは何ですか？

モデル選択画面にあるComposerは、Cursor独自のコーディングモデルファミリーです。Cursor内でエージェントの作業を動かします。現在ドキュメントに掲載されているComposerのバージョンはComposer 2.5です。

Composerのバージョンはどう確認しますか？

チャットまたはエージェントパネルで選択中のモデル名を読み、現行のモデルリファレンスと照合してください。Autoはモデルの振り分けを選ぶ設定で、ターンごとに異なるモデルを使う場合があります。AutoであることはComposerを使っている証拠にはなりません。

Composer 2.5はコーディングに向いていますか？

Cursorは、対話的なコーディング向けに作られ、継続的な作業能力が改善したと説明しています。まず、成功したかを自分で検証できるタスクから始めてください。曖昧なアーキテクチャ変更では、実装を評価する前に設計を固めます。

Composerは何のために使いますか？

本記事のComposerはCursorのコーディングモデルを指します。エージェントのツールでリポジトリの作業を進めるために選ぶもので、特に対話しながら実装の方向を調整したい場合に使います。

Composerの使い方を教えてください

Cursorのエージェントパネルで現行のComposerモデルを選び、意図する変更と受け入れ時の確認項目を伝えます。作業を受け入れる前に、実際の編集内容とツールの実行結果を確認してください。

Composerというソフトウェアの用途は何ですか？

CursorのComposerの用途は、ソフトウェアエンジニアリングです。タスクを理解し、ファイルを調べ、変更し、エージェントツールを通じて結果を確認します。同名の別のソフトウェアは本ガイドの対象外です。

Composerはどのように動きますか？

モデルが操作を選び、ツールが実行し、その結果をもとに次の操作を決めます。Cursorは、実際の利用時に対応するエージェント環境のコーディングタスクでComposerを学習させ、長い作業を続けやすくする自己要約も学習させています。

無料で使えるComposerアプリはありますか？

Cursorのコーディングモデルを指しているなら、CursorのFreeプランでファーストパーティーモデルによるAgentとChatを制限付きで利用できます。Composerを無制限に使えるわけではありません。本ガイドでは作曲アプリの比較は扱っていません。

composer installは何のために使いますか？

インストールコマンドの検索と、Cursorのコーディングモデルの選択は別の話です。本記事で扱うモデルはCursorのモデル選択画面から使います。本ガイドはインストールコマンドのリファレンスではありません。

コーディングモデルの実用ガイドや、どんな作業を任せるべきかを知りたい方は、ニュースレターにご登録ください。