gpt‑4o‑transcribeはEUデータゾーンで使える？Azure OpenAIとAzure Speechで実現するEU内完結アーキテクチャ

Azure OpenAI の新しい音声認識モデル「gpt‑4o‑transcribe」を EU データゾーン内で完結させて使えるのか――Sweden Central での提供状況や Data Zone Standard との関係、そして現実的な代替案（Azure Speech など）まで、公式ドキュメントと Q&A をもとに整理します。

gpt‑4o‑transcribe と EU データゾーン問題の全体像

gpt‑4o‑transcribe とは何か

Azure OpenAI（Microsoft Foundry の Azure OpenAI モデル群）の一部として提供されている gpt‑4o‑transcribe / gpt‑4o‑mini‑transcribe は、/audio API（および Realtime API）経由で利用する音声認識（speech-to-text）モデルです。モデル一覧では、既存の Whisper と並ぶ「Speech-to-text models」として明示的に掲載されており、最大 25MB の音声ファイルに対応することが記載されています。

2025 年の「What’s new in Azure OpenAI in Microsoft Foundry Models」では、2025 年 4 月の項目として gpt‑4o‑transcribe / gpt‑4o‑mini‑transcribe のリリース、さらに 10 月には gpt‑4o‑transcribe‑diarize の追加がアナウンスされています。つまり、機能としてはすでに安定したラインナップになりつつあり、「今後 EU データゾーンでも使えるのでは？」という期待を持ちたくなるタイミングです。

しかし本当に「EU から出ない」構成が組めるかどうかは、モデルそのものの機能ではなく、どのデプロイメント種別で提供されているかで決まります。

デプロイメント種別とデータの行き先

Azure OpenAI / Foundry では、モデルのホスティング形態として複数の「デプロイメント種別（SKU）」が定義されています。公式ドキュメントの「Deployment types for Microsoft Foundry Models」によると、代表的な種別は次のとおりです。

デプロイメント種別	SKU 名	推論処理の場所	特徴
Global Standard	`GlobalStandard`	モデルが展開されている任意のリージョン（世界中）	最初に新モデルが出ることが多く、スループットが高いが、処理場所は地理的に限定されない
Data Zone Standard	`DataZoneStandard`	指定された「データゾーン」（例：EU ゾーン）内の任意のリージョン	EU データゾーンなど、ゾーン単位で処理場所を制約可能
Standard（リージョン）	`Standard`	選択した Azure リージョン内	リージョン単位で処理を固定、ただし対応モデルは限定される
Provisioned（リージョン）	`ProvisionedManaged`	選択した Azure リージョン内	スループットを事前確保する課金モデル。大規模・安定負荷向け

さらに、データ、プライバシー、セキュリティの解説記事では次のように整理されています。

Global デプロイ：プロンプトとレスポンスは、そのモデルがデプロイされている任意の地域で処理され得る
DataZone デプロイ：プロンプトとレスポンスは、指定されたデータゾーン（EU など）のいずれかの地域で処理される
いずれの場合も、保存データ（at rest）は顧客が選んだ Azure ジオ内に留まる（処理場所だけが変わる）

ここからわかる重要ポイントは次の 2 つです。

「Sweden Central にデプロイしたから EU 内だけで処理される」は Global Standard では成立しない
EU 内完結を保証したいなら、Data Zone Standard かリージョン Standard/Provisioned を選ぶ必要がある

では、肝心の gpt‑4o‑transcribe はどのデプロイメント種別で提供されているのでしょうか。

公式ドキュメントから読み解く gpt‑4o‑transcribe の現在地

モデル一覧：/audio API の音声モデルとしての位置づけ

「Foundry Models sold directly by Azure」の「Audio models」セクションでは、/audio API 向けのモデルが種別ごとに整理されています。Speech-to-text（音声→テキスト）については、主要なモデルとして次の 3 つ＋1 が挙げられています。

モデル ID	種別	最大音声サイズ	備考
`whisper`	汎用音声認識	25 MB	従来からの Whisper ベース
`gpt‑4o‑transcribe`	GPT‑4o ベース音声認識	25 MB	高精度な STT 用
`gpt‑4o‑mini‑transcribe`	GPT‑4o mini ベース音声認識	25 MB	軽量版 STT
`gpt‑4o‑transcribe‑diarize`	話者分離付き音声認識	25 MB	会議・コールセンター向け

つまり、機能面では Whisper の完全な後継候補として設計されており、Azure OpenAI 経由で「音声→テキスト」を行うなら、今後の本命は gpt‑4o‑transcribe 系であることは間違いありません。

Global Standard 一覧にだけ現れる gpt‑4o‑transcribe

同じ「Foundry Models sold directly by Azure」には「Model summary table and region availability」という大きな表があり、各モデルがどのデプロイメント種別（Global Standard / Data Zone Standard / Standard…）とリージョンで提供されているかが一覧になっています。

この表のうち、

Global Standard model availability

のヘッダ行には、次のモデル名が含まれています。

gpt‑4o‑transcribe（2025‑03‑20）
gpt‑4o‑mini‑transcribe（2025‑03‑20）
gpt‑4o‑transcribe‑diarize（2025‑10‑15）

一方、同じページの

Data Zone Standard model availability

のヘッダ行には、GPT‑5 系、GPT‑4.1 系、o シリーズ、そして GPT‑4o / GPT‑4o‑mini などが並びますが、gpt‑4o‑transcribe 系の名前は出てきません。

つまり現時点では、

gpt‑4o‑transcribe / gpt‑4o‑mini‑transcribe / gpt‑4o‑transcribe‑diarize は「Global Standard」デプロイのみが公開されている
Data Zone Standard / Data Zone Provisioned / Data Zone Batch のいずれの表にも当該モデルは掲載されていない

という状態です。

Sweden Central で見えても「Global Standard」である理由

実際、上記の Global Standard の表を見ると、Sweden Central（swedencentral）の行にもチェックマークが並んでおり、Sweden Central にリソースを作成すると gpt‑4o‑transcribe が「使える」ケースがあります。

しかしこれは「Sweden Central リージョンの Global Standard デプロイを使っている」に過ぎません。デプロイメント種別が GlobalStandard である以上、前述の公式説明のとおり、

プロンプト（今回でいう音声データ）とレスポンス（文字起こし結果）は、モデルが展開されている任意の地理（EU 外を含む）で処理され得る

という前提は変わりません。Sweden Central にあるからといって、EU 内で完結しているとは言い切れないのです。

Microsoft Q&A での公式コメント

この点は、Microsoft Q&A のスレッド「gpt‑4o‑transcribe availability within EU data zone」でも繰り返し質問されています。

2025‑04‑17 の初回回答では、gpt‑4o‑transcribe / gpt‑4o‑mini‑transcribe の提供は Global Standard に限定されており、EU データゾーン対応については「将来のリリース予定は公開されておらず、What’s new を確認してほしい」とされています。
2025‑09‑26 時点のモデレーター回答では、「GPT‑4o‑transcribe を Data Zone Standard に載せる ETA はない」と明言されており、フィードバックフォーラムへの要望投稿が案内されています。

Sweden Central で利用できるようになった、というコメントはあるものの、それはあくまで「Global Standard として Sweden Central からも呼べるようになった」だけであり、EU データゾーン内完結（Data Zone Standard）になったわけではない、という整理が妥当です。

EU 域外にデータを出せない場合の実務的な選択肢

ここまでを踏まえると、2025‑12‑07 時点では：

「音声データを EU 域外に絶対出せない」要件で gpt‑4o‑transcribe を使うのは現実的ではない

という結論になります。では、実務ではどのような構成を取るべきでしょうか。

第一候補：Azure AI Speech（Speech サービス）に切り替える

Azure AI Speech（旧 Speech Service）のリージョン一覧では、次のように明記されています。

Speech service は、リソースのあるリージョン外でデータを保存・処理しない
音声データは、リソースを作成したリージョン内でのみ保存・処理される

つまり、Speech リソースを EU リージョン（Sweden Central / West Europe / France Central など）に作成すれば、音声データは物理的にも論理的にも EU 内に留めることができます。

このため、EU 域外へのデータ持ち出しが禁止されているプロジェクトでは、次のような 2 段構えがもっとも現実的です。

音声→テキスト：Azure Speech（EU リージョン）
テキスト処理：Data Zone Standard 対応の LLM（Azure OpenAI）

Data Zone Standard の表を見ると、GPT‑4.1 系や GPT‑5 系、GPT‑4o（テキスト／マルチモーダル）などが EU データゾーンに対応していることがわかります。このため、「音声は Speech で EU 内処理 → テキストは Data Zone Standard の LLM で EU データゾーン内処理」というルートを組めば、音声・テキストとも EU 境界を越えない構成にできます。

Azure Speech と gpt‑4o‑transcribe の比較イメージ

項目	Azure OpenAI gpt‑4o‑transcribe 系	Azure AI Speech （音声認識）
サービス種別	Foundry / Azure OpenAI の /audio API	Azure AI Services の Speech サービス
データの処理場所	Global Standard のため、モデルが展開されている任意の地域（EU 外含む）	リソースを作成したリージョン内のみ（例：Sweden Central）
EU 完結の保証	なし（現状 Data Zone Standard 対応モデル一覧に含まれていない）	Speech リソースを EU リージョンに置けば、EU 内完結が公式に保証される
LLM との一体感	同じ /audio / Realtime API で LLM と密に連携可能	テキスト出力を別途 Azure OpenAI に渡す二段構成が前提
コンプライアンス適合のしやすさ	Global デプロイの性質上、EU 域外処理リスクの説明が必要	リージョン単位で処理が固定されるため、説明が容易

推奨アーキテクチャ：EU 境界を越えないひな型

EU 域外への転送禁止（あるいは強い抑制）が求められる環境では、次のような 3 レイヤー構成をベースラインとしておすすめします。

音声→テキスト（Speech）
- Azure AI Speech リソースを EU リージョン（例：Sweden Central）に作成
- リアルタイム／バッチ／高速変換など、要件に応じたエンドポイントを選択
テキスト処理（Data Zone Standard LLM）
- Azure OpenAI（Foundry）のリソースを EU メンバー国リージョンに作成
- デプロイメント種別として DataZoneStandard を選択し、GPT‑4.1 / GPT‑4o / GPT‑5 などを利用
ストレージ（EU リージョン）
- Blob Storage や Cosmos DB なども EU リージョンに統一
- 暗号化・キー管理（CMK）やログ保持期間は社内ポリシーに合わせる

この構成であれば、

音声データ：Speech（EU リージョン）で処理
文字起こしテキスト：Data Zone Standard の LLM（EU データゾーン内）で処理
永続データ：すべて EU リージョンのストレージに保存

となるため、「音声もテキストも EU 内完結」という説明がしやすくなります。

ざっくりとした実装フロー（イメージ）

実装イメージをもう少し具体的に落とし込むと、例えば次のようなフローになります。

クライアントから音声ファイル（またはストリーミング）を受信（ブラウザ／モバイル／IVR など）
API サーバーがその音声を Azure Blob Storage（EU）に一時保存、または直接 Speech SDK に渡す
Azure Speech（EU リージョン）で文字起こし
得られたテキストを、Data Zone Standard の GPT‑4.1 / GPT‑4o などに渡して要約・分類・翻訳などを実施
結果を EU リージョンのストレージ／業務システムに保存し、クライアントへ返却

アプリケーションコードとしては、「Speech SDK 呼び出し部分」と「Azure OpenAI（Responses API or Chat Completions）呼び出し部分」を分離しておくと、将来 gpt‑4o‑transcribe が Data Zone Standard に対応した際にも切り替えやすくなります。

どうしても gpt‑4o‑transcribe を使いたい場合の考え方

現時点では EU データゾーン対応がない gpt‑4o‑transcribe ですが、「それでもどうしても使いたい」というケースもあるはずです。その場合は、あくまで法務・コンプライアンス部門の判断を前提に、次のような緩和策を検討することになります。

1. グローバル処理であることを前提にしたリスク評価

まず大前提として、Global Standard は「モデルが展開されている任意の地域で処理され得る」ことが公式に明記されています。

Sweden Central にリソースを作ったとしても、gpt‑4o‑transcribe の実際の推論処理が East US 2 や North Central US で行われる可能性を排除することはできません。このため、

EU 域外へのデータ転送に関する法的根拠（標準契約条項 SCC など）
Microsoft のデータ保護体制・準拠認証（ISO、SOC、GDPR 対応など）

と照らし合わせて、「グローバル処理でも許容できるか」を法務・コンプライアンスと一緒に評価する必要があります。

2. 音声の匿名化・マスキング

EU 域外処理を一定程度許容できる場合でも、リスク低減策としては次のような前処理が考えられます。

事前匿名化：録音前に本名や住所を取らない運用ルールを設計する（問い合わせ番号だけを読み上げてもらう等）
音声フィルタリング：オンプレや EU 内の自社環境で、名前・住所・電話番号など明確な PII 部分をマスキングまたはミュートしてから gpt‑4o‑transcribe に送る
ログ制御：アプリケーション側のログに音声の生データや全文文字起こしを保管しない（必要最低限のメタデータのみ保持）

もちろん、こうした処理は技術的・運用的コストが高くなるため、「そこまでして gpt‑4o‑transcribe を使う価値があるか？」はプロジェクトごとに慎重に判断する必要があります。

3. GlobalStandard を禁止する Azure Policy の活用

逆に、「グローバル処理を許容しない」強いポリシーを組織として採用する場合は、Deployment Types のドキュメントに記載されているように、Azure Policy を使って GlobalStandard SKU のデプロイメントを禁止することも可能です。

これにより、開発者が誤って Global Standard のモデル（gpt‑4o‑transcribe 等）をデプロイするリスクを技術的に抑止できます。その代わり、「音声認識は Speech で統一する」というアーキテクチャ上の制約を全社レベルで受け入れることになります。

よくある誤解と整理しておきたいポイント

誤解 1：「Sweden Central にあれば EU 外に出ない」

これは本記事の核心でもありますが、

リージョン（Sweden Central）とデプロイメント種別（Global / DataZone / Standard）は別物

です。Foundry の仕様では、Global Standard デプロイは、リソースがどのリージョンにあってもそのモデルが展開されている任意の地理にトラフィックをルーティングできるとされています。

Sweden Central で gpt‑4o‑transcribe が使えるようになったのは、「Sweden Central から GlobalStandard の gpt‑4o‑transcribe にアクセスできるようになった」という意味であり、「EU データゾーン内限定で処理される」ことを意味してはいません。

誤解 2：「Data Zone Standard と書いてあれば EU で完結する」

Data Zone Standard の説明では、EU データゾーンの場合、プロンプトとレスポンスは EU メンバー国のいずれかのリージョンで処理されるとされています。

つまり、「EU 外には出ない」という点では安心できますが、「必ず Sweden Central だけで処理される」とは限りません（France Central や West Europe 等も含む EU データゾーン内でダイナミックにルーティングされ得ます）。

これは通常、GDPR の観点からは問題にならないケースが多いですが、「特定の国（例：ドイツ国内のみ）に処理を限定したい」といった超厳格な要件がある場合には、Data Zone よりも「Standard / Provisioned（リージョン固定）」を検討する必要があります。

誤解 3：「gpt‑4o-transcribe が EU データゾーンにそのうち載るはず」

もちろん将来的に Data Zone Standard 対応が追加される可能性はありますが、現時点（2025‑12‑07）では、

モデル一覧（Foundry Models）の Data Zone Standard 表には gpt‑4o‑transcribe 系が載っていない
Microsoft Q&A でも「Data Zone Standard への追加予定（ETA）はない」とコメントされている

という状況です。プロジェクト計画としては、「載るかもしれない」前提で設計するのではなく、現状は載っていない前提でアーキテクチャを組むのが安全です。

要件別：おすすめ構成パターン

最後に、要件の違いごとにざっくりとした構成パターンを整理しておきます。

パターン	前提条件	推奨構成	コメント
A. 厳格 EU 境界（PII 含む）	音声に PII を多く含み、EU 域外転送は禁止	Speech（EU リージョン）＋ Data Zone Standard LLM	本記事で紹介した 2 段構え構成。最も保守的で説明しやすい
B. EU 域外も条件付き許容	SCC 等に基づき EU 外処理を許容可能	gpt‑4o‑transcribe（Global Standard）＋匿名化・マスキング	性能重視。ただしコンプライアンス部門と十分な合意が必須
C. PII ほぼ無し	テンプレ音声や機械ログなど、個人情報がほとんど存在しない	gpt‑4o‑transcribe（Global Standard）をシンプルに利用	EU データゾーン要件が緩い場合は、実装コストが最小
D. 将来の Data Zone 対応を見越す	現状は Speech で良いが、gpt‑4o‑transcribe の EU 対応を期待	アプリを「音声認識層」と「LLM 層」に分離して設計	将来 gpt‑4o‑transcribe が Data Zone Standard に載っても差し替えが容易

設計時に整理しておきたいチェックリスト

最後に、実際に要件定義や設計を行う際に整理しておくと議論がスムーズになる観点をまとめます。

1. 対象音声のプロファイル

長さ：1 回あたり数秒〜数分なのか、1 時間を超える会議録音なのか
同時接続数：何ストリームを同時にさばく必要があるか（Speech の SKU やスケールに影響）
リアルタイム性：低遅延が必須か、数分遅れのバッチでよいか

2. PII（個人情報）の有無と強さ

氏名、住所、クレジットカード番号など、明確な PII が含まれるか
音声から人物を特定し得るメタ情報（顧客番号＋小規模ユーザ母集団など）が含まれるか
匿名化やマスキングをどこまで現実的に行えるか

3. 保存要件

生の音声を保存する必要があるか（なければ、Speech で即時テキスト化して音声破棄も検討可能）
文字起こしテキストの保持期間（例：30 日、90 日、永続）
暗号化や鍵管理（Microsoft 管理キーで十分か、CMK が必要か）
監査ログをどこまで残すか（誰がいつ、どの音声を処理したか）

これらを整理した上で、

「gpt‑4o‑transcribe を使うべき案件」
「Azure Speech を使うべき案件」

を切り分けていくと、余計な議論を減らし、プロジェクトの進行をスムーズにできます。

まとめ

gpt‑4o‑transcribe / gpt‑4o‑mini‑transcribe / gpt‑4o‑transcribe‑diarize は、2025‑12‑07 時点で Global Standard デプロイのみが公式に一覧化されている（Data Zone Standard の表には載っていない）。
Microsoft Q&A でも「Data Zone Standard への対応予定（ETA）はない」と明言されている。
Global Standard はモデルが展開されている任意の地理で処理され得るため、Sweden Central で見えていても「EU から出ない」とは言えない。
音声データを EU 域外に出せない要件がある場合は、Azure AI Speech（EU リージョン）で文字起こしを行い、その後 Data Zone Standard 対応の LLM でテキスト処理を行う二段構成が現実的かつ安全である。
どうしても gpt‑4o‑transcribe を使う場合は、グローバル処理であることを前提に、匿名化・マスキングや Azure Policy による制御などのリスク低減策を講じる必要がある。

今後、gpt‑4o‑transcribe 系が Data Zone Standard に対応する可能性はありますが、現時点では「未対応」を前提に設計し、Azure Speech を組み込んだ EU 内完結アーキテクチャを標準パターンとして持っておくのが、もっとも現実的な戦略と言えるでしょう。

参考リンク

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。