Azure AI FoundryでGlobal PTUを使っている組織にとって、今回の更新で最も重要なのは「Global PTUの予約をリージョンごとに固定して考える必要が薄れた」という点です。Microsoft FoundryのGlobal Provisioned Throughput Units（PTU）予約がリージョン非依存で一般提供（GA）となり、条件を満たすGlobal PTUデプロイであれば、複数リージョンにまたがって1つの予約割引を適用しやすくなりました。Azure Updatesでは、この更新は2026年6月2日19:00 UTC、つまり日本時間では2026年6月3日早朝の更新として確認できます。(azurecharts.com)
これまでGlobal PTUを複数リージョンで使う場合、予約とデプロイの対応関係をリージョン単位で細かく管理し、余剰予約や未カバー分の時間課金が発生しないように気を配る必要がありました。今回の変更により、Global Provisionedの予約はリージョン非依存となり、予約数量・スコープ・デプロイ種別が合えば、複数リージョンのGlobal PTUデプロイをまとめてカバーできます。Microsoft Learnでも、Global予約はリージョン固有ではなく、十分な予約ユニット数があれば複数リージョンのGlobal PTUデプロイに適用できると説明されています。(Microsoft Learn)
ただし、これは「どのPTUにも自由に使える万能予約」ではありません。Global Provisioned、Data Zone Provisioned、Regional Provisionedの予約は相互に置き換えられず、Global予約はGlobalデプロイにのみ適用されます。管理者は、予約の集約によるコスト最適化だけでなく、デプロイ種別、スコープ、クォータ、実容量、データ所在地要件をあわせて確認する必要があります。
Azure AI FoundryのGlobal PTU予約で何が変わったのか
今回の変更は、Azure AI FoundryやMicrosoft Foundry上で大規模な生成AIアプリ、社内Copilot、AIエージェント、チャット基盤を運用している組織に影響します。
PTUは、モデル処理能力をあらかじめ確保するための単位です。通常の従量課金型デプロイでは、推論処理のキャパシティを他の利用者と共有し、需要によって性能が変動する可能性があります。一方、Provisioned Throughputでは、指定したPTU数に応じて専用のモデル処理スループットが確保されます。Microsoft Learnでは、プロビジョニング済みデプロイは固定量の処理容量を保持し、標準デプロイよりも予測しやすいレイテンシを得やすい方式として説明されています。(Microsoft Learn)
今回のGAで変わったのは、主にGlobal Provisioned Throughputの予約割引の適用単位です。
| 観点 | これまで意識が必要だったこと | 今回の変更後に期待できること |
|---|---|---|
| Global PTU予約の考え方 | リージョンごとの予約対応を強く意識する必要があった | 1つのGlobal予約で複数リージョンのGlobal PTUをカバーしやすい |
| コスト最適化 | リージョン別に余剰・不足が出やすい | 複数リージョンのGlobal PTU利用を合算して予約数量を設計しやすい |
| 運用管理 | リージョンごとに予約の購入・見直し・棚卸しが必要になりやすい | 集約したGlobal予約で管理を簡素化できる可能性がある |
| 適用対象 | デプロイ種別やリージョンの不一致に注意 | Global予約はGlobal PTUデプロイに適用。Data ZoneやRegionalには別予約が必要 |
| リスク | 予約を買っても実デプロイ容量と合わない場合がある | 予約前にデプロイを作成し、実容量を確認する重要性は変わらない |
ポイントは、Global PTUの予約割引がリージョンをまたいで使いやすくなっただけで、PTUのクォータや実際の容量制約がなくなるわけではないことです。
そもそもGlobal PTUとは何か
Global PTUを理解するには、Azure AI Foundryにおけるデプロイ方式の違いを押さえる必要があります。
Azure AI FoundryやMicrosoft Foundry Modelsでは、用途に応じて標準デプロイ、優先処理、プロビジョニング済みスループット、バッチなどを選択します。Provisioned Throughputは、一定以上の処理量と安定した応答時間が求められる本番ワークロード向けの選択肢です。Microsoft Learnでは、予測可能なトラフィック、低レイテンシ要件、本番規模の高スループット、リアルタイムのチャットやCopilot用途に適しているとされています。(Microsoft Learn)
Global PTUは、Provisioned Throughputの中でもGlobal Provisionedに該当するものです。ざっくり言えば、特定リージョンだけに閉じたキャパシティではなく、Globalデプロイとしてモデル処理容量を使う方式です。
実務では、次のようなケースで検討されます。
- 社内Copilotを複数拠点・複数地域の社員が利用する
- グローバル向けSaaSで生成AI機能を提供している
- ピーク時の429エラーや応答遅延を避けたい
- トークン従量課金よりも月額コストを予測しやすくしたい
- 本番環境で安定したスループットを確保したい
一方で、開発検証、PoC、利用量が小さいアプリ、アクセスが不定期な業務ツールでは、標準デプロイや時間課金のままの方が扱いやすい場合があります。
今回のGAで影響を受ける利用者
今回の更新が特に重要なのは、次のような環境です。
| 対象 | 影響 |
|---|---|
| 複数リージョンでGlobal PTUを使っている企業 | 予約を1つにまとめることで、余剰予約の発生を抑えられる可能性がある |
| 社内CopilotやAIエージェントを本番運用している管理者 | 安定性能と予約割引を両立しやすくなる |
| Azureコスト管理を担当するFinOpsチーム | PTU予約の利用率、未使用分、時間課金超過を見直す必要がある |
| 開発チーム・SREチーム | デプロイ種別、リージョン、スコープ変更時の予約適用を確認する必要がある |
| コンプライアンス部門 | Globalデプロイでよいか、Data ZoneやRegionalが必要かを再確認する必要がある |
特に注意したいのは、「Global予約がリージョン非依存になった」ことと、「データ所在地やコンプライアンス要件を気にしなくてよい」ことは別問題という点です。
データ所在地、規制、社内ポリシーにより、Regional ProvisionedやData Zone Provisionedを選ぶ必要がある場合、Global予約の集約メリットだけで判断すべきではありません。
管理者がまず確認すべき設定
今回の更新を受けて、Azure管理者やFinOps担当者は、いきなり予約を買い直すのではなく、現在のPTU構成を棚卸しすることが重要です。
現在のGlobal PTUデプロイを洗い出す
最初に確認するのは、どのサブスクリプション、どのリソース、どのリージョンでGlobal Provisioned Throughputを使っているかです。
確認すべき項目は次の通りです。
| 確認項目 | 見るべき理由 |
|---|---|
| デプロイ種別 | Global、Data Zone、Regionalで予約が別扱いになるため |
| リージョン | Global予約の集約対象を把握するため |
| PTU数 | 予約数量を決める基準になるため |
| サブスクリプション | 予約スコープと一致するか確認するため |
| リソースグループ | スコープを絞っている場合に適用漏れを防ぐため |
| モデル名・モデルバージョン | PTU効率や必要容量がモデルごとに異なるため |
| 稼働時間 | 予約が本当に得か判断するため |
PTUは「使ったトークン量」ではなく「デプロイしているPTU数」に対して課金されます。Microsoft Learnでも、PTU課金はトークン消費量ではなく、デプロイ済みPTU数に基づく時間課金であると説明されています。(Microsoft Learn)
そのため、利用率が低いまま大きなPTUを確保していると、予約割引を使っていても無駄が残ります。
既存予約の適用状況を確認する
次に、Azure Reservationsで購入済みのMicrosoft Foundry Provisioned Throughput予約を確認します。
見るべきポイントは次の4つです。
| 確認項目 | 判断ポイント |
|---|---|
| 予約種別 | Global Provisioned用か、Data Zone用か、Regional用か |
| 予約数量 | 実際のGlobal PTU合計をカバーしているか |
| スコープ | 対象サブスクリプションやリソースグループが含まれているか |
| 未使用分 | 予約PTU数が実デプロイPTU数を上回っていないか |
Microsoft Learnでは、予約割引は予約スコープ内の一致するデプロイに自動適用され、予約済みPTUを超えた分は時間課金になるとされています。また、予約したPTUよりデプロイPTUが少ない時間帯では余剰分は繰り越されません。(Microsoft Learn)
つまり、予約は「多めに買えば安心」ではありません。多すぎる予約は未使用コストになり、少なすぎる予約は超過分が従量課金になります。
Global予約にまとめられるか判断する
今回の変更により、複数リージョンに分かれているGlobal PTUデプロイを、1つのGlobal予約でカバーできる可能性があります。
たとえば、次のような構成を考えます。
| リージョン | Global PTUデプロイ数 |
|---|---|
| East US | 50 PTU |
| West Europe | 100 PTU |
| Australia East | 200 PTU |
| 合計 | 350 PTU |
この場合、条件が合えば350 PTU分のGlobal予約を1つ購入し、複数リージョンのGlobal PTUをまとめてカバーできます。Microsoft Learnでも、East US、West Europe、Australia EastにまたがるGlobal PTU合計350ユニットを、単一のGlobal予約でカバーする例が示されています。(Microsoft Learn)
ただし、予約スコープが狭すぎると、同じGlobal PTUでも適用されないことがあります。サブスクリプション単位、リソースグループ単位、管理グループ単位、課金アカウント単位など、自社の管理設計に合わせてスコープを選ぶ必要があります。
開発者が確認すべきポイント
開発者にとって、今回の変更はコード修正よりも、デプロイ設計と性能検証の見直しに関係します。
推論APIの呼び出しコードは基本的に変わらない
Provisioned Throughputのデプロイを使う場合でも、推論コードは他のデプロイ種別と大きく変わりません。Microsoft Learnでは、プロビジョニング済みデプロイへの推論コードは他のデプロイ種別と同じで、modelパラメータにはモデル名ではなくデプロイ名を使うと説明されています。(Microsoft Learn)
そのため、今回の更新だけを理由にアプリケーションコードを大きく変更する必要は通常ありません。
ただし、以下のような設計は見直し対象です。
- リージョンごとに固定したデプロイ名をアプリ側でハードコードしている
- フェイルオーバー時に別リージョンへ切り替える仕組みがない
- Global PTUと標準デプロイの使い分けが曖昧
- PTU上限超過時の429エラー処理が弱い
- 利用率メトリックを監視していない
予約の適用は課金側の話ですが、PTUを効率よく使えるかどうかはアプリケーションのトラフィック設計に左右されます。
ピーク時のトークン量でPTUを見積もる
PTU設計でよくある失敗は、平均利用量だけで見積もることです。
生成AIアプリでは、1日の平均トークン量は低く見えても、業務開始直後、月次処理、キャンペーン配信、社内ポータル公開直後などにアクセスが集中します。PTUは安定した処理容量を得るための仕組みなので、平均ではなくピーク時のリクエスト数、入力トークン数、出力トークン数、レイテンシ要件をもとに検証する必要があります。
最低限、次の値を取得してから判断しましょう。
| 指標 | 確認理由 |
|---|---|
| 1分あたりのリクエスト数 | 同時利用時の負荷を把握するため |
| 入力トークン数の中央値・95パーセンタイル | 長文プロンプトによる負荷を把握するため |
| 出力トークン数の中央値・95パーセンタイル | 回答生成時間と容量消費を見積もるため |
| ピーク時間帯 | 予約PTU数を過不足なく決めるため |
| 429エラー率 | PTU不足や標準デプロイの限界を判断するため |
| レイテンシ | Copilotやチャット体験に影響するため |
Microsoft Learnでも、プロビジョニング済みデプロイの運用では、PTU要件の見積もり、クォータ確認、デプロイ作成、予約購入、ベンチマーク、監視、スケーリングまでを一連のタスクとして扱うことが示されています。(Microsoft Learn)
移行・見直し時の推奨手順
既存のGlobal PTU構成を今回のリージョン非依存予約に合わせて見直す場合、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 1 | 現在のGlobal PTUデプロイを棚卸しする | Data ZoneやRegionalを混ぜて集計しない |
| 2 | 実際のPTU利用率とピークを確認する | 平均利用率だけで判断しない |
| 3 | 既存予約の数量・スコープ・期限を確認する | 未使用予約と時間課金超過を分けて見る |
| 4 | Global予約を集約できるか試算する | サブスクリプションや管理グループのスコープに注意 |
| 5 | 必要なら予約の交換・キャンセル可否を確認する | 返金や交換には制限や条件がある |
| 6 | 新規予約はデプロイ作成後に購入する | 予約は容量確保そのものではない |
| 7 | 適用後にコスト管理とメトリックを確認する | 予約割引が期待通り適用されているか確認する |
特に重要なのは、予約を先に買わないことです。
Microsoft Learnでは、モデルデプロイの容量可用性はリージョンやモデルによって動的に変わるため、まずデプロイを作成し、その後にデプロイ済みPTUをカバーする予約を購入することが推奨されています。予約は割引の仕組みであり、サービス側の容量確保を保証するものではありません。(Microsoft Learn)
よくある勘違いと注意点
Global予約はData ZoneやRegionalには使えない
今回の更新名に「Global PTU」とある通り、対象はGlobal Provisioned Throughputです。
Global、Data Zone、Regionalの予約は相互に交換できるものではありません。Global予約を買ってもRegional Provisionedデプロイには適用されません。Microsoft Learnでも、Global、Data Zone、Regionalの予約は別購入であり、Global予約の特典はGlobalデプロイにのみ適用されると説明されています。(Microsoft Learn)
コンプライアンスやデータ所在地の理由でRegionalやData Zoneを選んでいる場合、Global予約に集約する判断は慎重に行う必要があります。
予約は容量を保証しない
Azure Reservationsは、あくまで料金割引の仕組みです。PTUデプロイに必要な実容量が対象リージョンやモデルで空いていなければ、デプロイやスケールアップに失敗する可能性があります。
Microsoft Learnでも、PTUクォータがあっても容量が利用可能とは限らず、容量不足の場合はデプロイが失敗すると説明されています。(Microsoft Learn)
つまり、次の順番を守ることが重要です。
- 必要なモデルとリージョンで利用可能性を確認する
- PTUクォータを確認・申請する
- 実際にデプロイを作成する
- ベンチマークと監視で必要PTU数を確認する
- 予約を購入して割引を適用する
デプロイを削除しても予約は自動で消えない
PTUデプロイを削除すれば、そのデプロイに対する時間課金は止まります。しかし、購入済みの予約が自動でキャンセルされるわけではありません。
Microsoft Learnでは、デプロイを削除しても関連するPTU予約は自動でキャンセルまたは変更されず、Azure portalのReservationsから手動でキャンセルまたは交換する必要があると説明されています。(Microsoft Learn)
検証環境や一時的なイベント用にPTUを使った後、デプロイだけ削除して予約の棚卸しを忘れると、不要なコストが残る可能性があります。
予約数量を大きくしすぎると未使用分が無駄になる
予約は、対象時間帯に実際にデプロイされているPTUに適用されます。予約PTU数より実デプロイPTU数が少ない場合、余った予約分は次の時間帯へ繰り越されません。
たとえば、Global予約を300 PTU分購入しているのに、実際のGlobal PTUデプロイが100 PTUしかない時間帯では、残り200 PTU分は未使用になります。
そのため、予約数量は「最大ピークに合わせて大きく買う」のではなく、安定して稼働するベースライン容量を中心に設計するのが現実的です。突発的なピーク分は、別デプロイ、標準デプロイ、アプリ側のキューイング、スロットリング設計と組み合わせて考えるべきです。
コスト最適化の判断基準
Global PTUのリージョン非依存予約は、コスト削減に役立つ可能性があります。しかし、すべての環境で予約が最適とは限りません。
次の条件に多く当てはまるなら、予約の見直しを優先する価値があります。
- Global PTUを複数リージョンで常時稼働している
- 本番環境で毎日安定した生成AIトラフィックがある
- 標準デプロイでレイテンシ変動や429エラーが課題になっている
- 月次のAI利用コストを予測しやすくしたい
- 複数リージョンの予約利用率にばらつきがある
- 予約の未使用分や時間課金超過が毎月発生している
一方、次のような環境では慎重に判断してください。
- PoCや短期検証が中心
- 利用量が月ごとに大きく変動する
- 特定リージョンのデータ所在地要件が厳しい
- モデル変更が頻繁で、必要PTU数がまだ安定していない
- GlobalではなくData ZoneやRegionalを使うべき業務データを扱っている
予約の導入判断では、単純な割引率よりも、予約PTUの利用率を見ることが重要です。未使用予約が多い場合、割引率が高くても実質コストは下がりません。
展開時のチェックリスト
本番環境で今回の更新を反映する前に、次のチェックリストを使って確認してください。
| チェック項目 | 確認済み |
|---|---|
| Global Provisioned、Data Zone、Regionalのデプロイを分類した | |
| 複数リージョンのGlobal PTU合計数を把握した | |
| 既存のGlobal予約数量と実デプロイPTU数を比較した | |
| 予約スコープに対象サブスクリプションが含まれている | |
| 未使用予約と時間課金超過の両方を確認した | |
| データ所在地・規制要件上、Globalデプロイで問題ないことを確認した | |
| 新規予約前にデプロイ作成と容量確認を済ませた | |
| Azure MonitorなどでPTU利用率を確認できる | |
| デプロイ削除時に予約も棚卸しする運用手順を作った | |
| 開発・検証・本番で予約適用範囲を分けて管理している |
このチェックで空欄が多い場合、予約の集約や買い替えを急ぐよりも、まず現状把握を優先した方が安全です。
まとめ：Global PTUを使うなら予約設計を見直す好機
今回のAzure AI Foundry関連アップデートでは、Microsoft FoundryのGlobal PTU予約がリージョン非依存で一般提供となりました。これにより、複数リージョンでGlobal Provisioned Throughputを運用している組織は、予約を集約し、未使用予約やリージョン別の管理負荷を減らせる可能性があります。
一方で、Global予約はGlobalデプロイ向けであり、Data ZoneやRegionalには適用されません。また、予約は容量を保証するものではなく、デプロイ作成後に必要PTU数を確認してから購入するのが基本です。
次に取るべき行動は明確です。まず、現在のGlobal PTUデプロイと予約を棚卸しし、リージョン別ではなく合計PTU数・予約スコープ・実利用率で見直してください。そのうえで、Global予約に集約できるもの、Data ZoneやRegionalとして残すべきもの、予約せず時間課金で扱うべきものを分けることが、今回のGAを実務上のコスト最適化につなげる近道です。
コメント