Grok Botの利用枠と上限：週ごとの使用量、追加課金、アカウント連携を整理

2026年10月9日に確認した公式資料に基づきます。計算例は仮定の会計例で、実測の請求や現在の契約料金ではありません。

Grok Botの週ごとのプランに含まれる利用枠と、月ごとのon-demand支出上限は別の制御です。週の枠を使い切っても月額契約の期限切れとは限りません。on-demandを有効にすると追加料金で作業を続けられる場合がありますが、月の上限は実行中タスクを必ずその金額で停止させる境界とは説明されていません。契約変更や再実行の前に区別してください。公式プラン・請求。

診断では、アカウントに資格があるか、含まれる利用量が残っているか、追加消費が有効か、追加分にどの上限が適用されるかを別々に確認します。「一時停止」の表示だけで四つすべては判断できません。認証、アプリ権限、コンピューターの問題は、容量購入では直りません。

利用資格と残量は別

公式ページは有料Cursor個人プラン、Teams、Enterpriseの条件と、対象のGrok・X契約を関連付ける経路を示しています。SuperGrok Liteなど対象外の契約も区別されています。法人利用では該当アカウントや割り当てられたユーザー席の条件もあります。Grokという名前だけで同じ権利と考えず、現在の一覧とアカウント表示を確認します。

資格は製品を使える経路の有無、残量は今使えるプラン内の利用枠です。資格があっても今週の枠は使い切れます。有料モデルAPIキーも別のエージェント製品の資格を証明しません。購入したサービスと制限を表示するサービスを特定します。

まずGrok Botに表示されるアカウントと請求側アカウントを記録します。チームでは組織のユーザー席か個人契約かも確認します。識別情報は非公開の調査記録に残し、公開画像には載せません。

週単位と月単位で何が違うか

利用枠のリセット時刻はアカウントの実表示を読み、一律の曜日やローカル午前零時を割り当てないでください。タイムゾーンが違うと画像とサポート記録の日付が違って見えます。日時とタイムゾーンを保存し、画面にない情報は不明とします。

公式の試用クレジット説明はステップやトークンを用い、単純なメッセージ数ではありません。これは全契約に共通する換算規則を示すものではありません。似た長さの指示でも、閲覧、ツール操作、修正の量は異なり、「一メッセージ」を共通原価単位にはできません。

含まれる枠を使い切ったら

まず本当に使用量不足の通知かを確認します。ログイン要求や接続不可なら、その問題の経路で調べます。原因不明のまま再開すると仕事が重複し、使用量の帰属も難しくなります。

枠がなくon-demandが無効なら、資料は利用枠のリセットや該当する契約条件の変化まで仕事が止まると説明しています。追加料金を望まない場合、無効のままにするのは意図した選択で、直すべき故障ではありません。

追加消費を選ぶなら、再開前に現在の請求情報と管理者の規則を確認します。公式説明ではon-demandはCursorを通じて請求され、その月間上限に算入されます。利用資格を得た契約の販売者と追加請求先が同じとは限りません。

実行中のタスクは月間上限を超えて完了する場合があるとも説明されています。長い手順の仕事では特に重要です。小さな上限を設定しただけで最終請求が絶対に同額以下になるとは約束できません。組織が厳密な予算停止を必要とするなら、実際に利用できる制御を確認します。強い指示文でも請求の仕組みは変わりません。

契約を増やしても期待する容量が増えない理由

公式規則はGrok Botへの資格付与とCursorプランの変更を分けています。対象契約の関連付けはCursorのアップグレードと同義ではありません。既存契約は別々に請求され続けることがあり、複数対象契約の枠が単純加算されるとも説明されていません。関連付けとプラン。

確定前に関連付けるアカウントを確認します。文書では恒久的な連携で、自由な移動や解除はできません。ボタンを試すためだけに予備アカウントを使わないでください。誤連携と一時的に古い使用量表示は別の問題です。

すでに関連付けたSuperGrokをPlusまたはHeavyへアップグレードした場合、利用資格の反映に最大24時間かかる可能性が説明されています。この特定の変更をした場合に、控えと時刻を保存し、正しいアカウントと所定の反映期間を確認します。あらゆるプラン変更へ24時間を一般化したり、反映遅れの診断に契約を何度も購入したりしないでください。

もちろん、資格不足をすべて一日放置するという意味ではありません。明らかな別アカウント、対象外プラン、具体的なエラーは別途対処します。反映待ちなのか、そもそも付与されない変更なのかを区別します。

七日間の試用は無制限ではない

公式説明には試用枠と七日間の期間があり、別の条件です。日数が残っていても試用枠を使い切る場合があります。七日間使い放題と紹介すると、この構造を誤って伝えます。

実際の経路の条件を確認してください。資料は自動で有料化しない製品自身の試用と、更新条件を持つ場合があるAppleの導入特典などを区別しています。一つの経路の解約・更新ルールを別プラットフォームへ広げないでください。

試用では小さくても完結する仕事を選び、成果を検収します。際限のない指示で枠を使い切るより、文書処理を一巡させるほうが判断材料になります。元指示と出力を残し、通常の有料条件でも価値があったか評価します。

単位を混ぜずに原価を記録する

以下は仮定の例です。ある通貨表示の追加請求額が、一つの独立タスク中に2.40から2.85へ増えたなら差は0.45です。ただし同じ時間に他の仕事がその残量を使っていない場合に限り、その仕事の追加請求として観測した金額とみなせます。Grok Botの実請求や料金例ではありません。

他のBot、定期処理、ユーザーが動いていれば、アカウント全体の差をこの仕事だけに帰属できません。同時実行の影響を記録するか、製品が実際に提供するタスク明細を使います。共有使用量を均等配分するなら、自分の配賦仮定と明記し、提供者の一件請求と偽らないでください。

残量が80%から74%に動いた場合、差は六パーセントポイントです。六ドル、六credits、六件ではありません。文書化された換算がなければ金額へ直せません。

仮の月額Sを検収済み成果N件に配分するS/Nも、自分の会計方法です。提供者の一件単価ではなく、失敗出力や未使用容量によって解釈が変わります。次のように記録できます。

タスク識別子：
開始・終了日時とタイムゾーン：
アカウントとプラン（非公開）：
プラン内の利用枠の前後表示と元の単位：
on-demand請求の前後表示、表示された通貨：
同時に動いていた他の仕事：
実際に届いたファイル：
検収までに必要だった修正：
不明・閲覧できない請求項目：

見えない値はnullや不明にします。ゼロは確認したゼロだけです。過去の表示や明細は時刻付きで保存し、当時の条件を持たずに新料金で古い請求を説明しないでください。

支出設定だけでなく仕事の範囲も管理する

資料、成果、停止条件を指定すると検収と記帳が容易です。調査では問いを絞り、読めない情報源を際限なく再試行するのではなく報告させます。執筆ではまず草稿と未確定事実を受け取り、その後で公開や大規模修正を許可します。

これは費用を保証する方法ではありません。プロンプトは請求機構を上書きしません。仕事に終点を作り、追加修正をどこまで許可したかの曖昧さを減らすためです。

定期処理は別に確認します。新しい仕事を評価している間も古いroutineが消費する場合があります。有効な一覧と最近の実行を見てから、最新会話への帰属を考えます。一時停止は変更として記録し、一覧を整理するためだけに削除しないでください。Routineの資料。

症状ごとに対処を選ぶ

公式問題解決はアカウント、課題、コンピューターの故障を区別します。未解決の請求には資格経路、日時、正確な通知、提供してよい明細を正式な窓口へ渡します。秘密、決済情報、無関係な会話履歴を公開しないでください。

関連するGrok Botガイド

• Grok Botの始め方：インストールから最初の成果物の確認まで
• Grok Botのroutineが動かないときは？トリガー、所属先のBot、実行記録の確認手順
• Grok BotとOpenAI Dotsの文書に基づく比較