音声対話のためのオーディオシグニファイア
明示的、暗示的、そして、非言語的なシグニファイアを提供して、音声対話インタフェースの選択肢をユーザーが理解できるようにしよう。
良質な音声インタフェースには、優れた自然言語理解だけでなく、音声対話で利用できる行動やコマンドの領域をユーザーが理解できるようにする方策も求められる。つまり、「実行におけるへだたり」に橋をかけなければならない。対話デザインにおけるこの課題は、どんなシステムにも存在しているものだ。しかし、その性質上、音声インタフェースには、さらに難しい課題であるといえるだろう。
実行におけるへだたり
システムとうまくインタラクトするには、ユーザーは、（1）特定のゴールを達成するために取るべき行動を見つけ出し、（2）そうした行動による結果を理解することができなければならない。大きな影響力を持つ本、『誰のためのデザイン？』の中で、我々の仲間であるDon Normanは、これらのニーズをそれぞれ、「実行におけるへだたり」と「評価におけるへだたり」と表現した。この2つはどちらも重要なものだが、この記事では「実行におけるへだたり」に焦点を当て、どんなコマンドが可能なのかをユーザーに理解してもらうために、音声対話システムはどうすればいいのかを考える。
グラフィカルユーザーインタフェース（GUI)では、デザイナーはクリックできるテキストを目立つ色にするといった目に見えるシグニファイアを提供することで、ユーザーが「実行におけるへだたり」に橋をかける手助けをすることができる。こうしたテクニックは適切に使用すれば、どんな行動が取れるのかをユーザーがひと目見ただけで理解できるようにしてくれるものだ。その反対に、調査からは、グラフィックなシグニファイアが弱いと、タスク時間が長くかかるようになり、GUIのどこをクリックできるかがはっきりしなくなる原因になることが示されている。
視覚的な合図がない場合、ユーザーは可能なコマンドを想像するか、覚えておこうとしなければならない。その結果、どちらの場合にも認知負荷が増し、インタフェースはさらに使いづらいものになってしまう。しかし、音声対話システムのデザイナーは、重要なシステムコマンドにシグニファイアを盛り込むことで、こうした問題を最小限に抑えることが可能である。
定義：音声対話のシグニファイアとは、どんな音声コマンドが可能であるかをユーザーが理解できるようにシステムが提供するユーザーインタフェースのキュー（手がかり）のことである。
実行可能な音声コマンドを示すには、音声によるキューか、視覚的なキューを利用すればよい。画面が使えるなら、一般には、視覚的なシグニファイアを盛り込むのがベストだが、すべてのUIが画面を備えているわけではないだろう。そこで、この記事では、SiriやGoogle Now、Cortanaのようなスマートフォン埋め込み型のパーソナルアシスタントと、AmazonのEchoやGoogle Homeのような独立型の音声対話システムで使われるオーディオシグニファイアに焦点を当てる。
音によるシグニファイアの種類
ユーザーに行動を促し、可能なコマンドについて知らせる音ベースのシグニファイアやキューには3つの種類がある：
- 非言語音、あるいはイヤコン（聴覚アイコン）。システムによって生成される特徴的な音のことで、特定の行動や状態とセットで使われることが多い。たとえば、Siriは、起動フレーズを検知すると、2トーンのビープ音を発して、現在、コマンドを「聞き取り中」であると示す。
- どんなコマンドが利用可能なのかがユーザーがわかるように、システムがサジェストやリクエストを言語化する場合の、音声による明示的なシグニファイア。たとえば、Google Homeは、「タイマーをセットして」と言うと、「わかりました。タイマーの長さはどのくらいにしますか」と返事をする。
- ある行動が実行可能であることを、システムが明確なサジェストをすることなく、ほのめかす場合の、暗示的な音声キュー。たとえば、AmazonのEchoは、それが発話中にウェイクワードを検知すると、読み上げを一時停止することで、新しいコマンドを「聞き取り中」であるとユーザーに知らせる。こうした振る舞いは人間の話し方を模したものだ。人の会話で、短い間を入れるというのは、自分が話すのをやめて相手の話を聞く用意がある、という会話相手への合図だからだ。
非言語的な音
イヤコン（インタフェースの音によるキュー）は、グラフィカルユーザーインタフェースで見られる視覚アイコンに似ている。両者ともに言葉を省くことで、ユーザーとより効率的なコミュニケーションをしようとするものだからだ。ごみ箱のアイコンが「削除する」というラベルが付いたボタンよりも画面スペースを取らないのと同様、ビープ音を鳴らすほうが「新しいメッセージがあります」という言葉を読み上げるよりも時間はかからないのである。
しかし、アイコンやイヤコンによって効率が向上するかどうかは、そうした合図の意味をユーザーが実際に理解できるかどうかにかかっている。画像のもつ曖昧さという特性により、視覚アイコンにはユーザビリティ上の問題があることが多い。そして、聴覚アイコンというのはさらにわかりにくいものだ。なぜならば、意味を伝えるのに、言葉「も」画像「も」利用できないからである。よく使われる視覚アイコンと同じ意味をもつイヤコンを作り出そうとした途端に、この問題が浮かび上がってくるだろう。
たとえば、視覚アイコンは、アイコンが示す行動とそのシンボルとの関連の仕方によって、類似、関連、または、特殊の3つに分類される。類似アイコンは実行する機能をあらわした見た目になっている。たとえば、ごみ箱の画像は物理的なごみ容器と同じ形をしている。したがって、削除アクションの類似イヤコンは、ものがごみ入れの中に落ちるときのような、「ドスン」という音にしてもいいかもしれない。しかし、「ドスン」という音には、2つのものがぶつかったり、ものが棚の上に置かれたりしたときの音など、似たような音が他にもいろいろとある。
そして、イヤコンは概念に関連したものにしようとすると、さらに曖昧になる。たとえば、モーという牛の鳴き声を「牛乳」という概念の関連イヤコンにすることもあるかもしれない。（この場合、「もー」が指しているものは、乳牛に関する何かであって、実際の乳牛を示しているわけではない）。しかし、「モー」という音だけでユーザーに特定の行動を推測させるのは、買い物リストよりも、ゲームのほうが適切である。
非言語音は曖昧なので、ほとんどのイヤコンは、特定の行動の音に似せたつもりであっても、特殊な音として機能する。恣意的な特殊な音はユーザーの注意を引く。しかし、特定の意味を伝達できるのは、次のような一定の条件下に限られるだろう：
- タスクのコンテキスト中：ユーザーがコマンドを発した直後、プライミング効果（先行の刺激が後続の別の刺激の処理に、無意識的に影響をあたえること）によって、イヤコンをそのコマンドに関連したものと認識できる場合。たとえば、あるオブジェクトが削除されるべきであるとユーザーが表明した後に、「ドスン」という音を確認として利用する。
- 何度も聞いた後：たとえば、ある特殊な音は電話がかかってきたことを示しているが、別の音の場合は新しいテキストメッセージを指しているとユーザーも徐々に学ぶ。
繰り返し聞いた後でも、ユーザーが恣意的な特殊な音を一意的に特定できるようになる保証はない。ほとんどの人は電話のダイヤル時に発生するトーンを何千回も聞いたことがあるが、どのトーンがどの特定の数字のものか答えるのは苦労するものだからだ。
また、聴覚アイコンというのはコミュニケーションとしては一方的な形式ともいえる。つまり、システムは「ドスン」とか「ピーッ」といった音をユーザーに対して出せるが、ユーザーが非言語音をコマンドとして正確に発声することは不可能である。
このような制約により、イヤコンは狭い範囲内で繰り返しおこなわれるコンテキスト（たとえば、よくおこなわれるタスクの確認に使用される場合など）や、一般的に注意を引きたい場合に、主に効果的である。しかし、多くの場合、イヤコンが伝える情報は十分ではないので、音声によるシグニファイアも使う（または、音声によるシグニファイアに置き換える）必要がある。
音声によるシグニファイア：明示的なキューと暗示的なキューの両立
明示的な音声キューとは、質問やサジェストの形をとる、最もわかりやすいタイプの音によるシグニファイアだ。しかし、利用可能なすべてのコマンドをそのまま読み上げるのはうんざりするほど時間がかかるものだ。このことに関しては、スクリーンリーダーのユーザーに聞いてみるとよい。また、うっとうしいこと以外にも、音声によって延々と選択肢のリストを読み上げていくのは非効率的でもある。というのも、ユーザーがそのすべてを覚えておける可能性は低いからである。（10個の部署がリストアップされている電話のメニューを思い浮かべてみよう。5番目の部署まで聞いた頃には、選択肢の1番目の部署がどこだったかは忘れてしまっていることが多いだろう）。
明示的なシグニファイアは、買い物のような不可逆的な行動に不可欠である。しかし、他の多くの事例では、次のような特定のテクニックを使うことで、強力なシグニファイアと素早いやり取りは両立可能である：
- ユーザーのインテントを推測して、確認する。
- 明示的な発言の代わりに暗示的なキューを提供する。
- 明示的なキューを分割して、シーケンシャルな別個の対話にする。
- キューは段階的に開示し、必要になってから出す。
推測と確認
ユーザーのインテントを推測することで、対話は最も効果的なものになる。しかし、それはきちんと推測できるだけの情報をシステムがもっている場合に限られる。たとえば、Echoにどのステーションがいいかを言わずに、音楽ストリーミングサービスのPandoraをかけて、と頼むと、Pandoraで最近、利用したステーションを自動的にかけてくれる。そのステーションはユーザーが以前、選択したものなので、それで問題ない可能性は高いだろう。
一方、不正確な推測によって、対話に時間がかかってしまうこともある。へたな推測をされてしまうと、システムがしたその仮定の訂正方法をユーザーが見つけ出さなければならなくなるからである。
たとえば、ユーザーが音声対話システムに、「9時に約束を設定して」と依頼するシナリオについて考えてみよう。このシンプルに見えるタスクには、予定の名前や日付、時間帯（朝か夜か）を特定する以外にも、こうした値の一部を編集したり、予定として最終的に保存するための、補足的な質問やコマンドが必要だ。以下の表は、4種類の音声対話システムがこのタスクをどのように処理するかを示したものである：
| 「約束を9時に設定して」というユーザーのコマンドに対する音声システムの応答 | |||
|---|---|---|---|
| Echo | Cortana | Siri | |
| システム：イベントのタイトルは何ですか？
ユーザー：ヘアカット。 システム：わかりました。明日の午前9時にヘアカットですね。この約束を保存したいですか？ ユーザー：はい。 システム：承知しました。イベントを保存しました。 |
システム：それは朝の9時ですか、夜の9時ですか？
ユーザー：朝。 システム：何曜日ですか？ ユーザー：木曜。 システム：では、そのイベントの名前は何ですか？ ユーザー：ヘアカット。 システム：8月24日木曜日の午前9時にヘアカットの予定を入れますが、よろしいですか？ ユーザー：いいよ。 システム：はい、その予定を追加しました。 |
システム：どういう名前にしますか?
ユーザー：ヘアカット。 システム：カレンダーの今日の午後9時にヘアカットを追加しますが、それでよろしいですか？ ユーザー：いや、明日の午前9時に変えて。 システム：すみませんが、さっきの予定はカレンダーに追加すべきですか。 ユーザー：いいえ。 システム：変えたいのはタイトルですか、時間ですか？ ユーザー：時間。 システム：イベントはいつですか？ ユーザー：明日の午前9時。 システム：承知しました。カレンダーの明日の午前9時にヘアカットを追加しますが、それでよろしいですか？ ユーザー：はい。 システム：わかりました。 |
システム：はい、今日の午後9時に約束を設定します。予定を入れてもいいですか？
ユーザー：いや、明日の午前9時に変えて。 システム：確認かキャンセル、時間の変更、タイトルの変更をすることで、続けることができます。 ユーザー：時間を変更して。 システム：予定は何時ですか？ ユーザー：明日の午前9時。 システム：はい、明日の午前9時に約束を設定します。予定を入れてもいいですか？ ユーザー：タイトルを変えて。 システム：はい、この約束の新しい名前は何ですか？ ユーザー：ヘアカット。 システム：はい、明日の午前9時に約束を設定します。予定を入れてもいいですか？ ユーザー：はい。 システム：カレンダーの明日の午前9時に設定されました。 |
イベントの名前は推測しても失敗するに決まっているようなものだが、1つのシステムだけはそれを試みている。つまり、Siriは「約束」という名前の予定を作り出している。一方、その他のシステムは質問の形を取った明示的なシグニファイアを使って、イベント名をユーザーに問いかけていた。日付と時間帯については、4つのうちの3システムが推測を試みている。SiriとCortanaの推測結果は最も近い将来の該当日時だったが、Googleの推測は翌日だった。こうした推測は合理的なものだが、どちらの場合も、間違えた結果になってしまう可能性は低くない。そうなると、ユーザーは情報の編集方法を見つけ出さなければならなくなる。今回、たまたま、Googleは正しい推測をしたので、対話が最も短かった。しかし、間違ってしまう可能性もほぼ同じくらいあったわけで、その場合には、対話はもっとぎこちないものになっていただろう。（圧倒的多数の約束のリクエストから偶然を探す機械学習の技術を使えば、さまざまな状況下でももっと高い確率で正しい推測ができるようになると思われる）。
残念ながら、SiriもGoogleも、イベントの詳細の編集方法に関するシグニファイアは提供していない。そうではなく、この2つは予定を保存していいかという明示的な問いかけに直接進んでしまっていた。これは問題である。「この予定を入れてもいいですか」や「この約束を保存したいですか」という質問は、はい、か、いいえ、という答えを想定しており、イベントの情報を編集する可能性は考えていないからである。どちらのシステムでも情報は編集可能だ。しかし、実際にそうするかどうかはそうした選択肢の存在にユーザーが気づくかどうか次第になってしまっている。「このイベントを変更したいですか」のような質問もすれば、編集用のコマンドがあることを知らせることができるはずだ。とはいえ、そうすることで、タスクのステップはさらに増えることになるが。
暗示的なシグニファイア
明示的なシグニファイアの代わりに暗示的なシグニファイアを利用すると、対話を（あまり）長くせずに、効果的にユーザーに編集を促すことができる。暗示的なシグニファイアは、より効果的に情報を交換するために人間が発達させてきた話し方を模倣することによって、行動をほのめかすものだ。そうしたやり方の1つに、発言の最後に質問の言葉を追加するというのがある。たとえば、CortanaもEchoも、確認の問いかけの最後に短い暗示的なキューを入れている：
| 暗示的なキューとしての質問の言葉 |
|---|
| Cortana：カレンダーの今日の午後9時にヘアカットを追加しますが、それでよろしいですか？
Echo： 8月24日木曜日の午前9時にヘアカットの予定を入れますが、よろしいですか？ |
システムが生成した発話の最後にある、暗示的な質問キューによって、その予定は変更できるということがユーザーにも理解できる。
これらは、イベントの保存に進んでもよいかという許可を求める発言である。しかし、質問形式の確認の言葉（「それでよろしいですか」と「よろしいですか」）もイベントの詳細の記述のすぐ後で同じ文の中に置かれている。確認の言葉がこの位置に置かれていること、また、内容を限定しない一般的な確認の言葉を使っていることから、システムが質問しているのは、保存していいかということだけでなく、その前に続いている文全体の正確さについてでもあることが伺える。（しかし、この質問に対して、Cortanaが受け付ける答えが、はい、か、いいえ、のみなのは残念なことだ。「いいえ」と答えて、さらに明示的な編集の問いかけを待ってからでないと、ユーザーは情報を変更できないからである）。
シーケンシャルで明示的なシグニファイア
たとえば、「このイベントのタイトルと日付、時間帯を教えてください」という質問のように、複数の問いかけを1回のやり取りにまとめてしまえば、理論的には時間の節約になるはずだ。しかしながら、実際の運用では、この種の問いかけはユーザーの認知負荷を増加させる。なぜならば、ユーザーは3つの別の質問を覚えておいてから、その後で、全部の答えを一度に言わなければならないからである。現実には、認知負荷の増加による間違いと訂正のせいで、それぞれの質問を別々に聞くのに必要な時間と同じか、それ以上に時間がかかる可能性が高いだろう。
上の表にあるEchoの対話では、その代わりに、明示的なシグニファイアをシーケンシャルに提供するやり方が示されている。そこでは、イベント名、日付、時間帯についての問いかけを、3つの質問で別々に聞き、独立した3つの答えを得ている。その例で示されているように、このやり方は不正確な推測のせいで編集が必要になる場合よりも、結果的には効率が良い可能性もある。編集用のシグニファイアがないせいで、エラーになってしまったり、出だしから失敗してしまった場合にはとりわけそうだろう。
また、すべてのユーザーが全部の質問をされるわけではないということも覚えておこう。「ヘアカットという名前の約束を木曜の午前9時に設定して」のような、より詳細なコマンドを提供したユーザーの場合は、どのシステムでも、確認の質問を1回するだけで、タスクをうまく達成できるからだ：
| 詳細なコマンド＝ステップの削減 |
|---|
| ユーザー：Alexa、ヘアカットという名前の約束を木曜の午前9時に設定して。
Echo：8月31日木曜日の午前9時にヘアカット。これで正しいですか？ ユーザー：はい。 Echo：はい、それを追加しました。 |
ユーザーが最初のコマンドに必要な情報をすべて入れた場合、Echoはイベントダイアログでシーケンシャルな補足質問をしない。
キューの段階的開示
段階的開示では、あまり使われない選択肢は、ユーザーの行動からそうしたコマンドが必要だとわかって初めて提供される。たとえば、Siriは、まず、イベントを保存するかどうかをユーザーに明示的に問いかける。そして、ユーザーが保存することを断って初めて、「確認かキャンセル、時間の変更、タイトルの変更をすることで、続けることができます」という発言によって、代わりのコマンドを提示する。
適切な段階的開示では、どの機能が主要な機能として出てくるべきで、どの機能が副次的な機能として隠れているべきかを判断するための、優先順位づけが不可欠である。音声対話システムにとっての優先順位づけは、グラフィカルユーザーインタフェースの場合よりもさらに重要だ。というのも、選択肢が音声で出てくるので、ユーザーはその読み上げを聞かざるをえないからだ。一方、先送りされる音声の選択肢については、「さらに詳しく」という目に見える表示がないことにより、さらに気づきにくくなるだろう。（「さらに詳しく」のユニバーサルなイヤコンがあれば音声インタフェースでは便利だろう。しかし、まだそれは存在していない）。
Siriのイベント作成ダイアログが、ごくわずかなデータからイベントの名前と日付、時間帯を推測したことからすると、ほとんどのユーザーはこのタスクに関する推測を編集する必要があると思われる。したがって、この場合に、よく使われるコマンドを副次的選択肢として先送りし、暗示的なキューすらも提供しないと、節約した以上に余分に時間がかかるようになってしまうだろう。
分岐した経路をもつ複雑なタスクでは、段階的開示をすることで、ユーザーは進行中のステップに関連がある内容だけに集中できるようになる。Google Homeでは、このテクニックを使って、調理方法を1ステップずつ説明している。このタスクでは、システムから、「下ごしらえをしたいですか。それともそれについての説明はとばしますか」と質問される。もし、ユーザーが下ごしらえをしたいと言えば、材料について聞く際の選択肢を説明する、次のようなより具体的な問いかけをさらに受け取ることになる。「材料は全部で7つあります。3つまとめての説明がいいですか、それとも、1つずつ説明したほうがいいでしょうか」。しかしながら、この申し出がされるのは、材料の下ごしらえを選択したユーザーに「限られる」。材料についての説明を省略したいユーザーにとっては関係ない質問だからだ。
結論
音声インタフェースを有益なものにするには、行動が完了するまでの所要時間を最小限にする必要がある。なぜならば、シグニファイアを聞くことのほうがメニューを流し読みするよりも時間がかかるし、音声コマンドの読み上げのほうがボタンをクリックするよりも時間がかかるからだ。しかし、時間の節約のために、重要なシグニファイアを省略するのは逆効果になる可能性がある。つまり、タスクが早く終わっても、そのタスク自体が失敗なら、意味がないだろう。
推測や暗示的なシグニファイア、シーケンシャルなキュー、段階的開示はどれも、音声コマンドを効率的なものするための有効な方策で、副次的、あるいは、すぐに前の状態に戻れるようなコマンドにはとりわけ有効だ。こうした手法はときには明示的なシグニファイアよりも効率的で、「実行におけるへだたり」に効果的に橋をかけることができる場合もある。しかし、エラーを引き起こしてしまって、対話の時間を長くしてしまうのではなく、対話時間を実際に短縮できるように、こうしたテクニックは注意深くデザインする必要があるだろう。
