今回は第2章のPart3。会話のデザインにおいて結構重要な「確認」と「エラーハンドリング」について紹介する。

まず最初は「確認」についてのTips。

「確認」とはユーザーさんに出された指示が間違いないかを確認する行為などがある。

例えばメールを送信する際などに内容や贈り相手はこれで問題ないかどうかを確認するなどだ。

IVRの時代ではこれはかなり極端というか、しつこくやられることが多かったらしい。例えば

アシスタント「飛行機の予約をしたいですか？」
ユーザーさん「はい」
アシスタント「今あなたは"はい"と言いましたか？」

みたいな。これは鬱陶しいし、何より不自然だ。

送ろうとしたメールの宛先が間違っていたり、注文したピザが全然違うものだったりすると大変なのでしっかりと「確認」する必要はあると思うが、しつこいのは体験を損なうので良い塩梅にやる必要がある。

また、「確認」には以下の２種があるので場合によって上手く使い分けるのが良さそう。

- 明示的な確認

いわゆる一般的な「確認」で、ユーザーさんからの返事を期待する方法だ。「○○さんにメールを送ります。よろしいですか？」など。

- 暗黙的な確認

ユーザーさんへの返事に発話された内容を含めることで「あなたの指示を理解しましたよ」と暗に伝える確認方法。例えばリマインダーのセットを指示された際に「○○をリマインダーにセットしました」と返す。

これでインタラクションを１つ減らすことができる。

次は「エラーハンドリング」について。「会話にエラーは無い」とActions on Googleのデザインドキュメントにもあるように会話の最中にエラーを引き起こすのは体験を大きく損なう。

エラーハンドリングはごく単純な例だとアシスタントがユーザーさんの発話を上手く聞き取れなかった時に「すみません、もう一度お願いできますか」のように聞き返すなどがある。

これは無難な方法ではあるが、どのシーンにおけるエラーでも適用できるかといわれるとそんなこともない。

例えばウェイクワードの誤認識によってアシスタントが起動してしまい、ついでにテレビの音でも拾ってしまった際に「すみません、もう一度お願いできますか」なんて言われると鬱陶しい。

この場合、AlexaやGoogle Assistantなんかは無視して（Alexaは短いビープ音を鳴らして）会話を終了する。

このように聞き取れなかったからもう一度ユーザーさんに聞き返すというのは例えば複数回の会話をしている際中には便利だが、1回目の発話に対しては上記の不便さが勝る可能性があるため、状況によって処理を変更する必要がある。

個人的見解だがAlexaやGoogle Homeはこんな感じでユーザーさんからの発話に対する応答を分けていると思う。

- 発話が初回かつ日本語として不自然な内容
無視して会話を終了する

- 発話が初回かつ日本語として自然な内容
それに上手く対応することができないことを伝えて会話を終了する

- 発話が複数回目
「もう一度お願いできますか」と聞き返す。とはいえこの場合は基本的に3rd PartyのSkill/Appになるので開発者任せではある。

この本ではエラーを以下の4種に分類している。

- No Speech Detected
発話を検知できなかった場合。

- Speech Detected but Nothing Recognized
発話を検知できたものの、上手く認識ができなかった場合。

- Recognized but Not Handled
発話を検知し、正しく認識できたものの、正しくハンドリングできなかった場合。

- Recognized but Incorrectly
発話を検知し、認識したものの内容が正しくなかった場合。

3rd partyの開発者としては3番目と4番目は同じものではあるが、同じエラーでもシーンとして2種類あるということは頭の片隅に入れておいた方がいいのかなと思う。

また、エラーでとても怖いのは「発話の意味がわからない」よりも「発話の意味を勘違いしたまま先に進む」ほうがよっぽど怖いことを認識しておいた方が良さそう。

次回は同じく第2章 Part4