Cursorが新たにリリースしたコーディング特化型モデル「Composer 2.5」の実力と、AI業界における価格破壊の現状を解説する。MoonshotのKimmy K25をベースに、大規模な強化学習とテキストフィードバック、高品質な合成データを組み合わせることで、既存の大規模モデルを圧倒する低コストと高速性を実現。競合するClaude CodeやGemini 3.5 Flashとの比較、さらにSpaceX AIとの提携による膨大な計算資源の投入と、将来的なモデル構築の展望まで、開発者の視点からリアルな使用感とともにその全貌を明らかにする。
低価格で超高速な新モデルの登場
先週、多くの人が見落としているかもしれない非常に素晴らしいリリースがありました。それは膨大な計算資源を持つ企業から発表されたもので、コーディングタスクの解決に極めて高い効果を発揮する小型モデルに焦点を当てています。そう、それはGemini 3.5 Flashではありません。本来ならそうであるべきだったのかもしれませんが、正解はCursorがリリースしたComposer 2.5です。これはとんでもないリリースです。Cursorが最先端の技術に追いつくスピードはかなり異常ですが、ここには私たちが議論しなければならない注意点もあります。
CursorのComposerシリーズのモデルに馴染みがない方のために説明すると、これは優れたオープンウェイトモデルを蒸留し、Cursor内で利用するための素晴らしいコーディングモデルへと仕上げる彼らの試みです。とはいえ、これは実質的にCursorの内部でしか使用できないため、外部でベンチマークを測定することが困難です。つまり、私たちは実際の使用感を通じて感覚的に評価するしかなく、それはCursor自身もある程度同じです。彼らは独自のベンチマークであるCursor Benchを含む素晴らしい数値を公表していますが、残念ながらこれは一般公開されていません。しかし、その結果は信じられないほど素晴らしいものであり、私自身が使ってみた感想としても、これは単なる誇大広告ではないと言えます。
これが史上最高のモデルであり、あらゆる用途にこれを使うべきだとは思いませんが、見て理解する価値は十分にあります。なぜなら、開発者が何を求めているかを理解している企業からの優れたモデルリリースであるだけでなく、主要なAI研究所が持っている強みが、プレッシャーの中で少しずつ崩れ始めていることを示しているからです。私はCursorの初期の投資家ですが、SpaceXとの間で起きている買収関連の動きにより、このツールを過剰に宣伝するインセンティブは完全に消え去っています。ですから、私が偏った見方でこれを紹介しているのではありません。純粋に非常に興味深いと感じたから共有しているのです。また、この動画の中では、Cursorの他の多くの部分についても率直に批判していくので安心してください。その上で、Cursorからこのレビューに対する支払いは一切受けていないことを明確にしておきます。
継続的インテグレーションの妥協とBlacksmith
継続的インテグレーションは強力ですが、多くの妥協が伴います。私はこれをCIの妥協の三角形と呼んでいます。継続的インテグレーションを設定する際に考慮しなければならない異なる要素のことです。まずは利便性、つまりこれを実装するのがどれほど簡単かという点から始まります。次にパフォーマンス、つまり実行にどれだけの時間がかかるかです。CIのランナーがもう少し速ければ良いのにと思うことはよくあります。そしてもちろんコストです。この三角形の中で異なる妥協点を持つ多くのCIソリューションが存在するのは当然です。なぜなら、これらすべてにおいて単に優れているものを作ることは不可能だからです。利便性が高く、速くて、さらに安いなんて方法はあるわけがない、そうですよね。
おや、これはBlacksmithの広告でしょうか。その通りです。GitHub Actionsから移行した場合、ほとんどの人にとってBlacksmithは2倍速く、60%安くなります。私も多くの顧客、例えばMercury、Supabase、Descript、Exaなどと同じように、話が良すぎると思っていました。しかし実際に使ってみると、これなしでは生きられないことに気づきます。単に安いだけでも価値がありますし、単に速いだけでも価値があります。そして、単に信頼性が高いだけでも十分に価値があります。しかし、さらにコンソールを発見すると、それがGitHubがここ数年で出荷したものよりもどれほど優れているかに気づくのです。実行しているワークフローに関する実際のメトリクス、どのワークフローのエラー率が高いか、そのエラーが何であるかを確認できるだけでなく、すべてのCIで何が起きているかについての非常に有用な詳細を示すログを得ることができます。
新しいプロジェクトでBlacksmithを設定し忘れるたびに、私は激しく後悔します。そして移行すると、ビルド時間が3分以上から1分未満に短縮されるのを目の当たりにするのです。開発者やエージェントには高速なCIが必要です。今すぐ導入しましょう。
AIモデルの複雑な料金体系
Cursorが発表した、この新しくて知的で、高速かつ安価なモデルについて話しましょう。まず価格についてお話ししたいと思います。多くの人がモデルの価格設定を理解していません。ここではできるだけシンプルに説明します。価格にはインプットとアウトプットのコストがあります。これらは100万トークンのグループ単位で計算されます。トークンとはテキストの塊のことで、通常は3から5文字、単語のようなものです。モデルはこのようにしてテキストを解釈し、テキストを生成します。インプットトークンは通常、アウトプットトークンよりもはるかに安価です。なぜなら、インプットはモデルに渡すデータであり、モデルはそれを使って次のトークン予測の推測を設定するだけだからです。アウトプットはモデルが実際に行う作業であるため、コストが高くなる傾向があります。
Claude 3.5 Sonnetのようなモデルの基本料金は、歴史的にインプット100万トークンあたり3ドル、アウトプット150万トークンあたり15ドルでした。100万トークンのコンテキストバージョンでは、さらに高価になることもありました。Anthropicはその後その設定をやめましたが、OpenAIは続けています。そしてOpusモデルはさらに高価になる傾向があります。例えばClaude 3 Opusはインプットが5ドル、アウトプットが25ドルです。GPT-5からGPT-5.2は、私の意見では非常に寛大な価格設定で、インプットが1.25ドル、アウトプットが10ドルでした。5.2ではインプット1.75ドル、アウトプット14ドルへと少し上昇しました。5.4ではさらにインプット2.50ドル、アウトプット15ドルへと上昇しました。そして5.5ではインプット5ドル、アウトプット30ドルという大幅な上昇となり、5.4の2倍になりました。
業界全体で価格が上がっているように見えますが、必ずしもそうとは限りません。価格設定を考慮する上で重要な、さらに2つのレイヤーがあります。1つ目は、実際に生成されているトークンの量です。Artificial Analysisのデータを見てみましょう。Artificial Analysisは、モデルが世界に公開している独自の内部ベンチマークでどれほど知的であるかを大まかに測定していますが、他の要素も測定しています。特に、モデルが問題を解決する速度、生成するトークンの数、そして実行にかかるコストです。ここで私がお気に入りの指標の1つが、アウトプットトークンの数です。ここで興味深いことに気づくでしょう。最も多くのトークンを出力したのは、最も賢いモデルではありませんでした。それはDeepSeek V4 Flash、GPT-5.4 Mini、そしてClaude 3.5 Sonnet 4.6でした。小さなモデルは、問題を解決するために必要以上のトークンを大量に生成することがよくあります。
また、このトークンの過剰使用を減らすために最も努力している研究所はOpenAIであるように見えます。5.5はSonnetが2億トークンを要したのと同じベンチマークにおいて、わずか7500万トークンしか出力しませんでした。ほぼ3分の1のトークン数でありながら、より高いスコアを獲得しています。さらに、ベンチマークで非常に優れたスコアを獲得している5.5 LowやMediumのようなモデルを加えると、5.5 Mediumは概ねOpus 4.7と同等のスコアを記録し、Lowバージョンはそれより劣るものの、5.4 MiniやFlashよりも大幅に高く、Sonnet 4.6とほぼ同等の位置にあります。トークンあたりの単価は高いですが、出力するトークンの量が圧倒的に少ないことを忘れないでください。5.5 Highの10分の1、Sonnet 4.6の30分の1以下です。5.5 Mediumはわずか2200万トークンです。つまり、非常にトークン効率の良いモデルなのです。
これが価格設定の2つ目の要因です。第1の要因はトークンあたりのコスト、第2の要因は問題を解決するためのトークン数です。そして第3の要因は、より良い取引を交渉する能力です。いくつかの研究所は、モデルの実行にかかるコストに対して最大90%もの上乗せ料金を請求しています。なぜなら、モデルを訓練した人員のコスト、実行するために購入しなければならなかった計算資源のコスト、訓練に費やした計算資源のコストなど、他の多くのコストがあるからです。彼らはそれらを価格に反映させなければなりません。しかし、これらの企業の多くは、仮にトークンあたり半額以上のディスカウントを提供したとしても、赤字にはなりません。それは単に機会損失になるだけです。したがって、彼らは訓練やその他の作業に費やした不条理な金額を正当化するために、莫大な利益を上げる必要があるため、請求できる限界の価格を設定しているのです。
開発環境市場の補助金戦争
それこそが、彼らが過剰な補助金を出せる理由でもあります。例えば、Claudeが20ドルのプランで月額4,000ドル分に相当する利用枠を提供するようなケースです。これらのプランは非常に強力な補助金が出ているため、Cursorに影響を与えています。なぜなら、あなたがGitHub CopilotやClaude Codeを購読している場合、あなたはCursorの競合製品を使用していることになり、AnthropicやOpenAIはあなたを彼らのエコシステムに囲い込むために、意味のある方法で利用料金を補助するからです。これがこの世界の仕組みの性質です。Claude Codeに200ドルを費やせば、4,000ドル以上の利用枠を得ることができます。Copilotでも同じかそれ以上のメリットを得られるでしょう。
しかし、APIを直接使用している場合、そのようなレベルの補助金は一切受けられません。30%のディスカウントを交渉できれば幸運な方です。つまり、Claude Codeのサブスクリプションにおける4,000ドル分の利用は200ドルで済みますが、CursorがAnthropicのモデルを4,000ドル分API経由で利用する場合、良くても3,000ドルのコストがかかっているはずです。これはCursorにとっていくつかの意味を持ちます。API価格の面でこれらのモデルが高価になることは、Cursorのユーザーが利用できる枠を大幅に損なうことを意味します。また、彼らが参加する余地のない補助金戦争で競争していることも意味します。なぜなら、もしAnthropicやOpenAIがCursorを潰そうと決定した場合、実際にその動きは見られますが、彼らには計算資源とモデルがあり、Cursorの支払額を増やしつつ、ユーザーが他製品を使うためのコストを下げるというレバレッジを持っているからです。これはCursorを非常に厳しい状況に追い込みます。
しかし、Cursorには他の誰も、ある意味では大手の研究所さえも持っていない強みが1つあります。それはデータです。なぜなら、Cursorは非常に多くの開発者がAIを使って構築するために長期間にわたって使用してきたツールであり、その多くは設定でデータの共有をオフにしていません。それは彼らがモデルを訓練するために使用できるデータです。単にあなたのコードベースを読み取ったというような話ではありません。人々はその部分に興味を持ちすぎますが、それはそれほど面白くありません。本当に興味深いのは、エージェントとどのようにやり取りしているかというプロセスです。エージェントと一緒に計画を立て、エージェントが何かを生成する際にフィードバックを与えます。ここが抜けているから、そこも変更してくれ、と伝えます。それらのチャット履歴は非常に価値があり、Cursorはここで二重の利益を得ることができます。彼らは他社よりも明らかに高い価格でモデルを仕入れてユーザーに再販していますが、適切なスイッチがオンになっていれば、そのデータを保持することもできるのです。
彼らはそれを利用して、より賢いモデルを訓練することができます。彼らが蒸留元にしているモデルほど賢くはないかもしれませんが、失われているマージンの多くを回収するには十分なレベルに達しています。なぜなら、もしあなたがOpenAIのモデルを使うためにCopilotではなくCursorを選ぶなら、結果としてOpenAIはより多くの利益を得ることになるからです。そして、これはCursorが生き残るために必要なことです。価格が上がり続け、補助金が継続する場合、Cursorを使うインセンティブは経済的に大きな損失になってしまうからです。
Composerモデルの劇的な進化
そのため、最初のComposerがComposer 1として登場し、インプットが1.25ドル、アウトプットが10ドルで、非常にトークンを消費する仕様だったとき、私は困惑しました。大して優れていないモデルにしては高すぎると思ったのです。その後のバージョン1.5は、意味のある改善が見られたものの、依然として素晴らしいとは言えず、Sonnetよりも高価でした。Sonnet自体がすでに割高で、インプット3.50ドル、アウトプット17.50ドルです。この時点で、私はしばらくComposerを見限っていました。未来が見えなかったのです。
しかし、それは私の間違いでした。私はジェイコブの可能性に賭けていなかったのです。そして、ジェイコブの裏をかくような賭けは絶対にすべきではありません。ご存知ない方のために説明すると、ジェイコブはSupermavenおよびTabnineの創業者です。SupermavenはCursorに買収され、彼はコード補完機能を現在の優れた形へと進化させました。彼はより大きな挑戦を望み、それがモデルの訓練側を始めた理由です。そしてComposer 2が登場しました。それは遥かに安価でした。バージョン1.5よりも7倍安く、さらに賢くなっていました。
そして現在、私たちは2.5を手にしています。価格はインプット50セント、アウトプット2.50ドルという同じ低価格を維持していますが、数値の面でCursor Benchにおいて輝きを放っています。ちなみに、これはタスクあたりのコストを示しています。グラフの左側ほどコストが高くなります。Composer 2.5は、GPT-5.5 HighとClaudeの最上位モデルの間のスコアを記録していますが、どちらよりも遥かに低コストです。これは非常に大きな意味を持ちます。Composer 2の時点ですでにこの意味においてかなり競争力があり、3.5 Flashや、ベースとなっているモデルであるKimi K2.6を圧倒していました。これは本当に興味深いことです。遙かに安価でありながら、OpusのMediumバージョンに近いレベルに達していました。しかし、2.5はトークン効率がわずかに向上し、大幅に賢くなり、かつ異常なほどの高速性を維持しています。
ここに、Cursorが現在ベンチマークの実行結果を公開しているすべてのモデルの数値があります。これは彼らの独自のベンチマークであるCursor Benchによるものです。このベンチマークの詳細の多くは公開されていません。私の理解では、彼らが遭遇した実際の問題を集めたものですが、一般には公開されていません。それには多くの正当な理由があります。例えばSWE-bench Proは汚染されています。本当にそうなのです。ベンチマークをオープンソースにすると、各研究所はそのベンチマークをより良くクリアするためのデータを取得してしまい、そのベンチマークは役に立たなくなります。そうなってしまうのは悲しいことですが、それが現実です。
どうやらComposer 2と2.5は、どちらも依然としてKimi K2.5をベースにしているようです。ベースをK2.6に切り替えなかったことで、彼らの数値はさらに異常なものになっています。彼らはComposerにおいて、ベースモデルであるKimi K2.5のスコアを実質的に倍増させ、ベンチマークで63%を記録しました。GPT-5.5は64%でした。Opus 4.7は20倍のコストをかけて65%に少し近づいた程度です。5.5は1パーセントポイント高いスコアのために、およそ10倍のコストがかかっていました。しかし、Composer 2.5がこれほど低価格でこれほどのクオリティを発揮するのは不条理なほどです。オープンウェイトモデルを蒸留して、特にコーディングタスクにおいてこのレベルの知性に近づけることができると示したのは、見ていて非常にクールであると同時に、モデルをコードに適合させるための作業の大部分が、事後学習とRL（強化学習）にあることを示しています。彼らはコード生成がそこそこ得意なモデルを採用し、膨大な計算資源と事後学習を投入して、強化学習を通じてコーディング能力を高めるよう強制し、それに成功したのです。
テキストフィードバックによる強化学習の実態
彼らがこれについて何と述べているか読んでみましょう。2.5がCursorで利用可能になりました。これはComposer 2と比較して、知性と挙動の面で大幅な向上を遂げています。長期的なタスクにおける継続的な作業や、複雑な指示へのより信頼性の高い追従が得意になり、共同作業がより快適になりました。彼らは訓練をスケーリングし、より複雑な強化学習環境を生成し、新しい学習手法を導入することでComposerを改善しました。Composer 2.5をより困難なタスクで訓練することに加えて、コミュニケーションスタイルや努力の較正といったモデルの行動面のアスペクトも改善しました。これらの次元は既存のベンチマークではうまく捉えられませんが、現実世界の有用性において重要であると私たちは考えています。
私も、これらの要素の多くは測定が難しいという点に強く同意します。Composer 2.5は、Composer 2と同じオープンソースのチェックポイントであるMoonshotのKimi K2.5をベースに構築されています。このチャートは気に入っています。少し狂っていますが、これがどのようにしてこれほど優れたものになったかを示しています。これは、訓練の各段階でどれだけの計算資源が使用されたかの推定測定値です。Composer 2.5に投入されたすべての計算資源を、Moonshotによって訓練されたオリジナルのベースであるKimi K2に基づいて分解し、それをさらに洗練させてより優れた賢いモデルにしたKimi K2.5と比較すると、Composerはそれに対してさらに約8倍の作業を行いました。最終的には合計で10倍以上の計算資源が投入されたことになります。
そして、彼らがこれを実現できたのは、SpaceX AIとのコラボレーションのおかげです。これは今でも非常に煩わしく奇妙な名前のコラボレーションですが。ご存知ない方のために説明すると、Cursorは現在SpaceXとの間で保留中の契約を結んでおり、彼らのコラボレーションに対して100億ドルが支払われるか（その主な目的はデータの取得であり、同時にCursorはさまざまな用途に使用できる計算資源へのアクセスを得ます）、あるいは年の終わりにSpaceXがCursorを600億ドルで買収することができます。現在の噂では、現在進行中である彼らのIPOの際にそれが起きると言われています。S-1書類が提出されたばかりです。したがって、これが実現し、CursorがSpaceXの一部になる可能性は低くありません。しかし、その計算資源は彼らにとって巨大だったようです。コラボレーションが始まってからこれほど早く、すでにコーディングのベンチマークで3位に入るモデルを出してきたのは驚異的です。
彼らはここでの訓練方法についても、いくつかの興味深い詳細を明かしています。最初の要素は、テキストフィードバックを伴うターゲットを絞った強化学習と呼ばれるものです。強化学習中のクレジット割り当ては、ロールアウトが数十万トークンに及ぶ可能性があるため、ますます困難な課題になっています。報酬がロールアウト全体に対して計算される場合、モデルにとって、どの特定の決定が結果を助けたのか、あるいは損なったのかを判断するのが難しくなることがあります。それは、不正なツール呼び出し、紛乱を招く説明、スタイルの違反といった局所的な挙動を抑制したい場合に、特に制限となります。これは本当に難しい問題です。強化学習において出力が機能したことを測定しているものの、その過程で3つの悪い処理を行った場合、実際の出力を失敗させることなく、その処理が失敗したとどのように伝えるべきでしょうか。最終的な報酬は、何かがうまくいかなかったことを教えてくれますが、それがどこで悪かったのかを示すシグナルとしてはノイズが多いのです。
そのため、彼らはターゲットを絞ったテキストフィードバックを用いて2.5を訓練しました。そのアイデアは、モデルがより良い挙動を示せたはずのトラジェトリ内の特定のポイントで、直接フィードバックを提供することです。ターゲットとなるモデルのメッセージに対して、望まれる改善を説明する短いヒントを構築します。そのヒントをローカルのコンテキストに挿入し、結果として得られるモデルの分布を教師として使用します。オリジナルのコンテキストを持つポリシーを生徒として使用し、生徒のトークン確率を教師の確率に近づけるポリシー内蒸留KLロスを追加します。興味深いアプローチです。つまり実質的に、この追加のコンテキストと情報を提供されることで正しい方向へ誘導された別のモデルが存在し、そのモデルが、同じコンテキストを持たない訓練対象のモデルに対して同様に振る舞うよう指示を出そうとするのです。
1つのモデルに対して、これが私たちの望む行動だと伝えます。そしてそのモデルは、追加の指示を実際には持たないもう一方のモデルを、その方向へ導こうと試みます。なぜなら最終的には、私たちはモデルに対して、進むべきすべてのステップでどのように振る舞うべきかを指示する必要があってはならないからです。私たちが望むものを伝えれば、モデルが自発的に適切に振る舞うべきなのです。ですから、これがうまく機能するというのは私にとって理にかなっています。これを聞くのは非常にクールですし、彼らがこれについて非常に透明性を持っているのも素晴らしいことです。
ここでの良い例は、ツールのエラーが発生した場合です。例えば、モデルが不正なツール呼び出しを行ったり、利用不可能なツールの呼び出しを試みたりした場合、モデルはツールが見つからないというエラーを受け取りますが、その後、モデルはさらに追加の有効なツール呼び出しを継続します。これはまさにGeminiの挙動を思わせます。DeepMindやGoogleの友人たちがこれを読んでいることを願っています。なぜなら、彼らがここで話していることをすべてコピーする必要があるからです。私が定期的に使用しているモデルの中で、Geminiモデルほどフォーマットの崩れたツール呼び出しを行うものは他にありません。それは、彼らがほぼ間違いなく最終結果に対して強化学習を行っているからです。したがって、5つの不正な呼び出しと8つの正しい呼び出しがあったとしても、結果が正しく出力されればモデルは気にしません。彼らはそれらの挙動を修正しようとしています。
何百ものツール呼び出しのプロセスの中で1つのエラーに遭遇したという事実は、最終的な報酬に対して最小限の影響しか与えません。その通りですが、ではそれをどのように修正するのでしょうか。テキストフィードバックを使用すれば、問題のあるターンのコンテキストに、例えば、注意、利用可能なツールは以下の通りです、といったヒントを挿入することで、特定のミスをターゲットにすることができます。そして、これはすべて単なる確率であることを思い出してください。コンテキスト内の要素や、それがモデルにどのように影響したかに基づいて、特定の特定の方法で回答する可能性が高くなります。したがって、異なるコンテキストを持つ教師が存在する場合、その確率は私たちが望むものとより良く一致します。それは、このプロセスで強化学習と訓練を受けている生徒モデルを、この情報を持つ教師のようにより振る舞うように導きます。したがって、その追加のコンテキストを与えることで、確率的に誤ったツール呼び出しを行う可能性を下げ、代わりに有効なツール呼び出しを行う可能性を高めるのです。そしてこの特定のターンにおいて、生徒のウェイトを新しい確率に向けて更新します。Composer 2.5の実行中、彼らはこの手法をコーディングスタイルからモデルのコミュニケーションに至るまで、さまざまなモデルの挙動に適用しました。
合成データとモデルの不正行為
彼らが持つ次の要素は合成データです。どうやら、彼らはもう私たちから収集したデータだけを使用しているわけではないようです。Composerのコーディング能力は大幅に向上し、大半の訓練問題を正しく解決し始めるレベルに達しました。知性を向上させ続けるために、彼らは実行全体を通じて、より困難なタスクを動的に選択および生成しています。Composer 2.5は、Composer 2の25倍の合成タスクで訓練されています。彼らは実際のコードベースに根ざした合成タスクを生成することから、さまざまなアプローチを使用しました。
例えば、1つの合成的なアプローチは機能の削除です。これらのタスクでは、エージェントに大規模なタスクセットを持つコードベースが与えられ、特定のテスト可能な機能が削除される一方で、コードベースが機能し続けるような方法でコードやファイルを削除するよう求められます。合成タスクの目的はその機能を再実装することであり、テストは検証可能な報酬として使用されます。これは、このデータを生成するための賢い方法です。モデルをより賢くするための作業の多くは、こうした種類の巧妙な工夫によるものです。他の動画でもこれらについて多く語ってきましたが、これはスマートな手法です。モデルに機能を削除させ、古いテストを使ってその機能を再実装させるのです。
大規模な合成タスク生成の副次的な結果の1つは、予期しない報酬ハッキングを引き起こす可能性がある点です。モデルがより熟達するにつれて、Composer 2.5は課されたタスクを解決するために、ますます洗練された回避策を見つけ出すことができるようになりました。ある例では、モデルは残されていたPythonの型ヒントのキャッシュを発見し、そのフォーマットを逆コンパイルして削除された関数のシグネチャを見つけ出しました。別の例では、Javaのバイトコードを見つけてデコンパイルし、サードパーティのAPIを再構築することができました。彼らはエージェント監視ツールを使用してこれらの問題を特定し診断することができましたが、これらは大規模な強化学習に必要なケアがますます増大していることを示しています。
ええ、私自身の他愛のないテストでも、このような現象を見たことがあります。少し前、私が取り組んでいる新しいフレームワークの実演をしようとして、このビルドのためにいくつかのデモプロジェクトを作成しました。そこでは、モデルが近くにある似たような名前の別のプロジェクトで、すでに実装されているToDoアプリを発見したことが確認できます。私が別のデモや複数のデモを行っていたため、モデルは近くにある他のプロジェクトを見つけ出し、それを利用してカンニングを繰り返したのです。データベースAPIを推測するのではなく、近くにあるキャッシュファイルを確認して更新された構文をチェックしています、という具合です。近くにある、サンプルが含まれている他のフォルダを見つけ出してしまったのです。モデルは成功するように訓練されているのであって、カンニングを回避するように訓練されているわけではありません。そして、モデルにカンニングをさせずに強化学習を行うというのは非常に難しい作業です。彼らがそのモデルハッキングの例を共有してくれているのは素晴らしいことです。
実際の開発における検証
もうこれくらいにしましょう。実際に動かしてみたいと思います。しかし、ここで少し不満を言わなければならない部分もあります。なぜなら、Glassは率直にいって、まだかなり使いにくいからです。これは、ConductorやCopilotアプリ、T3 Codeのようなシステムを構築しようとする彼らの試みですが、遅くて、不格好で、煩わしいものです。ここでは彼らが提供する最良の選択肢であるため、これを使用します。T3 Codeでは、CLI用のACPバインディングを介してCursorモデルをサポートしているため、ここでCursorモデルを使用できることは指摘しておきます。しかし、すべてを適切に使用しているか確認するために、今回はCursor Glassを使用して実行します。
これは煩わしいですね。このディレクトリに対してCursorを起動したところ、異なるプロジェクトの新しいスレッドビューが表示されてしまいました。これは私が最も頻繁に使用するコマンドなのですが。2回目は正しく開きましたが、品質管理がどれほど低下しているか、言葉にできないほどです。Glassが私たちの求めるリセットになってくれることを本当に期待していましたが、そうはなっていません。
これは私がお気に入りのテストの1つになっているのですが、すでに構築されていて、ある程度機能しているものの、多くの改善を必要とするゲームを用意し、モデルに対してこのディレクトリ内にゼロからそれを再実装するよう指示します。私のゲームであるfishをゼロから再実装したいです、より優れたアセット、より信頼性の高いコアエンジン、そしてそれを本物の高品質なウェブゲームにするための道筋を求めています、ビルドディレクトリはここにあるので、それをリファレンスとして使用してください、ゲーム全体をこのディレクトリ内に完全に実装してください、終わるまで止めないでください、と伝えます。何を行うか見てみましょう。
これの最もクールな点の1つは、非常に速いことです。すでに並行エージェントを立ち上げて異なる処理を同時に行っており、これは本当に素晴らしいです。彼らが行ったクレイジーなことの1つで、企業がこれほど大胆な試みをするのを見たことがないのですが、先週モデルの社内テストを行い、数日間にわたって従業員のすべてのCursorチャットをComposer 2.5にリダイレクトしました。その従業員は気づきさえしませんでした。これはモデルがいかに優れているかの証明です。それを聞くのは非常にクールです。そして、現在これが猛スピードで処理を進めているのが見えます。急ピッチで稼働しています。同じ要素に対して5回連続で編集を行いました。
マイナス1、プラス1、マイナス1、プラス1。興味深いですね。実際に結果のコードをチェックしています。昨日3.5 Flashで同じことを試したときには、そのような処理は行われませんでした。その点において、Composer 2.5と同時にリリースされた3.5 Flashは、2.5よりも大幅に低いスコアであり、2.0よりも低く、コストは1.94ドルかかりました。なぜ誰もがほとんどすべての用途において3.5 Flashを使用するのか、私には理解できません。単に良い選択肢とは言えません。
処理が完了しました。ページがロードに失敗しました。これが結果です。実際のページをレンダリングさせるのに失敗した2つのモデルのうちの1つになってしまいました。それは残念ですが、それほど驚くことではありません。これは、徹底的に強化学習を施された中国製のオープンウェイトモデルなのですから。これがどのように機能するか見てみましょう。
今、それらをアンロックするのに十分なシェルを持っています。Geminiが作成した、実際に機能しコアメカニクスが動作するものとは異なり、これは本当に常軌を逸しています。ここで生成されたアセットはあまり気に入っていません。それを修正するために、少し面倒なタスクを課してみましょう。オリジナルのゲームからすべてのアセットを引っ張ってきてください、と指示します。アセットをオリジナルのゲームのものと入れ替えることができるか、そしてどれほど迅速にそれができるか見てみましょう。
PNGアセットがFish Game Publicに存在しますが、globツールがそれらを検出するのに失敗しました。興味深い現象です。これは大きな動きです。ゲームのレンダリングパイプライン全体をライブで変更しています。バックグラウンドでゲームが点滅しながら、すべての変更が行われているのが見えます。どうやら完了したようです。30秒未満で終わりました。そして、オリジナルのアセットに切り替わりました。多くの要素が小さくなりすぎています。それを修正するよう伝えましょう。スケールが完全に狂っており、UIが読みにくいです、低コントラストです、と指示します。
デザイン能力の比較と評価
UIの話題が出たので、これが生成するUIについて話したいと思います。なぜなら、それは実際にかなり印象的だからです。このチャンネルの友人であるDraが、モデルがどのようにデザインを行い、どのように異なる方法でデザインを処理するかを比較できる素晴らしいツールを作成しました。皮肉なことに、そのサイト自体がComposer 2によってデザインされたものです。彼は異なるモデルに同じプロンプトを実行して異なるウェブページを生成させ、それらのデザイン能力がどれほど優れているかを確認しています。
そして、こちらがComposer 2.5から得られたデザインです。これは実際にかなりナイスで落ち着いた雰囲気です。フォントの使い方が気に入っています。ここに作成された小さな要素も良いですね。上品な粒子感があります。ええ、これは問題ありません。フロントエンドのデザインスキルが明確に活かされています。これらはすべてフロントエンドデザインスキルから得られるデザインだからです。これらのボタンの間隔が少し崩れています。そこは下揃えにするべきだと思います。ここもあまり良く見えませんが、このデザインの目標には従っています。
こちらのデザインは、単純に気に入りません。このような気取ったスタイルは好きではありません。レトロなものは嫌いです。そして、これは問題ありません。では、Anthropicのフロントエンドデザインスキルがない場合はどのようになるか見てみましょう。これは問題ありません。これも問題ありませんが、似すぎています。これは異なります。これは少し可愛い感じで異なっています。大好きというわけではありませんが、可愛いです。これはひどいですね。そして、これは古いTailwindやBootstrapのようなサイトです。このようなサイトはたくさん見たことがあります。これは紫とピンクのグラデーションのクラシックな、古い時代のデザインのように感じられます。悪くはありません。これほど安価なモデルからこの種のデザインが得られるのは、見ていて非常にクールです。
興味深いバグが発生しました。バックグラウンドの作業が完了したときに再開します、と表示されています。完了しようとしているバックグラウンド作業とは何でしょうか。教えてくれれば良いのですが。現在の見た目を確認してみましょう。
ええ、残念ながらこれについてはスケーリングが大幅に崩れてしまいました。コアとなるメカニクスは正しく処理できています。しかし、下部にあるこれらのボタンはクリックしても機能しません。ホットキーを押す必要があります。完璧とは程遠いですが、お金があまりなく、Cursorのサブスクリプションや学生割引などを持っている人なら、十分な調整とやり取りを重ねることで、ここから実際にまともなものを作り出すことができるルートは見えます。その道筋は確かに存在します。非常に快適な道というわけではありませんが、存在はしています。
ゲーム内の給餌メカニクスについては、実際に多くの問題を抱えています。残念ながら、私がこれまで見てきた中で最悪のソリューションというわけではありませんが、素晴らしいとも言えません。これは明らかに非常に複雑なタスクですが、もう少し期待していました。私の日常的な、ランダムなTypeScriptのエンドツーエンドの処理においては、比較的快適に使用できると感じていました。
外部ベンチマークの不在とクローズドなエコシステム
しかし、大きな問題があります。その問題は、私がGlassを気に入っていないということではありません、実際に気に入っていませんが。問題は、それが高すぎる、遅すぎる、あるいは馬鹿すぎるということでもありません。問題は、実際にはこちらのCursor Benchにあります。そして、問題はCursor Benchそのものではありません。それが不誠実なテストであるとか、そういったことではないのです。問題は、このチャンネルで語る他のすべてのモデルとは異なり、比較するための他の基準が一切存在しないという点です。私たちがこのモデルを自分自身でテストするために叩けるAPIは存在しません。
どれほどのお金を支払う意志があるかに関わらず、Composerを試す唯一の方法は、Cursorの内部で使用することです。彼らを買収するために600億ドルを費やさない限り、他の用途に使うことはできません。私が言おうとしているのは、Cursorが公開しているもの以外に、このモデルの実際の測定値が存在しないということです。LroはTerminal BenchやSWE-bench Multilingualを報告していると発表しましたが、悲しいことに、それは汚染されたテストです。モデルの訓練データにそれが含まれてしまうほどの情報がすでにリークしており、現在では信頼性が損なわれてしまっています。それが現実です。
伝えられるところによると、彼らはより外部的な評価のためにArtificial Analysisなどと協力しているとのことで、それを聞くのは非常に良いことです。しかし、彼らがこれに全力投球していない理由も一面的には理解できます。なぜなら彼らはこのモデルをコーディングのためだけに作成し、他の用途には一切考慮していないからです。そのため、例えばSkatebenchのようなテストでは非常に低いパフォーマンスを示す可能性が高いでしょう。そのようなユースケースのために構築されていないからです。コーディングのためだけに構築されているのです。そして、これらのベンチマークの多くは、例えばArtificial Analysisのインテリジェンスインデックス、彼らが持っているコアベンチマークにこれを投入した場合、ベンチマークの多くがコードではない内容であるため、パフォーマンスは非常に悪く、おそらくKimi K2.5と同等かそれ以下になる可能性があります。
ですから、彼らがこれを優先していない理由は分かりますが、さまざまな用途に非常に有用に見えるモデルを、Cursorのアプリを介するか、あるいは私たちが彼らに修正するよう強く迫らなければならなかったCLI上のACP実装を介してしか使用できないというのは残念なことです。しばらくの間、彼らは新しいComposerモデルを含まない、限定的なハードコードされたモデルセットを持っていたため、ACPバインディングを介してComposerモデルを使用することさえできませんでした。不快な仕様でした。チームとの多くのやり取りを経て、彼らはその後それを修正しました。
開発者の未来とCursorのエコシステム
彼らはまた、Cursor SDKを発表しました。これにより、Cursorのハーネスやインフラストラクチャなどを使用してエージェントを構築することが可能になります。これは仮説的には、Composer 2を使用し特定のディレクトリへのアクセスを持つエージェントを作成し、それに対してプログラムから処理を実行するようなコードを記述できることを意味します。これは特に、クラウドのリポジトリを指定することもできるためクールです。ここには多くの期待があり、何度も言及しているように、私はCursor Cloudの機能を心から本当に気に入っています。
cursor.com/agents は、最近の私にとって一貫して最もお気に入りのCursorの利用方法です。なぜなら、クラウド内に完全なLinuxボックスを持ち、それがiOSアプリのようなものでない限り、あなたのプロジェクトが何であれ起動して、コンピュータの利用を伴うテストを実際に実行できるからです。Composer 2や2.5のような高速なモデルと組み合わせ、これらを私のスマートフォンやSlackからトリガーできる機能は非常にクールです。彼らがこれらすべてを進めている方向性は気に入っています。ただ、これほど優れた数値を持つ新しいモデルを目にしながら、彼らのエコシステム全体を採用することなく、自分の環境でプログラムからそれを実行できないのが嫌なのです。
彼らは、APIを介して自社のリソースを一切公開していない、注目に値する唯一の研究所と言えます。これは、自社のツールを介した利用には補助金を出す一方で、直接APIを叩く場合には満額の料金を請求するAnthropicのような企業とは大きく異なります。現在起きていることで近い唯一の例はGemini 3.5 Flashです。これについてはAPI価格を支払うことができますが、毎秒200トークンではなく1000トークンで動作する完全な高速バージョンを求める場合、その最高速度を得るためにはAnti-Gravity IDEかCLIを使用する必要があります。
ありがたいことに、現在では研究所がモデルへのアクセスを根本的なレベルで制限しているケースはほとんどありません。通常は補助金を出すだけですが、現在私たちは、GoogleがAPI経由でモデルの高速バージョンの使用を制限しているため、遅いバージョンしか使用できないという状況に直面しています。以前はMistralも同様のことを行っており、当時彼らがCerebrasとのパートナーシップを通じて提供していた毎秒1000トークンで動作するモデルのバージョンがありましたが、公式のMistral APIを叩いた場合は毎秒約50トークンにとどまっていました。そして今、私たちは文字通りCursorのインターフェースを介してしかアクセスできないComposerを手にしています。API経由では一切利用できません。
どうやら、Cursorが公開したAsia SDKを使用することで、Piのようなツールでこれを動作させている人たちもいるようです。それは素晴らしいことです。そして、彼らがSDKの利用方法を制限することに関して、あの巨大なA社がそうであったような酷い手法を取るとは思いません。しかし、これを意味のある形でベンチマークしたり、他のツールに統合したりできないと感じるのは残念なことです。例えば、SnitchBenchの内部やPiの内部にあるAPIエンドポイントを、彼らがここで提供しているものに単純に切り替えたいと思っても、それはできません。彼らのSDKを使用するためにアプリケーションを再構築する必要があります。
そして、その価値はともかくとして、私はそのSDKについてあまり良い評判を聞いていません。認めざるを得ないのは、私自身がそれを試す機会をまだ得ていないことですが、いくつかの機能が欠落しており、まだ最も信頼性の高いスタックではないと聞いています。とはいえ、もし皆さんの多くがCursor SDKを使ってクールなものを構築すれば、私はチームにそれをさらに推進させるために必要なレバレッジを得ることができるでしょうし、それは本当に素晴らしいことです。ですから、私は皆さんがこれを使ってクールなものを構築することを引き続きお勧めします。ただ、もし切り替えなければならなくなった場合でも、それほど難しくないような方法で行うようにしてください。
結論と今後の展望
では、これらすべてに対する私の最終的な考えはどうでしょうか。もしあなたが、エージェントが動作するのをまだじっと見つめており、モデルに何かをリサーチさせ、それがリサーチして結果を返し、さらに変更を加えるよう求め、モデルがそれを実行し、その結果を確認するという、モデルと深くエンゲージした密接な共同作業を行っているタイプの開発者であれば、これほど高速で賢いモデルを持つことは本当に、本当に強力です。だからこそ私は3.5 Flashに興奮し、最終的にはコーディングにおいて十分な体験が得られなかったため失望したのです。
Composer 2.5は、ここではるかによいバランスを実現しています。最新のGPTモデルや最新のOpusモデルのように、自ら問題を解決して複雑なタスクを処理する能力は高くないかもしれませんが、非常に高速であり、かつ十分に肉薄しているため、かつてのコーディングを思い出させるような方法で、モデルとこのやり取りを行うことができます。違いは、これが遥かに賢く、遥かに有能であるという点です。
したがって、巨大なリポジトリを持つ大企業で働いており、本物のIDEでコードベースに向き合い、行いたい変更についてモデルと対話し、モデルが探索するのを20分も待ちたくないという人々にとって、これは信じられないほど素晴らしいモデルです。しかし、もしあなたが同じ対象に対して20のエージェントを並行して立ち上げ、すべてに異なる処理をさせ、エージェント17を立ち上げる頃にはエージェント1から6が完了している、というようなタイプの人間であれば、これはそれほど役に立たないでしょう。とはいえ、私自身は最近、超並行化のアプローチからは離れつつあります。頭の中に保持すべきコンテキストが多すぎますし、他の作業を行っている場合、それを維持することは不可能です。このコンピュータの中のランダムなワークツリーには、まだ見る機会さえ得られていないクールなプロジェクトがどれほど眠っているか、言葉にできないほどです。ですから、モデルとこのように深く関わるやり取りを行う場合、高速なモデルは非常に強力です。
私がこれを自信を持って言えるのは、私自身が最近それを経験したからです。私はここ2週間ほど、GPT-5.5を高速モードで使用しています。OpenAIの5.5イベントに参加したため、彼らから非常に多くの無料利用枠を受け取ったからです。参加を申請した全員が、確か10倍の増枠を得たはずです。そのため、ここ数日、これらのモデルを使用して文字通りゼロからクラウドを構築しているにもかかわらず（ええ、私はクラウドを構築しています。これについてはまた別の機会に話しますので心配しないでください）、毎週の利用制限はおろか、5時間の制限の1%さえ消化するのに苦労しています。これを使い切ろうと必死に努力していますが、あのイベントの結果としてあまりにも高い制限を与えられたため、文字通り不可能なのです。異常な状況です。それが現実です。
しかし、そのような経緯から、私は速さに依存するようになってしまいました。コストは2倍高いですが、トークンを使い切ることすらほとんどできないからです。一時的にその無料の10倍の増枠を得ていない、また開発者に補助金付きのトークン利用をさせることができない企業にとって、Composer 2.5 Fastは遥かに現実的な選択肢だと思います。開発者が実際にエディタを開いてファイルを読み、モデルと手を取り合うように変更を確認しているような大規模なコードベースを持つ企業にとって、これは優れたワークフローです。そして、これほど高速で、安価で、信頼性の高いモデルを持つことは、Cursorの顧客のアーキタイプに非常によく合致しています。なぜなら、Cursorはエンタープライズ領域で圧倒的な成果を上げているからです。
Amazonのような独自のIDEを構築してしまった大企業の友人たちを除けば、私が話す他のほぼすべての人がCursorを使用しています。Fortune 500企業の多くがCursorを採用しており、それは驚異的なことです。これは彼らにとって非常に大きな勝利であり、OpenAIやAnthropicとの間で間違いなく行われているであろう潜在的な交渉において、彼らが不利な契約を結ぶのを防ぐことになります。これは極めて重要な一手です。
そして、それらの他の研究所とは異なり、例えばAnthropicのところへ行って契約を結んだ場合、利用できるのは最新のOpusとSonnetモデルだけです。もしOpenAIが何かクールなことを行った場合、あなたは対応できません。もしCursorが何かクールなことを行った場合も、あなたは対応できません。OpenAIと組んだ場合も同じ状況になります。しかし、もしCursorと組むのであれば、少なくともComposerによる彼らの素晴らしいモデルを手にすることができます。さらに、もし他の研究所のいずれかがどのアプローチであれ追い抜いたとしても、あなたはそれへのアクセスも維持できるのです。したがって、Cursorは企業にとって引き続き非常に魅力的な賭けであり続けています。
そして、これらの開発は、彼ら自身が補助金を出し、ユーザーに対して本当に魅力的な価値提案を行える優れたデフォルトを持つことによって、その状況を大いに助けています。彼らはこのレースにおいてプレイヤーであり続けることができます。そして、奇妙に聞こえるかもしれませんが、私はMicrosoftのような企業よりも、Cursorが汎用人工知能のバブルや今後起こるあらゆる事態を維持できると信じています。なぜなら、少なくともCursorは、かつて私たちがからかっていたVS Codeのフォークの域を遥かに超えて、Microsoftには理解すらできないレベルで、実際の開発者のワークフローに焦点を当てた本物の研究所へと進化したからです。
2年後に私たちがどこにいるかを予想するなら、日々の開発作業において、Geminiによるいかなる製品よりも、XAIのCursor Composer 7を使用している可能性のほうが本当に高いと私は考えています。たとえバックグラウンドで何も起きていないときに何かが進行しているとモデルが勘違いしたとしても、バグは発生するものです。
最後に1つ、締めくくりたい話があります。Cursorは、新しいモデルを発表したスレッドで次のように投稿しました。SpaceXと共に、私たちは10倍以上の合計計算資源を使用して、ゼロから大幅に大規模なモデルを訓練しています。それは、Kimiが訓練された量よりも100倍多くなることを意味します。Colossus 2の100万枚のH100相当の資源と、私たちの複合的なデータおよび訓練技術により、私たちはこれがモデル能力の主要な飛躍になると期待しています。
Cursorがコードにおいて単に最先端に追いつくだけでなく、追い抜くということは十分に起こり得ます。わずか数ヶ月のうちに、Cursorがコードにおいて最高のモデルを持つことになる現実的な可能性があります。そして、その軌跡に目を向け、彼らが現在の位置までどれほど急速にスケールアップしてきたかを確認し、それを彼らが持つ異常な量の計算資源やデータ、そして彼らが解明してきたすべての新しい訓練手法と組み合わせるなら、彼らがそれを成し遂げる可能性は十分に高いと私は考えています。少なくとも、私はそう願っています。そうすれば、私の投資も価値を持つことになります。しかし、それがどうなるかはこれから分かります。
これについて、私から他に話すことはありません。もしあなたがまだCursorを使っているなら、絶対にこれを試すべきです。そして、もしCursorを使っていないなら、代わりに何を使っているのか興味があります。コメントで教えてください。それではまた次回。
コメント