留守番電話検出（AMD：Answering Machine Detection）は、アウトバウンド通話に応答したのが人間か、留守番電話の応答メッセージか、自動音声メニューかを判定するステップです。音声AIの導入では、それぞれの結果を、定義されたアクション、ログ記録、リトライルールを持つ独立した通話状態として扱うべきです。
アウトバウンド通話の多くは、人間ではなく留守番電話の応答メッセージや電話メニューで終わります。検出機能がエージェントの前段に後付けされた別のダイヤラーにあると、こうした通話はキャンペーン終了後に誰かが仕分ける「残りもの」になってしまいます。本ガイドではこれらを最初から設計に組み込み、ビルダーが何を設定すべきか、運用リーダーがCRMに何が記録されるかを把握できるようにします。
留守番電話検出は実際に何を判定するのか？
誰が、あるいは何が応答したのかを、エージェントが同じ通話の中で行動を変えられるほど早い段階で判定します。Retell では、この判定は2つの独立した検出機能によって行われます。
- 留守番電話検出は留守番電話の応答メッセージを認識し、通話を切るかメッセージを残します。
- IVR検出は自動音声メニューを認識し、IVR Hangupが有効な場合は通話を終了します。
どちらもアウトバウンドの電話通話（およびテストに使用するWeb通話）で動作します。インバウンド通話では相手から電話をかけてくるため、効果はありません。検出は通話接続後の最初の3分間のみ実行され、この時間枠は変更できません。電話メニュー内で過ごした時間や人と話した時間もこの3分に含まれます。
AMDの隣には、さらに2つの結果があります。知らない番号からの着信をスクリーニングする電話では、相手が応答するかどうかを決める前に、エージェントに名前と用件を尋ねることがあります。また、そもそも接続されない通話（応答なし、話し中、拒否、ブロック）もあり、その場合は検出は実行されません。完全な設計では、これらすべてをカバーします。
なぜ留守番電話とIVRを後処理ではなく通話状態として扱うのか？
適切なアクションは通話中に実行する必要があり、その結果が次の発信を左右するからです。エージェントが機械につながったことを通話終了後に初めて知る場合、次の3つの問題が起こります。
- エージェントが応答メッセージに向かって冒頭のトークを最後まで話したり、メッセージにかぶせて話したりする。
- 誰にもつながっていないのに、CRMに「完了」した通話として記録される。
- リトライのロジックが「1時間前にメッセージを残した」と「一度もつながっていない」を区別できず、同じ人に何度もかけすぎるか、つながるはずの相手をあきらめてしまう。
通話状態とは、1つの検出シグナルに、1つのアクションと1つの処理結果（ディスポジション）を組み合わせたものです。
アウトバウンド音声エージェントにはどのような通話状態が必要か？
最低でも次の8つです。検出とログの列は、ドキュメント化されたRetell の動作を示しています。リトライの列は、チームが自社のダイヤラーやバックエンドで設定するルールです。
| 通話状態 | 検出方法 | エージェントの動作 | ログに記録される内容 | リトライルール（自社で設定） |
|---|
| 人間が応答 | 時間枠内に留守番電話検出もIVR検出も発動しない | 会話を進める：質問への回答、予約、転送、または終了 | call_status: ended、user_hangup、agent_hangup、call_transferなどの理由、in_voicemail: false | なし（成功基準を満たさず、フローでフォローアップが必要な場合を除く） |
| 留守番電話（メッセージを残す） | 留守番電話検出 | 話す順番を待ってから、固定またはプロンプトで生成したメッセージを伝える | voicemail_reached、in_voicemail: true | 次の発信は間隔を空ける（相手はすでにメッセージを受け取っているため） |
| 留守番電話（通話を切る） | 留守番電話検出 | 応答メッセージの途中でも即座に切断する | voicemail_reached、in_voicemail: true | 発信上限の範囲内で、別の時間帯にリトライする |
| IVR（通話終了） | IVR Hangupを有効にしたIVR検出 | 通話を切る | ivr_reached | やみくもにリトライしない。番号を確認するか、メニューを操作できるエージェントに回す |
| IVR（メニュー操作） | Press DigitツールまたはPress Digitノード | キーパッドの数字を押すか音声で応答して目的の相手にたどり着く。別の会社だった場合は通話を終了する | ivr_outcomeやivr_pathなど、独自の抽出フィールド | 結果による：折り返しの予定を入れるか、ブロックされた経路を人による確認に回す |
| 通話スクリーニング | 電話のアシスタントが発信者と用件を尋ねる | 設定した名乗りと用件を伝える | 文字起こし、およびその後に続く状態の記録 | 通話が最終的に終わった状態に従う |
| 応答なし・話し中・拒否 | 通話が接続されない | 何もしない（エージェントは一切話さない） | call_status: not_connectedと、dial_no_answer、dial_busy、user_declinedのいずれか | 発信上限の範囲内で、後でリトライする |
| ブロックまたは失敗 | 通話が接続されない | 何もしない | marked_as_spam、network_blocked、dial_failed、invalid_destinationのいずれか | 停止する。まず番号の評判（レピュテーション）または連絡先データを修正する |
エージェントはどのような場合に、通話を切らずに留守番電話にメッセージを残すべきか？
折り返しがなくてもメッセージ自体が役に立つ場合はメッセージを残し、後で再度かけたほうが効果的な場合は通話を切ります。リマインダー、折り返しの依頼、期限の案内はメッセージに適しています。営業の冒頭トークや、家族や同僚にスピーカーで聞かれたくない内容は、通常は適していません。
Retell では2種類のメッセージを利用できます。
- 静的な文（Static sentence）：動的変数を含む固定テキスト。例：
Hi {{first_name}}, this is the clinic confirming your appointment. Please call us back. - プロンプト（Prompt）：エージェントがメッセージを生成するための指示。例：電話をかけた理由を要約し、折り返しを依頼する。
いずれの場合も、エージェントは話す順番を待つため、応答メッセージの途中でメッセージが始まることはありません。デフォルト設定には注意が必要です。ダッシュボードで新規作成した空のエージェントは、留守番電話検出が有効で「通話を切る」に設定された状態で始まりますが、既存のエージェント、インポートした設定、転送用エージェントは元の設定を維持します。また、APIで作成したエージェントではvoicemail_optionを明示的に設定する必要があります。APIでは、何を留守番電話とみなすかを記述する任意のdetection_promptも指定できます。
メッセージの文言については、AI音声エージェントを使う際の留守番電話のベストプラクティス5選をご覧ください。
電話メニューにつながったとき、エージェントはどうすべきか？
まず、そのメニューが行き止まりなのか、目的の相手への経路なのかを判断します。消費者向けリマインダーキャンペーンで企業の代表番号につながった場合、番号が間違っている可能性が高いため、IVR Hangupを有効にしてivr_reachedを記録します。保険会社、取引先、請求窓口など、話したい相手がメニューの先にいる場合は、IVR Hangupを無効にしたままメニューを操作します。IVR Hangupが有効だと、検出時点で通話が終了してしまうためです。
メニュー操作には、シングルプロンプトおよびマルチプロンプトのエージェントではPress Digitツールを、カンバセーションフローのエージェントではPress Digitノードを使用します。ドキュメント化されている重要な設定は次のとおりです。
- Pause Detection Delayは、メニューの音声が途切れてからエージェントがボタンを押すまでの待機時間を設定します。デフォルトは1,000 msで、0〜5,000 msの範囲で指定できます。テンポの遅いメニューでは値を大きくしてください。
- エージェントは
0〜9、*、#を、単独または内線番号のような連続入力として押すことができます。 - フローでは、成功時と失敗時の遷移を作成します。たとえば、正しい部署につながった、メニューが3回繰り返された、別の会社だった、営業時間外や留守番電話のメッセージが流れた、といったケースです。
最後の遷移が重要なのは、3分間の時間枠があるためです。長いメニューの後や、誰かが通話を転送した後に留守番電話につながった場合、留守番電話検出が発動しないことがあるため、フロー自体でそれを認識する必要があります。
留守番電話で通話を切る設定が有効なのに通話が切れない場合、システムが応答メッセージをIVRと分類した可能性が高いです。これに対応するには、IVR Hangupを有効にしてください。メニューの詳細はNavigate IVRをご覧ください。
各通話結果について何を記録すべきか？
プラットフォームの切断理由を記録し、自社システムが管理する処理結果フィールドにマッピングします。Retell は3つのレイヤーを提供しています。
call_status：registered、not_connected、ongoing、ended、またはerror。disconnection_reason：上の表にある具体的な結果。call_analysis内のin_voicemail：通話が留守番電話につながったかどうか。
call_ended webhookには、call_analysis（call_analyzedで届きます）を除くすべての通話フィールドが含まれます。接続されなかった通話ではcall_startedは送信されませんが、残りの2つは送信されます。webhookは10秒以内に2xxが返されない場合、最大3回リトライされるため、イベントとcall_idの組み合わせで重複排除してください。
より詳細な処理結果を得るには、通話後分析の抽出フィールドを追加します。処理結果にはセレクターフィールドが適しており、Retell のIVRドキュメントにはreached_human、ivr_outcome、ivr_pathなどの既製のフィールド定義が含まれています。Retell は、接続されなかった通話や会話がなかった通話ではカスタム抽出フィールドを埋めないため、まずdisconnection_reasonから処理結果を組み立て、抽出フィールドで詳細を補ってください。
運用リーダーは、分析ダッシュボードのVoicemail Rate指標を追跡し、voicemail_reachedの通話をエージェントのバージョン別にグラフ化できます。これにより、新しいバージョンで留守番電話に回る通話が増えていないかを確認できます。処理結果をCRMレコードに反映するには、CRMと音声AIを連携するワークフローをご覧ください。
リトライルールは誰が管理するのか？
自社のダイヤラーまたはバックエンドです。Retell のドキュメントには自動再発信の記載はなく、Retell はエージェントが同じ番号に電話をかける頻度に上限を設けていないと明記されています。一括発信（バッチコール）には通話ごとの遅延設定がなく、発信拒否（do-not-call）フラグもチェックしません。Create Phone Call APIは、honor_internal_dnc: trueを指定した場合にのみこのフラグをチェックします。
ただし、Retell はリトライポリシーに必要な入力情報を提供しています。
- Contactsは、留守番電話や応答のなかった通話を含め、すべてのアウトバウンド電話通話を会話として記録します。そのため、
last_conversation_timestampに基づくクールダウンは発信試行もカバーします。 - List contact conversationsは各通話の切断理由を返すため、「今週すでに留守番電話を2回残したので停止する」のように、結果別に試行回数を数えられます。
- Do-not-call detectionは
user_requested_dncで通話を終了し、その連絡先にマークを付けます。これは恒久的な停止として扱ってください。
上限を設定する前に、業界や地域に適用される発信頻度の規制について法務部門に確認してください。
副作用にも注意が必要です。短時間に多数の短い通話を発信すると、通信キャリアがその番号をスパムとしてフラグ付けすることがあり、その後の通話はdial_failedで失敗します。すべての留守番電話で通話を切るキャンペーンはまさにこのパターンを生むため、発信ペースを調整し、番号を登録してください。アウトバウンド用電話番号のチェックリストでは、番号の認証やブランド付き発信者番号について解説しています。
ローンチ前に留守番電話検出をテストするには？
最初の本番キャンペーンの前に、表のすべての状態をテストしてください。Retell では2段階のテストが可能です。
- Web通話：録音した留守番電話の応答メッセージやメニュー音声をWeb通話に流します。エージェントは実際の留守番電話やメニューにつながることなく、同じ検出とアクションを実行します。
- 電話通話：実際にアウトバウンドのテスト通話を発信し、キャリアの音声経路もあわせてテストします。
簡単なテストセット：
- 標準的な留守番電話の応答メッセージ（「メッセージを残す」設定と「通話を切る」設定の両方）
- 企業の営業時間外メッセージ
- キーパッドメニュー（誤った選択肢を1つ、繰り返されるメニューを1つ含む）
- 名前と用件を尋ねる通話スクリーニング
- 長い間を置いてから応答する人
- 各テストが想定どおりの
disconnection_reasonで終了し、CRMに正しい処理結果が記録されること
アウトバウンドキャンペーンに通話状態を組み込む
AMDは、ワークフローの前段に置くフィルターではなく、ワークフローの一部として組み込むことで最大の効果を発揮します。Retell は留守番電話検出、IVR対応、通話スクリーニング、切断理由をエージェントと同じプラットフォームで管理するため、各結果にそれぞれのアクションとログ記録を持たせることができます。連絡先リスト全体でこれらの通話状態を運用するには、Retell の一括発信（バッチコール）から始めましょう。
