音声エージェントとは?STT・LLM・TTS・VAD の役割を分かりやすく解説!
この記事はこんな方に向けた内容です。
・音声エージェントの仕組みを基礎から理解したい方
・VAD・STT・LLM・TTSの関係を整理したい方
・音声AIやAI電話、会話型サービスの開発を検討している方
・音声エージェントの応答が遅い原因を突き止めたい方
・Aivis Cloud APIを音声エージェントへ組み込みたい方
⚠️ 本記事の内容は、2026年8月時点の情報です。各サービスやAPIの仕様は更新される可能性があるため、実装時は利用するサービスの最新ドキュメントもあわせてご確認ください。
皆さんこんにちは。
感情豊かな音声合成技術を誰もがかんたんに活用できる未来を目指す、Aivis Projectです✨
人が話しかけると、内容を理解して音声で返事をする。
AI電話、音声アシスタント、AIキャラクター、カスタマーサポートなどで使われているこの仕組みを、音声エージェント(Voice Agent)と呼びます。
一見すると、ひとつのAIが声を聞いて返事をしているように見えます。
しかし、一般的な音声エージェントの内部では、複数の技術が連携しています。
中心になるのが、次の4つです。
・VAD:人が話している音声区間を検出する
・STT:音声を文字へ変換する
・LLM:返答内容を考える
・TTS:返答テキストを音声へ変換する
ただし、実際の会話システムは、この4つを順番に置くだけでは完成しません。
マイク入力の前処理、発話の終了判定、通信、ツール呼び出し、音声の再生、ユーザーによる割り込みまで含めて設計する必要があります。
この記事では、基本となる4つの技術と、それらを自然な会話体験へつなげる実装上のポイントを詳しく解説します📚
【全体像】音声エージェントを構成する処理
代表的な音声エージェントは、次のような流れで動きます。
マイク入力
↓
音声前処理
エコーキャンセル・ノイズ抑制・音量調整
↓
VAD・ターン判定
人が話しているか、発話が終わったかを判断
↓
STT
音声をテキストへ変換
↓
LLM・外部ツール
返答を生成し、必要なら検索や予約処理を実行
↓
TTS
返答テキストを音声へ変換
↓
ストリーミング再生
↓
ユーザーが話し始めたら割り込み処理この図では縦に並べていますが、すべての処理が完全な直列で動くとは限りません。
例えば、STTは音声を受信しながら途中結果を返せます。
LLMが最初の文を生成した段階でTTSを開始すれば、返答全文の完成を待つ必要もありません。
音声エージェントを高速化するときは、各処理を単純に速くするだけでなく、処理をどこまで並行して進められるかが重要になります。
【音声前処理】VADの前にも処理がある
マイクから取得した音声を、そのままVADやSTTへ送ればよいとは限りません。
実際には、次のような音声前処理が使われます。
・AEC(Acoustic Echo Cancellation):スピーカーから再生したAIの声が、マイクへ回り込むのを抑える
・Noise Suppression:空調音や環境音などのノイズを抑える
・AGC(Automatic Gain Control):話者との距離による音量差を調整する
・リサンプリング:STTが受け付けるサンプリングレートへ変換する
・チャンネル変換:ステレオ音声をモノラルへ変換する
特に重要なのがAECです。
AIの音声をスピーカーから再生しながらマイクを動かすと、再生中の音声をユーザーの発話として検出してしまうことがあります。
これを適切に抑えないと、AIが自分の声を聞き取り、自分の発言へさらに返答する状態になりかねません。
⚠️ 音声エージェントの誤作動がVADやSTTの問題に見えても、実際にはマイク入力やエコー処理が原因ということがあります。
後段のAIだけでなく、最初に入力される音声も確認してください。
【VAD】音声が存在する区間を検出する
VADは、Voice Activity Detectionの略です。
日本語では「音声区間検出」と呼ばれます。
マイクから届く音声を解析し、主に次の状態を判定します。
・音声が始まった
・音声が続いている
・無音または非音声になった
VADが見ているのは、基本的には人の声らしい音が存在するかどうかです。
ここで注意したいのは、VADだけで「ユーザーが言いたいことをすべて話し終えた」と理解できるとは限らない点です。
VADとターン判定は同じではない
例えば、ユーザーが次のように話したとします。
明日の予約を……午後3時に変更してください。
「予約を」のあとに少し長い間があります。
無音だけで終了を判定すると、AIは「明日の予約を」の時点で発話が終わったと誤認する可能性があります。
そのため、実際の音声エージェントでは、VADに加えてエンドポイント検出やターン判定を組み合わせます。
・一定時間の無音を待つ
・STTの句読点や確定結果を見る
・文法的に発話が完結しているか確認する
・意味的にユーザーの意図が完了したか判断する
無音時間を中心に判定する方式に加えて、発話内容から終了を推定するセマンティックなターン判定も使われています。
VADで調整する主な項目
VADやターン判定では、次のような値を調整します。
・しきい値:どの程度の音量・確率から音声と判断するか
・先頭パディング:音声検出より少し前のデータを残す長さ
・終了無音時間:何ミリ秒の無音で発話終了と判断するか
・最小発話時間:短い物音を発話として扱わないための長さ
・最大発話時間:ユーザーが話し続けた場合に区切る上限
終了無音時間を短くすると返答は速くなりますが、ユーザーの発話途中で割り込みやすくなります。
長くすると話し終わりを待てる一方で、返答開始が遅くなります。
速さと割り込みにくさはトレードオフです。すべての利用者に共通する正解はありません。
【STT】音声をテキストへ変換する
STTは、Speech-to-Textの略です。音声認識とも呼ばれます。
STTは、入力された音声から次のような情報を生成します。
・認識されたテキスト
・途中結果と確定結果
・単語ごとの時刻情報
・認識結果の信頼度
・話者の識別情報
利用できる情報はSTTサービスによって異なります。
ストリーミングSTTの途中結果と確定結果
リアルタイム音声エージェントでは、音声を最後まで録音してから送信するのではなく、マイク音声を小さな単位で継続的に送ります。
STT側も、処理中の結果を順次返します。
途中結果:来週の
途中結果:来週の火曜日に
途中結果:来週の火曜日に予約を
確定結果:来週の火曜日に予約を変更してください途中結果を画面へ表示すれば、ユーザーは認識状況を確認できます。
一方で、途中結果は後から書き換わる可能性があります。
LLMへ早く渡しすぎると、誤った内容で返答生成や外部処理を始めてしまう場合があります。
予約変更、送金、購入などの重要な操作では、STTの確定結果を待つか、ユーザーへ確認を返す設計が必要です。
STTで確認したい指標
STTでは、単に「認識できたか」だけでなく、次の項目を計測します。
・認識精度:単語や文字がどの程度正しく認識されたか
・確定までの時間:発話終了から最終結果が返るまでの時間
・固有名詞の精度:社名・商品名・人名・地名を正しく認識できるか
・数字の精度:日時・金額・電話番号を正しく扱えるか
・雑音環境での精度:実際の利用場所でも認識できるか
日本語では、分かち書きを前提とした単語誤り率だけでなく、文字単位の誤り率が使われることもあります。
テスト時は一般的な文章だけでなく、実際のサービスで頻出する固有名詞や数字を含む発話を用意してください。
【LLM】返答内容と次の行動を決める
STTで得たテキストを受け取り、返答を生成するのがLLMです。
ただし、実用的な音声エージェントでは、LLMは文章を作るだけではありません。
・社内ナレッジを検索する
・顧客情報を取得する
・予約状況を確認する
・注文内容を登録する
・人間の担当者へ転送する
・回答できない内容を判定する
こうした外部処理は、ツール呼び出しやAPI連携によって実行します。
LLMの遅延は生成時間だけではない
LLMで確認したい主な時間は次のとおりです。
・リクエスト送信から最初のトークンが届くまで
・最初の発話可能な文が完成するまで
・返答全文が完成するまで
・外部ツールの実行が完了するまで
音声エージェントでは、返答全文の完成時間より、最初に読み上げられる短い文が完成するまでの時間が重要です。
例えば、検索に時間がかかる場合は、無言で待たせるのではなく、次のような短い返答を先に生成できます。
ただいま確認しています。少々お待ちください。
ただし、すべての返答で埋め合わせ音声を入れると会話が冗長になります。一定時間以上かかる処理にだけ使うなど、条件を決めておくのがおすすめです。
音声向けの返答は短くする
画面上の文章は読み飛ばせますが、音声は、途中の音声を聞き飛ばしにくいメディアです。
LLMには、次のような出力ルールを与えます。
・結論から話す
・一度に伝える情報を絞る
・長い箇条書きを避ける
・URLや記号をそのまま出力しない
・確認が必要な数字は復唱する
・一文を長くしすぎない
⚠️ TTSの話速を上げても、内容そのものが長ければ聞きやすくはなりません。音声エージェントでは、LLMの文章設計も音声品質の一部です。
【TTS】返答テキストを音声へ変換する
TTSは、Text-to-Speechの略です。日本語では音声合成と呼ばれます。
Aivis Cloud APIが担当するのは、このTTSの部分です。
音声エージェントのTTSでは、主に次の項目が重要になります。
・最初の音声データが届くまでの時間
・ストリーミング再生に対応しているか
・日本語の読みとアクセントが正確か
・長時間聞いても疲れにくい声か
・感情や話速を用途に合わせて調整できるか
・途中で再生を停止できるか
音声全体の完成を待たずに再生する
Aivis Cloud APIは、ストリーミング音声合成に対応しています。
音声全体の生成を待つのではなく、生成できた音声データから順次受信し、再生を始められます。
Aivis Cloud APIでは、実測上最速0.3秒でストリーミング再生を開始できます。
これは「音声全体が0.3秒で完成する」という意味ではありません。
APIへテキストを送信してから、最初の音声が再生可能になるまでの時間です。
実際の再生開始時間は、使用するモデル、入力テキスト、ネットワーク、音声形式、クライアント側のデコードやバッファリングによって変わります。
LLMの出力をどの単位でTTSへ送るか
LLMから届いた1文字や1トークンごとにTTSへ送るのは適切ではありません。
文章の意味や読み方を安定させるには、ある程度まとまったテキストが必要です。
一般的には、次のような単位で区切ります。
・句点まで完成した一文
・短い意味のまとまり
・一定文字数を超えた自然な区切り
・ユーザーへ先に伝える必要がある短い応答
短く区切りすぎると、文脈や感情表現が分断されます。長く待ちすぎると、再生開始が遅くなります。
一文単位を基本に、意味のまとまりと待ち時間のバランスを取るのが扱いやすい設計です。
日本語では読みの安定性が重要
音声エージェントでは、毎回同じ社名や商品名を読み上げることがあります。
Aivis Cloud APIでは、ユーザー辞書を使って次の情報を指定できます。
・表記
・読み方
・アクセント型
・品詞
・優先度
顧客名、商品名、地名、業界用語などは、本番運用前に辞書へ登録しておくと安心です。
また、LLMからTTSへ渡す前に、Markdown記号、URL、不要な箇条書き記号などを整理すると、読み上げの不自然さを減らせます✨
【割り込み】ユーザーがAIの発話中に話し始めたら
自然な会話では、AIの返答が終わるまでユーザーが必ず待つとは限りません。
ユーザーがAIの発話中に話し始めることを、バージイン(Barge-in)と呼びます。
バージインを検出したら、一般的には次の処理を行います。
1.ユーザーの発話開始を検出する
2.再生中の音声を停止する
3.残っている音声データを破棄する
4.進行中のTTSやLLM処理をキャンセルする
5.ユーザーが実際に聞いた範囲だけを会話履歴へ反映する
6.新しい発話のSTTを開始する
停止できないままAIが話し続けると、ユーザーは会話を主導できません。
一方で、相づちや咳、周囲の声に反応して毎回停止すると、会話が頻繁に途切れます。
VADだけで即時停止するのではなく、最小発話時間、認識結果、音響的な特徴などを組み合わせて、本当の割り込みかどうかを判断する設計も重要です。
【遅延計測】「何となく遅い」では改善できない
音声エージェントの遅延は、単純にVAD・STT・LLM・TTSの処理時間を足したものとは限りません。
各処理を並行できる場合は、一部の時間が重なります。反対に、ネットワークや音声再生バッファなど、4要素以外の待ち時間も発生します。
まず、次の時刻を記録してください。
T0 ユーザーが話し終えた時刻
T1 発話終了を確定した時刻
T2 STTの確定テキストを受信した時刻
T3 LLMの最初のトークンを受信した時刻
T4 TTSへ送れる最初の文が完成した時刻
T5 TTSの最初の音声データを受信した時刻
T6 実際に音声再生を開始した時刻これにより、次の時間を分けて確認できます。
・ターン判定時間:T1−T0
・STT確定時間:T2−T1
・LLM初回応答時間:T3−T2
・最初の文章生成時間:T4−T3
・TTS初回音声到着時間:T5−T4
・クライアント再生準備時間:T6−T5
・体感応答時間:T6−T0
⚠️ サーバー側で最初の音声を高速に生成できても、クライアントが大量のデータをためてから再生していれば、ユーザーには遅く感じられます。
APIだけでなく、実際の再生開始まで測ってください。
【高速化】効果が出やすい改善策
1.STTをストリーミング化する
ユーザーの発話終了後に音声全体を送るのではなく、話している間から音声を送信します。
2.ターン判定を用途に合わせる
無音時間を短くするだけでなく、発話内容や利用者の話し方に合わせて調整します。
3.LLMの返答を短くする
生成トークン数を減らすだけでなく、TTSへ早く渡せる短い一文を先頭に出します。
4.外部ツールを必要なときだけ呼ぶ
毎回すべての検索やデータ取得を行うと遅延が増えます。質問に必要な処理だけを選びます。
5.LLMとTTSをパイプライン化する
LLMの全文完成を待たず、最初の一文が完成した段階でTTSへ送ります。
6.TTSをストリーミング再生する
最初の音声チャンクが届いた段階で、デコードと再生を開始します。
7.先頭の無音を見直す
Aivis Cloud APIでは、必要に応じてleading_silence_secondsを0.0に設定することで、生成音声の先頭に付く無音を削減できます。
8.接続と再生バッファを見直す
通信接続の再利用や、クライアント側のバッファサイズを調整します。バッファが小さすぎると音が途切れ、大きすぎると再生開始が遅れます。
【本番設計】精度と速度以外に確認すること
音声エージェントを本番運用する場合は、次の項目も必要です。
・ユーザーが無言だった場合のタイムアウト
・STTで認識できなかった場合の聞き返し
・LLMや外部APIが失敗した場合の案内
・TTS生成中に通信が切れた場合の処理
・ユーザーによるキャンセルや割り込み
・会話ログや音声データの保存範囲
・個人情報を含む発話のマスキング
・人間の担当者へ切り替える条件
・同時接続数とレート制限
・工程別の遅延・エラー率の監視
特に、音声、文字起こし、LLMへの入力、生成された返答、音声合成用テキストが、それぞれどのサービスへ送信され、どこへ保存されるのかを整理してください。
複数のサービスを組み合わせる場合、データの取り扱い条件もサービスごとに確認する必要があります。
【補足】音声から音声へ直接変換する方式もある
ここまで解説したのは、VAD・STT・LLM・TTSを組み合わせるカスケード型の音声エージェントです。
現在は、音声を直接入力し、音声で返答するSpeech-to-Speech型のモデルもあります。
Speech-to-Speech型には、声色や話すテンポなど、文字へ変換すると失われやすい情報を扱いやすい利点があります。
一方、カスケード型には次の利点があります。
・STT、LLM、TTSを個別に選べる
・認識されたテキストを確認できる
・工程ごとの原因を調査しやすい
・ユーザー辞書や読み方を細かく管理できる
・既存のチャットボットや業務APIへ組み込みやすい
日本語の読みを細かく管理したい場合や、既存システムと連携する場合は、カスケード型が扱いやすいケースも多くあります。
Aivis Cloud APIは、こうした構成のTTS部分を担当する音声合成APIです。
よくある質問(FAQ)
Q.VADと発話終了判定は同じものですか?
厳密には同じではありません。
VADは音声が存在する区間を検出します。
ユーザーが発言を終えたかどうかは、無音時間、STT結果、文の意味などを組み合わせたターン判定で決めます。
Q.プッシュトゥトークならVADは不要ですか?
ボタンを押している間だけ録音する場合、発話区間を決める目的のVADは省略できます。
ただし、無音除去や割り込み検出などにVADを利用する構成もあります。
Q.LLMの出力は、届いた文字からすぐTTSへ送るべきですか?
1文字や1トークン単位ではなく、一文または短い意味のまとまりが完成してから送るのがおすすめです。
短く分けすぎると、読みや感情表現が不自然になることがあります。
Q.STTとTTSは同じサービスで揃える必要がありますか?
必須ではありません。
STT、LLM、TTSは個別に選べます。
日本語の読みや声の表現を重視して、TTSだけAivis Cloud APIを利用する構成も可能です。
Q.AIが自分の声に反応してしまいます。
スピーカーから再生した音声をマイクが拾っている可能性があります。
AECの設定、マイクとスピーカーの配置、イヤホンの利用、再生中の入力制御を確認してください。
Q.AIが話の途中で頻繁に止まります。
環境音や相づちを割り込みとして誤検出している可能性があります。
VADのしきい値、最小発話時間、エコーキャンセル、割り込み判定を見直してください。
Q.Aivis Cloud APIだけで音声エージェント全体を作れますか?
Aivis Cloud APIが提供するのは、現時点ではTTSのみです。
マイク入力、VAD、STT、LLM、外部ツール、音声再生などは、用途に合わせて他社のサービスを組み合わせる必要があります。
まとめ
この記事のまとめ
・音声エージェントの中心はVAD・STT・LLM・TTSの4要素
・VADは音声区間を検出し、発話終了は別のターン判定も組み合わせる
・STTは途中結果と確定結果を使い分け、固有名詞や数字も検証する
・LLMは返答内容だけでなく、検索・予約などの外部処理も制御する
・TTSは最初の音声が届く速さ、読みの正確さ、ストリーミング再生が重要
・応答時間は工程別に計測し、実際の再生開始まで確認する
・自然な会話にはAEC、バージイン、失敗時の処理も欠かせない
・Aivis Cloud APIは、カスケード型音声エージェントのTTS部分として利用できる
音声エージェントは、ひとつのAIだけで完成するものではありません。
入力音声の品質、発話終了の判断、音声認識、返答生成、読み上げ、割り込み処理がうまく連携して、初めて自然な会話になります。
まずは各工程の時間と精度を分けて測り、最も体験を損ねている部分から改善してください。
TTS部分では、Aivis Cloud APIのリアルタイム音声合成デモを使って、実際の文章がどのくらいの速さで再生されるかをご確認いただけます✨
以上で、この記事はおしまいです。
Aivis ProjectやAivis Cloud APIに関してご不明点や導入のご相談がある場合には、お問い合わせフォームよりお気軽にご連絡ください。
🔗 関連リンク
・Aivis Cloud API:https://aivis-project.com/cloud-api/
・Aivis Cloud APIドキュメント:https://api.aivis-project.com/v1/docs
・リアルタイム音声合成デモ:https://api.aivis-project.com/v1/demo/realtime-streaming
・AivisHub:https://hub.aivis-project.com
