
CursorのComposerは、Cursorに新しく追加されたコーディングモデルです。
低レイテンシであることを特徴としており、反復的なワークフローにおいて短いラウンドトリップを活かした対話的なコード生成が可能です。
特に関数の雛型作成やリファクタリング、バグ修正などでその強みを発揮します。
この記事では、Composerの使い方や料金、そして他のモデルとの違いについて解説します。
Cursorの新コーディングモデル「Composer」とは?

2025年10月29日のアップデートにより、Cursorに新コーディングモデルのComposerが追加されました。
この記事では、以前のエディタ内生成機能である旧Composerと区別するために、新Composerと記述します。
まずは新Composerの概要についてご紹介します。
Composerの位置づけ:低レイテンシのコーディング特化モデル
新Composerは、Cursor 2.0で導入された全く新しいコーディング特化モデルです。
その最大の特徴は、GPT-5 CodexやClaude Sonnet 4.5といった大規模モデルと比較して、思考深度よりも応答速度(低レイテンシ)を優先している点にあります。これにより、開発者はプロンプトを入力してから生成内容をレビューし、再実行するという反復的なワークフローを、数秒から数十秒単位の極めて短いラウンドトリップで回すことが可能になります。
Composer は、同等の知能レベルのモデル比で4倍高速な最先端モデルです。
このモデルは Cursor における低レイテンシのエージェント型コーディング向けに設計されており、ほとんどのターンを30秒未満で完了します。
出典:Cursor 2.0 と Composer を発表 · Cursor
日常的なコード片の生成や修正を高速に処理するモデルとして位置づけられており、大規模な設計や複雑な要件定義を担うモデルとは明確に役割が異なります。
旧Composerとの違いと混同ポイント
最も重要な注意点は、「旧Composer機能」と「新Composerモデル」の明確な違いです。
従来、「Composer」はエディタ内で直接コードを補完・生成する機能のことを指していました。これはエディタ内の機能名であり、本記事では「旧Composer機能」と呼称します。なお、現在はUI再編で実質的にAgentに統合されています。
一方で「新Composer」とは、今回新たに登場したコーディング特化のAIモデル名を指します。
この2つは全くの別物であるため、本記事では以降、この表記を厳密に使い分けます。
対応タスク:コード生成・編集・リファクタ・テスト補助
新Composerは、その高速な応答性を活かし、日常的なコーディング作業の大部分をサポートします。
具体的な得意タスクとしては、新規コンポーネントや関数の雛形作成、既存コードブロックのロジック修正、バグ修正などが挙げられます。また、選択範囲のコードをより簡潔な形に書き換えるリファクタリングや、既存の関数に対するテストコードの補助生成も得意分野です。
これらのタスクは、複雑な設計よりも素早い実装と反復が求められるため、新Composerの低レイテンシという強みが最大限に発揮されます。
CursorにおけるComposerの使い方:実践フロー

続いて、Cursorで新Composerを使う方法についてご説明します。
なお、Cursorの導入方法については以下の記事をご覧ください。

新Composerの使い方:複数モデルの並列実行方法
まずは新Composerをモデルとして選択して使用する方法について解説します。
画面左上の「Agents」タブをクリックし、UIをエージェントモードに切り替えます。

モデルのプルダウンを開き、Composer 1を選択します。

次にプロンプトを入力して送信しましょう。
プロンプトを入力する際、@Fileや@Repoを入力することでコンテキストを渡すことができます。
今回はエージェントモードで、リポジトリ内のコードをすべてリファクタリングしてもらうプロンプトを入力しました。

タスクの実行途中であっても、「New Agent」をクリックすることで新しいタスクを並列実行できます。

モデルを変更して実行することも可能です。

タスクの実行が完了したら、画面右に修正後の差分が表示されます。
差分を確認し、問題なければ「Keep All」をクリックして変更を適用しましょう。

もし適用したくなければ、「Undo All」をクリックすればもとに戻ります。
反復ワークフロー:生成→差分レビュー→テスト→再実行の30秒ループ
ここでは、実際に新Composerを使った反復ワークフローの例を示します。
まずはプロンプトを入力してコードを生成させます。

コード生成が完了したら、「Review」をクリックしてコードの差分を確認しましょう。

追加部分が緑色、削除部分が赤色で表示されます。

コードに問題がないか確認するため、プロンプトでテストの実行を依頼しましょう。

コマンド実行が必要な場合は確認されるので、許可して処理を進めましょう。

実行が完了すると、テスト結果が表示されます。

差分レビューで想定外の変更をしている場合や、テスト結果に問題がある場合、再度プロンプトを送ることで修正できます。

新Composerは低レイテンシであり、多くのターンが30秒未満で終了するため、このように何度もプロンプトを投げる場合でも素早く進めることができます。
差分レビュー、テストともに問題がなければ、「Keep All」をクリックして結果を適用しましょう。

Composerを使えるCursorの料金プラン

続いて、Cursorの料金プランについて解説します。
この記事では、個人向けプランと組織向けプラン別にご紹介します。
個人向けプラン比較
Cursorの個人向けプランとしては、Hobby・Pro・Pro+・Ultraの4種類があります。
それぞれのプランの違いはこちらです。
| プラン | 想定ユーザー | 月額 料金 | 年払い 料金 | Composerの選択 | Tab補完 | Agentリクエスト利用枠 |
|---|---|---|---|---|---|---|
| Hobby | 機能を試したいユーザー Tab補完のみを利用するユーザー | 無料 | 無料 | 制限あり | 制限あり | |
| Pro | 個人開発者 Agent機能をときどき使うユーザー | $20/月 | $16/月 | 無制限 | $20相当 | |
| Pro+ | AIを多用する開発者 日常的にAgent機能を使うユーザー | $60/月 | $60/月 | 無制限 | $70相当 | |
| Ultra | AI開発が業務の中心となるユーザー 複数エージェントの並列実行 | $200/月 | $200/月 | 無制限 | $400相当 |
Cursorは無料でも利用できますが、無料のHobbyプランではComposerを選ぶことはできません。そのため、新Composerを直接使いたい場合はProプラン以上の契約が必要となります。
なお、Proプランなら年払いすることによって割引が受けられるほか、無料で2週間のお試しもできます。
組織向けプラン比較
続いて、組織向けプランであるTeamsとEnterpriseについてご紹介します。
| プラン | 想定ユーザー | 月額料金 | 年払い料金 | Composerの選択 | Tab補完 | Agentリクエスト利用枠 | プライバシーモード | 管理ダッシュボード | 使用量のプール | 高度なセキュリティ制御 |
|---|---|---|---|---|---|---|---|---|---|---|
| Teams | スタートアップ 中小規模チーム | $40/ユーザー/月 | $32/ユーザー/月 | 無制限 | $20相当/ユーザー | |||||
| Enterprise | 大企業 高度なセキュリティ・コンプライアンス要件を持つ組織 | 要問い合わせ | 要問い合わせ | 無制限 | 要問い合わせ(プール型) |
組織向けプランではProプランの機能に加え、チーム向けの機能が搭載されています。請求の一元管理や使用状況統計を備えた管理ダッシュボード、組織全体のプライバシーモード制御などが提供されています。
Enterpriseプランではさらに、利用量のプールや高度なセキュリティ制御機能、請求書での請求などが可能です。特に大規模なチームや高度なセキュリティ要件を持つ組織におすすめです。
モデル利用枠とコスト最適化の考え方
Cursorの料金は、プランの料金に加えてモデルを利用する際のAPI料金がかかります。各プランにはそれぞれ利用分が含まれており、Proプランであれば$20分の利用枠が付与されます。利用枠の上限を超えた場合、従量課金で使い続けるかプランをアップグレードするかを選べます。
Cursorで利用できる主なモデルの100万トークンあたりの料金は以下の通りです。
| モデル | 入力 | キャッシュ書き込み | キャッシュ読み取り | 出力 |
|---|---|---|---|---|
| Composer 1 | $1.25 | $1.25 | $0.13 | $10.00 |
| Claude Sonnet 4.5 | $3.00 | $3.75 | $0.30 | $15.00 |
| Gemini 2.5 Pro | $1.25 | $1.25 | $0.13 | $10.00 |
| GPT-5-Codex | $1.25 | $1.25 | $0.13 | $10.00 |
| GPT-5 | $1.25 | $1.25 | $0.13 | $10.00 |
| Grok Code | $0.20 | $0.20 | $0.02 | $1.50 |
なお、これらの料金は各モデルのAPI料金に基づいており、変更される可能性があるため、公式サイトで最新情報を確認することをおすすめします。
CursorのComposerと他モデルとの違い

次に、新ComposerとCursorで使える他のモデルとの違いについて解説します。
この記事では、特にGPT‑5 CodexやSonnet 4.5との比較を行います。
速度・レイテンシで選ぶ:Composerが強いケース
新Composerは、その圧倒的な応答速度と低レイテンシが最大の強みです。
日常的なコーディングタスク、例えば既存関数のリファクタリング、テストケースの追加、あるいは単純なバグ修正など、思考を止めずに素早く結果が欲しい場面で真価を発揮します。生成されたコードの差分を確認し、即座に修正を指示するような反復的ワークフローに最適です。
特に、コンポーネントの雛形作成や定型的なコード生成において、GPT-5 CodexやClaude Sonnet 4.5の実行を待つよりも、Composerで素早く叩き台を得る方が開発効率は格段に向上します。
思考深度・到達精度で選ぶ:GPT‑5 Codex/Sonnet 4.5が強いケース
GPT-5 CodexやClaude Sonnet 4.5は、より複雑な思考と高い精度が求められるタスクで選択すべきモデルです。
例えば、新しいAPIの設計、複雑なビジネスロジックの実装、あるいはリポジトリ全体にわたる大規模なコードベースの変更など、深い文脈理解と高度な推論が必要な場面で優位性があります。
新Composerが素早く実装するためのモデルであるのに対し、これら上位モデルはより深い思考を行うモデルとしての役割を担います。
仕様が曖昧な段階での要件の壁打ちや、複数の依存関係を考慮した最適な実装パターンの提案など、一回での到達精度を重視するなら、これらのモデルが第一選択となります。
並列実行の実務パターン:設計(Plan)/実装(Build)の分担
Cursor 2.0の強力な機能であるモデルの並列実行は、これらモデルの強みを最大化する実務的なワークフローを可能にします。最も効果的なパターンは、設計(Plan)と実装(Build)の分担です。
まず、Claude Sonnet 4.5やGPT-5 Codexといった上位モデルに対し、実装したい機能の設計、インターフェース定義、主要なロジックのステップをPlanモードで生成させます。次に、その設計書をインプットとして、新Composerを使ってBuildを行います。
この手法により、上位モデルの深い思考力と、Composerの高速な実装力を組み合わせ、開発のボトルネックを解消できます。
Composerのユースケース

続いて、新Composerの具体的なユースケースをご紹介します。
Web/UI実装:コンポーネント生成とスタイル調整
新Composerは、フロントエンド開発における高速反復のサイクルで強みを発揮します。
例えば、ReactやVueの新しいコンポーネントの雛形作成を指示すると、即座にコードが生成されます。その結果を見ながら「Tailwind CSSを使ってスタイリングして」「このPropsを追加して」といった連続的なスタイル調整や機能追加の指示にも素早く応答します。

この生成からプレビュー、微修正までの短いラウンドトリップは、特にプロトタイピングやUIコンポーネントの量産フェーズにおいて、開発者の思考を妨げず、実装スピードを劇的に向上させます。
API/バックエンド:CRUDやスキーマ変更の適用
サーバーサイド開発において、新Composerは定型的ながらも正確性が求められるタスクを高速化します。
新しいAPIエンドポイントの追加時、@Fileで関連するスキーマ定義やモデルファイルをコンテキストとして渡し、「このスキーマに基づくCRUD操作を実装して」と指示するだけで、コントローラーやサービスの雛形が完成します。
また、データベースのスキーマ変更に伴う既存コードの修正作業も得意分野です。面倒なボイラープレートコードの生成をComposerに任せることで、開発者はより複雑なビジネスロジックの設計に集中できます。
テスト/リファクタ:既存コードの安全な改善
コードベースの品質維持と改善は、新Composerの高速な応答性が活きる領域です。
@Fileで既存の関数やクラスを指定し、「このロジックに対するユニットテストを生成して」と指示すれば、テストケースの叩き台を瞬時に得られます。
カバレッジの低い箇所を特定し、新Composerと対話しながらテストを追加していく反復作業も効率的です。
また、「この関数をリファクタリングして可読性を上げて」といった既存コードの安全な改善要求にも対応します。生成された差分を慎重にレビューすることで、コードの冗長性の解消を小さなステップで継続的に進めることが可能です。

Composerの注意点とFAQ

最後に、新Composerを使う際の注意点とよくある質問に対する回答をご紹介します。
旧Composer機能と新Composerモデルの厳密な使い分け
Cursor 2.0の導入において、最も混乱を招きやすいのが「Composer」という名称です。
本記事で定義する通り、旧Composer機能は、エディタ内で直接コードを補完・生成する機能を指します。
一方で、新Composerは、Cursorが独自に開発・チューニングした低レイテンシなコーディング特化AIモデルそのものです。
両者は全くの別物であり、性能や料金プラン、使い分けを議論する際は、この「機能」と「モデル」の呼称を厳密に区別する必要があります。
生成コードのレビューと安全対策
新Composerは高速ですが、万能ではありません。生成されたコードはAIによる提案と捉え、差分のレビューを必ずするように気を付けましょう。特に注意すべきは、AIが文脈を誤解し、不要な依存関係を追加してしまうケースです。
また、コード例の学習元データに起因し、意図せずハードコードされたAPIキーなどのシークレットや、不適切に広い権限設定を含むコードが生成されるリスクもゼロではありません。
生成コードは検証することを原則とし、必ず人間の目で安全性を確認してください。
失敗例と対処:長い依存関係/曖昧プロンプト/テスト不足
新Composerが期待外れの結果を出す典型的な失敗例は、コンテキスト不足が原因です。
複数のファイルをまたぐような長い依存関係を持つ複雑なロジック修正を、十分な情報を与えずに行わせようとすると、AIは依存関係を理解できずに誤った修正をしてしまう可能性があります。
対処として、@Fileや@Repoを活用し、関連するファイルを明示的にコンテキストとして読み込ませることが大切です。
「いい感じに直して」といった曖昧プロンプトも失敗の元であり、タスクは具体的に指示しなくてはなりません。
また、テスト不足はAI開発において避けるべきであり、生成コードの適用後は必ずテストを実行するフローを徹底するようにしましょう。
まとめ
Cursorの新Composerは、コーディングに特化したモデルであり、低レイテンシであることが特徴です。
特に反復的なワークフローにおいては、バグ修正やリファクタリングなどを対話的に素早く進めることができます。
利用には有料プランが必要となりますが、Proプランであれば無料で試すこともできるため、気になる方はぜひ新Composerを使ってみてください。
