Azure AIの公式ドキュメント更新「Update WebRTC session negotiation instructions」で最も確認すべき点は、Voice Live APIのWebRTC通話セッション開始時に使うエンドポイントが voice-live/realtime/calls と明示されたことです。従来の voice-live/realtime と混同している実装、環境変数、プロキシ設定、テストコードがある場合は、WebRTC用のセッションネゴシエーションだけを対象に確認してください。今回の更新は大規模な仕様変更というより、WebRTCセッション開始手順の誤解を防ぐための公式ドキュメント修正と見るのが現実的です。MicrosoftDocsのコミットでは、対象ファイルは articles/ai-services/speech-service/voice-live-webrtc.md、差分は1行追加・1行削除で、説明文として「WebRTC call sessionを開始する場合は voice-live/realtime ではなく voice-live/realtime/calls を使う」と明記されています。(GitHub)
Azure AIの公式ドキュメント更新「Update WebRTC session negotiation instructions」で何が変わったか
今回の更新は、Azure AIのVoice Live API with WebRTCに関するドキュメント更新です。Microsoft Learn上の該当ページは「Voice Live API with WebRTC (Preview)」で、2026年4月30日に更新されています。ページ内では、WebRTC接続によりWebクライアントやモバイルクライアントから低遅延のリアルタイム音声対話を実現できると説明されています。(Microsoft Learn)
変更の核心は、WebRTCのSDP交換を開始するためのWebSocketコントロールチャネルで、次のエンドポイントを使う点です。
wss://<your-ai-foundry-resource-name>.services.ai.azure.com/voice-live/realtime/calls?api-version=2026-01-01-preview&model=gpt-realtime英語版の公式ドキュメントでは、WebRTC call sessionを開始する際は voice-live/realtime ではなく voice-live/realtime/calls を使う、と明記されています。(Microsoft Learn)
ここで重要なのは、すべてのVoice Live API接続を機械的に /calls に変える話ではないという点です。Voice Live APIの一般的なWebSocketエンドポイント説明では voice-live/realtime が使われており、WebRTCを使う通話セッション開始手順では voice-live/realtime/calls が示されています。つまり、確認対象は「WebRTCでSDP offer/answerを交換して通話セッションを作る処理」です。(Microsoft Learn)
まず確認すべき結論
開発者、クラウド管理者、ソリューションアーキテクトが最初に見るべきポイントは次の3つです。
| 確認項目 | 見るべき場所 | 判断基準 |
|---|---|---|
| WebRTC通話開始エンドポイント | アプリコード、環境変数、設定ファイル | WebRTCのSDP交換に voice-live/realtime/calls を使っているか |
| 既存のWebSocket接続との切り分け | APIクライアント、SDKラッパー、共通接続関数 | WebSocketのみのVoice Live接続まで誤って /calls に変更していないか |
| 運用経路の許可設定 | API Gateway、WAF、プロキシ、監視ルール | /voice-live/realtime/calls へのWSS通信が遮断・誤ルーティングされないか |
今回の更新はエンドポイントの使い分けが主題です。WebRTC用のセッションネゴシエーションでは、WebSocketコントロールチャネルでSDPメッセージを交換し、ネゴシエーション完了後の音声はWebRTC RTPメディアトラックで送信されます。(Microsoft Learn)
voice-live/realtime と voice-live/realtime/calls を混同しない
実務で最も起きやすい失敗は、voice-live/realtime を「Voice Live APIの標準エンドポイント」として共通化し、そのままWebRTCセッション開始にも使ってしまうことです。
公式ドキュメントでは、Voice Live APIの一般的なWebSocketエンドポイントとして voice-live/realtime が紹介されています。一方、WebRTC call sessionを開始する箇所では voice-live/realtime/calls が使われています。(Microsoft Learn)
この違いは、実装上かなり重要です。
| 用途 | エンドポイントの考え方 | 注意点 |
|---|---|---|
| Voice Live APIの一般的なWebSocket接続 | voice-live/realtime | 既存のWebSocketベース処理を不用意に変更しない |
| Voice Live API with WebRTCの通話セッション開始 | voice-live/realtime/calls | SDP offer/answer交換を行うWebRTC初期化処理で確認する |
| WebRTCネゴシエーション後の音声 | WebRTC RTPメディアトラック | 音声データは通常のWebSocketイベントとして送る前提にしない |
| 非音声イベント | WebRTC data channelやWebSocket control channel | イベントの種類ごとに経路が分かれる |
設計上は、接続先を1つの REALTIME_ENDPOINT のような変数でまとめるより、用途別に分けるほうが安全です。
VOICE_LIVE_REALTIME_WS_ENDPOINT=/voice-live/realtime
VOICE_LIVE_WEBRTC_CALLS_ENDPOINT=/voice-live/realtime/callsこの名前はあくまで実装例ですが、設定名に「WebRTC」「calls」「realtime」を明示すると、後から運用担当者や別チームが見ても誤用しにくくなります。
WebRTCセッションネゴシエーションの流れを再確認する
Azure AIのVoice Live API with WebRTCでは、単にWebSocketで音声を流すのではなく、複数の通信経路を使い分けます。公式ドキュメントでは、典型的なセットアップとして、クライアントがVoice Live APIとのWebSocketベースのシグナリングチャネルを確立し、SDP offer/answerを交換した後、音声はWebRTC RTPメディアトラックで送信されると説明されています。(Microsoft Learn)
実装の流れは次のように整理できます。
| 手順 | 処理内容 | 確認ポイント |
|---|---|---|
| コントロールチャネル作成 | WebSocketでVoice Live APIに接続 | WebRTC開始時は /voice-live/realtime/calls を使う |
| SDP offer作成 | ブラウザー側で RTCPeerConnection を作成 | マイク権限、ICE gathering、localDescriptionを確認 |
| SDP offer送信 | rtc.call.sdp.create でSDP offerを送る | sdp_offer が空でないか |
| SDP answer受信 | rtc.call.sdp.created と sdp_answer を待つ | 応答イベントの種類を誤っていないか |
| remote description適用 | setRemoteDescription でWebRTC接続を完了 | ここまで進まない場合はSDP交換とネットワークを切り分ける |
| 音声・イベント処理 | 音声はRTP、非音声イベントは別経路 | WebSocketだけで全イベントを受ける設計にしない |
公式のサンプルでは、rtc.call.sdp.create に sdp_offer を含めて送信し、サーバー側から rtc.call.sdp.created と sdp_answer を受け取る流れが示されています。(Microsoft Learn)
開発者が確認すべきコード上のポイント
開発者は、まずリポジトリ内で次の文字列を検索してください。
voice-live/realtime
voice-live/realtime/calls
rtc.call.sdp.create
rtc.call.sdp.created
api-version=2026-01-01-previewvoice-live/realtime が見つかった場合、すぐに置換するのではなく、用途を判定します。
| コードの状態 | 対応 |
|---|---|
WebRTCのSDP交換に voice-live/realtime を使っている | voice-live/realtime/calls への修正を検討する |
通常のVoice Live WebSocket接続に voice-live/realtime を使っている | そのまま維持する可能性が高い |
| 接続関数がWebSocket用とWebRTC用で共通化されている | 引数や設定でエンドポイントを切り替えられるようにする |
| テストが接続成功だけを見ている | rtc.call.sdp.created と sdp_answer の受信まで確認する |
| エラー時のログがHTTP/WSS接続失敗だけ | rtc.call.error の中身を記録する |
特に注意したいのは、SDKラッパーや社内共通ライブラリです。アプリ本体では /calls に修正していても、共通ライブラリ側で voice-live/realtime を組み立てていると、WebRTCセッションだけが失敗します。
実装で分岐させる例
function buildVoiceLiveEndpoint(options: {
resourceName: string;
mode: "websocket" | "webrtc";
apiVersion: string;
model: string;
}) {
const base = `wss://${options.resourceName}.services.ai.azure.com`;
const path =
options.mode === "webrtc"
? "/voice-live/realtime/calls"
: "/voice-live/realtime";
return `${base}${path}?api-version=${encodeURIComponent(options.apiVersion)}&model=${encodeURIComponent(options.model)}`;
}このように、モードに応じてパスを分けると、将来の仕様確認やテストがしやすくなります。ポイントは、webrtc というモード名を明示し、WebRTCセッション開始時だけ /calls を選ぶことです。
クラウド管理者が確認すべき運用影響
クラウド管理者は、アプリコードだけでなくネットワーク経路を確認する必要があります。WSS通信のホスト名が同じでも、プロキシ、WAF、API Gateway、監査ログのルールがパス単位で制御されている場合、/voice-live/realtime/calls が許可されていない可能性があります。
確認すべき場所は次のとおりです。
| 領域 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| プロキシ | WSS通信が許可されているか | HTTPは通るがWSSが遮断される |
| WAF | /voice-live/realtime/calls がブロックされないか | 既存ルールが /voice-live/realtime の完全一致になっている |
| 監視 | 新しいパスをログ集計対象に含めているか | エラー率や接続数が別メトリックに分散する |
| シークレット管理 | APIキーやBearer tokenの適用先 | ブラウザー環境でAPIキーを露出させる設計になっていないか |
| リージョン | 対象リージョンとレイテンシ要件 | プレビュー機能の対応範囲を古い情報で判断する |
公式ドキュメントでは、Voice Live API with WebRTCはグローバル標準デプロイを使い、最寄りリージョンへ自動ルーティングしてレイテンシを最適化すると説明されています。また、対応リージョンは時期によって確認が必要な項目です。(Microsoft Learn)
ソリューションアーキテクトが見るべき設計上の論点
ソリューションアーキテクトにとって、今回の更新は「エンドポイント名の修正」だけではありません。リアルタイム音声AIを本番に近い環境で扱う場合、通信経路、責任分界、障害時の切り分けを見直すきっかけになります。
Voice Live API with WebRTCでは、WebSocketコントロールチャネル、WebRTC data channel、WebRTC media trackの3つの通信経路が使われます。公式ドキュメントでは、コントロールチャネルはSDP交換、セッション制御、エラー通知、ツールや関数呼び出しイベントに使われ、data channelはVADイベント、応答ライフサイクル、文字起こしデータなどを扱い、media trackはリアルタイム音声ストリームを扱うと説明されています。(Microsoft Learn)
設計レビューでは、次の観点で分けて考えると判断しやすくなります。
| 設計観点 | 確認すべきこと |
|---|---|
| 接続責任 | WebRTCの初期化をクライアントが担うのか、バックエンドが制御するのか |
| 認証 | ブラウザーに長期キーを持たせない設計になっているか |
| 監査 | SDP交換、セッション更新、エラー通知を追跡できるか |
| 障害対応 | 接続失敗、SDP不備、音声未到達を別々に切り分けられるか |
| 段階導入 | WebSocketベースの既存構成とWebRTC構成を併存できるか |
| プレビュー前提 | SLAなし・仕様変更可能性を踏まえたリスク管理があるか |
特に本番利用を検討している場合は、プレビュー機能である点を軽視しないでください。Microsoft Learnでは、この機能はパブリックプレビューであり、SLAなしで提供され、運用環境のワークロードには推奨されないと説明されています。(Microsoft Learn)
日本語ドキュメントを読むときの注意点
日本語版のMicrosoft Learnを参照する場合は、該当箇所の訳文だけで判断しないほうが安全です。2026年4月30日更新の日本語ページでは、本文上は voice-live/realtime/calls ではなく voice-live/realtime を使うように読める表現になっていますが、直後のサンプルURLは /voice-live/realtime/calls になっています。(Microsoft Learn)
一方、英語版では「use the voice-live/realtime/calls endpoint instead of voice-live/realtime」と明記されています。MicrosoftDocsのコミット差分でも、正しいエンドポイントの使用を明確化する更新として /calls が追加されています。(Microsoft Learn)
日本語圏のチームでは、次の運用にしておくと混乱を避けやすくなります。
| 状況 | 推奨される確認方法 |
|---|---|
| 日本語ページの文とサンプルURLが食い違う | 英語版とGitHubのコミット差分を確認する |
| 社内手順書を作る | 「WebRTC call sessionは /voice-live/realtime/calls」と明記する |
| 翻訳済みドキュメントを引用する | 該当箇所だけ英語原文も併記する |
| 実装レビューをする | URL文字列ではなく、用途と通信経路でレビューする |
移行準備でやるべきチェックリスト
既にAzure AIのVoice Live APIやリアルタイム音声機能を検証している場合は、次の順で確認すると効率的です。
| 手順 | 作業 | 完了条件 |
|---|---|---|
| 1 | WebRTCを使っている処理を洗い出す | SDP交換、RTCPeerConnection、rtc.call.sdp.create を使う箇所が特定できている |
| 2 | エンドポイントを確認する | WebRTC通話開始で /voice-live/realtime/calls を使っている |
| 3 | 通常WebSocket処理と分離する | WebSocketのみの処理を誤って /calls に変えていない |
| 4 | ネットワーク経路を確認する | WSSで /voice-live/realtime/calls へ接続できる |
| 5 | エラー処理を確認する | rtc.call.error、invalid_request_error、server_error をログに残せる |
| 6 | E2Eテストを追加する | SDP answer受信と setRemoteDescription 完了まで確認できる |
| 7 | 社内ドキュメントを更新する | 日本語訳の混乱を避ける説明が入っている |
このチェックリストで重要なのは、接続可否だけで終わらせないことです。WebSocketが開けても、SDP offerが不正だったり、sdp_answer を正しく受け取れていなかったりすると、音声は流れません。
よくある不具合と切り分け方
WebRTCまわりの障害は、原因がエンドポイント、SDP、ネットワーク、イベント経路のどこにあるか分かりにくいのが難点です。今回の更新を踏まえると、まずエンドポイントを確認し、その後にSDPとイベント経路を見るのが現実的です。
| 症状 | 可能性のある原因 | 確認すること |
|---|---|---|
| WebRTC開始時に接続できない | /voice-live/realtime を使っている、WSSが遮断されている | URLが /voice-live/realtime/calls か、プロキシが許可しているか |
| SDP answerが返らない | rtc.call.sdp.create の形式不備、sdp_offer 不足 | 送信JSONとSDP内容をログで確認する |
missing_sdp のようなエラーが出る | SDP offerが空、またはプロパティ名が違う | sdp_offer を送っているか |
| 音声が再生されない | remote description未設定、メディアトラック未処理 | setRemoteDescription と ontrack を確認する |
| イベントが想定した場所に来ない | data channelとcontrol channelの理解違い | イベント種別ごとのルーティングを確認する |
| ツール呼び出しが処理されない | バックエンドに届くべきイベントをクライアント側だけで待っている | control WebSocket側のイベント購読を確認する |
公式ドキュメントでは、エラー発生時にサービスがコントロールWebSocketへ rtc.call.error を送信し、error.type はクライアントエラーを示す invalid_request_error またはサービス側失敗を示す server_error になると説明されています。(Microsoft Learn)
実務では「置換」ではなく「経路の再設計」として扱う
今回の更新を単純なURL置換として扱うと、別の不具合を作り込みやすくなります。特に、既存のVoice Live API実装でWebSocket接続を使っている場合、全体を /calls に置換するのは危険です。
おすすめは、接続処理を次のように分けて管理することです。
接続種別:
- Voice Live WebSocket session
- Voice Live WebRTC call session
通信経路:
- WebSocket control channel
- WebRTC data channel
- WebRTC RTP media track
確認対象:
- endpoint path
- api-version
- model parameter
- authentication
- event routing
- error loggingこの分類にしておけば、将来APIバージョンやモデル、イベント仕様が更新されたときも、影響範囲を切り分けやすくなります。
APIバージョンとモデル指定もあわせて確認する
公式ドキュメントのWebRTCサンプルでは、api-version=2026-01-01-preview と model=gpt-realtime が含まれています。(Microsoft Learn)
運用では、エンドポイントパスだけでなく、APIバージョンとモデル指定も同時に確認してください。たとえば、設定ファイルに古いAPIバージョンが残っている、環境ごとにモデル名が違う、フロントエンドとバックエンドでクエリパラメータ生成ロジックが分かれている、といったケースがあります。
確認の観点は次のとおりです。
| 項目 | 確認内容 |
|---|---|
api-version | WebRTC用サンプルや現在の公式ドキュメントと矛盾していないか |
model | 利用するモデルが対象リージョンや機能に対応しているか |
| リソース名 | Microsoft Foundryリソース名が正しいか |
| 認証方式 | Entra IDまたはAPIキーの扱いが環境に合っているか |
| ブラウザー実装 | APIキーをクライアントに直接埋め込んでいないか |
Voice Live APIの認証について、公式ドキュメントではMicrosoft FoundryリソースまたはAzure Speech in Foundry Tools Servicesリソースが必要で、Microsoft Entraによるトークンベース認証やAPIキーの利用方法が説明されています。(Microsoft Learn)
チーム内で共有すべき短い説明文
社内のPull Request、変更管理、運用手順書には、次のように書くと誤解を減らせます。
Azure AI Voice Live API with WebRTCの公式ドキュメント更新により、WebRTC call sessionの開始には /voice-live/realtime ではなく /voice-live/realtime/calls を使用する点が明確化された。対象はSDP offer/answerを交換するWebRTCセッション開始処理であり、通常のVoice Live WebSocket接続を一律に変更するものではない。この説明に加えて、影響範囲として「WebRTC実装」「プロキシ/WAF」「E2Eテスト」「社内手順書」を明記しておくと、開発・運用・アーキテクト間の認識が揃いやすくなります。
今回の更新で次に取るべき行動
Azure AIの公式ドキュメント更新「Update WebRTC session negotiation instructions」で確認すべき最重要ポイントは、WebRTC call session開始時のエンドポイントです。英語版の公式ドキュメントとMicrosoftDocsのコミット差分では、voice-live/realtime/calls を使うことが明確化されています。(Microsoft Learn)
次に取るべき行動は明確です。まず、実装内の voice-live/realtime を検索し、それがWebRTCのSDP交換に使われているかを確認してください。WebRTC通話開始処理であれば /voice-live/realtime/calls への修正を検討し、通常のWebSocket処理であれば不用意に変更しないようにします。そのうえで、WAFやプロキシの許可設定、rtc.call.sdp.created まで確認するE2Eテスト、エラー時の rtc.call.error ログを整備しましょう。
プレビュー機能である以上、仕様やサポート範囲は変わる可能性があります。公式ドキュメントの更新日、英語版の原文、GitHubのコミット差分を確認しながら、小さな検証環境で接続経路を固めてから本格導入に進むのが安全です。
コメント