コーディングAI最安モデルに月額$300の壁——Grok Buildの採算

xAIが投入したコーディングAI「Grok Build」

2026年5月14日、xAIは「プロフェッショナルなソフトウェアエンジニアリングと複雑なコーディング作業」に向けたエージェント型コーディングCLI、Grok Buildを早期ベータとして公開しました。利用できるのはSuperGrok Heavy契約者（月額約$299）に限られ、対象アカウントなら次の1行でインストールできます。

curl -fsSL https://x.ai/cli | bash

機能構成は、2026年のコーディングエージェントとして想像どおりです。対話型TUIに加え、スクリプトやCIで使うヘッドレスモード、独自ツールへ処理ループを組み込むためのAgent APIを備えます。設計上の見どころは並列実行で、1セッションにつき最大8つのサブエージェントを動かし、それぞれを別のgit worktreeブランチで実行できます。

ただし、まだGAではありません。xAIはGrok Buildを早期ベータと明記し、フィードバックを収集中です。公式ローンチ投稿の位置づけも製品の正式リリースではなく、開発者向けプレビューです。その前提で見るべきでしょう。

最安モデルと最も高い入口、その矛盾

基盤モデルそのものは確かに安価です。grok-code-fast-1のAPI料金は、入力100万トークンあたり$0.20、出力100万トークンあたり$1.50、キャッシュ済み入力100万トークンあたり$0.02です。現在提供されている実用水準のコーディングモデルでは、入力単価が最も低いモデルです。キャッシュヒット時の価格設定もかなり攻めており、リポジトリ規模のワークフローなら収支を実際に変える水準です。

性能はベンチマークでも裏づけられています。xAIの社内ハーネスを使ったSWE-Bench Verifiedは70.8%。現行勢と競える一方、トップではありません。それでも本番運用で重要なのは、実用に耐える確かな性能があることです。

問題はパッケージの設計です。モデルはAPI従量課金なのに、エージェントは違います。早期ベータ中のGrok Buildを使うには、月額一律$300のSuperGrok Heavyが必要です。エージェントの処理ループをトークン単位では買えず、契約枠ごと購入することになります。

安いモデルでも、高額な定額プランの奥に置かれれば、採算が合うのは大半の個人運用者が届かない利用量を超えてからです。料金を考えるうえでの核心は、ここにあります。

運用者目線の結論——サブスクかAPI従量課金か

私はClaude Max上で本番環境の公開ルーチンを6本運用し、Codexへ移行する採算もすでに2回計算しました。Grok Buildは、新しいおもちゃとして試す対象ではありません。すでに2つのコーディングエージェントを抱える損益計算書へ、3つ目の費目を載せるかどうかの判断です。

Claude Code on MaxやCodexのような従量型スタックでは、限界費用がトークン量に応じて動きます。ルーチンを絞り、セッションに上限を設け、暴走したループを止められます。コストの増え方が読みやすいのです。

月額一律$300のプランは、コーディングエージェントの月間利用量を従量課金に換算して$300を超えるまで固定費の重荷です。その境界は、多くの個人運用者が考えるより高いところにあります。私の場合、既存のClaude Max契約でルーチンをすでに賄えています。Codexも損益上は移行寸前でしたが、計算する価値はあっても乗り換えるほどではありませんでした。3つ目の定額契約をその上に積む余地はなく、既存のどれかを置き換えられなければなりません。

判断基準は明快です。私がGrok Buildを採用するのは、(a) xAIがエージェントのAPI従量課金版を提供するか、(b) Arena Modeが正式に使えるようになり、代表的な評価で現在の合格率を明確に上回ったときです。それまでは採用しません。

モデルを疑っているわけではありません。入口にいくら払うかという、純粋な算数の問題です。

Grok Buildの料金をトークン単価で計算する

損益分岐点の問題として考えます。入力が$0.20/1M、出力が$1.50/1Mなら、月額$300の定額サブスクリプションがAPI従量課金より安くなるまでに、Grok Buildで何トークン処理する必要があるでしょうか。

個人開発者が毎日ヘビーに使うという大まかな想定でも、入力だけで損益分岐点を超えるケースはほとんどありません。出力の多いリファクタリングなら差は縮まりますが、すでに埋没費用となっているMax契約を上回るほどではありません。定額プランをコスト項目に加えるだけの価値を出すには、複数の開発者が継続的に使うか、8サブエージェントの並列性を積極的に広げるワークフローが必要です。

ただし、注意点が2つあります。

$0.02/1Mというキャッシュ済み入力の単価は、異例の安さです。同じリポジトリ、同じファイル、ツールの反復呼び出しなど、キャッシュ局所性の高いワークフローでは実効入力コストが1桁下がるため、従量課金APIに対して定額プランが価格で勝つのは難しくなります。

一方、8サブエージェントへの展開は逆に働きます。本来は小さく収まるワークフローでも、並列サブエージェントによってトークン消費が増え、最悪の場合は8×になります。この展開に対して定額プランが割安に見えるのは、支出に上限があるからです。同じ処理をAPIで自己管理すると上限はありません。xAIがアクセスを限定した理由として、これは筋が通っています。完全な並列展開で生じうる最悪のAPI請求額は実際に恐ろしく、その変動をサブスクリプション料金が吸収するからです。

どちらも、従量課金版を待って実環境で評価してから契約すべき理由です。うまくいくだろうと見込んで今すぐ契約する理由にはなりません。

今週やるべきこと

何も解約する必要はありません。現在使っている従量型スタックで問題ありません。

チームに使っていないSuperGrok Heavyの契約枠がすでにあるなら——実際にそういうチームもあります——重要度の低いルーチンを1つ選び、grok-code-fast-1と現在のモデルでA/Bテストしてください。追加費用なしで、実データを得られます。

実際のコードベースにある評価タスクを1つ選び、APIからモデルを呼び出すのも有効です。入力単価が$0.20/1Mなので、意味のある評価でも費用は数セントです。ローンチ投稿だけで判断せず、自分のリポジトリで70.8%の感触を確かめてください。ベンチマークは出発点であり、意思決定そのものではありません。

今週やることは、これだけです。問うべきは3つ目のサブスクリプション費用を追加するかどうかで、率直な答えはこうです。入口が変わるか、モデルが契約枠に見合う価値を証明するまでは追加しません。

今後30日で注視するポイント

追っているシグナルは3つです。

API従量課金のGrok Build。 基盤モデルだけでなくエージェント自体をトークン単位で購入できるようになった瞬間、利用量の少ない運用者にとって採算は逆転します。多くのスタックへ採用されるために必要な変更は、これに尽きます。

Arena Modeの正式提供。 複数のエージェントに同じタスクを競わせ、開発者へ結果を返す前に順位づけする機能を、xAIは予告しています。合格率の向上が本物なら、価格とは切り離された性能上の根拠になり、計算は変わります。

xAIがSuperGrok Heavy限定を続けるのか、開発者向けプランを出すのか。 大半の運用スタックに入らない原因は、この制限だけです。月額$20–50の開発者向けプランが登場すれば、この記事の結論は全面的に変わります。

この3つのどれかが実現するまでは、Grok Buildは実力がありながら料金の入口を間違えた新顔です。モデルは安い。エージェントは安くない。結論はそれだけです。