Azure OpenAI PTUとは？必要ユニット数の見積もりと予約課金の損益分岐

PTU（Provisioned Throughput Unit）は、Azure OpenAI／Microsoft Foundry でモデルの処理能力を確保する単位です。標準デプロイのようにトークン量で課金されるのではなく、デプロイした容量に対して1時間ごとに課金されます。この記事では、PTUが何を表すのか、ワークロードから必要PTU数をどう逆算するのか、時間課金と1か月／1年の予約をどの稼働率で切り替えるのかを、2026年8月時点の公式ドキュメント実測値から整理します。容量設計とコスト判断に絞った内容です。

まとめ：PTU採用の可否を分ける稼働率・必要ユニット数・予約期間の三点

結論から示します。PTUの導入可否は「ピーク時のトークン量」ではなく、そのピークが月730時間のうち何時間続くかで決まります。デプロイは一時停止できず、削除するまで毎時課金が続くためです。実効稼働率が半分に届かない用途なら、標準デプロイのまま実測を続けたほうが安く収まります。

必要PTU数は計算で出せます。ピークRPM・平均プロンプト長・平均応答長・キャッシュ率を正規化TPMに変換し、モデルごとの「PTUあたり入力TPM」で割る。gpt-5.2 で 1,000 RPM・入力200トークン・出力20トークンなら110 PTU、キャッシュが5割効けば80 PTUです。

予約は1か月か1年のコミットで $/PTU/時 の実効単価が下がる仕組みで、デプロイとは疎結合。モデル非依存のため、モデル更改の予定があっても予約が無駄になるとは限りません。ただし予約を買っても容量は確保されないので、順序は必ず「デプロイを作ってから予約を買う」。逆順の購入がPTU導入で最も多い金銭的な失敗です。

PTUの単位定義と課金対象：トークン量ではなく確保容量で決まる時間課金

PTUが表す処理能力とモデル非依存で共有されるクォータの割り当て単位

PTUはモデルの処理能力を表す汎用の単位です。デプロイ作成時に割り当てるPTU数を指定すると、Foundry はその分の計算資源を確保して保持します。リクエストが1件も来ない時間帯も、確保している以上は課金対象です。

特徴的なのは、PTUが特定モデルに紐づかない点です。クォータはサブスクリプション単位・リージョン単位・デプロイ種別単位で付与され、そのプールからサポート対象の任意のモデルをデプロイできます。「gpt-5.2用のPTU」という買い方ではありません。ただしリージョンをまたいだ持ち越しは不可で、米国東部の枠は西ヨーロッパで使えません。モデル系統ごとの選び方はAzure OpenAI Serviceのモデル一覧と選び方で整理しています。

デプロイ作成から削除までが対象になる時間課金の範囲と按分の扱い

課金メーターはデプロイを作成した時点で回り始め、削除した時点で止まります。300 PTUのデプロイなら、1時間あたりの単価×300が毎時計上されます。1時間に満たない場合は按分され、15分だけ存在したデプロイは1時間分の4分の1で計算されました。

実務で効いてくるのは、一時停止という選択肢が存在しない点です。夜間だけ止めて課金を抑える運用はできません。止めるには削除するしかなく、解放した容量はリージョンのプールに戻ります。なおサイズ変更は即時に課金へ反映され、リサイズ完了時点から新しいPTU数の分単位で日割り計算されます。

標準・バッチ・優先度処理と比べたときの課金軸とSLAの位置づけ

デプロイの種類は4つ。標準とバッチはトークン従量で待機時間SLAがなく、優先度処理は優先レートのトークン従量にモデルごとの待機時間目標が付きます。PTU単位の時間課金または予約で課金されるのはプロビジョニング済みだけです。待機時間の一貫性だけが欲しいなら優先度処理、非同期でよい一括処理ならバッチの割引レートで足ります。PTUを選ぶ理由は、専用容量による待機時間の一貫性と大量トラフィックでの単価改善、その両方が要るときに限られます。

必要PTU数の見積もり手順：正規化TPMから逆算する計算式と切り上げ単位

ピークRPMとプロンプト長・応答長から正規化TPMを出す計算式

入力は4つです。ピーク時のRPM（1分あたり呼び出し数）、平均プロンプトサイズ、平均応答サイズ、プロンプトキャッシュのヒット率。これらを次の順で1つの数値に畳み込みます。

1. 入力TPM ＝ ピークRPM × 平均プロンプトサイズ
2. 出力TPM ＝ ピークRPM × 平均応答サイズ
3. 正規化TPM ＝ 入力TPM ×（1 − キャッシュ率）＋ 出力対入力比 × 出力TPM
4. 必要PTU ＝ 正規化TPM ÷ PTUあたり入力TPM

キャッシュされたトークンは使用率の計算から全額差し引かれ、PTU容量を消費しません。同じシステムプロンプトを繰り返し送る構成では、ここが必要PTU数を直接押し下げます。キャッシュの仕組み自体はプロンプトキャッシュの解説で扱っています。

PTUあたり入力TPMと出力対入力比のモデル別実測値と読み替え方

計算に使う2つの係数はモデルごとに公開されています。2026年8月16日時点の公式ドキュメントから代表値を抜き出します。

出力対入力比は、出力1トークンを入力何トークン分として数えるかの重みです。gpt-5系の多くは8、gpt-5.4以降の一部は6、gpt-4.1系とgpt-4oは4。原則としてモデルのグローバル標準価格比に一致し、Llama-3.3-70B-Instruct のような例外もあります。応答が長い用途ほど、この重みが必要PTU数を押し上げます。

gpt-5.2で1,000RPMを捌く場合の必要PTUとキャッシュ率50%の差

公式の計算例を追います。データゾーンプロビジョニングで gpt-5.2、ピーク1,000 RPM、平均プロンプト200トークン、平均応答20トークン、キャッシュなしという条件です。

入力TPMは 1,000 × 200 = 200,000、出力TPMは 1,000 × 20 = 20,000。正規化TPMは 200,000 ＋ 8 × 20,000 = 360,000。これを gpt-5.2 のPTUあたり入力TPM 3,400 で割ると 105.88 となり、増分5に切り上げて110 PTUです。

同じ条件でプロンプトキャッシュが50%効けば、入力側は 100,000 に下がり、正規化TPMは 260,000、必要PTUは 76.47 で切り上げ80 PTU。キャッシュ率だけで3割近く削れます。裏を返せば、キャッシュ設計をしないままサイジングすると、その分の容量を毎時買い続けることに。

最小デプロイPTUとスケール増分がデプロイ種別で変わる切り上げ制約

計算結果はそのまま使えず、種別ごとの最小値と増分に丸められます。グローバル／データゾーンでは gpt-5系・gpt-4.1系とも最小15 PTU・増分5と細かい一方、リージョンプロビジョニングでは gpt-5.2 が最小50 PTU・増分50。小型モデルは25刻みです。

この差は小規模用途で効いてきます。計算上18 PTUで足りるワークロードでも、単一リージョン所在地の要件から種別を選べば50 PTUの購入となり、実需要の2.8倍を毎時支払う構成に。DeepSeek-R1 のように最小100 PTU・増分100のモデルは粒度がさらに粗く、小規模案件では最初に候補から外すほうが速く済みます。

デプロイ種別と容量確保：グローバル・データゾーン・リージョンの選択条件

三種類のデプロイ種別のルーティング範囲とデータ所在地の選択条件

種別は3つ。グローバル（sku-name は GlobalProvisionedManaged）はAzureリージョン間をまたいでルーティングされ、データゾーン（DataZoneProvisionedManaged）は米国またはEUの地理ゾーン内に、リージョン（ProvisionedManaged）は特定リージョン内に留まります。専用容量と待機時間の一貫性は3種別とも共通で、違いは処理される場所と最小単位だけ。所在地要件を社内審査で説明する案件は、要件を確定させてから種別を選んでください。順序が逆になるとデプロイのやり直しになります。種別ごとに日本のリージョンで何が取れるかは、Azure OpenAIのリージョン選定にデプロイの種類別の実測をまとめました。

クォータと容量の違いおよびデプロイ失敗を避けるための事前確認の手順

クォータと容量は別物です。クォータはサブスクリプション・リージョン・デプロイ種別ごとの上限を示すポリシー制限で、それ自体に費用は発生しません。容量は実際にデプロイできるPTUの実在量で、顧客需要に応じて1日のうちでも変動します。クォータが余っていても、容量が足りなければデプロイは失敗。事前確認はFoundryポータルのデプロイ画面（不足時は代替リージョンが提示されます）かモデル容量APIで行い、空きがなければ、少ないPTUで試す・時間をおいて再試行・クォータ要求フォームを出す、の順に切り分けます。増枠申請の実務はAzure OpenAIでGPT-5を使う方法で扱っています。

時間課金と予約の損益分岐：稼働率と契約期間で決まる採用ラインの引き方

時間課金が向く短期用途と本番運用でスケール戦略を避けるべき理由

時間課金が向くのは短期のシナリオです。予約にコミットする前のモデル品質・性能のベンチマーク、ハッカソンのような一時的な増強。公式ドキュメントは本番デプロイでの時間課金を非推奨としています。

理由は2つ。1つは単価で、予約には時間課金に対する相応の割引が付くため、本番相当のサイズを予約下で維持するほうが、トラフィックに合わせて上げ下げする運用より安く収まります。もう1つは容量リスク。クォータが余っていてもスケールアップ時に容量が取れる保証はありません。夜間に縮めて朝に戻す運用は、いちばん必要なタイミングで容量を失う設計です。

予約割引が適用される三条件と数量を超えた分に発生する時間課金

Azure予約はデプロイではなく課金メーターへの料金割引で、1か月または1年のコミットに対し $/PTU/時 の実効単価が下がります。割引が自動適用されるのは、実行中のデプロイと予約が次の3条件をすべて満たす場合です。

• デプロイ種別の一致（グローバル・データゾーン・リージョンは相互に流用できない）
• リージョンの一致（ただしグローバル予約はリージョン非固定で、複数リージョンのグローバルPTUデプロイをまとめてカバーできる）
• スコープの包含（予約のスコープにデプロイのサブスクリプションまたはリソースグループが含まれること）

照合はモデル名やデプロイIDでは行われません。グローバル予約の非固定性は集約に使えます。米国東部50・西ヨーロッパ100・オーストラリア東部200のグローバルデプロイがあるなら、任意のリージョンで350ユニットの予約1本にまとめて3拠点をカバーできます。

予約超過とスケールダウン時の課金挙動を追う500PTUの実例

公式の例で挙動を確認します。500 PTUのグローバル予約を購入し、既存デプロイが各リージョン合計で300 PTUを消費している状態に、DeepSeek-R1 のグローバルデプロイを追加するケースです。

逆方向も押さえてください。スケールダウンしても予約は元の数量のまま継続し、下回った分は未使用として残ります。予約使用率が100%未満なら、買いすぎか、解約せずにデプロイを消したかのどちらかです。キャンセルや交換には早期終了料金が発生する場合があり、種別をまたぐ交換はサポート対象外。グローバルからリージョンへ移すには解約と買い直しが要ります。

月730時間とピーク持続時間から損益分岐を出す試算の組み立て方

単価は $/PTU/時 の形でモデルファミリごとに定義され、Azureの価格ページと料金計算ツールで確認します（2026年8月16日時点、価格ページの表示は見積り扱いのため、契約前に自社の課金アカウントで実額を確認してください）。ここでは時間単価をPと置き、判断の型だけを示します。

先の110 PTU構成なら月額は 110 × 730時間 × P ＝ 80,300P で、稼働時間に関係なく固定。対する標準デプロイ側は、ピーク1,000 RPMが1日8時間・週5日だけ立つ業務システムなら月の実処理時間は約174時間（8×5×4.35）です。入力200,000 TPMで10,440分なら入力約20.9億トークン、出力は約2.1億トークン。百万トークン単価を入力i・出力oとすれば、月額は 2,088i ＋ 208.8o となります。

この2つが釣り合う点が損益分岐で、決め手は 174 ÷ 730 ＝ 約24% という実効稼働率です。PTUは残り76%の時間も同額を払い続けます。判断は言い切ります。営業時間帯だけにピークが立つ社内システムでは、実効稼働率が5割に届かないうちPTUへ移さない。まず標準デプロイで実トラフィックを1か月測り、正規化TPMとピーク持続時間を把握してから予約前提で切り替えを検討する。この順序だけで初期の過剰投資はほぼ防げます。

期間の選択も同じ枠組みです。1か月予約はトラフィック形状が固まらない導入直後、1年予約は稼働率が安定した段階。「モデルが更改されたら1年予約が無駄になる」という懸念は不要で、予約はモデル非依存のため、スコープ内に新モデルをデプロイすれば既存予約が自動的にカバーします。モデル廃止への備え方と予約の契約期間は、切り離して考えて構いません。

スパイクとバーストの受け止め方：スピルオーバーと長文要求のルーティング

429応答を標準デプロイへ流すスピルオーバーの適用範囲と制限

スピルオーバーは、プロビジョニング済みデプロイが使い切られて200以外の応答（PTU枯渇時の429など）を返す状況で、同じFoundryリソース内の標準デプロイへ要求を自動転送するオプション設定です。既定では有効になりません。対応範囲にも制限があり、プロビジョニング済みスループットをサポートするAzure OpenAIモデルはすべて対応する一方、DeepSeekやMeta Llamaなど他プロバイダーのFoundryモデルは現時点で非対応。DeepSeek系でPTUを組むなら、バースト時の退避先はアプリケーション側で用意することになります。

128kトークン超の長文要求の扱いとヘッダー単位での制御方法

待機時間目標には除外条件があります。gpt-5.4・gpt-4.1・gpt-4.1-mini・gpt-4.1-nano では128kプロンプトトークンを超える要求が対象外で、システムはそれをスピルオーバー先へルーティングし、転送先がなければエラーを返します。長文要約やRAGで巨大なコンテキストを流す構成は、この経路を必ず用意してください。x-ms-spillover-deployment ヘッダーを使えば、対話UIの要求はPTUで処理し、内部のバッチ処理だけスピルオーバーを許可する、といった要求単位の振り分けも可能です。待機時間目標はモデルごとに定義され、gpt-5.2 は99%の要求が50 TPS超、gpt-5.4-mini は100 TPS超、gpt-4o は25 TPS超という水準でした（2026年8月16日時点）。

PTUを採用する条件と見送る場面：ピーク持続時間で切り分ける判断基準

PTUに踏み切る条件：ピーク持続時間・レイテンシ要件・最小単位

次の3つが揃ったときにPTUへ移します。第一に、ピークトラフィックが月730時間の半分以上を占めること。第二に、待機時間の一貫性が業務要件として明文化されていること（対話UIやエージェントの応答時間がSLAに書かれている場合など）。第三に、計算で出た必要PTU数が、選ぶ種別の最小デプロイ単位を上回っていること。

3つ目を軽く見ないでください。gpt-5.2 をリージョンプロビジョニングで使うなら最小50 PTU・増分50のため、必要PTUが30と出たワークロードは6割超の余剰を抱えます。所在地要件が単一リージョンまで求めていないなら、データゾーン種別（最小15・増分5）へ落として粒度を細かくするほうが妥当です。

予約を先に買う失敗パターンとPoC段階で見送るべき具体的な場面

もっとも高くつく失敗は、デプロイより先に予約を購入することです。予約は容量を確保しません。購入後に目的のリージョンで容量が取れなければ、使えないPTUに料金を払い続け、解約には早期終了料金がかかる可能性があります。手順は「デプロイを作って容量を確認」「デプロイ済みPTUに数量を合わせて予約を購入」の順で固定してください。予約購入に必要なAzureロールとテナントポリシーの要件はFoundryのリソース作成権限とは別物なので、承認経路の確認も先に済ませておきます。

見送るべき場面も挙げます。PoC段階でトラフィック形状が不明なうち、日次バッチ中心でレイテンシ要件のない処理（バッチデプロイの割引レートのほうが安く済みます）、社内数十人が不定期に使う程度の利用量、最小デプロイ単位が実需要を大きく超える小型ユースケース。これらでPTUを選ぶと、専用容量の利点を受け取れないまま固定費だけが増えます。判断段階の整理はAzure OpenAI Service導入支援の進め方にまとめました。

内製と外部委託の分担で決める容量設計とベンチマーク実施の進め方

サイジングの精度は推定値ではなく実測に依存します。公式ドキュメントも、推定入力だけに頼らず代表的なトラフィックでベンチマークすることを推奨しています。標準デプロイでアプリケーションを走らせ、実RPM・実トークン長・キャッシュヒット率をログから取り、その数値を計算式に入れる。この流れなら手戻りが出ません。

社内で担うのは業務要件の確定（ピーク時間帯・許容待機時間・データ所在地）とログ計測、外部に任せて効くのは計測基盤の設計・負荷試験・切り替え時の回帰テストです。生成AI開発・AI受託開発では、標準デプロイでの実測からPTUサイジング、予約購入までの容量設計を支援しています。サービス自体の全体像はAzure OpenAI Serviceの基本と料金の解説を参照してください。

よくある質問

PTUの検討で実際に挙がる質問を5つ取り上げます。

PTUと標準デプロイはどちらが安いのですか？

トラフィックの持続時間で逆転します。PTUはデプロイが存在する限り毎時課金されるため、ピークが一部の時間帯にしか立たない用途では実効稼働率がそのまま割高さになりました。常時高負荷が続く大規模用途なら、トークン従量より単価は下がります。判断軸は「ピーク時のトークン量」ではなく「そのピークが月に何時間続くか」です。

必要なPTU数はどう見積もればよいですか？

ピークRPM・平均プロンプトサイズ・平均応答サイズ・キャッシュ率の4つを用意し、正規化TPM＝入力TPM×(1−キャッシュ率)＋出力対入力比×出力TPM を計算して、モデルのPTUあたり入力TPMで割ります。gpt-5.2 で1,000 RPM・入力200・出力20なら110 PTU。Foundryポータルの容量計算ツールでも同じ計算ができます。

予約は1か月と1年のどちらを選ぶべきですか？

トラフィックが安定しているかで決めます。形状が読めない導入直後は1か月、実効稼働率が安定した段階は1年。割引率はモデルファミリと期間で変わります。予約はモデル非依存でスコープ内の対象デプロイに自動適用されるため、将来のモデル更改を理由に1年を避ける必要はありません。

PTUを一時停止して課金を止められますか？

できません。一時停止の機能はなく、課金が止まるのはデプロイを削除したときだけです。夜間や休日に止める前提でコストを見積もると、実際の請求と乖離します。削除すれば容量はリージョンのプールへ戻るため、再作成時に同じ容量を取れる保証もない点に注意してください。

予約を買えば容量は確保されますか？

されません。予約は課金メーターに対する料金割引で、サービス側のキャパシティ予約ではないためです。容量はデプロイ作成時に割り当てられ、その有効期間中だけ保持されます。正しい順序は、先にデプロイを作成して容量が取れることを確認し、そのデプロイ済みPTU数に合わせて予約を購入する。逆順だと使えないPTUの費用を払う状態になり得ます。

関連記事

• Azure OpenAI Serviceとは？できること・料金・導入事例まで実務目線で解説：サービス全体の定義と料金体系の全体像を確認できます
• Azure OpenAI Serviceのモデル一覧と選び方：PTUを割り当てる対象となるモデル系統と選定の順序を扱っています
• Azure OpenAIでGPT-5を使う方法｜デプロイ・クォータ・推論パラメータの実装手順：クォータ階層とレート制限の読み方を実装手順から追えます
• Azure OpenAIのモデル廃止に備える方法：予約期間と切り離して考えるべきモデル移行の進め方をまとめています
• Azure OpenAI Service導入支援の進め方｜五工程と外部委託の判断基準：容量設計を含む導入全体の意思決定順序を発注視点で整理しています