なぜサブエージェントは30分で1週間分のクォータを使い切るのか
ツール呼び出しのたびに全履歴を再送している
5つのサブエージェントを30分間並列で動かすと、クォータの消費速度は単一の会話の数十倍になり得る——原因は、ツール呼び出しの往復のたびにそれまでの会話履歴全体を再送していることにある。
4つの重要事実
完全な履歴を再送している
多くのマルチターン/ツール呼び出し型 API はステートレスであり、リクエストのたびにシステムプロンプト、これまでの履歴メッセージ、それまでのすべてのツール呼び出し結果を入力として再送する必要がある。
累積消費はラウンド数にほぼ2乗で増加する
タスクが N ラウンドのツール呼び出しを要する場合、各ラウンドが運ぶ平均履歴量がラウンド数に比例して増えるため、累積トークン消費はおおよそ N の2乗規模になる。
複数のサブエージェントが同時に走ると効果が重なる
並列で動く各サブエージェントはそれぞれ独立に自分の履歴を保持・再送する。M 個の並列サブエージェントは単一会話の消費量をおよそ M 倍にする。
プロンプトキャッシュはコストは減らせてもクォータは減らせるとは限らない
一部のベンダーのプロンプトキャッシュは重複するプレフィックス部分の課金を下げられるが、クォータ/レート制限は通常実際に処理したトークン量で計算されるため、キャッシュをクォータ問題の万能薬にしてはいけない。
トークン再送とは実際どういうことか
主流の対話型/エージェント型 API の多くは「ステートレス」だ——リクエストのたびにコンテキスト全体（システムプロンプト、これまでのすべてのメッセージ、すべてのツール呼び出しの入出力）を運ばなければならず、モデル自体は前回のリクエストを記憶していない。つまり N ラウンドのツール呼び出しを必要とするタスクでは、1ラウンド目は初期コンテキストのみを送るが、2ラウンド目は1ラウンド目の結果も含める必要があり、Nラウンド目はそれまでのN-1ラウンド分すべてを含める必要がある——累積して送信されるトークン量は、ラウンド数に対して線形ではなく、おおよそ2乗で増加する。これが長時間タスクやマルチターンのエージェントループが特に「クォータを食う」根本的な理由だ。
なぜ並列サブエージェントでこの問題がより顕著になるのか
複数のサブエージェントを並列に起動して異なるサブタスクを処理させると、各サブエージェントが独立して上記の「履歴再送」を行い、しかも多くの場合同時に行われる——短時間で積み重なるトークン消費量は、単一会話の数倍から数十倍に容易に達する。これこそが「並列エージェントをいくつか動かしたら30分で1週間分のクォータを使い切った」という声の技術的な根本原因だ。
タイムライン
ステートレスな API が毎ラウンド完全な履歴を再送する設計は、主流の対話型/エージェント型 API に長く共通するアーキテクチャだ。
並列サブエージェントやマルチエージェント協調型ワークフローの普及により、この本来的な特性による消費が利用者に直接体感されやすくなっている。
プロンプトキャッシュなどの技術は課金コストを緩和できるが、クォータ/レート制限の計算方式は通常それに合わせて緩んではいない。
確認済み vs よくある誤解
確認済み
主流のマルチターン対話型/エージェント型 API のステートレスな特性、および毎ラウンドの完全履歴再送によるほぼ2乗規模の累積消費は、この種の API アーキテクチャの公開された一般的な挙動であり、公式ドキュメントと開発者の議論で一貫して説明されている。
よくある誤解
「プロンプトキャッシュを使えばすぐにはクォータ上限に達しない」と考える人が多いが、キャッシュは主に課金コストに影響するものであり、クォータ/レート制限は通常実際に処理したトークン量やリクエストの特性で計算されるため、キャッシュだけに頼ってクォータ消費を抑えることはできない。
消費の見積もりと圧縮の方法
見積もり方
タスクの想定ツール呼び出しラウンド数と各ラウンドの平均履歴量を見積もり、「1ラウンドの消費 × ラウンド数」という単純な線形計算ではなく、2乗に近い関係でおおまかに総消費を推定する。
圧縮の方法
履歴メッセージを定期的に要約圧縮する、ツール呼び出し結果は必要な部分だけ残しすべてをそのまま保持しない、並列サブエージェントの数と1つのサブエージェントあたりの最大ラウンド数を制限する——いずれもよく使われる圧縮手段だ。
具体的にどうするか
第一に、1つのタスクの最大ツール呼び出しラウンド数を制御し、閾値を超えたら無制限に積み上げるのではなく履歴の要約圧縮をトリガーする。第二に、ツール呼び出しの結果はタスクが本当に必要とする部分だけを残し、生のログや出力全体をそのままコンテキストに詰め込むのを避ける。第三に、同時に走らせる並列サブエージェントの数を制限するか、優先度の低いサブエージェントには安価で短いコンテキストのモデルを割り当てる。第四に、クォータ消費量をタスク計画の入力次元の1つとして扱い、複雑なタスクが走り出してから上限に当たると気づくのではなく、事前におおよそどれくらいのクォータを消費するか見積もっておく。
QCode 上での対処法
並列サブエージェントは短時間である特定のモデルのクォータを満杯にしやすい。QCode の1つのキーで異なるサブエージェントを異なるモデルファミリーに分散させれば、クォータ圧力を分散でき、1つのモデルが上限に当たってもマルチエージェントタスク全体が止まることを防げる。
よくある質問
なぜサブエージェントは単一の会話よりこれほど速くクォータを消費するのですか？
各サブエージェントは独立して自分の会話履歴を保持・再送するため、M個の並列サブエージェントは単一会話の消費量をおよそM倍にする。さらに1つのサブエージェント内部の累積消費自体がラウンド数にほぼ2乗で増加するため、両者が重なって短時間の消費量が大きく増幅される。
プロンプトキャッシュでこの問題は解決しますか？
重複するプレフィックス部分の課金コストは下げられるが、クォータ/レート制限は通常実際に処理したトークン量やリクエストの特性で計算されるため、キャッシュだけで上限到達を完全に避けることはできない。
1つのタスクがどれくらいクォータを消費するか、どう概算しますか？
想定されるツール呼び出しラウンド数と各ラウンドの平均履歴量を見積もり、「1ラウンドの消費 × ラウンド数」ではなく、2乗に近い関係でおおまかに推定してください。
並列サブエージェント数を制限すると、タスクの効率に影響しますか？
トレードオフがあります——並列数が多いほどタスクは速く完了しますが、短時間のクォータ消費圧力も大きくなります。自分のクォータ残量とタスクの緊急度に応じて判断する必要があります。
すべてのエージェントフレームワークにこの問題がありますか？
主流のステートレスな対話型 API を基盤に構築されたエージェントフレームワークであれば、原則としてこの特性を持ちます。フレームワーク側の履歴圧縮・要約戦略が優れているほど体感する消費速度は低くなりますが、アーキテクチャ上の根本原因は共通です。
クォータ上限に当たると、実行中のマルチエージェントタスクはどうなりますか？
上限に当たったモデル/アカウントは新しいリクエストを拒否し、タスクは通常中断するかエラーになります。一部のサブエージェントを事前に他のモデルに分散させておくことが、タスク全体が単一モデルの上限で止まってしまうのを避けるための一般的な方法です。
情報源
ステートレスな対話型/エージェント型 API が毎ラウンド完全な履歴を再送するというアーキテクチャ上の特性は、主要モデルプロバイダーの公開ドキュメントと開発者コミュニティで長く一貫して説明されている一般的な挙動である。本ページは特定のベンダーの非公開実装について断定するものではない。2026-08-27時点で整理。
関連記事
Claude の5時間ローリングウィンドウ解説
短時間の高強度利用で最も当たりやすい制限層。
サブスクリプション vs API：24/7 エージェントはプランを使い切るか
長時間の自動化タスクにおける経済比較。
複数ツールの額度をどう輪番で使うか
複数のモデル/ツールの額度を賢く組み合わせる方法。
本ページはベンダー横断の一般的な技術解説であり、特定のベンダーの非公開実装について断定するものではありません。実際の挙動は使用するモデルとクライアントのドキュメントに従います。