メインコンテンツまでスキップ

概要

AmiVoice API では、プロトコルの異なる3種類の 音声認識 API を提供しています。

  • 同期 HTTP 音声認識 API
  • 非同期 HTTP 音声認識 API
  • WebSocket 音声認識 API

同期 HTTP 音声認識 API は簡単に利用できる点が特徴ですが、16MB よりも大きいファイルは送信できません。長い音声の場合は、非同期 HTTP を使ってください。 また、リアルタイムに書き起こしをしたい場合は、WebSocket 音声認識 API を使ってください。

共通の特徴

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

  • HTTP や WebSocket による通信なので、クライアント側に特殊なライブラリを組み込む必要がありません。
  • HTTPS および WSS による暗号化通信なので、通信経路上の安全が確保されます。
  • 認識結果は、JSON 形式で返します。
  • 録音、および、音声データを対応する音声フォーマットにすることは、クライアントアプリケーションの責任で行います。
注記

同期 HTTP 音声認識 API と WebSocket 音声認識 API では、同じ音声データを同じパラメータで認識させた場合、同じ結果になります。一方、非同期 HTTP 音声認識 API は、若干計算リソースを多く利用できるようになっているため、認識結果は異なる可能性があります。

同期 HTTP 音声認識 API (短い音声ファイル)

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

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

注記

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

ヒント

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

非同期 HTTP 音声認識 API (長時間の音声ファイル)

すでに音声ファイルが存在し、16MB よりも大きい場合にこの方式を採用します。同期 HTTP 音声認識 API とリクエストの方法は同じですが、結果を得る方法が異なります。音声認識のリクエストを送ると、音声認識のジョブとして登録され、順に処理されることになります。リクエストのレスポンスに含まれるジョブの ID を使って、ジョブの状態や結果を得ることができます。

この方式は、例えばコールセンターの通話録音ファイルや、会議の録音ファイルをまとめてテキスト化するようなバッチ処理に使うことを想定しています。

ヒント

非同期 HTTP 音声認識 API は、認識途中結果は返しません。認識途中結果が必要な場合には、WebSocket 音声認識 API を使用してください。

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

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

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