Best Practices "In Conversation, There Are No Errors"の日本語訳です

注: この日本語訳は、翻訳時点での内容が反映されています。そのため、既に古い記載内容となっている可能性があります。必ず最新の情報を Actions on Google Document で確認してください。

GUIによるアプリでは、ユーザが何か期待していないことを行った時や、システムが予期せぬ状況になった時には、エラーメッセージをユーザに提示することが一般的です。しかし、会話型UIでは、エラーダイアログといったインタフェースはありません。全てが会話です。人間同士の会話でも、突然相手から「○○エラーです」とか提示されることは、あり得ません。その代わり、会話は継続されます。その会話の中で、間違いは自然な形で訂正されていくはずです。

Actions on Googleで掲載されているベストプラクティスの最後は、In Conversation, There Are No Errorsですが、まさに会話型UIにおけるエラーの扱いについてがテーマです。以下は、その日本語訳です。


会話では、エラーはありません

PDFをダウンロード

会話型インターフェースを設計する際に最も難しくて最も頻繁に無視される部分の1つは、いわゆる「不一致エラー」(認識しないことをユーザが言う)や「入力がないエラー」(ユーザが全く何も言わない)と呼ばれることから復帰する方法として知られています。

しばしば、私たちは、エッジケースとしてこれらのエラーイベントを頻繁に、そして誤って扱い、そして、謝罪して再び同じ質問を尋ねたり、過度に月並みで模範的なアプローチでそれらを処理するように、単純にそれらも処理します。それは、最高に堅苦しい体験や、最悪の場合に本当にイライラする体験を引き起こします。

人々は、「私はそれを理解できませんでした」や「すみません、私は理解できませんでした」のような、丁寧な指示を聞きます。そして、人々が取り去るメッセージは、「私は何も理解しません」や「この技術は動作しません」です。つまり、このような「エラー」からの回復は、ユーザーの経験やアプリの成功にとって、非常に重要です。

機会としてのエラー

意図のない問い合わせなどはありません。ユーザーは、明白にそう言っていなくても、何かをしたいと常に思っています。新しい方法でエラーにアプローチするには、さまざまな条件のダイアログにおいて、それらを新しいターンとして扱います。そのようなケースは、信頼を築き、毎日の会話がどのように行われるはずであるかという本来の期待を活用することにより、ユーザーとの更なる有意義なやり取りを強化する機会になる可能性があります。

人間の会話では、躊躇と訂正はいつも起こります。しかし、人間とコンピュータのやり取りでは、タイムアウトや認識エラーが発生します。違いは、人々は直感的に、そして リアルタイム に、軌道に戻るためにお互いからきっかけを得ることです。しかし、自動化され、作られた会話では、修正を計画し、設計し、そしてプログラムで 事前に 考慮しておく必要があります。

自然な会話の流れを維持しながらこれを行う唯一の方法は、そのようなケースを「エラー」につながない入力として扱うことです。まず、これは、話す方法を知っている人々に信用を与える指示を使用することを意味します。そこから、予防的な戦略を通じて大部分のエラーを排除し、会話と状況の文脈における各ターンに適した戦略を策定することを意味します。

何がうまくいかないかを知る

音声信号処理、言語解析、音声データ送信、ソフトウェアの起動など、ダイアログを成功させるためには、多くのこと全てが連携して機能します。すべてのメカニックは、話された入力をキャプチャして、関連する結果を返すだけのことを正しく動作させる必要があります。予期しない入力が「エラーイベント」を生成すると、それが面白いものになります。

人間の状態を機械から分離する

覚えておくべき重要なことは、そのようなイベントで作動して応答する技術的条件と、実際にユーザの視点から実際に同じ時に起こっていることの間には、違いがあることです。ノイズや中断、話の途中での遮り、多すぎる選択肢を聞くこと、または単に協力していることから、ユーザーは「エラー」を本質的に感じていて、アプリケーションロジックが処理しているのと全く同じではありません。

技術的な観点から、4つの基本的なことが間違っている可能性があります。

  1. 何も入力されなかったか、検出されなかったために、入力の取得に失敗します。その結果、システムはレスポンスを待ってタイムアウトします。
  2. 背後の雑音や、複数の人が話しているため、入力は受信されましたが認識または解析されませんでした。
  3. 入力は認識されますが、アプリはそれをどのように処理するか分かりません。例えば、ユーザーは「私は何をすることができるかわからない」と言っているかもしれません。アプリはテキストを正しく解析しますが、質問に適切に対処することはできません。
  4. 入力は認識されますが、間違ったものとして認識されます。ユーザーが間違ったパスを下って会話がさらに脱線する可能性があるため、これは最悪の種類のエラーになります。

これらの問題への解決策の取り組みを開始するには、実際に問題をさらに2つの経路に分解することから始めることができます。

  1. 入力がなかった(入力なしエラー)
  2. 入力がありますが、それを処理する準備ができていません(不一致エラー)

これで、プログラムで解決しようとしていることが分かりました。しかし、それはシンプルさがなくなり、より戦略的なアプローチが引き継がれる必要があります。これについては、次のセクションで説明します。

エラー処理のための戦略を策定する

堅牢な戦略を使って、これらのエラーをどのように処理できるかを見てみましょう。Dialogflowなどのツール、コードやフルフィルメントのロジックの一部、およびそれらの全てを組み合わせで、これらの一部を実装できます。

効果的な指示

エラーを解決するためのいくつかの指示の戦略があります。

迅速な再指示(文脈なし):

  • “What was that?” (何でしたか?)
  • “Say that again?” (もう一度言っていただけませんか?)

迅速な再指示(文脈あり):

  • “Sorry, what time?” (すみません、何時ですか?)
  • “I missed that number.” (その数字を気に逃しました。)

質問を言い換える:

  • “First, what’s your favorite color?” (最初に、あなたのお気に入りの色は何ですか?) → “What’s your favorite color?” (あなたのお気に入りの色は何ですか?)
  • “Sure, what movie would you like to see?” (承知しました、あなたが見たい映画は何ですか?) → “To get started, what movie do you want to see?” (最初に、あなたが見たい映画は何ですか?)

質問を組み直す:

  • “What time is this for?” (何時ですか?) → “Sorry, what time?” (すみません、何時ですか?)
  • “For when?” (いつですか?) → “What time would you like to book this for?” (これを何時に予約したいですか?)

聞かれていない質問に答える:

  • “I have your name and email from your account, so now all I need is your phone number.” (あなたのアカウントから名前とメールアドレスを持っていますので、今必要なのは電話番号です。)
  • “You can give me the day, the time, or both.” (日付、時間、またはその両方を言うことができます。)

積極的に:

  • “I could put you down for 6 p.m. for now, does that work? (今、あなたを午後6時に予約できますが、大丈夫ですか?)
  • “Do you want to finish this later?” (これを後で終えたいですか?)

現時点でのヘルプ

1つの重要な修復戦略には、混乱したり、質問を聞かなかったり、何を言いたいのかわからないユーザーのための準備が含まれます。このような場合は、直感的な言葉や巧みな指示を使用するなどの予防戦略を適用できます。しかしながら、何かをもう一度聞くよう求めることや(たとえば、「もう一度言ってください」や繰り返しの意図など)、「ヘルプ」や「わからない」のようなものを人々に準備する必要があります。

いつ終了するかを知る

不満を防ぐためのもう1つの基本的な戦略は、さまざまな理由で停止する必要があるため、タスクを完了していない、またはレスポンスを検証していない場合に、ユーザーが会話を離れることを容易にすることです。結局のところ、時々人生には邪魔が入ることがあります。ユーザーの出発の準備は、エラーを防止するための鍵であるだけでなく、行うことが正しいことです。また、後で戻ってきてどこで中断したかをユーザーに知らせることで、後で再び関わることもできます。 また、中断した場所をピックアップして戻ってくる方法をユーザに知らせることで、ユーザに邪魔をすることなく、後で再び関わる機会になることができます。

例 (アプリが終了する):

App I’m thinking of a number. What’s your fiarst guess?
数字を考えています。最初の推測は何ですか?
App I didn’t hear a number.
数字が聞こえませんでした。
App If you’re still there, what's your guess?
まだそこにいるなら、あなたの推測は何ですか?
App We can stop here. Let’s play again soon.
ここで終わりましょう。すぐにまた遊びましょう。

例(ユーザの終了):

User Let's stop playing.
遊ぶのを終わりにしましょう。
App Ok. Your score was 3 out of 5. Talk to you later.
オッケー。あなたの成績は5戦3勝です。また話しましょう。

堅牢なエラーのないパス

覚えておくべき強力な概念は、エラーに遭遇していないユーザーは、進んでいるように感じるはず、ということです。そうすれば、後でエラーに遭遇した場合でも、彼らは脱線したように感じません。

全体を通してより人間的に聞こえる

自然な印象と「偽装」エラーのための1つの方法は、エラー指示だけでなく、ダイアログ全体を通じて、会話をより魅力的にするための可変性を挿入することです。質問と回答にランダム化と可変的な内容を使うことによって、物事を混ぜ合わせるのに役立ちます。

あなたのアプリをもっと人間に聞こえるようにするための、いくつかの有益な戦略は次の通りです。

  • 指示のリストを使用し、コードを変更せずにそれらを任意の数にスケールする
  • これらの指示からランダムに選択する
  • 複数の指示を組み合わせて多数の順列を作成する
  • 実行時に置き換えられるプレースホルダ記号で指示を書式設定して動的値を追加する: 「ようこそ、%s」
  • 以前の指示を覚えておいて、次の指示をランダムに選んだ場合に、再度使用されることを防ぐ
  • エラーの数を追跡し、指示を調整して、最も一般的なエラーとの関連性を高める

ユーザーの信頼を得るための作業

何ができるのかを解決するために、システムへ問うためにユーザが尋ねるかも知れない基本的な質問に対して準備します。このように考えてください: 隣人との信頼関係を確立するために、あなたは芝刈り機を借りようと尋ねる前に、砂糖を一杯借りようとするかもしれません。人々は、インタラクティブなUIが知っていることを知っているかどうかを知りたがっています。

積極的になり、成功を活かす

彼らが来たのはどの程度の距離か、または彼らが物事を包み込むように遠くないことをユーザに思い出させることは、彼らを軌道に戻すことを助けます。

あなたのアプリのペルソナに依存し、それがいかに積極的であるかに応じて、会話を前進させ続ける状況を制御したいかもしれません。

ベストプラクティス

入力「エラー」は、会話の自然な部分として扱うことを忘れないでください。

  • ユーザーが間違った振る舞いとして技術的なエラー「イベント」を処理しないでください
  • さまざまなタイプのエラーイベントを適切な戦略で処理してください
  • 現時点でヘルプを提供してエラーを防止します
  • いつ諦めるべきかを知ります
  • 成功パスを「偽装」エラーによって強力にします

Creative Commons Attribution 3.0 License 原文

← Actions on Google開発者向けドキュメント 日本語訳インデックス

このエントリーをはてなブックマークに追加

関連記事

2023年のRemap

Remapにファームウェアビルド機能を追加しました

Google I/O 2023でのウェブ関連のトピック

2022年を振り返って

現在のRemapと今後のRemapについて