Cursor Composer 2が2026年3月にリリースされてから2ヶ月が経つ。$0.50/1M tokensという価格とSWE-bench Multilingualでのベンチマーク結果は話題になったが、運用コストを真に左右するのはキャッシュ読み取りの仕組みだ。実際の利用データを交えて、StandardとFastの選択基準を整理する。
なぜ専用モデルなのか
従来のCursorはClaude/GPT-4を裏でAPIコールしていた。Composer 2はコードデータのみで継続事前学習（Continued Pre-training）とRLをかけた自社モデルだ。
削ぎ落とされたのは「詩を書く」「歴史を語る」「倫理を議論する」能力全般。その代わりに得たのは：
- リポジトリ内のファイル依存グラフの推論（Aを直したらBも直す、という判断）
- 数百ステップに及ぶ長期タスクの自律実行
- サンドボックスターミナルとビルトインブラウザのループ
- 汎用モデルと比べて1/10のサービングコスト
価格（2026年5月時点）：
| モデル | 入力 (1M tokens) | 出力 (1M tokens) |
|---|---|---|
| Composer 2 Standard | $0.50 | $2.50 |
| Composer 2 Fast | $1.50 | $7.50 |
| Claude 4.6 Opus | $5.00 | $25.00 |
StandardとFastは「同じモデル」
Anysphereの公式の言葉は明確だ：「Same intelligence.」両バリアントはモデルの重みとパラメータが完全に同一。
違いはGPUの割り当てだけだ。Fastは高優先度キュー（H800/B200クラスのGPU）で即座に処理が始まる。StandardはGPUの空き時間や低優先度リソースを使うため、レスポンス開始まで10〜30秒の遅延がある。
推論コストはモデルの能力ではなく、計算リソースの優先度でスケールする。遅延を許容できれば、同じ出力が1/3の価格で得られる。
実務での使い分け
- Fastを使う場面： インタラクティブなチャット。出力をリアルタイムで見ながら次の指示を考える作業。レスポンスの遅さはフローを殺す。
- Standardを使う場面： ファイルを投げて放置するタスク。テストファイル100個の書き直し、リポジトリ全体のJSDoc生成、API移行。Enterを押してコーヒーを取りに行けばいい。
キャッシュ読み取りが本体
Composer 2への各リクエストには、ディレクトリ構造・開いたファイル・会話履歴がコンテキストとして含まれる。同じセッションで5回目、10回目のやり取りになると、そのコンテキストの大半は前回と同じ内容だ。それがキャッシュ読み取りになる。
キャッシュ料金（2026年5月）：
| 種別 | 新規入力 | キャッシュ読み取り |
|---|---|---|
| Standard | $0.50/1M | $0.20/1M |
| Fast | $1.50/1M | $0.35/1M |
5回以上やり取りが続くと、入力トークンの80%以上がキャッシュ読み取りになる。Standardのキャッシュ読み取り料金（$0.20）はFast（$0.35）より43%安く、Standardの新規入力（$0.50）より60%安い。
具体的な金額感： 大規模なリファクタリングで10回やり取りし、合計10Mトークン消費した場合：
- Composer 2 Standard（キャッシュあり）：約$1.50〜$2.00
- Composer 2 Fast：約$4.00〜$5.00
- Claude 4.6 Opus：$20以上
キャッシュバグの記録（2026年3〜4月）
実際のデータを見る前に、この時期のバグは記録しておく価値がある。
2026年3月末から4月にかけて、Composer 2 Standardでキャッシュ読み取りが0になるバグが発生した。同じコンテキストを何度送っても、毎回$0.50/1Mの新規入力として処理されていた。ユーザーの報告では「数時間の作業で今月のクレジットの26%が消えた」「通常の10倍のペースで減っている」。
皮肉だったのは、Fastに切り替えるとキャッシュが正常に機能するケースがあったことだ。単価が3倍高くても、キャッシュが効く分Fastの方がトータルで安上がりという逆転現象が起きた。
Cursorの開発チームが4月7日頃に修正をリリース。v2.1.116以降では安定している。
今キャッシュが正常かを確認する方法
cursor.com/settings → UsageでCache Readトークンの比率を確認する。同じコードベースで複数ターンやり取りしているなら、40〜90%がキャッシュ読み取りになるはずだ。0%や極端に低い数値が続く場合はバグの疑いがある。
チャット右上の「Copy Request ID」でIDを控えてサポートに連絡すると、クレジット補填の対応を受けられる可能性がある。
Claude Codeのキャッシュ（参考）
Claude Code（AnthropicのCLIツール）にも同様のキャッシュ機能があるが、TTL（有効期限）という概念がある。
| 設定 | 書き込みコスト | 読み取りコスト | 有効期限 |
|---|---|---|---|
| デフォルト | 入力の1.25倍 | 入力の約10% | 5分 |
| 1時間延長 | 入力の2.0倍 | 入力の約10% | 1時間 |
デフォルトの5分は実務では短すぎる。コードを確認したり、ドキュメントを読んだりして5分経つとキャッシュが消え、再書き込みコストが発生する。
Claude Code v2.1.108以降でENABLE_PROMPT_CACHING_1H=1を設定すると1時間に延長できる：
# ~/.zshrc または ~/.bashrc
export ENABLE_PROMPT_CACHING_1H=1
動作確認はusageコマンドのログでephemeral_1h_input_tokensが出ているかを見る。ephemeral_5m_しか出ていなければ設定が効いていない。
書き込みコストは上がるが、長時間セッションでは1時間キャッシュの方がトータルで安くなる。
自分の利用データで確認する
自分のCursor利用データ（442リクエスト、約1ヶ月分）をエクスポートして分析した結果がこれだ：
| モデル | リクエスト数 | 平均コスト | キャッシュ読み取り率 |
|---|---|---|---|
| Composer 2 Standard | 73件 | $0.19 | 88.3% |
| Composer 2 Fast | 25件 | $0.32 | 78.1% |
| Claude 4.6 Sonnet | 212件 | $0.37 | 84.7% |
| Claude 4.6 Opus | 93件 | $0.90 | 79.5% |
Standardのキャッシュ読み取り率88.3%が重要な数字だ。平均で約39万トークンを処理する1リクエストで、88%がキャッシュ読み取り（$0.20/1M）として処理され、新規入力（$0.50/1M）は最小限に抑えられている。
キャッシュが全く効かない場合、平均コストは約$0.19ではなく$0.40近くになるはずだ。つまりキャッシュが実際のコストをほぼ半減させている。
Opus最高額リクエストは1件あたり$4.25（合計390万トークン、うち382万がキャッシュ読み取り）。キャッシュ率が良くても、ベース単価の差でComposer 2 Standardの22回分のコストになる。
選択基準のまとめ
Composer 2は「安いClaude」ではない。汎用知能を削ぎ落として、コーディング性能とサービングコストに全振りした専用エージェントランタイムだ。
StandardとFastの選択は速度の好みではなく、タスクの性質で決まる：
- Standard： 3ターン以上続くマルチファイルタスク。キャッシュが積み上がるほどコストが下がる。
- Fast： 1〜2ターンの短い指示。対話のテンポが重要な場面。
- Frontier models（Opus等）： Composer 2が詰まった時だけ。複雑なアルゴリズムのデバッグ、コードに閉じないアーキテクチャ決定など。
Standardの本質は「遅いFast」ではなく、長いコンテキストウィンドウを使い回すほど単価が下がるバックグラウンド処理モードだ。