この記事のポイント
Azureクォータとは、サブスクリプションごとにリソースの利用上限を定める制度。コスト管理とリソースの公平分配を実現- VM・ストレージ・ネットワーク・Azure OpenAI Serviceなど主要サービスのクォータ制限値を一覧表で解説
- 調整可能なクォータはAzure Portalからセルフサービスで引き上げ可能（処理は数秒〜数分）。引き上げ自体は無料
- 2026年の新機能としてクォータグループ（EA/MCA-E向けサブスクリプション間共有）とAzure OpenAIクォータティア（7段階自動昇格）が登場
- 使用量アラートの設定や定期確認など、クォータによるサービス停止を防ぐベストプラクティスを紹介
Microsoft MVP・AIパートナー。LinkX Japan株式会社 代表取締役。東京工業大学大学院にて自然言語処理・金融工学を研究。NHK放送技術研究所でAI・ブロックチェーンの研究開発に従事し、国際学会・ジャーナルでの発表多数。経営情報学会 優秀賞受賞。シンガポールでWeb3企業を創業後、現在は企業向けAI導入・DX推進を支援。
Azureのクォータ（リソースクォータ）とは、サブスクリプションごとに各リソースの利用上限を定める制度です。コスト管理やリソースの公平な分配を実現し、予期せぬ料金の発生を防ぎます。
本記事では、クォータの基本概念、VM・ストレージ・Azure OpenAI Serviceなど主要サービスの制限値、調整可能なクォータと調整不可能なクォータの違い、Azure Portalでの確認・引き上げ手順、2026年の新機能（クォータグループ・クォータティア）、サービス停止を防ぐベストプラクティス、料金情報まで包括的に解説します。
Azureの基本情報については、以下の記事で詳しく解説しています。
Microsoft Azureとは？できることや各種サービスを徹底解説
目次
Azureのクォータとは（2026年最新）
Microsoft Azureのクォータ（リソースクォータ）とは、Azureサブスクリプションごとに設定されたリソースの利用上限のことです。仮想マシンのvCPU数、ストレージアカウントの数、ネットワークリソースの数など、各サービスで利用可能なリソース量の最大値が定められています。
クォータと混同されやすい概念として「予算」と「使用制限」がありますが、それぞれ役割が異なります。以下の表で整理しました。
| 概念 | 対象 | 制御方法 | 超過時の挙動 |
|---|---|---|---|
| クォータ | リソースの数や容量 | Azure Portalからの引き上げ申請 | 新規リソースの作成が失敗する |
| 予算（Azure Cost Management） | 金額 | アラート通知（自動停止は別途設定） | 通知のみ（デフォルトでは停止しない） |
| 使用制限（Spending Limit） | 金額 | 無料アカウント・クレジット付きサブスクリプションに適用 | サービスが自動的に停止する |
クォータの引き上げ申請自体は無料です。クォータを増やしても、実際にリソースを使用しない限り料金は発生しません。つまり、クォータはリソースの「枠」を確保する仕組みであり、課金はリソースの実際の使用量に基づきます。
クォータに制限がある3つの理由
Azureがリソースにクォータ制限を設けているのには、明確な理由があります。
1つ目はリソース管理と制御です。クラウドリソースは共有インフラ上に構築されており、特定のユーザーが大量のリソースを占有すると他のユーザーに影響を与えます。クォータによって各サブスクリプションの利用量に上限を設けることで、すべてのユーザーが安定したサービスを利用できる環境を維持しています。
2つ目はコスト管理です。クラウドの従量課金モデルでは、意図せず大量のリソースを作成してしまうと高額な請求につながります。クォータが上限を設けることで、予期せぬ料金の発生を防ぐ安全弁として機能します。
3つ目はサービスの品質保証です。リージョン単位の物理的なキャパシティには限界があり、特にGPUインスタンスやAzure OpenAI Serviceのような需要が集中するサービスでは、クォータによる割り当て管理が安定したパフォーマンスの維持に不可欠です。
クォータの種類と主要サービスの制限値
Azureのクォータは各サービスに対して個別に設定されています。以下の表で、代表的なサービスのクォータ制限値を整理しました。
| サービス | 制限項目 | デフォルト上限 | 最大上限（申請時） |
|---|---|---|---|
| VM（vCPU） | リージョンごとの合計vCPU数 | 20 vCPU | 10,000 vCPU |
| VM（VMファミリ別） | Dv5シリーズ等のvCPU数 | 20 vCPU | ファミリにより異なる |
| ストレージアカウント | リージョンごとのアカウント数 | 250 | 500 |
| 仮想ネットワーク | リージョンごとのVNet数 | 1,000 | 1,000 |
| パブリックIP | リージョンごとのIP数 | 10（Basic） | サポートに連絡 |
| Azure SQL Database | サーバーごとのDB数 | 500 | 500 |
| Azure Cosmos DB | アカウントごとのデータベース数 | 25 | サポートに連絡 |
| Azure OpenAI | リージョンごとのリソース数 | 30 | 30 |
| Azure OpenAI（TPM） | モデルごとのトークン/分 | ティアにより異なる | ティア6で最大45M TPM |
特にGPU系のVMシリーズ（NC、ND、NVシリーズ等）はデフォルトのvCPUクォータが0に設定されている場合があり、利用前に必ず引き上げ申請が必要です。以下で、特に設計時に注意が必要なサービスのクォータを詳しく解説します。
VM・コンピュートリソースのクォータ
Azure Virtual Machinesのクォータは3段階の制限体系で管理されています。最上位がリージョンごとの合計vCPU数（デフォルト20）、次にVMファミリ別のvCPU数（Dシリーズ、Eシリーズなどファミリごとに個別設定）、そして個々のVMサイズごとの制限です。
この3段階すべてを満たさないとVMのデプロイは失敗します。たとえばリージョン合計のvCPUクォータに余裕があっても、特定のVMファミリのクォータが上限に達していれば「QuotaExceeded」エラーが発生します。
2026年時点では、Azure Kubernetes Service（AKS）のクォータも重要です。AKSではサブスクリプションあたりグローバルで5,000クラスター、クラスターあたり5,000ノード、ノードプールあたり1,000ノードという制限が設定されています。大規模なコンテナワークロードを計画する場合は、事前にクォータの引き上げを検討してください。
ストレージ・ネットワークリソースのクォータ
Azure Storageのクォータは、リージョンごとのストレージアカウント数が250（最大500まで引き上げ可能）、ストレージアカウントあたりの最大容量が5 PiBです。Blob StorageやFile Storageなどのサービスはストレージアカウント内で管理されるため、アカウント数の制限がすべてのストレージサービスに影響します。
ネットワークリソースについては、仮想ネットワーク（VNet）がリージョンあたり1,000、ロードバランサーがリージョンあたり1,000、ネットワークセキュリティグループ（NSG）がリージョンあたり5,000という制限があります。パブリックIPアドレスはBasic SKUがリージョンあたり10、Standard SKUがリージョンあたり10がデフォルトで、引き上げ申請が可能です。
データベースリソースでは、Azure SQL Databaseがサーバーあたり500データベース、Azure Cosmos DBがアカウントあたり25データベースという制限が設定されています。マルチテナントアプリケーションやマイクロサービスアーキテクチャではデータベース数が増加しやすいため、早い段階で制限値を確認しておくことが重要です。
Azure OpenAI Serviceのクォータ
Azure OpenAI Serviceのクォータは、他のAzureサービスとは異なるTPM（Tokens Per Minute）ベースの管理体系を採用しています。モデルごと、デプロイの種類ごとにTPMの上限が設定されており、この上限がAPIのスループットを決定します。
2026年3月時点での主要モデルのTPM上限（GlobalStandardデプロイ・Tier 1の場合）は以下のとおりです。
| モデル | TPM上限（Tier 1） | RPM換算 |
|---|---|---|
| gpt-5 | 1M | 1,000 |
| gpt-4.1 | 1M | 6,000 |
| gpt-4.1-mini | 5M | 30,000 |
| o3 | 1M | 1,000 |
| o4-mini | 1M | 1,000 |
RPM（Requests Per Minute）はTPMから自動的に算出されます。標準的なチャットモデルでは1,000 TPMあたり6 RPM、o3やo4-miniなどの推論モデルでは1,000 TPMあたり1 RPMです。この換算比率の違いを理解しておかないと、同じTPMを割り当てても推論モデルのほうがリクエスト処理能力が低くなります。
Azure OpenAI Serviceのリソース数はリージョンあたり30、標準デプロイはリソースあたり32、ファインチューニング済みモデルのデプロイはリソースあたり10という制限も設定されています。複数のリージョンにリソースを分散配置することで、TPMの合計を増やすことも可能です。
調整可能なクォータと調整不可能なクォータ
Azureのクォータには、ユーザーが引き上げ可能な「調整可能なクォータ」と、システム上の制約により変更できない「調整不可能なクォータ」の2種類があります。以下の表でその違いを整理しました。
| 分類 | 引き上げ方法 | 代表例 | 処理時間 |
|---|---|---|---|
| 調整可能（セルフサービス） | Azure Portalの「マイクォータ」から直接申請 | vCPU数、ストレージアカウント数 | 数秒〜数分 |
| 調整可能（サポートリクエスト） | サポートチケット経由で申請 | 高い制限値（200 vCPU超）、特殊なSKU | 数日〜5営業日 |
| 調整不可能 | 変更不可 | CDNプロファイル数（25）、特定のAPIレートリミット | 変更不可 |
調整可能なクォータの代表例はvCPUクォータです。Azure Portalの「マイクォータ」ページから直接引き上げ申請を送信でき、小規模な引き上げであれば数秒から数分で自動承認されます。ただし、200 vCPUを超える引き上げでは与信審査が発生し、承認まで5〜7営業日かかる場合があります。
調整不可能なクォータの例としては、CDNプロファイル数がサブスクリプションあたり25個、CDNエンドポイント数がプロファイルあたり25個などがあります。これらはインフラストラクチャの設計上の制約に基づいており、サポートリクエストを送っても引き上げることができません。
調整不可能なクォータに該当するリソースが不足する場合は、サブスクリプションを追加するか、アーキテクチャの設計を見直す必要があります。Azure Portalのクォータページでは各クォータが「調整可能」かどうかが明示されているため、リソース計画の際に必ず確認してください。
クォータの確認方法と引き上げ手順
クォータの確認と引き上げは、Azure Portalのクォータページ、Quota REST API、サポートリクエストの3つの方法で行えます。以下の表でそれぞれの特徴を比較しました。
| 方法 | 対象 | 必要な権限 | 適した用途 |
|---|---|---|---|
| Azure Portal（クォータページ） | 調整可能なクォータ全般 | 共同作成者ロール以上 | 個別のクォータ確認・引き上げ |
| Quota REST API | Compute・ML・Network・Storage等 | 共同作成者ロール以上 | 自動化・大規模管理 |
| サポートリクエスト | 調整不可能なクォータ、高い制限値 | サポートプランの契約 | 大幅な引き上げ・特殊ケース |
いずれの方法でも、クォータの確認・引き上げを行うにはサブスクリプションに対する共同作成者ロール以上の権限が必要です。無料試用版サブスクリプションではクォータの引き上げができないため、有料サブスクリプションへのアップグレードが必要です。
Azure Portalでのセルフサービス引き上げ
Azure Portalでの引き上げは、最も一般的で簡単な方法です。手順は以下のとおりです。
- Azure Portalにサインインし、検索バーに「クォータ」と入力して「クォータ」ページを開く
- クォータプロバイダー（Compute、Storageなど）を選択する
- 引き上げたいクォータの行を選択し、「新しいクォータ要求」をクリックする
- 「新しい制限」に希望する値を入力する（現在の制限からの増分ではなく、希望する合計値を入力する）
- 「送信」をクリックする
- 承認結果がAzure Portalの通知とメールで届く
2026年時点では、多くの調整可能なクォータがセルフサービスで処理され、申請から承認まで数秒〜数分で完了します。従来はサポートチケットの審査に5〜7営業日を要していたため、大幅な改善です。
申請が拒否された場合は、リクエスト詳細画面からサポートリクエストを作成できます。拒否の理由としては、リージョンのキャパシティ不足や、サブスクリプションの利用実績が少ないことなどが考えられます。
サポートリクエストでの引き上げ
セルフサービスでは対応できないケースや、調整不可能と表示されるクォータについては、サポートリクエストを作成して引き上げを依頼します。
サポートリクエストの作成は「ヘルプ + サポート」メニューから行います。問題の種類で「サービスおよびサブスクリプションの制限（クォータ）」を選択し、対象のサービスとリージョン、希望する制限値を入力して送信します。
200 vCPU以上の引き上げでは与信審査が発生する場合があり、審査完了まで5〜7営業日かかることがあります。プロジェクトの開始前に余裕を持ってリクエストを送信することが重要です。Premier/Unified/Professional Directのサポートプランを契約している場合は、サポートREST APIを通じてプログラム的にリクエストを送信することも可能です。
2026年の新機能：クォータグループとクォータティア
2025年から2026年にかけて、Azureのクォータ管理に大きなアップデートが2つ導入されました。以下の表で概要を整理します。
| 新機能 | 対象 | 提供状況 | 主な利用者 |
|---|---|---|---|
| クォータグループ | IaaSコンピュートリソース（VM/vCPU） | GA（一般提供） | EA・MCA-Eサブスクリプション利用企業 |
| クォータティア | Azure OpenAI Service | GA | Azure OpenAI利用者全般 |
いずれも大規模なAzure環境を運用する企業にとって、クォータ管理の効率を大幅に改善する機能です。
クォータグループ（GA）
クォータグループは、複数のサブスクリプション間でvCPUクォータを共有・移動できる機能です。Enterprise Agreement（EA）またはMicrosoft Customer Agreement for Enterprise（MCA-E）のサブスクリプションを利用している組織が対象で、管理グループ配下にクォータグループを作成して利用します。
従来、サブスクリプションAで余っているvCPUクォータをサブスクリプションBに移すには、サポートリクエストを2件（A側の減少とB側の増加）作成する必要がありました。クォータグループでは、グループ内のサブスクリプション間でクォータの割り当てと解放をAzure Portalから直接実行できます。
たとえば、開発環境のサブスクリプションで使わなくなったvCPUクォータを本番環境のサブスクリプションに移す作業が、サポートチケットなしで完了します。数千〜数万台規模のVMを運用する大企業にとって、クォータの取得・再配分にかかる時間を大幅に短縮できる機能です。
現時点ではIaaSコンピュートリソース（VM/vCPU）のみが対象で、ストレージやネットワークのクォータには対応していません。また、1つのサブスクリプションが同時に参加できるクォータグループは1つまでです。
Azure OpenAI クォータティア
Azure OpenAI Serviceでは、従来のDefault/Enterpriseの2段階から7段階のクォータティア（Free Tier、Tier 1〜Tier 6）に移行しました。
| ティア | gpt-5 TPM | gpt-4.1 TPM | gpt-4.1-mini TPM |
|---|---|---|---|
| Tier 1 | 1M | 1M | 5M |
| Tier 3 | 9M | 9M | 46M |
| Tier 6 | 45M | 45M | 225M |
ティアの昇格は利用実績に基づいて自動的に行われます。EA/MCA-Eの契約があれば初期段階から高いティアが割り当てられるケースもあります。以前に承認されたクォータは維持され、ティアの降格によって減らされることはありません。
クォータをコスト制御の手段として利用している組織向けに、自動昇格をオプトアウトする機能もプレビューとして提供されています。API（api-version 2025-10-01-preview）からNoAutoUpgradeフラグを設定することで、意図しないティア昇格を防ぐことができます。
追加のTPMが必要な場合は、従来どおりクォータ増加リクエストフォームから申請が可能です。Azure OpenAI Serviceの料金やAzure AI Foundryでの管理方法については関連記事で解説しています。
クォータ管理のベストプラクティス
クォータの上限に達すると、新しいリソースの作成や既存リソースのスケーリングが制限されます。予期せぬサービス停止を防ぐために、以下のベストプラクティスを実践してください。
- 使用量アラートの設定
Azure Portalのクォータページから、各クォータの使用率に基づくアラートを設定できます。たとえば「vCPU使用率が80%に達したら通知」というルールを設定しておけば、上限に達する前に対処が可能です。Azure Monitorのアラートと組み合わせることで、より高度な監視体制を構築できます
- 定期的なクォータレビュー
月次または四半期ごとに、各サブスクリプションのクォータ使用状況を確認する運用を推奨します。Azure Portalのクォータページではリソースプロバイダーごとに現在の使用量と上限値を一覧で確認できます。特にプロジェクトの拡大期やリソースの使用量が急増する時期には、より頻繁なチェックが必要です
- 事前のキャパシティプランニング
大規模なデプロイや移行プロジェクトでは、必要なリソース量を事前に見積もり、プロジェクト開始前にクォータの引き上げを完了しておいてください。特にGPU系VMやAzure OpenAI Serviceのように需要が集中するリソースは、引き上げに時間がかかる場合があります
- Infrastructure as Code（IaC）との統合
ARMテンプレートやBicep、Terraformを使ったインフラ構成管理では、デプロイ前にクォータの余裕を確認するステップを組み込むことで、クォータ不足によるデプロイ失敗を事前に検知できます。Quota REST API（api-version 2025-09-01）を使えばプログラム的にクォータと使用量を取得可能です
もし自社のAzure環境で「VMのデプロイが突然失敗するようになった」「Azure OpenAI APIのレスポンスが429エラーで返ってくる」「サブスクリプション間でクォータが偏在して非効率」といった状況があれば、クォータ管理の見直しで解決できる典型的な課題です。
Azureの運用設計やAzureのセキュリティ対策と併せて、クォータ管理もAzure環境の安定運用に不可欠な要素として位置付けてください。
Azureのクォータ関連の料金情報（2026年3月版）
Azureのクォータに関する料金のポイントを以下の表にまとめました。
| 項目 | 料金 | 備考 |
|---|---|---|
| クォータの引き上げ申請 | 無料 | セルフサービス・サポートリクエストいずれも無料 |
| クォータの維持 | 無料 | 枠を確保しても実際に使用しなければ課金されない |
| リソースの使用 | 従量課金 | 実際にデプロイ・使用したリソースに対して課金 |
| Azure OpenAI PTU（Provisioned Throughput） | 月額課金 | 確保したPTU数に対して固定課金が発生 |
| サポートプラン | 月額$29〜$1,000+ | クォータの大幅引き上げにProfessional Direct以上が必要な場合あり |
注意が必要なのはAzure OpenAI ServiceのProvisioned Throughput Units（PTU）です。PTUは予約型の課金モデルで、確保した分だけ固定費用が発生します。標準的な従量課金（Pay-as-you-go）のTPMクォータとは異なり、PTUは使用量に関わらず課金されるため、需要予測に基づいた適切なサイジングが重要です。
Azureの料金体系の全体像や、料金計算ツールを使った見積もり方法については関連記事で解説しています。VMのコスト最適化には予約インスタンスやAzure VMのコスト削減方法も参考にしてください。
【無料DL】AI業務自動化ガイド（220P）
Microsoft環境でのAI活用を徹底解説
Microsoft環境でのAI業務自動化・AIエージェント活用の完全ガイドです。Azure OpenAI、AI Agent Hub、n8nを活用した業務効率化の実践方法を詳しく解説します。
まとめ
本記事では、Azureのクォータについて、基本概念、主要サービスの制限値、調整可能・調整不可能の違い、確認・引き上げ手順、2026年の新機能（クォータグループ・クォータティア）、ベストプラクティス、料金情報までを解説しました。
クォータはAzureの安定運用に直結する仕組みです。上限に達してからリソースの作成が失敗するのでは遅く、事前の確認と計画的な管理が不可欠です。
Azureのクォータ管理を始めるための具体的なステップは以下の3つです。
- ステップ1
Azure Portalのクォータページを開き、現在のサブスクリプションで使用率が高いリソースを確認してください。使用率が70%を超えているクォータがあれば、引き上げ申請を検討しましょう
- ステップ2
vCPU使用率80%などのしきい値で使用量アラートを設定し、クォータ上限への接近を自動で検知できる体制を整えてください。Azure Monitorのアラートと組み合わせることで通知先のカスタマイズも可能です
- ステップ3
EA/MCA-Eサブスクリプションを利用している場合は、クォータグループの導入を検討してください。サブスクリプション間のクォータ移動が即座に行えるようになり、リソース管理の効率が大幅に向上します
Azureの料金体系やBlob Storageの料金など、コスト管理に役立つ情報も関連記事で提供しています。
