テスト時間を最大 90% 削減 – Amazon Connect のテストとシミュレーション機能

はじめに

コンタクトセンター管理者は、本番環境を中断することなく、コンタクトフローを効率的にテストと検証するという課題に直面しています。従来のアプローチ、例えば手動でシステムに電話をかける、カスタム検証ツールを構築する、サードパーティソリューションに投資するような手段は、時間とコストがかかります。大企業では、年間予算の大部分が自動テストツールに割り当てられることも多く、一方で手動検証を用いる場合は変更ごとに数日から数週間の作業が必要になることがあります。Amazon Connect が高度な AI 機能で進化するにつれて、サービス品質と顧客満足度を維持するための効率的なテスト戦略がさらに重要になっています。

Amazon Connect はネイティブコールシミュレーション機能の一般提供を発表しました。組み込まれたこのテストソリューションは、検証時間と作業を大幅に削減しながら、コンタクトセンター設計への信頼性を高めます。外部ツールや手動での電話テストなしでコンタクトセンターワークフローを自動的にテストでき、チームはイノベーションと優れた顧客体験の提供に集中できます。

本記事で学べること

本記事では、Amazon Connect の新しいテスト機能を活用してコンタクトセンターの検証を自動化する方法を説明します。次のことを学べます。

直感的なビジュアルデザイナーでテストケースを設定する
自然な顧客インタラクションを反映したテストシナリオを作成する
自動テストを実行し、結果を分析して継続的な改善を行う

テストフレームワークの概要

Amazon Connect のテストとシミュレーションフレームワークは、直感的なビジュアルインターフェースでコンタクトセンター体験を検証できます。ステップバイステップのガイドと複雑な遷移による従来のテストアプローチとは異なり、顧客が実際にコンタクトセンターとやり取りする方法を反映した、自然でユーザーフレンドリーなものです。

イベント駆動型テストモデル

フレームワークのコアにはイベント駆動型モデルを使用しています。コンタクトフロー実装の深い技術知識による記述ではなく、「X が発生したら Y を実行する」という観点でテストを記述します。例: 「IVR が『エージェントと話すには 1 を押すか、エージェントと言ってください』と再生したら、顧客は 1 を押すか、エージェントと言う必要があります。」

これには 3 つの直感的な概念を活用します。

Observations (監視): 期待されるシステムイベントと対応するアクションを含む完全なインタラクション
Events (イベント): システムから期待される特定の動作 (プロンプト、ボットメッセージ、Lambda 関数呼び出し)
Actions (アクション): テストフレームワークが応答としてシミュレートすべきこと (顧客入力、属性検証、リソースモック)

イベント駆動型モデルは大きなメリットをもたらします。技術者以外のチームメンバーでもテストを簡単に理解して作成でき、QA チームにとっては最小限のトレーニングで済ませられ、フレームワークによってプロセスをアクセスしやすく保ちながら技術的な精度を維持できます。

ビジュアルテストデザイナーインターフェース

デザイナーは、インタラクショングループを使用してテストシナリオを視覚的に構築できるインターフェースです。各インタラクショングループは、期待される動作とシミュレートされたアクションの完全なシーケンスを表し、テストフローを一目で把握できます。ビジュアルアプローチにより学習にかかる時間が短縮され、チームメンバーは基礎となる技術実装の詳細を理解することなくテストを作成できます。

テスト分析とダッシュボード

Amazon Connect は、分析と最適化 > ダッシュボードとレポート > テストおよびシミュレーションダッシュボード からアクセスできる専用のテストとシミュレーションダッシュボードを提供します。ダッシュボードでは以下のようなテスト実行履歴の詳細な洞察が得られます。

全体的なテスト成功率を示すサマリーメトリクス
一般的な問題を特定するための失敗タイプの内訳
パフォーマンス分析のための実行時間メトリクス
時間の経過に伴う改善を追跡するための日付範囲フィルタリング

テストケースの作成

効果的なテストケースの構築には、3 つの主要なステップがあります。基本的なテスト設定の構成、インタラクショングループを使用したテストフローの設計、観察およびシミュレートする特定の動作の定義です。

テスト設定とパラメータの構成

テストケース管理ページ（ルーティング > テスト）で テストを作成 をクリックして、新しいテストケースを作成します。設定タブで次を構成します。

開始点: 特定のフローまたは電話番号
チャンネル: 音声通話
着信電話番号: シミュレートされる発信者の電話番号
属性: プロファイル情報などのユーザー定義コンタクト属性

インタラクショングループの構築

デザイナータブで、インタラクショングループのテストフローを構築します。各グループは、何かが発生することを期待し、そのイベントを検証または応答する必要がある瞬間を表します。+ 新しいインタラクションボタンでインタラクショングループを追加し、それらを接続して完全なテストケースフローを定義します。

Observation、Check、Action ブロックの設定

各インタラクショングループには、最大 3 つのブロックタイプが含まれます。

Observe ブロック (必須): 「Test started(テスト開始)」、「Message received(メッセージ受信)」、「Action triggered(アクション呼び出し)」などの期待されるシステムイベントを定義します。メッセージベースの観察の場合、メッセージの内容が一致するか確認するために次のいずれかを選択できます。

Contains : 実際のメッセージに指定されたテキストが含まれているかどうかをチェックします (部分一致)
Similar: セマンティックな類似性のための高度な比較を使用します (意味的一致)

※訳注ブログ翻訳時点では Observe ブロックは英語で受信されるメッセージをサポートしています。詳しくはドキュメントをご覧ください。

Check (チェック)ブロック (オプション): コンタクトジャーニーのその時点で、特定の属性に期待される値が含まれているか検証します。名前空間 (System、User defined、Segment Attributes など)、属性キー、期待値を指定して属性検証を構成します。

Action ブロック (オプション): 観察されたイベントに応答してフレームワークがシミュレートすべきことを定義します。

Mock resource behavior: 連携している Lambda 関数からの応答や、 Hours of Operation (オペレーション時間)、Queue(キュー)、Lex bot などのリソースをテスト用の代替リソースに置き換えることができます
Send instruction: 顧客入力をシミュレートします (DTMF トーン、テキスト発話、通話切断)
Test commands: 属性のログ記録やテストの終了などのユーティリティです

セルフサービスとキュー体験のテスト: 実践例

コンタクトセンターフローをテストすることで、顧客が一貫性のある信頼性の高い体験を受けられるようになります。このセクションでは、一般的なシナリオのテストについて説明します。既存の顧客が営業時間内に電話をかけてエージェントに到達するケースです。

顧客体験

フローは次のように動作します。

Lambda 関数が着信電話番号で顧客のタイプを確認します。
システムがウェルカムプロンプトを再生し、顧客にエージェントに到達するためには 1 を押すように求めます。
入力を受信した後、顧客は確認メッセージを聞きます。
システムは、エージェントが対応可能になるまで、保留音楽付きのキューに顧客を転送します。

テストケースの構築

体験を検証するために、3 つのインタラクショングループを持つテストケースを作成します。

テスト設定の構成

シミュレートするフローを選択し、顧客の識別情報として着信電話番号を入力します。

インタラクショングループ 1: テストの初期化

テストのセットアップと営業時間のオーバーライドを処理します。

Observe ブロック: イベントタイプとして「Test started」を選択します。テストが開始されるとすぐに実行されます。

Action ブロック: Hours of Operation リソースのオーバーライドを構成します。テストを実行するタイミングに関係なく、営業時間内であるかのようにテストが実行されます。フローの Hours of Operation リソースを選択し、フローで営業時間チェックが呼び出されたときに「営業時間内」になるように応答をモックするか、常に営業中の代替リソースを指定します。

インタラクショングループ 2: ウェルカムプロンプトの検証

ウェルカムプロンプトを検証し、顧客入力をシミュレートします。

Observe ブロック:

Event の種類: 「Message received」
Actor: 「System」(デフォルト。プロンプトはコンタクトフローから発信されるため)
Expected text: 「Press 1 to be connected to an agent(エージェントに接続するには、1 を押してください)」
Matching criteria: 「Similar」

Action ブロック: 顧客が 1 を押すことをシミュレートする「Send instruction」アクションを構成します。

Response type: 「DTMF Input」
Input value: 「1」

インタラクショングループ 3: キューの検証

キューへの配置を検証し、テストを終了します。

Observe ブロック: 期待される確認メッセージを指定します。「Thank you for calling. Your call is very important to us and will be answered in the order it was received.(お電話ありがとうございました。お客様からの声は重要です。順番におつなぎしますのでお待ちください。)」

Check ブロック: System 名前空間の「Queue Name」属性を期待値 (例: 「Agent Queue」) と照合して、正しいキューに転送されたかを検証します。

Action ブロック: 2 つの「Test commands」アクションを追加します。

Log data: テスト実行の詳細で分析するために関連する属性をキャプチャします
End test: テストケースの実行を終了します

テストの実行

すべてのインタラクショングループを構成した後、3 つのインタラクショングループが順番に接続されていることを確認します。その後、テストケースを保存して公開し、実行できる状態にします。

テストの実行と分析

テストケースの実行

テストデザイナーから テストを実行 ボタンで直接テストを実行するか、テストケース管理ページからバッチ実行できます。Amazon Connect は、インスタンスごとに最大 5 つの同時テスト実行をサポートし、追加のテストは自動的にキューに入れられます。主要な変更をテストして結果を取得してから、時間がかかる可能性のあるリグレッションテストを実行できます。

結果の監視とレビュー

テスト実行タブでテストの進行状況をリアルタイムで監視します。詳細な結果ページには、次のような詳細なビューを確認できます。

全体的なテストパフォーマンスを要約するセッションメトリクス
インタラクショングループの完了率と合格/不合格の統計、および合計シミュレーション時間
初期セットアップ、テスト開始、インタラクション、テスト完了を含む詳細なテスト実行ステップ
各 observe ブロック、check ブロック、action ブロックの実行の詳細

失敗したテストのトラブルシューティング

テストが失敗した場合、詳細な結果ページには、どの特定のインタラクションまたはブロックが失敗したかが示されます。次の情報を確認できます。

失敗した observe ブロックの期待されるイベントと実際のイベント
失敗した check ブロックの属性検証の詳細
アクション失敗の理由と試行された操作
完全な音声録音とトランスクリプション (有効な場合)

利用を始めるには

ベストプラクティス

整理: 「一般的な顧客 – 営業時間中 – エージェントへ転送」のように、明確でわかりやすいテスト名を使用します。タグを活用して、機能領域、顧客タイプ、優先度レベルごとにテストを分類します。
レジリエンス: 可能な限りプロンプトにセマンティックマッチングを使用して、わずかな文言の変更に対応できるようにします。時間依存のリソースをオーバーライドして、テストを実行するタイミングに関係なく一貫したテスト実行を定義します。
優先順位付け: 重要なカスタマージャーニーを最初に優先します。エージェント転送、一般的なセルフサービスシナリオ、営業時間外の体験です。最も重要な機能から常に検証していきます。
統合: テストをデプロイメントプロセスに組み込みます。コンタクトフローの変更をデプロイする前に関連するテストケースを実行して、顧客に影響を与える前に問題を発見します。

その他のテストシナリオの例

営業時間外のテスト: 営業時間外に電話をかけることをシミュレートするテストを構成し、適切なクローズメッセージとコールバックオプションを検証します。
セルフサービスの検証: 顧客が IVR メニューをナビゲートし、DTMF または音声でアカウント情報を提供し、期待される結果に到達することをシミュレートするテストを作成します。
認証された顧客体験: 認証された顧客に対する差別化された処理をテストします。優先キュー配置や専門エージェントルーティングなどです。
コールバックシナリオ: 待ち時間が長い場合のコールバックオプションを検証します。番号の収集と確認プロセスを含みます。

まとめ

Amazon Connect のネイティブなコールシミュレーション機能は、コンタクトセンター体験を検証および維持する方法を変革します。テストケースを迅速に作成し、オンデマンドに、あるいはデプロイメントプロセスの一部として実行し、継続的な改善を推進する洞察を得ることができます。

Amazon Connect インスタンスで今すぐこれらのテスト機能をお試しください。最も重要なカスタマージャーニーの重要なテストケースから始め、時間の経過とともにカバレッジを拡大し、テストダッシュボードを活用して進捗状況を追跡すれば、最適化の機会を特定できます。

詳細なドキュメントと実装のガイドは、Amazon Connect 管理者ガイドおよび Amazon Connect API Reference をご覧ください。

翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文はこちらです。

Amazon Web Services ブログ