リアルタイムアプリケーションでレスポンス時間を調整する方法
2025年11月、AmiVoice API に音声認識処理に関して複数の新機能がリリースされ、それらを使うためのリクエストパラメータが追加されました。
こちらの記事では、それらのうちボイスボット向けのパラメータである「recognitionTimeout」と「noInputTimeout」についてご紹介をしましたが、今回はそれ以外の、リアルタイムアプリケーションのような利用シーンで活躍するパラメータについて紹介をします。
なお、音声認識リクエストにおけるパラメータの指定方法については、マニュアルを参照してください。
音声認識にかかる時間
AmiVoice の音声認識エンジンでは、一般に、音声認識に時間をかけるほうが認識精度は上がり、認識時間を短く済ませると精度は低下します(とはいえ、かける時間を極限まで増やせば認識精度が 100% になる、というわけではありません)。AmiVoice API のデフォルトの設定では、このトレードオフとなる「認識処理時間」と「認識精度」が、多くの場面において程よい塩梅となるように設定をしていて、ある発話区間の音声認識にかかる時間は、多くの場合、その発話区間の長さの 0.5~1.5 倍程度になります。
また、音声データの内容も認識処理にかかる時間に影響を与えます。ざっくりといえば、人間にとっても聞き取りやすいような音声であれば比較的処理が早く、音量が小さかったり雑音が多かったりと、人間にとっても聞き取りにくいような音声の場合は、処理にかかる時間が長くなりやすいです。
そのほか、たとえば日本語用の音声認識エンジンに対して英語の発話を認識させようとすると、エンジンは聞こえる発話を日本語として聞き取ろうとするため、認識に非常に時間がかかってしまう場合があります。しかもこの場合、認識結果はほとんど使い物になりません。
このように、音声認識処理にかかる時間の長さは、「認識精度をどのくらい求めるか」や「音声データの内容」により左右されます。(ほかにも、AmiVoice API の場合はサーバの混雑状況なども影響します)
では、認識時間をデフォルトでかかる長さよりも短く済ませるとどうなるかというと、実は必ずしも認識結果が使い物にならないほど精度が悪くなるというわけではありません。むしろ、多少であれば、認識にかける時間を短くしても、認識結果の大意には大きく影響しない場合もあります。
ここで、商業施設などの案内ロボットにおいて音声認識を用いる場合を考えてみます。
お客さまがロボットに対して発話による質問をし、ロボットが生成 AI を用いて回答を返すという場合、そのシステムとして、「お客さまが発話する」→「発話の音声認識を行う」→「音声認識結果を生成AIに渡して回答を作成」→「お客さまへ回答」というステップが考えられます。
ロボットとのやりとりにおいて、お客さまにとっては、発話が終わってから回答が返ってくるまでの間は待ち時間になるため、よりリアルタイムなやりとりを実現したい場合、音声認識にかける時間は、可能ならできるだけ短くしたくなりますよね。また、生成 AI による後処理を行うのであれば、発話の全てを高精度で認識できなくとも、大意を把握できれば良いかもしれません。
このような場面において、音声認識にかける長さをある程度制御するのに役立つのが、今回ご紹介する機能です。パラメータとしては「maxDecodingTime」「maxResponseTime」「maxDecodingRate」「targetResponseTime」「targetDecodingRate」の5種類があり、それぞれ認識時間の長さの制御の仕方が異なります。
リアルタイム認識とバッチ処理、「ResponseTime」と「DecodingRate」の使い分け
5つの機能をご紹介する前に、まず初めに「maxResponseTime」と「maxDecodingRate」、「targetResponseTime」と「targetDecodingRate」の使い分けについて触れておきます。
端的に言えば、「『ResponseTime』系はリアルタイムに録音しながらストリーミングで音声認識を行うシステム用」、「『DecodingRate』系は録音済みの音声データをバッチ処理で音声認識を行うシステム用」となります。逆の組み合わせの場合は機能が発動しません。これは、リアルタイムで音声認識をする場合と、バッチ処理を行う場合とで、音声認識にかかる時間と音声データの長さとの関係が異なることによります。
「ResponseTime」系は、認識処理にかける時間を、「音声の長さ + 任意の長さ(ResponseTime)」という観点で制御を行います。リアルタイムに録音・音声認識を行うシステムの場合、音声を少しずつ API に送信しながら音声認識処理を行っていくため、音声認識の開始からある時点までにおいて、「それまでに音声認識処理にかかった時間」はほぼ確実に「それまでに API へ送られてきた音声の時間」以上の長さになります。したがって、認識処理の時間は音声の長さよりどれくらい長いか、が重要となります。
一方、「DecodingRate」系は、「認識処理にかける時間 / 音声の長さ」の割合(DecodingRate)という観点で制御を行います。バッチ処理の場合は、音声データの送信は一度に行われます。そのため、音声認識のしやすい音声であれば、音声認識にかかる時間は音声データの長さよりも短くもなり得るので、音声の長さに対する割合が重要となります。
この点を念頭においていただいたうえで、次から各機能・パラメータの紹介をしていきます。
最大認識処理時間:maxDecodingTime
音声認識処理にかける時間の最大値を設定することができます。単位はミリ秒です。この時間は、発話区間ごとにカウントされます。また、リアルタイム認識の場合でも、バッチ処理の場合でも有効です。
以下の式のように、その発話区間の音声認識にかけた時間が、「maxDecodingTime」に設定した値を超えると、その時点でその発話区間の音声認識処理が強制的に終了します。
「maxDecodingTime」は、認識させたい音声の発話区間の長さよりも短く設定することも可能なので、かなりレスポンスの早い状態をつくることもできます。
一方、発話区間の長さに対して「maxDecodingTime」が短すぎると、発話区間の途中までしか認識処理がなされずに終わる場合もあります。たとえば、「アドバンスト・メディア」という発話に対して「maxDecodingTime」が短すぎると、認識結果が「アドバンスト」までしか得られない、というようなことが起こり得ます。
なお、リアルタイム認識の場合は、発話区間の長さよりも「maxDecodingTime」が短いと、発話区間の途中までしか認識できなくなってしまう点に注意してください。
また、一つの音声データの中に長さの大きく異なる発話区間が複数含まれる場合、ある発話区間に対しては「maxDecodingTime」が長すぎるが、ある発話区間に対しては短すぎる、ということが起こり得る点に注意してください。
最大応答時間:maxResponseTime
認識させたい音声の長さに対して、プラスで何秒まで音声認識にかけて良いかを設定することができます。単位はミリ秒です。リアルタイム音声認識の場合にのみ有効です。
以下の式のように、発話区間ごとに、音声認識にかけた時間が、API へ送られた音声の長さと「maxResponseTime」の合計値を超えると、その時点でその発話区間の音声認識処理が強制的に中断します。
この機能の場合、音声の長さよりも音声認識にかける時間を短くすることはできません。また、音声認識処理を強制中断させる機能は、その発話区間の全ての音声データを音声認識サーバが受信し終わった後にしか発動しません。
この機能は、リアルタイムで録音しながらストリーミングで音声を API に送信するようなタイプのアプリケーションにおいて活用することで、発話が終わってからレスポンスを受け取るまでの時間を、おおむね指定した一定の時間以内に収めることができます(サーバや通信の混雑が起きておらず、ほぼリアルタイムに音声を送信できている場合)。
最大 RT:maxDecodingRate
RT とは、音声認識の処理速度を表す数値で、以下の式により計算されるものです。
「maxDecodingRate」では、この RT の値の最大値を設定することができます。
すなわち、以下の式のように、発話区間ごとに、音声認識処理にかけた時間が、API へ送られた音声の長さに対する「maxDecodingRate」の割合の長さを超えると、その時点でその発話区間の音声認識処理が強制的に中断します。なお、バッチ処理の場合にのみ有効です。
音声認識処理を強制中断させる機能は、その発話区間の全ての音声データを音声認識サーバが受信し終わった後にしか発動しません。
この機能の場合、音声認識処理にかける時間を音声データの長さよりも長くすることも短くすることも可能です。また、音声の長さに対する割合で認識処理時間が制御されるので、発話区間が長いものと短いものが混在するような場合に対しても、バランスの良い制御を行いやすいです。
しかし、あまり小さな値に設定してしまうと、発話区間の途中までしか認識処理がなされずに終わってしまう場合がある点には注意してください。
この機能は、予め録音済みの音声データを用いてバッチ処理を行うようなアプリケーションにおいて、各発話区間の音声認識処理の時間を、音声の長さに対する一定の割合の長さ以内に収めたい場合に活用できます。
目標応答時間:targetResponseTime
音声データの長さに対してプラスで何秒まで音声認識処理にかけて良いかの目標値を定め、その目標値をクリアできるように、音声認識処理中に、処理速度と認識率のバランスを動的に調節する機能です。リアルタイム音声認識の場合にのみ有効です。
まず、以下の式により「暫定 RT」を計算します。
この暫定 RT が、以下の式になるように調節がされます。
「これまでに入力された音声の時間」が1秒に満たない場合や、暫定 RT が1以上になっていない場合、すなわちこれまでにかかった認識処理時間が入力された音声の時間よりも短い場合は、この機能は発動しません。
「maxResponseTime」は、応答時間の上限値を定めて、その値を超えたら強制終了という機能であるため、その発話区間に非常に認識に時間がかかるような音声が含まれている場合(たとえば、大きな雑音が入り込んだ場合など)、その発話区間の認識処理の途中で応答時間の上限値に達してしまい、その発話区間の認識結果が最後まで得られない、ということが起きる場合があります。一方、「targetResponseTime」の場合、応答時間が目標値程度になるように、音声認識処理中に動的な調節を行うため、認識に時間のかかる箇所については早めに切り上げることになっても、目標応答時間までに認識が完了するような箇所はあまり影響を受けずに処理が行われます。
このため、「targetResponseTime」のほうがより汎用的に使いやすいパラメータと言えます。また、同じ音声に対し、「maxResponseTime」と「targetResponseTime」をそれぞれ別々に、同じ値を設定して音声認識を行った場合、「targetResponseTime」を設定したもののほうが、音声全体的に見て認識の精度が良くなりやすいです。
目標 RT :targetDecodingRate
音声データの長さに対して何割の長さまで音声認識処理にかけて良いかの目標値を定め、その目標値をクリアできるように、音声認識処理中に、処理速度と認識率のバランスを動的に調節する機能です。バッチ処理の場合にのみ有効です。
まず、目標応答時間の場合と同様に、「暫定 RT」を以下の式により計算します。
この暫定 RT が、以下の式になるように調節がされます。
「これまでに入力された音声の時間」が1秒に満たない場合や、暫定 RT が1以上になっていない場合、すなわちこれまでにかかった認識処理時間が入力された音声の時間よりも短い場合は、この機能は発動しません。
「maxDecodingRate」は RT の上限値を定めて、その値を超えたら強制終了するという機能であるため、その発話区間に非常に認識に時間がかかるような音声が含まれている場合(たとえば、大きな雑音が入り込んだ場合など)、その発話区間の認識処理の途中で RT が上限値に達してしまって、その発話区間の認識結果が最後まで得られない、ということが起きる場合があります。一方、「targetDecodingRate」の場合、暫定 RT が目標値程度になるように、音声認識処理中に動的な調節を行うため、認識に時間のかかる箇所については時間を短縮するために精度を下げることになっても、目標 RT までに認識が完了するような箇所はあまり影響を受けずに処理が行われます。
このため、「targetDecodingRate」のほうがより汎用的に使いやすいパラメータと言えます。また、同じ音声に対し、「maxDecodingRate」と「targetDecodingRate」をそれぞれ別々に、同じ値を設定して音声認識を行った場合、「targetDecodingRate」を設定したもののほうが、音声全体的に見て認識の精度が良くなりやすいです。
どのようなシーンで利用するか
たとえば、ある音声の認識に、通常は3秒かかるが、2.5秒で処理を終えたとしても、認識結果が大きく変わることはなく、クライアントシステムの挙動に大きな影響は無い、という場合があったとします。この時、冒頭で挙げた案内ロボットの例のように、よりリアルタイムなやりとりを実現したければ、音声認識を2.5秒で終えることが選択肢になり得るでしょう。
このように、より正確な文字起こしをするということは必ずしも重要ではなく、発話の大意が把握できれば良い、それよりも認識結果を早く得てシステムの次のステップに進みたい、というようなシーンにおいて、今回ご紹介したパラメータが活躍します。
また、今回ご紹介したパラメータは、「音声認識に時間がかかり過ぎるような音声が入力された場合に、時間をかけ過ぎずに結果を返却するようにする」という挙動も可能にします。
音声認識に時間がかかってしまうような音声というのは、多くの場合、雑音が多い、認識させたい発話の音量が非常に小さい、音質が悪い、音声認識エンジンの対応していない言語である、など、そもそも精度の良い音声認識を行うことが難しい音声です。したがって、音声認識に長く時間をかけたとしても、あまり良い認識結果が得られないことも多いです。
このような音声に対しては認識に時間をかけ過ぎてもほとんど意味が無いので、パラメータを使って早めに音声認識を諦めることで、システムのレスポンスが悪くなるのを避けることができます。
おまけ:音声認識処理が遅くなる音声の例
音声認識処理が遅くなってしまう音声ってどんな音声? そういう音声に対してパラメータを使うとどうなるの?
という例を最後にご紹介します。
マニュアルのクイックスタートで使用されているサンプル音声(test.wav)の音量を20dB下げたものを用意してみました。「アドバンスト・メディアは、人と機械との自然なコミュニケーションを実現し、豊かな未来を創造していくことを目指します」という発話の音声です。
この音声を、リアルタイム録音のクライアントシステムを模して、ストリーミングで少しずつ API に送って音声認識させます。あまり音量が小さすぎると正しく音声認識処理ができなくなってしまいますが、デフォルトでは、今回はギリギリ音声認識できました。
ここで、「maxResponseTime=10」と設定してみます。10 ミリ秒、すなわち 0.01 秒なので、音声データの長さとほとんど同じ時間しか音声認識処理にかけられない設定です。
この結果は、以下のようになりました。
「アドバンスト・メディアは、人と機械との自然なコミュニケーションを実現し、豊かな未来を創造していく。」
正解の発話と比べると、最後の「ことを目指します」の部分が音声認識処理できなかったことがわかります。
一方、元々のサンプル音声のままで同様に「maxResponseTime=10」と設定して音声認識処理を行った場合は、最後まで音声認識を行うことができました。つまり、音量を小さくした結果、音声認識処理にかかる時間が長くなったわけです。
今回のデータはギリギリ正しく音声認識できる音量でしたが、さらに音量を下げると、デフォルトでも正しく音声認識ができなくなってしまいます。にもかかわらず処理に時間がかかるとなると、時間がもったいないですよね。このような場合に、今回ご紹介したパラメータを利用することで、無駄に時間をかけずに終わらせることができます。
この記事を書いた人
-

茶まみれ
手がふさがっていても意思伝達に使える音声の活用の可能性を考えつつお茶を飲む人。
