Azure OpenAIの利用枠ガイド

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

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

運営メンバーが議事録自動化ツールを構築する過程で実際にこの壁に当たり、Azure公式の確認機能(API=Azureに直接問い合わせて情報を取得する窓口)で原因を特定し、後日の自動昇格を待って解消を確認した記録です(2026年7月時点)。以下の実測部分は運営メンバーの1アカウントによる観測であり、他の団体・契約形態では異なる可能性があります。

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

ここで運営メンバーが最初に考えたのは「予算内で気前よく使えば、利用実績でランクが上がるのでは?」という仮説でした。ただし公式ドキュメントは昇格の判定基準を「利用量の傾向」「契約の種類」「支払い履歴」といった抽象的な言葉でしか説明しておらず、分間の使用率がどう昇格条件に関わるかという計算式は公式には明記されていません。運営メンバーが年$2,000の予算を分単位に均等配分して試算したところ、gpt-5-miniの枠(1分あたり50万トークン)に対して1分あたり数千トークン程度にしかなりませんでした。この程度の使用量では昇格の決め手にはならないのではないか、というのが率直な感触です。ただしこれは運営メンバー個人の推測であり、実際に昇格に影響したかどうかは確認できていません。

代わりに決め手になったのが、「自分のアカウントは今どのランクで、いつ昇格するのか」を直接答えてくれるAzure公式の確認機能でした。

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

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

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

この確認は、昇格予定日を過ぎた頃にブラウザや管理コマンドから手動で行えば十分です。運営メンバーの場合、翌朝の確認で昇格(現在のランクがTier 1に変わったこと)を確認——実際の反映は予告の時刻より半日ほど早く完了していました。なぜ前倒しになったかの公式情報はなく、理由は不明です(利用実績などが影響した可能性はありますが、推測の域を出ません)。

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

先に結論を言うと、Azureの管理画面やコマンドで利用枠を一覧表示したときに出てくる数値は、多くのモデルで「1=1,000トークン/分」という千単位の数値です。数値の隣に小さく書かれた単位表記を見落とすと、実際の上限を1,000分の1に小さく見誤り(逆に言えば、指定した値が意図の1,000倍・1,000分の1になり)、「枠はあるはずなのに使えない」といった誤解や設定ミスにつながります。

言い換えると、確認結果に出てくる数値は多くのモデルで実際の1,000倍を意味します。同じ「1000」という数字でも、隣に書かれている単位の説明しだいで意味がまったく変わります。

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

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

教訓は2つです。

1. 数値を鵜呑みにせず、単位表記を必ず一緒に確認する

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

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

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

「生の値×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する数値」と「そのまま読む数値」が混在しているわけで、「数値の隣の単位表記を必ず読む」以外に確実な防御策はありません。