皆さんこんにちは！
私はAmiVoice API のSREを担当しているエンジニアです。

AmiVoice API の特長のひとつに、「発話区間のみ課金」があります。これはAPIに実際に送信した音声のうち、発話区間と判定された部分にしか費用がかからないということです。費用を抑える点ではよいのですが、どれくらいの費用がかかるのかは用途や実装によってかなり変わってしまうため、費用の見積もりが難しいという課題があるように感じていました。理想的にはアプリケーションやサービス毎に実際の運用データを使って算出するのが良いのですが、データがないというケースも多いと思います。

そこで今回は、事前の見積もりや設計の参考としていただくため、AmiVoice API の実運用データを使って、「発話区間割合」の分布と、そのおおよその目安を調べてみました。

発話区間については以下の記事を参考にして下さい。
発話区間検出ってなんぞや？！

発話区間割合とは

本記事では、次の指標を「発話区間割合」と呼びます。

今回は、2025 年 12 月のデータを対象に、AmiVoice API の利用量が多い 8k エンジン、16k エンジンそれぞれについて、利用上位 200 ユーザーを集計対象としました。

8kエンジンと16kエンジンについて

分析結果を見る前に、8k エンジンと 16k エンジンの違いを簡単に整理します。

AmiVoice API では、音声のサンプリングレートなどに応じてエンジンを選択します。

• 8k エンジン：主に電話音声のような狭帯域音声で利用されます。コールセンターなどの用途で使われることが多いエンジンです。
• 16k エンジン：広帯域音声で利用される標準エンジンです。会議音声、マイク入力、対面会話、工場での音声入力など、コールセンター以外の様々なシーンで利用されます。

両者は使われる場面が異なるため、発話区間割合にも違いが現れると考えられます。そのため、8k と 16k を分けて傾向を見ていきます。

調査1：発話区間割合の分布

まずは全体の傾向を見るために、利用者ごとの平均発話区間割合を集計し、その分布を確認しました。

8kエンジン

16kエンジン

8k エンジンは特徴的で発話区間割合が 50% 前後に集中しているのに対し、16k エンジンでは広く分布していることが分かります。

8kエンジンが使われるコールセンターでの主な音声認識の利用用途はオペレータとカスタマーの会話のテキスト化です。AmiVoice APIでは精度を高めるために、オペレーターとカスタマーの音声を混ぜてひとつのセッションとして送るのではなく、話者ごとに別セッションとして送ることを推奨しています。そのため、一方が話している間、もう一方のチャネルは無音になりやすく、結果として発話区間割合が 50% 前後に寄りやすいのだと考えられます。

また、8k エンジンのチャートで発話区間割合が 80% を超えるケースもわずかにありますが、これはボイスボットなどで発話だけを送信しているケースかもしれません。

16k エンジンのチャートでは、発話区間割合が 10〜50% と低いユーザーもいる一方で、70〜90% 付近に多くのユーザーが分布していることが分かります。発話区間割合が低いのは、送信音声に発話区間があまり含まれていないことを示しており、録音の開始と停止を細かく制御せず、長めに録音した音声を送信しているケースが含まれている可能性があります。

16k エンジンについてはさらに詳しく調べます。

調査2: 16kエンジンについての詳細分析

16k エンジンにおいては発話区間割合の分布が広いことがわかりました。そこで、ユーザーごとにセッションごとの発話区間割合の分布を確認したところ、主なパターンが 2 つあることがわかりました。

パターンA

一番多く見られる分布は以下のような形です。以下はあるユーザーの例です。縦軸は前のセクションとは異なりセッション数になっています。

発話区間割合が 97% を超えるセッションが非常に多く見られます。また、発話区間割合が高いほどセッション数が増えていく傾向があります。

このような分布は、録音データをそのまま送っているというより、クライアント側である程度の区間切り出しや無音除去が行われているケースに近いと考えられます。例えば、スマートフォンアプリなどで、発話ボタンを押している間だけ録音する仕様です。一見すると、このような実装では発話区間割合は 95% 以上になりそうにも思えますが、実際の統計を見ると、発話区間割合が低いセッションも一定数含まれます。そのため、ユーザー全体で見ると 85〜90% 程度に収まるケースが多く、見積もりでもこの程度を目安に置くのが現実的だと考えられます。

パターンB

もうひとつ見られたのが、パターンAのようなはっきりした偏りがない分布です。以下は、あるユーザーの例です。

このユーザーでは発話区間割合が高いほどセッション数が増える傾向はありますが、90% 以上のセッションはパターン A より少なくなります。特に、97% 付近に強く集中しておらず、発話区間割合が低い音声もそれなりに含まれている点が、パターン A との違いです。

このタイプの分布は平均も様々でした。これは録音した音声を比較的そのまま送信しているケースに近いのではないかと考えられます。例えば、会議室の据え置きマイクで常時録音した音声を処理する場合などです。こういったケースでは、会話内容や録音環境、アプリケーションの使い方によって大きく変わります。そのため、調査1で見たユーザーごとの発話区間割合の分布をもとに、70% 前後を目安にするのが妥当のように思われます。

まとめ

「音声認識の課金対象になる時間はどのくらい？」という疑問にお答えするため、AmiVoice APIの運用データから発話区間の分布を調査しました。サービスの種類によってこの割合は大きく変動します。今回の調査結果を元にした以下の目安をぜひ参考にしてみてください。

利用形態	発話区間割合の目安	補足
コールセンターの会話をオペレーターとカスタマーに分けて送信する場合	55% 前後	8k エンジンで多い利用形態
クライアント側で区間切り出しや無音除去を行い、発話中心の音声を送信する場合	85〜90%	想像より 95% 以上にはなりにくい
それ以外の一般的なアプリケーション	70% 前後	用途や実装によるばらつきが大きい。 特にクライアント側で音声の有無に関わらず常に音声データを送信し続けている場合などは大きく見積もりとは異なる可能性があります。

また、AmiVoice API ではサーバー側で発話区間を自動検出し、発話区間にのみ費用がかかるため、費用を下げることだけを目的にクライアント側で VAD を実装する必要はありません。一方で、使い勝手の向上や通信量の削減といった目的では有効です。目的に応じて、クライアント側での VAD の利用をご検討ください。

今後も、AmiVoice API の運用を通じて見えてきた傾向や知見を、導入や設計の判断に役立つ形で紹介していければと思います。