Amazon Lexにおける会話設計の基本（パート2）

このブログは2021年10月12日に Claire Mitchell、Rosie Connolly、Nancy Clarke（AWS Professional Service）によって執筆された内容を日本語化したものです。

新しい Amazon Lex アプリケーションを計画する際には、以下の会話設計のベストプラクティスを参考にすることで、チームは優れたカスタマーエクスペリエンスを生み出すことができます。前回のブログでは、優れた会話設計を作成するための基本について説明しました。優れた会話設計のビジネス的な価値を探り、チーム構築のヒントをいくつか紹介し、また、会話型インターフェースの基盤を構築するためにユースケースを特定することの重要性についても説明しました。シリーズ全体を通して強調したいのは、顧客を設計プロセスの中心に置くことでカスタマーエクスペリエンスを向上させることが重要であることです。

この記事では、私たちの基盤を確立した上で、ハイレベルな設計のベストプラクティスと、会話型インターフェースを設計する際にそれをどう使うかについて説明します。まず設計プロセスの個々のステップについて説明し、要件を収集し、音声とテキスト設計の違いについて考えるためのヒントを提供します。次に、サンプルダイアログの作成、プロンプトの記述、エラーの処理、AI エクスペリエンスの文書化など、設計プロセスの個々のステップについて説明します。これらのステップは、プロジェクトの設計にフォーカスを当て、リリースまでに必要となる作業を効率化します。全体を通してリテールバンキングの例を使用しますが、Amazon Lex のセルフペースワークショップを使用して、独自のボットを作成することもできます。

設計前にすべての要件を収集する

優れた設計プロセスは、設計のない状態から始まります。すべての主要な関係者を同じ部屋に集め、時間をかけてユースケースについて話し合います。これには、カスタマーエクスペリエンス（CX）チーム、ビジネスまたはプロダクトオーナー、開発者、SME(Subject Matter Expert)、カスタマーサービス担当者（CSR）、コンタクトセンターの管理担当が含まれます。ビジネスと顧客のニーズについてさまざまな視点を持つ人材が必要です。こうしたメンバーと協力することで顧客を成功させるための要件を全て集めることができます。多様な利害関係者により、あなたは将来の設計についてさまざまな視点を持つことができます。

チームに対する質問を考えてミーティングを準備します。「ハッピーパス」（顧客が比較的スムーズにシステムを利用するパス）と、顧客が問題に遭遇する可能性のあるポイントの両方を考慮します。例えば、アプリケーションが支払いを処理する場合、顧客が利用可能な時間外に支払いを行うとどうなるかについて話し合います。顧客の身元を確認するためのさまざまな方法（生年月日、個人識別番号、郵便番号など）を考慮し、認証に失敗した場合にいつ人間のエージェントに転送するかを検討します。

大多数の顧客に対して理想的なカスタマーエクスペリエンスを作りたいものです。残りの顧客は人間のエージェントが対応した方がよい特徴的な要件を持っているかもしれません。すべての顧客のニーズに合わせて設計しようとすると、システムは管理不能になります。

設計を開始する前に全体的なエクスペリエンスを明確に理解しておくと、試行錯誤を減らしてリリースまでの時間を短縮できます。また、開発リソースの利用時間も節約でき、プロジェクトのコストを節約できます。

音声とテキストの設計

設計する前に、顧客がアプリケーションをどのように操作するかを知っておく必要があります。彼らは話すのか、キーボードを打つのか、またはその両方なのか？ 音声とテキストの設計にはさまざまな課題があります。

まずは声で情報を提供することについて考えてみましょう。音声の設計は順番に行われる必要があります。なぜなら、顧客は情報の間を移動したり、聞いた事を時間をかけて理解するといったことができないからです。この順番は、顧客が聞く言葉が顧客にとって論理的な順序で発生しなければならないことを意味します。さらに、一度に多くの情報を顧客に提供すると認知的な過負荷が発生し、つまり一度に与える情報が多すぎるため、顧客はすべてを覚えていない可能性があります。

代わりにテキストインターフェースを使用すると、顧客は時間をかけて読んだり理解したりすることができます。また、情報を取り込むときにスキップすることもできます。しかしながら、認知的な過負荷はテキストでも起こりえます。システムに非常に長い応答メッセージを配信させたくありません。1 つのメッセージの長さは、顧客がスクロールせずに読める量を超えないようにしてください。複数の吹き出しやメッセージグループを使用するのは有効なテクニックですが、使い過ぎないようにしてください。アプリケーションが一度に複数のメッセージを送信して顧客がスクロールしなければならなくなると、カスタマーエクスペリエンスは低下します。

ユーザー入力の認識に関しては、音声とテキストは異なるパスを持ちます。音声の場合、システムは最初に自動音声認識 (ASR) システムを使用して音声をテキストに変換します。次にテキストは自然言語理解 (NLU) で処理されます。テキストベースのシステムでは、入力された単語は NLU に直接送られます。音声で追加されるステップはさらに困難を伴う場合がありますが、設計でこうした要素を考慮することができます（エラー処理に関する後のセクションを参照）。

単一のアプリケーションで、音声とテキストの両方を使用することを検討できます。顧客は異なるなプレゼンテーション方法で情報を受け取る必要があることに注意してください。たとえば、テキストウィンドウのリスト形式は音声でうまく読み取れません。支払概要の詳細を説明する段落は音声で理解できますが、テキストでは重要な詳細を見つけにくい場合があります。セッション属性を使用することで、Amazon Lex が顧客に正しい応答を提供するように設定できます。これにより、音声またはテキストを利用する顧客を別々にターゲットにしながら、同じインタラクションフローの構造を持つことができます。

サンプルダイアログを作成し、整合性を確認する

すべての要件を収集し、インタラクションタイプを決定したら、次は設計に進みます。ユースケース (顧客がアプリケーションを使って実現するタスク) から、サンプルダイアログを作成できます。これらのダイアログは、顧客と利害関係者がアプリケーションをどのように操作するかをよりよく理解するのに役立ちます。事前に収集した要件を使用して複数のシナリオを作成します。ダイアログには、ユースケースごとに少なくとも 1 つのハッピーパスと、エラーが発生しやすい会話のやり取りを含める必要があります。ただし、これらは考えられるすべてのフローまたはエラーシナリオを網羅したドキュメントではなく、さまざまな顧客とのやり取りを表現するハイレベルなスナップショットです。こうしたサンプルを記述したら、利害関係者に見てもらいます。繰り返しますが、要件の収集に関与したすべての人に参加してもらうことが理想的です。全員が参加できない場合は、主要なCX関係者を招待し要件の完全なリストを用意してください。

引き落し講座を変更する顧客向けのサンプルダイアログを示します。

初期段階でダイアログを見直すことには、2 つの利点があります。まず、すべての要件を理解し、把握していることを確認できます。その他の設計を行う前に、必ず確認するようにして下さい。次に、さまざまな視点から作業を見直すことができます。時間をかけてワークショップ形式で様々なアイデアを出して、デザインを改善してください。

サンプルダイアログでビジネス側から承認を得た後は、会話の台詞が期待している応答を引き出していることを確認する必要があります。明確で簡潔な台詞を考える事は、自然に聞こえる直感的な会話インターフェースを作成するための最も重要なステップです。

会話における台詞を考える

サンプルダイアログの最初のドラフトは、最終的なバージョンである必要はありません。これは出発点であり、すべての良い文章は複数のドラフトを経るものですので、会話における台詞を検討するためのワーキングセッションを実施します（必要に応じて複数回実施）。この時点での参加者は主要CXの利害関係者に限定します。これらのセッションでは、顧客が見たり聞いたりする台詞だけでなく、顧客の反応にもフォーカスする必要があります。

最初の最も重要な目標は、あいまいさを避けることです。あいまいさは、「続行しますか、キャンセルしますか、やり直しますか？」など、さまざまな形で発生する可能性があります。 この質問はあいまいなようには見えませんが、音声では、「続行しますか…」と聞こえ、ボットが話し終える前に「はい」と返答できます。もしアプリケーションが応答として「はい」を期待していない場合は、問題が発生する可能性があります。結局のところは、顧客がどのように対応するかを考えることにフォーカスすることが目標です。

次に、できるだけ簡潔な情報を顧客に提供します。顧客を認証する際には、認証が成功したことを知らせたい場合があります。複数の選択肢が考えら、アプリケーションは冗長なメッセージを返すことができます：「ありがとう。入力された情報を顧客のアカウントに登録されている情報と照合しました」 。もしくは、アプリケーションは簡潔に応答することもできます：「ありがとう」。 または、応答をこの2 つの中間にすることもできます。ブランドとアプリケーションのパーソナリティに最も合致するものを選択すべきでしょう。しかし、簡潔な回答に対する長くてカッコの悪い応答は、AIインターフェースが会話的ではなく機械的に聞こえてしまう理由の1つになります。顧客が AI とやり取りしているという事実を隠したいと思っているわけではない一方、それを人間との会話に感じさせることも可能でしょう。

第三に、顧客に知っておくべき情報のみを提供します。例えば顧客が電話をかけた場合、アプリケーションは顧客の電話番号を認識しません。顧客に「あなたが電話している電話番号を認識できません」と伝える必要はありません。もしかすると顧客は番号が一致しないことを知っているかもしれません。顧客が電話番号で識別される場合は、「アカウントに登録した電話番号は何ですか？」と尋ねることができます。 システムは必要な情報を収集しようとしたときに、このインタラクションを通して電話番号が一致しないことを認識できます。

さらに、言葉遣いは自然な会話のやり取りのように聞こえるべきで、フォーマルな文章のようにするべきではありません。厳密な文法規則に従わない言い回しを使っても大丈夫です。例えば、自然なネイティブの米国英語では、人々は定期的に不定詞を分割し（「to not go」）、前置詞で文を終わらます（「Whos’s that going to?」）、また接続詞で文章を始めます（「And where do you think you’re going？」）。短縮形を使って下さい（「can’t」）、それが文法的に正しくなくても短縮形を使用してください（たとえば、「what are」を音声で表現する場合の「what’re」）。ただし、それがブランドとシステムのパーソナリティと矛盾する場合を除きます。従来の書き言葉では受け入れられない場合でも、一般的な音声パターンを使用すると、アプリケーションはどの言語や方言でもより自然で会話的に聞こえるようになります。

最後に、柔軟性を高めましょう。下書き形式で台詞を作成したら、アプリケーションがテキストベースであっても、それを声に出して話してください。それは自然に聞こえますか？ チームが Amazon Polly の音声を使用している場合は、Amazon Polly コンソールにサインインして台詞をテストします。自然に聞こえない場合は、文言を更新します。SSML マークアップを使用して、読み上げる速度、スタイル、およびその他の属性を変更することもできます。この慣習を経ると、言葉遣いの変更につながる可能性があります。法務部門に文言の確認が必要な場合は、承認を受ける前に文言をテストします。そうすれば、法的な承認を2回受ける必要がなくなります。

その他のヒントについては、私達のブログ「ビルトインスロットとカスタムスロット用の優れた台詞を書く」をご覧ください。

エラーを処理する

顧客が最新の犬のおもちゃを銀行用のボットに説明し始めるたらどうなるでしょうか？ 顧客が最低支払額より少ない金額を支払うことを望んでいる場合はどうなりますか？

可能なら、これらのシナリオを考慮する必要があります。最初の例では、定義されたインテントと一致しない顧客の入力に相当します。これらのフレーズは、「一致しない」、つまりアプリケーションの NLU がトレーニングしていないフレーズとして扱うことができます。Amazon Lex では組み込みのフォールバックインテントを使用できます。フォールバックインテントにより、カスタマーはインテントを再び提供しようとします。フォールバックインテントの台詞を記述して、アプリケーションが処理できる応答を顧客が提供するように誘導します。

「一致しない」エラーシナリオでは、さらに考慮する必要があります。顧客が失敗するような状況を色々と想像できると思います。こうしたシナリオを説明するために、次の点を考慮してください。

• 顧客はどこで失敗する可能性があるか
• 顧客との会話を成功させるために、アプリケーションはどのようなHelpを提供できるか
• どのようにして顧客が無限のHelpループ（何を入力してもHelpメッセージが表示されてしまう状態）に巻き込まれないようにするか

最低支払額の場合、顧客が低い金額を提示した時にどのような台詞で応答しますか？ フローを失敗させる前に、顧客に何回試行させますか？ それらの顧客を転送するか、切断するか、またはメインメニューに戻しますか？ これらは全てあなたが尋ねるべき質問の例です。

すべてのエラーメッセージで、アプリケーションの文言がブランドとアプリケーションのパーソナリティに一致していることを確認する必要があります。そうしないと、顧客はこれらの経験が不快であると感じるかもしれません。

エラー処理を丁寧に作り込むことで、カスタマーエクスペリエンスが向上します。より多くの利用者が利用を継続し、途中で止めてしまう利用者を減らすことができます。「エラー処理」という用語は困難を意味しますが、それよりは顧客を支援する道具と見なすべきです。結局のところ、あなたはカスタマーエクスペリエンスを向上させたいと思っており、顧客はできるだけ困難なくフローを利用したいのです。

コンテンツの文書化および管理

ここまで、サンプルダイアログを作成し、エラーシナリオを決定し、利害関係者の承認を得ました。残りはドキュメンテーションです。

まず、フローダイアグラムを作成します。これは、顧客とのインタラクションのより詳細な流れを表現します。フローダイアグラムには、特定のエラー処理シナリオに加えて、すべてのハッピーパスが含まれている必要があります。必要に応じて、インタラクションの一部またはすべての文言を含めるか、フロー内の図形にラベルを付け、対応するドキュメントに関連付けることができます。

以下に、入金確認のフローダイアグラムを示します。

また、すべての台詞の一覧も用意する必要があります。これをキーと値のペアとして設定します (ここでは、キーは台詞のラベル、値は台詞の文言です)。動的な 応答に対しては複数のバージョンの台詞が必要になります。これらの台詞のラベルは、それぞれの応答に対してどのバージョンの台詞が使われるかを示す必要があります。

アプリケーション内の台詞の一部または全部の文言について、コピーライティングや法律などの外部からの承認が必要な場合は、それを実施しましょう。この時点でアプリケーションフローは文書化され、開発チームはハードワークしています。ですので、文言を変更するために手戻りがあったとしても、開発時間には大きな影響はないでしょう。

最後に、ドキュメントに変更ログが含まれていることを確認します。これは、加えられた変更とその変更がドキュメント内でどのようにマークされているかを記述するセクションまたはページです。ログには、誰が変更を加えたか、新しい文書がリリースされた日付、変更の簡潔な説明、場合によっては変更への内部リンク、および変更を示すために使用された強調表示または色づけが含まれます。複数のユーザーが同時にドキュメントで作業している場合は、他の人の変更を上書きしないように、バージョン管理を行うようにしてください。

まとめ

会話型 AI アプリケーションを設計する際は、会話設計におけるここで述べたような特徴を念頭に置いてください。これらのベストプラクティスにより、顧客を満足させる効率的な方法でアプリケーションを設計できます。開発サイクルを合理化して、リリースまでの時間を短縮することができます。また、時間の経過とともにアプリケーションが育っていくと、参照と更新のために使用される経験値が十分に文書化されます。

シリーズの最後のブログでは、最初の 2 つのブログから基本的な要素を取り出し、それを Amazon Lex に適用する方法について説明します。具体的には、対話モデル、プロトタイピング、テスト、アプリケーションのチューニングについて説明します。

AWS プロフェッショナルサービスと幅広い AWS パートナーネットワークは、ここで紹介したようなプロセスを通じてお客様とお客様のチームを支援します。コンサルティングやアドバイスのみが必要な場合でも、デザイナーの支援が必要な場合でも、我々の目標はあなたとあなたの顧客にとって最高の会話型インターフェースを実現できるようにすることです。

Amazon Lex の詳細とAWSでの会話型インターフェース の利用については、Amazon Lex のリソースをご覧ください。

翻訳は ソリューションアーキテクト北嵐が担当しました。原文はこちらです。