AIテレアポの留守番電話判定｜人・録音・判定不明で対応を分ける

AIテレアポで電話がつながっても、その相手が人とは限りません。留守番電話の案内に向かって商品説明を続けていたり、会社名を丁寧に名乗った受付担当者を録音と間違えて切ってしまったりすれば、会話を始める前に機会を失います。

導入時に決めたいのは、人・留守番電話・判定不明のそれぞれで、何を話し、どう通話を終えるかです。今回は新製品の速報ではなく、発信業務の設計を解説します。技術的な説明はTwilioの公式資料を参照し、業務の分岐や検証手順はIvyLeapの提案として整理しています。

留守番電話判定「AMD」で分かること

AMDはAnswering Machine Detectionの略で、電話を受けた相手が人か機械かを推定する機能です。Twilioの公式資料では、発話と無音の長さなどを使って判定し、人・機械・FAX・判定不明などの結果を返すと説明されています。判定は常に正しいわけではなく、短い留守番電話の案内を人の声と見なす場合もあります。Twilio：Answering Machine Detection

また、「人が出た」という推定は、目的の担当者が出たことや、用件を話してよいことの確認ではありません。受付担当者につながった場合も、別の方が電話に出た場合もあり得ます。

したがって、AMDの後には通常の挨拶と用件の確認が必要です。判定結果だけを根拠に、説明を聞く意思や商談の成立まで記録しないようにします。

最初に、留守番電話へ伝言を残すかを決める

留守番電話に切り替わったときの方針は、会話用の台本とは別に用意します。

• 伝言を残さない業務：留守番電話と判定したら、決めた終了処理へ進む。
• 伝言を残す業務：録音開始に対応できる構成を確認し、承認済みの短い伝言を一度だけ再生する。
• 相手が分からない場合：通常の営業説明や伝言を始めず、事前に決めた確認・保留の処理へ進む。

Twilioには、機械を検出した段階で結果を返す設定と、留守番電話の挨拶の終了を検出する設定があります。機械だと分かった時点と、伝言を録音できるタイミングは同じとは限りません。Twilio：検出の設定

たとえば「名乗り、連絡の目的、折り返し先」を残す方針なら、その短い文が冒頭から録音され、最後まで再生されるかを試します。顧客ごとの契約内容など、誰が聞くか分からない録音に入れたくない情報は、伝言の台本から外します。

判定を待つ間の沈黙と、途中の切り替えを設計する

TwilioのCalls APIでは、判定完了を待ってから通話処理を進める方式と、通話を進めながら裏側で判定する方式を選べます。後者でも判定が不要になるわけではありません。Twilio：非同期AMD

企業側では、待ち時間の短さだけでなく、相手に何が聞こえるかを確認してください。

判定を待つ構成では、電話に出た人が無音のまま取り残されないかを試します。先に挨拶を始める構成では、後から留守番電話と判定された際に、挨拶を止めて伝言へ切り替えるのか、終了するのかを決めます。二つの音声を重ねたり、同じ名乗りを何度も再生したりしないことも確認対象です。

「判定を早める設定にする」だけで解決しようとせず、発信先で実際に聞こえる音声を、開始から終了まで確かめることが大切です。

「判定不明」を留守番電話に置き換えない

判定不明は、不在が確認できたという意味ではありません。情報が足りないまま処理が終わった可能性があります。

IvyLeapの設計案では、判定不明を独立した状態として保存します。人の応答が確認できるなら通常の会話に進み、確認できなければ長い説明を始めず、その業務で決めた終了や担当者確認へ進めます。

法人の代表番号では、部署を選ぶ自動音声案内につながる場面も検証します。「自動音声らしいから伝言を流す」という分岐にすると、録音機能のない案内へ話し続ける構成になりかねません。番号入力による接続に対応するかどうかは、留守番電話対応とは別に確認してください。

再発信についても、判定不明になったら直ちに何度でもかけ直すルールにはしません。対応済みの記録や連絡不要の申し出を確認し、その業務で許可された回数・間隔・時間帯の範囲で判断する設計にします。

日本語の実際の挨拶で試す

TwilioのFAQは、一部の端末だけに合わせた調整を避け、回線や端末、挨拶の異なる条件で試すことを勧めています。また、人を機械と見なす誤り、その逆、挨拶終了の誤検出を区別しています。Twilio：AMDのFAQと検証方法

日本語で法人へ発信する予定なら、自社の検証用番号と協力者を使い、少なくとも次の場面を用意します。以下は検証ケースの例であり、実際の顧客への試験発信を勧めるものではありません。

1. 「はい」と短く答える人：切断せず、自然に挨拶へ進めるか。
2. 会社名・部署名・氏名を続けて名乗る人：途中で録音扱いにしないか。
3. 短い案内の留守番電話：人との会話を始めてしまわないか。
4. 長い案内や途中に無音を含む留守番電話：伝言の冒頭が欠けないか。
5. 応答後しばらく無音になる電話：不在と断定せず、決めた処理で終われるか。
6. 部署選択の自動音声：伝言を流し続けず、対象外の接続として扱えるか。

一つの設定を直したら、改善した場面だけでなく、以前うまく動いた場面も試します。留守番電話を見分けやすくした結果、人の長い名乗りまで切っていないかを見るためです。

開発側へ渡す記録は「判定」と「実際」を分ける

修正を依頼する際は、検証番号の種別、実際に人か留守番電話か、システムの判定、最初の音声が聞こえた時点、最終的な処理を並べて残します。伝言を残す構成なら、録音された冒頭と末尾も確認します。

たとえば「法人の長い名乗り／実際は人／機械と判定／挨拶前に終了」という記録なら、営業台本ではなく判定と切り替え処理を調べる必要があると伝わります。全体の成功率だけでは、この違いを見落とします。

AIテレアポの設計は、営業説明が流暢であることに加え、会話を始めてよい相手へ適切につなぐところから考えましょう。全体像はAIテレアポの基礎、導入のご相談はIvyLeapのAIコール導入支援をご覧ください。

参考資料は2026年10月9日に確認しました。AMDの利用可否や設定項目は利用する電話基盤によって異なります。本記事は特定の判定精度や導入効果を保証するものではありません。