Azure AI / Azure OpenAI / 公式ブログ / 2026/07/09 / 重要
FoundryのEU・米国外モデル配備が9月から値上げ
公式ブログ原文
Microsoft Foundry のモデル配備価格更新が公開されました。モデル展開の費用設計、PoC から本番への移行判断、利用量管理に関係します。
要点
- Microsoft Foundry のブログ記事は、モデル配備に関する価格更新を扱っています。
- モデルを試す段階と本番運用する段階では、推論量、配備単位、待機コスト、利用者数の見積もりが変わります。
- 価格更新は新機能の発表以上に、既存の予算設計や利用上限の見直しに直結します。
今回のブログ記事で語られていること
Microsoftは2026年9月1日から、EU Data Zoneと米国外のRegional配備の価格を引き上げます。同時に、処理をアジア太平洋地域内に留めるAPAC Data Zoneを新設します。理由として、世界共通の設備余力を使うGlobal配備に比べ、特定の地域または国の中で高可用性を維持する方が費用を要すると説明しています。Globalの価格は変更せず、引き続き最も低コストな選択肢と位置付けます。
Global価格に対する上乗せ率は、APAC Data ZoneとEU Data Zoneが20%、US Data Zoneと米国Regionalが10%です。米国外のRegionalは国・地域によって25〜50%となります。日本、韓国、台湾は35%、フランス、香港、英国などは40%、ブラジル、シンガポール、EU North、EU Westは50%です。オーストラリアやインドなどは25%、カナダ、ドイツ、メキシコ、UAEなどは30%に設定されます。新規提供地域には以前の料金がないため、すべてが既存価格からの値上げという意味ではありません。
適用条件は課金方式で異なります。従量課金のStandardでは、2026年9月1日以降に公開されるモデルへ移行した場合に新しい上乗せ率が適用されます。現在利用中のモデルに留まる限り、今回の値上げはありません。一方、事前確保型スループットでは、EU Data Zoneまたは米国外Regionalの割当を持つすべての顧客が対象です。既存モデルなら影響しないと一括りにせず、従量課金か事前確保型かを分けて確認する必要があります。
記事は、処理場所と実行方式を組み合わせるFoundryの選択肢も整理しています。Globalは設備余力のある場所で処理し、Data Zoneは米国・EU・APACの選択地域内、Regionalは指定国の中に処理を留めます。実行方式は、柔軟なStandard、低遅延向けPriority Processing、予測可能な性能を確保する事前確保型スループット、大量処理を低コストで行うバッチから選べます。データ所在地の要件を支援する選択肢は提供されますが、規制要件を満たすかの判断は利用組織側の責任です。
コストを抑える手段として、要求ごとに品質・遅延・費用を見てモデルを選ぶモデルルーター、同じ長い文脈の再計算を減らすプロンプトキャッシュ、確保枠を超えた通信を受けるPTU Spillover、クォータ最適化も紹介されています。ただし、これらで地域上乗せが消えるわけではありません。現在のモデル、配備場所、課金方式、9月以降のモデル更新計画を一覧にし、データ所在地の必要性と追加費用をワークロード単位で比較することが今回の実務上の焦点です。
今回のブログ記事が関係する人
Microsoft Foundryを使うAI基盤担当、FinOps、プロダクトオーナー、調達担当に関係します。特に日本Regionalの利用、EU Data Zone、米国外の事前確保型スループットを契約している組織は、2026年9月1日までに影響額を確認する必要があります。
どう読むと価値があるか
従量課金では新しいモデルへ移行するまで価格が変わらない一方、事前確保型では既存利用も対象になる違いが重要です。日本RegionalはGlobal比35%上乗せです。単価表だけでなく、モデル更新時期、処理場所の必須条件、予約済み処理量を合わせて見積もる必要があります。
実務へのつながり
配備一覧からGlobal、Data Zone、Regionalを分類し、さらにStandardと事前確保型スループットを分けます。9月以降に公開されるモデルへ移行する予定、データ所在地の契約要件、現在のトークン量を加えて差額を試算します。Globalへ移せない理由がある場合は、その根拠を法務・セキュリティと確認します。
結局、今回のブログ記事をどう読むべきか
今回の価格改定は、処理場所の厳格さに追加費用を付ける変更です。Globalの安さだけで決めるのでも、規制対応を理由に最も狭いRegionalを一律選択するのでもなく、ワークロードごとに所在地要件、遅延、可用性、上乗せ率を対応させる必要があります。