突然の Grok Imagine レート制限縮小、SuperGrok Heavy + Grok Build でどこまでできるのか試してみた
2026年5月、Grok Imagine の動画生成制限が突然激減し、SuperGrok 加入者ですら 1 日 20 件前後に絞られた。クォータを計画的に使う方法、代替サービスへの移行、xAI API 直接利用まで制限を回避する実践的な方法と、いつ元に戻るのかの見通しを探る。また Grok Build の 11 スキルとスラッシュコマンド体系も詳解する。
「なんか動画が 20 件しか生成できない」
5 月に入ったあたりから、X や Reddit に奇妙な報告が増えてきた。
「SuperGrok 月 30 ドル払っているのに、動画が 1 日 20 件でロックされる」「昨日まで普通に使えていたのに突然制限が来た」「フリーユーザーは完全に壁にぶつかる」――怒りの投稿が次々と並ぶ。
確かに数字は厳しい。以前は 1 日あたり数十件以上が当たり前だった動画生成が、実質 80% 以上削減されたという。月額を払っているユーザーほど裏切られた感が強い。
気になって調べていくと、Grok の X アカウントから「新しいサービスのリリースによりリソースが逼迫している」という返信を見つけた。ただし、このアカウントは AI による自動ポストで公式声明ではない。だとすれば「新しいサービス」とは何なのか。それを追いかけていくと、最近ひっそりとベータが始まった Grok Build にたどり着いた。
まず、制限の実態を整理する
怒りの声は感情的なものもあるので、実際の数字を冷静に確認しておこう。
2026 年 5 月時点で報告されているレート制限は以下のとおりだ（公式発表ではなく、サポートメールやユーザー報告のまとめ）。
| プラン | 月額 | 動画生成の制限（報告ベース） |
|---|---|---|
| Free | $0 | 実質ゼロ（完全ペイウォール化） |
| X Premium+ | $8〜 | 動画なし、基本的な画像生成のみ |
| SuperGrok | $30 | 24 時間あたり 20 件程度 |
| SuperGrok Heavy | $300（割引: $99） | 12 時間あたり 80 件程度 |
特に注目すべき点が 2 つある。
① フリーティアが事実上廃止された。 以前は無料でも毎日一定数の画像・動画生成が可能だった。今や新規アカウントもシークレットブラウザも関係なく、即座に「SuperGrok にアップグレードしてください」という壁に当たる。
② 上位の Heavy ユーザーも例外ではない。 あるユーザーの報告では、1 日あたりの動画生成が 500 件から 160 件に削減された。4 月のサポートメールでは「100 件以上」と案内されていたのに、5 月には下方修正されていた。
さらに見落としがちな落とし穴がある。コンテンツモデレーションによる失敗や生成エラーでもクォータが消費される。プロンプトが弾かれて動画が出てこなくても、1 件カウントとして引かれる。また制限を超えると、720p だった動画が自動的に 480p に品質ダウンする。
「公式見解」がない問題
xAI はこの件について、公式プレスリリースも CEO のコメントも出していない。
情報源として流通しているのは Grok の X アカウントからの返信だけだ。内容は「動画クォータのグリッチ（不具合）について申し訳ない」「新しいサービスのリリースによりリソースが一時的に逼迫している、調整中」というもの。
ここに大きな問題がある。このアカウントは AI が自動ポストしているものだ。公式声明と同等の信頼性はない。
ユーザーコミュニティはすでにこの矛盾に気づいている。「グリッチと言っているが、フリーティアの廃止・段階的な制限削減・Heavy プランへの誘導という一貫したパターンが続いている。意図的なポリシー変更ではないか」という見方が多数を占める。真偽は分からない。ただ、月に数十ドルを払っているユーザーが AI の自動投稿だけを頼りに状況を把握しなければならないのは、サービスとして問題がある。
「新しいサービス」の正体、Grok Build を試す
「新しいサービスのリリースによるリソース逼迫」という説明を頼りに調べると、Grok Build というサービスがベータを開始していることがわかった。SuperGrok Heavy 加入者向けに静かにリリースされ、Elon Musk が 5 月 14 日前後に X でテスター募集を呼びかけたことで知られるようになった。
Grok Build の一言定義は「ターミナルで動く AI コーディングエージェント」だ。Claude Code や Cursor に近い立ち位置だが、Grok のインフラを使っている点が違う。
スペックはなかなか強烈だ：
- 8 つの並行 AI エージェントを同時稼働：タスクを分割して複数エージェントが同時進行
- 200 万トークンのコンテキストウィンドウ：大規模なコードベース全体を保持したまま作業可能
- 基盤モデル: Grok 4.3 beta（16 エージェント対応の Heavy アーキテクチャ）
- ファイルを実際に作成・編集し、シェルコマンドを実行：質問に答えるだけでなく「動く」
コード補完ツールではなく、タスクを渡せば完結まで動く「ジュニアエンジニア」だ。これだけの並列処理とコンテキストを動かせば、確かにサーバー負荷は膨大になる。動画生成との競合でリソースが絞られるというのは、技術的には筋が通っている。
Grok Build でできること
Grok Build はスキル（skills）による機能拡張にも対応している。デフォルト 7 つのスキルに加え、開発ワークフロー向けのバンドルスキルが 4 つ同梱されており、合計 11 の自動化モジュールが最初から使える。
/help ― 設定・MCP サーバー・コマンドを即答
Grok 自身の設定（config.toml）や MCP サーバーの追加方法、認証、キーボードショートカット、スラッシュコマンドの使い方を参照できる。設定ファイルの読み込みや直接編集まで対応しており、「設定の仕方がわからない」という場面で自律的に解決してくれる。
/create-skill ― 独自ワークフローを対話的に自動化
繰り返し実行するタスクをスキルとして登録できる。「このコマンドを毎回手動で叩くのが面倒」という作業を自然言語で説明するだけで、スキルファイルを生成・保存してくれる。プロジェクト単位でもユーザー全体でも管理でき、チームと共有することも可能だ。
/check ― 完成後にサブエージェントが検証
作業が終わったとき、/check を実行すると独立した検証用サブエージェントが起動し、実装の正しさを確認する。チェック内容はコードのビルド・テスト実行・ロジックの評価・未実装の洗い出しまでカバーしており、最終的に「PASS」か「FAIL」の判定が返ってくる。レビュアー不在でも一定の品質保証を得られる。
/best-of-n ― 複数の実装を並行で走らせ、最良を選ぶ
/best-of-n 3 ログイン画面を実装して のように入力すると、3 つのサブエージェントが同時並行で別々のアプローチを実装し、正確性・コード品質・安全性の軸で自動評価した上で「勝者」の実装を採用する。同一タスクを N 通りのやり方で試してベストを選ぶ発想は、コード生成 AI の中でもあまり見ない機能だ。
/xlsx ― Excel ファイルを丸ごと生成・編集
Excel スプレッドシートの作成・編集・データ分析をすべてコードで処理する。pandas によるデータ解析、openpyxl によるフォーマット・数式の書き込み、LibreOffice を使った数式の再計算まで対応。財務モデルの色分けルール（青＝入力値、黒＝数式、緑＝他シート参照）も内包されており、会計的に正確なスプレッドシートを自動生成できる。
/pptx ― PowerPoint スライドをゼロから設計
プレゼン資料の生成に特化したスキルだ。markitdown によるテキスト抽出、pptxgenjs による新規作成、LibreOffice を使った PDF 変換と画像スナップショットによる品質確認まで一貫して処理できる。「無味乾燥なスライドにするな」という指示が SKILL.md に明記されており、配色・レイアウト・フォントのガイドラインが内包されている。
/docx ― Word 文書の作成・編集・トラッキング
Word 文書の新規作成はもちろん、既存ファイルの XML を直接編集する「アンパック → 編集 → リパック」のワークフローも対応。変更履歴（トラッキング）の挿入・コメント追記・画像挿入なども自動化できる。
デフォルト 7 スキルが「何でも屋」だとすると、バンドルスキル 4 つはエンジニアの開発フローに特化した自動化を担う。
/design ― 設計書を書く→レビューするループを自動化
/design <機能の説明> と入力すると、設計ドキュメントライター（サブエージェント）と設計レビュアー（別サブエージェント）が交互に起動し、未解決の指摘がゼロになるまで「書く→レビュー→修正」を繰り返す。最終的に設計書本体と具体的な PR プランが出力される。アーキテクチャの意思決定を記録した「Key Decisions」セクションも自動生成される。
/implement ― 実装→レビュー→修正ループを並列レビュアーで回す
タスクを渡すと実装エージェントが動き、完了後に最大 6 人の並列レビュアーが独立してコードを検証する。過去の指摘をメモリに蓄積して「同じミスを繰り返さない」学習機能付き。--effort N（1〜6）でレビュアー数を調整できる。単なる生成ではなく「実装してレビューを通過するまで繰り返す」という完結型の動きをする。
/review ― ローカル差分・ブランチ・GitHub PR を一括レビュー
/review --local（ローカル差分）、/review --branch（ブランチ全体）、/review --pr（GitHub PR）の 3 モードで動作する。レビュー結果は GitHub に「PENDING レビュー」として投稿され、人間が承認するまで保留される。Graphite によるスタック PR にも対応している。
/pr-babysit ― PR を継続監視、CI 失敗を自動修正
/pr-babysit add で監視対象の PR を登録すると、CI の状態を追い続け、テストが落ちたら自動でコードを修正してプッシュし、マージコンフリクトも解消する。/loop 5m /pr-babysit check と組み合わせると 5 分ごとに自動チェックが走る設計になっており、「マージされるまで人間がいなくてもいい」状態を目指している。
この 11 スキルから浮かんでくるのは、Grok Build が「コーディングエージェント」にとどまらず、設計・実装・レビュー・マージまでの開発フロー全体と、あらゆる知識労働の自動化基盤を目指しているという姿勢だ。コードを書くだけでなく、コードで作った成果物を検証し、設計書とスライドにまとめ、取引先への Word 報告書に仕上げるところまで、一続きのフローで完結させようとしている。
スラッシュコマンド一覧
Grok Build はターミナル上のインタラクティブ TUI（テキストUI）として動く。操作の基本は / で始まるスラッシュコマンドだ。スキルも /design のようにスラッシュコマンドとして呼び出す。
コマンドの種類はセッション管理・モデル切り替え・メモリ操作・メディア生成など幅広い。主なコマンドをまとめる。
| コマンド | 説明 |
|---|---|
/new / /clear | セッションをリセット |
/load [ID] | 過去のセッションを読み込む |
/compact | 会話履歴を圧縮してコンテキストを節約 |
/context | コンテキスト使用量とセッション統計を表示 |
/session-info | モデル・ターン数・使用量など詳細を表示 |
/model <name> | モデルを切り替える（例: grok-build） |
/always-approve / /yolo | 権限確認をスキップして全ツール自動実行 |
/multiline | Enter での改行入力モードに切り替え |
/plan | プランモードに入る |
/loop [間隔] <プロンプト> | 定期実行タスクを設定（最小 60 秒、例: 5m） |
/imagine <説明> | テキストから画像を生成（t2i） |
/imagine-video <説明> | テキストから動画を生成（t2v） |
/flush | セッション知識をメモリに即時保存 |
/dream | メモリを統合・整理（メモリ機能有効時） |
/hooks | フック管理モーダルを開く |
/plugins | プラグイン管理モーダルを開く |
/share | セッションをシェアして URL を生成 |
/rename | 現在のセッションに名前をつける |
/theme | TUI のカラーテーマを変更 |
/feedback | バグ報告・フィードバックを送信 |
/btw | 現在タスクを中断せず一言追記 |
/mcps | MCP サーバー管理モーダルを開く |
/terminal-setup | ターミナルの機能検出・設定情報を表示 |
/imagine と /imagine-video でメディア生成も Grok Build から可能
Grok Build の操作中に /imagine <説明> と入力すると、そのまま Grok のテキスト→画像生成（t2i）を呼び出せる。/imagine-video <説明> ならテキスト→動画生成（t2v）だ。コーディング作業の途中で「このフロー図を画像で出して」と指示するような使い方が想定される。
一方、画像から動画を生成する i2v（image-to-video）のコマンドは現時点では存在しない。i2v が必要なら Grok Build 外の Grok Imagine ウェブ UI から操作する必要がある。
なお、/imagine と /imagine-video は Grok Imagine の独立したクォータを消費する。Grok Build の Heavy クォータとは別に管理されている点に注意したい。
実際に /imagine で生成した画像がこちらだ（3枚同時生成）。
実際に試した感触では、/imagine の画像生成はウェブ版 Grok Imagine の高クオリティモードには及ばず、古いモデルが使われているように見える。動画生成（t2v）については、i2v が使えないため参照画像を起点にできず、クオリティ面でもウェブ版より一段落ちる印象だ。利用価値がないわけではないが、メディア生成の本格活用は今後のモデル更新に期待したいところだ。
一方でコーディングエージェントとしての Grok Build は自由度が高く、他のエージェントでは難しい用途に使える可能性を感じた。スキルで動作を細かく定義できる点や、スラッシュコマンドから MCP サーバー管理・定期実行・メモリ統合まで一体で扱える点は独自の強みだ。
-p フラグでスクリプト組み込みも可能
TUI を起動せずにコマンドラインから直接プロンプトを渡せる -p フラグにも対応している。
grok -p "こんにちは"シェルスクリプトへの組み込みやパイプ処理との連携が可能になり、「ファイルを読んでサマリを出す」「コミットメッセージを自動生成する」といったワンライナー的な使い方も実現できる。
この点で比較として重要なのが Claude Code の動向だ。Anthropic は claude -p による非インタラクティブ実行がクレジットを消費するようになると発表している。Grok Build は SuperGrok Heavy の月額に含まれる形での利用となるため、-p フラグを使った自動化スクリプトを多用しても追加課金は発生しない。スクリプトへの組み込みや CI/CD パイプラインへの統合を検討している開発者にとって、コスト面での差が出てくる部分だ。
制限を回避する方法
どう対応するかを考える前に、クォータがどう管理されているかを把握しておく必要がある。実際に試した範囲では、Grok のサービスはクォータを以下のように独立して管理している：
- テキストチャット（Grok 4 / Deep Search / Big Brain）：通常のトークン消費
- Grok Imagine（画像・動画生成）：専用クレジット制（動画は API 換算で 1 秒あたり 0.05 ドル）
- Grok Imagine Agent：Grok Imagine とはさらに独立したカウント
- Grok Build（コーディング CLI）：Heavy プラン専用の別クォータ
それぞれが「独立した財布」を持っており、チャットを使いすぎても Imagine のクォータには影響しない。逆に言えば、Imagine のクォータが切れてもチャットや Build は動き続ける。制限を感じているのが「動画だけ」なら、他の機能には手をつけていないクォータがある。
クォータを計画的に使う
最も即効性があるのは使い方の最適化だ。
- リセットタイミングを把握する：SuperGrok の動画クォータは「24 時間サイクル」で管理されている。最後に動画を生成した時刻から 24 時間後にリセットされる仕組みだ。一気に使い切るより、時間を分散させて使うとロックに当たりにくい。
- モデレーション失敗を減らす：プロンプトが弾かれた場合でもクォータが消費される。人物の顔・著名人・暴力・著作権のある要素などを含まないプロンプトを心がけることで、無駄消費を減らせる。
- 品質を絞る：720p 生成は 480p よりクォータを多く消費するとの報告がある（公式確認なし）。大量生成より高品質な数件に絞る使い方が現実的だ。
代替サービスを使い分ける
動画生成がメインの用途なら、他サービスとの使い分けも選択肢だ。
| サービス | 月額 | 特徴 |
|---|---|---|
| PixVerse | $5〜 | 動画生成専門、クォータ多め |
| Runway Gen-4 | $12〜 | 高品質・映像制作向け |
| Kling AI | $8〜 | 長尺動画、リアル系 |
| Sora（OpenAI） | ChatGPT Plus 経由 | 自然な動き |
SuperGrok の $30 を動画だけに使うなら、専門サービスとのコスト比較は必須だ。
X アカウントを分散させる
Imagine の生成枠を増やすことだけが目的なら、X の有料プランに複数アカウントで加入してクォータを分散させるという手もある。Heavy プランへの一本化よりも、複数の X プレミアムプランアカウントを使い分ける方がコスト効率が良い場合がある。Grok Build や高度な推論機能が不要で、メディア生成だけを増やしたい用途には現実的な選択肢だ。ただし X の利用規約との兼ね合いや、アカウント管理の手間は別途考慮が必要になる。
xAI API を直接利用する（上級者向け）
Grok の画像・動画生成は API 経由でも呼び出せる。動画生成は API 換算で 1 秒あたり $0.05 程度。月に数百件を生成するクリエイターにとっては、定額のサブスクより従量課金の方が割安になるケースがある。ただし設定コストがかかり、開発者向けの選択肢だ。
いつ元に戻るのか
ここが最も読者の知りたいところだが、正直に言って見通しは立っていない。
根拠を整理する：
- xAI が「一時的」と言い続けているが改善していない：Grok X アカウントは「リソースが逼迫しているが調整中」と繰り返している。しかしこの説明は 4 月から続いており、その間に制限は改善されるどころか悪化した。
- フリーティアは戻らない可能性が高い：段階的なペイウォール化の流れを見ると、フリーユーザーへの動画生成提供を再開するインセンティブが xAI 側にない。
- SuperGrok の制限緩和は Grok Build 次第：「Grok Build のリリースがリソース逼迫の原因」という見方が正しいなら、Build が安定して効率化されるにつれ Imagine の制限も緩和されるかもしれない。しかし Build はベータ段階であり、タイムラインは不明だ。
- 公式アナウンスがない：xAI が公式に声明を出さない限り、外部から予測することは難しい。
現実的な見立ては「フリーティアの復活は期待薄、SuperGrok の制限は現状維持か若干緩和、Heavy の優遇は継続」といったところだ。
プランの現実と損得勘定
SuperGrok（月額 30 ドル）
動画生成・音声モードの制限が厳しくなっているが、テキストチャット（Grok 4、DeepSearch、Big Brain reasoning）は変わらず使える。
向いているユーザー：チャット中心の利用、コーディング補助として週数回使う程度、画像生成を週数件しか使わない場合。
不向きなユーザー：動画を毎日何十件も生成したいクリエイター、長時間のボイスモード利用、Grok Build も使いたい開発者。
コストパフォーマンスを試算すると、1 日 20 件 × 30 日 = 600 件として月額 30 ドル、1 件あたり約 5 円になる。ただしモデレーション失敗分も消費されるため、有効生成率を 80% とすると実質 6〜7 円 / 件になる。
SuperGrok Heavy（月額 300 ドル、初期割引 99 ドル / 月）
現在唯一、Grok Build にアクセスできるプランだ。動画生成の制限も SuperGrok より大幅に緩い。Grok 4 Heavy（並行推論エージェント付き）、256K トークンのコンテキストウィンドウ、最優先アクセスが付く。
Grok Build を評価したい開発者へ：導入割引（6 ヶ月間 99 ドル / 月）は試す価値がある。ただし Grok Build はまだベータであり、Claude Code や Cursor との本格的な比較評価はこれからだ。割引期間中に評価を完了できるかどうかが判断の基準になる。
動画生成クリエイターへ：Heavy でも 1 日 80〜160 件程度が実態で、SuperGrok との差は体感で 2〜3 倍程度にとどまる。「大幅に緩い」とは言いがたく、Imagine に特化した用途なら割引期間中（$99 / 月）はまだ許容範囲だが、正規の $300 / 月を動画だけに使うなら PixVerse や Runway など専門サービスとの比較が先決だ。
まとめ：今すぐできることと長期的な見通し
今すぐできること
- クォータのリセットタイミングを把握して計画的に使う
- モデレーションが通りやすいプロンプトに切り替えてクォータ無駄消費を減らす
- 動画生成メインなら PixVerse・Runway などの専門サービスとの使い分けを検討する
- Grok Build にも興味があるなら Heavy の初期割引（99 ドル / 月）を試算する
中長期の見通し
- フリーティアの復活は期待薄
- Grok Build が安定軌道に乗れば SuperGrok の制限が若干緩和される可能性はある
- xAI が公式声明を出さない限り、外部からの予測に限界がある
Grok Build のスキル体系を見ると、xAI がコーディング + Office 文書生成 + 並列実装という「知識労働の全自動化」に本気で取り組んでいることが伝わってくる。Grok Imagine も動画生成 AI として機能の幅は確かに広い。
ただ、サービス変更を AI の自動ポストだけで済ます透明性の欠如は、長期的な信頼コストになる。$30 〜 $300 を毎月払うユーザーに対して、変更の理由と見通しをきちんと説明することは、サービスとしての最低限の責任だろう。
