---
title: Azure初心者がAIエージェントのレートリミットに振り回された話
tags: 
author: [Hayato](https://image.docswell.com/user/Hayato)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LEL8Z2ZN7R.jpg?width=480
description: Azure初心者がAIエージェントのレートリミットに振り回された話 by Hayato
published: November 13, 26
canonical: https://image.docswell.com/s/Hayato/Z4NPJG-2026-11-13-232959
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LEL8Z2ZN7R.jpg)

Azure初心者がAIエージェントの
レートリミットに振り回された話
AI エージェント
API Management
トークン制限


# Page. 2

![Page Image](https://bcdn.docswell.com/page/4JM6V8VQEW.jpg)

自己紹介
はやと
Azure初心者がAIエージェントのレートリミットに振り回された話
Azure 歴
1 年目（まだまだ初心者です）
普段の仕事
インフラエンジニア
最近
子どもが生まれて、パパをしています
X
@Mip9L
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/PJRP252KE9.jpg)

きっかけ：社内検証で出てきた「エージェントごとの上限」
議題に上がった要件
よくある構成
エージェント A
1
FAQ 回答
エージェント単位で上限を分けたい
1つの暴走で他のエージェントを止めたくない
モデル
エージェント B
社内検索
デプロイ
2
上限を超えて使わせたくない
コスト・クォータを確実に守りたい
エージェント C
長文 + Web検索
3
Foundry 側は変えずに入れたい
エージェントの定義や実装には手を入れない
C が使いすぎると、A・B も巻き込まれる
A zu re初心者がA Iエージェントのレートリミットに振り回された話
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/PEX3DKD5JX.jpg)

確認①：デプロイしたモデルで制限する（TPM）
検証：gpt-5.4-nano に TPM 1,000 を設定
10,585
単位
モデルのデプロイ単位。使うエージェント全員で共有
期間
1 分あたり（TPM / RPM）
判定
受付時点の残量で判定。消費は応答後に実績で加算
超過時
超えた“次の”リクエストから 429 で拒否
1 回で消費したトークン（上限の約 10 倍）
1 回目
上限を超えても最後まで回答
2 回目
429 rate_limit_exceeded
課題
エージェント単位にできない ／ 1 回分の消費は途中で止まらず大きく超える
Azure初心者がAIエージェントのレートリミットに振り回された話
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/3EKYX5XRJD.jpg)

確認②：Foundry の AI Gateway で制限する
Foundry の管理画面
AI Gateway を追加
プロジェクトに制限を設定
管理 ＞ AI ゲートウェイ
裏側は APIM
TPM 500 ／ クォータ 1,000 / 時
検証：クォータ 1,000 / 時 のプロジェクト
検証で分かったこと
6,431
• ポータルから手軽に設定できる（裏側は APIM）
1 回の応答で消費したトークン。クォータを大きく
超えても止まらなかった
• 消費は応答後に加算。1 回の応答で上限を超えてしまう
A zu re初心者がA Iエージェントのレートリミットに振り回された話
• 設定できる単位はプロジェクト（× モデルのデプロイ）。エ
ージェント単位ではない
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/L7395K5G75.jpg)

3 つの方法を比べると
デプロイの TPM 制限
Foundry AI Gateway
APIM カスタムポリシー（今回）
モデル（デプロイ）
プロジェクト × デプロイ
エージェント
1分
1分／時〜年
任意（今回は 1 時間）
超過の防ぎ方
受付時の残量のみ確認
受付時の残量のみ確認
出力上限を残量内に書き換え
検証での超過
上限 1,000 に 10,585
上限 1,000 に 6,431
超過 0（上限内で停止）
導入の手軽さ
◎
◎
制限の単位
期間
△
ポリシーを記述
※ 手軽さと引き換えに、エージェント単位で「1 回でも超えない」厳密さを取りに行ったのが今回の方法
Azure初心者がAIエージェントのレートリミットに振り回された話
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/87DGD3DN7G.jpg)

仕組み：出力上限を「残り − 予測入力」に書き換える
リクエスト受信時（APIM）
送信時
モデル
応答時
①
②
③
④
⑤
⑥
残りを調べる
入力を予測
不足なら拒否
上限を書き換え
上限で停止
実績で更新
エージェントごとの
残り
前回の実績 × 1.1
モデルに送らず 403
max_output_tokens
モデル側が
生成を止める
usage を即時記録
出力上限 ＝ 残り − 予測入力
→
入力 ＋ 出力 ≦ 残り
プロンプトエージェントを本文の agent_reference.name で識別。判定はすべて APIM の中で完結し、Foundry 側の設定は変えない
A zu re初心者がA Iエージェントのレートリミットに振り回された話
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/VJP3X4XNE8.jpg)

どこが実績値で、どこが予測値か
実績値
実績値
予測値
出力トークン
消費後の残り
入力トークン
モデル側が生成中に数え、
上限に達した時点で止まる
応答の usage で即時に更新
（実際の入力＋出力）
前回の実際の入力 × 1.1
で見積もる（初回は設定値）
max_output_tokens の働き
APIM が後から切っているのではない
llm-token-limit の反映遅れもすり抜
けない
入力はモデルが最初にまとめて読むた
め途中で止められない
ポイント
予測するのは入力だけ。しかも“前回の実績”なので、誤差は入力の差分に限られる
Azure初心者がAIエージェントのレートリミットに振り回された話
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/2EV4LXLYJQ.jpg)

検証①：出力上限ぴったりで生成が止まる
test-agent（クォータ 12,000 / 時）に同じ長文の質問を 4 回送信
トークン消費（入力＋出力）
1,371 ＝ 1,371
APIM が書き換えた
出力上限
6,171
5,423
モデルの
実際の出力トークン
1 回目（最後まで回答）
出力上限の計算
残り 5,829 − 予測入力 4,458
#1
#2
2 回目（上限で停止）
#3
残り
#4
status
incomplete
200
200
403
403
reason
max_output_tokens
成功
上限で停止
拒否
拒否
出力 2,119
出力 1,371
消費 0
消費 0
消費後の残り
406（マイナスにならない）
A zu re初心者がA Iエージェントのレートリミットに振り回された話
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/57G1XVXWEL.jpg)

検証②：上限に達したらモデルに送らず拒否
test-agent1（クォータ 200 / 時）に「フランスの首都は？」を 4 回送信
リクエスト #1
リクエスト #2
リクエスト #3
リクエスト #4
200 成功
200 成功
403 拒否
403 拒否
残り 200 → 125
残り 125 → 50
残り 50 のまま
残り 50 のまま
入力 60 ＋ 出力 15
入力 60 ＋ 出力 15
残り 50 ＜ 予測入力 66
以降も拒否が続く
ここがポイント
• 残りが「予測入力 ＋ 最小出力 16」に足りない
時点で拒否
• モデルに届かないので usage なし ＝ 消費 0
• 事後加算の方式では通ってしまう“上限超えの 1
回”を止められる
Azure初心者がAIエージェントのレートリミットに振り回された話
HTTP/1.1 403 Agent Token Quota Reached
x-agent-token-quota: 200
x-remaining-before-tokens: 50
x-predicted-input-tokens: 66
x-tokens-consumed: 0
{"error": {"code": "AgentTokenQuotaReached", ...}}
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/4EQD868QJP.jpg)

結果：どのエージェントもクォータを超えなかった
クォータに対する消費トークン（入力＋出力）
test-agent
超過 0 件
11,594
3 エージェント・全 12 リクエスト
test-agent1
test-agent2
150
50
8,182
消費
未使用
A zu re初心者がA Iエージェントのレートリミットに振り回された話
1,818
test-agent
11,594 / 12,000
test-agent1
150 / 200
test-agent2
8,182 / 10,000
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/KJ4Z242Y71.jpg)

制約と注意点
!
入力の予測ずれ分は超過しうる
!
web_search の結果などは実行するまで分からな
い。倍率 1.1 を上げれば安全側（ただし早めに止
まる）
!
ストリーミングは即時更新なし
usage を記録できないため、llm-token-limit 側の
推定値による集計のみになる
Azure初心者がAIエージェントのレートリミットに振り回された話
推論トークンも出力上限に含まれる
上限が小さいと推論だけで上限に達し、回答本文
が空になることがある
!
カウンターはゲートウェイ単位
複数リージョン・複数ユニットに広げると厳密さ
が下がる。同じエージェントの同時実行は 1 件に
制限
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/LE1RM4MNEG.jpg)

まとめ
1
エージェント単位で制限できる
agent_reference.name で識別し、Foundry 側は変更なし
2
実績値でピッタリ止められる
出力上限を「残り − 予測入力」に書き換え、モデル側が上限で止まる
3
足りなければ送らない
最後の 1 回もモデルに届かず 403、消費 0
使い分け
全体の流量 → デプロイの TPM ／ プロジェクト単位 → AI Gateway ／ エージェント単位 → APIM ポリシー
A zu re初心者がA Iエージェントのレートリミットに振り回された話
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/GEW13XDM72.jpg)

ご清聴ありがとうございました