Azure AI FoundryでProvisioned throughput unit（PTU）を使う場合、最初に押さえるべき結論は 「PTUは使ったトークン量ではなく、デプロイした処理容量に対して課金される」 という点です。短期検証なら時間単位課金で始められますが、本番で継続利用する場合はAzure Reservationsによる割引適用、クォータと実容量の確認、削除時の課金停止手順まで含めて設計しないと、想定外のコストが発生しやすくなります。
この記事では、Azure AI Foundryの「Provisioned throughput unit (PTU) costs and billing – Microsoft Foundry」で整理された公式情報をもとに、PTU課金の変更点、影響範囲、管理者・開発者が確認すべき設定、移行・展開時の注意点を実務目線で解説します。特に、Azure OpenAIやFoundry Modelsを本番環境で使うチーム、FinOps担当者、Azure管理者は、予約を買う前に「デプロイが作成できるか」を必ず確認してください。
Azure AI FoundryのPTU costs and billingで押さえるべき結論
Azure AI FoundryのPTU課金で重要なのは、次の4点です。
| 確認ポイント | 実務上の意味 |
|---|---|
| PTUはデプロイ済み容量に対して時間単位で課金される | リクエストが少なくても、PTUデプロイが存在すれば課金対象になる |
| Azure Reservationsは割引の仕組みであり、容量確保そのものではない | 予約を買っても、モデルをデプロイできる実容量が保証されるわけではない |
| クォータは容量保証ではない | クォータがあっても、対象リージョン・モデルの実容量が不足するとデプロイに失敗する可能性がある |
| デプロイ削除と予約管理は別操作 | デプロイを消しても予約は自動で取り消されない。予約のキャンセル・交換はAzure portal側で別途管理する |
公式ドキュメントでは、Regional Provisioned、Data Zone Provisioned、Global Provisionedの各デプロイは、デプロイされたPTU数に基づいて時間単位で課金され、Azure Reservationsの購入により割引を受けられると説明されています。さらに、不要な課金を避ける推奨順序として、先にFoundryでモデルをデプロイし、その後にデプロイ種別・リージョン・サブスクリプションに合う予約を管理者が購入または確認する流れが示されています。(Microsoft Learn)
PTUとは何か：トークン従量課金ではなく「処理容量」を確保する仕組み
PTUは、モデルのプロンプト処理と補完生成に必要なスループットを確保するための、モデル処理容量の単位です。Azure AI Foundryでは、PTUはサブスクリプションにクォータとして付与され、クォータはリージョンごとに管理されます。つまり、あるリージョンで使えるPTU数が、そのサブスクリプション内でデプロイに割り当てられる上限になります。(Microsoft Learn)
Standardのようなトークン従量課金と違い、PTUは「必要な処理能力をあらかじめデプロイする」考え方です。そのため、次のようなワークロードに向いています。
| 向いているワークロード | 理由 |
|---|---|
| 予測可能な高トラフィックの本番アプリ | 一定の処理容量を確保し、レイテンシのばらつきを抑えやすい |
| 社内AIチャット、業務エージェント、検索拡張生成（RAG） | 利用時間帯やリクエスト量を見積もりやすい場合、容量計画を立てやすい |
| SLAや応答速度が重要なサービス | Provisioned系はStandard系より一貫したスループット・低レイテンシを狙いやすい |
| 長期運用する生成AI基盤 | Azure Reservationsで割引を適用しやすい |
一方で、アクセスが月に数回しかないPoC、利用量が読めない検証環境、突発的な小規模利用では、PTUよりStandardやBatchのほうが扱いやすい場合があります。Microsoftのデプロイ種別の説明でも、変動が大きいバースト型トラフィックにはStandard系、一貫した高ボリュームにはProvisioned系が適すると整理されています。(Microsoft Learn)
何が変わるのか：時間課金とAzure Reservationsを前提に考える
今回の「Provisioned throughput unit (PTU) costs and billing」で実務上大きいのは、PTUを単なる固定契約ではなく、時間単位課金と予約割引を組み合わせて運用する前提 が明確になっている点です。
短期利用は時間単位課金で始められる
Regional Provisioned、Data Zone Provisioned、Global Provisionedのデプロイは、デプロイされたPTU数に対して時間単価で課金されます。たとえば300 PTUのデプロイであれば、時間単価に300を掛けた料金が基本になります。部分的な時間だけ存在したデプロイは分単位で按分され、15分だけ存在したデプロイは1時間料金の4分の1として扱われます。(Microsoft Learn)
この仕組みは、新モデルの性能検証、短期間のベンチマーク、ハッカソンや一時的なイベント対応に向いています。短期であれば、まず時間課金でデプロイし、性能・必要PTU数・実際のトークン使用量を見てから予約を検討できます。
本番環境では「時間課金だけで自動スケール」は避けたい
注意したいのは、本番環境でトラフィックに応じてPTUを増減させ、すべて時間課金だけで運用する設計です。公式ドキュメントでは、本番デプロイを受信トラフィックに合わせてスケールし、純粋な時間課金で払う方法は推奨されていません。理由は、Azure Reservationsによるコスト削減効果が大きいことに加え、未使用クォータがあっても必要なタイミングで実容量が利用できるとは限らないためです。(Microsoft Learn)
実務では、ピーク時に必要なPTUを見積もり、安定稼働に必要な分は恒久的なデプロイとして維持し、予約割引を適用する設計が基本になります。
Azure Reservationsは「容量予約」ではなく「割引の適用条件」
Azure Reservationsは、PTUデプロイそのものを作成する機能ではありません。課金メーターに対して割引を適用する購入・割引の仕組みです。デプロイと予約は疎結合であり、デプロイの作成・削除と予約の購入・交換・キャンセルは別々に行います。(Microsoft Learn)
ここを誤解すると、次のような失敗が起きます。
| 誤解 | 起きる問題 | 正しい対応 |
|---|---|---|
| 予約を買えば容量も確保される | 予約購入後に対象リージョンでデプロイできず、予約を使い切れない | 先に対象モデルをデプロイし、容量が取れたことを確認してから予約を買う |
| Global、Data Zone、Regionalの予約は相互に使える | デプロイ種別が一致せず、割引が適用されず時間課金になる | デプロイ種別ごとに予約を分ける |
| デプロイを削除すれば予約も消える | 予約が残り、利用しない割引枠の費用が続く可能性がある | Azure portalのReservationsで予約を別途確認する |
| 予約数を多めに買えば安心 | 使われない予約PTUは繰り越されず、無駄なコストになる | 実際にデプロイ済みのPTU数に合わせる |
Microsoftの予約ドキュメントでも、Global、Data Zone、Regionalの予約は相互に交換可能な割引枠ではなく、デプロイ種別ごとに別の予約が必要と説明されています。また、Global予約は条件を満たせば複数リージョンのGlobal PTUデプロイをまとめてカバーできますが、Data ZoneやRegionalのデプロイに流用できるわけではありません。(Microsoft Learn)
影響範囲：誰が確認すべきか
PTU costs and billingの影響は、開発者だけでなく、Azure管理者、請求管理者、セキュリティ・コンプライアンス担当にも及びます。
| 対象者 | 確認すべき内容 |
|---|---|
| Azure管理者 | サブスクリプション、リージョン、クォータ、予約購入権限、予約スコープ |
| 請求・FinOps担当 | 時間課金、予約割引、未使用予約、超過PTU、償却コスト |
| 開発者 | デプロイ種別、モデル、PTUサイズ、トークン使用量、レイテンシ、API実装 |
| アーキテクト | Global/Data Zone/Regionalの選択、データ処理場所、可用性、移行方式 |
| 運用担当 | デプロイ削除、リソース削除、パージ、予約更新、Azure Monitorでの利用率確認 |
| コンプライアンス担当 | データがGlobal、Data Zone、単一リージョンのどこで処理されるか |
デプロイ種別は、単なる料金プランではありません。Microsoft Foundry Modelsでは、Global、Data Zone、Regionalの選択により、データ処理場所、課金方式、パフォーマンス特性が変わります。Globalは任意のAzureリージョン、Data Zoneは米国またはEUのMicrosoft指定データゾーン、Regionalはデプロイリージョンで推論データが処理されると説明されています。(Microsoft Learn)
管理者が確認すべき設定
Azure AI FoundryのPTUを運用する管理者は、料金表だけでなく、予約が実際に割引として適用される条件を確認する必要があります。
クォータと容量を分けて確認する
PTUクォータは、サブスクリプションとリージョンにおけるPTU割り当て上限です。ただし、クォータがあることは実容量が空いていることを意味しません。公式ドキュメントでは、クォータはデプロイ可能なPTUの上限を示すだけで、容量可用性は保証しないと説明されています。容量はデプロイ時に割り当てられ、空きがなければデプロイは失敗します。(Microsoft Learn)
管理者が確認すべき順序は次のとおりです。
| 順序 | 作業 | 確認内容 |
|---|---|---|
| 1 | 対象リージョンのPTUクォータを確認 | Foundry portalのOperate > QuotaでPTUクォータを見る |
| 2 | 対象モデルをデプロイ | 実際に容量が確保できるか確認する |
| 3 | デプロイ情報を記録 | デプロイ種別、リージョン、サブスクリプション、PTU数を控える |
| 4 | 予約を購入または既存予約を確認 | 種別・リージョン・スコープ・数量が一致しているか確認する |
| 5 | 利用率を監視 | 予約PTUが使い切れているか、超過PTUが時間課金になっていないか確認する |
予約スコープを間違えない
予約割引は、対象となるデプロイが予約スコープ内にある場合に適用されます。予約スコープには、単一リソースグループ、単一サブスクリプション、共有スコープ、管理グループなどがあります。スコープ外のサブスクリプションにあるデプロイは、予約が存在していても時間課金になります。(Microsoft Learn)
たとえば、開発チームが別サブスクリプションにGlobal Provisionedデプロイを作成し、FinOpsチームが本番サブスクリプションだけを対象にGlobal予約を購入している場合、開発側のデプロイには割引が適用されません。予約購入前に、実際のリソース配置と請求スコープを照合してください。
予約購入権限を事前に確認する
予約購入には、通常のモデルデプロイ権限とは別の権限が必要です。Microsoftの予約ドキュメントでは、Azure portalでMicrosoft Foundry Provisioned Throughput予約を購入するには、サブスクリプションのOwnerロールまたはReservation purchaserロールが必要とされています。Enterprise契約ではReserved Instancesポリシー、CSPではadmin agentsまたはsales agentsの権限も関係します。(Microsoft Learn)
本番リリース当日に「予約を買える人がいない」となると、デプロイ作成後の時間課金が長引きます。リリース前に、予約購入担当者、承認フロー、支払い方法、予約スコープを決めておきましょう。
開発者が確認すべき設計ポイント
開発者側では、PTUを「とりあえず大きめに確保する」のではなく、実際のリクエスト形状から必要PTUを見積もることが重要です。
TPM、RPM、入力・出力トークンを計測する
PTUの容量計画では、単純なAPI呼び出し回数だけでは不十分です。必要なのは、少なくとも次の値です。
| 指標 | 見る理由 |
|---|---|
| RPM（Requests per minute） | 1分あたりのリクエスト数を把握する |
| 入力トークン数 | プロンプト、システムメッセージ、RAGで投入する文書量を把握する |
| 出力トークン数 | 回答生成に必要な容量とレイテンシに影響する |
| キャッシュ利用率 | キャッシュが効く場合、実効利用率に影響する |
| ピーク時間帯 | 平均ではなく最大負荷に合わせた設計が必要になる |
Microsoftのパフォーマンス・レイテンシ資料では、Azure MonitorのProcessed Prompt TokensとGenerated Completion Tokensを使い、複数週の1分単位データを分析する方法が説明されています。また、APIレスポンスのusage情報から、リクエスト単位のprompt_tokens、completion_tokens、total_tokensを集計してTPMを見積もる方法も示されています。(Microsoft Learn)
エージェントやfunction callingはトークン変動を大きめに見る
Azure AI Foundryでエージェントやfunction callingを使う場合、1回のユーザー操作でもツール呼び出し、追加プロンプト、検索結果の投入、再試行が発生し、トークン使用量が大きく変わります。公式ドキュメントでも、function callingやエージェントのユースケースではトークン使用が変動しやすいため、PTUへ移行する前に想定TPMを詳細に理解する必要があると注意されています。(Microsoft Learn)
開発時には、平均値だけでなく次の値をログ化してください。
- 95パーセンタイル、99パーセンタイルの入力トークン数
- 95パーセンタイル、99パーセンタイルの出力トークン数
- ツール呼び出し回数
- RAGで投入したチャンク数
- 再試行回数
- タイムアウト発生率
- キャッシュヒット率
特にRAGでは、検索結果を多く詰め込みすぎると入力トークンが増えます。エージェントでは、ユーザーには1回の質問に見えても内部的には複数回の推論が走ることがあります。PTU設計では、この「見えない呼び出し」を含めて見積もる必要があります。
出力トークンは容量消費が重くなりやすい
PTUあたりのスループットは、入力トークンと出力トークンの組み合わせで決まります。公式ドキュメントでは、出力トークンの生成は入力トークンより処理負荷が高く、モデルによって出力トークンが利用率上で複数の入力トークン相当として扱われる例が示されています。(Microsoft Learn)
実務では、次のような設計が有効です。
| 改善策 | 効果 |
|---|---|
max_tokensを用途別に設定する | 長すぎる回答生成を抑え、PTU消費とレイテンシを抑制する |
| 回答フォーマットを固定する | 不要な前置きや冗長な説明を減らす |
| RAGの投入チャンク数を制限する | 入力トークンの肥大化を防ぐ |
| システムプロンプトを定期的に棚卸しする | 毎回送る固定トークンを削減できる |
| キャッシュが効く設計にする | 繰り返し部分の利用効率を改善しやすい |
デプロイ種別の選び方：Global、Data Zone、Regional
PTUの予約・課金では、デプロイ種別の選択が非常に重要です。なぜなら、予約割引はGlobal、Data Zone、Regionalの種別をまたいで適用されないためです。
| デプロイ種別 | データ処理場所の考え方 | 向いているケース | 注意点 |
|---|---|---|---|
| Global Provisioned | Azureのグローバル基盤で処理される可能性がある | 広いモデル可用性、グローバルな高スループットを重視する本番環境 | データ処理場所の要件が厳しい場合は事前確認が必要 |
| Data Zone Provisioned | 米国またはEUなどMicrosoft指定データゾーン内で処理 | データゾーン単位のコンプライアンス要件がある場合 | GlobalやRegionalの予約とは別扱い |
| Regional Provisioned | デプロイリージョン内で処理 | 単一リージョンでのデータ処理が必要な場合 | 最小PTUや増分がGlobal/Data Zoneと異なる場合がある |
Microsoftのデプロイ種別資料では、Global Provisionedはグローバルルーティングと予約済み容量を組み合わせ、Data Zoneは指定データゾーン内、Regionalは単一リージョンでの処理に使う位置づけとされています。データ所在地や社内規程に関わるため、開発者だけで判断せず、セキュリティ・法務・コンプライアンス担当と確認してから選びましょう。(Microsoft Learn)
既存のCommitmentモデル利用者が注意すべき移行ポイント
2024年8月以前からAzure OpenAIのProvisioned Managedを利用していた組織では、従来のCommitmentモデルを使っている場合があります。公式情報では、August self-service update以前にオンボードされたFoundry provisioned利用者はCommitmentモデルを継続利用できる一方、新規顧客や2024年8月以降に導入された一部の新しいモデルではCommitmentモデルを利用できないと説明されています。(Microsoft Learn)
移行時に見るべきポイントは次のとおりです。
| 確認項目 | 判断ポイント |
|---|---|
| 既存リソースにCommitmentが残っているか | リソース単位で課金モデルや割引適用が変わる可能性がある |
| 新しいモデルを使いたいか | 最新モデルはHourly/Reservation側での利用が前提になる場合がある |
| Global/Data Zoneへ移行するか | 既存Regionalから移す場合、デプロイ作成・トラフィック移行・旧デプロイ削除が必要 |
| 移行期間の二重課金や時間課金を許容できるか | 予約とCommitmentの重複、または切替間の時間課金が発生する可能性がある |
| Azure Reservationsの購入権限があるか | 予約をすぐ購入できないと、移行後に時間課金期間が長くなる |
MicrosoftのProvisioned 2024 Updatesでは、Hourly/Reservationモデルにより短期利用や1か月・1年の予約割引が可能になったこと、CommitmentモデルからHourly/Reservationへ移行する場合に、切替期間の追加料金が発生し得ることが説明されています。(Microsoft Learn)
削除時の注意点：デプロイ、リソース、予約は別々に扱う
PTUで特に危険なのが、削除順序のミスです。公式ドキュメントでは、削除済みリソース上のデプロイに対する課金は、リソースがパージされるまで継続する可能性があるため、Azure AIリソースを削除する前にデプロイを削除する必要があるとされています。また、デプロイ削除はPTU予約のキャンセルや変更を意味しません。(Microsoft Learn)
安全な削除手順は次のとおりです。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 推論トラフィックを停止または切替 | 旧デプロイへのAPI呼び出しが残っていないか |
| 2 | Foundry portalでPTUデプロイを削除 | デプロイ一覧から対象が消えているか |
| 3 | Azure AIリソースを削除する場合は、その前に全デプロイ削除を確認 | リソースだけ先に消さない |
| 4 | 必要に応じて削除済みリソースをパージ | 課金停止に関わるため必ず確認 |
| 5 | Azure portalのReservationsで予約を確認 | 不要な予約のキャンセル・交換・更新設定を見直す |
予約は削除できるものではなく、キャンセルまたは交換の対象です。Microsoftの予約ドキュメントでも、デプロイを削除しても関連するPTU予約は自動でキャンセル・変更されず、Azure portalで手動管理が必要と説明されています。(Microsoft Learn)
よくある失敗と対策
PTU導入で失敗しやすいのは、技術設計よりも「課金条件の認識違い」です。
| 失敗パターン | 原因 | 対策 |
|---|---|---|
| 予約を先に買ったが、対象モデルをデプロイできない | クォータと実容量を同一視している | 必ずデプロイ成功後に予約を購入する |
| 予約があるのに時間課金が発生する | デプロイ種別、リージョン、スコープ、数量が一致していない | 予約属性とデプロイ属性を一覧化して照合する |
| 本番ピーク時にPTUを増やそうとして失敗する | 未使用クォータが容量保証だと思っている | 本番必要量は恒久デプロイ＋予約で確保する |
| デプロイ削除後もコストが残る | 予約や削除済みリソースのパージを見落としている | デプロイ削除、リソース削除、パージ、予約確認をチェックリスト化する |
| 予約PTUが余る | 過大見積もり、縮小後の予約見直し漏れ | Azure MonitorやReservation utilizationを定期確認する |
| エージェント導入後にPTU不足になる | function callingやRAGでトークン使用量が増えた | エージェント単位で入力・出力・内部呼び出しをログ化する |
Microsoftの予約ドキュメントでは、予約割引は予約済みPTUとデプロイ済みPTUを時間単位で比較して適用され、予約量を超えた分は時間課金になります。また、予約PTUがデプロイ済みPTUより多い時間帯では、余った予約PTUは使われず、後の期間へ繰り越されません。(Microsoft Learn)
導入・見直しの実務手順
Azure AI FoundryでPTUを導入する場合は、次の順序で進めると失敗を減らせます。
現在のワークロードを計測する
まず、Standardデプロイや既存環境で実トラフィックを計測します。最低限、入力TPM、出力TPM、RPM、ピーク時間帯、レイテンシ、キャッシュヒット率を確認します。エージェントやRAGでは、ツール呼び出しや検索チャンク投入によるトークン増加も含めます。
データ処理要件からデプロイ種別を決める
次に、Global、Data Zone、Regionalのどれを使うか決めます。コストや可用性だけでなく、データ処理場所の要件を優先してください。EUや米国データゾーン、単一リージョン処理が必要な場合は、技術チームだけでなくコンプライアンス担当の確認が必要です。
Foundry portalでクォータを確認する
Foundry portalのOperate > Quotaで、対象リージョンのPTUクォータを確認します。クォータが不足している場合は、クォータ引き上げ申請が必要です。ただし、クォータが増えても容量が保証されるわけではないため、予約購入はまだ行わないでください。
対象モデルを先にデプロイする
対象モデル、バージョン、デプロイ種別、リージョン、PTU数を指定して、実際にデプロイを作成します。この段階で容量が取れるかを確認します。CLIやAPIで作成する場合、Global ProvisionedはGlobalProvisionedManaged、Data Zone ProvisionedはDataZoneProvisionedManaged、Regional ProvisionedはProvisionedManagedのSKU名を使います。(Microsoft Learn)
ベンチマークでPTU数を調整する
デプロイ後、本番に近いリクエストでテストします。平均レイテンシだけでなく、ピーク時、長文出力時、RAGで多くの文書が入るケース、エージェントの複数ステップ実行時も確認してください。
デプロイに一致する予約を購入する
デプロイが成功し、必要PTU数が見えたら、Azure portalのReservationsからMicrosoft Foundry Provisioned Throughput予約を購入します。予約では、デプロイ種別、リージョン、数量、スコープ、期間、支払い方法を確認します。予約は1か月または1年の期間で利用でき、購入後は一致するPTU使用量に割引価格が適用されます。(Microsoft Learn)
運用中は利用率と超過を監視する
予約購入後も、毎月の利用率を確認してください。見るべきポイントは次の3つです。
- 予約PTUが余っていないか
- 予約PTUを超えた分が時間課金になっていないか
- デプロイ種別・スコープ変更により割引適用が外れていないか
予約利用率はAzure ReservationsポータルやAzure Monitorで確認できます。公式ドキュメントでも、予約作成後はAzure Reservation portalまたはAzure Monitorで期待どおり利用されているか監視することが推奨されています。(Microsoft Learn)
まとめ：PTUは「先にデプロイ、後で予約」が基本
Azure AI FoundryのProvisioned throughput unit (PTU) costs and billingで最も重要なのは、PTUを「料金プラン」ではなく、デプロイ、容量、予約割引、クォータ、削除手順をまとめて設計する運用モデル として扱うことです。
短期検証なら時間課金で始められますが、本番で継続利用するなら、実トラフィックから必要TPMを見積もり、対象リージョンでデプロイを作成し、容量が確保できたことを確認してからAzure Reservationsを購入する流れが安全です。逆に、予約を先に買う、クォータを容量保証と考える、デプロイ削除と予約キャンセルを同一視する、といった運用は想定外のコストにつながります。
次に取るべき行動は、自社のAzure AI Foundry環境で次の4項目を棚卸しすることです。
| すぐ確認する項目 | 確認先 |
|---|---|
| 既存のPTUデプロイ種別、リージョン、PTU数 | Microsoft Foundry portal |
| PTUクォータと実際のデプロイ可否 | Operate > Quota、デプロイ作成画面 |
| Azure Reservationsの数量、スコープ、更新設定 | Azure portal > Reservations |
| 入力TPM、出力TPM、RPM、ピーク時利用 | Azure Monitor、APIレスポンスログ |
この4つを確認すれば、PTUの過不足、予約のミスマッチ、削除漏れによる課金継続を早期に見つけられます。PTUは正しく使えば、Azure AI Foundryで高スループットかつ予測しやすい生成AI基盤を構築する有力な選択肢になります。
コメント