翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Connect Customer での動的でモジュール式の IVR エクスペリエンスの基盤を設計するためのベストプラクティス
<a name="introduction"></a>

*Ayesha Borker および Nicholas Pung、Amazon Web Services (AWS)*

*2023 年 8 月* ([ドキュメント履歴](doc-history.md))

テクニカルアーキテクト、デベロッパー、ビジネスチームは、Connect Customer を使用してクラウドベースのコンタクトセンターに移行する際に顧客に提供する自動化されたセルフサービスエクスペリエンスを再考する機会があります。

ビジネスチームは通常、機能を追加すると同時にセルフサービスエクスペリエンスをよりパーソナライズしたいと考えます。テクニカルアーキテクトと開発者は主に、冗長性の削減、迅速な変更と柔軟性の実現、反復的なプロセスのモジュール化、メンテナンスのオーバーヘッドの削減に主眼を置きます。

このガイドでは、テクニカルアーキテクトに向けて、モジュール式かつ動的な自動音声応答 (IVR) アプリケーションの基本設計に使用できる一連のベストプラクティスを提供します。ここでは IVR システム (つまり音声テクノロジー) の例を示しますが、同じ概念は他のあらゆるチャネルに拡張できます。このガイドでは、Connect Customer フローとモジュールを使用して、モジュール式のスケーラブルな IVR 設計を作成することに重点を置いています。IVR アプリケーションに自然言語 (NL) 機能を追加できる Amazon Lex は扱いません。

## 概要
<a name="overview"></a>

従来の IVR エクスペリエンス設計の方法は固定的で複雑です。多くの場合、組織はさまざまな言語、デプロイ環境 (開発、テスト、本番環境など)、国、事業部門 (LOB) ごとに個別のエクスペリエンスを管理します。プロンプトは人間による音声収録によって作成され、ハードコードされたスクリプトでアップロードおよび参照されます。このことが、特に緊急事態や時間的制約がある場合に、アナウンスをリアルタイムで変更または更新するプロセスを困難にしていました。アプリケーションがそのように分離されていると、一般的なユースケースが繰り返され、管理も重複することになります。よくある例としては、IVR システムでの支払いの受け取りや、取引後の SMS の送信などがあります。データベース、顧客関係管理 (CRM) ソリューション、またはその他のサードパーティーシステムへのバックエンド統合は多くの場合ハードコードされているため、変更があると複数のアプリケーションに手動でレプリケートする必要があります。

こうしたモノリシックアーキテクチャ設計は、過剰な管理プロセスと管理のオーバーヘッドにつながり、イノベーションを妨げます。小さな変更でも複数の依存関係をまたいで実装しなくてはならず、開発者の時間が奪われてアジャイル開発のプロセスに従うことが困難になります。多くの企業にとってこの複雑さが負担となり、変更管理をするのにプロフェッショナルサービス組織や外部コンサルタントに頼らなくてはならず、結果として通常の更新のターンアラウンドタイムが増加します。複雑で時間のかかる開発サイクルを伴う複雑なアーキテクチャによってコストが増大します。

このガイドでは、冗長性をなくし、変更管理プロセスを合理化する IVR アプリケーションの基本的アーキテクチャに焦点を当てます。このアーキテクチャによって開発者はメンテナンスの負担を減らしてイノベーションを促進し、企業はアジリティを高めることができます。

**目次**
+ [IVR アプリケーションのお客様の機能を接続する](features.md)
+ [IVR の設計原則](design-principles.md)
+ [ユースケースの例](example.md)
+ [結論](conclusion.md)
+ [リソース](resources.md)