インタフェースの使い分け
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 インタフェースは、他のインターフェースよりもエラー改善率が平均5%ポイント高い結果を出しています。 これは以下の理由によるものです。
- レスポンスをすぐに返す必要がないため、ある時点の音声の発話内容を推定するのに、多くの未来の情報を先読みしてから処理を行うことができる。
- 同期HTTPやWebSocketインタフェースを使って認識させるときよりも、計算リソースを多く利用できるように設定されている。
- トークンごとの時間情報だけでなく、発話区間の結果から発話の開始、終了の時刻が得られます。音声ファイルに複数の発話区間が含まれる場合、発話の開始時刻、終了時刻を利用できます。
注意点
- ジョブを開始するまでに数十秒〜数分程度の遅延があるため、短い音声を認識させる場合には相対的に遅延時間の影響が大きくなります。また、短い音声に対しては上記の利点の精度改善の効果も小さくなります。
- 認識途中結果(音声認識結果が確定する前の仮説)は返しません。認識途中結果が必要な場合には、WebSocket インタフェースを使用してください。