Azure AI FoundryでFoundry Modelsを本番利用する場合、今回まず確認すべきなのは「クォータの管理単位」と「レート制限に到達したときの設計」です。特にRealtime TranslateとRealtime Whisperでは、Global StandardやData Zone Standardのクォータがサブスクリプション単位の共有プールとして扱われるため、従来のように「リージョンごとに余裕がある」と考えていると、想定外の429エラーや展開失敗につながる可能性があります。
この記事では、2026年5月9日時点で確認すべきMicrosoft Learnの「Microsoft Foundry Models quotas and limits」の要点をもとに、Azure AI Foundryの管理者・開発者が見るべき変更点、影響範囲、設定確認、移行・展開時の注意点を整理します。
Azure AI FoundryのFoundry Models quotas and limitsで最初に押さえる結論
Microsoft Foundry Models quotas and limitsの重要点は、単に「上限値が載っている」ことではありません。実務上は、次の4点を先に押さえる必要があります。
- Realtime TranslateとRealtime Whisperでは、新しいクォータ管理が適用され、Global Standardはサブスクリプション内の全リージョンで共有、Data Zone Standardはデータゾーン単位で共有されます。
- それ以外のFoundry Modelsでは、現時点では従来どおり、リージョン・サブスクリプション・モデルまたはデプロイ種別ごとの制限として管理されます。
- TPM、RPM、同時リクエスト数、クライアントタイムアウト、カスタムヘッダー数など、アプリケーション設計に直結する制限があります。
- 本番運用では、クォータ申請だけでなく、再試行、負荷のならし、タイムアウト、監視、デプロイ種別の選定まで含めて設計する必要があります。
公式情報では、2025年5月6日以降のクォータ管理更新として、Realtime TranslateとRealtime Whisperからサブスクリプションレベルの共有クォータ管理が導入されると説明されています。Global Standardは同一モデル・同一バージョンのデプロイがサブスクリプション全体で1つのクォータプールを共有し、Data Zone StandardはUSやEUなどのデータゾーン単位で共有します。(Microsoft Learn)
何が変わるのか：クォータが「個別枠」から「共有プール」へ近づく
今回の変更で最も重要なのは、対象モデルではクォータを「リソースごと」「リージョンごと」に個別管理する発想から、「サブスクリプション内の共有プール」として見る必要が出てきた点です。
| 項目 | 変更前に近い考え方 | 更新後に注意すべき考え方 |
|---|---|---|
| Global Standard | リージョンごとにクォータを見積もる | 同一サブスクリプション内の全リージョンで、同一モデル・同一バージョンのクォータを共有 |
| Data Zone Standard | リージョン単位の余力を確認する | US、EUなどのデータゾーン単位で共有クォータを確認 |
| 既存の承認済みクォータ | 個別の割り当てとして管理 | 承認済みクォータは保持され、サブスクリプションレベルに自動適用 |
| 対象モデル | すべてのモデルに適用されると誤解しやすい | 現時点ではRealtime TranslateとRealtime Whisperが対象 |
ここで誤解しやすいのは、「Azure AI Foundry全体で一律に新方式へ移行した」という受け止め方です。公式ドキュメントでは、新しいクォータ管理の対象は現時点でRealtime TranslateとRealtime Whisperに限られ、その他のFoundry Modelsではリージョン、サブスクリプション、モデルまたはデプロイ種別ごとの管理が続くと明記されています。(Microsoft Learn)
つまり、管理者は「どのモデルが新しいクォータ管理の対象か」を棚卸しする必要があります。対象外のモデルまで共有プール前提で設計すると、逆に必要なリージョン別クォータ確認を見落とす恐れがあります。
影響を受ける対象者
この変更は、Azure AI Foundryを触るすべての人に同じ影響を与えるわけではありません。特に影響が大きいのは、複数リージョン、複数プロジェクト、複数デプロイを運用しているチームです。
| 対象者 | 確認すべきこと |
|---|---|
| Azure管理者 | サブスクリプション単位のクォータ、権限、申請フロー、リージョン別の割り当て |
| AI基盤担当者 | モデルごとのTPM/RPM、同時リクエスト数、デプロイ種別、PTUの必要性 |
| アプリ開発者 | 429エラー時の再試行、タイムアウト、急激な負荷増加への対策 |
| SRE・運用担当者 | 使用量監視、アラート、負荷試験、クォータ変更後の反映確認 |
| セキュリティ・ガバナンス担当 | デプロイ種別の制御、データゾーン、カスタムヘッダー依存の見直し |
特に本番環境で「東京リージョンと別リージョンに分けているから余裕がある」と判断している場合は注意が必要です。Global Standardの対象モデルでは、リージョンを分けても同じ共有クォータプールを消費する可能性があります。
Foundry Modelsの主な制限値
Microsoft Foundry Models quotas and limitsでは、リソース数、プロジェクト数、デプロイ数、TPM、RPM、同時リクエスト数などが整理されています。代表的な制限は次のとおりです。
| 制限項目 | 既定の上限 |
|---|---|
| Azureサブスクリプション・リージョンごとのFoundryリソース数 | 100 |
| 1リソースあたりの最大プロジェクト数 | 250 |
| 1リソースあたりの最大デプロイ数 | 32 |
| APIリクエスト内のカスタムヘッダー数 | 10 |
Foundryリソースはリージョンごとにサブスクリプションあたり100、プロジェクトは1リソースあたり250、モデルデプロイは1リソースあたり32が上限として示されています。また、カスタムヘッダーは最大10個で、超過するとHTTP 431エラーになると説明されています。(Microsoft Learn)
モデル別のレート制限も確認が必要
Foundry Modelsでは、モデルごとにTPM、RPM、同時リクエスト数の上限が異なります。代表的な例は次のとおりです。
| モデル例 | TPM | RPM | 同時リクエスト |
|---|---|---|---|
| DeepSeek-R1、DeepSeek-V3-0324 | 5,000,000 | 5,000 | 300 |
| Llama 3.3 70B Instruct、Llama-4-Maverick-17B-128E-Instruct-FP8、Grok 3、Grok 3 mini | 400,000 | 1,000 | 300 |
| その他の多くのモデル | 400,000 | 1,000 | 300 |
| Flux.2-Pro | TPMは該当なし | Low: 15、Medium: 30、High: 100 | 該当なし |
| Flux-Pro 1.1、Flux.1-Kontext Pro | TPMは該当なし | 2 capacity units、6 RPM | 該当なし |
Azure OpenAIモデルについては、モデルやSKUごとに制限が異なるため、Foundry Modelsの表だけで判断せず、Azure OpenAIのクォータと制限を別途確認する必要があります。公式ドキュメントでも、Azure OpenAI modelsはモデルとSKUにより異なるとされています。(Microsoft Learn)
Azure OpenAI in Foundry Modelsとは分けて考える
Azure AI Foundryでは、Foundry Models sold directly by Azure、Azure OpenAI in Foundry Models、パートナーやコミュニティ由来のモデルなどが混在します。ここを混同すると、クォータ申請や制限値の見積もりを誤ります。
Foundry Models sold directly by Azureのクォータ増加は、Microsoft Learnで案内されているクォータ増加フォームを使います。一方、Azure OpenAIはモデル・SKUごとの制限確認が必要で、パートナー・コミュニティモデルはAnthropicモデルを除き、クォータ増加の対象外とされています。(Microsoft Learn)
実務では、次のように分類して確認するとミスを減らせます。
| 確認項目 | 見るべき観点 |
|---|---|
| Foundry Models sold directly by Azure | Microsoft Foundry Models quotas and limitsの対象か |
| Azure OpenAI in Foundry Models | Azure OpenAIのクォータと制限を別途確認 |
| Anthropicモデル | クォータ増加申請の対象になり得る |
| その他のパートナー・コミュニティモデル | クォータ増加に対応していない可能性を確認 |
| 画像生成系モデル | TPMではなくRPMやcapacity unitで制限される場合がある |
管理者が確認すべき設定
Azure AI Foundryの管理者は、まずポータル上でクォータの見え方と権限を確認します。クォータがあるかどうか以前に、権限不足で正しい情報が見えていないケースがあるためです。
必要な権限を確認する
Microsoft Foundryのクォータ管理では、閲覧、申請、編集で必要な権限が異なります。
| 作業 | 必要な権限 |
|---|---|
| クォータ割り当ての閲覧 | サブスクリプションレベルのCognitive Services Usages Reader |
| クォータ増加申請 | サブスクリプションのOwnerまたはContributor |
| Foundryポータルでのクォータ割り当て編集 | Cognitive Services ContributorとCognitive Services Usages Readerの組み合わせ |
公式のクォータ管理手順では、クォータ閲覧にはCognitive Services Usages Reader、申請にはOwnerまたはContributor、編集にはCognitive Services ContributorとCognitive Services Usages Readerが必要とされています。(Microsoft Learn)
Foundryポータルで確認する場所
新しいFoundryポータルでは、次の流れでクォータを確認します。
| 手順 | 操作 |
|---|---|
| 1 | Microsoft Foundryにサインインし、New Foundryが有効になっていることを確認 |
| 2 | 対象プロジェクトを選択 |
| 3 | 画面上部の「Operate」を選択 |
| 4 | 左ペインの「Quota」を開く |
| 5 | Token per minuteまたはProvisioned throughput unitのタブを確認 |
| 6 | 対象デプロイを選び、現在の割り当て、使用量、関連デプロイを確認 |
| 7 | 必要に応じて割り当て編集またはRequest quotaを実行 |
クォータ画面にはTPM管理用の「Token per minute」と、プロビジョンドデプロイ向けの「Provisioned throughput unit」のタブがあります。割り当て変更や申請後は反映まで最大15分程度かかるため、変更直後の値だけで判断しないようにします。(Microsoft Learn)
共有クォータは本番用ではなくテスト用と考える
Foundryには、モデルカタログからの推論テストに使える共有クォータプールがあります。ただし、公式情報では共有クォータは一時的なテストエンドポイント用であり、本番エンドポイントには専用クォータを申請すべきとされています。(Microsoft Learn)
PoCでは共有クォータで素早く検証し、本番化の前に専用クォータへ切り替える、という運用が現実的です。共有クォータのまま本番運用を始めると、負荷が増えたタイミングで再現性の低い性能問題が発生しやすくなります。
開発者が実装で確認すべきポイント
クォータとレート制限は、管理者だけの問題ではありません。アプリケーション側の実装が不十分だと、十分なクォータがあるように見えても、ユーザー体験は不安定になります。
429エラーを前提に再試行を実装する
HTTP 429 Too Many Requestsは、TPMやRPMの上限に達したときに発生します。対策としては、単純な即時リトライではなく、Retry-Afterヘッダーを利用し、指数バックオフを入れた再試行が必要です。
| 悪い実装 | 問題 |
|---|---|
| 429が出たら即座に同じリクエストを再送 | さらに制限に近づき、復旧が遅くなる |
| 全クライアントが同じ秒数で再試行 | 同時再試行が集中し、再び429になりやすい |
| 無制限にリトライ | コスト増、遅延増、キュー詰まりの原因になる |
| 429をアプリの失敗として即時表示 | 一時的な制限でもユーザー体験が悪化する |
公式ドキュメントでも、429に対しては指数バックオフを伴う再試行とRetry-Afterヘッダーの利用が推奨されています。また、急激なワークロード変化を避け、負荷を段階的に増やすこともベストプラクティスとして示されています。(Microsoft Learn)
クライアント側タイムアウトを明示する
AIモデルの推論では、通常のWeb APIより処理時間が長くなることがあります。ライブラリ既定のタイムアウトに任せると、モデル側の仕様では処理可能でも、クライアント側で先に切断されることがあります。
| リクエスト種別 | 公式ガイダンス上の目安 |
|---|---|
| Reasoning models | 最大29分 |
| Non-reasoning modelsのストリーミング | 最大60秒 |
| Non-reasoning modelsの非ストリーミング | 最大29分 |
Reasoning modelsでは、中間推論トークンを生成してから要約結果を返すため、最初の応答トークンが返るまで時間がかかる場合があります。公式情報では、ライブラリ既定のタイムアウトは上記の制限と一致しない可能性があるため、アプリケーション側で明示的に設定するよう案内されています。(Microsoft Learn)
ただし、すべてのリクエストを29分待つ設計にすればよいわけではありません。チャットUIならユーザー体験を優先して短めにし、バックエンドのバッチ処理なら長めにするなど、用途に応じて設定を分けるべきです。
カスタムヘッダーに依存しすぎない
現在のAPIではカスタムヘッダーが最大10個まで許容されますが、超過するとHTTP 431 Request Header Fields Too Largeになります。さらに、将来のAPIバージョンではカスタムヘッダーのパススルーに依存しないよう注意されています。(Microsoft Learn)
社内システムでは、認証情報、トレースID、部門ID、課金タグ、実験IDなどをヘッダーに詰め込みがちです。Foundry Modelsに送る前に、必要なメタデータを整理し、アプリケーション側のログやリクエスト本文、別の管理テーブルに逃がせるものは分離しておくと安全です。
デプロイ種別の選び方
Azure AI Foundryでは、Global Standard、Data Zone Standard、Standard、Provisioned、Batchなど、用途に応じたデプロイ種別があります。クォータ設計は、どのデプロイ種別を選ぶかで変わります。
| デプロイ種別 | 向いている用途 | 注意点 |
|---|---|---|
| Global Standard | 一般的な従量課金ワークロード、高い初期スループットを期待するケース | 高負荷が継続するとレイテンシばらつきが出る可能性 |
| Data Zone Standard | USまたはEUのデータゾーン内で処理したいケース | データゾーン単位の共有クォータに注意 |
| Standard | 単一リージョンで低〜中程度の利用 | モデルやリージョンの対応状況を確認 |
| Provisioned | 安定した高スループット、低いレイテンシばらつきが必要な本番環境 | PTUの確保とコスト見積もりが必要 |
| Batch | 大量の非同期処理、リアルタイム応答が不要な処理 | 即時応答には向かない |
Microsoftのデプロイ種別の説明では、Standard系は従量課金、Provisioned系は予約容量、GlobalやData Zone、Regionalはデータ処理場所やコンプライアンス要件に応じて選ぶ構成になっています。また、高い一貫性が必要な高負荷ワークロードではProvisioned系の検討が示されています。(Microsoft Learn)
重要なのは、PoCで動いたデプロイ種別をそのまま本番へ持ち込まないことです。PoCではGlobal Standardで十分でも、本番で遅延のばらつきや429が許容できない場合は、ProvisionedやBatchを含めて再設計する必要があります。
移行・展開時の注意点
今回の更新で、既存の承認済みクォータは保持され、自動的にサブスクリプションレベルへ適用されます。そのため、Realtime TranslateやRealtime Whisperを利用している場合でも、すぐに手作業の移行が必要とは限りません。(Microsoft Learn)
ただし、「何もしなくてよい」と考えるのは危険です。設定値は維持されても、チーム内の見積もりロジック、監視ダッシュボード、運用手順が古い前提のまま残ることがあります。
移行前後で確認すべき観点
| 確認項目 | 見直す理由 |
|---|---|
| モデル名とバージョン | 共有クォータは同一モデル・同一バージョン単位で判断されるため |
| デプロイ種別 | Global StandardかData Zone Standardかで共有範囲が異なるため |
| サブスクリプション | クォータの上位スコープがサブスクリプション単位のため |
| リージョン構成 | Global Standardではリージョン分散がクォータ分散にならない場合があるため |
| 監視指標 | リージョン別だけでなく、共有プール単位で使用量を見る必要があるため |
| 負荷試験 | 複数デプロイが同時に動いたときの消費量を確認するため |
たとえば、米国リージョンと欧州リージョンでRealtime WhisperのGlobal Standardデプロイを分けている場合、リージョンごとに余力を見ているだけでは不十分です。同一サブスクリプション内の同一モデル・同一バージョンが共有プールを使う前提で、ピーク時間帯の合算使用量を確認する必要があります。
よくあるトラブルと対処法
Foundry Modelsのクォータや制限で起きやすい問題は、原因を切り分けると対処しやすくなります。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| HTTP 429 Too Many Requests | TPMまたはRPMの超過 | Retry-Afterを使った指数バックオフ、負荷の平準化、クォータ再割り当て、増加申請 |
| HTTP 431 Request Header Fields Too Large | カスタムヘッダーが10個を超過 | ヘッダー数を削減し、メタデータ設計を見直す |
| Quotaページで利用可能量が0 | クォータがすべて割り当て済み | 未使用デプロイからクォータを移す、または増加申請 |
| 特定モデルが見つからない | リージョン非対応、デプロイ種別非対応 | モデルのリージョン対応とデプロイ種別を確認 |
| Request quotaボタンが無効 | 権限不足、またはモデル・リージョンの組み合わせが非対応 | OwnerまたはContributor権限を確認し、対応可否を確認 |
| クォータ変更が反映されない | 反映待ち、画面更新不足 | 最大15分程度待ち、Quotaページを更新 |
公式のトラブルシューティングでも、429、431、Quotaページでの0表示、モデルのリージョン非対応などが代表的な症状として整理されています。(Microsoft Learn)
本番展開前のチェックリスト
Azure AI FoundryでFoundry Modelsを本番展開する前に、次の項目を確認しておくと、リリース後の障害を減らせます。
- 対象モデル、モデルバージョン、デプロイ種別を一覧化したか
- Realtime TranslateまたはRealtime Whisperを利用しているか
- Global StandardまたはData Zone Standardの共有クォータ範囲を確認したか
- TPM、RPM、同時リクエスト数を実際のピーク負荷で見積もったか
- 429エラー時の指数バックオフとRetry-After対応を実装したか
- クライアント側タイムアウトを用途別に明示したか
- カスタムヘッダーが10個を超えない設計になっているか
- FoundryポータルのQuota画面を確認できる権限を付与したか
- 本番用に専用クォータを申請したか
- クォータ変更後、最大15分程度の反映時間を運用手順に入れたか
- 負荷試験で急激なスパイクではなく、段階的な増加パターンも試したか
- 429、431、レイテンシ、使用量を監視するアラートを設定したか
このチェックリストで重要なのは、「クォータが足りるか」だけを見ないことです。クォータが十分でも、リトライ設計が悪ければ429を連発します。逆に、クォータが少なくても、キューイングやBatch処理を使えば安定して処理できるケースがあります。
次に取るべき行動
Azure AI FoundryのMicrosoft Foundry Models quotas and limitsを確認する際は、まず自社の利用モデルを「新しい共有クォータ管理の対象か」「Azure OpenAI側の制限を見るべきか」「パートナー・コミュニティモデルか」に分けてください。
そのうえで、管理者はFoundryポータルのQuota画面でサブスクリプション、リージョン、モデル、デプロイ種別ごとの割り当てを確認します。開発者は、429対策、タイムアウト、カスタムヘッダー、負荷平準化を実装します。
特にRealtime TranslateとRealtime Whisperを複数リージョンで使っている場合は、リージョン別ではなく共有プール単位で使用量を見ることが重要です。リリース前にクォータ表と実装チェックリストを照合し、足りない部分はクォータ申請、デプロイ種別の見直し、またはアプリ側の制御で補いましょう。
コメント