今週、私はミュージックビデオを作りました。音源を Grok Bot に渡し、私の PC 上にある Claude Opus 5.5 を呼び出して動画を制作するよう指示したのです。
https://x.com/cgnot996/status/2108157846005350754
この作品を作るには、大量の画像や動画フレームを確認する必要がありました。
ここ数日の投稿では、「クォータが 2〜3 日で枯渇してしまい、週次のリセットをただ待つしかない」という声も目立ちました。
この記事では、私が編み出した 12 のテクニックをまとめました。それぞれ Bot にそのままコピペできるプロンプト付きで、どこで節約できるのか、エントリープランでも使えるのかを解説します。
Bot に指示を送る前に、あまりメッセージを送っていないはずなのにクォータが静かに減っていく理由を不思議に思ったことはありませんか？
まず「クォータの消費ルール」を理解する
公式ドキュメントでは各プランに含まれる正確なクォータ量は公開されていませんが、根本的なルールは 3 つのポイントに集約されます。
第一に、クォータはメッセージ数ではなく、Bot が実際に実行した作業量に基づいて消費されます。
モデルの呼び出しコスト、文字数、ツール呼び出しのすべてが消費対象です。
第二に、各 Bot には会話スレッドが 1 つしかなく、ターンごとに履歴全体を読み直します。
チームアカウントを確認していた Cursor の従業員によると、最もアクティブな Bot はステップごとに 80,000〜90,000 トークンを読み直していたそうです。
第三に、使い切った場合は翌週のリセットまで作業を止めて待つか、トークン単位の従量課金で支払うかのどちらかになります。オンデマンド課金を有効にすると、あっという間に消費が進みます。
仕組みを理解すれば、クォータ節約の戦略はシンプルです。最もコストの高い処理を外部に任せ、無駄な出力を減らし、重い作業はすでに持っているツールに委ねることです。
まずは一番コストがかかるものを削る
コツ 1：画像分析・動画の確認・文字起こしは CLI ツールに任せる
マルチモーダル入力は消費の大きな原因です。スクリーンショット、動画フレーム、スキャンデータを直接チャットに送ると、コンテキストサイズが一気に膨れ上がります。
あるユーザーの検証では、1 日に画像 4 枚を送信し、検索を 1 回行い、スキャン文書 2 件を処理しただけで、最上位プランの週間クォータの 11% が消費されました。
正しいアプローチは、クラウド PC 内の Grok Build や agy といったコマンドラインツールを使ってファイルを読み込み、テキスト要約を生成させることです。Bot はその要約だけを読めば済みます。
CLI 環境がない場合は、まず grok.com の Web 版や無料の Gemini Web で要約を取得し、それを Bot に貼り付けましょう。
Bot 用のコピペプロンプト：
「スクリーンショットの確認、動画フレームの分析、フレームごとの確認、音声の文字起こし、長いスキャン文書の認識などのタスクでは、あなた自身がマルチモーダルファイルを直接読み込まないでください。優先的にクラウド PC 内の Grok Build を呼び出してファイルを読み込み、テキスト要約を出力させてください。あなたはそれが生成したテキストの結論だけを読むようにしてください。コマンドラインツールが使えない場合は、私に『まず Web 版でテキスト要約を取得してから送ってください』と促してください。」
- 節約ポイント：Bot がマルチモーダルファイルを直接読むのを防ぎます。外部ツールが画像や動画を要約した後、Bot は数百語のテキストを読むだけで済みます。
- エントリープランでの利用：部分的に利用可能。クラウド PC に Grok Build をインストールすると、それ自身のサブスクリプションクォータを消費します。未インストールの場合は、Web 版での要約から始めましょう。
コツ 2：1 つの会話を長くしすぎない
各 Bot には会話スレッドが 1 つしかありません。チャットが長くなるほどコードやログが蓄積され、句読点を 1 つ変えるだけでも履歴全体を読み直すことになります。
会話の長さをコントロールするには、次の 4 ステップに従ってください。
第一に、長期的なルールは Bot の説明文に書き込み、完成したワークフローはスキルとして保存しましょう。毎日チャットで同じ指示を繰り返す必要はありません。
第二に、長い資料、ログ、進捗状況はファイルに保存し、Bot には結論とファイルパスだけを返させます。大量の生テキストをチャットに貼り付けさせないでください。
第三に、スケジュールされたタスクや長期プロジェクトは専用 Bot に任せ、日常チャット用のメイン Bot には入れないようにします。
第四に、会話が長くなりすぎたら、Bot に引き継ぎ用の要約を書かせます。iPhone ではこの Bot を複製できます（iPhone で検証済み。動作します。デスクトップ版のメニューにはもうこのオプションがありません）。要約をコピーに送り、古い Bot は削除せずに非表示にします。
ここでのトレードオフは、複製したコピーには過去の会話、メモリ、添付ファイルが引き継がれないため、重要な事実を一度伝え直す必要がある点です。
Bot 用のコピペプロンプト：
ルールとスキルの整理：
「あなたが常に守るべきルールを 1 つの段落にまとめてください。あなたの説明文に貼り付けられるようにします。また、今完成させたワークフローをスキルとして保存してください。」
長い資料のファイル保存：
「これからは、長い資料、トラブルシューティングのログ、中間結果は /workspace/ 配下にファイルとして保存してください。私に返信する際は、結論とファイルパスだけを提示し、元のテキストをチャットに貼り付けないでください。自分用に notes.md を作成し、あなたの役割、現在のタスク、下した決定を記録して、区切りごとに更新してください。」
引き継ぎ要約の作成：
「10 行以内で引き継ぎ要約を書いてください。あなたの役割、現在のタスク、下した決定、次のステップ、必要なファイルパスを含めます。これをあなたの複製に渡します。」
- 節約ポイント：メインの会話が長い資料で肥大化するのを防ぎ、ターンごとの再読み込みを劇的に削減します。重要なルールは説明文やファイルに固定されるため、薄まることもありません。
- エントリープランでの利用：ルールの整理、ファイル保存、Bot の分割はすべて利用可能です。Bot の複製は現在 iPhone からの操作が必要で、コピーには事実を伝え直す必要があります。
コツ 3：スケジュールの間隔を空け、変化がなければ沈黙させる
ルーティンタスクは管理しないと、気づかないうちにクォータを消費します。公式ヘルプセンターでも、短い間隔のタスクは 1 日で 1 週間分のクォータを使い切る可能性があると警告しています。
自己監査をしたあるユーザーは、高頻度のタスクが週に 672 回トリガーされていることを発見しました。1 時間ごとに変更したところ、168 回に減りました。
使っていないルーティンタスクを一時停止すれば課金は止まります。ただし、画面上で「テスト」をクリックするたびにクォータが消費されるので注意してください。
Bot 用のコピペプロンプト：
「あなたが設定しているスケジュールタスクをすべてリストアップし、それぞれの実行頻度、週間の合計実行回数、変化がない場合でもメッセージを送るかどうかを教えてください。どのタスクが最もクォータを消費しているか特定し、その間隔を長くして、ルールを変更してください。チェックしても実質的な変化がなければ、沈黙したままでレポートを生成しないでください。」
- 節約ポイント：無駄な起動を減らします。「変化なし」のレポートを取りやめることで、その都度の呼び出しコストを節約できます。
- エントリープランでの利用：完全に利用可能。全プランでいつでもサイクルの調整やタスクの一時停止ができます。
コツ 4：変化があったときだけ起動する
これはコツ 3 の応用版です。Bot が休止中でも、クラウド PC バックエンドの Linux cron ジョブは動き続けています。
Web ページやファイルの変更をチェックするシステムスクリプトは数秒で終わり、モデルを経由しないため Bot のクォータは一切消費しません。
最近、私はマーケティングディレクター Bot をリファクタリングしました。6 つあるスケジュールのうち、データ監視系の 2 つをスクリプトベースの監視に移行し、変化があったときだけ Webhook で Bot を起動するようにしました。
リファクタリングには約 23 分かかりましたが、週 8〜10 回の無駄な起動を減らしつつ、検知のタイムラグを 30 分以内に改善できました。
Bot 用のコピペプロンプト：
「データ監視のルーティンタスクについては、Routines で定時ポーリングによる起動を設定しないでください。クラウド PC のバックエンドに軽量なチェックスクリプトを設定し、通常はシステムを休止させておいてください。スクリプトが対象データの実質的な変化を検知したときだけ、Webhook アドレス経由で私を起動してください。」
- 節約ポイント：起動して何も見つからず再びスリープする、というポーリングを排除します。Bot は実際の作業があるときだけ起動し、クォータを消費します。
- エントリープランでの利用：利用可能。全プランのクラウド PC で、基本的なスクリプトと Webhook トリガーの組み合わせを実行できます。
Bot の無駄口を減らす
コツ 5：グループチャットを避け、Bot 同士の会話を最小限にする
Grok Bot の公式エンジニアは、グループチャットが非常にトークンを消費することを公言しています。人数が多いほどコストがかさむため、一般ユーザーは避けるよう推奨しています。
Cursor の従業員は、メッセージが 1 件送られるたびに Bot が履歴を読み直し、返信が他の Bot を起動させてしまうと指摘しています。
あるアカウントでは、ターンの約 3 分の 1 が Bot 同士の相互起動でした。エントリープランのユーザーは Bot の数を減らし、個別の 1 対 1 チャットで対応すべきです。
Bot 用のコピペプロンプト：
「私が直接出した指示のみを厳格に実行してください。グループでの連携や複数者への確認のために、他の Bot を自発的に起動しないでください。タスクに複数ステップの調整が必要な場合は、私が主要な結論を中継するか、サブタスクをそれぞれのツールに個別に委任します。」
- 節約ポイント：Bot 同士の挨拶や循環参照によるオーバーヘッドを回避し、クォータを実際のタスクのために温存できます。
- エントリープランでの利用：完全に利用可能。1 対 1 のコミュニケーションへの切り替えに制限はありません。
コツ 6：新しく作る前に再利用する
新しい Bot を作るたびに、プロンプトの入力やツール呼び出しのテストが必要です。公式の新規ユーザー向けクォータは限られており、大きなタスクなら一撃で使い切り、補充もありません。
公式エンジニアは「新しく作る前に再利用し、無駄に騒がないこと」を勧めています。コアとなる Bot は 2〜3 個に絞り、新しい要件が出たら既存の Bot にルールを追加することを優先しましょう。
Bot 用のコピペプロンプト：
「新しい要件のために新しい Bot を作成する前に、現在のワークフローとツールの設定を見直してください。既存の Bot がすでに同様の基本機能を持っている場合は、独立した新しい Bot を作るのではなく、元の設定にルールを追加したり機能を拡張したりすることを優先してください。」
- 節約ポイント：新しい Bot 作成に伴うデバッグ、テスト、初期化のオーバーヘッドを節約します。
- エントリープランでの利用：全プランで完全に利用可能です。
重い作業は既存のサブスクリプションに任せる
コツ 7：クォータの迂回、スケジューラ ≠ 実行者
これは 9 月に杭州で共有した核心的なロジックです。Grok Bot はスケジューリングを担当し、重い作業は既存のサブスクリプションに切り離します。
チャットボックスで何百行ものコードを書いたり、リファクタリングのためにリポジトリを読み込んだりすると、クォータは急速に枯渇します。
クラウド PC に Grok Build をインストールしてログインしておきます。Bot にバックグラウンドでコマンドを発行させて Grok Build にコードを書かせ、Bot 自身は結果を報告するだけにします。
テストでは、コーディングを Grok Build に委ねた後、Bot プールは 2 日半で 70% を消費しましたが、外部の開発プールはわずか 6% の消費でした。
別のユーザーは Bot に Cursor での開発をスケジュールさせるだけにして、3 時間連続で作業した後の週間クォータ消費はわずか 3% でした。
Bot 用のコピペプロンプト：
「あなたの役割はタスクスケジューラであり、計画の分解、ロジックの整理、ツールの割り当てを担当します。ダイアログウィンドウで直接長いコードを書いたり、大規模なファイル変更を行ったりしないでください。コードの記述やプロジェクトのリファクタリングタスクは、バックグラウンドで認証済みの Grok Build を呼び出して一括で行い、最終的な実行結果だけを私に同期してください。」
- 節約ポイント：消費の激しいコード記述を既存サブスクリプションの開発プールに移し、Bot は短い指示を送るだけにします。
- エントリープランでの利用：利用可能。クラウド PC に Grok Build をインストールし、既存アカウントでログインしてください。
コツ 8：X 検索は内蔵の無料枠を使い、要点だけを残す
現在の Grok Bot の X プラットフォーム検索は内蔵の無料枠を使用しており、1 分あたり 30 回、1 日あたり 1000 回に制限されています。
この検索は Bot の週間クォータも X API クレジットも消費しません。
問題は結果の逆流です。大量のツイートをチャットに貼り付けると会話が肥大化し、その後のすべてのステップで再読み込みと支払いが発生してしまいます。
大量の生ツイートは Bot にファイルへ保存させ、チャットには要点とリンクだけを返させましょう。また、頻度制限にも注意してください。
Bot 用のコピペプロンプト：
「X プラットフォームのツイート、意見、アップデートを取得する際は、内蔵の無料検索機能を使用してください。取得した大量の生ツイートは /workspace/ 配下のファイルに直接保存し、ダイアログでは抽出した核心ポイントと対応するリンクだけを報告してください。ツイートの原文を大量にチャットへ貼り付けないでください。」
- 節約ポイント：検索に内蔵の無料枠を使い、ツイートを外部に保存することで会話の肥大化を防ぎます。
- エントリープランでの利用：完全に利用可能。全プランにネイティブでこの検索枠が含まれています。
無料 API：クォータを節約しつつ機能を追加する
既存のサブスクリプションに加えて、公開されている無料 API を統合すれば、軽量のテキスト処理、画像認識、生成を外部に逃がせます。
OpenRouter：軽量テキスト＆無料の画像認識
OpenRouter は :free で終わる無料モデル群を提供しており、短いテキストのリライト、要約、無料の画像認識に適しています。
公式の制限は 1 分あたり 20 回、1 日あたり 50 回ですが、過去の実績では 10 ドルのクレジットを積み上げると 1 日の上限が 1000 回に引き上げられます。
3 つの注意点があります。
第一に、API Key 作成時にクレジット上限を 0 に設定し、誤って有料モデルで課金されるのを防ぎます。
第二に、機密データは送信しないでください。一部のプロバイダーは入力データがモデルの学習に使われる可能性があると明記しています。
第三に、Key はクラウド PC に保存し、そのマシン上のすべての Bot がファイルを読み込めるようにします。
リンク：
- API Key 管理：https://openrouter.ai/settings/keys
- レート制限ドキュメント：https://openrouter.ai/docs/api-reference/limits
- 無料モデルのドキュメント：https://openrouter.ai/docs/guides/routing/model-variants/free
Bot 用のコピペプロンプト：
「OpenRouter の無料モデル呼び出し環境を設定してください。手順：
1. チャットのシークレット入力ボックスを通じて私から API Key を取得してください。キーをチャットに直接貼り付けさせないでください。
2. 受け取ったキーを ~/.agents/secrets/openrouter.env に変数名 OPENROUTER_API_KEY で保存してください。
3. そのファイルに対して chmod 600 を実行してください。
4. 処理中にキーをターミナルやチャットウィンドウに出力することは厳禁です。
5. 最小限のテストを実行してください。:free で終わるモデルを呼び出して 1 文だけ返信させ、コストが 0 であることを確認し、結果を報告してください。」
発展的なアイデア：FreeToken-Bots の閾値とリスク
オープンソーススキルの FreeToken-Bots（https://github.com/limin112/min-skill/tree/main/skills/FreeToken-Bots）は、OpenRouter 上の無料モデルをスキャンします。
作者は「完全自動の無人切り替えを期待しないでください」と明言しています。私が試したところ、20 の無料モデルをスキャンして、そのまま使えるものは 0、パラメータ検証が必要なもの 17 でした。
キーはクラウド PC 上のすべての Bot から見え、無料モデルにはレート制限や学習条項があるため、エントリーユーザーはここに労力を割かない方がよいでしょう。
ModelScope：画像生成・編集のみに使う
ModelScope の API-Inference は、画像生成・編集のみに使うことをおすすめします。
テストしたところ、テキスト、ビジョン、AV インターフェースはサービス利用不可を示す 429/400 エラーを頻繁に返し、安定性に欠けます。
3 つの注意点があります。
第一に、Aliyun アカウントの紐付けと実名認証が必要です。
第二に、「Magic Cube」クレジットから消費されます。1 日の上限は公式ページに記載されています。
第三に、Bot にこの公開画像生成スキルをインストールさせます：https://github.com/RongleCat/tiezhu-modelscope-api-inference。
リンク：
- Access Token 管理：https://modelscope.cn/my/myaccesstoken
- API-Inference の紹介：https://modelscope.cn/docs/model-service/API-Inference/intro
- 制限とルール：https://modelscope.cn/docs/model-service/API-Inference/limits
Bot 用のコピペプロンプト：
「ModelScope の画像生成環境を設定してください。手順：
1. チャットのシークレット入力ボックスを通じて私から Access Token を取得してください。トークンをチャットに直接貼り付けさせないでください。
2. 受け取ったトークンを ~/.agents/secrets/modelscope.env に変数名 MODELSCOPE_API_KEY で保存してください。
3. そのファイルに対して chmod 600 を実行してください。
4. 処理中にトークンをターミナルやチャットウィンドウに出力することは厳禁です。
5. 最小限のテストを実行してください。Tongyi-MAI/Z-Image-Turbo を呼び出して画像を 1 枚生成し、ローカルパスを報告してください。」
財布を守る
コツ 9：小さく試し、ダッシュボードを確認する
闇雲に一括処理を行うと、簡単にクォータを使い切ってしまいます。2 ステップ目で Bot が誤解した場合、何度もやり直すうちに 1 週間分のクォータが燃え尽きます。
あるユーザーは、順次タスクの試行錯誤によって 2 時間で週間クォータの半分以上を消費してしまいました。
複雑なタスクでは、まず 1〜2 件のサンプルで単一ステップを検証し、確認のために一時停止させましょう。
確認後、Settings → Usage & Billing で消費割合をチェックしてから続行します。
Bot 用のコピペプロンプト：
「バッチ処理、長いフローのトラブルシューティング、複雑なマルチステップタスクでは、まず 1〜2 件の最小サンプルを使って単一ステップの検証を行ってください。単一ステップ完了後は必ずすぐに一時停止し、私の確認を待ってください。明確なゴーサインの前に後続のステップを自動実行することは厳禁です。」
- 節約ポイント：単一ステップのサンプルで方向性の誤りを食い止め、論理的なズレが週間クォータを焼き尽くすのを防ぎます。
- エントリープランでの利用：完全に利用可能。使用量やリセット時刻は設定パネルでいつでも確認できます。
コツ 10：ループの上限を設け、迷ったら聞く
エラー時のリトライは隠れた罠です。解決できない環境や権限の問題に直面すると、Bot は無限リトライループに陥ります。
10 分間のデスループで週間クォータが枯渇することもあります。1 回の操作に対するリトライ上限は必ず 2 回にし、2 回連続で失敗したらすぐに人間に問い合わせるようにしなければなりません。
Bot 用のコピペプロンプト：
「自動化スクリプト、API 呼び出し、トラブルシューティング中は、アンチループルールを厳格に実行してください。同じ操作のリトライ上限は 2 回です。2 回連続で失敗した場合や結果が不確かな場合は、すぐに実行を中断して私に問い合わせてください。無限の自己リトライは厳禁です。」
- 節約ポイント：エラーによるデスループを断ち切り、バックグラウンドでの無駄な消費を防ぎます。
- エントリープランでの利用：完全に利用可能。純粋なプロンプトによる制約なのでコストゼロです。
コツ 11：従量課金を無効にし、適切なパックを購入する
Cursor のアカウント設定でオンデマンド課金を無効にするか、上限を低く設定してください。
オンデマンドは実際のトークン単価で請求されるため高額です。30 分で 26 ドル課金され、最終的な請求額が 51 ドルになったという報告もあります。
一晩で余分に 190 ドル消費した人や、小規模チームで週に約 1500 ドルのオンデマンド請求が発生した例もあります。
公式ヘルプセンターは、月次上限は緊急ブレーキではないと注意喚起しています。実行中のタスクは上限を超える可能性があります。オンデマンドが無効なら、枯渇してもリセットまで停止するだけです。
grok.com でアドオンパックを決して購入しないでください。課金システムが別で、資金の移動はできません。100 ドルのパックを買ったのに使えなかったというユーザーもいました。
Bot 用のコピペプロンプト：
「現在の環境の実行ルールを確認してください。クォータが枯渇しそうになったら停止して私に通知し、Cursor の課金ページでオンデマンドのトグルを確認するよう促してください。」
- 節約ポイント：財布の最低ラインを守り、制御不能なタスクによる暴走コストを防ぎます。
- エントリープランでの利用：完全に利用可能。Cursor の課金ページでオフに切り替えられます。
コツ 12：クォータ枯渇時は手動でクラウド PC に接続する
長いタスクでクォータが 90% 消費されると、フロントエンドのチャットがロックされます。
サードパーティのユーザーによると、クラウド PC への接続自体は可能で、途中までの成果物をダウンロードしたり手動で続行できたりするそうです。まずは自分で検証してみてください。
Bot 用のコピペプロンプト：
「システムが週間クォータの枯渇を警告した場合、セッション終了前に、アクティブなファイルパス、一時出力、実行のブレークポイントをすべてワークスペース内の一時アーカイブフォルダに一括保存し、簡潔な引き継ぎ手順を生成してください。」
- 節約ポイント：最後の数ステップを救うために強制的なオンデマンド課金を発生させるのを防ぎます。
- エントリープランでの利用：利用可能。基本的なターミナル知識が必要で、あくまで緊急措置です。
現実と合わない 3 つのテクニック
1. 軽いモデルに切り替えてクォータを節約する
公式ドキュメントによると、現在モデルピッカーは存在しません。
システムがタスクの難易度に応じて自動的にモデルを割り当てるため、手動での切り替えは不可能です。下位プランへの切り替えも存在しません。
2. 複数のティアのサブスクリプションを重ねる
公式 FAQ には、バインドは合算されない（Cursor プランと SuperGrok/X Premium+ の連携は合算されない）と明記されています。
二重サブスクリプションの場合、高い方のクォータのみが採用され、他方はアイドル状態になります。加算はされません。
3. grok.com でアドオンを購入する
grok.com は Web チャット向けであり、Grok Bot は Cursor システムを使用しています。アカウントは別々で、チャージしても Bot のクォータは増えません。
境界に関する注意事項
これらのコツは Grok Bot の週間クォータを節約するものです。公式はプランごとの具体的なトークン数やタスク上限を一切公開していません。
本記事の消費比率や課金データは、主にサードパーティの個人的なサンプルに基づくものであり、実際の消費量はタスクによって異なります。
枯渇後の手動クラウド接続に関する主張はサードパーティの情報ですので、頼る前に必ず自分でテストしてください。
まとめ
公式はティアごとのトークン数や週間のタスク処理能力を公開しておらず、相対的なランキングのみです。
有料サブスクライバーとしては、タスクやツールの消費詳細が透明化され、毎日推測する手間が省かれることを願っています。
ここでは現在の旧サブスクリプション構造におけるクォータ問題を扱いました。公式はサブスクリプションの統合を進めているので、新しいパッケージが発表されたら改めて解説します。Musk 氏が、こんな窮屈な思いをせず、余裕たっぷりに使えるようにしてくれることを願っています。
あなたの Grok Bot クォータを最も早く消費するのは何ですか？コメントで語り合いましょう。
オープンソース Grok App の作者（GitHub 1400+ Stars）。現場で数百万ドル規模の AI プロジェクトを実装しています。
Grok Bot の実践チュートリアルとコピペプロンプトを継続的に更新中。@cgnot996 をフォローして、私と同じ轍を踏まないようにしましょう。
