【AgentOps・キャパシティ運用編】”動くのに、混むと止まる”を越える——エージェントのレート制限・クォータ・同時実行の運用規律｜提供元のTPM/RPM上限をエージェント間でどう配分するか、429ストームとリトライの増幅、優先度つきキューイング、ピーク予測、提供元をまたぐフェイルオーバーで”成功率が負荷に比例して落ちる”を防ぐキャパシティ設計

PromptOps編（”指示資産”）、ナレッジ運用編（”参照資産”）、ツール運用編（”能力資産”）、そしてモデル運用編（”頭脳”）と、エージェントを構成する資産の運用を一通り扱ってきた。だが本番で起きる障害の多くは、資産そのものの不具合ではない。「昨日までは動いていたのに、利用が増えた今日は止まる」——流量の問題だ。

エージェントは、1つのタスクをこなすために何十回もLLMを呼ぶ。計画し、ツールを呼び、結果を読み、また考える。人間がチャット画面で1往復するのとは桁が違う。そのため、PoCでは見えなかった提供元のレート制限（RPM/TPM）に、本番ではあっという間に当たる。そして429エラーが返ると、SDK・フレームワーク・エージェント自身がそれぞれリトライを始め、混雑がさらに混雑を呼ぶ。

これはネットワーク運用でいう輻輳（ふくそう）とQoSの問題と同じ構図だ。回線が細いこと自体より、「誰の通信を先に通すか」「再送が再送を呼ぶのをどう止めるか」が決まっていないことのほうが致命的になる。本稿では、提供元のクォータを共有の帯域とみなし、配分・キューイング・リトライ規律・ピーク予測・フェイルオーバーの5つで「成功率が負荷に比例して落ちる」状態を防ぐ運用設計を整理する。

本稿の位置づけ——”資産”の次は”流量”
なぜエージェントは”混むと止まる”のか
429ストーム——リトライが輻輳を増幅する仕組み
クォータ配分——共有の”帯域”をエージェント間でどう分けるか
優先度つきキューイング——”全部を遅く”ではなく”大事なものを先に”
ピーク予測——”混む日”は事前にわかる
提供元をまたぐフェイルオーバー
観測——流量ダッシュボードに載せる指標
キャパシティ運用チェックリスト
よくある質問（Q&A）
まとめ——流量も”運用対象”として設計する
関連記事
参考リンク

本稿の位置づけ——”資産”の次は”流量”

本稿は「上限」を扱うが、これまでの記事が扱ってきた上限とは対象が違う。混同しやすいので、先に線を引いておく。

記事	扱ったもの	本稿との違い
AgentOps④・コスト（8/25）	お金の上限（予算・単価・キャッシュ）	本稿は処理量（スループット）の上限。予算が余っていても、1分あたりの枠を超えれば止まる
財布枯渇攻撃対策（8/15）	悪意ある大量消費への防御	本稿は正当な利用で起きる混雑の運用。攻撃者がいなくても起きる
AgentOps・フリート編（9/11）	エージェント群の台数・設定・所有者の管理	本稿は群れが共有するクォータの配分。台数が増えるほど取り合いが起きる
連載⑫ AIレジリエンス（7/14）	AIが止まったときの業務側の代替手段	本稿は技術側の流量制御。そもそも止まりにくくする

なぜエージェントは”混むと止まる”のか

1タスク＝数十コール——チャットとは桁が違う

人間向けのチャットボットなら、1回の質問は1〜2回のLLM呼び出しで済む。一方エージェントは、計画→ツール選択→ツール結果の解釈→再計画→最終回答、というループを回す。サブエージェントを並列に起動する構成なら、1タスクで数十〜100回を超える呼び出しも珍しくない。しかも毎回、会話履歴やツール結果を含む長いコンテキストを送るため、トークン消費も呼び出し回数以上に膨らむ。

つまり「同時に使う人が10人」でも、提供元から見れば数百の同時リクエストに相当しうる。PoCで1人ずつ試していたときに見えなかった上限が、本番の朝9時に一斉に見えてくるのはこのためだ。

上限は1種類ではない

「レート制限」と一口に言っても、提供元は複数の軸で上限をかけている。どれか1つに当たれば止まるので、すべてを把握しておく必要がある。

上限の種類	中身	エージェントで当たりやすい場面
RPM（Requests Per Minute）	1分あたりのリクエスト数	短い呼び出しを大量に繰り返すツールループ、並列サブエージェント
TPM（Tokens Per Minute）	1分あたりのトークン数。提供元によっては入力・出力を別枠で管理	長い会話履歴・大きなツール結果を毎回送る構成
同時実行数	同時に処理中にできるリクエスト数	ストリーミング応答や長考型モデルで1リクエストが長時間占有される場合
日次・月次クォータ	一定期間の総量上限	バッチ処理や再インデックスで短期間に集中消費した場合
提供元側の過負荷	契約上の枠とは別に、提供元全体が混雑して一時的に拒否・遅延	新モデル公開直後、特定リージョンの障害時

もう1つ見落とされやすいのが、上限がどの単位にかかっているかだ。多くの提供元では、上限は組織・プロジェクト・APIキーなどの単位で共有される。社内の別チームが同じ組織アカウントで大量のバッチを流せば、自分たちのエージェントが巻き添えで止まる。

“成功率が負荷に比例して落ちる”カーブ

流量の設計がないシステムでは、負荷が上限に近づくと次のような経過をたどる。

負荷が上限の手前まで上がる。まだ成功率は高い
一部のリクエストが429で拒否される
拒否されたリクエストが一斉にリトライされ、実際の送信量は元の負荷より増える
さらに多くのリクエストが拒否され、タスクの途中で失敗するものが出る
失敗したタスクが最初からやり直され、負荷がさらに増える

結果として、負荷が上限を少し超えただけで成功率が急落する。「混むと遅くなる」ならまだよいが、「混むと止まる」になるのは、リトライと再実行が負荷を増幅しているからだ。

429ストーム——リトライが輻輳を増幅する仕組み

リトライは”掛け算”で増える

エージェントのスタックには、リトライする層がいくつも重なっている。たとえば次のような構成は珍しくない。

提供元SDKが既定で2回リトライする（最大3回送信）
その上のエージェントフレームワークが、LLM呼び出しの失敗を3回リトライする（最大4回）
さらにエージェント自身が「ツール実行に失敗した」と判断して、ステップを3回やり直す（最大4回）

この場合、元の1回の呼び出しが最悪で3×4×4＝48回の送信に化ける。各層の開発者は「念のため数回リトライするだけ」と考えているが、重なると混雑時に負荷を数十倍に増幅する装置になる。

ネットワーク運用でいう”再送の同期”

もう1つの問題は、リトライのタイミングがそろうことだ。多数のエージェントが同じ瞬間に429を受け取り、同じ待ち時間（たとえば固定の1秒）でリトライすれば、1秒後にまた同時に殺到して、また同時に拒否される。TCPの輻輳制御で知られる「グローバル同期」と同じ現象で、回線ならパケットロスと再送の波、LLMなら429の波が周期的に繰り返される。

対策の基本は、待ち時間を指数的に伸ばし（エクスポネンシャルバックオフ）、さらにランダムなゆらぎ（ジッター）を加えてタイミングをばらけさせることだ。

リトライ規律の5原則

原則	中身	効果
① Retry-Afterを尊重する	提供元が429応答や応答ヘッダーで「いつ再試行してよいか」を返している場合は、それより早く送らない	提供元の回復を邪魔しない
② 指数バックオフ＋ジッター	待ち時間を倍々に伸ばし、ランダム幅を持たせる。上限時間も決める	再送の同期を崩す
③ リトライは1層だけ	SDK・フレームワーク・エージェントのうち、リトライする層を1つに決め、他は無効化するか即座に上へ返す	掛け算の増幅を止める
④ リトライ予算	全リクエストに占めるリトライの割合に上限（例：10％）を設け、超えたら新たなリトライをせず失敗として扱う	混雑時に再送が本来の流量を食いつぶすのを防ぐ
⑤ サーキットブレーカー	一定時間内の失敗率が閾値を超えたら、その提供元・モデルへの送信を一時停止し、一定時間後に少量だけ試す	壊れている先に送り続けない。フェイルオーバーの起点にもなる

特に③と④は、個々の開発者の善意では守られない。LLM呼び出しは必ず共通のゲートウェイ（またはラッパー）を経由させ、そこでリトライ方針を一元管理するのが現実的だ。エージェントのコードからSDKを直接呼べる状態を放置すると、どこかで誰かが独自のリトライを足してしまう。

クォータ配分——共有の”帯域”をエージェント間でどう分けるか

429を”受けてから”ではなく”送る前に”制御する

429は、上限を超えたことを事後に知らせる信号にすぎない。流量の設計ができている組織は、送る前に自分で数えている。代表的な手法がトークンバケットだ。バケットに一定速度で「送信してよい量」が補充され、リクエストは送る前にそこから必要量を取り出す。足りなければ、送らずにキューで待つ。

ここで重要なのは、リクエスト数だけでなくトークン数も事前に見積もって差し引くことだ。入力トークンは送信前に概算でき、出力トークンは最大出力長（max_tokens）の設定値で上限を見積もれる。応答後に実際の消費量で精算すれば、見積もりの誤差は吸収できる。提供元の多くは残り枠を応答ヘッダーで返しているので、それを使って自分の数え方を定期的に補正するとよい。

配分モデルは3種類

複数のエージェントやチームで1つのクォータを共有するとき、配分の方式は大きく3つある。

方式	仕組み	向いている場面／弱点
早い者勝ち	配分なし。先に送ったものが通る	エージェントが1〜2体の小規模時のみ。1体の暴走や大量バッチが全体を止める
固定割当	エージェント（またはチーム）ごとに上限を固定で割り振る	影響範囲は閉じ込められるが、空いている枠を他が使えず、全体の利用効率が落ちる
保証＋借用	各エージェントに最低保証枠を割り当て、全体に空きがあるときだけ保証枠を超えて借用できる。混雑時は借用分から削る	本番運用の推奨形。ネットワークQoSのCIR（保証帯域）とEIR（超過帯域）と同じ考え方

保証＋借用方式では、保証枠の合計を提供元の上限の7〜8割程度に抑え、残りを借用用の余白とすることが多い。保証枠の合計が上限を超える「オーバーブッキング」を認めるかどうかは、各エージェントのピークがどれだけ重なるかで判断する。

キーとプロジェクトを分けて”影響範囲”を切る

ゲートウェイで配分しても、同じ組織アカウントを社内の別システムが直接使っていれば意味がない。提供元が組織内でプロジェクトやワークスペース単位の上限設定を用意している場合は、本番の対話系・バッチ系・開発検証系を別の単位に分け、それぞれに上限を設定しておく。開発者の実験が本番を巻き添えにする事故は、これだけでかなり防げる。

優先度つきキューイング——”全部を遅く”ではなく”大事なものを先に”

リクエストをクラスに分ける

混雑時にすべてのリクエストを平等に遅らせると、人が画面の前で待っている対話も、夜までに終わればよいバッチも、同じように遅くなる。ネットワークで音声パケットを優先キュー（LLQ）に入れるのと同じく、LLM呼び出しにもクラスを設ける。

クラス	例	混雑時の扱い
P0：対話	顧客・社員が応答を待っているエージェント	最優先。待ち時間の上限（例：数秒）を超えたらデグレード応答
P1：締め切りつき業務	当日中に終える必要がある処理、承認フロー	P0の次。締め切りから逆算して順番を上げる
P2：バックグラウンド	評価の自動実行、要約の事前生成、埋め込みの再計算	空き枠でのみ実行。混雑時は停止して後回し
P3：実験・検証	開発者の試行、新プロンプトの比較	本番の枠を使わない。別プロジェクトに隔離

ただし、厳密な優先度だけで回すと、混雑が続いたときにP2以下が永久に実行されない（飢餓状態）。重みつき公平キューイング（WFQ）の考え方で、下位クラスにも一定割合の枠を残しておくとよい。

タスク単位の”入場制限”

エージェント特有の注意点がある。最悪なのは、タスクが途中で止まることだ。10ステップのうち6ステップ目で枠が尽きると、それまでに消費したトークンは無駄になり、しかも途中までの副作用（チケット起票、メール下書き、DB更新など）が中途半端に残る。

そこで、個々のLLM呼び出しではなくタスクの開始時点で入場制限（アドミッション制御）をかける。そのタスクを最後まで完了できる見込みの枠がなければ、そもそも開始しない。開始したタスクは、後から来た新規タスクより優先して枠を配る。「始めたら終わらせる、終わらせられないなら始めない」が原則だ。

ロードシェディングとデグレード

それでも需要が上限を超える時間帯はある。そのとき、すべてを受け付けて全部を遅くするより、一部をはっきり断る（ロードシェディング）か、品質を落として応答する（デグレード）ほうが、全体の成功率は高くなる。

軽量なモデルに切り替えて応答する（評価ゲートを通過した代替モデルに限る）
コンテキストを短縮する、ツール呼び出しの回数上限を下げる
即時応答をあきらめ、「受け付けました。完了したら通知します」と非同期に切り替える
P2以下のバックグラウンド処理を一時停止する

どの順番で何を落とすかは、混雑してから考えても間に合わない。デグレードの段階と発動条件を事前にランブックに書いておくことが重要だ。

ピーク予測——”混む日”は事前にわかる

必要な流量を見積もる

キャパシティ計画の出発点は、ピーク時に必要な流量の見積もりだ。定常状態では、次の式でおおよその値が出る。

必要RPM ≒ ピーク時の新規タスク数／分 × 1タスクあたりの平均呼び出し回数
必要TPM ≒ 必要RPM × 1呼び出しあたりの平均トークン数

たとえば、ピーク時に1分あたり20件のタスクが始まり、1タスクで平均25回LLMを呼び、1回あたり平均3,000トークンを使うなら、必要RPMは500、必要TPMは150万になる。ここに前述のリトライ分を上乗せする。1タスクあたりの呼び出し回数とトークン数は、平均だけでなく上位パーセンタイル（p95など）も必ず見る。エージェントは入力次第でループ回数が大きくぶれるため、平均で見積もると足りなくなる。

使用率の目標は”7割”

ネットワーク回線と同じく、LLMのクォータも100％まで使い切る設計にしてはいけない。瞬間的な山は分単位の平均より高く、上限に近づくほど429と待ち時間が急増する。ピーク時の使用率目標は上限の60〜70％程度に置き、それを超える見込みが出た時点で手を打つ。

打ち手は主に3つある。

上限緩和の申請：提供元の利用階層（ティア）の引き上げや個別の上限緩和は、承認までに日数がかかることがある。ピークの直前ではなく、数週間前に動く
予約型スループット：クラウド経由の提供形態では、一定の処理能力を事前に確保する予約枠（プロビジョンド型）を選べる場合がある。コストは上がるが、混雑時の予測可能性を買える
需要側の削減：キャッシュ、コンテキスト圧縮、バッチAPIへの振り替えなど。コスト編④の施策は、そのまま流量の削減にも効く

“混む日”カレンダーをつくる

ピークの種類	例	事前の打ち手
業務の周期	月末・期末の締め、月曜朝、始業直後	P2処理を前日夜に前倒し、保証枠の一時的な組み替え
自社イベント	キャンペーン、新機能リリース、全社展開の開始日	上限緩和申請、段階的な展開で流入を平準化
外部要因	提供元の新モデル公開直後、大きなニュースの直後	提供元側の混雑を想定し、フェイルオーバー先の枠を確認
内部の一括処理	ナレッジの全件再インデックス、評価セットの全件再実行	本番のピークと重ならない時間帯に予約、別プロジェクトで実行

提供元をまたぐフェイルオーバー

前提——”同じ答え”は返らない

提供元の障害や過負荷に備えて、別の提供元・別のモデルへ切り替える経路を用意しておくのは有効だ。ただし、モデルが変われば出力の傾向も、ツール呼び出しの形式への従い方も変わる。モデル運用編で扱ったとおり、評価ゲートを通過していない代替モデルへ自動で切り替えるのは、障害を別の障害に置き換えるだけになりかねない。フェイルオーバー先は、主系と同じゴールデンセットで評価済みのモデルに限定し、プロンプトもそのモデル用に調整したものを組にしておく。

切替と戻しの条件を先に決める

状態	判定の例	動作
正常	429率・エラー率・待ち時間が平常範囲	主系のみを使用
劣化	429率が数分間閾値を超える、p95待ち時間が上限を超える	P2以下を停止。P1の一部を副系へ振り分け
障害	サーキットブレーカーが開く、提供元のステータスで障害発表	P0・P1を副系へ切替。デグレード段階を発動
回復	主系への少量の試行が一定時間連続で成功	段階的に主系へ戻す（一気に戻さない）

「戻し」の条件を決めていない組織は多い。主系が回復した瞬間に全量を戻すと、溜まっていたリクエストが一斉に流れ込み、回復直後の主系をまた止めてしまう。戻すときも段階的に、が原則だ。

副系を”満杯”にしない

フェイルオーバーでよくある失敗は、副系の枠が主系よりずっと小さいことだ。普段ほとんど使わない副系は、利用階層が低く上限も低いままになっていることが多い。そこに主系の全流量を流せば、副系も即座に429を返し始める。副系の上限は定期的に確認し、切替時には優先度の高いクラスだけを流す設計にしておく。

また、提供元を変えるとデータの保存場所や利用規約、学習への利用可否などの条件も変わる。フェイルオーバー先も、主系と同じ審査（データ所在地・契約条件）を通しておくこと。障害時に慌てて規約違反の経路へ流すことがないよう、事前承認済みの経路だけを切替候補に登録しておく。

観測——流量ダッシュボードに載せる指標

流量の問題は、エラーが出てから気づいても遅い。上限に近づいている兆候を、平常時から見える場所に出しておく。

指標	見る理由	アラートの目安（例）
クォータ使用率（RPM/TPM別）	上限までの余裕を把握する	ピーク時に70％超が続く
429率	上限到達の直接的なシグナル	数分間で1％超
リトライ率・リトライ予算の消費	増幅が始まっていないかを見る	リトライ予算の50％超
クラス別のキュー待ち時間	優先度制御が効いているかを見る	P0のp95が上限の半分を超える
タスク完了率と負荷の関係	“負荷に比例して落ちる”カーブの兆候	負荷上昇時に完了率が低下し始める
途中失敗タスク数	アドミッション制御の漏れを見る	ゼロ以外は原因調査
フェイルオーバー・デグレードの発動回数	キャパシティ不足の頻度を見る	月次で増加傾向なら上限の見直し

キャパシティ運用チェックリスト

領域	チェック項目
把握	利用している提供元・モデルごとに、RPM・TPM・同時実行数・日次上限と、上限がかかる単位（組織／プロジェクト／キー）を一覧にしている
把握	1タスクあたりの呼び出し回数とトークン数を、平均とp95で計測している
リトライ	リトライする層を1つに決め、SDKやフレームワークの既定リトライを確認・調整している
リトライ	Retry-Afterの尊重、指数バックオフ＋ジッター、リトライ予算を実装している
リトライ	サーキットブレーカーを設け、開閉の条件を文書化している
配分	LLM呼び出しは共通ゲートウェイを経由し、送信前にトークンバケットで流量を制御している
配分	エージェント（チーム）ごとの保証枠と借用ルールを決めている
配分	本番対話・バッチ・開発検証を別のプロジェクト／キーに分け、それぞれ上限を設定している
優先度	リクエストをクラス分けし、下位クラスにも最低限の枠を残している
優先度	タスク開始時のアドミッション制御で、途中失敗を防いでいる
優先度	デグレードの段階と発動条件をランブックに記載している
予測	ピーク時の使用率目標（60〜70％）を定め、”混む日”カレンダーを運用している
予測	上限緩和申請のリードタイムを把握し、ピークの数週間前に動いている
フェイルオーバー	副系は評価ゲート通過済みのモデル＋専用プロンプトの組で、データ所在地・契約の審査も済んでいる
フェイルオーバー	切替・戻しの条件を定め、副系の上限を定期的に確認している
観測	使用率・429率・リトライ率・クラス別待ち時間・途中失敗数をダッシュボード化している

よくある質問（Q&A）

Q1. 提供元に上限を引き上げてもらえば、この運用は不要ではないですか？

上限の引き上げは有効な打ち手の1つだが、それだけでは解決しない。上限が2倍になっても、リトライの増幅が30倍なら結局は止まる。また、エージェントの数や利用者は増え続けるので、いずれ新しい上限にも当たる。上限は「広げる」ものであると同時に、「その中でどう使うか」を設計するものだと考えたい。

Q2. SDKにリトライ機能が組み込まれているので、それを使えば十分ではないですか？

単体のSDKのリトライは、多くの場合バックオフも実装されていて妥当なつくりだ。問題は、その上にフレームワークやエージェント自身のやり直しが重なることにある。SDKのリトライを使うなら、上位層ではリトライしない。逆に上位層で一元管理するなら、SDKのリトライ回数を0にする。どちらかに寄せることが重要だ。

Q3. コスト編④の予算上限と、本稿のクォータ配分は何が違うのですか？

コスト編の予算上限は「今月いくらまで使ってよいか」という総量の管理で、本稿のクォータ配分は「この1分間にどれだけ流せるか」という速度の管理だ。予算が十分に余っていても、朝9時の1分間に集中すれば止まる。両者は同じゲートウェイで実装できるが、設計の目的と指標は別物として扱う。

Q4. 小規模なチームでエージェントも数体です。どこから始めればよいですか？

まずは3つだけでよい。①リトライする層を1つに絞り、バックオフとジッターを入れる。②本番と開発検証のAPIキー（プロジェクト）を分ける。③429率とクォータ使用率をダッシュボードに出す。優先度キューやフェイルオーバーは、エージェントの数や利用者が増えて、この3つの指標に兆候が出てから足しても間に合う。

Q5. ローカルLLMやオープンウェイトのモデルを自社で動かす場合も、同じ考え方が必要ですか？

必要だ。外部の提供元のレート制限はなくなるが、代わりに自社のGPUの処理能力が上限になる。同時実行数を超えれば待ち行列が伸び、タイムアウトとリトライの増幅が同じように起きる。むしろ、上限を超えたときに429で丁寧に断ってくれる仕組みがない分、自分でアドミッション制御とキューイングを組む必要がある。

まとめ——流量も”運用対象”として設計する

エージェントが本番で止まる原因は、指示や知識や道具やモデルの不具合だけではない。1タスクで何十回もLLMを呼ぶエージェントにとって、提供元のクォータは群れ全体で共有する帯域であり、配分と制御の規律がなければ、利用が増えた日に”混むと止まる”状態に陥る。

リトライを規律で縛る：リトライする層を1つに絞り、Retry-Afterの尊重・指数バックオフ＋ジッター・リトライ予算・サーキットブレーカーで、429ストームの増幅を止める
送る前に配分する：共通ゲートウェイでトークンバケットを回し、保証＋借用の枠と優先度つきキュー、タスク単位のアドミッション制御で、”大事なものを先に、始めたら終わらせる”を実現する
ピークに先回りする：必要流量をp95で見積もり、使用率70％を目安に上限緩和・予約枠・需要削減を前倒しで打ち、評価済みの副系へのフェイルオーバーと段階的な戻しを事前に決めておく

資産の運用が「何を動かすか」の規律なら、流量の運用は「どれだけ、どの順番で動かすか」の規律だ。成功率が負荷に比例して落ちるシステムから、負荷が増えても”大事なものは通る”システムへ。ネットワーク運用が長年かけて磨いてきたQoSの考え方は、エージェントの時代にもそのまま使える。