AmiVoice Cloud Platformでは、音声認識を行う方式として、プロトコルの異なる2種類のAPIを提供しています。

  1. HTTP音声認識API
  2. WebSocket音声認識API

共通の特徴

2つの方式に共通する技術的な特徴は以下の通りです。

・HTTPやWebSocketによる通信なので、クライアント側に特殊なライブラリを組み込む必要がありません。
・HTTPSおよびWSSによる暗号化通信なので、通信経路上の安全が確保されます。
・認識結果は、扱いやすいJSON形式で返却されます。
・録音すること、および、音声データを所定のフォーマットに整えることは、クライアントアプリの役目です。

2つの方式には各々の特徴がありますが、その相違は通信プロトコルの違いに由来するものです。どちらの方式であれ、同じ音声データを認識させた場合、認識結果は同じになります。

1. HTTP音声認識API (非ストリーミング )

クライアントアプリが、HTTPリクエストで音声データを一括送信し、そのHTTPレスポンスとして、 JSON形式の認識結果を受け取る方式です。既に音声ファイルが存在する場合で、その容量が大き過ぎない場合には、通常この方式を採用します。この方式を利用する際に開発者に要求される通信処理の知識は、HTTPのPOSTメソッドおよびマルチパートについてのみであり、とても簡単に利用開始することができます。この方式の弱点をあげるとすれば、1回でアップロードした音声データに含まれるすべての発話の認識処理が終了するまで、認識結果を受け取ることができないということでしょう。

この方式をリアルタイム録音で利用する場合には、少なくとも一区切りの録音が終わるまで音声データを送信できない点に注意が必要です。そのため、一区切りの録音完了までが長ければ長いほど、送信開始が遅れ、認識処理開始が遅れ、認識結果の返却が遅れます。つまり、送信する音声データが短くはなく(複数の発話区間が含まれていたり、ひとつの発話が長いなど)、かつ、結果のリアルタイム性(レスポンス速度)が強く要求されるケースには、この方式は不向きです。逆に言えば、認識させたい発話が十分に短く(数秒程度)、結果のリアルタイム性もそれほど強く要求されないケースであれば、リアルタイム録音の場合でも、この方式は十分検討に値します。

※ Chunkedエンコーディングで分割送信するのであれば、一区切りの録音完了を待つことなく送信を開始できるため、送信開始や認識処理開始の遅れは回避できます。しかし、1回でアップロードした音声データ(たとえ複数のチャンクで分割送信したとしても、それは1回のアップロードです。すなわち1セッションの音声データということです)に含まれるすべての発話の認識処理が終了するまで認識結果が返却されないことに変わりはありません。そのため、複数の発話区間が含まれている場合には、後述するWebSocket音声認識APIに比べて、認識結果の返却が遅れることになります。同じ音声データを送信した場合でも、WebSocket音声認識APIであれば各発話ごとに認識結果を受け取ることができるのに対し、HTTP音声認識API では、全発話の認識結果を最後にまとめて1回で受け取ることになってしまう、ということです。

※HTTP音声認識APIを利用する場合には、認識途中結果は返却されません。これは、HTTP通信内での輻輳エラーを防ぐためです。認識途中結果が必要な場合には、WebSocket音声認識APIを使用してください。

2. WebSocket音声認識API (ストリーミング)

クライアントアプリと音声認識サーバがWebSocket接続をすることで、双方向通信が可能になる方式です。この方式では、クライアントアプリがリアルタイムに録音している場合でも、一区切り(ひとつの発話)の録音完了を待つことなく、次々と音声データをストリーミング送信することが可能です。またサーバ側も、ストリーミングで届く音声データをリアルタイムに認識処理しながら、次々と結果を返却することが可能です。この方式は即応性に優れており、結果のリアルタイム性が強く要求されるケースに向いています。クライアントアプリは、録音・送信中であっても、これまでに送信した音声に関する各種イベント通知や認識途中結果、認識確定結果を、リアルタイムに受け取ることができます。イベントや認識結果は、HTTP音声認識APIと同じJSON形式で返却されます。

既に音声ファイルが存在する場合でも、この方式を採用することは可能です。その音声ファイルの録音時間が長い場合には、HTTP音声認識APIよりも、むしろこちらの方式を採用する方が現実的で賢明です。その場合クライアントアプリは、音声ファイルから音声データを少しずつ読み出しつつ、少しずつストリーミング送信するようにします。決して矢継ぎ早に送信せず、送出と送出の間に適切なインターバルを必ずとり、実際の発話速度と同程度もしくは若干早い程度の送出速度に抑えるように調節してください。詳細はサンプルアプリの実装を参照ください。尚、これはサーバ側の過負荷や通信エラーを避けることが目的であり、認識精度に影響するものではありません。

認識結果返却タイミングの比較

 50秒の音声データを送信するとします。この音声データの中で実際に発話があるのは、「10~20秒」と「30~40秒」だけです。この音声データの中には「2個の発話区間」があるということです。

    [0]————[10]########[20]———–[30]########[40]———–[50]

HTTP音声認識API の場合

50秒すべての音声データの送信を完了させない限り、確定した認識結果を得ることができません。最後にまとめて、2個の発話区間の認識結果が返却される、ということです。
※ 受け取るJSONの中では、各発話区間の認識結果の区別はありません。各単語の時間情報は含まれています。

WebSocket音声認識API の場合

50秒すべての音声データの送信を完了させなくても、1個目の発話区間の最後である20秒までの音声データの送信が終われば、1個目の発話区間の認識結果が返却されてくることになります。また、2個目の発話区間の最後である40秒までの音声データの送信が終われば、2個目の発話区間の認識結果が返却されてくることになります。

認識途中結果の通知について

WebSocket音声認識APIでは、発話区間のデータ送信途中でも、認識途中結果が次々と通知されてきます。認識途中結果の通知を何度か受け取ってから認識確定結果を受け取る、という流れが、発話区間の数だけ繰り返されるわけです。尚、認識途中結果はあくまでも未確定の途中情報であり、認識確定結果では内容が変化している場合があります。
HTTP音声認識API の場合、認識途中結果を受け取ることもできません。1回の音声データのアップロードについての結果通知はあくまでも1回です。

ブラウザアプリについての補足

ブラウザ上で動作するアプリの場合、そのブラウザがマイク録音可能でWebRTCに対応していれば、録音をして音声認識をさせることはどちらの方式でも可能です。ただし、認識結果を得るリアルタイム性は、両方式で差が出ます。また、両方式とも、動作させる端末スペックやブラウザの種類によっては、JavaScriptの実行遅延に由来する音飛びなどの品質劣化が起き、正しく認識できない場合があります。特にクライアントアプリ画面上で波形描画アニメーションなど負荷のかかる処理を行っている場合には音飛びが発生しやすいのでご注意ください。