Azure AIの公式ドキュメント更新「Updates from discussions/feedback」は、単なる表現修正として流し読みしない方がよい更新です。今回確認すべきポイントは、Azure OpenAI Responses APIのWebSocketモードにおけるstore=falseの扱い、APIキーとMicrosoft Entra ID認証の使い分け、previous_response_idによる継続処理、接続切断時の復旧設計です。
2026年4月29日のMicrosoftDocs系コミットでは、articles/foundry/openai/includes/how-to-websockets-content.mdが更新され、1ファイルに対して41行追加・6行削除の差分が入っています。対象はAzure AI全体の仕様変更ではなく、Azure OpenAI Responses APIのWebSocketモードに関する公式ドキュメントの更新として読むのが現実的です。(GitHub)
Azure AIの公式ドキュメント更新「Updates from discussions/feedback」で何が変わったか
今回のAzure AI公式ドキュメント更新で中心になるのは、Azure OpenAI Responses APIをWebSocketモードで利用する場合の説明です。公式ドキュメントでは、WebSocketモードは/v1/responsesへの永続的な接続を維持し、各ターンで新しい入力項目とprevious_response_idを送ることで継続する方式と説明されています。長いチェーンのワークフローでターンごとのオーバーヘッドを下げる狙いがあります。(Microsoft Learn)
実務上の変更点は、次のように整理できます。
| 確認項目 | 変更・明確化された内容 | 実務で見るべき点 |
|---|---|---|
| 対象ドキュメント | WebSocketモードの利用手順を含むhow-to-websockets-content.mdが更新された | Azure AI全体ではなく、Azure OpenAI Responses APIのWebSocket利用箇所を確認する |
store=false | WebSocketモードはstore=falseで動作すると説明されている | データ保持ポリシー、会話継続、障害復旧の設計を分けて確認する |
| ZDR表現 | 差分では「Zero Data Retention（ZDR）」を含む表現が削除され、store=false中心の表現に変更された | store=falseとZDRを同義として扱わず、コンプライアンス要件は別途確認する |
| 認証方法 | APIキーとMicrosoft Entra ID認証のサンプルが分けて示された | 本番環境では認証方式、権限管理、キー管理の方針を見直す |
| 継続処理 | previous_response_idと接続ローカルのキャッシュに関する説明が追加・整理された | 切断、失敗、再接続時のリカバリー処理を実装に入れる |
| 接続制限 | 1接続で同時実行できないこと、60分制限、再接続時の扱いが説明されている | 並列処理、長時間ジョブ、監視アラートの設計を見直す |
特に注意したいのは、今回のコミットが「新機能の華やかな発表」ではなく、議論やフィードバックを受けて公式説明を実装・運用寄りに整えた更新に見える点です。検索している開発者やクラウド管理者が知りたいのは「使えるか」だけではなく、「本番でどう扱えば安全か」です。
WebSocketモードはどのような用途で使うべきか
Azure OpenAI Responses APIのWebSocketモードは、短い単発チャットを高速化するための万能な方法ではありません。公式ドキュメントでは、エージェント型コーディングや、ツール呼び出しを繰り返すオーケストレーションループなど、多数のモデル・ツール間ラウンドトリップがあるワークフローに向くと説明されています。一方、単発リクエストや短い会話では標準のHTTP Responses APIを使い続ける方針が示されています。(Microsoft Learn)
判断基準はシンプルです。
| 利用シーン | WebSocketモードの適性 | 理由 |
|---|---|---|
| 1回の質問に1回回答するFAQボット | 低い | 接続維持や復旧処理の実装コストが見合いにくい |
| 数ターン程度の一般的なチャット | 中 | 既存のHTTP実装で十分な場合が多い |
| コーディングエージェント | 高い | ツール呼び出し、検証、修正指示が何度も発生しやすい |
| 複数ツールを使う業務自動化エージェント | 高い | 各ターンで増分入力だけを送る設計と相性がよい |
| 長時間の分析・調査ワークフロー | 高いが要設計 | 60分制限、再接続、状態復元を考える必要がある |
開発チームが最初にやるべきことは、既存の処理をWebSocketへ一括移行することではありません。まず、現在のアプリケーションで「同じ会話・同じタスクの中で、何度もモデルとツールの往復が起きている箇所」を洗い出すことです。
store=falseとZDRを混同しない
今回の差分で最も読み飛ばしてはいけないのが、store=falseとZero Data Retention（ZDR）に関する表現です。コミット差分では、従来の「ZDRとstore=falseの両方で動作する」という趣旨の文から、現在は「store=falseで動作する」という説明に変わっています。また、store=false時に永続化されたフォールバックがないという説明からも、ZDRを含む表現が削除されています。(GitHub)
これは「ZDRが使えなくなった」と短絡的に読むべきではありません。ただし、実務では次のように扱うべきです。
store=falseは、Responses APIの状態保存をどう扱うかというAPI利用上の設定です。一方、ZDRはデータ保持、監査、契約、コンプライアンスに関わる広い概念です。公式のWebSocket手順でZDR表現が外れた以上、設計書や顧客向け資料で「WebSocketモードはZDR対応」と書く場合は、別の公式情報や契約条件で確認する必要があります。
Microsoftのデータ、プライバシー、セキュリティに関する公式説明では、Azure Direct ModelsにAzure OpenAIモデルが含まれること、データの処理・保存・不正利用監視に関する説明、Responses APIのような状態を持つ機能では設定に応じてメッセージ履歴などのデータストアが作られることが説明されています。(Microsoft Learn)
実務での確認ポイント
| 確認対象 | 確認する内容 | 失敗しやすいポイント |
|---|---|---|
| APIリクエスト | storeを明示しているか | デフォルト挙動に任せ、後からデータ保持方針を説明できなくなる |
| 社内設計書 | store=falseとZDRを別項目として記載しているか | store=false = ZDRのように書いてしまう |
| セキュリティレビュー | 入力データ、ツール出力、ログ、監視データの保存先を確認しているか | API側だけ見て、アプリ側ログにプロンプトを残す |
| 顧客説明 | 公式ドキュメント、契約、Azure設定のどれを根拠にしているか | WebSocketの手順書だけを根拠にコンプライアンス要件を満たしたと判断する |
本番環境では、store=falseを設定しても、アプリケーションログ、APM、プロキシ、ツール実行ログ、デバッグログにプロンプトや応答が残る可能性があります。Azure AI側の設定だけでなく、周辺システムのログ設計まで含めて確認してください。
Microsoft Entra ID認証のサンプル追加は本番運用で重要
今回の更新では、WebSocketエンドポイントへ接続する例として、APIキーとMicrosoft Entra ID認証のサンプルが分けて示されています。公式ドキュメントでは、WebSocketモードがAPIキーとMicrosoft Entra ID認証の両方をサポートすると説明されています。(Microsoft Learn)
この変更は、サンプルコードが増えただけに見えますが、クラウド管理者やソリューションアーキテクトには重要です。APIキーは実装が簡単ですが、漏えい時の影響範囲、ローテーション、保管方法、開発者端末への配布が課題になります。一方、Microsoft Entra IDを使う場合は、マネージドIDやサービスプリンシパル、RBAC、条件付きアクセスなど、組織のID管理と合わせて設計できます。
Azure OpenAI Responses APIの一般的な手順でも、認証方法としてAPIキーまたはMicrosoft Entra IDが示され、Microsoft Entra IDが推奨とされています。(Microsoft Learn)
認証方式の判断基準
| 観点 | APIキー | Microsoft Entra ID |
|---|---|---|
| 初期実装 | 簡単 | やや設計が必要 |
| 本番運用 | キー保管とローテーションが重要 | ID、権限、監査と統合しやすい |
| 権限管理 | キーを持つ主体の制御が課題 | ロールやマネージドIDで管理しやすい |
| 監査 | アプリ側の工夫が必要 | AzureのID基盤と組み合わせやすい |
| 推奨される用途 | 検証、限定的なPoC | 本番、チーム開発、エンタープライズ運用 |
本番環境でAPIキーを使う場合は、コードに直書きしないこと、Key Vaultなどで安全に保管すること、漏えい時のローテーション手順を運用手順書に入れることが最低ラインです。Microsoft Learnでも、APIキーをコードに直接含めず、安全に保存する注意が示されています。(Microsoft Learn)
previous_response_idの扱いを設計しないと障害時に詰まる
WebSocketモードでは、同じチェーンを継続するためにprevious_response_idを使います。公式ドキュメントでは、同じソケット上で次のresponse.createを送り、直前のレスポンスIDをprevious_response_idに設定し、入力には新しい項目だけを含める流れが説明されています。(Microsoft Learn)
ここで重要なのは、「前回のIDを渡せばいつでも続きから再開できる」と考えないことです。公式説明では、アクティブなWebSocket接続上で、サービスは直近のレスポンス状態を接続ローカルのインメモリキャッシュとして保持するとされています。store=falseの場合、IDがキャッシュにないと永続化されたフォールバックがなく、previous_response_not_foundが返ると説明されています。(Microsoft Learn)
つまり、store=falseで低レイテンシな継続処理を使う場合は、次のような実装が必要です。
{
"type": "response.create",
"model": "<deployment-name>",
"store": false,
"previous_response_id": "<直前のresponse ID>",
"input": [
{
"type": "message",
"role": "user",
"content": [
{
"type": "input_text",
"text": "<新しい入力>"
}
]
}
]
}この形は概念としては分かりやすいものの、実運用では「IDが使えない場合にどうするか」まで決めておく必要があります。
previous_response_not_foundへの対応
previous_response_not_foundが返った場合、考えられる対応は大きく3つです。
| 対応 | 向いているケース | 注意点 |
|---|---|---|
| 新しいチェーンとして開始する | 短い会話、再生成しても問題ない処理 | 直前までの文脈が失われる |
| 必要な入力コンテキストを再送する | 業務ワークフローを継続したい場合 | トークン量とレイテンシが増える |
store=trueを検討する | 状態復元を優先する場合 | データ保持ポリシーとコンプライアンス確認が必要 |
障害対応を考えるなら、previous_response_idは単なるレスポンス識別子ではなく、「接続状態とセットで有効な継続キー」と捉えるべきです。特にstore=false運用では、接続が切れた後に同じIDで常に再開できるとは限らない前提で設計してください。
60分制限と非多重化を前提にアーキテクチャを組む
公式ドキュメントでは、1つのWebSocket接続で複数のresponse.createを受け取れるものの、実行は順次であり、1接続内での多重化はサポートされないと説明されています。また、接続時間は60分に制限され、制限に達したら再接続する必要があります。(Microsoft Learn)
この仕様は、スケーリング設計に直接影響します。
たとえば、1つのWebSocket接続を複数ユーザーや複数タスクで使い回す設計にすると、処理が詰まりやすくなります。並列実行が必要な場合は、複数接続を前提に設計する必要があります。長時間のエージェント処理では、60分に達する前に再接続し、store=true、全量コンテキスト再送、コンパクション結果の利用など、どの方法で復旧するかを決めておくべきです。
運用設計で入れておきたい項目
| 設計項目 | 推奨される確認内容 |
|---|---|
| 接続単位 | ユーザー単位、タスク単位、ジョブ単位のどれでWebSocketを張るか |
| 並列処理 | 1接続で多重化しようとしていないか |
| タイムアウト | 60分制限に達する前の再接続処理を入れているか |
| 監視 | 接続時間、再接続回数、previous_response_not_found発生数を記録しているか |
| 復旧 | コンテキスト再送、store=true、コンパクション利用のどれを採用するか |
| コスト | 再送やコンパクションによるトークン増加を見積もっているか |
「WebSocketだから速い」という理解だけで導入すると、接続管理と復旧処理でつまずきます。速さよりも、状態管理の責任範囲が変わる点を重視してください。
コンパクション利用時は継続パターンを分けて考える
長い会話やエージェント処理では、コンテキストが大きくなりやすくなります。公式ドキュメントでは、WebSocketモードにおけるコンパクションについて、サーバーサイドコンパクションとスタンドアロンの/responses/compactで継続パターンが異なると説明されています。サーバーサイドコンパクションでは通常どおり最新のprevious_response_idと新しい入力項目で継続し、スタンドアロンの/responses/compactでは新しい圧縮済み入力ウィンドウを基に新しいレスポンスを開始する流れです。(Microsoft Learn)
ここで失敗しやすいのは、圧縮後も同じprevious_response_idチェーンとして扱おうとすることです。スタンドアロンの/responses/compactはレスポンスIDではなく、圧縮された入力ウィンドウを返す説明になっています。そのため、previous_response_idを省略する、またはnullにして、圧縮済み出力を入力として渡す設計が必要です。(Microsoft Learn)
コンパクションの使い分け
| 方式 | 継続方法 | 向いているケース |
|---|---|---|
| サーバーサイドコンパクション | 最新のprevious_response_idと新しい入力で継続 | 通常の長期ワークフローを自動的に軽量化したい |
スタンドアロン/responses/compact | 圧縮済み入力ウィンドウを使い、新しいレスポンスとして開始 | 明示的に文脈を整理してから再開したい |
| 手動で要約して再送 | アプリ側で要約品質を制御したい | ドメイン固有の重要情報を残したい |
移行時は、長いワークフローを1つ用意し、「通常継続」「接続切断」「コンパクション後の再開」をそれぞれテストしてください。正常系だけのPoCでは、本番時の障害に気づけません。
開発者、管理者、アーキテクト別の確認ポイント
今回のAzure AI公式ドキュメント更新は、開発者だけが読めばよい内容ではありません。認証、状態管理、データ保持、障害復旧が絡むため、クラウド管理者、ソリューションアーキテクト、技術意思決定者も確認すべきです。
| 役割 | 確認すべきこと | 具体的なアクション |
|---|---|---|
| 開発者 | WebSocket接続、response.create、previous_response_id、エラー処理 | SDKや接続ライブラリの実装を確認し、再接続テストを書く |
| クラウド管理者 | 認証方式、Key Vault、マネージドID、監査ログ | APIキー運用を見直し、Entra ID利用方針を整理する |
| ソリューションアーキテクト | HTTPとWebSocketの使い分け、並列処理、状態復旧 | エージェント処理だけWebSocket化するなど適用範囲を決める |
| セキュリティ担当 | store=false、ログ、データ保持、ZDR説明 | アプリ側ログとAzure側設定を分けてレビューする |
| 技術意思決定者 | 移行コスト、運用負荷、性能メリット | PoC結果を基に段階導入するか判断する |
特にグローバル展開している組織では、英語版の公式情報を基準に確認することをおすすめします。Microsoftのデータ・プライバシー関連文書では、英語版を正式版として参照するよう明記されています。(Microsoft Learn)
移行準備でやるべき手順
Azure OpenAI Responses APIのWebSocketモードを検討している場合、次の順番で進めると失敗しにくくなります。
現在のAPI利用箇所を棚卸しする
まず、Chat Completions、Responses API、Assistants API、Realtime APIなど、どのAPIをどの用途で使っているかを整理します。WebSocketモードはResponses APIの話であり、音声やリアルタイム会話向けのWebSocket利用とは目的が異なります。
棚卸しでは、次の項目を一覧化します。
| 項目 | 記録する内容 |
|---|---|
| アプリ名 | どのサービス・機能でAzure OpenAIを使っているか |
| 現在のAPI | Chat Completions、Responses APIなど |
| ワークフロー | 単発回答、複数ターン、ツール呼び出し、エージェント処理 |
| 認証方式 | APIキー、Microsoft Entra ID、マネージドID |
| データ保持 | store設定、ログ保存、監査要件 |
| 障害対応 | タイムアウト、再試行、再接続、コンテキスト復元 |
WebSocket化する対象を絞る
次に、WebSocket化する候補を絞ります。最初から全機能を移行するのではなく、ツール呼び出しが多く、レイテンシ改善の効果が見込める処理に限定してください。
適した候補は、たとえば次のような処理です。
- コード生成、実行、修正を繰り返す開発支援エージェント
- 社内データ検索、外部API呼び出し、回答生成を複数回行う業務エージェント
- 複数ステップの調査、要約、検証を行うナレッジワーク支援
- 長いタスクを途中状態を保ちながら進めるバックエンド処理
一方、FAQ、短い問い合わせ、単発の分類処理、短文生成などは、既存のHTTP APIで十分な場合が多いです。
認証方式を決める
検証環境ではAPIキーで始めても、本番ではMicrosoft Entra IDの利用を検討してください。特に複数チームでAzure AIを利用する場合、キー共有よりもIDベースの権限管理の方が運用しやすくなります。
決めるべき項目は次のとおりです。
| 項目 | 判断内容 |
|---|---|
| 実行主体 | アプリ、ジョブ、ユーザー代理のどれで呼び出すか |
| ID | マネージドID、サービスプリンシパル、ユーザー認証のどれを使うか |
| 権限 | 最小権限でAzure OpenAIリソースにアクセスできるか |
| シークレット管理 | APIキーを使う場合、Key Vaultで管理するか |
| ローテーション | キーや資格情報の更新手順があるか |
失敗系を先にテストする
WebSocketモードのPoCでは、成功レスポンスの確認だけでは不十分です。次の失敗系を必ずテストしてください。
| テスト | 確認すること |
|---|---|
| 接続が切れた | 再接続後にどの方法で再開するか |
| 60分制限に達した | 事前再接続または制限到達後の復旧ができるか |
previous_response_not_foundが返った | 新規チェーン開始、全量再送、store=true検討の分岐があるか |
| 4xx/5xxが返った | キャッシュされた状態に依存し続けないか |
| 並列ジョブが増えた | 1接続に多重化しようとして詰まらないか |
| ログに機密データが残った | アプリログ、プロキシログ、監視ログを確認したか |
公式ドキュメントでは、ターンが失敗した場合に参照されたprevious_response_idが接続ローカルキャッシュから削除されることも説明されています。失敗後に同じ状態をそのまま使い回す設計は避けるべきです。(Microsoft Learn)
公式ドキュメント更新を読むときの注意点
MicrosoftDocsのコミットは、仕様変更、表現修正、サンプル改善、フィードバック反映が混在します。そのため、GitHubの差分だけを見て「サービス仕様が変わった」と断定しないことが大切です。
今回のような更新では、次の順番で確認すると安全です。
| 確認順 | 見るもの | 目的 |
|---|---|---|
| 1 | GitHubのコミット差分 | 何の文言・サンプルが変わったかを把握する |
| 2 | Microsoft Learnの該当ページ | 公開版の説明がどう反映されているか確認する |
| 3 | 関連するResponses APIページ | モデル、リージョン、APIサポート、制限事項を確認する |
| 4 | データ・プライバシー文書 | store=falseやデータ保持の扱いを別軸で確認する |
| 5 | 自社の設計・運用手順 | 影響があるコード、設定、説明資料を更新する |
Azure OpenAI Responses APIの公式ページでは、最新機能へのアクセスにv1 APIが必要であること、モデルやリージョンの対応は確認が必要であることも示されています。モデルやリージョンの対応状況は変わる可能性があるため、記事や設計書に固定的に書きすぎず、導入時点で公式ページを再確認する運用にしてください。(Microsoft Learn)
すぐに確認すべきチェックリスト
Azure AIの公式ドキュメント更新「Updates from discussions/feedback」を受けて、現場で最初に確認すべき項目は次のとおりです。
| チェック | 対応 |
|---|---|
| WebSocketモードを使っている、または検討している | store=false、previous_response_id、再接続設計を確認する |
| 社内資料にZDRと書いている | 根拠がWebSocket手順だけになっていないか確認する |
| APIキーを本番で使っている | Key Vault、ローテーション、漏えい時対応を確認する |
| Microsoft Entra IDへ移行したい | マネージドID、権限、トークン取得方法を検証する |
| 長時間エージェントを運用する | 60分制限と再接続時の復旧パターンを実装する |
| 並列処理が必要 | 1接続で多重化せず、複数接続設計を検討する |
| コンパクションを使う | サーバーサイドとスタンドアロンで継続方法を分ける |
| 本番移行前 | 失敗系テスト、ログ確認、監視メトリクスを追加する |
今回の更新は、Azure AIを使ったエージェント開発を「試す」段階から「運用する」段階へ進めるための確認ポイントが多い内容です。まずは自社のAzure OpenAI利用箇所を棚卸しし、WebSocket化する価値があるワークフローだけを選んでください。そのうえで、store=false、認証方式、再接続、previous_response_idのエラー処理を設計に入れることが、実務で最も重要な次の一歩です。
コメント