Azure AI Foundryの「Global PTU Reservations Are Now Region-Agnostic」は、Global Provisioned Throughput（Global PTU）の予約がリージョン単位に縛られなくなり、1つのGlobal予約で複数リージョンのGlobal PTUデプロイをカバーできるようになったという変更です。複数リージョンでAzure AI Foundryの本番推論基盤を運用している組織にとっては、予約の使い残しを減らし、コスト最適化と運用管理をしやすくするアップデートです。(マイクロソフト Azure)
ただし、これは「すべてのPTUがリージョンをまたいで自由に使える」という意味ではありません。Global予約が対象にできるのはGlobal Provisionedのデプロイであり、Data Zone ProvisionedやRegional Provisionedとは別扱いです。また、PTUのクォータや実際の容量確保は引き続きリージョンやデプロイ種類の制約を受けます。管理者は予約スコープ、PTU数量、利用率、既存の課金設計を見直し、開発者はデプロイ種類とリージョン選定を誤らないことが重要です。(Microsoft Learn)
Azure AI FoundryのGlobal PTU Reservationsで何が変わったのか
今回の変更点はシンプルです。Global PTU予約がリージョン非依存になり、1つのGlobal予約を複数リージョンのGlobal PTUデプロイに適用できるようになりました。
Microsoft Learnの予約ドキュメントでも、Global予約はリージョン固有ではなく、予約PTU数が合計デプロイPTU数を十分にカバーしていれば、複数リージョンのGlobal PTUデプロイに1つのGlobal予約を適用できると説明されています。(Microsoft Learn)
たとえば、以下のような構成を考えます。
| リージョン | デプロイ種類 | PTU数 |
|---|---|---|
| East US | Global Provisioned | 50 |
| West Europe | Global Provisioned | 100 |
| Australia East | Global Provisioned | 200 |
この場合、合計350 PTU分のGlobal予約を1つ購入すれば、3リージョンに分散したGlobal PTUデプロイをまとめてカバーできます。Microsoftのドキュメントでも、複数リージョンに分散したGlobalデプロイに対して、合計PTU数を満たす単一のGlobal予約を使える例が示されています。(Microsoft Learn)
これまではリージョンごとに予約を分けて管理していた環境でも、今後は「Global PTUの合計利用量」を軸に予約設計を見直せます。特に、リージョンごとの利用量に偏りがある組織では、予約の使い残しを減らせる可能性があります。
変更前と変更後の違い
Global PTU予約のリージョン非依存化で変わるのは、主に予約割引の適用範囲です。アプリケーションのエンドポイント、モデルの呼び出しコード、既存デプロイの動作が自動的に変わるわけではありません。
| 観点 | 変更前の考え方 | 変更後の考え方 |
|---|---|---|
| Global PTU予約の適用 | リージョン単位で考える必要があった | 1つのGlobal予約で複数リージョンのGlobal PTUをカバー可能 |
| 予約の最適化 | リージョンごとに余剰・不足が出やすい | 複数リージョンの合計PTUで利用率を高めやすい |
| 管理単位 | リージョン別の予約管理になりやすい | グローバルな予約プールとして管理しやすい |
| 対象デプロイ | Global PTU | 引き続きGlobal PTUのみ |
| Data Zone / Regionalへの適用 | 対象外 | 引き続き対象外 |
重要なのは、リージョン非依存になったのはGlobal予約の割引適用であり、すべてのデプロイ種類を横断して使える予約になったわけではない点です。Global、Data Zone、Regionalの予約は相互に置き換えられず、Global予約はRegional Provisionedデプロイをカバーしません。(Microsoft Learn)
そもそもPTUと予約は何を意味するのか
Azure AI FoundryでProvisioned Throughputを使う場合、処理能力はPTU、つまりProvisioned Throughput Unitで表されます。PTUはモデル処理容量を表す汎用的な単位で、デプロイ時に割り当てるPTU数を指定します。課金は実際に消費したトークン数ではなく、デプロイしているPTU数に基づきます。(Microsoft Learn)
たとえば300 PTUのProvisionedデプロイを作成すると、リクエストが少ない時間帯でも、基本的にはその300 PTU分のデプロイ容量に対して時間課金されます。Provisionedデプロイは一時停止できず、課金を止めるにはデプロイを削除する必要があります。(Microsoft Learn)
Azure Reservationsは、このPTU時間課金に対する割引の仕組みです。1か月または1年などの期間で一定数のPTU利用をコミットする代わりに、時間課金より有利な実効単価を得るためのものです。Microsoft Learnでは、Azure Reservationsはデプロイ作成などの操作そのものではなく、PTU課金メーターに適用される金銭的な割引だと説明されています。(Microsoft Learn)
つまり、予約は「容量そのものを確保する権利」ではなく、既に動いているProvisionedデプロイの課金を割引する仕組みです。この違いを誤解すると、予約を買ったのにデプロイできない、予約PTUを使い切れない、といった失敗につながります。
対象になるユーザーと影響範囲
今回の変更で特に影響を受けるのは、Azure AI FoundryでGlobal PTUを本番利用している、またはこれから複数リージョンに展開しようとしている組織です。
| 対象者 | 影響するポイント |
|---|---|
| Azure管理者 | Reservationsのスコープ、数量、更新設定、利用率の見直しが必要 |
| FinOps / コスト管理担当 | リージョン別予約から集約予約への変更で、コスト配賦ルールの再整理が必要 |
| AI基盤チーム | 複数リージョンのGlobal PTU合計値を基準に予約設計しやすくなる |
| アプリ開発者 | 通常はコード変更不要。ただしデプロイ種類やフェイルオーバー設計の確認は必要 |
| セキュリティ・コンプライアンス担当 | Global Provisionedのデータルーティング特性と組織要件の整合確認が必要 |
一方、Azure AI Foundryを従量課金のStandardデプロイだけで使っている場合や、Regional Provisionedのみを使っている場合は、今回の変更による直接的なメリットは限定的です。予約の対象はProvisionedデプロイであり、Standardデプロイやファインチューニングなど他の提供形態は含まれません。(Microsoft Learn)
管理者がまず確認すべき設定
Global PTU予約をすでに使っている場合、最初に見るべきなのはAzure portalのReservationsページです。予約の利用状況を確認し、Global予約がどの程度実際のデプロイに適用されているかを把握します。
特に確認したい項目は次のとおりです。
| 確認項目 | 見るべき内容 | 判断の目安 |
|---|---|---|
| 予約の製品種別 | Global / Data Zone / Regionalのどれか | Global予約だけが複数リージョンのGlobal PTUに適用可能 |
| 予約スコープ | 単一サブスクリプション、共有、管理グループなど | 対象デプロイがスコープ外だと割引されない |
| 予約PTU数 | 予約しているPTU数量 | 複数リージョンのGlobal PTU合計と比較する |
| Utilization | 予約利用率 | 100%未満なら使い残し、超過分があれば時間課金の可能性 |
| 自動更新 | 更新の有無と期間 | 統合予定があるなら更新前に見直す |
| コスト配賦 | 部門・プロジェクト別の負担ルール | 予約集約で費用の見え方が変わる可能性 |
Microsoft Learnでは、予約の詳細画面でUtilizationを確認し、100%なら予約PTUがすべて利用されており、100%未満なら一部の予約PTUが実行中デプロイと一致していない可能性があると説明されています。(Microsoft Learn)
また、予約はスコープに基づいてデプロイと照合されます。たとえば単一サブスクリプションスコープで購入した予約は、そのサブスクリプション内の一致するデプロイだけをカバーします。別サブスクリプションのGlobal PTUデプロイを同じ予約でカバーしたい場合は、共有スコープや管理グループスコープの利用を検討する必要があります。(Microsoft Learn)
既存環境での見直し手順
既存のGlobal PTU予約をすぐにキャンセルしたり交換したりする前に、まず現状を棚卸しします。予約には期間や返金条件があり、安易な変更は逆にコスト増になる場合があります。
現在のGlobal PTUデプロイを一覧化する
まず、Azure AI Foundry側で稼働中のProvisionedデプロイを確認します。最低限、次の情報を一覧にしてください。
| 項目 | 例 |
|---|---|
| サブスクリプション | production-ai-sub |
| リソースグループ | rg-foundry-prod |
| リージョン | East US、Japan East、West Europe |
| デプロイ種類 | Global Provisioned、Regional Provisionedなど |
| モデル | GPT系モデル、その他Foundry Models |
| PTU数 | 50、100、300など |
| 用途 | 本番API、社内チャット、バッチ処理など |
| 所有チーム | カスタマーサポート、開発部門など |
ここで大切なのは、リージョンではなくデプロイ種類を必ず確認することです。Japan EastにあるからGlobalではない、East USにあるからGlobalである、という判断はできません。予約適用の可否は、リージョン名ではなくGlobal Provisionedかどうかで決まります。
現在の予約を一覧化する
次にAzure Reservations側で、既存予約を確認します。
| 項目 | 確認理由 |
|---|---|
| 予約名 | 管理上の識別に必要 |
| 製品種別 | Global / Data Zone / Regionalを判別 |
| リージョン | 既存予約の管理単位を把握 |
| PTU数量 | デプロイ合計PTUと比較 |
| 期間 | 1か月・1年など |
| 更新設定 | 統合前に自動更新されないか確認 |
| スコープ | どのサブスクリプションやリソースグループを対象にしているか |
| Utilization | 使い切れているか、余っているか |
複数リージョンにGlobal予約が分かれていて、どこかのリージョンで使い残し、別リージョンで時間課金が発生している場合は、統合の余地があります。
統合するか、リージョン別に残すかを判断する
Global予約を1つにまとめられるからといって、必ず統合すべきとは限りません。判断基準は次のとおりです。
| 判断軸 | 単一Global予約が向くケース | リージョン別予約を残すケース |
|---|---|---|
| 利用率 | リージョンごとのPTU利用量が変動しやすい | 各リージョンの利用量が安定している |
| 管理負荷 | 予約数を減らして管理を簡素化したい | 地域ごとの予算管理を重視する |
| コスト配賦 | 全社共通のAI基盤として費用を集約したい | 部門・国・法人ごとに明確に費用を分けたい |
| 将来展開 | 新リージョンへの展開予定がある | 展開リージョンが固定されている |
| 監査 | 集約管理で問題ない | 1対1対応の証跡が必要 |
Microsoftのドキュメントでも、Globalデプロイについては単一のGlobal予約に集約できる一方、リージョンごとの1対1マッピングを維持するために、あえてリージョン別にGlobal予約を購入する選択肢も示されています。(Microsoft Learn)
移行・変更時に失敗しやすいポイント
今回のアップデートはコスト最適化に有利ですが、予約と容量の関係を誤解するとトラブルになります。
予約を買っても容量は保証されない
最も重要な注意点は、予約は容量保証ではないことです。Microsoft Learnでも、予約は容量の可用性を保証しないため、先にデプロイを作成して容量が利用できることを確認してから予約を購入することが推奨されています。(Microsoft Learn)
悪い例は、将来の本番展開を見込んで先に大きなGlobal予約を購入し、その後で必要なリージョンにPTUデプロイを作ろうとするパターンです。もしその時点で対象モデル・対象リージョンの容量が足りなければ、予約PTUを使い切れない可能性があります。
安全な順序は次のとおりです。
| 順序 | 作業 | 理由 |
| -: | ————————– | ——————- |
| 1 | 対象モデル、リージョン、デプロイ種類を決める | 予約対象を明確にする |
| 2 | PTU必要量を見積もる | 過不足のない予約数量を決める |
| 3 | Foundry portalやAPIで容量を確認する | デプロイできないPTUを予約しないため |
| 4 | Provisionedデプロイを作成する | 実際に容量を確保する |
| 5 | デプロイ済みPTU数に合わせて予約を購入する | 割引を最大化する |
Global予約でRegionalデプロイはカバーできない
Global、Data Zone、Regionalは予約上も別のデプロイ種類として扱われます。Global予約を購入しても、Regional Provisionedのデプロイには適用されません。(Microsoft Learn)
たとえば次のような構成では注意が必要です。
| デプロイ | PTU数 | Global予約の対象になるか |
|---|---|---|
| East USのGlobal Provisioned | 100 | 対象 |
| Japan EastのGlobal Provisioned | 100 | 対象 |
| Japan EastのRegional Provisioned | 100 | 対象外 |
| EUのData Zone Provisioned | 100 | 対象外 |
「複数リージョンにあるからGlobal予約でまとめられる」と考えるのではなく、各デプロイのSKU名・デプロイ種類を確認することが必要です。
スコープ外のデプロイには割引が適用されない
予約はスコープ内の一致するデプロイに適用されます。単一リソースグループや単一サブスクリプションに限定したスコープで予約している場合、別サブスクリプションにあるGlobal PTUデプロイは対象外になります。(Microsoft Learn)
複数チームや複数サブスクリプションでAzure AI Foundryを使っている場合は、予約を統合する前に次の点を確認してください。
- 対象デプロイが同じ課金コンテキスト内にあるか
- 予約スコープが単一サブスクリプションに閉じていないか
- 管理グループスコープを使う場合、組織の権限設計に合っているか
- 部門別のコスト配賦に必要な情報をCost Managementで追えるか
デプロイ削除と予約キャンセルは連動しない
Provisionedデプロイを削除しても、対応するPTU予約が自動的にキャンセルまたは変更されるわけではありません。Microsoftの予約ドキュメントでも、デプロイを削除しても関連するPTU予約は自動的にキャンセル・変更されず、Azure portalのReservationsから手動でキャンセルまたは交換する必要があるとされています。(Microsoft Learn)
開発・検証環境で一時的にGlobal PTUを使った後、デプロイだけを削除して予約を放置すると、予約期間中の費用や使い残しが発生します。検証用途では、まず時間課金で試し、継続利用が見えてから予約に切り替えるほうが安全です。
開発者が確認すべきこと
今回の変更は主に課金・予約管理のアップデートなので、多くのアプリケーションではコード変更は不要です。ただし、Global PTUを複数リージョンで運用する場合、開発者にも確認すべき点があります。
エンドポイントやデプロイ名の変更は基本的に不要
既存のGlobal PTUデプロイに対して、予約がリージョン非依存になっただけであれば、アプリケーションが呼び出すエンドポイントやデプロイ名を変更する必要は通常ありません。予約は課金メーターに対する割引であり、デプロイ作成やAPI呼び出しそのものに直接適用する設定ではありません。(Microsoft Learn)
ただし、コスト最適化を機にリージョン追加やデプロイ再配置を行う場合は、アプリケーション側の接続先管理、フェイルオーバー、監視設定を見直します。
Global Provisionedのデータルーティング特性を理解する
Microsoft Learnでは、Global ProvisionedはAzureリージョンをまたいでグローバルにルーティングされるデプロイ種類であり、高い可用性を重視し、ルーティング先リージョンに厳格な制約がない場合に向くと説明されています。一方、Data Zone ProvisionedはUSまたはEUなどの地理的ゾーン内、Regional Provisionedは特定Azureリージョン内に処理を留める設計です。(Microsoft Learn)
そのため、次のような判断が必要です。
| 要件 | 選びやすいデプロイ種類 |
|---|---|
| 可用性や容量確保の選択肢を広げたい | Global Provisioned |
| EUやUSなど特定ゾーン内のデータ所在地を重視したい | Data Zone Provisioned |
| 単一リージョン内での処理が必須 | Regional Provisioned |
今回の変更はGlobal予約のコスト面を改善するものですが、データ所在地要件や規制要件を緩和するものではありません。セキュリティやコンプライアンス上、Regional Provisionedを選ぶべき環境では、Global予約のコストメリットだけでGlobal Provisionedへ切り替えないようにしてください。
スケールダウン後の再スケールに注意する
ProvisionedデプロイはPTU数を増減できますが、スケールアップにはその時点の容量が必要です。また、スケールダウンで解放した容量が後で再び確保できる保証はありません。(Microsoft Learn)
コスト削減のために夜間だけPTUを下げ、翌朝に戻す、といった運用は一見合理的に見えます。しかし、本番環境では必要なタイミングで容量を再取得できないリスクがあります。Microsoft Learnでも、継続的な本番ワークロードでは時間課金で上下させ続けるより、予約を使うほうが適していると説明されています。(Microsoft Learn)
新規展開時のおすすめ設計
これからAzure AI FoundryでGlobal PTUを本番展開する場合は、最初から予約を買うのではなく、次の流れで進めると安全です。
| フェーズ | 実施内容 | 注意点 |
|---|---|---|
| 検証 | 時間課金でモデル性能、レイテンシ、必要PTUを確認 | 短期検証に予約を使わない |
| 本番設計 | リージョン、デプロイ種類、可用性要件を決める | データ所在地要件を必ず確認 |
| 容量確認 | Foundry portalまたはAPIで容量を確認 | クォータがあっても容量があるとは限らない |
| デプロイ作成 | 必要PTUでGlobal Provisionedデプロイを作成 | 先に実容量を確保する |
| 予約購入 | 複数リージョンのGlobal PTU合計に合わせて購入 | スコープとPTU数量を誤らない |
| 運用監視 | Utilization、時間課金超過、未使用PTUを確認 | 月次で見直す |
短期のベンチマークやイベント用途では時間課金が向きます。継続的な本番ワークロードでは予約のほうがコスト効率を高めやすい、という使い分けが基本です。(Microsoft Learn)
コスト最適化の具体例
次のような構成を例に考えます。
| リージョン | デプロイ種類 | PTU数 |
|---|---|---|
| East US | Global Provisioned | 100 |
| Japan East | Global Provisioned | 80 |
| West Europe | Global Provisioned | 120 |
合計は300 PTUです。この3つが予約スコープ内にあり、すべてGlobal Provisionedであれば、300 PTU分の単一Global予約でカバーできます。
一方、実際の運用では次のようなズレが起きます。
| 状態 | 課金上の影響 |
|---|---|
| 予約300 PTU、実デプロイ300 PTU | 予約を使い切る |
| 予約300 PTU、実デプロイ250 PTU | 50 PTU分が未使用になりやすい |
| 予約300 PTU、実デプロイ350 PTU | 超過50 PTU分は時間課金になりやすい |
| 予約300 PTU、うち100 PTUがスコープ外 | スコープ外分は予約対象にならない |
| 予約300 PTU、Regional Provisionedが含まれる | Regional分はGlobal予約対象外 |
Microsoft Learnでは、予約PTUを超えるデプロイ分は時間課金になり、予約PTUがデプロイ量を上回る期間では余った予約PTUはその期間に使われず、別期間へ繰り越されないと説明されています。(Microsoft Learn)
そのため、予約数量は「最大瞬間値」ではなく、継続して使う見込みが高いベースラインPTUを軸に決めるのが現実的です。一時的なピークまで予約で覆うと、平常時の未使用予約が増える可能性があります。
運用チェックリスト
Global PTU予約のリージョン非依存化を受けて、管理者と開発者は次の項目を確認してください。
管理者・FinOps向け
- 既存のMicrosoft Foundry Provisioned Throughput予約を一覧化する
- Global、Data Zone、Regionalの予約種別を分類する
- 複数リージョンのGlobal PTU合計値を算出する
- 予約スコープが対象サブスクリプションやリソースグループを含んでいるか確認する
- ReservationsページでUtilizationを確認する
- 100%未満の予約があれば、過剰購入やデプロイ削除漏れを疑う
- 時間課金が残っている場合、予約PTU数不足またはスコープ不一致を確認する
- 予約の自動更新前に統合・分割方針を決める
- コスト配賦や部門別チャージバックのルールを更新する
- 予約変更・キャンセル時の条件や手数料を確認する
開発者・AI基盤チーム向け
- 各デプロイがGlobal ProvisionedかRegional Provisionedかを確認する
- リージョン追加時にアプリ側の接続先、ルーティング、フェイルオーバーを見直す
- データ所在地要件があるシステムでGlobal Provisionedを選んでよいか確認する
- スケールダウン運用で容量を失うリスクを評価する
- PTU不足時の429やレイテンシ変化を監視する
- 必要に応じて標準デプロイへの退避やバースト対策を設計する
- IaC、運用手順書、コスト管理ドキュメントの「リージョン別予約」前提を更新する
よくある疑問
既存のアプリケーションコードを変更する必要はありますか
通常は不要です。今回の変更はGlobal PTU予約の割引適用範囲に関するものであり、既存のエンドポイントやAPI呼び出し方法を直接変えるものではありません。
ただし、コスト最適化をきっかけにデプロイリージョンを増やす、フェイルオーバー構成を変更する、RegionalからGlobalへ移行する、といった設計変更を行う場合は、アプリケーション設定や監視の見直しが必要です。
Global予約はRegional Provisionedにも使えますか
使えません。Global、Data Zone、Regionalの予約は相互に置き換えられません。Global予約でカバーできるのはGlobal ProvisionedのPTUデプロイです。(Microsoft Learn)
予約を購入すればPTU容量も確保されますか
確保されません。予約はPTU課金に対する割引であり、容量保証ではありません。容量を確認し、デプロイを作成してから、そのデプロイ済みPTUをカバーする予約を購入するのが安全です。(Microsoft Learn)
Global予約を1つにまとめれば必ず安くなりますか
必ずではありません。複数リージョンのGlobal PTU利用量に偏りがある場合は、予約利用率を高めやすくなります。一方で、部門別・地域別のコスト配賦を厳密に行っている場合は、単一予約に集約すると費用配分が分かりにくくなることがあります。
既存予約はすぐ交換すべきですか
すぐに交換する必要があるとは限りません。予約の交換やキャンセルには条件があり、変更によって期間がリセットされる場合もあります。まず利用率、残期間、更新日、キャンセル条件を確認し、更新タイミングで統合する選択肢も検討してください。(Microsoft Learn)
今回のアップデートで次にやるべきこと
Azure AI FoundryのGlobal PTU Reservationsがリージョン非依存になったことで、複数リージョンのGlobal PTUを1つの予約で効率よくカバーしやすくなりました。特に、複数リージョンに本番AI推論基盤を分散している組織では、予約の使い残しを減らし、コスト管理を簡素化できる可能性があります。
一方で、今回の変更は予約割引の適用範囲に関するものであり、PTU容量の保証、クォータの共有化、Data ZoneやRegionalへの横断適用を意味するものではありません。まずは現在のGlobal PTUデプロイ、予約種別、予約スコープ、Utilizationを確認し、統合すべき予約と分けておくべき予約を整理しましょう。
実務では、次の順序で進めるのが安全です。
- 稼働中のProvisionedデプロイをデプロイ種類別に棚卸しする
- Global ProvisionedのPTU合計をリージョン横断で算出する
- 既存予約のスコープと利用率を確認する
- 予約を単一Global予約に集約するか、リージョン別に残すか判断する
- 新規購入はデプロイ作成後に行い、未使用予約を避ける
- 月次でUtilizationと時間課金超過を確認する
今回のアップデートは、Azure AI Foundryを本番規模で使う組織にとって、単なる仕様変更ではなくFinOps設計を見直すきっかけになります。Global PTUを複数リージョンで使っている場合は、まずReservationsページを開き、予約が本当に使い切れているかを確認するところから始めてください。
コメント