OpenAIのRealtime APIが一般提供になり、「Azure OpenAI Serviceでgpt-realtimeはいつGA？」「今すぐ本番導入するならどう使い分ける？」という疑問が増えています。最新状況を踏まえ、最短で安全に導入するポイントを整理します。
結論：Azureでも gpt-realtime は本番利用（GA）で使える
「OpenAI本家では gpt‑realtime / Realtime API がGA（一般提供）になった。Azure OpenAI ServiceではいつGAになるの？」という疑問は、2024年〜2025年前半は確かに多くの人が抱えていました。しかし、2025年後半に状況が大きく変わり、Azure側でも gpt-realtime がGAとして提供されています。
いま押さえるべきポイントはシンプルです。
- Azure上で「本番前提」で使うなら、基本は gpt-realtime（GA）/ gpt-realtime-mini（GA系） を選ぶ
- 旧来の gpt-4o-realtime-preview / gpt-4o-mini-realtime-preview は“プレビュー用途”として位置づけ、検証・比較・一部の限定用途に寄せる
- Realtime APIは GAのエンドポイント（/openai/v1） と、プレビューのエンドポイント（api-version付き） が混在するため、接続先とSDK設定を整理して移行する
提供状況の早見表（OpenAI本家 / Azure）
まずは「どこで、どのモデルが、GAなのか」を表で整理しておくと迷いが減ります。Azureは現在、Realtime系をAzure AI Foundry（Foundry Models / Direct Models）とAzure OpenAIリソースの両方の流れで扱えるため、見た目がやや複雑です。
| 利用基盤 | 本番向け（GA）モデル | プレビュー系モデル | 利用の入口 | 押さえる注意点 |
|---|---|---|---|---|
| OpenAI（本家） | gpt-realtime（GA） | gpt-4o-realtime-preview など | Realtime API（WebRTC / WebSocket / SIP） | 最速で新機能が来やすい。運用ポリシーや請求・契約の前提がAzureと異なる |
| Azure（Microsoft Foundry / Azure OpenAI） | gpt-realtime（2025-08-28）、gpt-realtime-mini（2025-10-06）、gpt-realtime-mini-2025-12-15（2025-12-15） | gpt-4o-realtime-preview（2024-12-17）、gpt-4o-mini-realtime-preview（2024-12-17） | FoundryポータルのModel Catalog／Azure OpenAIリソースのDeployments | Realtime系の提供リージョンが限定される。GAとPreviewでエンドポイント形式が違う |
AzureでのGAはいつ？時系列で確認する
「AzureでいつGAになったのか」を正確に把握するために、公式の更新情報を時系列で整理します。
| 日付 | 出来事 | 意味合い | 利用者への影響 |
|---|---|---|---|
| 2024年10月1日 | Azure OpenAIで GPT-4o-Realtime-Preview のパブリックプレビューを公式に告知 | Azure側のRealtimeは「まずはpreview」で提供開始 | 検証は可能。ただし本番利用は“リスクを許容した上で” |
| 2025年8月28日 | OpenAIが Realtime API をGA化し、gpt-realtime を発表 | 音声エージェントを“本番品質”で作るためのGAモデルが確定 | 本家ではGAモデルで本番導入が現実的に |
| 2025年8月（Microsoft Learnの更新） | Azure側でも「Realtime API audio model GA」を明記 | Azure AI Foundry Direct Models上で GPT RealTime / Audio がGA扱いに | Azure内で“GAモデル前提”の設計に切り替えられる |
| 2025年9月3日 | Microsoftが gpt-realtime のGA提供をアナウンス | Azure AI Foundry上で gpt-realtime がGAとして利用可能に | 「Azureでいつ？」への回答が明確に |
「Azure OpenAI Service」と「Azure AI Foundry」は何が違う？
最近のMicrosoftのドキュメントでは「Azure OpenAI in Azure AI Foundry Models」という言い回しが増えており、初見だと混乱しがちです。要点は、ポータルやモデルカタログがFoundryに統合されつつあり、Azure OpenAIリソースへのデプロイもFoundry側の導線で扱えるということです。
Realtime系モデルのデプロイ導線も、ドキュメント上で次のように書き分けられています。
- Azure OpenAIリソースの場合：Foundryポータルの「Deployments」からデプロイ
- Foundryリソースの場合：Foundryポータルの「Models + endpoints」からデプロイ
Azureで本番導入するなら、まず確認すべき3つ
利用できるリージョン
Realtime系（gpt-realtime、gpt-realtime-mini、そして旧preview）は、現時点ではEast US 2 / Sweden Centralでグローバルデプロイが可能と明記されています。まずは「この2リージョンにリソースを作れるか」が導入の分岐点になります。
また、Foundry機能全体としても East US 2 / Sweden Central / West US 2 が“機能の網羅性が高い”リージョンとして案内されています。Realtime導入の観点でも、設計の初期に押さえておくと後戻りが減ります。
プレビューを本番に持ち込まない理由
「プレビューでも動くなら、そのまま本番で…」となりがちですが、Realtime系に限らず、previewは将来の互換性・性能・制限が変わり得ます。実際、gpt-4o-realtime-preview のモデルカードには“テストとフィードバック目的で、本番トラフィック向けに最適化されていない”旨が明記されています。
GAモデルへ移行するメリット
- Microsoft側の更新情報で「GAモデルへの移行を強く推奨」とされている
- 新しい音声（Marin / Cedar）や、画像入力・関数呼び出し改善などの機能がGA前提で整理されている
- プレビュー世代より価格が下がる（約20%）というアナウンスもある
GAとPreviewで「接続先」が違う：エンドポイント整理
移行でつまずきやすいのが、同じRealtimeでもURL形式が2系統ある点です。AzureのWebSocketsドキュメントでは、GA版とPreview版の例が並べて提示されています。
WebSocket（Azure）の例
wss://{your-resource}.openai.azure.com/openai/v1/realtime?model={your-deployment-name} # GA
wss://{your-resource}.openai.azure.com/openai/realtime?api-version=2025-04-01-preview&deployment={your-preview-deployment} # Previewまた、WebRTCのGAプロトコルでは、ブラウザへ直接APIキーを渡さないために、短命トークン（ephemeral token）を発行するエンドポイントが案内されています。
https://{your-resource}.openai.azure.com/openai/v1/realtime/client_secretsWebRTCは「GAプロトコル」優先で設計する
Microsoft Learnでは、WebRTCについて“GA Protocol”を推奨し、既存ユーザーは移行計画を立てるべき、という趣旨が明記されています。Realtimeを長期運用するなら、ここは最初からGAプロトコル前提で組むのが安全です。
Realtime APIの接続方式：WebRTC / WebSockets / SIPの使い分け
AzureのRealtime APIは、WebRTC・WebSockets・SIPの3ルートで利用できます。公式ドキュメントでは、低遅延なクライアント向けにはWebRTCが推奨され、WebSocketsはサーバー間の用途に向く、と整理されています。またRealtime APIは「エンドユーザー端末へ直接つなぐ設計ではない」点も明記されているため、音声ストリームを終端する“中継層（クライアント統合/ゲートウェイ）”が必要です。
| 方式 | 向いている場面 | メリット | 注意点（実務で詰まりやすい所） |
|---|---|---|---|
| WebRTC | ブラウザ/モバイルなど“端末とリアルタイム会話” | 低遅延・音声ストリーミングに最適。GAプロトコル推奨 | 短命トークン発行サービスがほぼ必須。ネットワークやNAT環境の検証が要る |
| WebSockets | サーバー→モデルのストリーミング（低遅延が必須でない） | 実装が比較的単純で、サーバー側で制御しやすい | GA/PreviewでURLが異なる。クライアント直結より遅延が出やすい設計になりがち |
| SIP | 電話（通話）をRealtimeへ接続 | 既存の電話番号/コールフローに組み込みやすい | SIPトランク事業者との接続、Webhook運用、通話品質/録音/監査要件の整理が必要 |
今どう使い分ける？最短で本番導入するための判断表
「できるだけ早く本番導入したい」という前提で、現実的な選択肢を整理します。ポイントは、“Azure内に閉じたい理由”が強いかどうかです。
| 要件 | おすすめ | 理由 | 実装上のコツ |
|---|---|---|---|
| Azureの請求・ガバナンス・既存ネットワークに統合したい | Azureの gpt-realtime（GA） | Azure上でGAモデルが利用可能。運用統合がしやすい | East US 2 / Sweden Centralでリソース設計。GAエンドポイントへ寄せる |
| 最新機能・新モデルを最速で追従したい | OpenAI本家の gpt-realtime（GA） | 機能提供のタイムラグが出にくい | 将来Azureへ寄せる可能性があるなら抽象化レイヤーを用意 |
| どうしても対応リージョン外にデータを出せない | 当面は“音声→テキスト→LLM→TTS”の分離構成も検討 | Realtime系が対応リージョンに限定されるため | 要件が強いほど、リージョン拡大を待つより設計を分離して逃がす方が早い |
| PoCは急ぐが、本番は堅牢にしたい | Previewで検証 → GAへスムーズ移行 | 比較検証はpreviewで十分。ただし本番はGA前提が無難 | 最初からGA/Previewの差分（エンドポイント、イベント、音声）をコードで吸収 |
gpt-4o-realtime-preview → gpt-realtime 移行の具体手順
すでに preview 系でPoCを作っている場合、移行を“短期で終わらせる”ための手順をまとめます。
| ステップ | やること | チェックポイント |
|---|---|---|
| モデルの棚卸し | 利用中のモデル名、バージョン、APIの接続先を一覧化 | previewエンドポイント（api-version付き）か、/openai/v1 かを区別 |
| GAモデルを新規デプロイ | gpt-realtime（必要ならminiも）を別デプロイ名で作成 | 同一環境でA/B比較しやすい命名にする |
| 接続方式ごとに移行 | WebSocket / WebRTC / SIPで順番に移行 | WebRTCはGAプロトコル前提でテスト |
| プロンプトと音声設定の調整 | トーンや読み上げの要件（固有名詞、数字、免責文）を再評価 | 新音声（Marin / Cedar）を前提に“読み上げ品質”の回帰テスト |
| 本番リリース | 段階的ロールアウト、失敗時のフォールバックを用意 | previewへの後戻りではなく、テキスト対話へ落とす設計が安全 |
本番運用チェックリスト（音声エージェントはここが事故りやすい）
Realtimeは“低遅延”が売りですが、運用で詰まりがちなポイントも独特です。導入初期にチェックしておくと、障害対応のコストが激減します。
| 観点 | 最低限の対策 | 理由 |
|---|---|---|
| リージョン制約 | East US 2 / Sweden Central 前提で設計し、音声系をそこへ集約 | Realtime系の対応リージョンが限定されるため |
| 接続の安定性 | 切断・再接続（リトライ）とセッション再構築を実装 | 音声は“瞬断”がUXに直結する |
| ツール呼び出し（関数呼び出し） | タイムアウト、冪等性、失敗時のユーザー案内を設計 | 会話中に外部APIが遅いと“沈黙”が発生する |
| 監査・ログ | 音声→テキストの転写ログ、モデル出力、ツール呼び出しを相関IDで追跡 | 障害解析・品質改善・監査に必須 |
| モデル更新（バージョン） | 定期的に新バージョンで回帰テストし、切替を計画的に | GAでもモデル更新はある。Azureでは“廃止/引退”のルールがある |
モデルのライフサイクル（廃止・引退）を前提に運用設計する
「GAになった＝ずっと同じモデルを使い続けられる」ではありません。Azure OpenAIでは、モデルのdeprecation（新規不可）とretirement（利用不可）が明確に定義され、GAとpreviewで通知・猶予期間も変わります。
- GAのモデルバージョンは最低12か月提供される
- 12か月経過後、既存顧客は追加で6か月使える場合がある（新規は不可）
- 通知はAzure Resource Healthやメールで行われ、GAは少なくとも60日前通知などの目安が示されている
Realtime導入では「いつ切り替えるか」を後回しにすると、音声UXの回帰テストが追いつかずに詰みます。最初から“モデル更新の定常運用”をチームの仕事に組み込むのが現実的です。
| 項目 | Azureのルール（要点） | 実務でのおすすめ |
|---|---|---|
| GAバージョンの最低提供期間 | 最低12か月 | 四半期ごとに新バージョンで回帰テスト→問題なければ計画的に切替 |
| 既存顧客の猶予 | 12か月後に追加6か月の猶予が示されるケースあり | 「猶予で延命」ではなく、移行完了を前提に運用する |
| 通知経路 | Azure Resource Health / Email | サブスク所有者だけに依存せず、運用担当がアラートを受ける仕組みにする |
| Realtime previewの扱い | previewモデルは“not sooner than”で更新・退役が進む | PoC用途に限定し、本番はGAモデルへ寄せる |
参考までに、Azureの一覧では gpt-4o-realtime-preview（2024-12-17）はPreviewとして退役日（例：2026-02-02）や置き換え（gpt-realtime）が示され、gpt-realtime（2025-08-28）はGAとしてdeprecation/retirementの目安が掲載されています（運用計画を立てるときに重要な情報です）。
用語整理：GAとプレビューは何が違う？
最後に、用語を短く整理しておきます。
- GA（General Availability / 一般提供）：長期運用を前提に、互換性やサポートを含めて“本番利用”の土台が整った状態。Azure側でもRealtimeのGAモデルが明記されています。
- プレビュー（Preview / Public Preview）：検証・評価のための提供で、仕様変更や制限変更が入りやすい。モデルカード等で“本番最適化ではない”と明記されるケースがあります。
GA後も迷わない：更新情報で見るべきページ（運用者向け）
Realtime系はリリーススピードが速く、GAになってからも音声や機能、提供リージョン、モデルの世代交代が進みます。導入を“イベント”で終わらせず、運用の中で定点観測するために、最低限このあたりは押さえておくのがおすすめです。
| 目的 | 見るべき公式情報 | 分かること | おすすめ確認頻度 |
|---|---|---|---|
| 新機能・GA/Previewの更新 | Azure OpenAI（Foundry Models）の「What’s new」 | RealtimeのGA化、推奨移行、機能追加（画像入力、async function calling等） | 月1回 |
| 退役・アップグレード計画 | Model deprecations / retirements（廃止・引退） | GAは最低12か月、通知の目安、モデルごとの置き換え先 | 月1回＋通知設定 |
| リージョン選定 | Feature availability across cloud regions（リージョンサポート） | 機能の網羅性が高いリージョン（例：East US 2 / Sweden Central など） | 新規プロジェクト開始時 |
| 料金・提供形態 | Azure OpenAI の価格ページ | Realtime/Audioの提供形態や大枠の説明（Foundry / Azure OpenAI） | 四半期ごと |
| 本家のアップデート把握 | OpenAIの gpt-realtime / Realtime API 公式発表 | 新モデル・新機能の背景、設計思想、今後の方向性 | 重要アップデート時 |
まとめ：Azureで急いで本番導入するなら、GAモデル＋GAエンドポイントへ寄せる
2025年12月時点では、Azure側でも gpt-realtime がGAとして提供されており、「AzureでいつGA？」という問いには“すでにGA。2025年8月〜9月に公式に明記・アナウンス”と答えられます。
実務での最短ルートは、次の3点をセットで進めることです。
- モデルは gpt-realtime（必要なら mini）へ移行
- 接続先は /openai/v1 を基準にし、previewのapi-version付き接続を整理して消していく
- リージョン制約（East US 2 / Sweden Central）を早期に確定し、運用・監査・障害対応まで含めて設計する
これだけで、Realtime導入は「動いたら勝ち」から「継続運用できる」へ一気に前進します。
コメント