Azure OpenAI料金ガイド｜従量課金・PTU・Batchの選び方

結論：処理場所を決めてから、従量・Batch・PTUを選ぶ

Azure OpenAIの導入では、最初にデータ処理場所の制約を決めます。制約がなければGlobal、US・EU・APACのデータゾーン内へ限定するならData Zone、Azure geography内に限定する要件があるならRegionalが候補です。その後、需要が変動する同期処理はStandard、待てる大量処理はBatch、安定した高負荷と低い遅延変動が必要ならProvisionedを比較します。

Microsoftは、多くのワークロードでGlobal Standardから始めることを推奨しています。新モデルと機能が先に提供され、既定quotaが大きく、従量課金で需要の下振れリスクを持たないためです。Globalで処理できないデータ要件がある場合だけData ZoneやRegionalへ狭め、対応モデル、価格、quota、可用性を再確認します。

Provisionedは『大量利用なら自動的に安い』契約ではありません。PTU数に応じて利用のない時間も課金され、導入後は停止できず、削除するまで請求が続きます。平均月間トークンではなく、守りたいピーク時間帯のRPM、平均入力・出力、キャッシュ率を使って必要PTUを算出し、未使用容量を含む完了タスク原価で従量課金と比較します。

この節の一次情報：Microsoft Learn｜Deployment types（2026年10月19日確認） ／ Microsoft Azure｜Azure OpenAI Service pricing

Azure OpenAI料金の全体像：モデル単価以外を分けて見積もる

Standard系の基本料金は、入力トークン、キャッシュ入力、キャッシュ書込、出力トークンをモデルとdeployment typeごとの単価へ掛けます。画像、音声、動画、fine-tuning、検索などは別の課金単位を持つ場合があります。Global、Data Zone、Regionalで同額とは限らず、モデルによって利用できる欄も異なります。

Azureの公式料金ページは、リージョン、通貨、契約プログラムによって表示が変わります。記事に固定のドル額だけを転載すると、読者の契約やリージョンと一致しない可能性があります。見積もりでは対象モデル、バージョン、deployment type、リージョン、通貨、Azure契約を固定し、Pricing Calculatorの保存結果と請求meter名を残してください。

モデル推論費のほかに、Azure Monitor・Log Analyticsの取り込みと保持、Application Insights、Private Link、Key Vault、API Management、ネットワーク、ストレージ、検索基盤などの費用が加わります。社内原価では、タイムアウト、再試行、フォールバック、品質検品も同じ親タスクへ結び付けます。

• モデルID・バージョン・deployment type・リージョンを固定する
• input、cached input、cache write、outputを分けて集計する
• リアルタイム、優先処理、Flex、Batchを別の料金表で扱う
• ログ、ネットワーク、検索、セキュリティなど周辺Azure費を加える
• 公開価格、EA等の契約価格、税、為替、請求meterを区別する

この節の一次情報：Microsoft Azure｜Azure OpenAI Service pricing

Global・Data Zone・Regional：データ保存と推論処理を混同しない

GlobalはAzureの利用可能な地域へ推論処理を動的に振り分けます。Microsoftは、最大の既定quota、幅広いモデル提供、新モデルと機能の早い展開を特徴として挙げています。一方で、安定して非常に大きな負荷を流す場合はレイテンシの変動が大きくなる可能性があり、必要ならProvisionedを比較します。

Data Zoneは、推論処理をUS、EU、APACのいずれかのデータゾーン内へ限定します。APACは単一のAzureリージョンではなく、Microsoftが定義するアジア太平洋の複数地域です。保存データは指定したAzure geographyに残る一方、推論処理の範囲はdeployment typeで変わるため、保存場所の設定だけで判断しません。

StandardとRegional Provisionedは、顧客が指定したAzure geography内で処理します。ただしモデル、バージョン、地域、deployment typeのすべての組み合わせが提供されるわけではありません。地域を狭めるほど、モデル公開時期、quota、容量、価格の選択肢が減る可能性を契約要件と一緒に評価します。

この節の一次情報：Microsoft Learn｜Data processing locations

Standard・Priority・Flex・Batch：従量課金でも処理経路を分ける

Standard系は使ったトークンに応じる従量課金で、PoC、需要の読めない新機能、日内変動の大きい本番に向きます。Global Standardでは、対応モデルについてリクエスト単位のPriority processingとFlex processingも選べます。Priorityは応答速度を重視し、Flexは遅延を許容して費用を抑えるための経路です。対応モデルと単価は料金表で確認します。

Global BatchとData Zone Batchは、Global Standard比50%引きで非同期ジョブを処理し、目標完了時間は24時間です。リアルタイムSLAはなく、24時間を超える可能性も公式に明記されています。評価、分類、抽出、要約、コンテンツ生成など、個々のレコードが独立し、結果を後で受け取れる処理に向きます。

オンライン処理をすべてPriorityへ、夜間処理をすべてBatchへ移す必要はありません。同じ製品の中でも、顧客向け応答、社内処理、評価、再計算を分け、処理期限と失敗時の再実行方法に合う経路を選びます。安さだけでなく、遅延による再試行と運用工数を含む完了タスク原価で比較します。

この節の一次情報：Microsoft Learn｜Global Standard・Batch・processing tiers

Provisioned Throughput：使ったトークンではなくPTU容量へ支払う

Provisioned Throughput Unit（PTU）は、モデル処理容量を表す単位です。作成したdeploymentへPTUを割り当てると、その容量が保持され、処理がない時間もPTU数に応じて時間課金されます。Global、Data Zone、RegionalのProvisionedがあり、処理場所と容量保証を組み合わせて選びます。

時間課金は分単位で按分され、PTU数を変更すると新しい数量へ直ちに切り替わります。ただしdeploymentを一時停止する機能はなく、請求を止めるには削除が必要です。縮小した容量はプールへ戻り、後から同じ数量へ戻せる保証もありません。イベントのたびに縮小・拡大する運用は、価格と再確保の両方でリスクがあります。

PTU quotaと実際のcapacityは別です。quotaがあっても、その地域とdeployment typeで新しいPTUを確保できるとは限りません。Microsoftは、予約を購入する前にProvisioned deploymentを作成し、必要容量を確保するよう案内しています。予約購入そのものはサービス容量を保証しません。

この節の一次情報：Microsoft Learn｜Provisioned throughput billing ／ Microsoft Learn｜Provisioned throughput concepts

必要PTUの計算：ピークRPM・入出力・キャッシュ率を使う

必要PTUは月間トークン総量からは計算できません。Microsoftの式は、ピークRPM×平均入力でinput TPM、ピークRPM×平均出力でoutput TPMを出し、モデル固有のoutput-to-input比率を使ってnormalized TPMへ変換します。最後にモデル固有の1 PTU当たりTPMで割り、購入可能な増分へ切り上げます。

公式例では、gpt-5.2 Data Zone Provisionedへピーク1,000 RPM、平均入力200、平均出力20を流す場合、入力200,000 TPM、出力20,000 TPMです。出力比率8を使うとnormalized TPMは360,000となり、3,400 TPM/PTUで割って105.88、5 PTU単位へ切り上げて110 PTUです。

同じ例で入力の50%がキャッシュされると、公式計算ではnormalized TPMが260,000となり、必要量は80 PTUへ下がります。ただし新しいnormalized-token accountingを使うGPT-6 Astra、GPT-6 Sol、GPT-6.1 Solなどでは、キャッシュ読込と書込にもモデル固有の重みがあります。古い『キャッシュ分を100%控除』の式を流用せず、対象モデルの最新表を使います。

この節の一次情報：Microsoft Learn｜Determine PTU sizing（公式式・計算例）

損益分岐の出し方：表示単価ではなく使用率を入れる

従量課金の月額は、入力、キャッシュ、出力などの実測トークンへ対象単価を掛けた合計です。Provisionedの月額は、PTU数×PTU時間単価×稼働時間が基準です。予約を使う場合は予約の実効単価へ置き換え、予約数量を超えたPTUの時間課金、未使用予約、周辺Azure費を加えます。

比較で重要なのは、PTUを100%使い切った場合の理論単価ではありません。業務時間に山がある、週末に使わない、モデル移行で需要が減ると、未使用時間を含む実効単価が上がります。『PTU費用÷品質条件を満たして完了したタスク数』を従量課金側の同じ指標と比べます。

料金ページの金額はリージョン、通貨、契約で変わるため、ここでは固定の損益分岐額を断定しません。対象条件でAzure Pricing Calculatorを保存し、2〜4週間の本番ログへ当てます。PTUはp95負荷を満たす数量、従量側は再試行を含む実請求量として、需要が20%・50%下振れしたケースも計算します。

この節の一次情報：Microsoft Azure｜Pricing Calculator ／ Microsoft Learn｜PTU billing and reservations

Azure Reservations：1カ月・1年の割引とcapacityを分ける

Provisionedは時間課金のまま短期検証でき、持続的な本番利用にはAzure Reservationsによる割引があります。公式条件は1カ月または1年です。予約はPTU billing meterへ適用される金銭的な割引であり、deploymentの作成やcapacity確保とは独立しています。

Global、Data Zone、Regionalの予約は別商品です。Globalの予約をRegionalへ適用することはできません。適用範囲はリソースグループ、サブスクリプション、管理グループ、請求アカウントなどから選べ、条件が一致するdeploymentへ予約数量まで割引が適用されます。超過PTUは通常の時間単価です。

予約数量を下回るようdeploymentを縮小しても、予約自体は元の数量で継続し、未使用分が生じます。キャンセルや交換は可能ですが、手数料や上限が適用される場合があります。モデル更新の周期、需要の下振れ、組織変更を考え、短期の時間課金で負荷試験してから期間を選びます。

• 先にdeploymentを作成し、必要PTUのcapacityを確保する
• Global・Data Zone・Regionalの種類を予約と一致させる
• 割引率、1カ月／1年、支払方法、適用scopeを確認する
• 未使用予約と超過PTUを別々に月次集計する
• モデル移行・需要下振れ・解約交換条件を契約前に確認する

この節の一次情報：Microsoft Learn｜Azure Reservations for PTU

向くケース・向かないケースと導入判断フロー

Global Standardが向くのは、PoC、新規機能、需要変動の大きい本番、モデルを頻繁に更新するチームです。Data Zone StandardやStandardは、処理場所の要件を守りつつ従量課金の柔軟性を残したい場合に向きます。Batchは、24時間の完了目標を受け入れられる独立した大量処理で優先的に比較します。

Provisionedが向くのは、毎日継続する大口負荷があり、共有容量のレイテンシ変動やcapacity不足が顧客体験へ直接影響するケースです。必要PTUを継続利用でき、運用チームがcapacity、使用率、予約、spilloverを監視できることが前提です。

需要が短時間だけに集中する、週末は使わない、モデル更新が多い、処理をBatchへ移せる、必要capacityを確保できない場合は、Provisionedの固定費と運用負荷が不利になりやすくなります。最初から予約せず、Global Standardでログを取り、非同期化とキャッシュを先に適用し、残った安定負荷へPTUを当てます。

• 推論処理をGlobalへ出せるか → 可能ならGlobal Standardから開始
• US・EU・APAC内へ限定するか → Data Zone系を比較
• Azure geography内へ限定するか → Standard／Regional Provisionedを確認
• 結果を後で受け取れるか → Global／Data Zone Batchを比較
• 安定した高負荷と低い遅延変動が必要か → PTUを実測評価
• PTUを継続利用できるか → 時間課金から始め、予約は後で購入

導入時の確認事項：料金と性能を同じタスクへ結び付ける

アプリのログには、親タスクID、deployment名、モデルとバージョン、deployment type、リージョン、処理tierを残します。入力、キャッシュ読込・書込、出力の各トークン、最初のトークンまでの時間、出力速度、全体時間、429、5xx、タイムアウト、再試行、最終成功を同じタスクへ結び付けます。

PTU評価では、月平均ではなく5分・15分単位のピークRPMとTPM、capacity使用率、spillover、429、p95・p99を確認します。公式calculatorの推定だけで契約せず、代表的な本番プロンプトと同時実行数で負荷試験します。入出力比率や長文、画像、キャッシュでcapacity消費は変わります。

運用開始後は、Azure料金表、モデル提供地域、PTUパラメータ、quotaを同じ確認日で月次レビューします。新モデルへ移行すると1 PTU当たりTPMやoutput-to-input比率が変わるため、品質だけでなく必要PTUと予約適用も再計算します。

FAQ

Q. Azure OpenAIは月額固定ですか？　A. Standard、Global Standard、Data Zone Standardは基本的に使ったトークンの従量課金です。Provisionedは割り当てたPTU数に対する時間課金で、Azure Reservationsを使うと1カ月または1年の割引契約になります。

Q. Azure OpenAIとOpenAI APIの料金は同じですか？　A. 別の料金表と請求です。Azureではリージョン、deployment type、通貨、Azure契約によって条件が変わります。OpenAI公式APIの単価をAzure請求へそのまま当てないでください。

Q. 最も安いdeployment typeはどれですか？　A. 非同期化できる対応処理ならBatchがGlobal Standard比50%引きです。リアルタイムではモデルと条件によりFlexが候補です。ただし、待ち時間、再試行、対応機能、運用工数を含む完了タスク原価で比較します。

Q. PTUを買えばcapacityは必ず確保できますか？　A. Azure Reservationの購入はcapacityを保証しません。先にProvisioned deploymentを作成して容量を確保し、その後に一致する種類とscopeの予約を購入します。

Q. PTU deploymentは停止できますか？　A. 公式仕様では一時停止できません。PTU数を変更するか、請求を止めるにはdeploymentを削除します。縮小後に同じcapacityを再確保できる保証はありません。

Q. GlobalならデータがAzure外へ保存されますか？　A. Globalという名称は主に推論処理の範囲です。保存データは指定したAzure geographyに残る一方、プロンプトと応答の処理は利用可能なAzure地域へ動的に振り分けられます。自社の規制・契約要件で確認してください。

Q. 必要PTUは月間トークンから計算できますか？　A. できません。ピークRPM、平均入力・出力、キャッシュ率、モデル固有のTPM per PTUとoutput比率を使い、増分単位へ切り上げます。calculatorの結果は本番相当の負荷試験で検証します。