コスト10分の1でClaude Opus 4.6に匹敵。CursorのComposer 2がAI開発の常識を覆す理由

Cursorが静かにやらかした

Composer 2が出た。コーディング特化モデル。入力$0.50/M、出力$2.50/M。

Claude Opus 4.6は入力$5.00/M、出力$25.00/M。

計算するまでもない。10分の1だ。しかもベンチマーク性能はほぼ並んでる。

これ、普通にやばくないか。

Composer 2で何が起きたのか

2026年3月19日、CursorがComposer 2を正式リリースした。

Cursorが公式で出している料金はこうだ。

• Standardプラン: 入力$0.50/M、出力$2.50/M
• Fastプラン（デフォルト）: 入力$1.50/M、出力$7.50/M

比較対象として、AnthropicのClaude Opus 4.6は入力$5.00/M、出力$25.00/Mだ。Standardプランで見ると、入力・出力ともにOpus 4.6の10分の1のコストで動く。

性能の話もしておく。Cursorが独自に設計した内部ベンチマーク「CursorBench」でのスコアはこうなっている。

• Composer 2: 61.3
• Claude Opus 4.6: 58.2
• 前世代のComposer 1.5: 44.2

Composer 2がOpus 4.6を上回っている。コーディング特化ベンチマークで、だ。

ここまでが表の話。裏がある。

リリースから数日後、Kimi（中国のAIスタートアップ）の社員が自力で調査し、Composer 2のベースモデルがKimi K2.5であることを突き止めた。Cursorはこれを最初のブログ記事で一切開示していなかった。

Cursorの共同創業者が後から認めた内容によると、事前学習の約4分の1がKimi K2.5のベースモデル由来で、残りはCursorが独自にファインチューニングと継続学習を行っている。推論パートナーのFireworksを通じて商業ライセンスを取得しており、ライセンス上の問題はないとされている。

ただ、最初から言わなかった。それが批判を浴びた。

しんたろー：
「なんで隠したの？」って話、わかる気はする。「俺たちAnthropicとOpenAIに勝てないじゃん」って白状することになるから。でもそれより「中国OSSのファインチューニングで10分の1コストでOpus 4.6に並んだ」って最初から言えば、むしろ武器になったのに。タイミングが全部悪かった。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

「これ、僕らの開発に何を意味するの？」という話

2つの生存戦略が可視化された

今回の件で、AI開発の世界に2つの明確な路線が浮き彫りになった。

資本集約型。AnthropicとOpenAIがやってること。数十億ドルを投じて汎用フロンティアモデルを自前で作る。Claude Opus 4.6はエージェントコーディング、コンピュータ操作、金融分析などで業界トップ水準の性能を持つ。Anthropicは同時期にVercept社を買収してcomputer use機能を強化し、パートナーネットワークに1億ドルを投資している。エコシステムごと囲い込む戦略だ。

特化型・軽量型。Cursorがやったこと。強力なOSSモデルをベースに、コーディングという1つの領域に絞ってファインチューニングする。巨額の資金はいらない。特定領域ではフロンティアモデルに並べる。

どちらも成立する。それが証明された。

フロンティアモデルの「価値」が問われ始めた

Cursorのやり方が突きつけた問いはシンプルだ。

「数十億ドルかけて作った独自基盤モデルって、スマートなファインチューニングに対してどれだけのアドバンテージがあるの？」

コーディング特化ベンチマークでComposer 2がOpus 4.6を上回ったという事実は、フロンティアラボにとって居心地が悪い。汎用性や安全性への投資、コンピュータ操作のような複合タスクでは差が出る。「コードを書く」という行為に絞れば、差は想像より小さかった。

Claude Codeで毎日開発してる身からすると

僕はClaude Codeを使って日常的にコードを書いている。Claude Opus 4.6とSonnet 4.6を使い分けながら、ThreadPostの開発を進めている。

Composer 2の登場で気になったのは、タスクの性質によってモデルを使い分ける必要性がより明確になったことだ。

複雑な要件定義、エージェント的な操作、システム全体の設計判断。こういうタスクにはClaude Opus 4.6やSonnet 4.6の「推論の深さ」が効く。Anthropicのcomputer use機能はVercept買収後さらに強化される方向で、複合的な自動化タスクでの差はむしろ広がる方向にある。

一方、エディタ上での繰り返しのコード生成、リファクタリング、定型的な実装。こういうタスクにComposer 2を使えば、コストが10分の1になる。

「全部Opus 4.6に任せる」という選択肢は、コスト的に見直す余地が生まれた。

しんたろー：
うちの構成で言うと、Claude Codeでの複雑な設計判断はOpus 4.6系に任せたいし、そこは変わらない。ただ大量のコード生成とかリファクタリングのループを回すとき、コスト10分の1の選択肢が手元にあるのは普通に気になる。Composer 2、エディタ内での使い勝手が気になってる。

OSSファインチューニングが「現実的な選択肢」になった

もう一個、開発者として見逃せない話がある。

Cursorがやったことは、強力なOSSモデルのファインチューニングだ。Kimi K2.5をベースに、コーディング特化の継続学習を行い、フロンティアモデルに並ぶ性能を出した。

これ、Cursorだけの話じゃない。

自社プロダクトにAIを組み込みたい開発者にとって、「ゼロからモデルを作る」か「APIを叩く」かの二択ではなくなってきた。強力なOSSをベースにファインチューニングして、特定領域に特化させるという第三の道が、現実的な選択肢として機能することが証明された。

コーディングエディタという競争の激しい領域でこれが通用したなら、他のドメインでも応用が効く。

開発実務で今すぐ知っておくこと

Composer 2の料金を正確に把握しておく

公式の料金はこうだ（再確認）。

• Standardプラン: 入力$0.50/M、出力$2.50/M
• Fastプラン（デフォルト）: 入力$1.50/M、出力$7.50/M

デフォルトはFastプランだ。Standardプランを使うには意識的に切り替える必要がある。コスト最適化を狙うなら、この違いの把握は必須だ。

マルチモデル戦略を意識する

「全部同じモデルに任せる」という発想は、コスト効率の観点から見直す時期に来ている。

タスクを性質で分類するとこうなる。

1. 複雑な推論・設計判断・エージェント操作 → Claude Opus 4.6 / Sonnet 4.6
2. 大量のコード生成・リファクタリング・定型実装 → Composer 2（コスト優位）
3. 日常的なコード補完 → 各エディタのデフォルト設定を見直す価値あり

全部Opus 4.6に投げていたワークフローがあるなら、タスクの性質を見て仕分けする余地がある。

企業利用の場合はデータポリシーの確認を

Composer 2はKimi K2.5ベースであることが後から判明した経緯がある。企業での利用を検討する場合、Cursorの利用規約とデータ取り扱いポリシーを確認しておく必要がある。

コンプライアンス要件が厳しい業種では、「どのモデルを使っているか」「データがどこを経由するか」の把握は必須だ。推論パートナーのFireworks経由での運用という構造も、セキュリティレビューの対象になり得る。

OSSファインチューニングの選択肢を選定に入れる

自社プロダクトにAI機能を組み込む際、今後の選択肢はこうなる。

1. フロンティアモデルのAPI利用（Anthropic、OpenAI等）
2. OSSモデルのファインチューニング（Kimi K2.5、Llama等）
3. 特化型モデルの活用（Composer 2のようなドメイン特化モデル）

Cursorの事例は「2」が特定領域でフロンティアモデルに並べることを示した。自社のユースケースがコーディングのように「特定領域に絞れる」ものであれば、OSSファインチューニングはコスト面で圧倒的に有利になり得る。

しんたろー：
ThreadPost開発で言うと、今すぐComposer 2に全部移行するつもりはない。Claude Codeで複雑な設計の判断を回すのは変わらない。ただ「大量コード生成のコストが10分の1になる選択肢がある」という事実は、ワークフロー設計のときに頭に入れておく価値がある。透明性の問題は気になるけど、性能とコストの数字は事実だ。

---

よくある質問

Q1. Composer 2はClaude Opus 4.6と比べてどのくらい安いですか？

Composer 2のStandardプランは入力$0.50/M、出力$2.50/Mだ。Claude Opus 4.6は入力$5.00/M、出力$25.00/Mなので、入力・出力ともにOpus 4.6の10分の1のコストで利用できる。

デフォルトのFastプランは入力$1.50/M、出力$7.50/Mで、これでもOpus 4.6より大幅に安い。コスト最適化を狙うならStandardプランへの切り替えを意識する必要がある。ベンチマーク性能（CursorBench）はComposer 2が61.3に対してOpus 4.6が58.2。コーディング特化の評価ではComposer 2が上回っている。

Q2. Composer 2がKimi K2.5ベースであることによるリスクはありますか？

ライセンス面では、CursorはFireworksを通じた商業ライセンスを取得して運用しており、法的な問題はないとされている。ただし、ベースモデルの出所を当初開示していなかったことで透明性への批判が起きた経緯がある。

企業での利用を検討する場合は、Cursorの利用規約とデータ取り扱いポリシーを確認することが必要だ。推論パートナーのFireworksを経由する構造も含め、データがどこを通るかを把握しておくことがコンプライアンス上の基本になる。コーディングエディタという性質上、ソースコードが処理される経路には特に注意が必要だ。

Q3. Claude 4.6系とComposer 2はどう使い分ければいいですか？

タスクの性質で分けるのが現実的だ。

Claude Opus 4.6 / Sonnet 4.6が向いているタスク:

• コンピュータ操作（computer use）を伴う複雑な自動化
• 高度な推論が必要なシステム設計・アーキテクチャ判断
• エージェント的なタスク（複数ステップの自律実行）
• 金融分析や複合的な専門領域のタスク

Composer 2が向いているタスク:

• エディタ上での日常的なコード補完・生成
• 大量のリファクタリング
• 定型的な実装の繰り返し

コーディング特化ベンチマークでComposer 2がOpus 4.6を上回った一方、汎用推論や複合タスクではClaude系の優位は変わらない。「全部Opus 4.6に任せる」から「タスクで使い分ける」への移行が、コスト最適化の現実的な一手になる。

---

まとめ

10分の1のコスト。同等の性能。透明性の欠如。

Cursorがやったことは「特化型・軽量型」の生存戦略が機能することを証明した。隠し方が悪かったのは事実だが、数字は数字だ。

マルチモデル戦略、OSSファインチューニングの現実性、そしてフロンティアモデルの「価値」の問い直し。今回の件で動いたものは、思ったより多い。

---

👉 ThreadPostでSNS運用を自動化する