LLM APIの高額請求を防ぐ｜rate limit・spend limit・tool予算を分ける【2026】

生成AIの利用制御を「一分に何回まで」にしても、高額請求や可用性低下を十分には防げません。短い要求を大量に送る濫用と、長い入力・高価なモデル・何段もtoolを呼ぶエージェントは、同じrequest数でも消費する資源が大きく異なるためです。

結論は、入口のrequest数、モデル推論の実費、エージェントが起こすtool実行を別の予算として制御することです。Cloudflare AI Gatewayのrate limitとspend limitはモデル呼出しの入口を守る手段になりますが、それだけで検索回数、ファイル処理、外部送信、キューに積んだ後続jobまで制御できるわけではありません。利用者・テナント・操作単位の境界を先に決めます。

request数だけでは、LLMの消費を測れない

OWASPは、過剰かつ制御されない推論がDoS、経済的損失、model theft、サービス低下を生む「Unbounded Consumption」として整理しています。大きいcontext、長い出力、複数回のretry、agent loopは、少ない画面操作でも高い消費になり得ます。反対に、同じ利用者が短い問い合わせを複数回行うことまで一律に止めれば、正当な業務を妨げます。

制御対象を一つの数値に畳まないことが出発点です。最低限、次の三層を分けます。

1. request予算：短時間に入口へ到達できる回数。botや偶発的な再送から可用性を守ります。
2. spend予算：モデル・provider・token使用量から推定される金額。高価なモデルや長い入出力による請求を抑えます。
3. action予算：一つのエージェント実行で許す検索、取得、書込み、外部送信、後続jobの回数。model呼出し後の暴走を抑えます。

rate limitは入口の混雑を、spend limitは実費の偏りを抑える

Cloudflare AI Gatewayのrate limitingは、一定時間内にgatewayへ送れるrequest数を制御します。固定windowとsliding windowを選べ、上限超過時は429 Too Many Requestsで要求を処理しません。急な連打や認証前の濫用を抑えるには有効です。

ただしrate limitは、同じ回数のrequestが同じコストであることを前提にしません。AI Gatewayのspend limitsはtoken使用量とmodel pricingに基づく累積コストを追い、上限に達すると429でブロックします。model、provider、custom metadataの組み合わせで範囲を分けられるため、全社の一つの総額だけでなく、teamやapplication単位の予算を設計できます。

この二つは代替関係ではありません。入口でのburstを抑えるrate limitと、長文・高価格modelの偏りを抑えるspend limitを重ねます。さらに、AI Gatewayはcostをbest-effort estimationとして扱い、正確な請求額はproviderのdashboardで確認するよう明記しています。gateway表示だけを会計上の正本にせず、請求確定の照合経路を残します。

上限のキーはIPアドレスだけにしない

IPアドレスだけで制限すると、企業ネットワークやプロキシ配下の正当利用者まで同じ枠を取り合います。認証済みの利用者、テナント、アプリケーション、model、操作種別を組み合わせ、どの単位が他者の枠を使ってよいかを決めます。

Cloudflare Accessで保護されたcustom domain経由のAI Gatewayでは、認証済みAccess userのIDがcf.user_id metadataとして付与され、利用者別のspend limitに使えます。Accessを通さない場合はcustom metadataを渡せますが、クライアントが任意のuser_idを名乗れる設計では、予算回避や他者へのなりすましを招きます。利用者・テナント識別子は認証済みのserver側の情報から設定し、料金・権限に使うmetadataを画面入力からそのまま受け取らないことが重要です。

エージェントにはtool予算と停止条件を別に持たせる

AI Gatewayで一回のmodel requestを通しても、その応答が十回の検索や外部更新を選べば、後段の負荷やリスクは残ります。エージェント実行ごとに、最大tool回数、最大並列数、最大wall time、最大取得bytes、最大queue投入数を決めます。上限に達したら、黙ってより安いmodelへ変えたり、操作を継続したりせず、理由を利用者へ返して停止します。

より安いmodelへのfallbackは、要約や候補生成のように品質条件をあらかじめ定めた処理では選択肢になります。しかし契約文書、顧客への外部送信、分類結果で次の操作が変わる処理では、モデル変更が品質と説明責任を変えます。予算超過を理由に同じ操作を別modelで続けるなら、どの操作に許すかを業務側と先に合意します。外部送信や更新には、AIエージェントの承認ゲート設計も別途必要です。

429を失敗ではなく安全な状態として設計する

429を受けたクライアントが即時再試行を繰り返すと、制限そのものを増幅させます。画面では「上限に達した」「いつ再試行できるか」「結果が未作成か」を明示し、同じ操作IDの二重起動を防ぎます。バックグラウンドjobは、上限に達した理由と再開条件を記録して、無条件のretryを避けます。

課金予算は、認可の代わりにもなりません。予算内だから外部送信してよい、という判断は危険です。MCPや外部toolの権限はOAuth認可の設計で狭め、操作の正当性は別の承認・監査経路で確認します。

実装前チェックリスト

• request、spend、tool actionの三つを別の上限として定義したか
• 利用者、テナント、アプリ、modelのどれで予算を分けるか説明できるか
• 料金・権限に使う識別子を、認証済みserver側の情報から付けているか
• 固定windowとsliding windowのどちらがburstを許容する業務に合うか決めたか
• spendの推定値とprovider請求額を照合する担当・周期を決めたか
• 上限時に429を返し、同じ操作を無条件にretryしないか
• tool回数、取得bytes、並列数、queue投入数にも停止条件を置いたか
• fallback modelを許す操作・品質条件・利用者への表示を決めたか

限界：上限は、正当性や品質を保証しない

rate limitとspend limitは消費を制御しますが、prompt injection、誤った権限、情報漏えい、誤答を防ぐものではありません。また、厳しすぎる上限は月末や障害時の正当な利用を止めます。全社一律の小さな数値から始めるより、利用目的ごとに安全に止められる経路を作り、実測した消費と業務影響から見直す方が現実的です。

AI Gatewayのspend limitも、既知価格に基づくbest-effort estimationです。providerの個別契約、割引、税、遅延した利用集計を完全に代替しません。予算アラートと請求照合を残し、「上限を置いたから請求は必ずこの額以下」とは表現しないでください。

MCP・AIエージェントのセキュリティレビュー

AIエージェントの利用上限、モデル選択、外部toolの実行権限を安全に設計したい方は、MCP・AIエージェントのセキュリティレビューをご利用ください。

一次情報と確認範囲

確認日：2026年9月8日。Cloudflare AI Gatewayの機能・制限は変わり得ます。料金、モデル対応、provider請求は導入時に各公式画面と契約条件を再確認してください。

一次情報と確認範囲

確認日：2026年9月8日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。

1. 過剰なLLM推論はDoS、経済的損失、model theft、サービス低下につながり得る
2. rate limitingは時間枠内のrequest数を制御し、固定windowとsliding windowを選べ、超過時は429となる
3. spend limitはtokenとmodel pricingに基づく推定コストを追い、model・provider・metadataで範囲を分けられる
4. Gateway設定・ログ・Unified Billingには製品上の個別制限がある
5. timeout・retry・rate limit・budget limitは同じrequest handlingでも目的が異なり、重ねて設計する
6. AI導入後のmonitoringにはincident response、recovery、change managementを含める