AIコールのプッシュ入力｜音声と番号入力を切り替える設計
AIコールで話す代わりに電話のボタンを押せるようにするには、何を決める必要があるでしょうか。DTMFの受信設定、音声との優先順、入力途中の切り替え、無入力時の分岐を企業担当者向けに整理します。
AIコールで「受付番号を教えてください」と案内しても、利用者が番号を話しにくい場面があります。周囲が騒がしい、数字を続けて読み上げにくい、声に出す代わりに電話のボタンを押したい、といった場合です。
音声とプッシュ入力を選べるようにするには、「ボタンでも入力できます」という案内だけでは足りません。どの段階で入力方法を変えられ、切り替える前の内容をどう扱うかまで、受付の流れとして決めます。
本記事はTwilioの公式資料を2026年11月2日に確認した基礎解説です。新機能の提供開始やIvyLeapの導入実績を紹介するものではありません。以下の業務例と切り替え手順は、当社が提案する設計例です。
ボタンを押す操作を、AIまで届ける経路を確認する
電話のプッシュ信号はDTMFと呼ばれます。利用者が押した数字を、電話基盤や業務アプリケーションが入力として受け取れる構成か、最初に確認します。音声会話ができることから、プッシュ入力も利用できるとは推定しません。
例えばTwilioのConversationRelayには、DTMFイベントをアプリケーションへ送る設定があります。公式資料では初期値は無効とされ、AIが話している間に利用者の入力をアプリへ報告する設定も別に説明されています。Twilio公式資料：ConversationRelay
そのため、開発・運用担当者には次の三点を確認します。
- 利用者の電話からプッシュ信号を受け取れるか。
- 受け取った数字を、業務の入力欄へ渡す処理があるか。
- AIの案内中と、案内が終わった後のどちらで受け付けるか。
「数字のイベントが届いた」ことと、「受付番号として保存できた」ことは別です。電話基盤から受付処理まで、実際に使う接続経路で確かめます。
同時に待つ場合は、どちらの入力が優先されるか
音声とボタンの両方を受け付ける設定でも、二つの結果を自由に合わせられるとは限りません。TwilioのGatherは、両方を受け付ける場合、最初に検出した入力を優先します。音声を先に検出した場合は、ボタンによる入力終了の指定を無視すると説明しています。Twilio公式資料：Gather
この仕様を使う画面や電話フローでは、「途中まで話した後、続きだけを押す」といった操作が期待どおりになるか確認が必要です。受付側で音声の候補とプッシュの数字を無条件につなぐと、利用者が意図しない内容になる場合があります。
自社の運用では、次のどちらを採るかを明確にします。
- 最初から両方を待つ：先に受け付けた方式と、後から来た入力の扱いを決める。
- 入力方法を選んでから待つ：音声用・プッシュ用の受付を分け、切り替え時に現在の入力を整理する。
どちらが適するかは、用件と利用者の操作で判断します。「両方対応」とだけ説明せず、途中から変更する場合の動きまで試して選びます。
入力方法を変えるときは、途中の候補を持ち越さない
例えば、利用者が受付番号を話している途中で、プッシュ入力に変えたいと希望する仮想例を考えます。ここでは、番号は一つの方式で最初から受け直す設計にします。
AIは「番号入力に切り替えます。受付番号の最初から入力してください」と案内し、音声で得た未確定の候補を、その入力項目の採用値から外します。すでに確認済みの用件や折り返し希望まで消す必要はありません。どの項目を受け直しているかを限定します。
システム側では、切り替え前の音声結果が遅れて届いても、現在の入力へ上書きしないようにします。開発担当者には、通話中の質問を区別し、終了した質問への遅い応答を採用しない仕組みを確認します。これはIvyLeapの設計提案であり、特定製品が自動で提供する機能の説明ではありません。
プッシュ入力が終わった後も、必要な確認を経てから保存します。聞き取った値を確定する手順は、氏名・日付・番号の確認設計で扱っています。本記事では、その前にある入力方法の選択と切り替えに焦点を当てます。
入力完了の合図と、待つ時間を案内に合わせる
利用者には、必要な桁数、最後に押すキーがあるか、やり直す方法を案内します。システムが待っている条件と、電話で説明している条件をそろえます。
Twilio Studioの入力ウィジェットには、桁数に達したら入力を終える設定と、指定キーで終える設定があります。終了用のキー自体は、入力した数字として送られないと説明されています。Twilio公式資料：入力ウィジェット
例えば「最後にシャープを押してください」と案内する場合は、そのキーが送信の合図なのか、番号の一部なのかを混同しないようにします。案内が終わる前に押した数字、キーを探している間の無操作、入力途中で間が空いた場合も確認対象です。
待ち時間は、全業務に同じ短い値を当てはめず、端末の操作と利用者の反応を見て決めます。短くして通話を早く終えることだけを優先せず、利用者が入力を完了できたかを確かめます。
無入力と、入力内容の不一致を別に扱う
何も入力を受け取れなかった状態と、入力された値が受付条件に合わない状態では、次の案内が異なります。
Twilio Studioでは、キー入力・音声入力・無入力を別の分岐として扱います。また、キー入力の分岐が接続されていなければDTMFを待ち受けないと説明しています。案内文に選択肢を足すだけでは、処理の接続まで完成しません。Twilio公式資料：入力後の分岐
無入力なら、利用者がキーを探しているのか、接続経路で入力を受け取れないのか、操作方法が分からないのかを、記録と試験で切り分けます。入力された番号が該当しない場合は、所定の確認方法へ進めます。無入力を「いいえ」や特定の選択肢として扱わないことが大切です。
何度も同じ案内へ戻すのではなく、受け直す回数と、人へ渡す条件を決めます。引き継ぎでは、入力方法、確認済みの項目、未完了の項目を伝え、担当者が続きを受けられるようにします。人への引き継ぎ設計も参考になります。
導入前に試したい六つの場面
提供元と合意した検証用の電話経路と架空のデータを使い、次の操作を確かめます。
- 案内が終わる前にキーを押す。 数字を受け付ける開始時点と、利用者への説明が合うか。
- 話しながらキーも押す。 どちらを採用したか分かり、二つの結果を無断で混ぜないか。
- 途中から入力方法を変える。 古い未確定の候補や、遅れて届く音声結果が現在の入力へ戻らないか。
- 入力の途中で間が空く。 完了と時間切れを区別し、未完の値を確定扱いしないか。
- 入力を受け取れない経路を使う。 同じ案内を繰り返さず、利用できる別の受付へ渡せるか。
- 終了キーを押す、または所定の桁数へ達する。 案内どおりの時点で終了し、保存先へ意図した値が届くか。
結果は、入力方法、受け付けた値、終了理由、次の分岐、実際の保存結果を並べて記録します。切り替えられた回数だけで評価せず、誤った入力を確定しなかったか、最後まで進めなかった人を担当者へ渡せたかも確認します。
プッシュ入力を使っても、数字が記録に残らないとは限りません。通話録音や操作ログの保存範囲は、採用する構成で確認します。また、入力ができたことだけで、個別情報を開示する権限が確認できた扱いにはしません。
IvyLeapのAIコール導入支援では、電話業務に合わせた設計をご相談いただけます。音声で受けたい用件と、プッシュ入力を用意したい項目を整理して、お問い合わせください。
※公式資料は2026年11月2日に確認。対応する接続経路・入力方法・初期設定はサービスごとに異なります。資料の確認日を機能の新規提供日とは扱っていません。