GrokとCursorの共同学習——モデル選びが、道具選びと同じになる日

新しいモデルが出ると、ついこう聞きます。

「前より強いのか。」 「他社より上なのか。」 「うちも切り替えたほうがいいのか。」

2026年7月8日に発表されたGrok 4.5も、その聞き方を誘います。SpaceXAIは自社の最も賢いモデルだと書き、コーディングやエージェント作業、知識仕事向けだと説明しています。

ただ、今回いちばん先に見るべきなのは、点数表ではありません。

Cursorの公式ブログは、SpaceXAIと一緒にGrok 4.5を出したと書き、mixture-of-expertsモデルを共同で学習したと明記しています。SpaceXAI側も、Cursorと並んで学習したと書いています。

つまり今回の発表は、「新しいモデルが来た」だけではなく、「モデルを作る側」と「毎日の開発道具を作る側」が、同じ学習の中に入った、という話です。

ここを外すと、切替判断はまた性能自慢の追いかけになります。

共同学習で何が変わったのか

Cursor側の説明では、訓練にCursorデータの数兆トークン規模が含まれます。対象は、既存のソフトウェアだけではありません。開発者がコードベースやツールとどうやり取りしたか、エージェントが環境とどう関わったか、という相互作用も含む、と書かれています。

以前のComposer 2.5は、コーディングに特化して学習した、とCursorは説明しています。一方Grok 4.5では、訓練データの混ぜ方を意図的に広くした、とも書いています。STEMの課題、研究論文、その他の知識仕事を入れ、ソフトウェア以外にも広げる、という方針です。

ここまでの話を、現場の言葉に落とすとこうなります。

静的なコードの山だけを読んだモデルと、実際の開発の行き来の中で育ったモデルは、同じ「コーディングモデル」という棚に並んでいても、育ち方が違います。

だから、APIの価格表だけを見て「安いから乗り換える」は危険です。育ち方の違いを、自社の代表タスクで確かめる前に、道具ごと乗り換える判断になってしまうからです。

いま使える範囲と、まだ使えない範囲

確認できる提供範囲は、次のとおりです。

• SpaceXAIの発表では、Grok Build、Cursorの全プラン、SpaceXAI consoleで利用できる
• Cursorの発表では、desktop、web、iOS、CLI、SDKで利用できる
• 個人向け・チーム向けのCursorプランに含まれ、初週は利用枠を倍にする、とCursorは書いている
• 料金は、CursorブログでもSpaceXAI発表でも、基本が入力100万トークン当たり2ドル、出力6ドル
• Cursor側には、入力4ドル・出力18ドルのfast variantもある
• SpaceXAI製品およびAPI consoleでは、開始時点でEU未提供。中旬見込みは予定であり、提供済みではない

ここで急がなくてよい判断があります。

EUで使う必要があるチームは、見込み日を確定日として扱わないことです。日本でCursorを使っている個人やチームでも、「全プランで使える」ことと、「自社の失敗条件を満たす」ことは別です。

価格が安いように見えても、再試行や長いエージェント作業まで入れると総額は変わります。料金表は比較の入口であって、採否の結論ではありません。

Composerは残る。置き換え話にしない

Cursorは、Grok 4.5とComposer 2.5を別のモデル重量クラスだと書き、Composer 2.5は継続提供する、同サイズの新しいモデルも今後出す、と明記しています。

これは地味ですが、現場には重要です。

「新しいモデルが出たから、今の日常作業も全部そちらへ」という話にはなりません。少なくともCursorの公式説明では、日常の速いコーディング用と、より広く長い作業用を併存させる構えです。

現場で起きやすい失敗は、ここです。

新しいモデルを試す前に、既存の日常作業までまとめて切り替えてしまう。結果、速く終わるはずの修正が重くなり、チームの不満だけが増える。

今後の展開を見るときも、同じ軸で見てください。

• Composer側の後継が出るのか
• Grok側がどこまで「ソフトウェア以外」へ広がるのか
• EU提供がいつ確定するのか
• Cursor内の利用枠や料金がどう変わるのか

どれも、発表文の予定や方針です。確定した運用条件になるまで、社内標準の切替日にはしないほうがよいです。

では、今後なにを追えばよいのか。

追うべきは、モデル名の更新履歴だけではありません。共同学習が続くなら、次に出るものも「単体の頭脳」ではなく、「どの道具のログで育ったか」がセットで来る可能性が高いです。CursorがComposer同サイズの後継を出すときも、Grok側がOffice作業や長い調査へ広がるときも、同じ問いを使えます。

その道具の中で、誰のどんな失敗が学習材料になっているのか。 自社の失敗の形は、それに近いか。 近いなら試す。遠いなら、話題に乗らなくてよい。

投資や買収の噂、順位表の一夜の変動は、ここでは採否の材料にしません。一次情報で確認できない話を、現場の標準に入れないためです。

ベンチマークより先に読むべき一文

性能比較の話をするなら、Cursor自身が書いた次の開示を先に置きます。

Grok 4.5はCursorBenchで有利になった可能性がある。理由は、訓練データにCursorコードベースの古いスナップショットが誤って入っていたからだ。影響の正確な大きさは不明で、そのデータは将来モデルでは除去する。CursorBench自体も大きな更新を進めており、今回の比較からは外している——Cursorブログはそう書いています。

これは弱い話ではありません。

モデルを出す側が、「うちのベンチでは勝ちました」だけで終わらず、測定の歪みを自分で書いた、ということです。

現場が学ぶべきなのは、「だからGrokは弱い」でも「だから信用できない」でもありません。

自社の採否を、提供者のベンチ表に預けない、ということです。

提供者が正直に歪みを書く時代でも、自社の代表タスク、失敗条件、確認者、止める条件は、自社で持つ必要があります。モデル比較そのものを外部表に丸投げしない。この一点を先に残します。

モデル選びが、道具選びと同じになる

共同学習が進むと、次の問いが強くなります。

このモデルは、どの現場の動きで育ったのか。 その育ち方は、自社の仕事の動きに近いのか。 試す場所は、その道具の中なのか、API単体なのか。

以前は、モデルと道具を分けて考えやすかったです。モデルはAPI、道具はエディタ。成績表を見て、あとから道具へつなぐ。

今回の形は、その順番を崩します。

道具の中で起きたやり取りが、次のモデルの材料になる。モデルは、またその道具の中で最初に配られる。評価も、道具の外の一般ベンチだけでは足りなくなる。

だから、切替判断はこう変わります。

「一番強いモデルはどれか」ではなく、「自社の代表タスクを、どの道具の中で、どの失敗条件まで見て試すか」です。

小さく試す場所の選び方そのものは、最初に試す1業務の選び方へ任せます。本稿で決めるのは、その前の一段です。

試す単位を「モデル名」だけにしない。 「Cursorの中のGrok 4.5」なのか、「APIのgrok-4.5」なのか、「Grok Build」なのかを分ける。 日常のComposer作業と、長い調査・修正のGrok作業を、最初から同じ箱に入れない。

Grok 4.5の採否を急ぐ必要はありません。条件付き試験、または地域要件で見送る、という置き方が妥当です。本稿はその条件の中身を、共同学習という切り口で具体化したものです。

条件付き試験にするなら、次を紙に残してから開いてください。

• 試すタスクは一つに限る
• 成功の定義と、失敗で止める定義を先に書く
• 機密データは入れない
• 日常のComposer作業は、試験中も別ルートのまま残す

この四つがない切替は、評価ではなく乗り換えです。

月曜までに残す判断

今後の展開を追うときも、ニュースの見出しより先に、次の四行を残してください。

1. 自社の代表タスクは何か
2. 失敗したら何をもって不合格とするか
3. 試す場所はCursor内か、APIか、Grok Buildか
4. 日常作業用のモデルと、長い作業用のモデルを分けるか

GrokとCursorの共同学習は、モデル業界の話題であると同時に、現場の道具の話です。

新しい発表を見るたびに「強いかどうか」だけを追う必要はありません。育ち方と使う場所が同じ側へ寄ってきた今は、採否の単位そのものを書き換えるタイミングです。