はじめに
こんにちは、サーバーワークス 飯山です。
Amazon Connectでのコンタクトセンター構築において、時間がかかるフェーズの一つが「テスト」かと思います。 これまでは、修正のたびに実際に電話をかけ、DTMF（プッシュボタン）操作を行い、挙動やログを確認するという物理的な作業が必要でした。
本記事ではテストの効率化に大きく貢献できる、Amazon Connectの標準機能として提供されている「テスト・シミュレーション機能」について解説します。 Lambdaのモック化や発話内容のアサーション（検証）などといった機能の概要やユースケース、現状の注意点をまとめました。
テスト・シミュレーション機能とは？
Amazon Connectのコンソール上で、コンタクトフローの動作を自動検証できる機能です。 物理的な電話機を使わず、GUI上で仮想的な顧客の挙動（入力）と、それに対するシステムの挙動（応答・分岐）を定義し、シナリオテストを実行できます。
テストシナリオを構成する3つのブロック
テストシナリオは以下の3つのブロック（要素）を組み合わせて定義します。これらをパズルのように配置することで、一連のシナリオを構成します。
①Observe
システム側で発生するイベントをトリガー（検知）するブロックです。大きな特徴としてイベント（発話など）が発生するまで「待機」する動きとなります。
- 例：「プロンプト（音声案内）が再生された時」「電話がつながった時」など、システムの出力を監視します。
②Check
その時点で設定されているコンタクト属性（システム属性、ユーザー定義属性など）が期待通りかを判定するブロックです。
- 例：「再生されたプロンプトに『担当者』という言葉が含まれているか」「属性 CustomerType が Premium になっているか」を判定します。
③Action
システムに対して顧客の入力をシミュレートしたり、外部連携のモック（擬似応答）を設定するブロックです。
- 例：オペレーション時間/Lambda関数/Lex/キュー のモック設定を行います。
- 例：「ダイヤルキーの『1』を押す」「通話を切断する」といった顧客側の操作を行います。
- 例：「ログ出力をする」「テストを終了する」といったシステム操作を行います。
テスト機能で「できること」の抜粋
AWS Lambdaの戻り値を「モック化」できる
これはシミュレーションテストを行う上で大きなメリットになると思います。フロー内で呼び出すLambda関数を実際に実行せず、指定したJSONレスポンスを返却させることができます。 Actionブロックを使用して設定します。
- 活用シーン:
- バックエンド（DBやAPI）がまだ未完成な状態でのフロー先行開発。
- 「会員情報なし」「システムエラー」など、実データで作るのが面倒な異常系パターンのテスト。
- 実データを連携すると問題がある外部連携先に影響を与えずにテストを実施したい。
- 設定方法:
- テスト設定で対象のLambda ARNを指定し、返却したいJSONを定義する。
// モック返却例
{
"customerType": "premium",
"lastOrderDate": "2023-12-01"
}
各種リソースの動作上書き
Lambda以外にも、Connect固有リソースの挙動をテスト用にモック化できます。
| リソース | できること |
|---|---|
| オペレーション時間 | 現在時刻に関わらず、「営業時間内」「時間外」の結果を強制指定する。 |
| Amazon Lex | Lexボットの呼び出し結果（インテント、スロット値）をモック化する。 |
| キュー | コンタクトフローで実際に設定されているキューではなく、テスト用のキューに転送させる。キュー内の最大コンタクト数超過を強制指定する。 |
システム発話（プロンプト）の「アサーション」
IVRが顧客に対して「何を喋ったか」を検証できます。テキスト読み上げ（TTS）の内容が、期待値と一致しているかを自動判定します。 Observeブロックでメッセージ受信を検知&内容を判定します。
- 検証タイプ:
- Similar（完全一致）: 定義したテキストと一字一句同じか。
- Contains（部分一致）: 特定のキーワード（例：「担当者にお繋ぎします」）が含まれているか。
顧客入力（DTMF/音声）の「シミュレーション」
顧客が電話口で行う操作を自動化します。 Actionブロックを使用します。
- DTMF: 「1」を押す、「#」を押す、といった操作。
- 音声入力: Lexなどを使用している場合、「予約を変更したい」といった発話テキストを入力として渡すことができる。
- 切断: 顧客側から電話を切る動作もシミュレート可能。
コンタクト属性（Attributes）の検証
フローの分岐判定に使われる「コンタクト属性」が、期待通りの値を持っているかをチェックできます。 Checkブロックを使用します。
- 検証対象:
- ユーザー定義属性
- システム属性
- 外部属性（External）
- 活用シーン: ルーティングロジックが正しく機能し、後続の処理（Queue転送など）に必要な属性が付与されているかの確認。
テストシナリオの作成例
以下を作成し検証しました。
テスト対象のコンタクトフロー
- コンタクトフローのポイント
- 音声の設定：言語を英語に設定
- オペレーション時間を確認：Basic Hoursでのオペレーション時間判定あり
- 顧客の入力を取得する：DTMFでカメラに関する問い合わせは1を、洗濯機に関する問い合わせは2を押下させる
- 作業キューの設定：顧客のインプットに応じたキューを設定する
作成したテストシナリオ
- テストシナリオのポイント
- インタラクション名：テスト初期化
- オペレーション時間、およびキューをモック化
- インタラクション名：オペレーション時間を確認
- オペレーションの判定がされていることを確認
- インタラクション名：DTMFアナウンスの確認
- 営業時間内であると判定された先でDTMFアナウンスが発話されていることを確認
- DTMFのインプットとして"1"が押下されるよう指示
- インタラクション名：キューの確認
- DTMFの判定がされた先でカメラ部門に案内する旨のアナウンスが発話されたこと、および作業キューにCameraQueueが設定されていることを確認
- テストを終了
- インタラクション名：テスト初期化
テストシナリオでの設定値
- インタラクション名：テスト初期化
- Observe
- Event: Test started
- Action1
- Action: Mock resource behavior
- Resource type: Hours of operation
- Target resource: Basic Hours
- Option: Mock response
- Operation: Check hours of operation
- Response: In hours
- Action2
- Action: Mock resource behavior
- Resource type: Queue
- Target resource: CameraQueue
- Option: Substitute responce
- Substitute resource: TestQueue
- インタラクション名：オペレーション時間を確認
- Observe
- Event: Action triggered
- Resource type: Hours of operation
- Target resource: Basic Hours
- Operation: Check hours of operation
- インタラクション名：DTMFアナウンスの確認
- Observe
- Event: Message received
- Parameter: Text-to-speech or chat text->Set manually->"press"
- Interpret as: Text
- Matching criteria: Contains
- Action1
- Action: Send instruction
- Input type: Dtmf input
- Parameter: "1"
- Option: Substitute responce
- Substitute resource: TestQueue
- インタラクション名：キューの確認
- Observe
- Event: Message received
- Parameter: Text-to-speech or chat text->Set manually->"the camera department"
- Interpret as: Text
- Matching criteria: Contains
- Check1
- Namespace: System/Queue name
- Condition type: Equals
- Condition value: Set manually->"CameraQueue"
- Action1
- Action: Test commands
- Test control type: End test
テストの結果
テスト実行の結果、問題なく成功することを確認できました。
実務利用における「注意点・制限事項」
非常に便利な機能ですが、本記事執筆時点（2026/02/17時点）では万能ではありません。 導入前に知っておくべき注意点や制限事項を記載します。
発話内容のアサーションは「英語のみ」対応
システムが何を喋ったかを検証する「プロンプトのアサーション」機能ですが、残念なことに現時点では英語のみの対応となっています。 日本語のプロンプトを検証しようとしても、正しくマッチングしない可能性があるため注意が必要です。日本語環境では属性チェックなどを中心にテストを組み立てる必要があります。
アサーション結果の「揺らぎ」に注意
発話内容のアサーション（検証）は現時点で英語のみ対応ですが、英語であっても単語の区切り方や発音の解釈の違いにより、結果に揺らぎが生じることがあります。
例として 「serverworks」という単語をアナウンス発話させ、その単語で一致確認しようとした際、システム内部では「serve works」と判定され、不一致のためテストが失敗するケースがありました。
このように、アナウンス内容の完全一致（Equals）ではテスト結果が不安定になる可能性があります。厳密な一致条件よりも、部分一致（Contains）を利用するなどの工夫が必要です。
キューをモックしないと「実際に着信する」
テスト実行時、キュー（Queue）リソースをモック化していない場合、実際にそのキューへルーティングが行われます。 その結果、待機中のオペレーターの電話機に着信してしまったり、本番の待ち行列にテスト呼が混ざったりする事故につながります。
これを防ぐには、以下のいずれかの対策が必須です。
- キューをモック化する: Actionブロック等で対象のキューをモックし、実際には転送させないように設定する。
- 転送前に切断する: テストシナリオ上で、キュー転送ブロックに到達する前に「切断（Disconnect）」アクションを実行させる。
テスト実行に関する制限
テスト機能には、同時実行シミュレーション数や実行時間などにいくつかの制限が存在します。 現状の主な制限を記載しますが最新の値については、後述のAWS公式ドキュメントをご参照ください。
- 同時実行シミュレーション数: 最大5つのテストを同時に実行できます。
- 追加で実行しようとしたテストは待機状態になり、順番待ちになります。
- 実行時間: 各テストシミュレーションの最大実行時間は5分間です。
- もしテストがこの時間を超えた場合、自動的にタイムアウトとなり強制終了します。
- 逆にテストシナリオの最後にActionブロックで「通話を切断する」という終了処理を入れなかった場合、テストがタイムアウトまで終了しない動作となります。
コストがかかる（無料ではない）
テスト機能の利用には料金がかからないのではと想像される方もいると思うのですが、通常のAmazon Connect利用料とは別に料金が発生します。 大量の自動テストを実行する場合などは事前のコスト試算が必要となります。
まとめ
Amazon Connectのテスト・シミュレーション機能は、開発初期のロジック検証や、リグレッションテスト（改修時の影響範囲確認）において強力な武器になります。これらを活用し、コンタクトセンター開発におけるテストの効率化を目指していきましょう！
