Composer モデルを使い始める
Composer は Cursor 独自のフロンティアなエージェント型コーディングモデルで、社内でトレーニングされ、1 つのことに最適化されています。それは、実際のコーディング作業を素早くこなすことです。計画を立て、複数のファイルを編集し、ターミナルコマンドを実行し、非常に低いレイテンシでツールをループします。そのすべてを、大型フロンティアモデルのほんの一部のコストで行います。本ガイドでは、Composer とは何か、どのように選択するか、どこで優れているか、どこで依然として Claude や GPT クラスのモデルに頼るべきか、そして日々の作業で最大限に活用する方法を説明します。
Composer モデルとは何か
Composer は、サードパーティからライセンス供与されたものではなく、Cursor チームが構築したカスタムモデルのファミリーです。コードベースを読み、計画を立て、ツールを呼び出し、ファイルをまたいで編集を適用し、結果を検証するという、エージェント型コーディングのために特別にトレーニングされています。コーディング向けに適応された汎用チャットモデルとは異なり、Composer は最初からエージェントループのために最適化されています。
このモデルラインの背後にある設計目標は次のとおりです:
- 低レイテンシ: 応答は素早く始まり、ツール呼び出しは長い間隔なしで実行されるため、編集とテストのループが即座に感じられます。
- エージェント効率: モデルは、各ステップをあなたが細かく管理するよう求めるのではなく、ツール呼び出しを賢く連鎖させるように調整されています。
- 価格効率: Composer はリクエストあたりのコストが最上位のフロンティアモデルより大幅に安く、これは長いエージェントセッションで重要です。
- 実用的な推論: 拡張思考モデルよりもはるかに高速でありながら、複数ステップの変更を計画できるだけの強さを持っています。
エディタ内では他のモデルと同様に動作します。モデルピッカーで選択すると、Chat、Agent モード、インライン編集、バックグラウンドエージェントを動かします。違いはスループットで感じられます。フロンティアモデルが 1 分間考えるタスクが、Composer では数秒で完了することが多く、日常的なコーディング作業の大部分で十分に通用する品質を備えています。
Composer モデルを、Cursor が 2024 年に提供した従来の「Composer」複数ファイル編集機能と混同しないでください。その初期のツールは、多くのファイルにまたがって変更を適用するための UI ワークフローであり、後に現在の Agent モードに統合されました。本ガイドで扱う Composer はモデルそのもので、Claude や GPT と同じピッカーから選択します。Composer を別個のパネルやキーボードショートカットとして扱っている古いチュートリアルを読んだ場合、それらはこのモデルではなく引退した機能について述べています。
Composer がサードパーティモデルとどう違うか
Claude、GPT、Gemini モデルは、Cursor がネットワーク経由でルーティングする汎用フロンテ ィアモデルです。Composer は異なる種類のものです。Cursor がエージェントループのために特別に構築したモデルです。その違いは、正確な内部構造が公開されていなくても、挙動に現れます。
基盤モデルの系譜とルーティングされたフロンティアモデル
Cursor でサードパーティモデルを選択すると、非常に広い分布でトレーニングされ、その後 Cursor のエージェントハーネスで包まれた、大規模な汎用モデルを呼び出しています。Composer を選択すると、コードベースのナビゲーション、ツール使用、高速な反復を最初から中心に設計目標が形作られたモデルを呼び出しています。実務的には次のことを意味します:
- サードパーティモデルは、レイテンシとリクエストあたりの価格を犠牲にして、膨大な広さと深い推論をもたらします。
- Composer は、一般的な推論ベンチマークではなく、コーディングタスクの特定の形に合わせて調整された、速度と低コストをもたらします。
- どちらの場合もハーネスが重要です。 Cursor のツール（ファイル読み取り、編集、ターミナル、検索）が両方の前に位置するため、比較は実際にはそのハーネス内でのモデルの挙動に関する ものです。
速度と深さのトレードオフ
これを「良い」と「悪い」の二択ではなく、深さとスループットの間のダイヤルと考えてください:
- 深さ重視のモデルは、内部でより多くの時間を計画と推論に費やし、曖昧で広範な問題で報われます。
- Composer のようなスループット重視のモデルは、より早く行動し、その速度が示唆するよりも推測が少なく、明確に範囲が定まったタスクで素早く収束します。
- 実際の作業のほとんどは混ざり合っています。既定ではスループット重視の端を使い、タスクが深さを必要とすることが判明したらエスカレートしてください。
参考としてのレイテンシ数値
トレードオフを具体的にするため、大まかな参考数値を示します。これらはおおよその目安として扱い、測定されたベンチマークとは考えないでください。レイテンシはタスクのサイズ、コンテキストの長さ、負荷に大きく依存します。
| シナリオ | Composer（おおよそ） | フロンティアモデル（おおよそ） |
|---|---|---|
| 最初の意味のあるト ークン | 1 秒未満 | 1 秒以上 |
| 短い単一ファイルの編集 | 数秒 | 10〜30 秒 |
| 複数ファイルのツール多用タスク | 数十秒 | 1 分〜数分 |
上記の数値は、違いの形を伝えるためだけに存在します。Composer は一貫して速く、ツール多用のループで差が広がります。これらを確定値として引用しないでください。精度が重要なら自分のワークロードで測定してください。
モデルピッカーで Composer を選択する
Composer は、モデルを選べるあらゆる場所で利用できます。Chat、Agent モード、そして Agent 内の Composer 流のインラインワーク フローです。切り替えるには:
- いつものパネルショートカットで Chat または Agent モードを開きます。
- 入力ボックスの隣にあるモデルピッカーをクリックします。
- モデル一覧で Composer を見つけます。Cursor の自社モデルはサードパーティモデルとは別にグループ化されています。
- Composer の項目を選択し、通常どおりプロンプトを送信します。
Settings > Models で Composer をデフォルトモデルにすることもでき、すべての新しいチャットがそれで始まります。多くの開発者は Composer をデフォルトに保ち、タスクが本当により深い推論を必要とするときだけ、手動でより重いモデルに切り替えます。
Composer はバックグラウンドエージェントのモデル一覧にも表示されるため、レイテンシを直接監視しないけれどコストと総所要時間を気にするリモートタスクの自然な選択肢になります。
Composer を使える場所
| サーフェス | Composer の使い方 | 典型的なコストモデル |
|---|---|---|
| Chat | モデルピッカーで選択する | リクエストごと、プランに対して課金 |
| Agent モード | 同じピッカー、複数ステップのタスクに使用 | リクエストごと |
| Cmd-K / インライン編集 | 素早い単一箇所の編集に利用可能 | リクエストごと |
| バックグラウンドエージ ェント | タスク開始時に Composer を選択する | リクエストごと、長いセッションほど高コスト |
| Tab 補完 | ピッカーの選択肢ではない。Tab は独自のモデルを使用 | モデルリクエストとは別に課金 |
リクエストごとのコストとトークンごとのコスト
Cursor のプラン使用量は一般に純粋なトークン単位ではなくリクエストごとに課金されるため、Composer のようなリクエストあたりの安いモデルは、生のトークン価格だけが示唆するよりもはるかにプランを長持ちさせます。実務上の 2 つの含意:
- 多くのツール呼び出しを連鎖させる長いセッションは、Composer の優位が最も大きくなる場面です。追加の各ステップが比較的安いからです。
- 生の API 用語でトークンコストを考えることに慣れている場合、Cursor は使用量をプラン消費として表示することを覚えておいてください。注視する数値はプランメーターであり、ドルの金額ではありません。
強みとトレードオフ
すべてに勝つ単一のモデルはありません。Composer が、通常交互に使うフロンティアモデルとどう比較されるかを示します。
| 能力 | Composer | Claude クラスのモデル | GPT クラスのモデル |
|---|---|---|---|
| 応答レイテンシ | 非常に高速 | 中程度から遅い | 中程度 |
| リクエストあたりのコスト | 低い | 高い | 高い〜中程度 |
| 複数ファイルの編集 | 強力、そのために専用設計 | 優秀 | 非常に良い |
| ターミナルコマンドの流暢さ | 強力 | 優秀 | 非常に良い |
| 深いアーキテクチャ推論 | 良好 | 優秀 | 優秀 |
| 長く曖昧なリファクタリング | 明確な指示があれば良好 | 最良 | 非常に良い |
| 高速な反復ループ | 最良 | 中程度 | 中程度 |
パターンは明確です。Composer はピークの推論深度を少し犠牲にして、速度とコストの大きな向上を得ています。明確に仕様が定まったコンポーネントの実装、失敗するテストの修正、マイグレーションスクリプトの作成、明確なインターフェースを持つモジュールのリファクタリングなど、日々のタスクの大部分では、フロンティアモデルが計画を立て終える前に Composer が仕事を終えます。
Composer とより大きなモデルの選び方
実用的な経験 則は、既定では Composer を使い、タスクがより深い推論を必要とする兆候を示したらエスカレートすることです。次の場合に Composer を選んでください:
- タスクの仕様が明確である: ファイル、従うべきパターン、完了の定義がわかっている。
- 素早く反復し、小さな編集のラウンドを何度か想定している。
- 定例のメンテナンス（依存関係の更新、リネーム、フォーマット主導のリファクタリング）を行っている。
- 多数の独立した小さなタスクをまとめて処理しており、コストがすぐに積み上がる。
次の場合は Claude または GPT クラスのモデルに頼ってください:
- 問題が曖昧で、モデルが広大なコードベースから意図を推測しなければならない。
- 相互依存する多数のモジュールにまたがる持続的な推論が必要である。たとえばクライアント、サーバー、スキーマ層に触れるプロトコル変更。
- 誤った推測のコストが高い、微妙な並行性、メモリ、正確性の問題をデバッグしている。
- 最初の応答の速さよりも最初の計画の質が重要な、アーキテクチャレベルの設計を行っている。
Composer でタスクを始めて、収束せずに堂々巡りしていることに気づいたら、新しいチャットを始めるのではなく次のターンでモデルを切り替えてください。既存のコンテキスト、開いているファイル、これまでの計画が引き継がれ、より強力なモデルが高速なモデルが停滞した地点から続けられます。
小さく高速なモデルのためのプロンプトのコツ
高速なモデルは正確さに報います。Composer はプロンプトが推測を排除すると著しく良く応答します。なぜなら、行う必要のない推測の 1 つ 1 つが、節約されるレイテンシとトークンだからです。
次の習慣に従ってください:
- ファイルとディレクトリを最初に明示する。 高速なモデルは広く計画しないため、適切な範囲を最初に指し示すことで軌道に乗り続けます。
- 完了の定義を述べる。 どのテストが通るべきか、どのコマンドを実行すべきか、どの挙動が変わるべきかを伝えます。
- プロンプトごとに 1 つの目的。 複数ゴールのリクエストは連続するプロンプトに分割し てください。エージェントループは、1 つの広大なゴールよりも小さなゴールの連鎖をはるかにうまく扱います。
- 既存のパターンに固定する。 望むパターンをすでに実装しているファイルを参照し、それに従うようモデルに求めます。
- 影響範囲を制限する。 触れてはいけないものを明示的に伝えます。たとえば「
UserServiceの公開 API を変更しないでください」。
Composer のためのよく形作られたプロンプトは次のようなものです:
In src/services/, add retry logic to the StripeClient class.
Follow the existing retry pattern in src/services/GithubClient.ts
(exponential backoff, max 3 attempts, logs via the shared logger).
Requirements:
- Only src/services/StripeClient.ts and its test file may change.
- Add unit tests mirroring GithubClient.test.ts.
- `npm test -- stripe` must pass when you are done.
Do not modify the public constructor signature.
これを「Stripe クライアントにリトライを追加して」のような曖昧なプロンプトと比較してください。どちらも結局は機能しますが、最初のバージョンは通常 1 回で完了します。まさにそれが速度最適化モデルの目的です。
高速モデルのためのプロンプト最適化
上記の習慣は基本をカバーしています。このセクションでは、高速モデルの作業を形作って 1 回目のパスで成功させる方法をより深く掘り下げます。
すべきこととすべきでないこと
| すべきこと | すべきでないこと |
|---|---|
| 正確なファイルとディレクトリを指定する | リポジトリ全体から「X がどこにあるか探して」とモデルに頼む |
| 完了の定義を述べる | 成功基準を暗黙のままにする |
| プロンプトごとに 1 つの目的を与える | 無関係な複数のゴールを 1 つのプロンプトに束ねる |
| コピーすべき既存のパターンを指し示す | まったく新しいパターンを文章だけで説明する |
| 変更してはいけないものを列挙する | モデルが影響範囲を推測すると仮定する |
| 検証ステップを求める | テストを省き、差分を目視で信用する |
良いプロンプトと悪いプロンプト
拡散したプロンプトは拡散した編集を生みがちです:
Clean up the auth code and make it better.
範囲を定めたプロンプトは、高速モデルが 1 回で完了するために必要なすべてを与えます:
In src/auth/session.ts, extract the token-refresh logic into a
private method refreshToken() and call it from getSession().
Constraints:
- Only src/auth/session.ts and src/auth/session.test.ts may change.
- Keep the public exports of the module identical.
- Mirror the structure of src/auth/oauth.ts, which already does this.
- `npm test -- auth` must pass.
Report the test output when done.
違いは丁寧さや長さではありません。モデルが自分で下さなければならない決定の数です。決定が少なければ誤った方向転換が減り、速度最適化モデルにとっては無駄な秒数が減ります。
タスクを小さなステップに範囲分けする
より大きなゴールを短いシーケンスに分解し、エージェントループに各ステップを運ばせます:
- 計画: 書面での計画を求め、編集の前に確認します。
- 実装: プロンプトごとに 1 つのファイルまたは 1 つのモジュール。
- 検証: 各ステップの後に関連するテストまたはコマンドを実行します。
- 継続: 前のステップがグリーンになって初めて次のステップに進みます。
明示的なファイル参照を与える
説明よりもパスとシンボルを優先してください。「請求書コードを更新して」よりも「src/billing/Invoice.ts を更新して」の方が優れています。可能なときは、従うべき正確な関数名や短いスニペットを貼り付けてください。そうすればモデルは検索に費やす時間が減り、編集に費やす時間が増えます。
検証を求める
高速なモデルは、検証を明示したときに最も恩恵を受けます。プロンプトを「npm test -- <scope> を実行して出力を貼り付けて」や「実行した正確なコマンドを報告して」といった行で締めくくってください。これにより、エージェントの速度が、検証されていない動きではなく信頼できる進捗に変わります 。
チームの規約をルールにエンコードする
Composer は速度のために最適化されているため、すべてを推論で解決する遅いモデルよりもガードレールに頼ります。規約を .cursor/rules に置くことは、高速なモデルで不相応に大きな効果を発揮します。コンパクトなルールファイル:
---
description: Service layer conventions for fast model edits
globs:
- "src/services/**/*.ts"
alwaysApply: false
---
- Follow the client class pattern in src/services/GithubClient.ts.
- All network calls use the shared http client; never import axios directly.
- Every public method needs a unit test in the matching .test.ts file.
- Prefer early returns; keep methods under 40 lines.
- After edits, run `npm test -- <affected-scope>` and report results.
このようなルールが整っていれば、Composer に短いプロンプトを投げて、反復的な標準が毎回言い直さなくても適用されると信頼できます。
バックグラウンドエージェントで Composer を使う
バックグラウンドエージェントは、あなたが何か別のことをしている間に Cursor のエージェントをリポジトリに対してリモートで実行し、差分やプルリクエストで報告します。Composer はそこでの最良のデフォルトであることが多いです。理由は 2 つ:
- コスト効率。 バックグラウンドタスクはより長く、より探索的である傾向があり、トークンコストはセッション全体で積み上がります。リクエストあたりの安いモデルは、バックグラウンドエージェントの群れを手頃な価格に保ちます。
- スループット。 複数の並列バックグラウンドエージェントを展開すると、各々が数分早く終わることが、はるかにきびきびとした全体的なワークフローに複合的に効いてきます。
Composer に適したバックグラウンドタスクには、モジュールの不足しているテストを書くこと、パッケージ全体に機械的なリファクタリングを適用すること、ドキュメントのスタブを生成すること、トラッカーから引っ張ってきた単純な問題を修正することなどがあります。システム全体にわたる判断を必要とするタスクでは、代わりに Claude または GPT クラスのモデルでバックグラウンドエージェントを開始するか、フォアグラウンドのエディタで計画フェーズを始めてから正確な計画を Composer に渡してください。
バックグラウンドエージェントは、対話セッションのように実行中にあなたへ確認の質問をできません。ゴール、制約、関与するファイル、成功の検証方法を与えてください。プロンプトを小さく自己完結したチケットとして扱えば、Composer はその自律性をうまく使います。
バックグラウンドエージェントにおける Composer
バックグラウンドエージェントは、Composer のコストと速度の優位が複合的に効く場所です。各ステップを座って見守っているわけではないからです。うまく委任するには少しの規律が必要です。
長時間実行タスクの委任
良い委任プロンプトは自己完結しており、チケットの形をしています:
Goal: add unit tests for every public method in src/services/Billing.ts.
Context: follow the testing style in src/services/Billing.test.ts if it
exists; otherwise mirror src/services/GithubClient.test.ts.
Scope: only create or edit test files under src/services/. Do not change
production code. If a method looks untestable as written, note it in the
final summary instead of refactoring.
Verify: `npm test -- services/Billing` must pass. Report the output.
スコープの選び方
- バックグラウンドタスクは 1 つのパッケージ、1 つのモジュール、1 つの関心事に保ってください。広いタスクは逸脱します。
- バックグラウンド実行には機械的な変更を優先してください: リネーム、テストカバレッジ、ドキュメントのスタブ、マイグレーションスクリプト。
- 好みやアーキテクチャの判断に依存するタスクは避けてください。それらは舵を取れるフォアグラウンドセッションで始めてください。
差分のレビュー
バックグラウンドエージェントは差分やプルリクエストを返すため、チームメイトの作業のようにレビューしてください:
- 触れられたファイルを、設定したスコープと照らし合わせて確認します。スコープ外のものは、より注意深く見るべきシグナルです。
- エージェントが主張する「行ったこと」の要約を読み、少なくとも 1 つの主張をコードで検証します。
- マージする前に、テストをローカルで実行するか、報告された出力を確認します。
- 差分がほぼ正しいが粗い部分がいくつかある場合、エージェント全体を再実行するのではなくエディタで修正してください。再実行は無関係な行を変更するかもしれません。
Composer は速く動くため、大きな差分を素早く生成できます。生成の速さは正確さの速さではありません。テストとスコープを検証するまでは、すべてのバックグラウンド結果を提案として扱い、実行時間だけでなくレビュー時間をスケジュールしてください。
コストと使用量の特性
Composer は Cursor プランを消費する最も価格効率の良い方法の 1 つです。実務上の含意:
- すべてをフロンティアモデルで実行する場合と比べ、プランの使用許容量に収まるエージェントリクエストが大幅に増えます。
- 多くのツール呼び出しを連鎖させる長いエージェントセッションは、各ステップのコストが低いため手頃なままです。
- 高速な応答はセッションあたりの所要時間を減らし、対話的に反復するときに間接的にコストを節約します。
ダッシュボードで使用量を監視すると、Composer をデフォルトにして 1 週間後には違いがはっきりわかります。同じ量の完了したタスクが、クォータの目に見えて低い割合で収まります。一般的な戦略は、フロンティアモデルのクォータを本当に推論の質を買う場面だけに使い、日常的な量は Composer に吸収させることです。
制限にカウントされるもの
Chat と Agent のリクエスト、Cmd-K 編集、バックグラウンドエージェントの実行はすべてプランにカウントされ、リクエストごとに課金されます。Tab 補完は一般に別に扱われ、ファイルの読み取りやコマンドの実行自体は課金されません。コストはそれらを呼び出すモデルのターンによって決まります。
相対的なコスト、速度、品質
以下の表は選択を助けるための大まかなおおよその比較であり、ベンチマークではありません。順位はモデルのバージョン間やタスクの構成によって変わりえます。
| モデル | 相対的な速度（おおよそ） | 相対的なコスト（おおよそ） | 相対的な推論深度（おおよそ） |
|---|---|---|---|
| Composer | 最速 | 最低 | 良好 |
| Claude Sonnet | 中程度 | より高い | 強い |
| Claude Opus | 最も遅い | 最も高い | 最も強い |
| GPT ファミリーのモデル | 中程度 | 高い〜中程度 | 強い |
| Gemini モデル | 中程度〜高速 | 中程度 | 強い |
この表は「Composer は速度とコストで勝ち、フロンティアモデルはピークの推論で勝つ」と読んでください。ほとんどのチームは、その逆ではなく、既定で Composer を使い意図的にエスカレートする形に落ち着きます。
Composer を他のモデルと組み合わせる
最強のワークフローは「永遠に 1 つのモデルを選ぶ」ことではありません。タスクの各フェーズを、それに合うモデルにルーティングすることです。
- 推論モデルで計画する。 Claude または GPT クラスのモデルで始め、計画だけを求めます。どのファイルに触れるか、どの順序で、どう検証するか。まだ編集はしないでください。
- Composer で実行する。 計画が書かれ、それに同意したら、実際の編集のためにモデルを Composer に切り替えます。明確な計画を持つ高速モデルは、計画を進めながら発見する高速モデルを上回ります。
- 2 つ目のモデルでレビューする。 編集が完了したら、別のモデルに切り替え、正確性、エッジケース、見落とされた要件について差分をレビューするよう求めます。結果を読む新鮮なモデルは、実行モデルが正当化して捨て去ったものを捕まえます。
Phase 1 (Claude/GPT, plan only):
"Read src/payments/ and propose a step-by-step plan to add idempotency
keys to the charge endpoint. List files, order, and verification. Do not edit."
Phase 2 (Composer, execute):
"Implement step 1 from the plan. Only src/payments/charge.ts may change.
Run `npm test -- payments` and report output."
Phase 3 (second model, review):
"Review this diff for correctness and edge cases. Flag anything that
breaks idempotency under retries."
この計画・実行・レビューのループは、高価で深い推論の呼び出しを小さく集中させ、Composer が実際の編集の量を吸収します。
タスクの途中でモデルを切り替えるとチャット、開いているファイル、計画がそのまま保たれるため、フェーズ間の引き継ぎにコストはかかりません。タスクを再説明する必要はありません。ピッカーを変更して続けるだけです。
今後の道: Composer 3
Composer ラインは活発に開発されており、コミュニティのロードマップには次のイテレーション（しばしば Composer 3 と呼ばれる）への要望がすでに溢れています。その議論で繰り返し現れるテーマには、より強力な長期的計画、非常に大きなリポジトリでの性能向上、曖昧な複数ステップタスクでの信頼性向上があり、同時に象徴的な低レイテンシと低コストを維持することが含まれます。
今日その恩恵を受けるために、これらのどれかを待つ必要はありません。現在の Composer モデルは製品品質の日々の相棒であり、モデル選択はコミットメントではなくドロップダウンなので、今すぐ採用し、新しい世代がピッカーに登場した瞬間に切り替えられます。
よくある問題と制限
Composer は高速であり、速度には早めに認識すべき失敗パターンがあります。
大規模で広範な編集を行う
Composer は一度にリポジトリ全体の変更を試み、広散でレビューしにくい差分を残すことがあります。
- 原因: 「ロギングをどこでもリファクタリングして」のような範囲を定めないプロンプト。
- 修正: 変更を 1 つのパッケージまたはモジュールに制限するか、タスクを範囲を定めた短いプロンプトのシーケンスに分解します。変更が本当に広い場合は先に計画を求めます。
長いタスクで指示を失う
長いセッションでは、コンテキストが増えるにつれて以前の制約が薄まることがあります。
- 原因: 1 つのチャットで目標が次々変わる多くのターン。
- 修正: 方向転換するときに重要な制約を言い直すか、目標とルールの簡潔な要約を添えて新しいチャットを始めます。
.cursor/rulesのルールファイルもセッション全体で規約を固定する助けになります。
ハルシネーションによる API
高速なモデルは時折、存在しないメソッドやパッケージを参照します。
- 原因: モデルがあなたのコードベースからではなくトレーニングからパターンマッチする。
- 修正: 明示的なファイル参照を与え、実際のソースと照合して検証するよう求めます。API をでっち上げた場合、実在する方を指し示し、リポジトリに存在するシンボルだけを使って編集をやり直すよう求めます。
コードベース全体のリファクタリングが必要
一部のリファクタリングは本当にシステム全体にまたがり、高速モデルが 1 回でうまく扱える範囲を超えます。
- 原因: 変更が横断的な依存関係と曖昧な境界を持つ。
- 修正: まず推論モデルで計画し、範囲を定めた一連の Composer ステップとして実行し、各ステップ後に検証します。単一の巨大な実行ではなく、パッケージごとに 1 つのバックグラウンドエージェントを検討してください。
タイムアウトや停滞
時折、特に非常に大きなタスクでエージェントの実行が停滞したりタイムアウトしたりします。
- 原因: 過度に広い目標、巨大なコンテキスト、または解決しない単一ステップ。
- 修正: タスクを絞って再試行します。再発する場合は作業を小さなステップに分割し、停滞し続けるステップにはフロンティアモデルを検討してください。長いバックグラウンド実行は、停滞のコストが 1 時間ではなく数分になるように範囲を定めてください。
症状から原因、そして修正へ
| 症状 | 考えられる原因 | 修正 |
|---|---|---|
| 巨大でレビュー不能な差分 | 範囲を定めないプロンプト | スコープを制限し、計画を求めてステップに分割する |
| モデルが以前の制約を無視する | 長いチャットでのコンテキストの希薄化 | 制約を言い直すか、要約した新しいチャットを始める |
| モデルが存在しないメソッドを呼ぶ | トレーニングに基づくパターンマッチ | ファイル参照を与え、実際のシンボルと照合して検証させる |
| コードベース全体のリファクタリングが危険に感じる | 横断的な変更 | 推論モデルで計画し、範囲を定めたステップとして実行する |
| 実行が停滞またはタイムアウトする | 過度に広いタスクまたは過大なコンテキスト | 絞って再試行し、小さなステップに分割する |
よくある質問
Composer は 2024 年の Composer 機能と同じですか?
いいえ。2024 年の「Composer」は Cursor UI の複数ファイル編集ワークフローであり、後に Agent モードに統合されました。本ガイドの Composer はモデルであり、Claude や GPT と同じピッカーから選択します。
Composer はどのモデルで動作しますか?
Composer は Cursor 独自の自社モデルラインで、サードパーティにルーティングされるのではなく Cursor チームがト レーニングしています。その速度とコストの特性は、汎用基盤モデルではなくその集中から生まれています。
Claude や GPT よりいつ Composer を選ぶべきですか?
明確に仕様が定まった高速で反復的な作業には既定で Composer を使ってください。タスクが曖昧である、相互依存する多くのモジュールにまたがる、または深いアーキテクチャレベルの推論を必要とする場合はエスカレートしてください。
実際の本番作業に十分ですか?
はい、日常的なタスクの大部分には十分です。指定されたコンポーネントの実装、テストの修正、機械的なリファクタリング、定例のメンテナンスなどです。高いリスクを伴う推論には、計画・実行・レビューのワークフローを使ってフロンティアモデルと組み合わせてください。
追加コストはかかりますか?
プランを消費する最も安い方法の 1 つです。プランは主にリクエストごとに課金されるため、リクエストあたりのコストが低いモデルは、より多くの作業を許容量に収められます。
タスクの途中でモデルを切り替えられますか?
はい、そして切り替えるべきです。チャット、開いているファイル、計画が引き継がれるため、推論モデルで計画し、コンテキストを失うことなく Composer に切り替えて実行できます。
編集が停滞したり堂々巡りしたりするのはなぜですか?
通常はタスクが 1 回のパスには広すぎたためです。スコープを絞り、明示的なファイルを与え、1 つのプロンプトですべてをこなすことを期待するのではなく各ステップ後に検証してください。
Composer 3 は登場しますか?
コミュニティの議論は、より強力な長期的計画と大規模リポジトリ性能を備えた次世代を指し示しています。待つ必要はありません。モデル選択はドロップダウンなので、新しいバージョンが登場した日に採用できます。
クイックリファレンス
| 質問 | 回答 |
|---|---|
| Composer とは何ですか? | Cursor の自社製で速度最適化されたエージェント型コーディングモデル |
| どこで選択しますか? | Chat と Agent モードのモデルピッカー、または Settings > Models |
| いつ使うべきではないですか? | 深く、曖昧で、アーキテクチャ重視の推論タスク |
| 古い Composer 機能ですか? | いいえ、2024 年の複数ファイルツールは Agent モードに統合されました |
| バックグラウンドエージェントで動作しますか? | はい、そしてそこではコスト効率の良いデフォルトです |
| 次は何ですか? | Composer 3 世代に関するコミュニティの議論 |
Composer は単純なワークフローに報います。既定でそれを使い、正確なプロンプトを書き、規約をルールにエンコードし、タスクが本当により深い推論を必要とするときだけフロンティアモデルにエスカレートすることです。その習慣により、Cursor 独自のモ デルラインの速度とコストの利点を、重要な場面で品質を犠牲にすることなく得られます。