前回：hatsune.hatenablog.jp
はじめに
前回の投稿を書いているときに、Voice Live APIを使って、「You can add Azure Speech in Foundry Tools capabilities such as noise suppression, echo cancellation, and advanced end-of-turn detection」が可能という learn の情報を見つけました。
learn.microsoft.com
もちろん、今までも Azure Speech Service を WebSocket を使って呼び出すことはできましたが、「いままで」と「これから」は主流となる SDK が変わるのかを調べてみましょう。
(いままで) Speech SDK を使う
Azure Speech Service を WebSocket で呼び出す場合、Coginitive.Service.Speech SDK (Speech SDK) から呼び出します。
endpoint = $"wss://{this.Location}..stt.speech.microsoft.com/speech/recognition/conversation/cognitiveservices/v1?language={this.Language}";
subscription_key = ""
config = speechsdk.SpeechConfig(endpoint=endpoint, subscription=subscription_key)
いままでの留意点
Windows 版の Speech SDK は内部的に 「Microsoft.CognitiveServices.Speech.core.dll」という C++ ネイティブライブラリ (DLL) を使っているため、開発環境や実行環境に Visual C++ Redistributable (VC++ ランタイム) がインストールされていないとロードに失敗することがあります。
VC++ ランタイムは、OS標準添付ではないにしても、大抵の Windows 環境では、他のアプリを入れた時に導入されているため、あまり気に必要はないかも知れませんが、インストーラーで VC++ ランタイムがあるかを確認し、なければダウンロードしてインストールするというステップを（場合によってはインストール媒体にランタイムのインストーラーも入れて）設定することは個人的には避けたいのです。
いままでの ClientWebSocket での実現方法
Speech SDK の中から呼び出しているエンドポイントは次のようになります。
wss://japaneast..stt.speech.microsoft.com/speech/recognition/conversation/cognitiveservices/v1?language=ja-JP
このエンドポイントは、あくまでも Speech SDK からの呼び出しであり、この後のプロトコル（データのやり取り）が複雑という難点があります。
具体的に Speech SDK の内部で実施している次のようなことも自前実装が必要です。
- api-key ヘッダー
- X-RequestId
- Path: speech.config
- 最初の speech.config JSON
- PCM16 のストリーミング
- speech.hypothesis / speech.phrase / turn.start などのイベント処理
- ping/pong
- 接続維持
もちろんこのあたりをキチンと実装してしまえば、Speech SDK よりも柔軟な連携が可能となります。
(これから) Voice Live API
Voice Live API は、Windows 環境でも例えば WPF アプリならば「System.Net.WebSockets.ClientWebSocket」を使って WebSocket 通信を実現しているため、 VC++ ランタイム不要でリアルタイム音声認識が可能です。
gist.github.com
「いままで」から「これから」に移行するときの留意点
いままでを「Azure Speech Service API」、これからを「Voice Live API」として比較してみます。
| 項目 |
Azure Speech Service API |
Voice Live API |
| --- |
--- |
--- |
| エンドポイント |
``/stt/speech/recognition/...`` |
``/voice/live/ws`` |
| 認証 |
``api-key`` |
``api-key`` |
| モデル |
Azure Speech STT |
gpt-realtime-mini / MAI-Transcribe-1 など |
| LLM |
なし |
**内蔵** |
大きな違いはモデルの違いから生じる LLM の有無でしょう。
もし、 LLM がいらず音声認識だけが必要な場合では、「いままで」の方式の方が理にかなっています。
この場合、自前実装よりも素直に Speech SDK を使うことも視野に入れておくとよいでしょう。
まとめ
「いままで」と「これから」に加えて Foundry API についても追記して比較してみます。
| 項目 |
Azure Speech Service API |
Voice Live API |
Foundry API |
| --- |
--- |
--- |
--- |
| WebSocket |
✔ |
✔ |
❌ (RESTのみ) |
| 音声認識(ASR) |
✔ (ASR専用) |
✔ (Realtime ASR) |
✔ (MAI-Transcribe-1) |
| LLM |
❌ |
✔ (必ず LLM が入る) |
✔ |
| 用途 |
音声認識だけしたい場合の正解 |
会話AI・音声対話 |
バッチ処理・非リアルタイム |
何を使うべきか、用途から逆引きするのがよさそうです。
一方で、Voice Live API で LLM を指定しない場合は、「いままでの」Azure Speech を呼びだしてくれるとアプリ作成側としては非常に助かるのではないかと思いました。
