電話の問い合わせ窓口は、人手不足や人件費の高騰、応対品質のばらつきといった課題を長く抱えてきました。これまでの解決策は、プッシュ信号で操作するIVR（自動音声応答）でしたが、固定的なメニューを辿る手間が顧客体験を損ないがちでした。ここへ来て、大規模言語モデルと音声処理を組み合わせた「対話型の音声AIエージェント」が急速に広がっています。
顧客の自然な話しかけをその場で理解し、文脈に沿って柔軟に応じる仕組みへと、電話対応は大きく姿を変えつつあります。
カスケード型から「音声をそのまま扱う」構成へ
音声AIの作り方は、大きく二つに分かれます。ひとつは、音声認識（STT）、言語モデル（LLM）、音声合成（TTS）を直列につなぐ従来型のカスケード構成です。各工程で最適な専門プロバイダーを選べる自由度がある一方、APIをまたぐたびに遅延が積み上がり、合計の応答時間が1秒を超えることも珍しくありません。人同士の自然な会話の目安とされる500ミリ秒を超えると、顧客は「機械と話している」という違和感を覚えはじめます。
これに対して主流になりつつあるのが、音声認識と合成をモデル内部に統合し、音声を直接入力して直接音声を返すS2S（Speech-to-Speech）構成です。テキストへの変換という重い工程を挟まないため遅延が大きく縮み、声のトーンや抑揚といった、文字では抜け落ちてしまう情報までモデルが解釈して応答に反映できます。この方式の登場によって、これまで常態化していた「500ミリ秒の壁」を破ることが現実になりました。
頭脳を担う最新モデル
この領域を牽引しているのが、OpenAIとGoogleです。OpenAIのRealtime APIは2025年8月に正式提供が始まり、音声を直接扱うモデルとともに、WebSocketでの双方向ストリーミングを前提に設計されています。
AIの人物像や音声区間の検出方法を指定しながら、ツール呼び出しを交えた複雑な処理をこなしつつ、低い遅延で音声を返し続けられる点が強みです。
一方、GoogleのGemini Multimodal Live APIは、音声に加えてテキストや画像・動画の入力にも対応します。ユーザーの表現に合わせて応答のトーンを動的に変える機能や、70以上の言語をまたいだリアルタイム翻訳を備えており、グローバル展開を見据えた設計で力を発揮します。
商用利用では、通常のAPIキーではなく一時的なトークンを用いるなど、セキュリティ面の配慮も欠かせません。
電話網とAIをつなぐTwilio
インターネット上のAIと電話網をつなぐ役割は、Twilioが事実上の標準を担っています。作り方は主に二通りです。
ひとつはMedia Streamsを使い、通話音声を生のデータとして双方向にやり取りする低レベルな方式で、中継サーバーを自前で組むことで細部まで制御できます。着信の対応だけでなく、こちらから架電するアウトバウンドの発信まで、同じ基盤で構築できます。
もうひとつは、音声認識から言語モデル連携、音声合成までをTwilio側でまとめて束ねるConversationRelayです。開発者は音声データの細かな処理から解放され、構造化されたテキストのやり取りだけで対話を組めます。認識する言語を固定したり、返答テキストの言語を自動で判定して発話させたりと、日本語や多言語への対応もしやすく、ビジネスロジックの設計に集中できます。
日本語ならではの「自然な会話」を設計する
技術がどれだけ進んでも、電話で自然な会話が成り立たなければ、顧客は途中で離れ、有人対応への転送が増えてしまいます。とりわけ日本語では、言語や文化に根ざした対話の作法をAIに組み込むことが欠かせません。
まず大切なのが相槌です。人は相手の話を黙って聞き続けることはなく、「はい」「なるほど」といった短い言葉で理解や関心を示しながら、会話のリズムを作ります。AIが長い説明を無言で聞いていると、顧客は「固まったのではないか」「ちゃんと聞き取れているのか」と不安になります。話の区切りで適切に肯定的な相槌を打つよう指示しておくことで、「きちんと聞いてもらえている」という安心感が生まれます。
次に、遅延を感じさせない工夫です。後述するデータベース検索などが走ると、どうしても処理の待ち時間が生じます。この間を気まずい沈黙にしないために、「少々お待ちください」「ただいま確認しますね」といった繋ぎ言葉を差し込み、体感的な遅れを和らげます。あわせて、音声合成そのものを速くする選択肢もあります。
CartesiaのSonicは、独自のState Space Modelによって90ミリ秒台という低遅延で音声を生成し、40以上の言語に対応します。
そして、割り込みへの対応です。人の会話では、相手が話している途中で質問を挟むことがよくあります。AIが話している最中に顧客が話しはじめたら、すぐに発話を止めて聞き取りに切り替える「バージイン」は、自分の出力音声と顧客の声を分離するエコーキャンセルや、人の声だけを素早く捉える音声区間検出（VAD）があって初めて成り立ちます。国内でも、こうした割り込み対応を備えた音声AIが登場しはじめています。
なお、音声向けのプロンプト設計は、テキストチャットとは勘どころが異なります。耳で一度聞いて分かる、簡潔で自然な話し言葉が求められます。日本語では、固有名詞や専門語の読み間違いを防ぐために、プロンプトのなかで読みをカタカナで添えるといった地道な調整が今も有効です。
業務を動かすRAGと関数呼び出し
流暢に話せるだけでは、現場の用件は片づきません。「残高を教えてほしい」「予約を変更したい」といった要望に応えるには、社内の知識や動的なデータへアクセスする仕組みが要ります。
社内のFAQやマニュアルを検索し、回答に反映させるのがRAG（検索拡張生成）です。ただ、音声でそのまま使うと検索と生成の処理が積み重なり、応答が遅れがちになります。
そこで、過去の似た質問と回答をためておき、近い問い合わせには検索や再生成を省いて即座に返すキャッシュの活用や、顧客が話し終える前に区切りを捉えて裏で検索を先回りさせる工夫によって、遅延を抑えます。
一方、予約やアカウント操作のように「動かす」処理を担うのが関数呼び出し（Function Calling）です。AIは会話の途中で外部APIを呼ぶ必要を自ら判断し、必要な情報を渡して処理を実行させ、その結果を受けて会話を続けます。
この裏側の動きを繋ぎ言葉で覆い隠すことで、顧客は複雑な操作を意識せずにサービスを受けられます。
国内コールセンターでの導入成果
こうした技術は、すでに国内で成果を上げはじめています。住友生命保険は、あるサポートセンターで入電の約1割をボイスボットで完結させ、オペレーターの負担を軽くしています。
ビックカメラは、メール振り分けの自動化に加え、通話後の記録業務にかかる時間を半分ほどに短縮しました。
小林製薬は、通話内容をその場でテキスト化してFAQやマニュアルを検索できる仕組みを取り入れ、応対時間を約半分に減らすとともに、後処理の時間も大きく削っています。
三井住友トラストTAソリューションは、応対内容の要約やオペレーター支援によって年間およそ9,200時間の業務を削減し、蓄積した応対記録を活用して新人研修の日数も一人あたり3営業日短縮しました。
狙いは人件費の削減にとどまらず、あふれ呼の抑制や24時間対応、通話データからの顧客理解へと広がっています。
録音データと個人情報の扱い
顧客の発話をテキスト化し、保存して要約や学習に使う以上、データ管理の体制づくりは避けて通れません。通話から得られる音声やテキストには、氏名や連絡先をはじめ機微な情報が含まれることが多く、その取り扱いは個人情報保護法の規律を受けます。
保管方法と暗号化、不要になったデータの確実な破棄、顧客からの開示や利用停止の請求への対応など、運用ルールを社内で明確に定め、必要に応じて利用目的を示すことが求められます。海外の主要なセキュリティ基準に準拠したプラットフォームを選ぶことは、こうしたリスクを土台から抑えるうえで有効です。
導入を成功させる二つの軸
電話の自動化は、入力待ちのIVRから、言語モデルとリアルタイム通信を束ねた自律的な音声AIへと進みました。要になるのは、Twilioのような堅牢な通信基盤の上にS2S型のモデルを組み合わせ、「500ミリ秒の壁」を越えることです。
そのうえで日本語圏では、相槌や割り込みへの対応、繋ぎ言葉といったきめ細かなUXの作り込みが欠かせません。開発を加速したいなら、専用プラットフォームの選定も鍵になります。
開発者向けに柔軟な組み合わせを重視するならVapi、ノーコードで素早く本番品質へ届けたいならRetell AIといった選択肢があります。適切な技術選定と、日本市場の対話文化への理解を両立できたとき、音声AIは単なるコスト削減の道具を超えて、次のカスタマーサポートを担う基盤になっていきます。
