Azure AI Foundryで生成AIアプリや社内向けCopilotを本番展開するなら、最初に確認すべきは「どのリージョンでプロジェクトを作れるか」だけではありません。結論として、Foundryプロジェクトの作成リージョン、利用するモデル、デプロイ種別、SpeechやContent Safetyなどの依存サービス、クォータを同じ流れで確認する必要があります。
2026年5月19日時点の公式情報を踏まえると、今回のポイントは「Azure AI Foundryの全機能が全リージョンで同じように使えるわけではない」ことを前提に、管理者と開発者が展開前に確認すべき判断軸を整理した点です。Microsoft Learnでは現在「Microsoft Foundry」という表記が使われており、Foundryは従来個別のAzure AIサービスとして提供されていた機能をまとめる位置付けです。ただし、機能の提供状況はリージョンによって異なり、公式ページも単一のリアルタイム一覧表ではなく、機能別の公式ページで確認する方針を示しています。 (Microsoft Learn)
Azure AI Foundryのリージョン別機能対応で何が変わるのか
Azure AI Foundryの「Feature availability across cloud regions」は、新機能の使い方を説明するページというより、本番展開前にリージョン対応をどう確認するべきかを整理した参照情報です。
特に重要なのは、次の3点です。
| 確認項目 | 実務上の意味 | 見落としやすい点 |
|---|---|---|
| Foundryプロジェクトを作成できるリージョン | そのリージョンでFoundryプロジェクトの土台を作れるか | プロジェクトを作れることと、目的のモデルや機能が使えることは別 |
| Foundry Modelsの対応状況 | Azure OpenAIモデル、Azure販売モデル、パートナー/コミュニティモデルの利用可否 | モデル、バージョン、デプロイ種別で対応リージョンが変わる |
| 依存サービスの対応状況 | Speech、Content Safety、Agent Serviceなどが使えるか | Foundry側と依存サービス側のリージョンが一致しない場合がある |
| クォータ | 想定トラフィックを処理できるか | クォータはテナント全体ではなく、サブスクリプション、リージョン、モデル、デプロイ種別ごとに見る必要がある |
公式ページでは、Foundryプロジェクトを作成できるリージョンとしてJapan Eastが含まれています。一方で、SpeechのサポートリージョンではJapan Eastに加えてJapan Westも掲載されています。つまり、「SpeechがJapan Westで使えるから、FoundryプロジェクトもJapan Westで作れる」とは判断できません。リージョン対応はサービスごとに確認する必要があります。 (Microsoft Learn)
管理者が最初に押さえるべき前提
プロジェクト作成リージョンは「入口」であり、最終判断ではない
Azure AI Foundryでは、まずFoundryプロジェクトをどのリージョンに作成するかを決めます。しかし、プロジェクトを作成できるリージョンであっても、利用したいモデル、Agent Serviceのツール、Speechの高度な機能、Content Safety APIなどが同じ条件で使えるとは限りません。
たとえば、日本のユーザー向けに低遅延を期待してJapan Eastを選ぶ判断は自然です。しかし、実際には次のような追加確認が必要です。
| 確認対象 | 確認する内容 |
|---|---|
| モデル | 利用したいモデル名、バージョン、デプロイ種別がJapan Eastで利用可能か |
| デプロイ種別 | Global Standard、Data Zone、Standard、Provisionedなどのどれを使うか |
| 依存サービス | Speech、Content Safety、Azure AI Search、Storage、Cosmos DBなどが要件を満たすか |
| クォータ | 本番のTPM/RPM、PTU、エージェント利用量を処理できるか |
| データ所在地 | 推論時のデータ処理場所が社内ポリシーや契約条件に合うか |
公式情報でも、Foundry Modelsはプロバイダーやデプロイ種別によってリージョン対応が異なると説明されています。Azure OpenAIモデル、Azureが販売するFoundry Models、パートナー/コミュニティモデルを同じ前提で扱わないことが重要です。 (Microsoft Learn)
デプロイ種別はリージョン選定とデータ所在地に直結する
Azure AI Foundryでモデルを展開するときは、モデル名だけでなくデプロイ種別も選びます。公式ドキュメントでは、デプロイ種別によってデータ処理場所、課金方式、性能特性が変わると説明されています。たとえばGlobal系は任意のAzureリージョンで処理される可能性があり、Data Zone系は米国またはEUの指定データゾーン内、Standard/Regional系はデプロイ先リージョンで処理されます。 (Microsoft Learn)
| デプロイ種別の考え方 | 向いている用途 | 注意点 |
|---|---|---|
| Global Standard | まず試したい、広いモデル対応や高い初期クォータを重視したい | 推論データが単一リージョン内に限定されない |
| Data Zone Standard | 米国またはEUのデータ境界を重視したい | 日本国内処理の要件にはそのまま合わない場合がある |
| Standard | 単一リージョンでの処理を重視したい | モデル対応やスループットが限定される可能性がある |
| Provisioned | 予測可能な高スループットや低レイテンシの安定性を重視したい | PTUの確保、費用、容量確認が必要 |
| Batch | 大量処理を非同期で安く処理したい | リアルタイム応答には向かない |
日本国内のデータ処理が要件に含まれる場合は、GlobalやData Zoneを安易に選ばず、StandardまたはRegional Provisionedのような単一リージョン処理の選択肢を優先して検討します。ただし、そのリージョンで目的のモデルと必要クォータが確保できるかは別問題です。
クォータは「リージョンごと」に確認する
Azure AI Foundryの本番展開で失敗しやすいのが、クォータの見落としです。Azure OpenAI in Microsoft Foundry Modelsのクォータは、テナント単位ではなく、サブスクリプション、リージョン、モデル、デプロイ種別ごとに割り当てられます。たとえば同じモデルでも、East USとJapan Eastでは別のクォータプールとして考える必要があります。 (Microsoft Learn)
公式情報では、Foundryポータルの「Operate > Quota」で「Show all」を有効にし、未展開のモデルやリージョンも含めて確認する流れが示されています。設計段階では、現在の利用量だけでなく、ピーク時、再試行、バッチ処理、将来のユーザー増加まで見込んで確認してください。 (Microsoft Learn)
影響範囲は管理者・開発者・利用部門で異なる
今回のリージョン別機能対応の整理は、Azure管理者だけでなく、アプリ開発者、セキュリティ担当、業務部門にも影響します。
| 立場 | 主な影響 | 確認すべきこと |
|---|---|---|
| Azure管理者 | リージョン、クォータ、RBAC、ネットワーク設計の見直し | サブスクリプションごとのクォータ、利用可能リージョン、Azure Policy |
| 開発者 | エンドポイント、デプロイ名、SDK設定、フェイルオーバー実装に影響 | モデルのデプロイ種別、環境変数、SpeechのリージョンID、Agentツール |
| セキュリティ担当 | データ所在地、認証方式、プレビュー機能の利用可否に影響 | Entra ID/RBAC、APIキー運用、データ処理場所、監査ログ |
| 業務部門 | 使える機能、応答速度、障害時の継続性に影響 | 利用予定機能が対象リージョンで使えるか、代替手段があるか |
新しいFoundryポータルはGAとして本番利用向けの中核機能を提供していますが、すべての機能がGAではありません。公式のGA概要でも、一部機能はPreviewのままであり、既存のAzure OpenAIやFoundry classicのワークフローではclassicポータルの継続利用が必要なケースがあると説明されています。 (Microsoft Learn)
本番展開前に確認すべき手順
利用シナリオを機能単位に分解する
最初にやるべきことは、「Azure AI Foundryを使う」と大きく捉えるのではなく、ワークロードを機能単位に分解することです。
たとえば社内ナレッジ検索型Copilotなら、次のように分解します。
| 機能 | 例 |
|---|---|
| 生成AIモデル | チャット応答、要約、分類 |
| 埋め込みモデル | 社内文書のベクトル化 |
| 検索基盤 | Azure AI Search |
| エージェント | Agent Service、ツール呼び出し |
| 安全対策 | Content Safety、プロンプト/出力の制御 |
| 音声機能 | Speech to Text、Text to Speech |
| 運用 | 監視、ログ、クォータ、アラート |
| ネットワーク | Private Endpoint、VNet、Firewall |
この分解をせずに「Japan Eastで作れそうだから進める」と判断すると、後から「目的のモデルがそのデプロイ種別で使えない」「Agentのツールが対象リージョンにない」「Speechのキーとリージョン設定が合わない」といった手戻りが起きます。
候補リージョンを2つ以上決める
本番環境では、第一候補リージョンだけでなく代替リージョンも設計に入れておくべきです。Microsoft Foundry自体は自動フェイルオーバーや災害復旧を提供しないため、複数リージョン展開、依存リソースの冗長化、フェイルオーバー手順は利用者側で設計する必要があります。 (Microsoft Learn)
日本向けサービスであれば、第一候補としてJapan Eastを検討するケースが多いでしょう。ただし、目的のモデルや機能が不足する場合は、Southeast Asia、East US、West Europeなど、要件に合う候補を比較します。ここで重要なのは、単に「近いリージョン」ではなく、モデル、機能、クォータ、データ所在地、運用体制をまとめて比較することです。
Foundryポータルと公式ドキュメントの両方で確認する
公式ページはリージョン確認の入口として有用ですが、最終確認は実際のサブスクリプションとテナントで行う必要があります。公式情報でも、ドキュメント上のリージョン一覧はスナップショットであり、本番展開前にはサービス別ページやインフラストラクチャページ、ポータル体験を確認するよう示されています。 (Microsoft Learn)
実務では、次の順番で確認すると安全です。
| 順番 | 作業 | 判断基準 |
|---|---|---|
| 1 | Foundryプロジェクトを作れるリージョンを確認 | 候補リージョンにプロジェクト作成が可能か |
| 2 | 利用モデルの対応を確認 | モデル名、バージョン、デプロイ種別が一致するか |
| 3 | クォータを確認 | TPM/RPM、PTU、同時実行数が足りるか |
| 4 | 依存サービスを確認 | Speech、Content Safety、Agent Serviceなどが使えるか |
| 5 | データ所在地を確認 | 推論データの処理場所が要件に合うか |
| 6 | PoCを同一条件で実施 | 本番と同じリージョン、サブスクリプション、認証方式で動くか |
| 7 | 代替リージョンを検証 | 障害時に切り替えられるか |
移行時に注意すべきポイント
既存のAzure OpenAI利用者はclassicとの併用を前提に棚卸しする
既存のAzure OpenAIリソースを使っている場合、すぐにすべてを新しいFoundryプロジェクトへ移行できるとは限りません。公式のGA概要では、Azure OpenAIの既存リソースや一部の未対応ワークフローについて、classicポータルを継続利用しながらFoundryプロジェクトへのアップグレードを計画する流れが示されています。 (Microsoft Learn)
移行前には、次の項目を一覧化してください。
| 棚卸し項目 | 具体例 |
|---|---|
| 既存リソース | Azure OpenAI、AI Search、Storage、Key Vault、Cosmos DB |
| リージョン | 現在のデプロイ先、移行後の候補リージョン |
| モデル | モデル名、バージョン、デプロイ名 |
| デプロイ種別 | Standard、Global Standard、Provisionedなど |
| 認証方式 | APIキー、Microsoft Entra ID、マネージドID |
| 接続元 | Webアプリ、業務システム、Power Platform、バッチ処理 |
| 運用設定 | クォータ、監視、アラート、コスト管理 |
移行時は、リージョン変更、モデル変更、認証方式変更を同時に行わないことが重要です。複数の変更を一度に入れると、障害が起きたときに原因を切り分けにくくなります。まず同じモデル・同じデプロイ種別でリージョン移行を検証し、その後にモデル更新やエージェント化を進めるほうが安全です。
Preview機能を本番依存にしない
Azure AI Foundryでは、GA機能とPreview機能が混在します。Preview機能は評価や検証には有用ですが、サービスレベル契約や制約の扱いがGAとは異なる場合があります。公式情報でも、Preview機能を本番依存にすること、APIキーがEntra IDのRBACと同じ粒度の制御を持つと考えること、リージョン確認を省略することが一般的な落とし穴として挙げられています。 (Microsoft Learn)
管理者は、次のようなルールを明文化しておくと運用しやすくなります。
| ルール | 例 |
|---|---|
| 本番で使える機能 | GAのみ。Previewは例外申請制 |
| 認証方式 | 原則Microsoft Entra IDとRBAC。APIキーは用途を限定 |
| デプロイ種別 | データ所在地要件に応じて許可するSKUを定義 |
| モデル更新 | Previewモデルは自動更新や廃止リスクを評価 |
| 監査 | 誰がモデルを展開・変更したかを記録 |
Azure Policyを使えば、特定のデプロイ種別を制限する運用も検討できます。たとえば、社内ポリシー上Global Standardを使えない環境では、許可されるSKUを事前に整理し、開発チームが誤って選ばない仕組みを作るべきです。 (Microsoft Learn)
Agent Serviceはモデルだけでなくツール対応も確認する
Foundry Agent Serviceを使う場合は、モデルが対応しているだけでは不十分です。公式情報では、Agent ServiceはAzure OpenAI Responses APIをサポートするリージョンのFoundryプロジェクトで利用できるとされており、さらにツールの利用可否もリージョンによって異なります。たとえばFile searchはItaly NorthとBrazil Southでは利用できないと説明されています。 (Microsoft Learn)
エージェント構成では、次のような確認が必要です。
| 確認項目 | チェック内容 |
|---|---|
| モデル | Agent Serviceで使えるモデルか |
| API | Responses APIが対象リージョンで使えるか |
| ツール | File search、Bing Search、コード実行、独自ツールなどが使えるか |
| 状態管理 | Basic/Standardモード、Cosmos DB、Storage、AI Searchの構成 |
| ネットワーク | Private networking、VNet、サブネット委任、Firewall要件 |
| 障害復旧 | エージェント定義、ナレッジ、ツール接続を再展開できるか |
Agent Serviceのプライベートネットワーク構成では、Standard Setupで専用の隔離ネットワーク環境を作れる一方、機能やリージョンに制約があります。特にBing Search groundingなどは対応リージョンが限定されるため、セキュリティ要件だけでなく機能要件とセットで確認してください。 (Microsoft Learn)
SpeechはリージョンIDとキーの不一致に注意する
Speechを使うアプリでは、SDKやREST APIに設定するリージョンIDが重要です。公式ドキュメントでは、Speech SDKでSpeechConfigを作る際にjapaneastのようなリージョンIDを指定し、Speechリソースのリージョンと一致させる必要があると説明されています。キーはリージョンに紐づくため、異なるリージョンのキーを使うと認証エラーになります。 (Microsoft Learn)
設定ファイルでは、少なくとも次の値を明示的に分けて管理します。
AZURE_OPENAI_ENDPOINT=<Azure OpenAIまたはFoundry Modelsのエンドポイント>
AZURE_OPENAI_DEPLOYMENT=<モデルのデプロイ名>
AZURE_SPEECH_REGION=japaneast
AZURE_SPEECH_KEY=<Speechリソースのキー>
CONTENT_SAFETY_ENDPOINT=<Content Safetyのエンドポイント>リージョン名をコードに直書きすると、検証環境、本番環境、代替リージョンでの切り替えが難しくなります。環境変数や構成管理に分離し、リージョン変更時にアプリを再ビルドしなくても済むようにしましょう。
展開設計で失敗しやすいポイント
「プロジェクトが作れる＝すべて使える」と判断する
最も多い失敗は、Foundryプロジェクトを作成できた時点でリージョン確認が終わったと考えることです。実際には、モデル、デプロイ種別、依存サービス、クォータ、ネットワーク制約をそれぞれ確認する必要があります。
特に、モデルカタログに表示されるモデルは契約条件、サブスクリプション、リージョン、デプロイ種別によって変わる可能性があります。開発者が個人検証で使えたモデルが、本番サブスクリプションでは使えないこともあり得ます。
Global Standardをデータ所在地要件なしに選ぶ
Global Standardは広いモデル対応や高い初期クォータの面で便利です。公式ドキュメントでも、Global deploymentsはAzureのグローバルインフラを使って利用可能なデータセンターへ動的にルーティングし、新しいモデルや機能が先に提供される傾向があると説明されています。 (Microsoft Learn)
一方で、推論データの処理場所を単一リージョンに限定したい場合には注意が必要です。社内規程、金融・医療・公共系の要件、顧客契約でデータ処理場所が定められている場合は、Global系ではなく単一リージョン処理を前提に設計してください。
クォータをコスト管理の代わりに使う
クォータは重要ですが、コスト管理の代替にはなりません。公式情報では、Foundry Modelsのクォータ階層は利用状況に応じて自動的に上がる仕組みが導入され、過去の承認済みクォータ増加は維持されると説明されています。また、自動アップグレードをオプトアウトする機能もありますが、プレビュー機能として扱われています。 (Microsoft Learn)
コストを抑えたい場合は、クォータだけに頼らず、Azure Cost Management、予算アラート、タグ設計、API Managementでのレート制限、アプリ側の利用上限を組み合わせるべきです。
障害復旧を後回しにする
Azure AI Foundryの本番利用では、モデルやプロジェクトだけでなく、Storage、Cosmos DB、Azure AI Search、Key Vault、Application Insights、Container Registryなどの依存リソースも設計対象になります。Agent ServiceのStandardモードでは、状態を保持する依存リソースの耐久性を利用者側で設計する必要があります。 (Microsoft Learn)
公式の高可用性ガイドでは、ユーザー割り当てマネージドID、Cosmos DBの継続バックアップ、StorageのGZRS、Infrastructure as Code、複数リージョンへのデプロイ、Azure Service Healthアラートなどが推奨されています。特に、Foundry自体が自動DRを提供しない点は、管理者が明確に理解しておくべきです。 (Microsoft Learn)
管理者・開発者向けチェックリスト
本番展開前には、次のチェックリストを使って確認してください。
| チェック項目 | 管理者 | 開発者 |
|---|---|---|
| Foundryプロジェクトの候補リージョンを決めた | 〇 | 〇 |
| 利用モデルとバージョンを確定した | 〇 | 〇 |
| デプロイ種別をデータ所在地要件に合わせて選んだ | 〇 | 〇 |
| Foundryポータルで対象リージョンのクォータを確認した | 〇 | |
| 依存サービスのリージョン対応を確認した | 〇 | 〇 |
| SpeechのリージョンIDとキーを環境別に分離した | 〇 | |
| Agent Serviceのツール対応を確認した | 〇 | 〇 |
| Preview機能の利用可否をルール化した | 〇 | |
| Entra ID/RBACを前提に権限設計した | 〇 | |
| APIキーの保管・ローテーション方針を決めた | 〇 | 〇 |
| 代替リージョンとフェイルオーバー手順を確認した | 〇 | 〇 |
| IaCで再現可能な構成にした | 〇 | 〇 |
| 監視、アラート、コスト管理を設定した | 〇 |
このチェックリストを満たせない項目がある場合は、まだ本番展開の準備が整っていません。特に、モデル対応、クォータ、依存サービス、データ所在地の4つは、後から修正すると影響が大きいため、設計初期に確認してください。
次に取るべき行動
Azure AI Foundryのリージョン別機能対応で重要なのは、公式ページに載っているリージョン名を眺めることではありません。自社のワークロードに必要なモデル、機能、依存サービス、クォータ、データ所在地要件を1枚の設計表に落とし込み、第一候補リージョンと代替リージョンの両方で検証することです。
まずは、次の項目をスプレッドシートや設計書にまとめてください。
| 項目 | 記入例 |
|---|---|
| ワークロード名 | 社内FAQ Copilot |
| 第一候補リージョン | Japan East |
| 代替リージョン | 要件に応じて選定 |
| 利用モデル | チャット、埋め込み、画像、音声など |
| デプロイ種別 | Standard、Global Standard、Provisionedなど |
| 依存サービス | Speech、Content Safety、AI Search、Storage |
| 必要クォータ | TPM、RPM、PTU、同時実行数 |
| データ所在地要件 | 日本、EU、米国、制限なしなど |
| Preview利用可否 | 不可、条件付き可、検証環境のみ |
| フェイルオーバー方式 | 手動、API Management、複数リージョン構成 |
Azure AI Foundryは、モデル開発からエージェント、運用管理までを統合できる強力な基盤です。一方で、リージョン対応を誤ると、機能不足、認証エラー、クォータ不足、データ所在地違反、移行の手戻りにつながります。公開前に「プロジェクト」「モデル」「依存サービス」「クォータ」「運用」の5点を確認し、同じ条件でPoCを実施してから本番展開に進めましょう。
コメント