Grok Rate Limit完全解説――API設計・429対策・プラン別制限の実装指針

Grok rate limitとは何か――制限の種類と設計上の位置づけ

xAIが提供する対話AI「Grok」には、コンシューマ向けサブスクリプションとAPI、それぞれに独立したレート制限（rate limit）が設けられている。エンジニアが直面する問題は大きく二つに分類できる。一つはgrok.com・Xアプリ上でのチャット利用で制限を受けるケース、もう一つはAPI統合においてHTTP 429（Too Many Requests）が返ってくるケースだ。両者は仕組みが異なるため、切り分けて理解することが実装判断の出発点になる。

公式ドキュメント（docs.x.ai/developers/models、2026年6月8日取得）によれば、現行の旗艦モデルはGrok 4.3（APIスラッグ grok-4.3）であり、2026年5月15日に旧モデル群（Grok 3、Grok 4初版 grok-4-0709、Grok 4 Fast等8モデル）は引退している。旧スラッグは grok-4.3 へリダイレクトされ、同モデルの標準価格で課金されるため、古いスラッグを使い続けているコードベースは意図せずコスト増になり得る点に注意が必要だ。

制限の種類を整理すると、以下の三層構造になる。

• コンシューマ層（grok.com / X）：時間窓あたりのプロンプト数制限。Freeプランでは「おおむね2時間あたり約10プロンプト」が公式の目安とされている（grok.com Plans、2026年6月8日確認）。ただし、xAIは具体的な数値を定期的に変更しており、この数字を固定値として設計に使うことは推奨しない。
• API層（x.ai）：リクエスト/分（RPM）およびトークン/分（TPM）による制限。Tier制で課金実績に応じて上限が段階的に引き上がる設計になっている。
• 生成系制限（Grok Imagine / Video）：画像・動画生成は別枠でカウントされ、プランによって1日あたりの生成回数が定められている。

コンシューマ層 grok.com / X アプリ 約10プロンプト/2時間（Free）

API層 RPM / TPM / Tier制 課金実績で上限が段階的に拡大

生成系制限 Imagine / Video テキスト系と独立したカウンター

HTTP 429 Too Many Requests Retry-After ヘッダーを確認して指数バックオフ RPM超過 / TPM超過 / 日次クォータ超過の3種を切り分ける

Grokの基本的な機能概要や料金体系については、Grok概要記事およびGrok料金プラン詳細記事も合わせて参照されたい。

プラン別 grok rate limit の実態――Free・SuperGrok・APIの違い

制限設計の肝は「どのプランで何を使うか」によって制限の粒度と緩和手段がまったく異なる点にある。特にエンジニアが見落としがちな点として、コンシューマプランのサブスクリプションではAPIアクセスが付与されないという構造的な制約がある。grok.com上での利用枠と、docs.x.ai経由のAPIキーによる利用枠は完全に独立しており、混同するとトラブルシュートで無駄な時間を費やすことになる。下表にプラン別の主要制限を整理した。

プラン	月額（USD）	チャット制限（目安）	Grok Imagine	API利用
Free	$0	約10プロンプト/2時間	大幅制限あり（2026年1月以降）	不可（別途APIキー要）
X Premium	$8（約1,200円）	Free比増量（詳細は非公表）	基本アクセス	不可
SuperGrok Lite	$10（約1,500円）	Free比2倍のチャット長	480p・6秒程度	不可
SuperGrok	$30（約4,500円）	DeepSearch含む大幅増量	標準品質（制限あり）	不可
SuperGrok Heavy	$300（約45,000円）	Grok 4 Heavy含む最上位	最高品質	不可
API（従量課金）	利用量に応じて変動	RPM/TPM（Tier制）	$0.02〜$0.05/枚	可（APIキー）

出典：xAI公式（grok.com/plans、docs.x.ai、2026年6月8日時点）。コンシューマ向けチャット制限の具体数値はxAIが随時変更するため、最新値は公式を参照のこと。

注目すべきはGrok Imagineの制限変更の急さである。2026年5月15日頃からSuperGrokの動画生成上限が「150〜200回/12時間」から「35回/24時間（480p）」へ大幅に引き下げられ、ユーザーから強い反発が生じたと報告されている（xAI Grok Imagine制限変更、2026年5月）。この変更は予告なく実施された点が問題であり、コンシューマ向け制限が事前通知なく変更されるリスクを示す典型事例として捉えるべきだ。プロダクトの重要機能をコンシューマプランの制限枠に依存させる設計は、この観点から推奨できない。詳細はGrok Imagine解説記事で扱っている。

また、xAI公式ドキュメントが明記しているとおり、開発者向けには月最大約$175相当の無料APIクレジットが提供されているが、この枠内では制限が厳しく設定されており、プロダクションワークロードに耐えるには有料Tierへの移行が前提となる（docs.x.ai、2026年6月8日取得）。

APIにおけるgrok rate limitの仕組みとHTTP 429対策

API利用時のgrok rate limitは、xAIのTier制によって課金実績に応じて段階的に引き上がる設計になっている。HTTP 429が返ってきた際の対処を、実装レベルで以下に示す。

1. Retry-Afterヘッダーを読み指数バックオフを実装する

xAIのAPIは429レスポンスに Retry-After ヘッダーを付与するケースがある。この値（秒数）を読んで待機するのが最も確実な方法であり、ヘッダーが存在しない場合は指数バックオフ（exponential backoff）とジッターを組み合わせて実装する。ジッターを加えないと、複数クライアントが同時にリトライして再び制限を超過する「thundering herd」問題が発生する。

import time, random, httpx

def call_with_retry(client: httpx.Client, payload: dict, max_retries: int = 5):
    """
    Grok API呼び出しにおける指数バックオフ＋ジッター実装例。
    Retry-Afterヘッダーが存在する場合はその値を優先する。
    """
    delay = 1.0
    for attempt in range(max_retries):
        response = client.post(
            "https://api.x.ai/v1/chat/completions",
            json=payload,
            timeout=60.0
        )
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            # Retry-Afterが存在すれば優先、なければ指数バックオフ
            wait = float(retry_after) if retry_after else delay
            # ジッター: 0〜500msのランダム加算でthundering herd防止
            time.sleep(wait + random.uniform(0, 0.5))
            delay = min(delay * 2, 60)  # 上限60秒
            continue
        if response.status_code == 200:
            return response.json()
        # 4xx系（安全フィルター等）はリトライせず即例外
        response.raise_for_status()
    raise RuntimeError(f"Grok API: max retries ({max_retries}) exceeded")

実装上のポイントとして、4xx系エラーのうち429はリトライすべきだが、400・401・403は即座に例外を上げるべきだ。安全フィルターによる拒否（後述）やAPIキーの認証エラーは、リトライを繰り返しても解消しない。

2. モデルの使い分けでTPMを節約する

現行ラインアップには用途別のモデルが揃っており、すべてのリクエストに旗艦モデルを使うとTPM消費が大きくなる。コーディングタスクには grok-build-0.1（Grok Build 0.1）が100+ tokens/secの高速処理と入力$1.00/Mトークン・出力$2.00/Mの低コスト設計を持つ（xAI News — Grok Build 0.1、2026年6月8日取得）。旗艦の grok-4.3（入力$1.25、出力$2.50/Mトークン）との比較では、コーディング専用タスクに限ればコストと速度の両面で優位だ。タスクの複雑度に応じたモデルルーティングが、rate limitへの到達を遅らせる最もシンプルな手段の一つとなる。

モデル別のコスト・コンテキスト長・用途を整理した比較はGrok API解説記事を参照されたい。

3. コンテキスト長の管理

Grok 4.3・Grok 4.20は1Mトークンのコンテキストウィンドウを持つが、大きなコンテキストを毎回送信するとTPMを急速に消費し、実質的に制限に達しやすくなる。具体的には、長大なシステムプロンプト（例：数千トークンの仕様書）を全会話ターンに含め続けると、たとえRPMが低くてもTPMを先に超過するパターンが多い。会話履歴のトリミング、要約によるコンテキスト圧縮、または必要なターンのみを含む設計が推奨される。

4. マルチエージェント利用時の並列度設計

Grok 4.20系には grok-4.20-multi-agent-0309 スラッグのマルチエージェント向けモデルが存在する（xAI Docs、2026年6月8日）。エージェントが並列でAPIを叩く設計では、単一ユーザーのワークロードでもRPMを短時間で超過する。エージェント数・並列度・ポーリング間隔の設計はrate limitを見越して行い、並列ワーカー数の上限をTierのRPM制限から逆算して設定することが重要だ。

また、grok-4.20系はstrong agentic tool-callingと低ハルシネーション率を訴求しているが（xAI公式、2026年6月8日）、ツール呼び出しのたびに追加トークンが消費される点は見落としがちなTPM増大要因だ。ツール呼び出し1回あたりのトークン消費を事前にベンチマークし、設計上の予算として組み込む必要がある。Grok 4の機能設計についてはGrok 4詳細記事も参考になる。

grok rate limitのトラブルシュートと設計判断――429の原因切り分けから旧スラッグ移行まで

429エラーの原因を3種類に切り分ける

429エラーが発生した場合、原因は大きく三つに分類できる。エラーメッセージ本文とレスポンスヘッダーの両方を取得した上で判断することが先決だ。

1. RPM超過：短時間に大量のリクエストを送った場合。バッチ処理の並列度を削減し、リクエスト間にスリープを挟むことで対応する。P99レイテンシではなくリクエスト発火間隔を制御することが本質的な解決策だ。
2. TPM超過：1リクエストあたりのトークン量は少なくても、コンテキストが大きく合計TPMを超えている場合。1Mトークンウィンドウを持つGrok 4.3でも、並列リクエスト×長大なシステムプロンプトは容易にTPMを圧迫する。特に非同期並列処理を採用している場合、同一分内に発火するリクエストのトークン総量を集計する仕組みを実装に組み込むべきだ。
3. 日次クォータ超過：RPM/TPMは通っていても1日あたりの総量制限に達したケース。開発者向けの無料クレジット枠（月最大約$175相当）では特に起きやすい。xAI dashboardのUsageページで累積消費量を確認できるが、プログラマティックなモニタリングと組み合わせることが望ましい。

安全フィルターによる拒否とrate limitを区別する

Grokには安全フィルターによるリクエスト拒否（4xx系）も存在し、これはrate limitとは別の問題だ。応答コードや本文のエラーメッセージで区別し、rate limitの緩和策（バックオフ・Tier変更）を安全フィルターの問題に誤適用しないよう注意が必要だ。安全フィルターで拒否された場合、リトライしても同じ結果になるため、即座に例外として上位レイヤーへ伝播させる設計が正しい。詳細はGrok安全性・フィルター解説記事を参照されたい。

旧スラッグのリダイレクトコストに注意する

2026年5月15日の引退後、grok-3・grok-4-0709・grok-code-fast-1 等の旧スラッグへのリクエストは引き続き受け付けられるが、すべてGrok 4.3の標準価格で課金される（xAI Docs — May 15, 2026 Model Retirement、2026年6月8日取得）。旧スラッグのまま運用していると、想定より高いコストが発生し、それが同時にTPM消費量の増加にもつながる。コーディング用途では grok-code-fast-1 の後継である grok-build-0.1 へ移行することで、入力$1.00/Mという低コスト枠を活用できる。本番コードベースに存在するモデルスラッグを全件検索し、現行スラッグへの移行を速やかに実施することを推奨する。

コンシューマ制限とAPI制限の混在構成に注意する

社内ツールを「SuperGrokのチャット」と「APIキーによるバックエンド統合」の両方で運用する場合、制限は独立した別枠として管理される。チャット側の制限を使い果たしてもAPIは影響を受けないが、逆にAPIクォータが切れてもgrok.com上のチャットは動き続ける。監視の対象を混在させると誤検知につながるため、メトリクスは必ず分けて取得し、アラートも別系統で設定することが重要だ。

Grok Imagineの生成制限は別枠で管理する

画像生成（$0.02〜$0.05/枚）・動画生成（$0.050〜$0.080/秒）・音声（STT: $0.10〜$0.20/時、TTS: $15/100万文字、リアルタイム: $0.05/分）はすべてテキスト系のTPM/RPMとは独立したカウンターで管理されている（xAI Docs — Models、2026年6月8日）。マルチモーダルなパイプラインを構築する場合、各モダリティのクォータを別々に監視するアーキテクチャが必要だ。2026年5月の動画生成制限の急激な引き下げが示すように、生成系のクォータはテキスト系以上に変動が激しい傾向がある。Grok Imagineの仕様についてはGrok Imagine記事を参照されたい。

rate limitを前提とした実装設計のベストプラクティス

grok rate limitを「障害」として扱うのではなく、設計上の制約として最初から織り込むことが堅牢なシステムを作る上での基本姿勢だ。以下に実装上の勘所をまとめる。

キューイングとトークンバケット

バックエンドにリクエストキューを設け、トークンバケットアルゴリズムでAPIへの送出レートを制御する。Celery・BullMQ等の既存キューに「Grok API用ワーカー」を独立して設け、concurrencyをTierのRPM制限に合わせた値に固定する構成が一般的だ。ワーカーのconcurrency値を環境変数で外部から注入できる設計にしておくと、Tier変更時の対応コストが下がる。

ストリーミングでユーザー体験を維持する

xAI APIはServer-Sent Events（SSE）によるストリーミング出力をサポートしている。レート制限による待機が発生する場合でも、キューに入ってから最初のトークンが届いた瞬間からストリーミングを開始することで、ユーザーが感じるレイテンシを抑えられる。ユーザー向けUIでは「処理中」のスピナーを出すだけでなく、待機理由を「現在リクエストが集中しています」のように明示する設計が保守性とユーザー体験の両面で有効だ。

モニタリングと自動アラート

429のレスポンス率・Retry-Afterの観測値・日次クォータ消費率の三指標をメトリクスとして収集し、クォータの80%到達でアラートを発火する設計が実用的だ。特に日次クォータ消費率は「1日のうち何時間でクォータを使い切るか」を予測する上で重要であり、線形外挿による残余推定を自動計算する仕組みを組み込むと運用上の視認性が高まる。

retry stormを防ぐフォールバック設計

プロダクション環境では、Grok APIがrate limit超過・障害でダウンした際のフォールバックを設けることが推奨される。完全なフォールバックが難しい場合でも、429発生時に無限リトライでAPIを叩き続ける実装（いわゆる「retry storm」）は避けなければならない。上限リトライ回数・最大バックオフ時間・サーキットブレーカーの三点セットを実装しておくことで、障害時の波及を最小限に抑えられる。

フォールバック先の選択は要件次第だが、「キャッシュ済みの結果を返す」「処理を遅延キューに積む」「ユーザーに後で再試行を促す」の三択が現実的だ。いずれの場合も、フォールバックが発動した事実とその理由をログに残し、次のTier申請やアーキテクチャ見直しの根拠として活用することが重要だ。

バーチャルヒューマン統合システムにおける注意点

弊社（クリスタルメソッド）が開発するDeepAIは、実在の人物の容姿・表情・声・振る舞いをデジタル空間で再現するバーチャルヒューマン／AIアバターソリューションであり、接客・研修・面接練習・広報等のリアルタイム対話用途に活用されている。このようなリアルタイム対話システムにGrok APIを組み合わせる場合、rate limitに起因する応答遅延がユーザー体験に直結するため、レート制限を要件段階から設計制約として明文化し、クリティカルパスにrate-limited APIを配置しない設計方針を採用することを推奨する。深層学習の基礎設計については深層学習解説記事も参考になる。強化学習を用いたエージェント設計との組み合わせについては強化学習記事を参照されたい。

Grokの全体的なエコシステムや最新動向についてはGrokブログ記事・ブログトップから継続的に情報を取得することを勧める。

---

以上、grok rate limitの仕組み・プラン別制限・429対策・実装設計の要点を解説した。制限値はxAIが随時改訂しているため（2026年5月の動画生成制限引き下げがその典型例だ）、本番運用前には必ずxAI公式ドキュメントで最新値を確認されたい。

弊社が開発するDeepAIについての詳細は、担当チームまでお問い合わせいただきたい。

---

参考文献

• xAI Docs — Models: https://docs.x.ai/developers/models（2026年6月8日取得）
• xAI Docs — May 15, 2026 Model Retirement: https://docs.x.ai/developers/migration/may-15-retirement（2026年6月8日取得）
• xAI News — Grok 4: https://x.ai/news/grok-4（2026年6月8日取得）
• xAI News — Grok Build 0.1 on API: https://x.ai/news/grok-build-0-1（2026年6月8日取得）
• grok.com Plans: https://grok.com/plans（2026年6月8日確認）
• Artificial Analysis — xAI launches Grok 4.3: https://artificialanalysis.ai/articles/xai-launches-grok-4-3-with-improved-agentic-performance-and-lower-pricing（2026年6月8日取得）

関連記事

• grok.com
• grok imagine
• grok プラン
• grok4
• grok api
• grok 規制
• grok build 使い方