インタフェースの種類と使い方
AmiVoice APIは用途に応じて3つのインタフェースを提供しています。
このセクションではそれぞれの違いや使い分けるための基準、使い方について説明します。
同期 HTTP インタフェース
実装が最も簡単な方法です。リクエストパラメータをつけて音声ファイルをHTTP POSTで送信すると、レスポンスに発話内容のテキストが得られます。音声ファイルのサイズが 16MB 以下の場合にのみ利用できます。
ユースケース
- 認識精度などの検証を行いたい場合
- アプリケーションへの組み込みを簡単に行いたい場合
- 短い発話を認識させたい場合
認識結果を逐次取得できませんが、認識させたい発話が数秒程度と十分に短く、結果のリアルタイム性もそれほど強く要求されない場合はプロダクションでも利用できます。
利点
音声といくつかのパラメータをHTTP POSTで送信するだけなので簡単に実装できます。また、curl、Postman、Visual Studio CodeのREST Clientなど、HTTPリクエストを送信できるツールがあればすぐに試すことができます。
注意点
- 音声ファイルが 16MB を超える場合はエラーになります。
- Chunked 形式で分割送信することもできます。ただし、結果はまとめて返します。
- 送信した音声データに複数の発話区間が含まれる場合でも、発話区間の時間情報を返しません。発話区間の結果が必要な場合には、非同期 HTTP インタフェースやWebSocket インタフェースを使ってください。
- 認識途中結果(音声認識 結果が確定する前の仮説)は返しません。認識途中結果が必要な場合には、WebSocket インタフェースを使用してください。
リソース
- チュートリアルの短い音声ファイルの書き起こしにステップバイステップで実行する例を示しています。
- 開発ガイドの同期 HTTP インタフェースにリクエストの送信方法を説明しています。
- 仕様の詳細はAPIリファレンスの同期 HTTP インタフェースを参照してください。
非同期 HTTP インタフェース
音声認識のジョブとしてサーバ側で非同期的に音声認識処理が実行されます。ジョブが完了するまでポーリングし、ジョブが完了したら認識結果を得ることができます。
ユースケース
- 大きな音声ファイル(16MB より大きい場合)をテキストに変換したい場合
- 逐次レスポンスを受け取る必要がなく、少しでも精度を上げたい場合
例えば、コールセンターの通話録音ファイルや、会議の録音ファイルをまとめてテキスト化するようなバッチ処理を想定しています。
音声認識にかかる時間は、送信した音声の0.5〜1.5倍程度です。例えば、1時間の音声を送信した場合は、結果を得るまでに30〜90分程度の時間がかかります。このような場合、ひとつのHTTPセッションでリクエストと結果の取得を行うと、長時間セッションを維持する必要があり、途中でセッションが切れてしまった際に結果が得られない可能性があります。そのため、同期HTTPインタフェースでは、音声ファイルのサイズを16MB以下に制限しており、それよりも大きな音声ファイルは、非同期HTTPインタフェースを用いてリクエストと結果の取得を分けて行うことにしています。 なお、非同期HTTPインタフェ ースの新しいバージョン（v2）では、音声データをある程度の長さに分割して並列処理を行うため、ほとんどの場合、送信した音声の0.5〜1.5倍程度よりも早く音声認識処理が終わります。
利点
- 他のインタフェースよりも精度が良くなる可能性があります。
注記
当社の様々なテストセットに対して、非同期 HTTP インタフェースは、他のインターフェースよりもエラー改善率が平均5%ポイント高い結果を出しています。 これは以下の理由によるものです。
- レスポンスをすぐに返す必要がないため、ある時点の音声の発話内容を推定するのに、多くの未来の情報を先読みしてから処理を行うことができる。
- 同期HTTPやWebSocketインタフェースを使って認識させるときよりも、計算リソースを多く利用できるように設定され ている。
- トークンごとの時間情報だけでなく、発話区間の結果から発話の開始、終了の時刻が得られます。音声ファイルに複数の発話区間が含まれる場合、発話の開始時刻、終了時刻を利用できます。
注意点
- ジョブを開始するまでに数十秒〜数分程度の遅延があるため、短い音声を認識させる場合には相対的に遅延時間の影響が大きくなります。また、短い音声に対しては上記の利点の精度改善の効果も小さくなります。
- 認識途中結果(音声認識結果が確定する前の仮説)は返しません。認識途中結果が必要な場合には、WebSocket インタフェースを使用してください。
リソース
- チュートリアルの長い音声ファイルの書き起こしにステップバイステップで実行する例を示しています。
- 開発ガイドの非同期 HTTP インタフェースにリクエストの送信方法を説明しています。
- 仕様の詳細はAPIリファレンスの非同期 HTTP インタフェースを参照し てください。
WebSocket インタフェース
WebSocket 接続をすることで、双方向通信が可能になります。ストリーミング音源から音声をサーバに少しずつ送信し、音声認識結果を逐次取得できます。リアルタイム性が求められるアプリケーションに向いています。
ユースケース
- 音源が音声ストリームで逐次結果を取得して利用したい場合
- 音声認識の途中結果(音声認識結果が確定する前の仮説)を利用したい場合
- ユーザーの話し終わりの検出の精度を高めたい場合
利点
- 音声認識結果を逐次取得できます。
- 認識途中結果(音声認識結果が確定する前の仮説)が得られます。音声認識結果は発話の終端を検出してから結果が確定するため、リアルタイムアプリケー ションでは結果が得られるまでに時間がかかってしまいます。画面に途中結果を表示することでユーザーへの素早いレスポンスを実現できます。
- 発話の終端の検出をAPI側で行うことができます。例えば、同期 HTTP インタフェースを使って対話アプリケーションを実装しようとすると、ユーザーが話し終わったタイミングで録音を終了して音声ファイルを作成する必要があります。録音システムが終端検出機能を持っていない、または単純な音量に基づく実装しか持っていない場合には、背景ノイズが大きい場合やユーザーの声が小さい場合などはうまく動作しないことがあります。WebSocketインタフェースの場合は、音声データを逐次送信するだけで、AmiVoice APIの深層学習モデルを使った発話の終端の検出を利用することができ、単純な音量による終端検出より良い精度で話し終わりを検出し結果を得ることができます。
- トークンごとの時間情報だけでなく、発話区間の結果から発話の開始、終了の時刻が得られます。音声ファイルに複数の発話区間が含まれる場合、発話の開始時刻、終了時刻を利用できます。
注意点
- WebSocket接続した後、音声認識サーバとは独自のテキストベースのプロトコルで通信する必要があるため、実装が複雑になります。
リソース
- 開発ガイドのWebSocket インタフェースにリクエストの送信方法を説明しています。
- プロトコルの詳細を隠蔽して様々なプログラム言語から簡単に扱えるようにしたクライアントライブラリを提供しています。リアルタイム音声認識ライブラリ Wrpの使い方で説明しています。
- 仕様の詳細はAPIリファレンスのWebSocket インタフェースを参照してください。