Azure STTを用いて、字起こしをしているが、最近cancelledが頻発する

調べていくと、カスタムスピーチを使っている場合(もしくは、カスタムスピーチ+フレーズリスト)の場合に発生するようです。

カスタムスピーチの場合にcancelされる頻度が上がりました。。

カスタムスピーチのベースモデルは20241203です。まだサポート期限内のはずですが、あたらしいモデルを使えということでしょうか。

チャブーンです。

この件ですが、LLMモデル側に問題がある場合、ここで愚痴っても問題解決はしないと思います。念のためCopilot=コパくん、に聞いたところ、以下の回答が来ました。使い続ける場合、ローカルアプリ側で調整しなくてはいけない可能性がありますね。

このエラーは Custom Speech 固有というより、Speech SDK と Speech Service 間のストリーミング処理が滞留したとき に発生することが多いです。

Reason=CancellationReason.Error
code=CancellationErrorCode.ServiceTimeout
error_details=Due to service inactivity,
the client buffer exceeded maximum size.
Resetting the buffer.

Microsoft の説明によると、クライアント側で送信した音声データに対してサービス側の処理・応答が追いつかず、SDK の内部バッファが上限に達すると発生します。特に「サービス応答がリアルタイムより大幅に遅れる」「長時間の無音」「音声送信の異常」が原因候補として挙げられています。 [github.com], [learn.microsoft.com]

Custom Speech利用時によくある原因

1. カスタムモデルの処理遅延

標準モデルでは問題なくても、Custom Speech モデルでは推論時間が長くなり、

音声送信速度 > サービス処理速度

となることがあります。

まず確認してください。

• 同じ音声を標準モデルで試す
• Custom Speech だけで発生するか確認する

Custom Speech のみで発生する場合は、モデル側の問題の可能性があります。 [learn.microsoft.com], [github.com]

2. PushStreamへの書き込みが速すぎる

よくある実装ミスです。

NG例:

この場合、1時間の音声を数秒で送り込んでしまい、サービスが処理しきれません。

音声ファイルをリアルタイム認識として扱うなら、

16kHz PCM
= 約32KB/秒

程度の速度で送る必要があります。 [github.com], [github.com]

3. 長時間無音

Microsoft Q&A では、

• 8時間連続接続
• 1時間以上の無音区間

のようなケースでも同様のエラーが報告されています。 [learn.microsoft.com]

例えば

認識開始
↓
無音が数十分続く
↓
ServiceTimeout

というパターンです。

対策:

• 無音が続く場合はセッションを再作成
• VADで無音区間をスキップ
• 長時間接続しっぱなしを避ける

4. ネットワーク遅延

特に以下構成で発生例があります。

• ExpressRoute
• Private Endpoint
• プロキシ
• VPN

接続自体は正常でも、レスポンスの遅延で内部バッファがあふれることがあります。 [learn.microsoft.com], [github.com]

確認してほしいポイント

ログで以下を取得してください。

speechConfig.SetProperty(
    PropertyId.Speech_LogFilename,
    "speechsdk.log");

さらに

recognizer.Canceled += (s, e) =>
{
    Console.WriteLine(e.ErrorDetails);
};

を有効にして、

• SDKバージョン
• セッションID
• 発生タイミング

を採取します。

ありがとうございます。

（１）ただ、標準モデルでは同じ音声でも発生しません。これはカスタムモデルのみ無効化した状態と比較して確認しました。

また、発生自体がここ1か月ほどのことで、特にここ数日は急激に悪化しているため、こちらの作りの問題は考えにくいです。

（２）ソースはリアルタイム音声なので、早すぎることはないと思います。

（３）接続後わりとすぐでも発生します。

（４）ネットワークはとても疑いましたが、ネットワークが原因とおもわれるものはありませんでした。また、パブリックエンドポイント経由で同じAPIキー、同じカスタムモデルで発生したため、ネットワークは無関係だと判断しました。

原因ですが、20250820をベースモデルとして、同じデータで学習し、あたらしいエンドポイントを作成すれば問題がおきなくなりました。

ただし、これがベースモデルを変更したために解決したのか、

あたらしくエンドポイントを作り直したために解決したのかは切り分けしてません。

20241203をベースモデルにしていても作成日から2年間は有効であるのでちゃんと動いてほしいところですが、、

とりあえず問題が解決したのでここに残しておきます。