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

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

会話型インターフェースは、顧客が自動化されたシステムとより自然にやり取りできる可能性を秘めています。仮想アシスタントからコンシェルジュのチャットボットまで、会話型インターフェースは顧客に利便性とパーソナライゼーションをもたらします。ただし、これらのメリットは、Amazon Lex プラットフォームや他の AWS サービスが提供できるテクノロジーだけでなく、優れた会話設計のベースがあることにも依存します。

会話型の設計手法は、会話インターフェースの目的・経験・インタラクションを定義する際の規則であり、あなたがプロダクトオーナー、設計リーダー、開発者のいずれであっても、会話型AI特有の設計プロセスと課題を理解することは有益です。このブログでは、設計をプロセスに組み込むことの価値と、コードによる具体的な手順と概念について説明します。

会話型の設計手法のビジネス価値

開発の基本として、設計を行うことにはどういった意味があるのでしょうか？ 技術的な課題にチャレンジしたり、Amazon Lex を使うことですぐに会話型アプリケーションの構築を開始したくなるかもしれません。しかし、このテクニカルファーストのアプローチは、顧客アプリケーションを開発する場合、考慮不足に陥る可能性があります。同様の設計原則は、会話型アプリケーションの成功に当てはまるだけでなく、あらゆるソフトウェアアプリケーションの成功にも当てはまります。顧客のニーズ・機能・インタラクションを最初に考慮すると、求められるカスタマーエクスペリエンスが明確に定義されます。この基本的な作業により、カスタマーエクスペリエンスが向上し、構築時の作業の重複が軽減されます。別の言葉で言えば、ことわざの“二回測って一回切る”（よく計画して注意深く準備を行うべき）になります。

会話型の設計手法をプロジェクトに取り入れるには、リソースと時間への先行投資が必要ですが、そのメリットとして、カスタマーエクスペリエンスの向上、明確に定義されたビジネスニーズ、および収益の向上が挙げられます。

このような先行投資を行うために社内でビジネスケースを提案する際には、次の点を考慮してください。

• 設計に重点を置くことで、事前の計画が可能になり、後で開発作業が重複する可能性を軽減できます。
• 設計ドキュメントを通じて製品またはユースケースについて共通の理解を深めることで、すべての関係者が提案された結果に同意できるようになります。
• サンプルダイアログからフロー図、さらにはプロトタイプまで、設計アセットを早い段階でユーザーに提示することで、コードが記述される前にテストや反復を行うことができます。
• 理想的な将来の状態を想定し、そこに到達するためのステップは、望ましい結果を得る機会を提供します。実用最小限の製品 (MVP) によって制約なく機能のバックログを作成できます。

ユースケースの特定

現在、会話型インターフェースは、銀行、医療、コマースなど、さまざまなセルフサービスシナリオで一般的です。ただし、インターフェースの設計はビジネスによって異なる場合があります。

通常、ボットとの最も優れたインタラクションは、短くシンプルで、かつ直感的なものです。これらのアクションは、アカウントを検索するための情報を収集する場合など、予測可能で反復的なパターンに向いている傾向があります。シンプルなインタラクションに慣れた後は、クリエイティブでより複雑なものにチャレンジする余地が常に出てきますが、会話型 AI の限界を考慮することも重要です。大量の説明を必要とするような複雑な要件は、自動化された会話型インターフェースほどは良いユースケースではないかもしれません。

成功するアプリケーションの種類を基本的に理解した上でユースケースを特定するには、まず顧客のペイン・ポイントとニーズを理解します。あなたの顧客は、あなたの商品やサービスを購入する人であったり、仕事のために社内サービスに利用している従業員かもしれません。

たとえば、顧客がエージェントと話すために長時間待たされていることに気づいた銀行などの金融機関を想像してみましょう。これは、カスタマーエクスペリエンスの低下やビジネスの損失につながる可能性のあるペインポイントです。

顧客として、新しい明細のリクエスト、紛失したカードの報告、別の口座への送金を手伝ってくれる人と話したいと思うかもしれません。こうした要求からカスタマーコールを適切なカスタマーサービス担当者に自動的にルーティングする機能が必要になる場合があります。または、より反復的で単純な要求を完全に自動化する機能が必要になるかもしれません。

このような目的はユーザストーリーと呼ばれることがあります。ユーザーストーリーは、ユーザーの目的と、その目的が満たされる必要性を表現する短い文章です。ユーザーストーリーは、顧客の目標とその重要性を定義します。それは「[User Type（種類）] として、[Need（要求）]を満たすために[Objective（目的）] を行いたい」というパターンに従うことができます。 例えば、銀行の顧客として口座残高を取得できるように自分自身を認証したい。カスタマーサービス担当者として顧客の懸念に対処する準備ができるように、電話が転送される前にその状況を知りたい、といった例が挙げられます。また、顧客が音声アシスタントと共有した情報をサービス担当者に提示することで、顧客が同じ作業を繰り返す必要がないようにする機能に繋がるかもしれません。

ユーザーストーリーの網羅的なリストを作成したら、重要度の観点からサポートするユースケースに優先順位を付けることができ、最も優先順位の高いものはさらに設計に進むことができます。

チームを構築する

会話型 AI アプリケーションを実現するには、多くの機能が必要です。プロジェクトの規模に応じて、これらの機能は非常に小規模なチームで開発する場合もあれば、さらに専門的なチームが必要な場合もあります。複数の分野にまたがるさまざまな才能を持っている個人も多いかもしれませんが、我々は複数の視点とアプリケーションへの貢献の観点からチームの必要性についてディスカッションしていきます。

話を単純化するために、会話型AIプロジェクトに貢献するメンバーを大きく4つの視点から考えることができます。

• ビジネス — オーナーまたはビジネスリーダー。通常、彼らはチームの他のメンバーと協力してプロジェクトの要件を定義します。利害関係者であり、プロジェクトを進めて行くために必要となる成果物では彼らの承認が最も重要です。
• マネジメント — プロダクト/プロジェクトマネージャー。彼らの最大の関心事はビジネス要件を追跡することであり、またプロジェクトを予算内かつスケジュールに合わせて管理することです。セキュリティとプライバシーの継続的なコンプライアンスを保証する責任がある運用者の管理も含まれます。
• 開発者 — 開発者または技術チームは、さまざまな利害関係者の要件を満たせるように合意された方法で設計を実装する責任があります。状況によっては、技術チームはパフォーマンス分析を実装する必要がありますし、QA チームは実装が設計基準を満たしていることを確認します。
• 設計 — 設計者の責任は、ビジネスの利害関係者が提供する要件を理解・解釈してエンドユーザーエクスペリエンスに反映することです。設計者は開発者にとって設計指針となる一覧の成果物（利害関係者の要望に添って作成されるシステムについての記述）を作成します。

設計者に必要な能力は、マルチタレントな個人が持っている場合もあれば、プロジェクトにとって最も重要な分野に特有の強みを持つメンバーで構成されるチームが提供する場合もあります。プロジェクトの規模に応じて1人の設計者または設計チームが必要になりますが、設計者が優れた会話設計を行うために必要となるバックグラウンドは1つではありません。これらの分野のうち2つ以上の分野に跨がるバックグラウンドを持つことは非常に重要です。

以下は、会話設計に特有のいくつかのタスクになります。大規模なプロジェクトでは、より専門的な役割が必要になる場合があります。

• 要件が明確ではないがユースケースに合わせることが必要な場合には、プロジェクトの開始時に設計を考えます。
• ユーザー調査。実際のエンドユーザーを代表する少数のユーザーからのインプットを取得・分析することは、アプリケーションの方向性を決めるのに役立ちます。
• スクリプトやコピーライティング。完璧な会話を構築できるように、例えばチャットボットの場合だと、企業のイメージに配慮しながら会話のニュアンスを考えます。
• ユーザーエクスペリエンスの設計では、すべての設計でユーザーの利用体験（エクスペリエンス）に与える影響（プラスとマイナスの両方）を考慮する必要があります。

プロジェクトのスコープに応じて役立つその他のリソースには、次のものがあります。

• 会話型AIアプリケーションにビジュアルコンポーネントが含まれるケースでは、ビジュアル設計が必要になる場合があります。例えば、レスポンスカードやボタンからアバターやインターフェースデザインなど全てのものがWebチャットにおけるユーザーの利用体験を向上できます。
• 会話型AI体験を生き生きとさせるために使用される聴覚アイコン(earcon)、音のブランド(sonic logs)、またはその他のオーディオを提供するには、サウンドデザインが必要になる場合があります。銀行ボットの例では、アカウントの詳細が登録されていることの確認として、または顧客が担当者に転送されていることを示すために、聴覚アイコン（earcon）を使用できます。
• ボットのパーソナリティの作成には、ブランディングの特徴をガイドラインに落とし込んだり、キャラクターの開発が必要になる場合があります。

システムパーソナリティの確立
会話型アプリケーションのパーソナリティは、ボットが使用する声のトーンや用語などの基本的な特性の組み合わせです。パーソナリティは、ユーザーの期待を設定するのに役立ちます。たとえば、金融または医療に重点を置いたアプリケーションへの信頼感を確立するために、フォーマルな話し方を選択する場合があります。同じようにコーチングや教育を支援することを目的としたアプリケーションには、動機付けしてくれるような話し方を採用するかもしれません。一方、会話のリスクが低いアプリケーションでは、カジュアルな話し方やまたはスラングが選択される可能もがあります。注意すべき重要な事は、システムパーソナリティはユーザーが人間とやり取りしているように思わせることでユーザーを混乱させることを意図していないことです。

銀行の例に戻ると、パーソナリティにアプローチする1つの方法としては、アプリケーションの目的とブランディング・ガイドラインを参照することが挙げられます。たとえば、Example 銀行 のブランディングガイドラインには、自信に満ちて、信用できて、洗練された、信頼できるなどのキャラクター特性が含まれています。また銀行が構築したい会話型アプリケーションの目的は、銀行業務を支援し、財務上のアドバイス、利便性、およびパーソナライゼーションを提供することです。

これらを組み合わせることで、会話のスタイルを定義するのに役立つ特徴を設定し、アプリケーションの使用目的をユーザーに自然な形で伝えます。

下記の 2 つの会話の違いについて考えてみましょう。

「こんにちは、アカウントサービスにお電話いただきありがとうございます。またお取引いただきありがとうございます。今日何をお手伝いしましょうか？」

「やあ友よ、電話してくれてありがとう。何が必要かな？」

2つ目はフレンドリーで1つ目と同様の内容が含まれていますが、銀行が必要とする信頼を想記させる話し方ではありません。ただし、小売業のカスタマーサービス用のボットではよりカジュアルな話し方が適していますし、共感はヘルスケア分野のボットに適しています。

まとめ

このブログでは、会話型AIのユースケースを特定する方法について説明し、システムのパーソナリティの作成に触れました。このシリーズの次回のブログでは、会話型 AI アプリケーションをゼロから設計するための戦術的なガイダンスを提供します。銀行業務の例を使用して、会話の設計プロセスにおける以下の各ステップを確認し、その過程で適切な設計ドキュメントを作成します。

• 正常パス（happy paths)のスクリプト作成
• フローのダイアグラム設計
• ダイアログの修復
• 対話モデルの定義
• プロトタイピング
• テスト

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

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

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