公開2025.03.27更新2026.10.01 AWS

Amazon Connectのアウトバウンドウィスパーフローとは｜設定手順と録音・発信者番号

Amazon Connectのアウトバウンドウィスパーフロー（Outbound whisper flow）は、エージェントが発信した通話で相手が電話に出たあと、エージェントとつながる直前に顧客側で動くフローです。「この通話は品質向上のため録音しています」といった案内を流す、録音を開始する、表示する発信者番号を決める、の3つが主な用途になります。エージェントには聞こえません。この記事では、どのキューの設定が使われるのか、実行のタイミングと2分の上限、作成とキューへの割り当て手順、録音と発信者番号の注意点を、AWSの管理者ガイドとre:Postの公式記事に沿って整理します。なお、音声入力アプリの「Wispr Flow」とは別物です。

まとめ：アウトバウンドウィスパーフローの要点

ウィスパーは片側だけに流れる案内で、アウトバウンドウィスパーフローは顧客に流れます。エージェント向けのウィスパーは着信時のものです。
対象はエージェントの直接発信とコールバックです。API（StartOutboundVoiceContact）で発信する場合は、指定したフローが動きます。
使われるのは、エージェントのルーティングプロファイルに設定された「既定のアウトバウンドキュー」のフローです。
最初の「プロンプトの再生」ブロックより前は発信前に、それ以降は相手が出たあとに実行されます。録音の設定と発信者番号の指定は、プロンプトより前に置きます。
ウィスパーの上限は2分です。超えると通話が切断されます。

以下、仕組み・設定手順・録音・発信者番号の順に説明します。

ウィスパーフロー3種類の違いと聞こえる相手

ウィスパーフローは、顧客とエージェントが接続されるときに一方だけが聞く（チャットなら一方だけに表示される）案内です。AWSのSet whisper flowブロックの説明は「one-sided interaction」と書いており、顧客向けのウィスパーはエージェントに聞こえず、エージェント向けのウィスパーは顧客に聞こえません。Amazon Connectには用途の違う3種類があります。

フローの種類	聞く相手	動く場面	既定フローの内容
エージェントウィスパー	エージェント	着信を受け入れた直後	キュー名の読み上げ
顧客ウィスパー	顧客	着信でエージェントにつながる直前	ビープ音
アウトバウンドウィスパー	顧客	発信で相手が出たあと、接続の直前	録音していない旨の英語音声

着信では、エージェントが受け入れるとエージェントウィスパーが先に流れ、終わってから顧客がキューから外れて顧客ウィスパーが流れます。両方が最後まで再生されてから会話が始まります。一方、公式の説明では、発信の音声通話でウィスパーが流れる相手は顧客です。「アウトバウンドウィスパーはエージェントに発信先の情報を伝える仕組み」という説明を見かけますが、これは着信用のエージェントウィスパーと混同した誤りです。発信ではエージェント自身が番号を入力しているので、相手の情報はエージェントの画面側で出すのが筋になります。

既定のアウトバウンドフロー（Default outbound）は、任意の録音設定ブロックのあとに英語の音声 This call is not being recorded. を流して終わります。日本語の案内に変えたい場合や録音を有効にしたい場合は、独自のアウトバウンドウィスパーフローを作ってキューに割り当てます。なお、AWSの管理者ガイドは2026年10月時点で製品名を「Connect Customer」と表記していますが、本記事では通称のAmazon Connectで書きます。

アウトバウンドウィスパーフローの実行タイミング

対象になる発信：直接発信とコールバック

Call phone number（電話番号への発信）ブロックの説明によると、アウトバウンドウィスパーフローは、直接発信とコールバックの場面で、エージェントが通話を受け入れた直後に実行されます。コンタクトコントロールパネル（CCP）のダイヤルパッドから番号を入力して発信する操作が直接発信にあたります。

APIのStartOutboundVoiceContactで発信する場合は仕組みが違います。このAPIはContactFlowIdで指定したフローを実行し、そのフローが顧客をキューに入れると、着信と同じようにエージェントへ振り分けられます。自動発信のシステムを組む場合は、案内や録音の設定をこの指定フロー側に置く前提で設計してください。

プロンプトの再生ブロックを境にした実行タイミング

既定のアウトバウンドフローの説明に、設計上もっとも大事な規則が書かれています。最初のPlay prompt（プロンプトの再生）ブロックより前のブロックは発信する前に実行され、最初のプロンプトとそれ以降のブロックは顧客が電話に出たあとに実行されます。

このため、録音の設定（Set recording, analytics and processing behavior）と発信者番号の指定（Call phone number）はプロンプトより前に置きます。Call phone numberブロックについては、プロンプトより前に置く必要があると公式に明記されています。逆に、顧客に聞かせたい案内や、応答後に設定したいコンタクト属性はプロンプト以降に置きます。

ウィスパーの2分上限と超過時の切断

ウィスパーは最長2分で、それを超えると顧客またはエージェントが切断されます。エージェントの画面が「接続中」のまま止まり、最後に切れる場合は、ウィスパーフローが2分以内に終わっているかを確認するよう公式ドキュメントが案内しています。Lambda関数の呼び出しや長い音声ファイルを入れる場合は、再生時間と待ち時間の合計で2分を大きく下回るように組んでください。

使われるキューの決まり方：ルーティングプロファイルの既定アウトバウンドキュー

アウトバウンドウィスパーフローはキューの設定項目で、キューの編集画面にある「アウトバウンドウィスパーフロー（オプション）」で選びます。ここで迷いやすいのが、エージェントが発信したときにどのキューの設定が使われるかです。AWSのre:Postの公式記事によると、エージェントは1つのルーティングプロファイルに属し、ルーティングプロファイルごとに既定のアウトバウンドキューが1つあります。Amazon Connectは、その既定のアウトバウンドキューに設定されたアウトバウンドウィスパーフローを使います。

そのため、「営業部門は録音あり、サポート部門は録音なし」のように部署ごとに案内を分けたいときは、キューを分けるだけでは足りません。部署ごとにルーティングプロファイルを分け、それぞれの既定アウトバウンドキューに別のアウトバウンドウィスパーフローを割り当てます。1つのルーティングプロファイルの中で相手や案件によって案内を変えたい場合は、フローの中でコンタクト属性を見て分岐させる方法になります。

また、キューに選べるのは公開済み（Publish）のフローだけです。保存しただけの下書きは選択肢に出ません。

アウトバウンドウィスパーフローの作成とキューへの割り当て

管理画面でのフロー作成手順

Amazon Connectの管理画面（https://インスタンス名.my.connect.aws）に、フローを作成できる権限のあるユーザーでログインして作業します。re:Postの公式手順をもとにした流れは次のとおりです。

ナビゲーションで「ルーティング」→「フロー」を開き、「フローを作成」の横の矢印から「アウトバウンドウィスパーフローを作成」を選びます。
フロー名を入力します（例：Outbound whisper – 録音案内）。
録音する場合は、Set recording, analytics and processing behavior（記録、分析、処理の動作を設定する）ブロックを置き、アクションで「Set recording and analytics behavior」、チャネルで音声を選んで、エージェントと顧客の録音をオンにします。
発信者番号を固定したい場合は、Call phone number（電話番号への発信）ブロックを置きます（次の章で説明）。
Set voice（音声の設定）ブロックで日本語と音声を選び、Play prompt（プロンプトの再生）ブロックで案内文を設定します。
End flow / Resume（フローの終了/再開）ブロックで終えます。このブロックはフローを終えても顧客との通話を切りません。
保存して公開します。
「ルーティング」→「キュー」で対象のキューを開き、「アウトバウンドウィスパーフロー（オプション）」で作成したフローを選んで保存します。

手順3と4がプロンプトより前にあるのは、前章の実行タイミングの規則に合わせるためです。日本語の読み上げ音声はAmazon Pollyの音声が使われるので、使える音声と制約はAmazon Pollyの日本語音声の制約で確認できます。

AWS CLIでキューに割り当てる手順

キューが多い場合や、設定を検証環境から本番へ揃えたい場合はAWS CLIが使えます。キューの発信設定はOutboundCallerConfigにまとまっていて、アウトバウンドウィスパーフローはOutboundFlowId、発信者番号はOutboundCallerIdNumberId、発信者名はOutboundCallerIdNameです。以下はAWS CLIリファレンスのオプション名に沿った例で、各手順の結果を次の手順の変数に入れていきます。INSTANCE_ID、ROUTING_PROFILE_ID、FLOW_IDの3つは、先に自分の環境の値を入れておいてください。

# 事前に設定する値
INSTANCE_ID="インスタンスID"
ROUTING_PROFILE_ID="ルーティングプロファイルID"
FLOW_ID="アウトバウンドウィスパーフローのID"   # 1)で確認した値

# 1) アウトバウンドウィスパーフローの一覧とIDを確認する
aws connect list-contact-flows --instance-id "$INSTANCE_ID" \
  --contact-flow-types OUTBOUND_WHISPER \
  --query "ContactFlowSummaryList[].[Name,Id]" --output table

# 2) ルーティングプロファイルの既定アウトバウンドキューを取得する
QUEUE_ID=$(aws connect describe-routing-profile --instance-id "$INSTANCE_ID" \
  --routing-profile-id "$ROUTING_PROFILE_ID" \
  --query "RoutingProfile.DefaultOutboundQueueId" --output text)

# 3) そのキューの現在の発信者名と番号を取得する（値が無いとNoneが返る）
CALLER_NAME=$(aws connect describe-queue --instance-id "$INSTANCE_ID" --queue-id "$QUEUE_ID" \
  --query "Queue.OutboundCallerConfig.OutboundCallerIdName" --output text)
NUMBER_ID=$(aws connect describe-queue --instance-id "$INSTANCE_ID" --queue-id "$QUEUE_ID" \
  --query "Queue.OutboundCallerConfig.OutboundCallerIdNumberId" --output text)
[ "$CALLER_NAME" = "None" ] && CALLER_NAME=""

# 4) 発信者名と番号を残したまま、フローだけ差し替える
#    発信者名が空なら OutboundCallerIdName の項目ごと省く
aws connect update-queue-outbound-caller-config --instance-id "$INSTANCE_ID" \
  --queue-id "$QUEUE_ID" \
  --outbound-caller-config "${CALLER_NAME:+OutboundCallerIdName=$CALLER_NAME,}OutboundCallerIdNumberId=$NUMBER_ID,OutboundFlowId=$FLOW_ID"

手順4で発信者名と番号も渡しているのは、省略した項目がどう扱われるかがリファレンスに書かれていないためです。既存の値を明示して渡せば、フローの差し替えで発信者番号が外れる事故を避けられます。発信者名は任意項目ですが、指定するなら1文字以上が必要です。--output textは値が無いとNoneを返すので、その場合は空にして、発信者名の項目ごと渡さないようにしています。AWS環境での実行は検証していないため、まず検証用のキューで試してください。

録音の案内と通話録音の設定

発信の通話を録音するには、アウトバウンドウィスパーフローにSet recording, analytics and processing behaviorブロックを置き、録音の設定をするのが公式の推奨です。他の種類のフローに置いた場合は、エージェントとつながったあとに実行されることがあり、録音されない通話が出る可能性があると説明されています。ブロックでは「Set recording and analytics behavior」のアクションを選び、録音する範囲（エージェントと顧客の両方か、どちらか一方か）、音声分析、エージェントの画面録画を設定します。旧来のSet recording and analytics behaviorブロックは既存フローとの互換のために残っていますが、新しく作るフローや修正するフローでは後継のこのブロックに置き換えるよう案内されています。

既定のアウトバウンドフローが流す案内は英語なので、日本の顧客向けには独自フローで日本語の案内に差し替えます。法的な位置づけも押さえておきます。個人情報保護委員会のQ&A（Q1-10）は、通話内容から特定の個人を識別できる場合は個人情報にあたり、事業者は利用目的を通知または公表する義務を負う一方で、録音していることを伝える義務までは負わないと説明しています。根拠は個人情報保護法第21条1項で、利用目的をあらかじめ公表している場合を除き、取得後速やかに本人へ通知するか公表することを求めています。つまり個人情報保護法上、録音の案内そのものは義務ではありません。ただ、利用目的を公表していない場合は「品質向上と応対内容の確認のため、この通話を録音しています」のように目的まで含めた案内にしておけば、通知の役割も果たせます。録音データを応対記録として保管する運用は、カスハラ対策の義務化で求められる録音・対応記録の要件でも扱っています。

ウィスパーは通話の文字起こしには残りません。案内を流した記録を残したいときは、フロー内でコンタクト属性に書き込むなど、別の方法で残してください。

発信者番号の上書きとつまずきやすい設定

発信時に相手へ表示される番号は、通常はキューの「アウトバウンド発信者ID番号」です。アウトバウンドウィスパーフローにCall phone numberブロックを置くと、この番号を上書きできます。複数の番号を持っていても代表番号に揃えたい場合や、顧客の属性で表示番号を変えたい場合に使います。

使える番号：発信者IDの設定ページは、発信者番号にはインスタンスで取得済み（またはポート済み）の番号を使うと定めています。例外として外部の番号も使えますが、カスタム発信者IDに対応した国の番号であること、所有を証明する書類を出すこと、AWSサポートで有効化してもらうことが条件です。属性で渡す場合もE.164形式（日本なら+81から始まる形式）が必要で、E.164でない値はキューの番号に置き換わります。
エラー分岐がない：Call phone numberブロックにはErrorの分岐がありません。発信を開始できなかった場合はフローが終わり、エージェントは後処理（ACW）状態になります。
外部番号の申請：外部番号をカスタム発信者IDに使う場合は、AWSサポートのケース（Connect (Number Management)、Custom Outbound Called ID）で申請します。インスタンスで取得済みの番号を選ぶだけなら、この申請の手順は出てきません。
通話中の転送には効かない：エージェントが通話中に転送で発信する場合、発信者番号は元の着信を処理したキューのものになり、アウトバウンドウィスパーフローでは上書きできません。転送先で番号を指定するならTransfer to phone number（電話番号への転送）ブロックで設定します。
コールバックの番号：キュー付きコールバックでは、コールバックに使うキューに発信者番号を設定しておかないと、相手には非通知で表示されます。
メール送信のループ：アウトバウンド系のフローにSend message（メッセージを送信）ブロックでメールを送る処理を入れると、送ったメールが同じフローを再び動かしてループする危険があると公式が警告しています。チャネルを判定してメールを除外する分岐を先に置いてください。

着信側の画面に発信者番号から顧客情報を出す仕組みは、CTIの仕組みと機能で扱っています。

音声案内を省くべき場面とエージェント向け情報の出し方

大量に発信する業務では、顧客が電話に出てからエージェントの声が聞こえるまでの間が短いほど切られにくくなります。AWSのアウトバウンドキャンペーンのベストプラクティスも、顧客が感じる遅延を減らすため、Set whisper flowブロックでエージェントウィスパーと顧客ウィスパーを無効にするよう勧めています。これはキャンペーンの発信がキューを経由してエージェントにつながるときのウィスパーの話で、本記事のアウトバウンドウィスパーフローとは設定場所が違います。ただ、応答直後の無音を短くするという考え方は、エージェントの直接発信にもそのまま当てはまります。録音の案内が不要な運用なら、プロンプトを入れずに録音設定と発信者番号の指定だけを置いたアウトバウンドウィスパーフローにするのが妥当です。

エージェントに発信先の情報を伝える目的でもアウトバウンドウィスパーフローは使えません。顧客にしか流れないためです。発信先の顧客情報は、CCPやエージェントワークスペースの画面、CRM連携で表示してください。

Amazon Connectの料金体系や導入の流れはAmazon Connectの料金・機能・導入方法に、自動音声でのセルフサービスはAmazon LexとAmazon Connectの連携にまとめています。

よくある質問

ウィスパーフローとは何ですか？

Amazon Connectで顧客とエージェントが接続されるときに、どちらか一方だけに流す案内のフローです。着信用のエージェントウィスパーと顧客ウィスパー、発信用のアウトバウンドウィスパーの3種類があります。長さの上限は2分です。

アウトバウンドウィスパーフローの音声はエージェントにも聞こえますか？

聞こえません。発信の音声通話でアウトバウンドウィスパーが流れる相手は顧客で、ウィスパーは片側だけに流れる仕組みです。エージェントへ情報を出したい場合は、画面側（CCPやCRM連携）で表示します。

エージェントウィスパーフローとの違いは何ですか？

エージェントウィスパーフローは着信でエージェントが受け入れた直後にエージェントへ流れ、既定ではキュー名を読み上げます。アウトバウンドウィスパーフローはエージェントの発信で相手が出たあとに顧客へ流れ、既定では英語で録音していない旨を案内します。

発信した通話を録音するにはどうすればよいですか？

アウトバウンドウィスパーフローにSet recording, analytics and processing behaviorブロックを置き、Set recording and analytics behaviorのアクションで録音をオンにして、最初のプロンプトより前に配置します。そのフローを、エージェントのルーティングプロファイルの既定アウトバウンドキューに割り当ててください。