Azure AI FoundryでGPT‑5の20k TPM上限を突破する方法｜増枠申請とProvisioned Throughput完全ガイド

Azure AI Foundry で GPT‑5 を使い始めると、最初に壁になるのが「20k TPM 上限」です。長文プロンプトが一度に通らない、チームで同時利用できない、増枠申請の待ち時間が長い――。この記事では、実務で直面する失敗パターンを体系化し、短期の応急処置から長期の恒久対策（Provisioned Throughput／専有 RU）まで、意思決定に直結する手順・計算式・テンプレートをまとめます。

GPT‑5「20k TPM 上限」問題の全体像

TPM（Tokens Per Minute）はモデルに対する分あたりの合計トークン処理量を示す制限です。Azure AI Foundry ではデフォルトで 20,000 トークン／分の上限が適用されることがあり、入力（prompt）と出力（completion）の合算がこの枠内に収まらないと、429（rate limit）や 503（capacity）などのエラーが発生します。特に GPT‑5 は長文プロンプト＋長文出力というユースケースが多く、上限を一瞬で使い切ることも珍しくありません。

よくある失敗パターン

数十 k トークン級の「長文プロンプト」を 1 回送っただけで上限を超えて失敗。
PoC では問題なかったが、本番で同時アクセスが集中しリトライ地獄に陥る。
増枠申請の審査が長期化し、開発・導入スケジュールが止まる。

主な課題と現場の困りごと

課題	具体的な困りごと
デフォルト上限が低すぎる	1 人でも使い切る・チームで共有できない
増枠申請が遅い	審査に時間がかかりリリースが遅延
信頼性の不足	本番でリトライが頻発し、開発も停滞

どれだけ足りないのかを数式で把握する

感覚ではなく トークン予算表でボトルネックを可視化します。最低限、以下の式で見積もります。

必要TPM = (平均入力トークン + 平均出力トークン) × 1分あたりリクエスト数 × 同時実行倍率 × バッファ係数

同時実行倍率：瞬間的な集中（平常時 1.0～2.0、イベント時 3.0 以上）
バッファ係数：予備枠（1.2～2.0 を推奨）

サンプル計算

社内 500 人が 1 分あたり 2 回操作、平均 1,500 トークン（入出合算）、同時実行倍率 1.5、バッファ 1.3 の場合：

必要TPM = 1,500 × (500×2/60) × 1.5 × 1.3
         ≒ 1,500 × 16.7 × 1.5 × 1.3
         ≒ 48,800 TPM

デフォルトの 20k TPM を大きく超過します。チーム・部門・全社の各レイヤで予算表を作り、段階的に拡張計画を設計しましょう。

ユースケース別の目安（例）

ユースケース	平均入出力トークン	1 分あたりリクエスト	推奨 TPM 目安	備考
チャット型ヘルプデスク	1,200	200	~ 312k	ピーク同時実行 2.0、バッファ 1.3
コード補完（CI統合）	800	500	~ 520k	短スパン高頻度・スパイク強
ドキュメント要約（バッチ）	2,500	50	~ 163k	夜間バッチなら PT で低コスト化

短期対策：クォータ増枠申請の実務

新規導入・検証段階では、まずクォータ増枠申請でボトルネックを緩和します。審査は「利用実績」と「業務重要度」の説明が鍵です。

準備する情報

項目	内容例
組織メール	[email protected]
サブスクリプション ID	xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
希望 TPM	300k / 1M など根拠付きで提示
利用実績	現行枠の 80% 以上を継続消費、ピーク値、失敗率など
業務影響	社内サポートの SLA、顧客向け機能のリリース計画
技術対策	レート制御、リトライ、バッチ化、監視ダッシュボード

申請テンプレート（日本語）

件名：GPT‑5 利用に伴う TPM 増枠申請（サブスクリプション：<ID>）

目的：
・社内 1,000 名向けヘルプデスクと開発者支援に GPT‑5 を利用
・現在の 20k TPM では長文プロンプトやピーク時に失敗が頻発

現状：
・直近 7 日の平均消費 18k TPM、ピーク 25k TPM（429/503 の発生）
・リトライ実装済み、失敗率 7.3% → SLA 未達

要請：
・希望 TPM：300k（根拠：必要TPM算定式、ピーク 230k + バッファ 1.3）
・対象リージョン：<利用リージョン>

補足：
・プロンプト削減、バッチ化、監視を実施済み
・将来的に Provisioned Throughput の検討あり（見積り進行中）

「通りやすくなる」添付資料の作り方

メトリクス：TPM 使用率の時系列、失敗率、P95/P99 レイテンシ。
アーキ図：レートリミッタ、ジョブキュー、キャッシュの配置。
ビジネス理由：SLA、法令／社内監査、顧客影響の具体化。

実装の即効薬：バックオフ＆キューイング

レート制御は「全体 TPM を守る」「失敗を顧客から隠す」の二段構えが有効です。

Python（トークンベースの滑らかなレート制御例）

import time
from collections import deque

class TokenBucket:
def **init**(self, capacity_tpm, refill_interval=60):
self.capacity = capacity_tpm
self.tokens = capacity_tpm
self.queue = deque()
self.refill_interval = refill_interval
self.last_refill = time.time()
def _refill(self):
    now = time.time()
    elapsed = now - self.last_refill
    if elapsed &gt;= self.refill_interval:
        self.tokens = self.capacity
        self.last_refill = now

def acquire(self, cost):
    self._refill()
    if cost &lt;= self.tokens:
        self.tokens -= cost
        return True
    return False

bucket = TokenBucket(capacity_tpm=20000)

def call_with_retry(cost_tokens, func, max_retry=5):
backoff = 0.5
for i in range(max_retry):
if bucket.acquire(cost_tokens):
return func()
time.sleep(backoff)
backoff = min(backoff * 2, 8.0)
raise RuntimeError("Rate limit exceeded")

Node.js（指数バックオフ＋ジッター）

async function retryWithBackoff(fn, {maxRetry = 5, base = 300} = {}) {
  for (let i = 0; i &lt; maxRetry; i++) {
    try { return await fn(); }
    catch (e) {
      const jitter = Math.random() * base;
      await new Promise(r =&gt; setTimeout(r, base * (2 ** i) + jitter));
    }
  }
  throw new Error("Rate limit exceeded");
}

「どれだけ待つか」は 推定トークン消費 と 残り枠 を入力に決めます。推定コストの付与は 入出力トークンの平均値×係数（1.2〜1.5） を使うと安全側になります。

長期対策：Provisioned Throughput（専有 RU）に移行する

Provisioned Throughput（PT）は、事前に専有の計算資源（Request Units）を時間単位で確保する仕組みです。混雑の影響を受けづらく、性能が安定し、必要時に即時スケールできます。

PT のメリット

安定性：ピーク時でも一定のスループットを担保。
即時スケール：時間帯によって RU を増減し、コスト最適化。
大規模枠：1M～10M TPM といったオーダーを専有で確保しやすい。

コスト試算フレーム

価格は時点・契約により変動するため、以下の「式」で比較検討します。

PT 総コスト ≒ RU 単価 × RU 数 × 稼働時間（h） + α（ネットワーク/ログ等）
オンデマンド総コスト ≒ リクエスト課金 + 失敗/リトライの隠れコスト
TCO 差分 ≒ 失敗率低下による SLA 達成 × ペナルティ/機会損失の回避

移行判断の基準

ピーク時の必要 TPM が 300k～1M を超え、継続的に発生している。
SLA/OLAs に「応答遅延・失敗率」の数値目標があり、現状未達。
夜間/繁忙期など時間帯で需要が偏り、スケジュールスケールで最適化できる。

移行ステップ

現行トラフィックを 1 か月計測し、ピーク・バースト・平均を分離。
PT の最小 RU と段階を決め、スケールスケジュール（例：業務時間帯のみ増枠）を設計。
本番と同等の負荷でカナリアリリースを実施し、SLO を検証。
段階的に 4o/4.1/o3 等の補助モデルから GPT‑5 へトラフィックを寄せ替え。

契約プラン別の目安

プラン	デフォルト上限	増枠後の目安	備考
Free / Pay‑As‑You‑Go	20k TPM	申請で数十～数百 k	新規顧客・決済状況によって制限が厳格
EA / CSP（企業契約）	数十 k TPM	最大 1M TPM	GPT‑5 の優先割当がある場合も
Provisioned Throughput	契約 RU に応じる	1M～10M TPM	時間課金・安定性能

運用ベストプラクティス（すぐ効く 8 つ）

プロンプトの簡潔化：不要な説明・重複を削除、参照テキストはチャンク化。
バッチ化：まとめ送信でオーバーヘッドを削減（ただし出力上限に注意）。
キャッシュ：同一プロンプトの結果、あるいは補助モデルの中間結果を TTL キャッシュ。
モデルの併用：GPT‑5 を全流量に使わず、4o/4.1/o3 で前処理・分類を分担。
Azure Monitor 監視：TPM、429/503 率、P95/P99、キュー長、失敗の相関。
レート整形：キュー＋トークンバケットで瞬間バーストを吸収。
安全側のトークン見積もり：入出平均 × 1.2～1.5 の係数で枠外れを防止。
フェイルオープン/クローズの切替：本番では UX を守るために省略応答等を用意。

事例：スウェーデン中央リージョンでのボトルネック解消

社員 1,000 名規模の企業が 20k TPM の制限で検証が滞りました。サポートの Gating Team に申請 ID と利用計画（必要 TPM の根拠、監視・レート制御の実装状況、事業インパクト）を整理して共有した結果、エンタープライズ枠に昇格。Sweden Central リージョンで十分な TPM を確保し、検証〜構築を再開できました。ポイントは「証拠（メトリクス）」「準備（運用対策）」「計画（段階的スケール）」の 3 点です。

再現のための提出パッケージ（例）

1 か月分の TPM/失敗率のグラフ、ピーク時のスクリーンショット。
レート制御・バックオフの実装コード抜粋、設定値。
利用開始計画（部門ごとの段階導入）、PT への移行ロードマップ。

アーキテクチャ設計：混雑を前提にした「流量設計」

推奨ブロック図（テキスト説明）

入口：API Gateway（WAF/認証）＋キューワーカー。
整形：レートリミッタ（TPM/RPM）＋ Token Estimator（プロンプト長予測）。
処理：マルチモデルルータ（GPT‑5 / 4o / 4.1 / o3）。
メモリ：結果キャッシュ、ドキュメントベクタ格納。
監視：メトリクス（TPM/レイテンシ/失敗）＋分散トレーシング＋ログ。

トークン見積もりの自動化

呼び出し前に入力テキストをトークナイズし、見積もりトークンを算出して「見積もり > 残枠」の場合は即時キュー行きにします。入出合算の上限は モデルの最大出力も考慮して上乗せします。

プロンプト最適化チェックリスト

役割・指示・制約の重複を削る（同じ指示の再掲禁止）。
参照資料は箇条書き＋ ID 付与、ファイル全文は避けて抜粋。
出力フォーマットを固定（JSON/HTML 等）し、冗長表現を抑制。
ツール／関数呼び出しの結果だけを後段プロンプトへ継承。

キャッシュ戦略

対象	キー	TTL 目安	注意点
プロンプト結果	ハッシュ（プロンプト＋設定）	数時間～1日	個人情報・権限の違いに留意
RAG 検索	クエリ正規化＋Top‑k	数分～数時間	インデックス更新時の無効化
補助モデル結果	分類/抽出の入力	数日	誤差が蓄積しないよう再学習周期を設定

モデル併用で枠を節約する設計

すべてを GPT‑5 に投げるのではなく、前段の軽量モデルで「仕分け」してから重い推論へ通します。

分類・ルール抽出・要約の一次処理：o3/4o/4.1 で実施。
創造・長文アウトプット・高度推論：GPT‑5 へ。
再質問はコンテキストを絞って差分だけ送信（会話メモリをサブサンプリング）。

このだけでも TPM を 20～60% 節約できる事例が多く、増枠が通るまでの「橋渡し」として有効です。

監視と SLO：数字で会話する

KPI	定義	目標の置き方
TPM 使用率	使用 TPM / 上限 TPM	P95 < 80%、ピーク＜ 95%
失敗率	429/503 の割合	< 1%（重要機能は 0.1%）
レイテンシ	P95 / P99	業務要件に合わせ 2～10 秒
キュー滞留時間	投入～消化の平均	業務時間帯で 3 秒以内

ダッシュボードは「全体」「アプリ単位」「ユーザーセグメント」の 3 階層で用意し、アラートは 予兆（上昇率） と 限界（閾値） を分けます。

セキュリティ／ガバナンスの注意

増枠でトラフィックが増えるほど、ログと監査の整備が不可欠。
PII/機密の取り扱い方針（マスキング、テナント分離、鍵管理）。
プロンプトに権限情報を含めない（権限はアプリ層で強制）。
キャッシュやジョブキューの保管期間・暗号化設定。

トークン削減の実践テクニック

語彙制約：出力は指定フォーマットに固定、重複表現の禁止を明記。
参照の圧縮：要点サマリ（箇条書き）を生成してから本推論へ。
段階推論：粗→精の 2 段推論で、初回の過剰出力を抑制。
会話コンテキストのスリム化：直近 N ターン＋要約のみを保持。

サンプル：冗長出力を抑えるプロンプト雛形

あなたは企業内ヘルプデスク AI です。以下の制約を厳格に守ってください：
- 回答は 300～500 文字の要約のみ
- 箇条書き 5 点以内、重複説明の禁止
- 出力は JSON（title, bullets[]）で返す

業務別の「最小構成」レシピ

業務	前段モデル	後段モデル	その他構成	ねらい
社内 QA	o3（意図抽出）	GPT‑5	RAG（Top‑k 5）＋キャッシュ	GPT‑5 の回数を削減
議事録要約	4o（スピーカ分離）	GPT‑5	バッチ化＋夜間 PT	コストと TPM を最適化
コードレビュー	4.1（静的解析）	GPT‑5	Diff だけを提示	トークンを 50% 削減

よくある質問（FAQ）

TPM と RPM の違いは？ TPM はトークン量ベース、RPM はリクエスト回数ベースの上限です。長文は TPM、連打は RPM にぶつかります。

<dt>「1 回の長文が通らない」場合の対処は？</dt>
<dd>入力をチャンク化し段階処理に分割。長文出力の最大トークンも下げ、必要に応じてキュー経由で逐次合成します。</dd>

<dt>増枠申請はどのくらいの根拠が必要？</dt>
<dd>直近の実測値（平均・ピーク）と将来予測、失敗時の業務影響、具体的な運用対策（レート制御・監視）をセットで示すと通りやすくなります。</dd>

<dt>PT はいつ検討すべき？</dt>
<dd>恒常的に 300k TPM 以上が必要、SLA が厳格、ピークが予測可能――この 3 条件のうち 2 つ以上を満たすなら前向きに検討します。</dd>

<dt>全モデルを GPT‑5 に置き換えるべき？</dt>
<dd>いいえ。分類や下処理は軽量モデルで賄い、GPT‑5 は「価値の高い推論」に集中させるのが現実的です。</dd>

チェックリスト（導入前／本番移行）

導入前

必要 TPM を式で算定（平均・ピーク・バッファ）。
プロンプト最適化と分割戦略を用意。
キュー、レート制御、キャッシュを最初から組み込む。
監視ダッシュボードとアラート閾値を設定。

本番移行

カナリアリリースで P95/P99 を検証。
429/503 のハンドリングをユーザー体験に影響しない形で実装。
増枠申請と PT の見積を並行して実施。
モデル併用のルーティングでコストと TPM を均衡化。

推奨解決策まとめ

短期：クォータ増枠申請――組織メール、サブスクリプション ID、希望 TPM、利用実績（現行枠 80%以上消費など）を準備し、メトリクスと業務影響を添えて申請。
長期：Provisioned Throughput へ移行――時間単位の専有 RU で安定性能を確保し、1M～10M TPM 規模へ拡張。スケジュールスケールでコストも最適化。
運用ベストプラクティス――プロンプト簡潔化、バッチ化、継続監視、モデル併用で負荷分散。いきなり全量を GPT‑5 に置き換えない。

導入直後は制限が厳しいため、決済状況と実績の明示で短期の増枠を取りに行きつつ、恒常運用は PT で確実に――これが最短ルートです。

付録：評価シナリオ（コピーして使える）

SLO テンプレート

対象：社内ヘルプデスク GPT‑5
目標：P95 レイテンシ 5s 以内、失敗率 0.5% 以下、可用性 99.9%
監視：TPM 使用率、キュー滞留、429/503、ユーザー満足度（CSAT）
アラート：TPM 使用率 &gt; 85%（5 分間）、失敗率 &gt; 1%（1 分間）

負荷テスト設計

平常・繁忙・障害（意図的に上限超過）の 3 パターン。
プロンプトの長短を混在、出力最大トークンを複数水準で試験。
キュー長・バックオフ・再試行回数の最適点を探索。

インシデント対応プレイブック

429/503 が閾値超過 → 直ちに最大トークンを一時縮小。
キューの優先度を切替（対外向け > 内部向け）。
必要に応じて軽量モデル回避経路にフォールバック。
事後にメトリクスを根拠に増枠／PT を再評価。

結論

GPT‑5 の 20k TPM 上限は、個人利用でもすぐ飽和し、企業利用では本番の信頼性を揺るがします。しかし、数式で現状を見える化し、短期は増枠申請＋実装対策、長期は Provisioned Throughput で専有スループットを確保すれば、導入スピードと安定運用を両立できます。重要なのは「準備された証拠」と「段階的な拡張」。今日から計測と申請の準備を始め、同時に PT への移行設計を進めましょう。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。