電話対応の自動化は、番号で案内先を選ぶIVRから、音声を認識するシナリオ型ボイスボット、LLMを使った音声応答へと広がってきました。従来の仕組みでは、利用者が考えている途中で応答を始めたり、言い直しを正しく反映できなかったりします。GPT-Live-1 APIを使えば、こうした発話にも対応しやすい音声AIを電話業務へ組み込めます。ただし、無人運用には、業務処理、権限管理、障害対応まで含めた設計が必要です。

【関連記事】なぜAIそのものへの反発が大きいのか？「アンチAI」が生まれる構造

ボイスボットがどう変わるのか

IVRやシナリオ型ボイスボットは、GPT-Live-1以前から定型的な問い合わせを自動化してきました。従来の製品にも、案内中の発話で再生を止めたり、利用者の回答を待ったりする機能があります。GPT-Live-1で変わるのは機能の有無ではなく、割り込みや言い直しがあっても会話を続けやすくなる点です。

IVRとシナリオ型ボイスボット

IVRは、利用者が電話機の番号を押し、案内先や手続きを選ぶ仕組みです。「契約内容の確認は1」「故障の問い合わせは2」のように選択肢を示し、入力に応じて担当部署へ転送したり、自動処理を実行したりします。あらかじめ用意した選択肢によって利用者の用件を分類できるため、問い合わせ先の振り分けや情報照会に適しています。

シナリオ型ボイスボットは、利用者の発話を音声認識で文字に変換し、あらかじめ決めた手順に沿って質問を進めます。予約受付であれば、希望日、時間、人数、氏名を順番に確認し、必要な項目がそろった段階で予約システムへ登録します。注文状況の確認や担当部署への振り分けなど、必要な情報と完了条件を明確に定められる業務で利用されてきました。

LLMを組み込むと、言い回しが違っても利用者の用件を読み取り、適切な処理へ進みやすくなります。「来週の金曜に空いている時間を知りたい」と「金曜日に予約できる時間はありますか」のような表現を、別々の分岐として登録する必要も減らせます。ただし、登録内容や処理手順は業務システム側で管理しなければなりません。

割り込みとバージイン

割り込みへの対応は、GPT-Live-1で初めて実現した機能ではありません。利用者がボイスボットの案内中に話し始めた際、再生を止めて発話を受け付ける機能をバージインと呼びます。Amazon Lex V2にも、案内中の発話で再生を止めるバージインや、利用者が予約番号などを確認するまで待つ機能があります。音声とDTMF入力の併用や、待ち時間の設定にも対応しています。

従来のバージインは、利用者の発話を検知すると案内を止めます。このため、「はい」「ええ」といった相づちまで割り込みと判断し、会話が途切れる場合があります。GPT-Live-1では、相づちなのか依頼内容の変更なのかを、会話の流れから判断しやすくなりました。

従来のボイスボットは、利用者が話し終えるたびに内容を確定し、次の処理を始めます。このため、「木曜日でお願いします。やはり金曜日に変更してください」と続けて話した場合、訂正前の木曜日で検索や登録が始まることがあります。金曜日への訂正を反映するには、木曜日の処理を取り消さなければなりません。

音声応答で生じる待ち時間

従来のボイスボットは、音声認識で発話を文字にし、LLMで回答を作り、音声合成で読み上げます。利用者が話し終えたと判断するまで待つため、応答までに間が空きます。判断を早めすぎると、利用者が話し終える前に応答を始めてしまいます。

利用者が言葉を探している沈黙と、発話を終えた後の沈黙を区別できなければ、会話の間を適切に取れません。「予約日は、ええと、木曜日……ではなく金曜日です」のような発話では、途中の間を発話終了と判断し、「木曜日」を処理へ渡すおそれがあります。後から訂正を認識しても、先に始めた検索や登録を止める仕組みがなければ、木曜日を条件にした処理が進んでしまいます。

自然な電話応対には、回答文の品質だけでなく、応答を始めるタイミング、相づちの扱い、言い直しの反映方法まで設計しなければなりません。個々の機能だけでなく、会話全体の流れを検証しましょう。

音声の自然さと対応品質は別に評価する

応答が自然でも、誤った窓口へ案内したり、取得済みの情報を何度も尋ねたりすれば、電話対応としては失敗です。予約の変更を依頼されたのに新しい予約を追加した場合や、注文状況を尋ねられたのに注文を取り消した場合も、会話の印象にかかわらず業務上の問題になります。

Google Cloudは、誤転送、初回解決率、平均対応時間、顧客満足度、やり取りの回数、途中離脱を評価指標に挙げています。聞き取れなかった場合は、不足した情報だけを短く尋ね直します。No-MatchまたはNo-Inputが3回続いたら、同じ質問を繰り返さず、担当者へ引き継ぐ設計が推奨されています。

従来のボイスボットでも、予約受付や注文状況の照会は自動化できます。しかし、沈黙や相づちを発話の終了と誤認したり、訂正前の内容で処理を始めたりする問題が残っていました。音声の聞き取りやすさだけでなく、必要な情報を取得し、依頼どおりに処理できたかまで評価しましょう。

GPT-Live-1のAPIで何ができるのか

OpenAIは2026年9月10日、GPT-Live-1のAPI提供を開始しました。GPT-Live-1は入力音声と出力音声を一つのモデルで扱い、AIが話している間も利用者の音声を処理するフルデュプレックスに対応します。APIを利用すると、ブラウザで会話を試すだけでなく、電話回線や業務システムへ接続し、必要な情報を正しく聞き取って受付を完了できるかを検証できます。

連続した音声の中で割り込みや訂正を扱う

GPT-Live-1は、AIが話している間も利用者の音声を受け付けます。利用者が考えている間は応答を待ち、相づちや割り込み、言い直しにも対応しながら会話を続けやすくなりました。相づちを依頼内容の変更と誤認しないか、言い直した内容を正しく反映できるかは、実際の通話で確かめましょう。

入力音声と出力音声を一つのモデルで扱うため、音声認識、回答生成、音声合成の間で処理を受け渡す際の遅延や、会話の文脈が失われる問題を抑えられます。OpenAIは、割り込みや相づちへの応答、背景音や沈黙の処理、長時間の会話をGPT-Live-1の特徴として挙げています。ただし、認識結果は電話回線の品質や利用者の話し方によって変わるため、実際の利用条件で検証しなければなりません。

Speakの初期評価では、従来のターン制システムと比べて、学習者が考えている途中でAIが割り込む回数が約80％減りました。ただし、Speakが特定の用途と条件で得た結果であり、ほかの用途でも同じ改善率が得られるとは限りません。導入先の利用者との会話で、応答のタイミングや割り込みへの対応を測りましょう。

会話とバックエンドを分ける

GPT-Live-1は利用者との会話を担当し、検索、予約、登録はバックエンドへ依頼します。バックエンドにはOpenAIのResponsesモデルを使うほか、自社のモデル、AIエージェント、業務サービスを接続できます。会話を続けながら、バックエンドで情報を検索したり、業務システムを操作したりする構成です。

GPT-Live-1には、話す速さ、質問の順序、確認方法など、会話の進め方を指示できます。バックエンドでは、予約の検索条件、変更できる範囲、承認手順を管理します。例えば、GPT-Live-1が予約変更の依頼を聞き取り、バックエンドが対象の予約を検索して変更できるかを確認します。処理結果が返った後、GPT-Live-1が利用者へ結果を伝えます。

本人確認、操作権限、入力値の検証、処理前の最終確認、二重登録の防止は、アプリケーション側で必ず実行します。会話が自然でも、予約の受付や変更が正しく完了したとは限りません。

ブラウザから電話回線へ接続する

GPT-Live-1には、ブラウザからWebRTCで接続する方法、サーバーからWebSocketで接続する方法、電話回線からSIPで接続する方法があります。電話基盤や連携サービスを選ぶ際は、音声形式、DTMF、転送、同時接続数への対応を確認しましょう。

まずブラウザで、質問の順序、待ち時間、割り込み後の応答、言い直しの反映を確認しましょう。その後、電話回線へ接続し、遅延や雑音があっても質問と回答が滞りなく続くかを検証します。問題が起きたときは、会話設計に原因があるのか、電話回線に原因があるのかを切り分けます。

電話回線へ接続したら、会社名、氏名、数字を正しく認識できるかを確認します。業務システムへ聞き取った情報を渡し、処理結果を利用者へ正確に案内できるかも検証します。APIと接続方法が用意されていても、使用中の電話基盤や業務システムに合わせた実装と試験が必要です。

PoCは用途を絞る

最初のPoCは、担当者不在時の用件確認から始めましょう。会社名、氏名、折り返し先、用件を聞き取り、聞き取れなかった項目だけを尋ね直します。最後に内容を復唱し、利用者の確認を得てから担当者へ通知します。予約や契約を確定する処理を伴わないため、誤処理の影響を抑えながら、聞き取り、復唱、訂正、通知までの流れを検証できます。

最初のPoCでは、回答内容が多岐にわたるFAQ対応や、契約条件の判断が必要な手続きは対象外とします。割り込み、言い直し、取得済み情報の保持、復唱、終話を一つずつ確認しましょう。「090……すみません、080です」と言い直した場合に、訂正後の番号だけを担当者へ通知できれば成功です。

GPT-Live-1の音声セッションは、1分当たり0.05ドルで、秒単位で課金されます。これとは別に、バックエンドモデルとツールの利用料が発生します。PoCの費用は、電話回線、バックエンドのモデル、業務システムとの接続、通話ログの保存まで含めて見積もりましょう。

APIを使えば、GPT-Live-1を電話回線や業務システムへ接続し、実際の電話業務に近い条件で試せます。PoCでは、必要な情報を正しく聞き取れるか、言い直しを反映できるか、登録や通知まで完了できるかを確認しましょう。本番化を判断するときは、会話の自然さだけでなく、処理結果の正確さや障害から復旧できるかも確かめます。

実運用で必要なるるもの

無人運用には、音声認識だけでなく、訂正前の処理を取り消す仕組み、本人確認と権限管理、二重処理の防止、障害時の結果確認、有人対応への切り替えまで用意しなければなりません。

電話回線では認識精度が変わる

電話回線を通すと、音声形式、雑音、音量、話す速さ、固有名詞の発音によって認識精度が変わります。会社名、氏名、電話番号、日時を誤認識したまま処理すれば、誤った連絡先へ通知したり、予約日時を間違えて登録したりするおそれがあります。

電話番号や日時などの重要な情報は復唱し、利用者の確認を得てから確定します。訂正された場合は、その項目だけを聞き直しましょう。決めた回数だけ聞き直しても認識できない場合や、本人確認に失敗した場合は、担当者へ切り替えます。担当者が不在なら、折り返しに必要な情報を保存して連絡予定を案内します。

利用者から有人対応を求められた場合も、自動応答を続けず、担当者へ切り替えます。

割り込みとバックエンド処理の取り消し

利用者がAIの案内中に話し始めると、音声の再生は止まっても、バックエンドで始まった検索や登録は止まらない場合があります。「木曜日ではなく金曜日」と訂正されたときは、案内を止めるだけでなく、木曜日を条件にした処理も取り消さなければなりません。

依頼ごとに識別番号と更新番号を付け、返ってきた結果が最新の依頼に対するものかを確認します。古い依頼の結果は、案内や登録に使いません。通信が切れた場合は、まず業務システムへ結果を照会し、処理されていないと確認できた場合だけ再実行します。同じ識別番号の処理を重複して実行しない仕組みも必要です。予約登録の応答を受け取る前に接続が切れても、結果を照会せずに再実行してはいけません。

プロンプトとアプリケーションの役割を分ける

GPT-Live-1には、話す速さ、一度に尋ねる項目数、沈黙したときの待ち方、バックエンドへ処理を渡す条件を指示できます。担当者不在時の受付なら、最初に不在を伝え、会社名、氏名、折り返し先、用件を聞き取るように設定しましょう。

本人確認、操作権限、入力値の検証、処理前の最終確認は、アプリケーション側で必ず実行します。利用者が確認を省くよう求めても、確認が終わるまでは予約を変更しない設計にしましょう。電話番号や予約番号も、桁数や形式を確認してから業務システムへ渡します。

法令や契約で文言が決まっている案内は、モデルに自由生成させず、固定音声を使う方法もあります。通話内容、バックエンドへ送った依頼、業務システムの処理結果、利用者への案内を記録しておけば、どの段階で誤りが生じたのかを確認できます。

PoCと本番運用で評価する項目を分ける

PoCでは、会話の聞き取りやすさ、発話速度、応答のタイミング、割り込みへの対応を確かめましょう。担当者不在時の用件確認を対象にするなら、必須項目の取得率、固有名詞や数字の誤認識率、訂正の反映率、受付完了率で評価します。

バックエンドと連携する場合は、訂正後の内容がバックエンドへ渡ったか、業務システムが一度だけ処理したか、処理の成功を確認してから利用者へ結果を案内したかを順に確かめましょう。例えば、「8月7日、すみません、8月6日」と言い直した場合、登録される予約は8月6日の1件だけでなければなりません。AIが「8月6日で予約しました」と答えても、業務システムに8月7日の予約が残っていれば失敗です。

本番稼働後は、二重処理の件数、有人転送率、途中離脱率、平均対応時間を継続して測りましょう。依頼どおりに処理しても結果を誤って案内すれば、電話対応は完了していません。反対に、案内が自然でも異なる処理を実行すれば、業務上の事故になります。

完了条件を定めやすい業務から導入する

無人化する業務は、必要な情報と完了条件を明確に定められるものに絞りましょう。担当者不在時の用件確認なら、必須項目を聞き取り、利用者の確認を得て、担当者へ通知できれば完了です。注文状況の照会なら、本人確認を終え、該当する注文の状況を正しく案内できれば完了とします。

例外の多い相談、契約上の判断が必要な問い合わせ、苦情や強い不満を伴う問い合わせは、担当者へ引き継ぎましょう。すぐに転送できない場合は、受付内容を保存し、折り返す担当者と予定時刻を案内できるようにします。

本番へ進む前に、状態管理、権限管理、二重処理の防止、障害対応、監視、担当者への切り替えまで確認しましょう。対応範囲を広げるときも、業務ごとに完了条件と例外を定め、通話内容と処理結果が一致しているかを確認します。

まとめ

GPT-Live-1の用途は、コールセンターの無人化に限りません。会話中の相づちや言い直しにも対応しやすいため、来客受付や施設案内にも使えます。

顧客向けの問い合わせ窓口を全面的に自動化するのは簡単ではありません。本人確認、契約内容の判断、業務システムの操作、苦情への対応など、人の判断が必要な場面が多く、対象を広げるほど開発費と運用負担が増えるためです。

これに対し、来客受付や施設案内はAIの役割を絞れます。例えば、来訪者の氏名と訪問先を確認して担当者へ連絡したり、用件に応じて窓口と行き方を案内したりする使い方です。難しい問い合わせだけを人へ引き継げば、専任者を常駐させる必要はありません。

小規模な受付や案内では、専任者の配置も従来型ボイスボットの導入も費用に見合わない場合があります。しかし、案内板や番号入力だけでは、用件に応じた案内ができません。大規模な問い合わせ窓口の完全無人化を目指す前に、これまで専任者もボイスボットも置けなかった受付や案内から試してみましょう。定型的な案内をGPT-Live-1に任せ、判断が必要な場合だけ人へつなげば、音声AIを導入できる場所は大きく広がります。

参考文献

Build more natural voice experiences with GPT-Live-1 in the API

GPT-Live evaluation guide

Voice agent design best practices

Pricing