音声UIで画面を置き換えると、たいてい失敗する

「画面を触らずに声で操作できたら便利そうだ」。音声UI（声で操作する仕組み）の企画は、たいていここから始まります。そして、画面でやっていた操作をそのまま声に置き換えた製品は、使われずに終わりがちです。

失敗の原因は、音声を画面の同類として扱うことにあります。音声は偏った手段です。入力は打鍵より速いのに、出力は一覧が利かず、1件ずつしか届きません。この記事の主張はそこに尽きます。置き換えではなく、この偏りに合う場面を選び、聞き間違いを前提に設計する。この2つが音声UIの成否を決めます。

話す入力は速い。聞く出力は1件ずつ

まず入力側です。スマートフォンで英語と中国語を対象にした比較実験では、短い文の書き写しで、音声入力は画面の打鍵より3倍近く速く、入力の途中で言い直しが必要になった誤りも打鍵の半分以下でした[1]。ただし、直されないまま残った誤りは音声のほうがわずかに多かったことも、同じ実験は報告しています[1]。速いが、確認なしでは小さな誤りが残る。これが入力としての音声です。

出力側は逆です。声で届く情報は、一度に1件ずつ、順番にしか流れてきません。画面なら10件の検索結果を見比べられますが、声で10件を読み上げられると、聞き終えるころには最初のほうを覚えていられません。不要な項目だけ飛ばして聞くこともできません。

だから、長い答えを声で返す設計は最初から捨てます。読み上げは上位の2〜3件か件数だけにして、一覧は画面に出す。話して入力し、画面で確認して確定する。こう分担すると、音声は得意な入力だけ、画面は得意な一覧表示だけを受け持てます。

効くのは、手と目がふさがっている場面

この偏りを場面に当てはめると、向き不向きが決まります。

効くのは、まず手と目が別の作業に取られている場面です。運転中、調理中、設備点検の最中。作業の手を止めない入力手段が、音声くらいしか残っていない場面です。電話窓口には選ぶ余地がありません。そもそも画面がないので、やりとりの土台は声になります。もうひとつ効くのは、言い方が決まっている短いやりとりです。「3番、異常なし」のような点検報告は認識が安定しやすく、聞き間違いが起きてもその場で言い直せます。

逆に効かないのは、選択肢を見比べて選ぶ操作です。声には一覧性がないからです。声を出せない場所でも使われません。静かな共有オフィスで端末に話しかける人はいませんし、発話は隣の席に筒抜けなので、他人に聞かれたくない内容の入力にも向きません。同じ音声入力の機能が、1人の車内では使われて、オフィスでは使われない。音声UIを入れるかどうかは、機能と、使う瞬間の環境の両方で決まります。

設計は、聞き間違いが起きる前提で組む

場面を選んだら、次は誤りへの備えです。音声認識の誤りは、モデルの性能が上がっても残ります。しかも音声UIの裏側は、音声認識で聞き取り、答えを組み立て、声で返す直列の作りなので、聞き間違えた文字はそのまま後段に渡ります[3]。設計でやることは、誤りが起きたときの被害を小さくすることです。

• 取り消しの効かない操作の前だけ、復唱で確認を挟む。「明日10時の予約を取り消します。よろしいですか」。やり直せる操作にまで毎回確認を挟むと、せっかくの入力の速さが消えます
• 言い直しの経路を作る。1項目の聞き間違いで、5項目すべてをやり直させない
• 聞き始めの合図を決める。マイクを開けっぱなしにすると、独り言に誤反応するうえ、利用者には「聞かれ続けている」不安が残ります。呼びかけ語（ウェイクワード）か、押している間だけ聞くボタンで区切ります
• 聞き取りの失敗が続いたら、画面の操作に切り替えるか、人に引き継ぐ。音声だけで完結させない

部品の性能表だけで製品や構成を選ぶと、この設計が丸ごと抜けます。音声認識・文章生成・音声合成の組み合わせを入れ替えて比べた評価では、客観的な品質指標と利用者の満足度の相関は弱かったと報告されています[2]。認識率をあと数ポイント上げることを競うより、間違えたあとの動線を作るほうが、体験には効きます。

音声の偏りに合う場面を選び、誤りを前提に組む。成否を分けるのは、ほぼこの2つです。

裏側の作りの全体像は 音声アシスタントと電話の自動応答は、同じ4つの技術でできている に、電話という条件で聞き間違いが増える理由は 電話の音声認識はなぜ聞き間違えるのか に書いています。