Amazon Connectで自動発信する際のAnswerMachineDetectionConfigと[通話の進捗を確認]ブロックの設計パターンを整理してみた

はじめに

Amazon Connectで自動発信する場合、StartOutboundVoiceContact APIを使って指定した電話番号へ発信し、コンタクトフローを開始できます。

このとき、APIパラメータの AnswerMachineDetectionConfig を指定するべきか、またフロー内に 「通話の進捗を確認」 ブロックを入れるべきか迷うことがあります。

例えば、次のような判断に迷うことがあります。

• 留守電を区別しないなら、「通話の進捗を確認」ブロックは不要なのか
• 人間応答と留守電を区別し、留守電にはメッセージを流さず切断したい場合はどうするのか
• 留守電に折り返し依頼のメッセージを流したい場合はどうするのか
• 電話に出ない場合や、接続後に入力がない場合はどこで制御するのか

AnswerMachineDetectionConfig の仕様や、AnswerMachineDetectionConfig と「通話の進捗を確認」ブロックの役割の違いは、以下の記事で整理しています。

https://dev.classmethod.jp/articles/amazon-connect-startoutboundvoicecontact-answer-machine-detection-config/

本記事では、細かい仕様説明は前回記事に譲り、実際の要件ごとに AnswerMachineDetectionConfig と「通話の進捗を確認」ブロックをどう組み合わせて設計するか を整理します。

結論

自動発信時の設計パターンは、大きく以下の3つに整理できます。

ここでの AMD は Answering Machine Detection の略で、人間応答か留守電かを判定する機能を指します。本記事では、AnswerMachineDetectionConfig と「通話の進捗を確認」ブロックを組み合わせる構成を AMDを使う と表現します。

パターン2では、留守電分岐でメッセージを流さないため AwaitAnswerMachinePrompt=false としています。true にすると留守電プロンプトやビープ音を待つため、切断までの待ち時間が発生します。そのため、本記事では false を基本として整理します。

判断フローにすると以下です。

Q1. 人間と留守電で処理を分けたいか

No
  → パターン1
  → AnswerMachineDetectionConfig なし
  → 通話の進捗を確認ブロックなし

Yes
  ↓

Q2. 留守電にメッセージを流したいか

No
  → パターン2
  → AnswerMachineDetectionConfig あり
  → 通話の進捗を確認ブロックあり
  → AwaitAnswerMachinePrompt=false

Yes
  → パターン3
  → AnswerMachineDetectionConfig あり
  → 通話の進捗を確認ブロックあり
  → AwaitAnswerMachinePrompt=true

ポイントは、人間応答と留守電を分けて扱いたいか です。分けて扱いたい場合に、留守電分岐でメッセージを流すかどうかを決めます。

なお、相手が電話に出ず、留守電応答にも切り替わらない場合は、「通話の進捗を確認」ブロックでは制御できません。
相手が応答していないため、そもそもコンタクトフロー上の分岐まで到達しません。このケースは、後述する RingTimeoutInSeconds で制御します。

前提

本記事では、以下を前提にします。

• StartOutboundVoiceContact APIで自動発信する
• コンタクトフロー内で案内や入力取得を行う
• エージェントが手動で留守電かどうかを判断する構成は対象外
• Amazon Connect Outbound Campaigns機能でキャンペーンを作成・実行する構成は対象外
• AnswerMachineDetectionConfig の細かい仕様説明は前回記事に譲る

AWSのベストプラクティスには、AMDをオフにしてエージェントが手動または録音済みの留守電メッセージを残すユースケースも記載されています。

AMD がオフで、エージェントが手動のボイスメールを残すことができる
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/outbound-campaign-best-practices.html#machine-detection-oc

本記事では、コンタクトフローで自動的に分岐・再生する構成を中心に整理します。エージェントが実際の応答内容を聞いて判断する構成は、別の設計として考えます。

また、AMDの利用は国や地域、用途によって規制上の考慮が必要になる場合があります。AWSのベストプラクティスでも、AMDの導入は適用法に準拠した方法で行う責任が利用者側にある旨が説明されています。

The use of answering machine detection (AMD) may not be compliant with telemarketing laws.
留守番電話検知（AMD）の使用は、テレマーケティングに関する法律に準拠していない場合があります。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/outbound-campaign-best-practices.html#machine-detection-oc

実運用では、技術要件だけでなく、法務・コンプライアンス上の要件も確認してください。

通話の進捗を確認ブロックとは

通話の進捗を確認 ブロックは、留守電検知の結果を使ってフローを分岐するブロックです。

This topic defines the flow block for engaging with the output provided by an answering machine, and providing the appropriate branches to route the contact.

このトピックでは、留守番電話から提供される出力を利用し、コンタクトをルーティングするための適切なブランチを提供するフローブロックについて説明します。

https://docs.aws.amazon.com/connect/latest/adminguide/check-call-progress.html

このブロックでは、主に以下の分岐を利用できます。

ポイントは、通話の進捗を確認 ブロックは留守電検知を有効化する設定そのものではない点です。StartOutboundVoiceContact APIで AnswerMachineDetectionConfig を指定し、その検知結果をフロー内で分岐するために、このブロックを利用します。

パターン1：人間か留守電かを判定せずに同じフローを流す

このパターンが向いている考え方

パターン1は、人間か留守電かを判定せず、電話がつながったら同じフローを実行する構成です。人間が応答した場合も、留守電が応答した場合も、同じ案内や入力取得処理へ進みます。

以下のような考え方に向いています。

• 留守電に音声が録音される可能性はあるが、確実に残らなくても許容できる
• 入力がなければ未回答扱いにする
• 留守電や未検出を個別に集計しない
• 未回答者には後続で再架電や別チャネルでフォローできる

想定ケース例です。

• 緊急出勤確認で、入力があった人だけ回答扱いにする運用
• 簡易アンケートで、回答があった人だけ集計する運用
• イベント参加可否確認で、未回答者は別途フォローする運用
• 社内向けの一斉確認で、未回答者には再架電や別チャネルで確認する運用
• メールやSMSなど別チャネルでも案内済みで、電話は補助的な確認手段として使う運用

このパターンは、留守電にメッセージを確実に残すための設計ではありません。留守電が応答した場合でも、留守電ガイダンスとAmazon Connect側の案内が重なり、音声の冒頭が録音されない、または一部だけ録音される可能性があります。

そのため、予約リマインドや面談リマインドのように内容を確実に届けたい場合は、パターン3のように留守電分岐で専用メッセージを流す構成や、SMS・メールなど別チャネルとの併用を検討します。

構成

パターン1では、AnswerMachineDetectionConfig を指定しません。
また、フロー内に「通話の進捗を確認」ブロックも配置しません。

AnswerMachineDetectionConfig
  → 指定しない

通話の進捗を確認ブロック
  → 配置しない

フロー例です。

Start
  ↓
案内
  ↓
必要に応じて入力取得
  ├─ 1 → attendanceResponse=1
  ├─ 2 → attendanceResponse=2
  └─ 入力なし → 未回答
  ↓
切断

ここで使っている attendanceResponse は、発信先のユーザーが 1 または 2 を押した結果を保存するための例示のコンタクト属性名です。実際の環境では、response や answer など任意の属性名に置き換えてください。

例えば、以下のように扱います。

このパターンでは、attendanceResponse が入ったものだけを回答として扱います。留守電、無応答、途中切断などは細かく分類せず、まとめて未回答として扱う考え方です。

API例

aws connect start-outbound-voice-contact \
  --instance-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --contact-flow-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --destination-phone-number "+819012345678" \
  --source-phone-number "+815012345678" \
  --region ap-northeast-1

ap-northeast-1、インスタンスID、コンタクトフローID、電話番号は例です。実際の環境に合わせて置き換えてください。

このパターンのメリット

パターン1のメリットは、構成がシンプルなことです。

• AnswerMachineDetectionConfig が不要
• TrafficType=CAMPAIGN が不要
• 「通話の進捗を確認」ブロックが不要
• Not detected の扱いを考えなくてよい
• 入力があったかどうかだけで回答判定できる

また、TrafficType=CAMPAIGN を使わないため、Amazon Connect Outbound Campaigns側のクォータを考慮しなくてよい点もメリットになります。

StartOutboundVoiceContact の TrafficType では、EnableAnswerMachineDetection が true の場合に CAMPAIGN を使用すると説明されています。

Use CAMPAIGN if EnableAnswerMachineDetection is set to true.
EnableAnswerMachineDetection が true に設定されている場合は CAMPAIGN を使用します。
https://docs.aws.amazon.com/connect/latest/APIReference/API_StartOutboundVoiceContact.html

また、AWSドキュメントでは、TrafficType=CAMPAIGN の通話には事前にサービスクォータ申請が必要と記載されています。

Campaign calls are not allowed by default.
キャンペーン通話はデフォルトでは許可されていません。
https://docs.aws.amazon.com/connect/latest/APIReference/API_StartOutboundVoiceContact.html

Amazon Connect Outbound Campaigns service quotas には Concurrent campaign active calls per instance があります。

Concurrent campaign active calls per instance
The maximum number of concurrent campaign active calls you can have in this instance in the current Region.
インスタンスの現在のリージョンで保持できる同時キャンペーンアクティブ通話の最大数です。
https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-service-limits.html

パターン1では TrafficType=CAMPAIGN を使わないため、少なくとも TrafficType=CAMPAIGN を前提としたキャンペーン通話のクォータは考慮対象から外せると考えられます。

ただし、通常のAmazon Connectの同時通話数やAPIスロットリングなど、別のクォータは引き続き考慮が必要です。

このパターンの注意点

パターン1では留守電を判定しません。
そのため、相手が留守電だった場合でも、通話として接続されると同じフローが実行される可能性があります。

つまり、パターン1は以下の考え方に合う場合に向いています。

留守電を検知しない
留守電を別扱いしない
入力結果だけを見る

「留守電にはメッセージを流したくない」や「留守電だったことを判断して処理を分けたい」という要件がある場合は、次のパターン2を検討します。

パターン2：留守電を判定して留守電分岐ではメッセージを流さない

このパターンが向いている考え方

パターン2は、人間応答と留守電を判定し、留守電分岐ではメッセージを流さない構成です。人間応答時は、IVR、オペレーター転送、通常案内など、要件に応じた処理へ進めます。一方で、留守電分岐ではメッセージを流さず、切断や属性設定などを行います。

以下のような考え方に向いています。

• 留守電と判断した場合は切断、または属性を設定してから切断したい
• 留守電と未回答を分けて再架電したい
• 通話スクリーニングや留守電を、人間応答とは別扱いで判断したい
• 留守電プロンプトやビープ音を待つ必要がない

想定ケース例です。

• 本人が応答した場合だけ入力を受け付けたい確認業務
• 緊急出勤確認で、留守電分岐では勤務連絡を流したくない運用
• 個人情報や勤務情報を含む可能性があり、留守電分岐ではメッセージを流したくない案内
• 留守電、未検出、未回答を分けて再架電ルールを変えたい業務
• 留守電と判定された番号は一旦切断し、別時間帯に再架電したい業務
• 通話スクリーニングや留守電を、人間応答とは別扱いで判断したい業務

例えば、以下のようなメッセージは、後から留守電で聞いても 1 や 2 を押せません。

緊急出勤の確認です。
出勤可能な方は1を、出勤できない方は2を押してください。

このようなケースで、留守電分岐ではメッセージを流さず、人間応答時だけIVRに進めたい場合は「通話の進捗を確認」ブロックを使います。

構成

パターン2では、AnswerMachineDetectionConfig を指定し、「通話の進捗を確認」ブロックを配置します。

AnswerMachineDetectionConfig
  → 指定する

通話の進捗を確認ブロック
  → 配置する

AwaitAnswerMachinePrompt
  → false

AwaitAnswerMachinePrompt=false は必須という意味ではありません。true でも留守電分岐で切断すれば、留守電分岐でメッセージは流しません。

ただし、留守電分岐でメッセージを流さないのであれば、留守電プロンプトやビープ音を待つ必要性は低いため、本記事では false を基本として整理します。

API例

aws connect start-outbound-voice-contact \
  --instance-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --contact-flow-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --destination-phone-number "+819012345678" \
  --source-phone-number "+815012345678" \
  --answer-machine-detection-config "EnableAnswerMachineDetection=true,AwaitAnswerMachinePrompt=false" \
  --traffic-type CAMPAIGN \
  --ring-timeout-in-seconds 60 \
  --region ap-northeast-1

AnswerMachineDetectionConfig を指定し、人間応答と留守電を分ける前提のため、TrafficType=CAMPAIGN も指定しています。

フロー例

Start
  ↓
通話の進捗を確認
  ├─ Call answered
  │    ↓
  │   人間向けIVR
  │    ↓
  │   入力取得
  │
  ├─ Voicemail (beep)
  │    ↓
  │   切断、または属性保存して切断
  │
  ├─ Voicemail (no beep)
  │    ↓
  │   切断、または属性保存して切断
  │
  ├─ Not detected
  │    ↓
  │   要件に応じて処理
  │
  └─ Error
       ↓
      切断

留守電系の分岐をすべて切断するだけであれば、Voicemail (beep) と Voicemail (no beep) で別々の後続処理を用意しなくても構いません。

Voicemail (beep)
  ┐
Voicemail (no beep)
  ├→ 切断
Not detected
  ┘

ここでいう「メッセージを流さない」とは、留守電と判定された分岐でメッセージ再生ブロックを実行しない、という意味です。相手側の留守電に無音や途中の音が残らないことを保証するものではありません。

また、「通話の進捗を確認」ブロックより前にプロンプトを再生している場合、その音声が相手側に届く可能性があります。留守電分岐でメッセージを流したくない場合は、フローの早い段階で「通話の進捗を確認」ブロックに到達するように設計します。

このパターンのメリット

パターン2では、留守電と人間応答を分けて扱えます。

例えば、以下のように分岐できます。

Call answered
  → 人間応答としてIVRへ進める

Voicemail (beep)
  → 留守電分岐として扱い、切断

Voicemail (no beep)
  → 留守電分岐として扱い、切断

Not detected
  → 未検出分岐として扱い、要件に応じて処理

後続処理で留守電判定や未検出を集計したい場合は、切断前にコンタクト属性を設定します。

Voicemail (beep)
  → callProgress=voicemail_beep を設定
  → 切断

Voicemail (no beep)
  → callProgress=voicemail_no_beep を設定
  → 切断

Not detected
  → callProgress=not_detected を設定
  → 切断、または再架電対象にする

留守電を判定したいが、留守電分岐でメッセージを流す必要はない場合は、このパターンが基本になります。

このパターンの注意点

AMDを有効にすると、人間応答と留守電を分けられる一方で、誤検知やレイテンシーを考慮する必要があります。

AWSのベストプラクティスでは、AMDはボイスメール通話の数を削減するのに役立つ一方、検出精度には限界があると説明されています。

However, the detection accuracy has limitations.
ただし、検出精度には限界があります。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/outbound-campaign-best-practices.html#machine-detection-oc

同じベストプラクティスでは、短い留守電のあいさつを人間応答として検出してしまうケースや、人が応答した際の長いあいさつを留守電として誤検出してしまうケースがあることも説明されています。

また、AMDを有効にすると、人が応答した場合でも判定処理により小さな遅延が発生する可能性があります。

AMD adds a small latency to live calls.
AMD は、人が応答した通話に小さな遅延を追加します。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/outbound-campaign-best-practices.html#machine-detection-oc

そのため、パターン2のように Voicemail 系を即切断する設計では、人間応答が誤って留守電扱いになる可能性も考慮する必要があります。

重要な連絡で、できるだけ多くの人に案内を届けたい場合は、パターン1のようにAMDを使わない構成や、Not detected を人間向けIVRへ進める構成も検討してください。

パターン3：留守電を判定して留守電分岐で専用メッセージを流す

このパターンが向いている考え方

パターン3は、人間応答と留守電を判定し、留守電分岐では専用メッセージを流したい場合の構成です。人間応答時は、IVR、オペレーター転送、通常案内など、要件に応じた処理へ進めます。一方で、留守電分岐では、人間向けの案内とは別に、折り返し依頼などの専用メッセージを流します。

以下のような考え方に向いています。

• 人間応答時と留守電応答時で処理を分けたい
• 留守電分岐では折り返し依頼などの専用メッセージを流したい
• 人間向けの案内と留守電向けのメッセージを分けたい
• 留守電プロンプトやビープ音を待ってからメッセージを流したい
• すべての留守電に確実に残せるとは限らないことを許容できる

想定ケース例です。

• 予約日前日のリマインドで、留守電分岐でも確認メッセージを流したい運用
• 面談日程や来店予定の確認で、留守電分岐でも要件を伝えたい運用
• 配送や訪問予定の連絡で、留守電分岐でも不在時の案内を流したい運用
• コールバック依頼で、留守電が応答した場合にも折り返し依頼を流したい運用
• 緊急連絡で、人間応答時はIVR、留守電分岐では折り返し依頼を流したい運用

ただし、確実な通知が必要な場合は、SMSやメールなど別チャネルとの併用も検討します。

構成

パターン3では、AnswerMachineDetectionConfig を指定し、「通話の進捗を確認」ブロックを配置します。

パターン2との違いは、留守電分岐で専用メッセージを流したいため、AwaitAnswerMachinePrompt=true を基本にする点です。

AnswerMachineDetectionConfig
  → 指定する

通話の進捗を確認ブロック
  → 配置する

AwaitAnswerMachinePrompt
  → true

AwaitAnswerMachinePrompt は、留守電プロンプトを待つための設定です。

Wait for the answering machine prompt.
留守番電話のプロンプトを待ちます。
https://docs.aws.amazon.com/connect/latest/APIReference/API_AnswerMachineDetectionConfig.html

留守電分岐で専用メッセージを流したい場合、AwaitAnswerMachinePrompt=false だと、相手側の留守電ガイダンス中にAmazon Connect側のメッセージを再生し始める可能性があります。

そのため、留守電分岐で専用メッセージを流す目的では、AwaitAnswerMachinePrompt=true を検討します。

API例

aws connect start-outbound-voice-contact \
  --instance-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --contact-flow-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --destination-phone-number "+819012345678" \
  --source-phone-number "+815012345678" \
  --answer-machine-detection-config "EnableAnswerMachineDetection=true,AwaitAnswerMachinePrompt=true" \
  --traffic-type CAMPAIGN \
  --ring-timeout-in-seconds 60 \
  --region ap-northeast-1

フロー例

Start
  ↓
通話の進捗を確認
  ├─ Call answered
  │    ↓
  │   人間向けIVR
  │
  ├─ Voicemail (beep)
  │    ↓
  │   留守電用メッセージを再生
  │    ↓
  │   切断
  │
  ├─ Voicemail (no beep)
  │    ↓
  │   必要に応じて留守電用メッセージを再生、または切断
  │    ↓
  │   切断
  │
  ├─ Not detected
  │    ↓
  │   要件に応じて処理
  │
  └─ Error
       ↓
      切断

留守電用メッセージは、人間向けのIVRとは分けるのがおすすめです。

人間向けメッセージの例です。

緊急出勤の確認です。
出勤可能な方は1を、出勤できない方は2を押してください。

留守電向けメッセージの例です。

緊急出勤の確認です。
このメッセージを確認されましたら、お手数ですが担当者まで折り返しご連絡ください。

留守電ではDTMF入力できないため、留守電向けには折り返し依頼などのメッセージに分けた方が自然です。

このパターンの注意点

パターン3は、留守電と判定された場合に、留守電用メッセージを再生する構成です。

ただし、すべての留守電に確実にメッセージを残せるとは限りません。AWSのベストプラクティスでは、「AMD がオンで、自動ボイスメールを残す」ユースケースについて、誤検出などの影響により、ボイスメールを残せる割合には限界があることが説明されています。

The technology leaves voicemails 50-60% of the time due to false detections.
このテクノロジーは、誤検出が原因で、50～60% の確率でボイスメールを残します。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/outbound-campaign-best-practices.html#machine-detection-oc

そのため、記事や設計書では「必ず留守電に残せる」と断定せず、留守電と判定された場合に留守電用メッセージを再生する と表現する方が安全です。

また、Voicemail (no beep) はビープ音を検出できなかったケースです。この分岐でもメッセージを流すか、切断するかは業務要件に合わせて判断してください。

AMD利用時はNot detectedと誤検知を考慮する

前提章で整理したとおり、「通話の進捗を確認」ブロックでは Call answered、Voicemail (beep)、Voicemail (no beep)、Not detected などの分岐を利用できます。

この中で特に設計時に注意したいのが Not detected の扱いです。

ドキュメントでは Not detected について以下のように説明されています。

Not detected: Could not detect whether there is voicemail.
未検出：留守電であるかどうかを認識できませんでした。
https://docs.aws.amazon.com/connect/latest/adminguide/check-call-progress.html

今回の検証では、以下のような挙動を確認しました。

つまり、着信者が電話に出ていても、無言のままだと Call answered に進まず、Not detected に分岐する場合があります。

想定ケース例です。

• 着信者が電話に出たあと、すぐに話さない
• 着信者が周囲の音を気にして無言で待つ
• Bluetooth機器や車載機器で応答し、発話まで時間が空く
• 騒音が大きい場所で応答した

Not detected の扱いは、以下のように要件に応じて決めるとよいです。

AWSのベストプラクティスでは、特にエージェントへ転送する構成では、Not detected 分岐を Call answered と同じように扱うことが推奨されています。これは、Not detected が人間応答の可能性もボイスメールの可能性もあるためです。

This branch should be treated in the same way as Call answered.
この分岐は、応答した呼び出しと同じ方法で処理する必要があります。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/outbound-campaign-best-practices.html

本記事では、留守電や未検出には案内を流したくない要件も想定しているため、Not detected を切断する例も記載しています。ただし、人間が無言で応答した可能性を拾いたい場合は、Not detected を人間向けIVRへ進める、または短い案内を流す設計も検討してください。

電話側の通話スクリーニングに当たった場合

最近のスマートフォンには、着信時にAIが代わりに応対する通話スクリーニング機能があります。

Google Pixelの通話スクリーニングでは、電話がかかってきた際に、発信者の名前や用件を確認する機能が説明されています。

https://store.google.com/jp/magazine/google-pixel-call-screening?hl=ja&pli=1

今回の検証では、電話側で通話スクリーニングに応答させた場合、Amazon Connect側では Voicemail (no beep) に分岐しました。

想定ケース例です。

• 着信者がGoogle Pixelの通話スクリーニングを使っている
• スマートフォン側の迷惑電話対策機能が自動応答する
• 企業や個人の電話アプリが自動応答する

ただし、これは今回確認した条件での結果です。端末、OS、電話アプリ、通話スクリーニングの応答内容によって挙動が変わる可能性があります。

通話スクリーニングを利用している相手が多い想定であれば、Voicemail (no beep) を単純な留守電扱いにするのか、別途属性を残して分析するのかを検討するとよいです。

通話の進捗を確認ブロックで制御できないケース

相手が応答しない場合

相手が電話に出ず、留守電応答にも切り替わらない場合の制御は、「通話の進捗を確認」ブロックではできません。

「通話の進捗を確認」ブロックは、相手が応答した後に、人間応答、留守電、未検出などを分岐するためのブロックです。相手が人間としても留守電としても応答していない場合、コンタクトフロー内の「通話の進捗を確認」ブロックまで到達しません。

整理すると以下です。

相手が電話に出ない
  → 人間応答がない
  → コンタクトフローの分岐まで到達しない
  → 通話の進捗を確認ブロックでは制御できない

留守電応答にも切り替わらない
  → 留守電としても応答していない
  → コンタクトフローの分岐まで到達しない
  → 通話の進捗を確認ブロックでは制御できない

人間が出る
  → 応答後に通話の進捗を確認ブロックで分岐できる

留守電が応答する
  → 応答後に通話の進捗を確認ブロックで分岐できる

この違いを混同すると、「電話に出ない場合も通話の進捗を確認ブロックで切断できる」と誤解しやすいため注意が必要です。

つながらない場合に早めに終話させたい場合

相手が電話に出ない場合の待ち時間は、StartOutboundVoiceContact APIの RingTimeoutInSeconds で制御します。

想定ケース例です。

• 大量架電で、1件あたりの呼び出し時間を短くしたい
• すぐに出ない相手は次回再架電に回したい
• 緊急連絡で、出ない相手に長く鳴らし続けたくない
• 架電リストを短時間で一巡させたい

RingTimeoutInSeconds は、発信先が応答するまで待つ最大秒数です。

The maximum time the outbound call will wait for the destination to answer the call, in seconds
アウトバウンド通話が宛先の応答を待つ最大時間を秒単位で指定します。
https://docs.aws.amazon.com/connect/latest/APIReference/API_StartOutboundVoiceContact.html

また、指定可能な範囲は15秒から60秒です。

Valid Range: Minimum value of 15. Maximum value of 60.
有効範囲：最小値は15、最大値は60です。
https://docs.aws.amazon.com/connect/latest/APIReference/API_StartOutboundVoiceContact.html

例えば、早めに諦めたい場合は以下のようにします。

aws connect start-outbound-voice-contact \
  --instance-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --contact-flow-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  --destination-phone-number "+819012345678" \
  --source-phone-number "+815012345678" \
  --traffic-type CAMPAIGN \
  --ring-timeout-in-seconds 15 \
  --region ap-northeast-1

「つながらない場合に即終話」という要件では、RingTimeoutInSeconds の最小値である15秒が実質的な下限になります。

RingTimeoutInSeconds と「通話の進捗を確認」ブロックは、効くタイミングが異なります。

タイムラインで表すと以下です。

StartOutboundVoiceContact API 実行
  ↓
発信開始
  ↓
呼び出し中
  ↓
RingTimeoutInSeconds が効く
  ↓
相手が応答しないままタイムアウト
  → 通話失敗
  → 通話の進捗を確認ブロックには到達しない

相手が応答した
  ↓
コンタクトフロー開始
  ↓
通話の進捗を確認ブロックで分岐

つまり、RingTimeoutInSeconds は 応答前の呼び出し待ち時間、通話の進捗を確認ブロックは 応答後の人間 / 留守電 / 未検出の分岐 と考えると整理しやすいです。

つながった後に入力がなければ早めに終話させたい場合

電話がつながった後、入力がなければ早めに切りたい場合は、入力取得ブロックのタイムアウトで制御します。

想定ケース例です。

• 1 または 2 の入力がなければ未回答扱いにする
• 無言のまま一定時間経過したら切断したい
• 留守電や通話スクリーニングに対して長く音声を流したくない
• 人間が出ても入力しない場合は再架電対象にしたい

例えば、以下のようなフローです。

Start
  ↓
「出勤可能な方は1を、出勤できない方は2を押してください」
  ↓
顧客の入力を取得する
  ├─ 1 → attendanceResponse=1 → 切断
  ├─ 2 → attendanceResponse=2 → 切断
  └─ 入力タイムアウト → 切断

今回のような緊急出勤確認で、入力がなかったものを未回答扱いにするだけでよいなら、「通話の進捗を確認」ブロックを使わず、入力待ち時間だけ短くする設計も有効です。

この場合、留守電か人間かは区別しません。
その代わり、attendanceResponse が設定されたかどうかで回答有無を判断します。

まとめ

Amazon Connectで自動発信する際の AnswerMachineDetectionConfig と「通話の進捗を確認」ブロックの設計パターンを整理しました。

判断の起点は、人間応答と留守電を分けて扱いたいか です。

• 分けて扱わない場合は、AnswerMachineDetectionConfig も「通話の進捗を確認」ブロックも不要
• 分けて扱う場合は、両方を組み合わせて利用する
• 留守電分岐でメッセージを流さないなら AwaitAnswerMachinePrompt=false、専用メッセージを流すなら true を基本にする
• 相手が応答しない場合は「通話の進捗を確認」ブロックではなく、RingTimeoutInSeconds で制御する

まずは、人間応答と留守電で処理を分ける必要があるかを決めると、設計しやすくなります。