アプリの UI ではなく会話型 UI
RBM エージェントは効率的で具体的なタスクをユーザーに提供するのに適している 直接やり取りできます優れた設計のエージェントはインタラクションを維持 焦点を絞り、明確でわかりやすく、自然な会話のように構造化されています。
エージェントはアプリやウェブページの視覚的な UI には依存できないため、 試みます。エージェントは慎重に策定された ユーザーとやり取りする方法を言葉で手がかりで導き、 適切なエラー処理を行う必要があります。
また、電話ツリーやユーザーに依存するインターフェースを模倣しないでください。 アクションを表す数値で応答しますユーザーは エージェントとやり取りする際と同じように、 できます。
会話型 UI の詳細については、会話型 UI とその理由をご覧ください。 事項。
デバイスの機能を確認する
ユーザーとの会話を開始する前に、ユーザーの デバイスが RCS メッセージを受信できることを確認します。メッセージを送信 ケーパビリティ リクエスト デバイスの機能を特定し、エージェントの対応を調整できる 必要があります。ユーザーのデバイスでサポートされている方法でのみユーザーとやり取りする。もし ユーザーのデバイスが RCS 対応でない場合は、フォールバックの通信方法を設定してください 他のテクノロジー（SMS など）と やり取りできます
会話を開始する
会話の冒頭で、エージェントができることについてユーザーが期待することになる できます。会話は、エージェントの個性を見せ、 ユーザーが関心を持っている情報を最初に掲載し、エージェントの概要を共有する できます。エージェントとやり取りする方法を明確にし、 会話を続けます。
メッセージの最大サイズを尊重する
RBM が RBM メッセージとメディア ファイルの最大サイズに上限を実装 メッセージに含めることができる名前です。これらの機能については メッセージを送信する できます。
良いリズムを保つ
会話でさまざまな種類の情報を使用することで、ユーザーのエンゲージメントを維持し、 ただし、ユーザーを圧倒しないように注意してください。維持 メッセージは魅力的でわかりやすい長さに 表示して ユーザーは全体像を把握できます メッセージを画面に表示できます。画像とリッチカードは そのため、ユーザーがどこまでスクロールすればよいか、 メッセージ全体を読むことができます。
メールを整理する
複数のメッセージを順番に送信する場合は、ユーザーが受信した
並べ替えることができます。メディアを含むメッセージなど一部のメッセージは、
他のメッセージよりも処理に時間がかかります（テキストのみのメッセージなど）。宛先
ユーザーが送信した順にメールを受信し、
メッセージに対して 200 OK レスポンスを受信してから、次のメッセージを
あります。
200 OK レスポンスは、RBM プラットフォームがメッセージを受信したことを確認します。
ユーザーがメッセージを正しい順序で受信できるようにすることです。この操作を
200 OK の応答を待ってから次のメッセージを送信します。場合によっては、
見ていきます
受信メールの重複を確認する
ユーザーからの着信メッセージを確認して返信する際は、
messageIdして、お客様がまだ
返信しました。
分散システムでは、メッセージを 1 回まで送信するか、 少なくとも 1 回は失敗します
- [1 回限り]システムがメッセージを 1 回送信し、 その途中でネットワークエラーや通信エラーが発生した場合、 受信できない場合があります。
- 「1 回以上」送信すると、システムからメッセージが送信される 受信できる場合があります。ネットワークに接続されていても、 通信エラーなどです
Google Cloud Pub/Sub では、「少なくとも 1 回」というありませんその結果
重複したメッセージがある場合は、Google Chat で
トラッキング messageId 文字列。すでにメッセージを受信している場合は
同じ名前で受信した他のメッセージを無視して
messageId。
明確で一貫性のあるメッセージを記述する
ユーザーが理解できる魅力的でわかりやすいメッセージを送信します。良好 メッセージ テキストがユーザーに返信を促し、スタイル、書式、 ユーザーの信頼を築きます。
メッセージ テキストを作成する際は、次のベスト プラクティスに留意してください。
- デッドエンドを回避各返信文の候補は、 会話スレッドを作成します。
- 必要に応じて、ユーザーを「自分」ではなく「あなた」と呼んでください。
- タイトルやラベルには、語頭を大文字にせず、文章を大文字にします。たとえば 「アカウント詳細情報」ではなく「アカウントの明細書」。
- 文を短くするよう心がけてください。「そうだ」より会話調で表現されます。
- 感嘆符は控えめに使う。
- シリアルカンマを使用します。たとえば、「A、B、C」ではなく「A、B、C」とします。
- 数字は数字で記述します。例: 「1, 2, 3」ではなく「1, 2, 3」。
ユーザーがメッセージを受け取りたくない場合を尊重する
ユーザーが Gmail からのメールの受信停止を希望している場合 お客様の選択を尊重する必要がありますエージェントは、ユーザーが 「STOP」と返信適切に対応できますエージェントは、 ユーザーがメールの受信停止を希望していることを伝えたり、 欲求を伝えるために使用できるあらゆる言語が含まれます。
拠点とする国の法律とベスト プラクティスを参照して、 STOP などの必須コマンドに応答することもできます。たとえば、 CTIA ベストプラクティスを確認します
お客様をサポートする
エージェントはユーザーからのヘルプ メッセージに対応し、以下について説明する必要があります。 向上します定型返信文のリストなどシンプルなもの ユーザー エクスペリエンスの低下を招くことがあります。 有用なものに変換します。
指数バックオフを使用して再試行を実装する
API を呼び出す場合、インフラストラクチャが原因で呼び出しが失敗することがあります。 問題、サービスの過負荷、QPS 上限、その他のエラー。安全に復旧するには 指数バックオフによる再試行を実装できます。
指数バックオフで再試行を使用すると、インフラストラクチャが 次のとおりです。
- 失敗した API 呼び出しを特定します。
- 最初の待機時間と再試行の最大数を設定します。
- 待機時間の間一時停止します。
- API 呼び出しを再試行します。
API 呼び出しのレスポンスを評価します。
- 成功した場合、ワークフローの次のステップに進みます。
- 失敗した場合は、待機時間を長くしてステップ 3 に戻ります。
- 最大再試行回数を超えて失敗した場合は、不合格状態になります。
理想的な待機時間と理想的な最大再試行回数は、ユースケースによって異なります。 インフラストラクチャのレイテンシ要件に基づいてこれらの数値を決定します。 ワークフローを合理化します
リッチカード
リッチカードを使用すると、メディア、テキスト、候補を 1 つのメッセージにまとめることができます。として リッチカードの要素はメディアだけではありません アクションの提案機能は、必ずスタンドアロンのリッチカードと一緒に使用する必要があります。
縦向きのリッチカード
縦長のリッチカードでは、カードの上部に横長のメディアが表示されます。横長タイプ アスペクト比は 2:1、16:9、7:3 のいずれかにしてください。
ユーザーにメディアを送信するときは、ユーザーのリソースを尊重する必要があります。 横向きのメディアの比率が 2:1 の場合の最適な解像度は次のとおりです。 1,440×720 ピクセル（画像の推奨ファイルサイズは最大 2 MB） 動画の場合は 10 MB です。メディアのサムネイルに最適な解像度は次のとおりです。 770x335 ピクセル（推奨ファイルサイズ 40 KB、推奨サイズ） サイズの上限は 100 KB です。
横向きリッチカード
横向きのリッチカードでは、画面の左側または右側に縦向きのメディアが表示されます。 。縦向きのメディアのアスペクト比は 3:4 にしてください。
ユーザーにメディアを送信するときは、ユーザーのリソースを尊重する必要があります。 縦長のメディアのアスペクト比が 3:4 の場合の最適な解像度は次のとおりです。 768x1024 ピクセル（画像の推奨ファイルサイズは最大 2 MB） 動画の場合は 10 MB です。メディアのサムネイルに最適な解像度は次のとおりです。 250×330 ピクセル（推奨ファイルサイズ 40 KB、推奨サイズ） サイズの上限は 100 KB です。
リッチカード カルーセル
リッチカード カルーセルは、コンテンツやさまざまなオプションの閲覧に最適ですが、 複数の項目が比較、 データプランやデバイスなどですカルーセルの最初の項目が最適な選択である 最適な選択である理由を説明します。 ユーザーに伝える必要があります。
カルーセルの下に表示される候補ワードで、会話を進めたり、方向転換したりします。 候補ワードでは、カルーセル内にリストされている選択肢を繰り返さないでください。 は、カルーセルに表示されるアイテムの選択ツールではありません。
リッチカード カルーセル内のメディア
リッチカード カルーセルでは、リッチカードの上部に横長のメディアが表示されます。 カルーセル内の横向きメディアのアスペクト比は 4:3 にしてください。
ユーザーにメディアを送信するときは、ユーザーのリソースを尊重する必要があります。 メディアのアスペクト比が 4:3 の場合の最適な解像度は次のとおりです。 960x720 ピクセル（画像の最大サイズは 1 MB、5 MB 以下） 使用できます。メディアのサムネイルの最適な解像度は 605x452 ピクセルです 推奨ファイルサイズは 40 KB、推奨最大サイズは 100 KB。
定型返信文とアクション
リッチカード内の返信文や操作の候補は、 表示されます。
チップリスト内の返信文や操作の候補は、候補を前進させたり、 話題を変えます。
返信文の候補
定型返信文は、ユーザーが自分の好みに合った方法でエージェントに返信するのに役立ちます。 簡単に対応できますインタラクションで自由形式の回答が必要な場合を除き、 定型返信文。自由形式のテキストよりも処理が簡単で、 会話を最適なパスに導くことができます。
推奨される措置
推奨アクションを使用すると、エージェントはネイティブ デバイスのアクションを利用し、 ユーザーエクスペリエンスが 緊密に統合されています関連性がある場合に推奨されるアクション を使用すると、簡単にカスタマー サポートに電話したり、地図で場所を検索したりできます。
ただし、ユーザーに選択肢を過剰に提示しないでください。関連するアクションのみを提供する 必要な数のアクションのみを提示します。上限 その相手にとって有用なアクションの候補と、 あるかもしれません。
設計のまとめ
会話、ユーザビリティ、効率性を考慮した設計は、 作成されます。エージェントは会話型 UI と 返信文やアクションの候補を使用して、最適なワークフローでユーザーをガイドします。日時 使用する場合、エージェントは、ユーザーが操作できるように コンテキストを保持し、メールを簡単に読むことができます。
ユーザー エクスペリエンスを考慮し、会話のデッドエンドを回避できる エージェントの設計は 優れたエクスペリエンスをユーザーに提供し エージェントを使用する必要があります。