Grok 4.5 は「コードを書くAI」から「仕事を進めるAI」への転換点か
こんにちは。Algomatic でソフトウェアエンジニアをしている Go（@53able）です。
Grok 4.5 は、どんなアップデートだったのか。
Cursor の発表を読むと、見どころは「より賢いコーディングモデル」への更新だけではないと分かります。狙いは、コードを書くだけでなく、調査し、ツールを使い、失敗から戻り、結果を検証する エージェント型の作業モデル にあります。
論点は、ベンチマーク表の順位だけではありません。むしろ次の問いです。
**AI は、短い質問に答える存在から、長い作業を任せられる存在へ移れるのか。
この問いを軸に置くと、Grok 4.5 の位置づけが見えやすくなります。
*本記事の図解はすべて Grok 4.5 で生成しています。*
- 何が変わったのか
- Cursor は Composer 系で足場を作っていた
- 学習したのは「コード」だけではない
- 強化学習環境も、エージェントで作っている
- DeepSWE が示している評価軸
- 価格・速度・効率も重要な売りになっている
- 評価で注意すべき点
CursorBench にはデータ混入の注記がある
- EU ではリリース時点で未提供
- まとめ
- エンジニアを募集しています！
何が変わったのか
Grok 4.5 は、Cursor と SpaceXAI/xAI が共同で学習したモデルです。Cursor の記事では、これを「ソフトウェアエンジニアリング以外の用途も見据えて開発した初のモデル」と説明し、用途や学習対象として次の範囲を示しています。
- ソフトウェアエンジニアリング
- データサイエンス
- 金融
- 法務
- STEM タスク（科学・技術・工学・数学の分野における課題）
- 研究論文を含む知識労働
Cursor はもともとコードエディタの会社です。しかし、エディタ上でエージェントに任せたい作業は、もはやコード生成だけではありません。
- リポジトリを読む
- バグの原因を探す
- 仕様を理解する
- テストを実行する
- エラーから復旧する
- ドキュメントを書く
- 調査結果をまとめる
こうした作業は、どれも「一発で答えを出す」タイプではありません。途中で調べ、判断し、手を動かし、検証する必要があります。Grok 4.5 は、この長い作業に寄せて作られたモデルだと読むのが自然です。
Cursor は Composer 系で足場を作っていた
Grok 4.5 の前段には、Cursor の Composer 系モデルがあります。Composer 2.5 はコーディング特化のモデルとして位置づけられており、Cursor の Grok 4.5 記事でも、Grok 4.5 ではそこから学習データの範囲を意図的に広げたと説明されています。
公式に「Composer の知見を Grok 4.5 へ移植した」と明言されているわけではありませんが、公開情報を並べると、次の関係として読むのが自然です。
- Composer 系で、エージェント型コーディングモデルの実装・運用経験を積む。
- Cursor 上の実利用データから、開発者とエージェントの相互作用を学習対象にする。
- Grok 4.5 では、その対象をコーディングからより広い知識労働へ広げる。
つまり Grok 4.5 は、Composer の直接の後継というより、Composer 系で見えていた方向性を、より大きく、より広い用途へ展開したモデルと考えられます。
学習したのは「コード」だけではない
Cursor の説明によれば、学習には数兆トークン規模のデータが含まれます。そこには静的なコードだけでなく、コードベースやソフトウェアツールに関するユーザーのやり取りも含まれています。
ここが重要です。従来のコードモデルは、完成したコードや公開リポジトリから多くを学びます。一方、実際の開発では、完成形よりも途中過程のほうが長いです。
- どのファイルを見るか
- どのエラーを疑うか
- どのコマンドを実行するか
- 泥臭い部分をどこまで直したら十分か
- 何をもって検証済みとするか
Grok 4.5 は、こうした「作業の進め方」まで学習したモデルとして説明されています。
だからこそ、Grok 4.5 は「コードを書く AI」よりも、開発作業を進める AI** として見るほうが近いです。
強化学習環境も、エージェントで作っている
もう一つの鍵は、強化学習のための環境構築です。
モデルが強くなると、既存のタスクはすぐに簡単になります。以前は難しかった問題も、次世代モデルにとっては定型問題になります。すると、さらに強いモデルを作るには、より難しく、より現実に近いタスクが必要になります。
Cursor の Grok 4.5 記事では、そのために分散エージェントシステムを使ったと説明しています。エンジニアが問題と検証方法を指定し、多数のエージェントが環境を構築し、テストし、改善する流れです。
ここには、いまの AI 開発を象徴する循環があります。
- 前世代のモデルを使って、次世代モデルの訓練環境を作る。
- エージェントを使って、エージェントを鍛える。
- 人間は問題設計と検証基準に寄る。
Grok 4.5 の背景には、「大きな計算資源で大きなモデルを学習した」という話だけでなく、訓練環境づくりそのものの変化があります。
DeepSWE が示している評価軸
Grok 4.5 の文脈では、DeepSWE のようなベンチマーク（評価基準）も補助線になります。Datacurve の公式説明によれば、DeepSWE は短いコード生成力ではなく、実務に近いコーディングエージェント（コード作成支援エージェント）評価を目指すベンチマークです。話題のベンチマーク: DeepSWE についても、その特徴を整理しています。
Grok 4.5 と DeepSWE が重なるのは、「一問一答のコード生成」ではなく「リポジトリ（ソースコード管理システム）を読んで作業を進める力」を見ている点です。特に次の観点が近いです。
- プロンプトが冗長で指示的すぎず、エージェントが変更箇所や実装方法を自分で発見する必要がある。
- 複数ステップを積み重ねる Long-Horizon Tasks（長期にわたるタスク）を含む。
- Datacurve の説明では、既存のコミットや PR（プルリクエスト）由来ではなく一から作られたタスクで、コンタミネーション対策（学習データへの汚染防止策）を意図しているとされている。
- TypeScript、Go、Python、JavaScript、Rust など複数言語を対象にしている。
- mini-swe-agent のような共通ハーネス（評価用枠組み）を使い、ビルダー側の実行環境差を抑えようとしている。
ここで見たいのは、単に「関数を一つ正しく書けるか」ではありません。曖昧な依頼からリポジトリを読み、必要な変更を見つけ、複数ファイルを直し、最後に検証できるかです。DeepSWE は、まさにそのエージェント的能力を測ろうとしています。
そのため、Cursor の Grok 4.5 発表に DeepSWE 1.0（Artificial Analysis）の数値が載っていることには意味があります。Cursor が見ているのは、単発の正答率だけではなく、エージェントとして作業を進める力でもあるからです。
同表では、DeepSWE 1.0 のスコアとして、Grok 4.5 が 62.0%（high）、Opus 4.8 が 55.8%（max）、GPT-5.5 が 64.3%（xhigh）、Composer 2.5 が 18.0%、Fable 5 が 66.1%（max）と示されています。
ただし、この数値だけで Grok 4.5 の優位性を断定するのは危険です。DeepSWE 1.0 では Fable 5 や GPT-5.5 のほうが高く、他のベンチマークでは順位も入れ替わります。
さらに DeepSWE には版の違いがあります。xAI/SpaceXAI 側は DeepSWE 1.0 を provider/native harness（プロバイダー/ネイティブ・ハーン）、1.1 を Datacurve の mini-swe-agent harness と区別しており、reasoning 設定（high / max / xhigh）によっても比較の意味が変わります。
ここでは「Cursor が DeepSWE を公式比較に入れた」ことを、Grok 4.5 の評価軸を読む手がかりとして見るのがよさそうです。一方で、その1本のスコアだけを全体の結論として扱うのは避けたほうがいいです。
価格・速度・効率も重要な売りになっている
xAI/SpaceXAI 側の発表では速度やトークン効率、低コストが訴求されています。また Axios は、Elon Musk の X 投稿を引用する形で、Grok 4.5 を「Opus-class model, but faster, more token-efficient and lower cost(Opus クラスのモデルですが、より高速で、トークン効率が高く、コストも低くなっています)」と紹介しています。
つまり、売りは最高性能だけではありません。同じような重い作業を、より速く、より安く処理できることも訴求しています。
xAI の Grok 4.5 docs、model detail、Pricingでは、API 価格は以下のように示されています。
- 入力: $2 / 100万 tokens
- cached input: $0.50 / 100万 tokens
- 出力: $6 / 100万 tokens
- Reasoning: low / medium / high
- 対応 API: Responses API, Chat Completions
- Tools: function calling, web search, X search, code execution
ただし、価格を見るときは注意が必要です。
モデル詳細ページでは、Grok 4.5 は 500K のコンテキストウィンドウ（context window）を備えている一方、200K トークンを超える高文脈（higher-context）の領域では別の単価が設定されています。キャッシュ入力（cached input）はキャッシュヒット時の単価であり、ドキュメント（docs）ではキャッシュを効かせるために prompt_cache_key や x-grok-conv-id の利用が推奨されています。推論トークン（reasoning tokens）もトークン使用量（token usage）として扱われます。
また、xAI の価格設定（Pricing）では、Web Search、X Search、Code Execution などのサーバーサイドツール（server-side tools）には、トークン使用量とは別に呼び出しコスト（invocation cost）がかかります。例として Web Search / X Search / Code Execution は 1,000 回呼び出しあたり 5 ドルとされており、関数呼び出し（function calling）はこれらのサーバーサイドツール呼び出しコストとは別枠で見る必要があります。
一方、Cursor の Grok 4.5 記事では、Cursor 内での価格として、ベースモデルが入力 $2/M・出力 $6/M、ファストバリアント（fast variant）が入力 $4/M・出力 $18/Mと書かれています。これは Cursor のモデル提供・課金体系上の表現なので、xAI API の価格設定と比較するときは条件をそろえる必要があります。
評価で注意すべき点
CursorBench にはデータ混入の注記がある
Cursor の Grok 4.5 記事には、重要な脚注があります。
Grok 4.5 が CursorBench で有利だった理由として、Cursor のコードベース（codebase）の以前のスナップショットが誤って学習に含まれていたと説明されています。正確な影響は不明で、今後のモデルではそのデータを除外し、CursorBench も大規模に更新中とされています。
このため、少なくとも CursorBench に関しては、スコアをそのまま汎化性能（generalization performance）の証拠として読むべきではありません。
Grok 4.5 の実力を見るなら、CursorBench だけではなく、DeepSWE、SWE-Bench 系、Terminal-Bench、実運用での作業成功率などを分けて見る必要があります。なお Cursor の脚注では、SWE-Bench Pro と Terminal-Bench はサードパーティ製モデル（third-party models）の自己申告スコア（self-reported scores）を示すと説明されています。DeepSWE の版・ハーネスの違いについては前節のとおりです。
EU ではリリース時点で未提供
xAI/SpaceXAI の発表・報道では、Grok 4.5 は Grok Build、Cursor、API console で利用可能とされています。
ただしローンチ時点の EU では、SpaceXAI/xAI の各製品・API console のいずれもまだ利用できないという caveat が付いており、xAI のモデル詳細では availability は later this month（報道では mid-July 見込み）と説明されています。地域ごとの提供状況は変わりうるため、現時点の可否は docs や console で確認するのが安全です。
まとめ
Grok 4.5 を「また賢いモデルが出た」で片づけると、見えにくくなるものがあります。
このリリースは、Grok シリーズの通常アップデートというより、Cursor と SpaceXAI/xAI が「エージェント時代の作業モデル」を作ろうとしている流れの一部です。Composer 系で積んだコーディング特化モデルの経験、Cursor 上の実利用データ、開発者とエージェントの相互作用、強化学習用の難しい環境、SpaceXAI/xAI 側の大規模計算資源。これらが重なって Grok 4.5 が生まれました。
私が注目しているのは、その先です。このモデルは、仕事の任せ方を考え直させます。
Grok 4.5 は「コードを書くモデル」から「ツールを使って長時間の知識労働を進めるモデル」へ移るためのリリースです。だとすれば、使い手の側も発注の粒度が問われます。一問一答を投げる使い方から、調査・実装・検証まで含む一続きの作業を渡す使い方へ。高いスコアのモデルを選ぶ問題というより、どこまで任せる仕事を自分が用意できるかという設計の問題です。
だから、このリリースはベンチマーク表だけでは測りきれません。どのような作業を任せようとしているのか、どのような訓練環境で作られたのか、どの評価軸で測られているのか。この三つを切り分けて読み、自分の現場のどの仕事をこの作業モデルに預けられるかを考える。そこまで踏み込むと、Grok 4.5 の位置づけが見えてきます。
エンジニアを募集しています！
ここまで読んでいただきありがとうございました！
Algomatic では、「AI 革命で人々を幸せにする」をミッションに、変化の速い領域でも学びや試行錯誤を続けられるエンジニアを募集しています。
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
原文を表示
こんにちは。AlgomaticでソフトウェアエンジニアをしているGo（@53able）です。
Grok 4.5 は、どんなアップデートだったのか。
Cursor の発表を読むと、見どころは「より賢いコーディングモデル」への更新だけではないと分かります。狙いは、コードを書くだけでなく、調査し、ツールを使い、失敗から戻り、結果を検証する エージェント型の作業モデル にあります。
論点は、ベンチマーク表の順位だけではありません。むしろ次の問いです。
AI は、短い質問に答える存在から、長い作業を任せられる存在へ移れるのか。
この問いを軸に置くと、Grok 4.5 の位置づけが見えやすくなります。
*本記事の図解はすべて Grok 4.5 で生成しています。*
- 何が変わったのか
- Cursor は Composer 系で足場を作っていた
- 学習したのは「コード」だけではない
- 強化学習環境も、エージェントで作っている
- DeepSWE が示している評価軸
- 価格・速度・効率も重要な売りになっている
- 評価で注意すべき点
CursorBench にはデータ混入の注記がある
- EU ではリリース時点で未提供
- まとめ
- エンジニアを募集しています！
何が変わったのか
Grok 4.5 は、Cursor と SpaceXAI/xAI が共同で学習したモデルです。Cursor の記事では、これを「ソフトウェアエンジニアリング以外の用途も見据えて開発した初のモデル」と説明し、用途や学習対象として次の範囲を示しています。
- ソフトウェアエンジニアリング
- データサイエンス
- 金融
- 法務
- STEM タスク
- 研究論文を含む知識労働
Cursor はもともとコードエディタの会社です。しかし、エディタ上でエージェントに任せたい作業は、もはやコード生成だけではありません。
- リポジトリを読む
- バグの原因を探す
- 仕様を理解する
- テストを実行する
- エラーから復旧する
- ドキュメントを書く
- 調査結果をまとめる
こうした作業は、どれも「一発で答えを出す」タイプではありません。途中で調べ、判断し、手を動かし、検証する必要があります。Grok 4.5 は、この長い作業に寄せて作られたモデルだと読むのが自然です。
Cursor は Composer 系で足場を作っていた
Grok 4.5 の前段には、Cursor の Composer 系モデルがあります。Composer 2.5 はコーディング特化のモデルとして位置づけられており、Cursor の Grok 4.5 記事でも、Grok 4.5 ではそこから学習データの範囲を意図的に広げたと説明されています。
公式に「Composer の知見を Grok 4.5 へ移植した」と明言されているわけではありませんが、公開情報を並べると、次の関係として読むのが自然です。
- Composer 系で、エージェント型コーディングモデルの実装・運用経験を積む。
- Cursor 上の実利用データから、開発者とエージェントの相互作用を学習対象にする。
- Grok 4.5 では、その対象をコーディングからより広い知識労働へ広げる。
つまり Grok 4.5 は、Composer の直接の後継というより、Composer 系で見えていた方向性を、より大きく、より広い用途へ展開したモデルと考えられます。
学習したのは「コード」だけではない
Cursor の説明によれば、学習には数兆トークン規模のデータが含まれます。そこには静的なコードだけでなく、コードベースやソフトウェアツールに関するユーザーのやり取りも含まれています。
ここが重要です。従来のコードモデルは、完成したコードや公開リポジトリから多くを学びます。一方、実際の開発では、完成形よりも途中過程のほうが長いです。
- どのファイルを見るか
- どのエラーを疑うか
- どのコマンドを実行するか
- 泥臭い部分をどこまで直したら十分か
- 何をもって検証済みとするか
Grok 4.5 は、こうした「作業の進め方」まで学習したモデルとして説明されています。
だからこそ、Grok 4.5 は「コードを書くAI」よりも、開発作業を進めるAI として見るほうが近いです。
強化学習環境も、エージェントで作っている
もう一つの鍵は、強化学習のための環境構築です。
モデルが強くなると、既存のタスクはすぐに簡単になります。以前は難しかった問題も、次世代モデルにとっては定型問題になります。すると、さらに強いモデルを作るには、より難しく、より現実に近いタスクが必要になります。
Cursor の Grok 4.5 記事では、そのために分散エージェントシステムを使ったと説明しています。エンジニアが問題と検証方法を指定し、多数のエージェントが環境を構築し、テストし、改善する流れです。
ここには、いまのAI開発を象徴する循環があります。
- 前世代のモデルを使って、次世代モデルの訓練環境を作る。
- エージェントを使って、エージェントを鍛える。
- 人間は問題設計と検証基準に寄る。
Grok 4.5 の背景には、「大きな計算資源で大きなモデルを学習した」という話だけでなく、訓練環境づくりそのものの変化があります。
DeepSWE が示している評価軸
Grok 4.5 の文脈では、DeepSWE のようなベンチマークも補助線になります。Datacurve の公式説明によれば、DeepSWE は短いコード生成力ではなく、実務に近いコーディングエージェント評価を目指すベンチマークです。話題のベンチマーク: DeepSWEについても、その特徴を整理しています。
Grok 4.5 と DeepSWE が重なるのは、「一問一答のコード生成」ではなく「リポジトリを読んで作業を進める力」を見ている点です。特に次の観点が近いです。
- プロンプトが冗長で指示的すぎず、エージェントが変更箇所や実装方法を自分で発見する必要がある。
- 複数ステップを積み重ねる Long-Horizon Tasks を含む。
- Datacurve の説明では、既存のコミットや PR 由来ではなく一から作られたタスクで、コンタミネーション対策を意図しているとされている。
- TypeScript、Go、Python、JavaScript、Rust など複数言語を対象にしている。
- mini-swe-agent のような共通ハーネスを使い、ビルダー側の実行環境差を抑えようとしている。
ここで見たいのは、単に「関数を一つ正しく書けるか」ではありません。曖昧な依頼からリポジトリを読み、必要な変更を見つけ、複数ファイルを直し、最後に検証できるかです。DeepSWE は、まさにそのエージェント的能力を測ろうとしています。
そのため、Cursor の Grok 4.5 発表に DeepSWE 1.0（Artificial Analysis）の数値が載っていることには意味があります。Cursor が見ているのは、単発の正答率だけではなく、エージェントとして作業を進める力でもあるからです。
同表では、DeepSWE 1.0 のスコアとして、Grok 4.5 が 62.0%（high）、Opus 4.8 が 55.8%（max）、GPT-5.5 が 64.3%（xhigh）、Composer 2.5 が 18.0%、Fable 5 が 66.1%（max）と示されています。
ただし、この数値だけで Grok 4.5 の優位性を断定するのは危険です。DeepSWE 1.0 では Fable 5 や GPT-5.5 のほうが高く、他のベンチマークでは順位も入れ替わります。
さらに DeepSWE には版の違いがあります。xAI/SpaceXAI 側は DeepSWE 1.0 を provider/native harness、1.1 を Datacurve の mini-swe-agent harness と区別しており、reasoning 設定（high / max / xhigh）によっても比較の意味が変わります。
ここでは「Cursor が DeepSWE を公式比較に入れた」ことを、Grok 4.5 の評価軸を読む手がかりとして見るのがよさそうです。一方で、その1本のスコアだけを全体の結論として扱うのは避けたほうがいいです。
価格・速度・効率も重要な売りになっている
xAI/SpaceXAI 側の発表では速度やトークン効率、低コストが訴求されています。また Axios は、Elon Musk の X 投稿を引用する形で、Grok 4.5 を「Opus-class model, but faster, more token-efficient and lower cost(Opusクラスのモデルですが、より高速で、トークン効率が高く、コストも低くなっています)」と紹介しています。
つまり、売りは最高性能だけではありません。同じような重い作業を、より速く、より安く処理できることも訴求しています。
xAI の Grok 4.5 docs、model detail、Pricingでは、API 価格は以下のように示されています。
- 入力: $2 / 100万 tokens
- cached input: $0.50 / 100万 tokens
- 出力: $6 / 100万 tokens
- Reasoning: low / medium / high
- 対応 API: Responses API, Chat Completions
- Tools: function calling, web search, X search, code execution
ただし、価格を見るときは注意が必要です。
モデル詳細ページでは、Grok 4.5 は 500K context window を持つ一方、200K tokens を超える higher-context では別の単価が設定されています。cached input はキャッシュヒット時の単価であり、docs ではキャッシュを効かせるために prompt_cache_key や x-grok-conv-id の利用が推奨されています。reasoning tokens も token usage として扱われます。
また、xAI の Pricing では、Web Search、X Search、Code Execution などの server-side tools に token usage とは別の invocation cost がかかります。例として Web Search / X Search / Code Execution は $5 / 1k calls とされており、function calling はこれらの server-side tool invocation cost とは別枠で見る必要があります。
一方、Cursor の Grok 4.5 記事では、Cursor 内での価格として、base model が 入力 $2/M・出力 $6/M、fast variant が 入力 $4/M・出力 $18/M と書かれています。これは Cursor のモデル提供・課金体系上の表現なので、xAI API の Pricing と比較するときは条件をそろえる必要があります。
評価で注意すべき点
CursorBench にはデータ混入の注記がある
Cursor の Grok 4.5 記事には、重要な脚注があります。
Grok 4.5 が CursorBench で有利だった理由として、Cursor の codebase の以前の snapshot が誤って学習に含まれていたと説明されています。正確な影響は不明で、今後のモデルではそのデータを除外し、CursorBench も大規模に更新中とされています。
このため、少なくとも CursorBench に関しては、スコアをそのまま汎化性能の証拠として読むべきではありません。
Grok 4.5 の実力を見るなら、CursorBench だけではなく、DeepSWE、SWE-Bench 系、Terminal-Bench、実運用での作業成功率などを分けて見る必要があります。なお Cursor の脚注では、SWE-Bench Pro と Terminal-Bench は third-party models の self-reported scores を示すと説明されています。DeepSWE の版・ハーネスの違いについては前節のとおりです。
EU ではリリース時点で未提供
xAI/SpaceXAI の発表・報道では、Grok 4.5 は Grok Build、Cursor、API console で利用可能とされています。
ただしローンチ時点の EU では、SpaceXAI/xAI の各製品・API console のいずれもまだ利用できないという caveat が付いており、xAI のモデル詳細では availability は later this month（報道では mid-July 見込み）と説明されています。地域ごとの提供状況は変わりうるため、現時点の可否は docs や console で確認するのが安全です。
まとめ
Grok 4.5 を「また賢いモデルが出た」で片づけると、見えにくくなるものがあります。
このリリースは、Grok シリーズの通常アップデートというより、Cursor と SpaceXAI/xAI が「エージェント時代の作業モデル」を作ろうとしている流れの一部です。Composer 系で積んだコーディング特化モデルの経験、Cursor 上の実利用データ、開発者とエージェントの相互作用、強化学習用の難しい環境、SpaceXAI/xAI 側の大規模計算資源。これらが重なって Grok 4.5 が生まれました。
私が注目しているのは、その先です。このモデルは、仕事の任せ方を考え直させます。
Grok 4.5 は 「コードを書くモデル」から「ツールを使って長時間の知識労働を進めるモデル」へ移るためのリリース です。だとすれば、使い手の側も発注の粒度が問われます。一問一答を投げる使い方から、調査・実装・検証まで含む一続きの作業を渡す使い方へ。高いスコアのモデルを選ぶ問題というより、どこまで任せる仕事を自分が用意できるかという設計の問題です。
だから、このリリースはベンチマーク表だけでは測りきれません。どのような作業を任せようとしているのか、どのような訓練環境で作られたのか、どの評価軸で測られているのか。この三つを切り分けて読み、自分の現場のどの仕事をこの作業モデルに預けられるかを考える。そこまで踏み込むと、Grok 4.5 の位置づけが見えてきます。
エンジニアを募集しています！
ここまで読んでいただきありがとうございました！
Algomatic では、「AI革命で人々を幸せにする」をミッションに、変化の速い領域でも 学びや試行錯誤を続けられる エンジニアを募集しています。
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み