チャネル固有の考慮事項

デジタル・アシスタントの設計時に考慮して計画する必要があるチャネル関連の事項を次に示します。

「チャネル」という用語は、メッセージング・プラットフォームと、ボットがユーザーと対話するために使用するメッセンジャ・クライアントを網羅しています。チャネルの考慮事項は、デジタル・アシスタント・プロジェクトの計画フェーズ中およびデジタル・アシスタントの実装時に行う必要があります。

Oracle Digital Assistantは、Facebook、MS Teams、Slack、Web、iOS、Android、SMSなど、多数のチャネルをネイティブでサポートしています。ネイティブ・サポート・チャネルの場合、デジタル・アシスタントは、受信メッセージ・ペイロードのメッセージ変換をデジタル・アシスタントで使用される形式(またはその逆)に処理します。開発者は、デジタル・アシスタントでチャネル構成を作成し、必要なチャネル固有の情報を提供するだけで済みます。

デジタル・アシスタントでネイティブ・サポートがないチャネルは、Webフックを介してデジタル・アシスタントに接続できます。これは、メッセージを変換およびキューに入れるために記述する必要があるカスタム・コードで使用する汎用構成です。

チャットボットを設計する際のチャネルの制限の検討

通常、すべてのチャネルが同じことをしますが、それぞれにチャネル固有の機能と制限があります。一般的な制限には、値のリストまたはカルーセルのカードに表示できる処理可能アイテムの数、またはカードのレイアウトが含まれます。たとえば、Slackでは垂直カード・レイアウトのみがサポートされます。

その他の違いは、メッセージの書式設定と強調表示のサポートです。たとえば、Webチャネルでは、HTMLマークアップおよびスタイルシートを使用してメッセージを書式設定できますが、他のチャネルでは書式設定できません。

ノート

ターゲットとするチャネルおよび必要な書式設定の範囲によっては、メッセージでHTMLマークアップを使用できる場合があります。この方法を使用する場合、メッセージが各チャネルに送信されると、マークアップは自動的にチャネル固有の形式に変換されます。チャネルでのリッチ・テキスト形式を参照してください。

戦略として、次のものから選択できます。

  • 単一のチャネルのボットを設計します。

  • 最も一般的な分母用にボットを設計します。

  • すべてのチャネルでボットを設計し、いくつかの最適化。

1つのチャネルにボットを設計

最も持続可能な解決策は、デジタル・アシスタントを1つのチャネルのみに設計し、他のチャネル(将来オプションになる可能性もある)を無視することです。このソリューションは、最低限のサステナブルであることに加えて、シングルユース製品を設計しているため、最も推奨されません。

このようなアプローチには、概念実証のように、迅速に作成する必要があるユースケースがある場合があります。ただし、本番環境にリリースするボットについては、他の2つのアプローチのいずれかを検討する必要があります。

最も高い共通分母のボットを設計します

ボットでサポートする必要があるチャネルがわかっており、各チャネルがサポートできる実装に合意している場合は、開発作業がほとんどない複数のチャネルで同じように動作するデジタル・アシスタントを作成できるため、遅延がほとんどありません。この欠点は、一部のチャンネルでは、スポーツカーを運転しているように感じるが、6つのギアのうち最初のものしか使わないということだ。

このオプションは、チャットボットについて概説した目標に最適化されたチャネル・エクスペリエンスを必要としない場合に有効です。

すべてのチャネルにボットを設計し、数台に最適化

このオプションに使用するもう1つの用語は、「適応設計」または「適応ボット・レスポンス設計」です。Webアプリケーション開発の同じパラダイムと同様に、すべてのチャネルで機能するようにチャットボットを構築し、ユーザー・エクスペリエンスを最適化するために変更を適用します。アダプティブ・ボット・レスポンス設計の実装には時間がかかりますが、可能な限り最高のユーザー・エクスペリエンスを確保するとともに、MS Teamsチャネルでアダプティブ・カードなどのチャネル固有の機能を活用できます。

この設計戦略を実装するには、次のツールを使用できます。

  • チャネル固有のメッセージを表示するためにICUメッセージ形式を使用するリソース・バンドル。

  • チャネル固有の会話フローに分岐するスイッチ・コンポーネント。

  • 共通レスポンス・コンポーネントに表示されるプロパティで、使用されるチャネル・タイプに基づいてレスポンス・アイテムを表示または非表示にします。

  • ダイアログの${system.channelType}式はエンティティにフローし、組込みダイアログではチャネル固有のメッセージを表示します。カスタム・コンポーネントを使用してボット・レスポンスをレンダリングする場合、チャネル・タイプはコンテキスト・オブジェクトの関数としても使用できます。

  • 共通レスポンス・コンポーネントおよびカスタム・コンポーネント。チャネル・カスタム・プロパティをサポートし、MS Teamsチャネルのアダプティブ・カード・ペイロードなど、チャネル固有のプロパティを送信するために使用できます。

  • Oracle Digital Assistantに組み込まれた最適化で、プラットフォームで使用できない機能に最適な代替機能を自動的に使用します。たとえば、Slackの水平カード・レイアウトは、自動的に垂直カードに変更されます。

チャネル固有のボット・レスポンスの実装

頻繁に監視するが推奨しない実装の1つは、リソース・バンドル参照を使用するかわりに、テキスト・メッセージをUIコンポーネントに直接書き込むことです。

2つ目のパターンは、開発者がUIコンポーネントのテキスト・メッセージ・プロパティに直接追加するか、リソース・バンドルに格納するメッセージにHTMLマークアップを追加することです。HTMLマークアップを使用すると、ボットのチャネル・サポートが、マークアップをサポートするチャネルに制限されます。

マークアップは使用できますが、ロックインしない方法で使用することをお薦めします。次に、Oracle Digital Assistantのリソース・バンドルにICUメッセージ形式を使用してチャネル・ロックインを回避する例を示します。

{channelType, select,
  web {<b>This message uses HTML markup to display in bold</b>}
  slack {*This message uses markdown to display in bold*}
  other {This message is for all other channels}
}

リソース・バンドルでメッセージを参照するには、ダイアログ・フロー、エンティティまたはスキル構成で次の式を使用します:

${rb('the_key_name','channelType',system.channelType)}

チャネルの考慮事項のチェックリスト

  • ☑すべての人に合わせて設計し、いくつかの最適化を図ります。
  • ☑複数のチャネルをサポートする場合は、適応設計を検討してください。
  • ☑ すべてのボット・メッセージにリソース・バンドル文字列を使用します。
  • ☑ICUメッセージ形式を利用して、チャネルへのメッセージに適応するリソース・バンドルを構築します。

さらに学ぶ