Grok 4.6 を実機で検証する
— ベンチが割れた新モデルに、8つの課題を投げた

2026年8月13日 ／ Routine Labo

SpaceXAI が 2026年8月12日に Grok 4.6 を公開しました。 総合指標では GPT-5.6 Sol と並び、価格は前世代から据え置き。ここまでは各所で報じられている通りです。

ただ、公式ページの同じ表をよく見ると、勝っているベンチと、大きく負けているベンチが混在しています。 今回は、その割れ目を実機で確かめました。動画共有サイトのUIから3Dアクション、正規表現エンジンまで 8つの課題を GPT-5.6 Sol と同じ条件で作らせ、速度・完成度・指示追従を比べています。 あわせて、50万トークンという文脈長の裏にある課金の関門も実測しました。

1. 何が変わったのか

前世代 Grok 4.5 との差は、総合指標で最もはっきり出ます。 Artificial Analysis の Intelligence Index は 56 から 61。1世代で5ポイントの上昇です。 この指標は9つのベンチマークの合成スコアだと公式が説明しています。

使える場所は Cursor と Grok Build、そして API。パートナー経由では OpenRouter・Vercel・Cloudflare に載っています。 文脈長は50万トークン、画像の入力にも対応します。知識のカットオフは 2026年2月1日です。

2. ベンチマークは割れている

ここが今回の中心です。公式が公開している比較表を全部並べると、 単独1位が3つある一方で、大きく負けている項目も2つあります。

単独1位が3つ

GDPVal-AA v2 で 1753、AA-Briefcase で 1577、Harvey LAB で 15.8%。 いずれも他の3モデルを上回っています。とくに Harvey LAB は GPT-5.6 Sol Max の 2.5% に対して 6.3倍という開きがあります。この3つはどれも、コードそのものより 調査・書類・知識労働の側に寄った評価です。

大きく負けているのが2つ

DeepSWE v1.1 は 65.9% で、GPT-5.6 Sol Max の 73% に7ポイント差。 Terminal-Bench v3.0 に至っては 26% で、Sol Max の 34.6% に8.6ポイント差の最下位です。 ターミナルを操作しながら長時間かけて実装を進める種類の仕事では、まだ差をつけられています。

3. なぜ見た目の生成が強くなったのか

公式の説明で目を引いたのは、学習に使った環境の記述です。 領域を指定した強化学習を行っており、挙げられているのは カーネル最適化・Web開発・そして CAD（コンピュータ支援設計）。 CAD が学習環境として名指しされたのは、このシリーズで初めてです。

あわせて開発元は、視覚的・インタラクティブな課題で一発目の完成度が前世代より上がったこと、 長い作業の途中でモデルが自分の出力を検証してから次に進む挙動が見られるようになったことを述べています。

ここから立つ仮説はこうです。見た目とレイアウトの一発生成は強い。では論理の正確さはどうか。 ベンチが割れている理由がここにあるなら、実際に生成させれば同じ割れ方が再現するはずです。

4. 検証のやり方

同じ課題文を Grok 4.6 と GPT-5.6 Sol に同じ条件で渡します（課題1と2は Grok 4.5 も加えて世代差を見ます）。 追加の指示も、エラーの指摘も、再生成もしません。一度の応答で出てきたものだけを比べます。 課題は全部で8つ。見た目とインタラクションを問うものから、論理の正確さを問うものまで揃えました。

5. 課題1 動画共有サイトUI — 見た目とインタラクション

動画共有サイトの画面を、単一の HTML ファイルだけで作らせます。 外部ライブラリも CDN も画像ファイルも禁止。アイコンやサムネイルもコードで描かせます。 見るのは、レイアウトの完成度だけでなく、検索の絞り込みやページ遷移が実際に動くか、 保存した状態が残るかどうかです。

【出力条件・厳守】
1. 出力は「単一のHTMLファイル」を1つだけ。file:// でダブルクリックして即動くこと。ビルド・サーバ不要。
2. コードは省略禁止。「// 以下同様」「...(省略)」は禁止。全文を書ききる。
3. 外部アセット(画像/音声/フォント/モデル)への参照は禁止。必要な素材は Canvas / WebAudio / コードで生成する。
4. 物理・ゲームロジックは固定タイムステップ 1/60秒 で更新し、描画と分離する(可変dtをそのまま積分するのは禁止)。フレーム落ち時はアキュムレータで補正(最大5ステップでクランプ)。
5. 乱数はseed固定のPRNG(xorshift等)。同じ入力列なら必ず同じ結果になる(決定論)。
6. 画面右上に常時HUDを出す: FPS / フレーム時間ms / 現在state / 主要デバッグ値。
7. F1キーで当たり判定(コリジョン形状・法線・接地フラグ)のデバッグ描画をトグルできる。
8. 起動時のコンソールエラーは0件であること。
9. 自動採点用に window.__GAME = { state, player, entities, step(n), reset(seed) } をグローバル公開する。
10. 最後に「仕様チェックリスト」を表で出し、各項目に ✅ / ❌ を自己申告する(嘘の✅は最も減点される)。

【お題】
(ここに各課題を貼る)

【お題】動画共有サイトのUIクローンを作れ。単一のHTMLファイルで、file:// で開いて即動くこと。
外部ライブラリ・CDN・画像ファイルは一切禁止（サムネイルやアイコンは Canvas / SVG / CSS でコード生成する）。
※実在サービスのロゴ・商標・実在の動画やチャンネル名は使わないこと。サービス名・ロゴはオリジナルにする。UIの構造とインタラクションを再現するのが目的。

必須仕様:
- ヘッダー: ハンバーガー、ロゴ、中央に検索バー（サジェスト表示つき・実際に絞り込みが動作する）、右にアップロード/通知/アカウントのアイコン（SVGで描画）。
- 左サイドバー: ホーム / 登録チャンネル / 履歴 / 再生リスト / 後で見る / 高評価。折りたたんでミニサイドバー化できること。
- ホーム: カテゴリチップ（すべて・ゲーム・音楽・AI・ニュース…）で絞り込み。動画カードのグリッド（画面幅に応じて1〜4列）。カードはサムネ・尺バッジ・タイトル・チャンネル名・再生数・投稿日を持ち、ホバーでサムネがプレビュー再生風にアニメする。
- 視聴ページ: カードのクリックでビューを切り替える（SPA的に遷移）。
  - プレイヤー: 実動画は使えないので Canvas で描いたアニメーションによる擬似再生にする。再生/一時停止、シークバー（ドラッグ可）、音量、再生速度、ミニプレイヤー、全画面、経過時間/総時間を実装。
  - タイトル、再生数、日付、高評価/低評価（押すとカウントが動く）、共有、保存。
  - チャンネル行（アイコン・名前・登録者数・チャンネル登録ボタン＝トグル）。
  - 概要欄（「もっと見る」で展開）。
  - コメント欄（並び替え、実際に投稿して追加できる、いいね、返信の折りたたみ）。
  - 右カラムに関連動画リスト。
- 検索結果ページ（絞り込み結果の一覧）。
- ダークモード/ライトモードの切替（localStorage に保存）。
- コード内に30本ぶんのダミー動画データ（すべて架空のオリジナルタイトル）を持つ。
- 履歴・登録チャンネル・後で見るは localStorage に保存され、実際に機能すること。
- レスポンシブ（スマホ幅では1列＋サイドバー非表示）。

6. 課題2 正規表現エンジン — 論理の正確さ

正規表現エンジンを一から自作させます。言語に組み込みの正規表現機能は、実装にもテストにも使用禁止。 20問の固定テストを起動時に自動実行させ、合否を赤と緑の表で出させます。

最大の差がつくのは最後の項目です。極端に処理が重くなるパターンを投げたとき、 素朴な実装は固まり、効率的な方式で書けていれば一瞬で終わります。 見た目ではなく、計算量まで理解して設計できているかが問われます。

【出力条件・厳守】
1. 出力は「単一のHTMLファイル」を1つだけ。file:// で開いて即動くこと。
2. コードは省略禁止。「// 以下同様」「...(省略)」は禁止。全文を書ききる。
3. 外部ライブラリ・CDN禁止。★JavaScriptのネイティブ正規表現（RegExpリテラル・new RegExp・
   String.prototype.match/replace/split/search の正規表現利用）は実装・テスト双方で使用禁止★。
   ソース中に正規表現リテラルが1つでもあれば失格。
4. 起動時のコンソールエラーは0件であること。
5. 最後に「仕様チェックリスト」を表で出し、各項目に ✅ / ❌ を自己申告する(嘘の✅は最も減点される)。

【お題】正規表現エンジンをゼロから自作せよ。パーサ＋実行器を書き、下記の固定テストを起動時に
自動実行して赤/緑の表で結果を出す。強いエンジンの条件は「正しさ」と「病的パターンで凍らないこと」。

対応構文: リテラル / . / * / + / ? / 選択 | / グループ() / 文字クラス[abc] [a-z] [^…] /
アンカー ^ $ / エスケープ \d \w \s \. \\ 。マッチ関数は test(pattern, text) → true/false。

起動時に自動実行する固定テスト（この期待値どおりか赤/緑表示。1問でも改変したら失格）:
 1. test("abc","abc")=true            2. test("a*b","aaab")=true
 3. test("a*b","b")=true              4. test("a+b","b")=false
 5. test("a?b","ab")=true             6. test("^ab$","ab")=true
 7. test("^ab$","xab")=false          8. test("a|b","b")=true
 9. test("(ab)+","abab")=true        10. test("[a-c]x","bx")=true
11. test("[^a-c]x","bx")=false       12. test("\\d+","a12b")=true
13. test("^\\d+$","12a")=false       14. test("a.c","abc")=true
15. test("a.c","ac")=false           16. test("(a|b)*c","ababc")=true
17. test("x(y|z)?w","xw")=true       18. test("\\w+\\s\\w+","ab cd")=true
19. test("(a*)*b","aaab")=true       20. test("[.]","a")=false

病的パターン耐性（最重要の差分ポイント）:
- 「病的テスト実行」ボタンを置く（自動実行はしない）。押すと test("(a+)+b", "a"×28+"c") を実行。
- 素朴なバックトラック実装はここで数十秒〜永久に凍る。Thompson NFA / Pike VM など多項式時間の
  方式なら一瞬で false が返る。実行前に performance.now() を取り、完了したら経過msを表示。
- ボタン押下時に setTimeout で3秒後の生存確認を仕込み、3秒以内に完了しなければ
  「エンジンが凍りました」を表示できるようにする（凍った場合は表示されないこと自体が証拠になる）。
- 対話UI: パターンとテキストを入力して試せる欄も付ける。
- 採点用API: window.__RE__ = { test(p,t), results:[{no,pass}], pathologicalMs } をグローバル公開。

7. 全9課題の結果

上の2つを含めて、全部で9つの課題を同じ条件で投げました。結果を速い順に並べます。

9戦して7勝2敗。生成の完走率はどちらも9/9で互角でした。 最も差が開いた課題1では2.41倍ですが、合計では1.48倍です。 JRPGとミニ表計算では Sol の方が速く、全勝ではありません。 2Dアクションはほぼ互角の1.05倍で、生成物が小さくなるほど差は縮みます。

品質の方は逆の傾向が出ました。そのまま動いたのは Grok 4.6 が7つ、Sol が8つ。 Grok 4.6 は課題5と課題6で、要求されている仕様チェックリストを出していません。 申告と実態の食い違いは両者に1件ずつありました。 速さは Grok 4.6、そのまま動く率と指示の細部を守る律儀さは Sol という結果です。

そのまま動いたのは、9つ中いくつか

生成が最後まで終わることと、開いて実際に動くことは別です。 全9課題を実際にブラウザで開き、画面のピクセルを数えて判定しました。

差は1つだけで、しかもどちらも落ちています。 そして落ちた原因を調べると、3件とも設計の失敗ではなく単純なタイプミスでした。

3件とも、直したら全部動きました。 設計はできているのに、1〜2文字で全体が止まる。これが今回いちばんはっきり出た事実です。

1文字で全部が止まった話

今回いちばん印象に残ったのは、課題9の2Dアクションです。 Grok 4.6 が出したファイルは、開いても何も動きませんでした。 原因はスクリプト1042行目にあった、余分な閉じ括弧が1つ。

if (game.stageIndex === 2) shade = ((x + y) & 1) ? "#4e342e" : "#3e2723");

たった1文字ですが、これで約4万字のスクリプト全体が解析できなくなり、 ゲームは起動すらしません。それにもかかわらず、モデルが最後に出した自己申告の表は 19項目すべてに ✅ がついていました。 起動時のエラーは0件、という項目にもです。

そしてこの1文字を消すだけで、完全に動きます。 設計の中身はむしろ厚く、実装量も相手より多い。 設計では勝っていたのに、タイポ1つで出荷できない状態になっていたわけです。 生成されたコードをそのまま信じない、という原則がよく分かる例でした。

8. 50万トークンの裏にある関門

ここは料金の話です。文脈長は50万トークンと発表されていますが、 料金はその全域で一定ではありません。

公式ドキュメントには、しきい値に達したリクエストは the higher rate for all tokens in the request で課金される、と書かれています。 つまり 20万トークンを超えた分だけが高くなるのではなく、そのリクエストの全トークンが倍額になります。

入力と出力の単価そのものは前世代 4.5 から据え置きです。ただし キャッシュ読み出しは 4.5 の $0.30 から $0.50 に上がっています。 長い前提を毎回投げてキャッシュで安く済ませる使い方は、前世代より不利になりました。

これは仕様書の記述だけではなく、API が返すデータにも入っています。 OpenRouter のモデル一覧を叩くと、価格の中に overrides という配列があり、 min_prompt_tokens: 200000 から単価が切り替わることが機械可読な形で書かれています。

curl -s "https://openrouter.ai/api/v1/models" | python3 -c "
import json,sys
for m in json.load(sys.stdin)['data']:
    if m['id'] in ('x-ai/grok-4.6','x-ai/grok-4.5'):
        print(m['id'], json.dumps(m['pricing'], ensure_ascii=False, indent=2))
"

x-ai/grok-4.6 {
  "prompt": "0.000002",
  "completion": "0.000006",
  "input_cache_read": "0.0000005",
  "overrides": [
    {
      "min_prompt_tokens": 200000,
      "prompt": "0.000004",
      "completion": "0.000012",
      "input_cache_read": "0.000001"
    }
  ]
}

回避策

1. 20万トークンの手前で会話を畳む。長い履歴はいったん要約してから渡す。
2. キャッシュを効かせる。ただし前世代よりキャッシュ単価が上がっている点は勘定に入れる。
3. 20万トークン超が常態になる用途なら、最初から別のモデルを検討する。

9. 結論 — 順位ではなく用途で選ぶ

ベンチマークが割れているというのは、優劣がついていないという意味ではありません。 どの仕事に向くかがモデルごとに分かれてきたという意味です。 順位表の1位を選ぶのではなく、自分の仕事の種類で選ぶ段階に入っています。