Azure OpenAIの利用枠ガイド

Microsoftの非営利プログラムで寄贈される年間$2,000 (USD)のAzureクレジット。これを使ってAzure OpenAI(Azure上でGPT系のAIモデルを使えるサービス)を動かそうとすると、最初にぶつかるとみられるのが「使いたい新しいモデルが、そもそも使い始められない」という壁です。運営メンバーも実際にここでつまずきました。

原因は「クォータ」と呼ばれる利用枠にあります。Azure OpenAIでは、モデルごとに「1分間に処理できるトークン数(トークン=AIが文章を数える単位。日本語ならおおむね1文字1〜2トークン)」の上限が決まっていて、この枠が0のモデルは利用開始の設定(デプロイ)自体ができません。

運営メンバーが議事録自動化ツールを構築する過程で実際にこの壁に当たり、公式APIで原因を確認して突破した記録です(2026年7月時点)。

この利用枠の大きさを決めているのが Quota Tier(クォータティア)という仕組みです。いわばアカウントのランク制度で、下からFree Tier、Tier 1〜Tier 6まであり、ランクが上がるほど各モデルの利用枠が大きくなります(枠そのものはモデルごと・リージョンごと・デプロイ方式ごとに細かく分かれています)。昇格は自動で、公式には「利用量の傾向」「Microsoftとの契約の種類(大企業向け契約は高ランク)」「支払い履歴」が考慮されるとされています(公式: Quotas and limits、英語)。

ここで運営メンバーが最初に考えたのは「予算内で気前よく使えば、利用実績でランクが上がるのでは?」でしたが、計算してみて断念しました。一番下のランクでもgpt-5-miniの枠は1分あたり50万トークン。年$2,000のクレジットを全額AIに注ぎ込んだとして、gpt-5-miniの単価で買えるトークン量を時間で割った概算では、24時間365日均等に使って1分あたり約1,900トークン、平日の日中だけに集中させても約8,300トークン——枠の上限の2%にも届きません。「たくさん使って昇格を狙う」作戦は、この予算規模では数字の上で成立しないのです。

代わりに決め手になったのが、「自分のアカウントは今どのランクで、いつ昇格するのか」を直接答えてくれる公式API(プログラムから情報を取得する窓口)でした。Azureの管理コマンド(Azure CLIの az rest)から次のアドレスに問い合わせます:

GET https://management.azure.com/subscriptions/{自分のサブスクリプションID}/providers/Microsoft.CognitiveServices/quotaTiers/default?api-version=2025-10-01-preview

(2026年7月時点ではプレビュー=正式版前の機能です。サブスクリプションIDは、Azureポータルの「サブスクリプション」画面で確認できるアカウントの識別番号です)

運営メンバーの環境で実際に返ってきた答えがこちら(応答の主要部分の抜粋):

{
  "currentTierName": "Free Tier",
  "tierUpgradeEligibilityInfo": {
    "nextTierName": "Tier 1",
    "upgradeApplicableDate": "2026-07-15T17:09:55Z",
    "upgradeAvailabilityStatus": "Available"
  }
}

意味は「現在のランク: Free Tier(最下位)。翌日、Tier 1へ自動昇格予定」。ネットのQ&Aで他人の体験談を漁るより、公式APIで自分のアカウントの生データを見る方が早く確実でした。

あとは人間が毎日確認するのではなく、昇格予定日を過ぎた頃に1回だけこのAPIと利用枠一覧を自動実行して結果を知らせる予約タスクに任せました。翌朝の確認で昇格(currentTierName: "Tier 1")を確認——実際の反映は予告の時刻より半日ほど早く完了していました。なぜ前倒しになったかの公式情報はなく、理由は不明です(利用実績などが影響した可能性はありますが、推測の域を出ません)。

枠が開通したことを確認した後、実際にモデルを使い始める設定の段階で、運営メンバーが実際に踏んだ失敗です。

利用枠の一覧を返すコマンド az cognitiveservices usage list の数値は、実は「トークン/分」そのものではなく、「千トークン/分」を1とする単位で返ってきます(応答の localizedValue という欄に「One Thousand Tokens Per Minute」と明記されています)。つまり画面に limit: 1000.0 と出たら、それは「1,000トークン/分」ではなく「1,000×1,000=100万トークン/分」という意味です。

同じ「1000」でも、単位表記しだいで意味がまったく変わります(下段の例は後述)。

運営メンバーは上段の「1000」をそのまま実際の値だと誤読し、モデル利用開始時の割り当て量(capacity。これも同じ千トークン/分単位)に「1」=1分あたり1,000トークンを指定してしまいました。

会議1本の議事録生成は数千〜数万トークンを使うため、1回の処理を始めた瞬間に上限オーバーで弾かれ、「枠は開通したはずなのに議事録が1本も作れない」という誤解が発生。直前までgpt-5.5の枠がずっと0だった経験が「新しいモデルはどうせ枠が小さい」という先入観になり、誤読を後押しした面もあったようです。

教訓は2つ:

• 数値を鵜呑みにせず、単位表記(localizedValue)を必ず一緒に確認する

az cognitiveservices usage list -l japaneast \
  --query "[].{name:name.value, unit:name.localizedValue, current:currentValue, limit:limit}"

• 「枠が開通したか」の確認と、「実際の設定に正しい値を入れたか」は別の工程。両方を確かめて初めて動作確認が完了する

もう一段の罠: 単位の「軸」そのものが違うモデルもある

「生の値×1,000=実際のトークン/分」というルールは、GPT系だけでなくMistralやCohereなど他社モデルの枠にもほぼ共通して成り立っていました。ただし運営メンバーが全モデルの単位表記を突き合わせたところ、DeepSeekの新しめのモデル(V3.2以降)だけは、単位が「Requests Per Minute」=トークン数ではなく1分あたりのリクエスト回数でした。

つまり、単位を確認せずに「Mistral-Large-3(1,000)とDeepSeek-V3.2(1,000)は同じ枠」と読むと、実際には片方は100万トークン/分・もう片方は1,000回/分という、まったく違う次元の数字を並べて比較していたことになります。同じ一覧に「×1,000する数値」と「そのまま読む数値」が混在しているわけで、「数値の隣の単位表記(localizedValue)を必ず読む」以外に確実な防御策はありません。