Azure AI Video Indexerの字幕作成の進捗が40%進捗で停止してしまう

@yuki masuda - こんにちは。

本件の問題は解決いたしました。PGチームからの回答は以下の通りです。

本件の問題は修正済みであり、今後再発することはないと考えております。

2026-09-08 05:17 UTC — 根本原因分析（RCA）調査完了

結論：報告されたVideo Indexerのジョブは、9月1日～2日に「Japan East（東日本）」リージョンで確認されたバッチ文字起こし処理のバックログ（滞留）の影響を受けていました。これはAPIによる拒否や「15秒未満のメディア処理要件」に起因するものではなく、Speech（音声認識）バックエンドのキャパシティまたはオートスケーリングの障害によるものでした。

対象の文字起こしジョブについて

ID 7b2a485a-fc56-4a30-9d14-******* のジョブは、07:03:44.785Zに作成され、07:03:45.243ZにProductionJPE環境でジョブID 37a3ada9-9577-463b-aea6-******* としてキューに追加されました。

キューからの最初の取り出し（ピックアップ）は正常に行われ、キュー追加から1.114秒後には最初のデキュー（取り出し）が発生していました。その後、13:09:34Zまでに計431回のデキューが行われており、遅延はAPIによる受け付けや最初の取り出しよりも後の（下流の）工程で発生していたことが特定されました。

ご提示いただいた相関ID（correlation ID）004334be-... は、作成リクエストではなく、13:06Zに行われた文字起こし取得（Get Transcription）のポーリング（HTTP 200）のものです。なお、07:03Zの作成リクエストもHTTP 201を返していました。

Speech処理は6時間5分56秒経過後の13:09:41Zに最終状態（終了状態）に達し、RecordingsUriNotFound / BlobNotFound エラーで失敗しました。長時間のバックログにより、一時的なソースURI/Blobが利用できなくなったことが原因です。このコンテンツエラーは最終的な結果であり、問​​題の根本的な原因ではありません。

影響範囲とアラートの相関

対象のアカウント（viprod-je-speech）において、当該の送信期間中に作成された文字起こしジョブは104件（成功74件、失敗30件）でした。そのうち39件は、処理完了までに6時間以上を要しました。失敗の内訳は、RecordingsUriNotFound が21件、DownloadRecordingsUrisAuthenticationError が9件でした。この21件という数は、VIにおける21件のインデックス処理失敗と整合していますが、正確な1対1の対応付けを行うには、残りのVI IDも必要となります。

「Japan East」リージョンでは広範なサービス低下が発生しました。多くのカウントにおいて、1時間あたりのリクエスト到着数が処理完了数を上回り、アクティブなキューの滞留数は、9月1日09:00（UTC）時点の45,165件から、9月2日08:30（UTC）にはピーク時の375,761件へと増加しました。

したがって、IcM 860758750 と 860771942 は同一の機能低下事象を対象としていますが、08:50Z/09:20Z 時点でのモニターによる自動緩和措置は、10 分遅延の完了数に基づく「正常」判定が 3 回確認されたことのみを反映したものでした。これはリージョン内のバックログが解消されたことを意味するものではなく、09:20Z 以降も影響を受けた送信（サブミッション）が発生した原因はここにあります。

根本原因と緩和措置の確認

関連する IcM 861338468 における根本原因分析（RCA）により、8 月 27 日に JPE 環境へ ​​DQv5 がデプロイされていたことが確認されました。9 月 1 日の緩和措置の際、フロントエンドの DQv5 ルーティングは無効化されましたが、DQv5 Host HPA コントローラーは有効なままでした。そのため、DQv5 への取り込みが停止した後もバックエンド・デコーダーの HPA 最小/最大値が低い値に強制され続け、需要に応じたコンピューティング・リソースのスケールアップが妨げられました。さらに、同時期に発生した JPE Pool5 ノードプールのスケーリング障害も、キャパシティへの負荷を増大させました。9 月 2 日に DQv5 Host が無効化され、デコーダーのキャパシティがスケールアップされたことで、08:30Z 頃から継続的なバックログの解消（ドレイン）が始まり、その後キューの滞留数は急激に減少しました。

ステータス：過去の影響については緩和済みであり、その後のトラフィック状況は回復を示しています。Speech テレメトリ上では、VI（Video Indexer）で当初失敗した動画の再処理が成功したことは確認されていません。失敗したジョブについては、有効なソースメディアを使用して VI または顧客側から再送信を行う必要があります。再発防止策として推奨されるのは、DQv5 フロントエンドと Host/HPA 制御を同時に無効化し、再有効化の前に検証を行うこと、および単なる最終ジョブのレイテンシ数だけでなく、滞留期間の長いバックログや「到着から完了までの時間」を監視してアラートを設定することです。

本情報がお役に立てば幸いです。ご不明な点がございましたら、お知らせください。

この回答で疑問が解決した場合は、「回答の承認 (Accept Answer)」および「この回答は役に立ちましたか? (Was this answer helpful?)」に対して「はい (Yes)」をクリックしてください。

よろしくお願いいたします。