LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

音声AIエージェントとは、電話・受付業務で人と話すAIの仕組み

音声AIエージェントとは、音声認識(STT)・大規模言語モデル(LLM)による対話理解・音声合成(TTS)を組み合わせたAIです^*1*3。電話やマイクを通じて、人と自然に話すことを目的としています。電話の一次対応や予約受付、社内FAQへの応答など、これまで有人で対応していた会話業務の一部を担う仕組みです。

電話網から届く音声をCTI(Computer Telephony Integration。電話交換機とコンピューターシステムを連携させる仕組み)で受信し、STTでテキストに変換します^*2*4。変換後のテキストをLLMが解釈し、応答文を生成、TTSで音声化して発話する流れが基本形です^*1。

チャットボットとの違いは、応答をテキストではなく音声で、かつリアルタイムに返す点にあります。人の発話の切れ目や割り込みを検知しながら、途切れのない会話を成立させる処理が求められます^*3。

実装を後押しする技術動向——OpenAI Realtime APIとAzure Voice Live API

音声AIエージェントの実装が現実的になった背景には、STT・LLM・TTSを個別に組み合わせる従来方式に代わる、統合APIの登場があります。OpenAIはRealtime APIを、ユーザーの発話を聞き、推論し、話し、ツールを呼び出す音声エージェントを構築するためのAPIと位置づけています^*1。

接続方式は3種類あります^*1。ブラウザ・モバイル向けのWebRTC、サーバー側の音声パイプラインで使うWebSocket、電話音声エージェント向けのSIPです^*1。SIPとは、IP電話などの呼制御に使う通信規約を指します。この対応により、既存の電話網とAIモデルを直接つなぐ構成が可能になりました。

MicrosoftもVoice Live APIで同様の統合を進めています。音声認識・生成AI・音声合成を単一のインターフェースに統合し、開発者が複数コンポーネントの手動連携を意識しなくてもよい設計です^*3。雑音抑制・エコーキャンセレーション・割り込み検知・発話終端の検知といった会話品質向上機能も備えています^*3。

これらのAPIは、従来エンジニアが個別に設計・調整していたレイテンシ対策や割り込み処理を、プラットフォーム側の機能として提供する方向に進んでいます^*1*3。とはいえAPIを使うだけで完成するわけではなく、電話網との接続、業務ロジックの組み込み、有人エスカレーションの設計は個別に構築する必要があります。

リアルタイム対話を支える4つの技術要素

音声認識(STT)——発話をテキスト化する入力処理

音声認識は、利用者の発話をリアルタイムでテキストに変換する処理です。Azure AI Speechはリアルタイム音声テキスト変換を提供し、仮想エージェントやエージェント支援の用途で継続的に音声を認識できます^*4。Amazon Transcribeもストリーミング文字起こしに対応し、SDK・HTTP/2・WebSocketの3方式で音声を送信できます^*5。

Amazon Transcribeのドキュメントでは、音声チャンクを50〜200ミリ秒の単位に区切ることを推奨しています^*5。これは低レイテンシを実現するためのベストプラクティスとされています^*5。チャンクを細かくし過ぎるとオーバーヘッドが増え、粗くし過ぎると応答が遅れるため、この範囲での調整が実務上のポイントになります。

対話処理(LLM)——意図理解と応答生成の中核

テキスト化された発話をLLMが解釈し、意図を理解したうえで応答文を生成する仕組みです。単純な一問一答ではなく、会話の履歴を保持しながら文脈に応じた応答を返す必要があります。OpenAIのRealtime APIでは、モデルがユーザーへの応答生成に加えてツール呼び出しや会話状態の管理も担います^*1。

音声合成(TTS)——テキストを発話に変換する出力処理

生成した応答文を音声化するのがTTSです。Amazon Pollyは40以上の言語・言語バリアントで100種類超の音声を提供しています^*6。SSML(発声の抑揚や強弱を調整する記述形式)を使うと、強調や間の取り方を細かく調整できます^*6。企業名や製品名の発音を辞書登録できる点も、コールセンター用途では重要です^*6。

電話網・CTI連携——音声を電話システムとやり取りする経路

実際の電話対応に組み込むには、電話網から音声を取り出し、AIエージェントとやり取りする経路が要ります。TwilioのMedia Streamsは、通話の音声データをWebSocket経由でリアルタイムにストリーミングする機能です^*2。双方向ストリームを使うと、会話型AIモデルと発信者の間で双方向会話を確立できます^*2。OpenAIのRealtime APIもSIP接続を直接サポートしており、電話音声エージェント向けの経路として位置づけられています^*1。

応答遅延と割り込み対応——自然な対話に欠かせないレイテンシ設計

音声AIエージェントが不自然に感じられる主な原因は、応答の遅れと割り込みへの対応不足です。人と人の会話では、相手の発話中に相づちを打ったり、途中で話を差し込んだりすることが日常的に起こります。この動きに追随できないと、機械的な印象を与えてしまいます。

Azure Voice Live APIは、4つの会話品質向上機能を備えています^*3。雑音抑制・エコーキャンセレーション・割り込み検知・発話終端の高度な検知です^*3。割り込み検知は会話中の中断を正確に認識する機能で、発話終端の検知は自然な間を早期に会話終了と誤判定しないための仕組みです^*3。

これらの機能が重要になる理由は、従来方式の課題と関わります。音声認識・対話処理・音声合成を個別に組み合わせる従来方式では、コンポーネント間の連携が複雑になりやすいためです^*3。その複雑さは、エンジニアリングの負荷だけでなく、利用者が感じる遅延の増加にもつながりやすいとされています^*3。Voice Live APIのような統合基盤を使うか、個々のコンポーネントを自前で最適化するかは、実装コストとの兼ね合いで判断する事項です。

レイテンシ対策の実務では、音声チャンクのサイズ調整も欠かせません。Amazon Transcribeの推奨どおり、チャンクを50〜200ミリ秒に保つことが基本です^*5。さらにLLMの応答生成とTTSの発話開始を並行処理するなど、複数コンポーネントを横断した調整が必要になります。

一次対応・予約受付・FAQ対応——想定される活用シーンとログ・エスカレーション設計

音声AIエージェントの活用シーンとして想定されるのが、電話の一次対応・予約受付・社内外のFAQ対応です。Azure AI Speechのコールセンター向け機能では、仮想エージェントという活用例が挙げられています^*4。電話を経由したカスタマー対応の音声ボットや、音声対応チャットボットがその例です^*4。

すべての問い合わせを完全に自動化できるわけではありません。複雑な相談や感情的な対応が必要な場面では、有人オペレーターへの引き継ぎ、いわゆるエスカレーションの設計が欠かせません^*4。エージェント支援(Agent-assist)の形で、リアルタイムの会話を分析し、人の担当者へ次のアクションを提案する使い方も選択肢の一つです^*4。

ログ設計も運用上の重要な論点です。Azure AI Speechと連携するAzure Language(自然言語処理サービス)を使うと、会話ログの分析が可能です^*4。会話の要約、個人情報の抽出・マスキング、発話ごとの感情分析などに対応しています^*4。通話内容を後から分析・改善につなげるには、発話ログと判定結果を構造化して保存する設計があらかじめ必要です。

。想定シーンに応じて、どこまで自動応答に任せ、どこから有人対応へ切り替えるかの線引きは、業務内容ごとに検討する必要があります。

内製と外注の分かれ目——実装体制の工数で判断する

音声AIエージェントの実装では、音声認識・対話処理・音声合成・電話網連携という複数領域の知識が同時に求められます。この作業を内製で担う場合、STTやTTSのAPI連携、LLMのプロンプト設計、SIPやCTIの知識を一人でカバーするのは容易ではありません。レイテンシ調整のノウハウも欠かせない要素です。これらすべてを備えたエンジニアは多くありません。

失敗した場合の影響も見過ごせません。応答が遅れたり割り込みに対応できなかったりすると、電話をかけた利用者が対応を待たずに切ってしまう可能性があります^*3。電話は他のチャネルと比べて代替手段への切り替えが速く、一次対応の品質がそのまま顧客体験に直結する点は意識しておくべきです。

専門パートナーに委託する場合と内製で構築する場合の違いを整理すると、次のようになります。

実装範囲が広い依頼ほど、委託先の選定が重要になります。音声認識の精度検証から対話フローの設計、電話網との接続、エスカレーション後の運用設計までを一括して依頼できるかどうかを確認することが実務的な判断材料です。内製では既存の情報システム部門が通常業務と並行して対応することになり、検証に割ける時間が限られる場合があります。

。対象とする業務範囲や電話網の構成によって必要な工数は変わるため、現状のシステム構成を確認したうえで内製・外注の切り分けを検討することが望ましいでしょう。

まとめ：音声AIエージェント実装で押さえる3つの判断軸

本稿では音声AIエージェントの仕組みと実装の要点を、公式情報をもとに整理しました。要点は3つに集約できます。第一に、音声AIエージェントは音声認識・LLM・音声合成・電話網連携という4つの技術要素を統合して成立します^*1*3。第二に、自然な対話には割り込み対応や発話終端の検知といったレイテンシ設計が欠かせず、統合APIの活用でその一部を軽減できます^*3。第三に、内製・外注の判断は対象業務の範囲とエスカレーション設計まで含めた実装体制の工数で決まります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：OpenAI「Realtime API」（OpenAI Platform Docs）（https://platform.openai.com/docs/guides/realtime）
2. *2　出典：Twilio「Media Streams」（Twilio Docs）（https://www.twilio.com/docs/voice/media-streams）
3. *3　出典：Microsoft「Voice Live API Overview」（Microsoft Learn、Azure AI Foundry）（https://learn.microsoft.com/en-us/azure/ai-services/speech-service/voice-live）
4. *4　出典：Microsoft「Foundry Tools for Call Center Overview」（Microsoft Learn、Azure AI Foundry）（https://learn.microsoft.com/en-us/azure/ai-services/speech-service/call-center-overview）
5. *5　出典：AWS「Transcribing streaming audio」（Amazon Transcribe Developer Guide）（https://docs.aws.amazon.com/transcribe/latest/dg/streaming.html）
6. *6　出典：AWS「Amazon Polly」（AWSプロダクトページ）（https://aws.amazon.com/polly/）

Tweet