CursorにGrok 4.7 500k登場、Fast併用で料金3倍の落とし穴

• Cursorのモデル選択にGrok 4.7 500kが追加され、超長文コンテキストの直接指定が可能になった
• 単価は256k標準比で500k指定時が2倍、Pro既定のFast併用時は3倍（出力$18/1M）へ跳ね上がる
• SpaceXAI直接APIとは異なり手動選択で倍率が変わるため、エフォート調整とFast解除が必須対策となる

深夜のリファクタリング作業中、大規模なモノレポのコードベース全体をコンテキストに読み込ませて一気に処理させようとした経験は誰にでもあるはずだ。AIエディタの進化によって、ファイルツリーの大部分を気兼ねなくプロンプトへ放り込めるようになった現代において、コンテキストウィンドウの拡大はエンジニアにとって麻薬のような魅力を持つ。しかし、今回のCursorにおけるGrok 4.7のアップデートは、その快楽の対価として想定外の請求書を突きつけてくる危険性を孕んでいる。

Grok 4.7においてCursor上で新たに選択可能となった「500k」モデル。これまでGrok 4.6のCursor上でのUIでは256kのみが提供されていたため、「4.7になってコンテキスト窓が倍に広がった」と単純に喜んでそのまま常用してしまうエンジニアが後を絶たないだろう。しかし、料金体系を注意深く確認すると、標準の256kと500kではトークン単価が明確に差別化されている。Grok 4.7 256kが入力$2/キャッシュ$0.50/出力$6（すべて100万トークンあたり）であるのに対し、500kモデルを選択した瞬間、これらはすべて2倍の入力$4/キャッシュ$1/出力$12へと跳ね上がる。

さらに現場で深刻な問題を引き起こすのが、Cursor Pro以上のプランで既定値（デフォルト）として有効化されている「Fast」設定とのバッティングだ。Fast単体でも通常単価の2倍が適用される仕様だが、500kモデルとFastが組み合わさると、料金倍率は3倍に達する。つまり、出力トークン単価は100万トークンあたり$18という極めて高額な水準に達するのだ。日常的なコーディング支援の感覚で、リポジトリ全体のコンテキストを常に含めたままFast+500kで対話を繰り返せば、APIクレジットや従量課金の上限にあっという間にデッドロックを起こすことは火を見るより明らかである。我々エンジニアは、単にモデルの賢さだけでなく、エディタのUI裏で動く課金メーターの回転速度を冷徹に把握しなければならない。

開発現場においてサードパーティツール経由で基盤モデルを叩く際、最も警戒すべきは「プロバイダ側の生API仕様」と「UIツール側の抽象化レイヤー」の間に生じる微妙なズレだ。今回のGrok 4.7を取り巻く環境は、まさにその典型例と言える。SpaceXAIが提供する公式ドキュメントを精読すると、実は基盤モデル側としてはGrok 4.6の時点ですでに500kのコンテキストウィンドウに対応していた。しかし、Cursor側のUIや料金表では4.6は256k枠のみに制限され、今回の4.7のリリースに合わせて初めて「500k」が明示的な選択肢としてプライスリストに登場したという経緯がある。

この両者の差異は、ロングコンテキスト料金が適用されるトリガー条件において極めて顕著に現れている。SpaceXAIの直接APIを利用する場合、リクエストのトークン数が20万トークンを超えた段階でシステムが自動的にロングコンテキスト料金（通常比2倍）へとスケールアップするアーキテクチャを採用している。これに対し、Cursorではユーザーがプルダウン等で「500k」モデルを明示的に選択した段階で、実際のリクエストがわずか数千トークンの小規模な修正であっても、一律で2倍（Fast併用時は3倍）の単価が課される構造になっている点だ。

小規模な関数単位のバグフィックスやテストコードの生成において、モデル選択を500kにしたまま作業を続けることは、近所のコンビニに買い物へ行くために大型トレーラーをチャーターするような完全なリソースの浪費である。API直接利用時の「実トークン数に応じた動的課金」と、Cursor上での「モデル枠の静的選択による課金」の性質の違いを理解していなければ、チーム内の開発費予算は瞬く間に溶けていくことになる。

Grok 4.7におけるもう一つの重大な技術的ファクターが「Reasoning Effort（思考エフォート）」の制御である。エフォートレベルはlow、medium、high、xhighの4段階が用意されており、既定値はhighに設定されている。注目すべきは、Cursor公式ヘルプが指摘している通り、Grok 4.7では4.6時代よりもエフォートレベル間の挙動と推論精度の差がより大きく開いている点だ。エフォートをxhighに引き上げると、モデルカードに示されたCursorBench 4.0のベンチマークスコアはhighの43.9%から46.3%へと確かに向上する。

しかし、エフォートの引き上げはトークン単価そのものは変わらないものの、裏側で生成される推論（思考）トークンの量を劇的に増加させ、結果として出力トークン数を爆発させる。出力単価が標準でも$6、Fastや500kなら$12〜$18に達する環境下で思考トークンを大量に吐き出させれば、1リクエストあたりのコストは掛け算で膨れ上がる。Cursorのコア開発者がフォーラムで「トークンあたりの投資対効果を考えるなら、日常開発ではLowやMediumを積極的に試してほしい」と発信している背景には、推論コストのインフレに対する強い危機感がある。

そして、このGrokの急速な進化と高機能化・高コスト化は、Cursor独自のエージェントモデルである「Composer」の立ち位置に大きな影を落としている。2026年前半の履歴を振り返ると、Composer 1.5（2月）、Composer 2（3月・Kimi K2.5ベース）、Composer 2.5（5月）と極めてハイペースで刷新が続いていたが、7月にSpaceXAIと共同のGrok 4.5が登場して以降、4ヶ月近くComposerのメジャーアップデートが途絶えている。公式は「Composerは日常の速度と安さのために今後も維持し、別ウェイトクラスとして継続する」とアナウンスしている。だが、同じエコシステム内で高コストなGrokと低コストな内製モデルを並行運用し続ける必然性は、ビジネスおよび推論インフラの最適化の観点から見て本当に維持できるのだろうか。

我々エンジニアが明日からの開発現場で取るべき処方箋は明白だ。まず第一に、Cursorの設定を見直し、意図しない「Fastデフォルト」をオフにすること。第二に、普段のコーディングではGrok 4.7 256kのlow〜mediumエフォートを基本とし、巨大なレガシーコードの解析やアーキテクチャ刷新の時のみ500kをピンポイントで投入する運用の規律を設けることだ。開発環境のAIが賢くなるほど、それを使うエンジニア側には「知能の費用対効果」を厳密にプロファイルする冷徹な視線が試されている。