先日参加したUX DAYS TOKYO 2019にて、
Cheryl Platzの「音声デザインに力を与える」に参加してきました。

本記事は、このワークショップのレポートです。
※ 内容について適切でない箇所があれば指摘いただけると助かります。

ワークショップの概要

• 音声テクノロジーの歴史
  • はじまりは1952年から。その後1976年に出現したテクノロジーが今も同じコンセプトとして使用されている。
  • 2008年にGoogleが音声検索を公開。その後、一般にも広まるようになる。
• なぜ、言語インタフェースなのか？
  • 昔のロボットコミュニケーションは、30分の決められた範囲で、決まった順序のやりとりをするだけだった。
  • 今は、柔軟な文脈理解が可能となった。
  • Amazon Echoの購買層は、高齢者が多かった。老人ホームでも使われるようになった。
    • 音声インタフェースは、「音楽を聴く」「電気を付ける」など、日常の問題を解決することに多く使われていた。それが、日常生活に支障を感じる人たちの課題解決に非常にマッチした。
      • 「非常にシンプルなことだが、それが日常をドラマチックに変えた。出来ていたことが出来なくなった、それがまた出来るようになったことで、我々は尊厳を取り戻せた」
• 音声デザインの基本
  • VUI用語
    • 発話
      • ユーザの発音。フレーズ
    • インテント
      • 発話の裏にある意味。ユーザのしたいこと。意図。
      • AIによる自動判断ではない。音声デザイナが設計する。
    • イアコン
      • アイコンをもじった造語。音声アイコン。使いすぎると自然な会話にならない。
      • 例）Siriの起動と終了のときに出る音。
    • グラマー
      • 文法。
      • 音声テクノロジーの初期は、これしかなかった。
      • シンプルな会話シナリオなら、現在でも充分これで事足りる。
      • スピーカが喋る音声は、TTS(Text To Speech)で構成される。
    • エンティティ
      • システムが知っておくべき意味の概念。
      • ユーザの言葉の意味について、共通の概念をもたないといけない。
      • 例）USAと言ったとき、それは曲名なのか国の名前なのか？をシステムが推論する。
      • 例）「4ケタの数字」といったとき、同じ1234でも「サウザンド・トゥーハンドレッド・サーティ・フォー」とも発音できるし、「トゥエルブ・サーティフォー」とも発音できる。意外に複雑。
    • コンテキスト
      • ユーザの発言のうち、変わらない部分
      • 例）アラームをセットして！
    • スロット
      • ユーザの発言のうち、変わる部分。デザイン時には必須のものとオプションのものを設計する。
      • 例）アラームを「６時に」セットして！
    • 返事（プロンプト）
      • ユーザーへ向けた返事の文字データ
  • 仕組み
    • (ASR ⇔ NLU) ⇒ エンティティ認識、の順に実施される。
    • ASR
      • 自動音声認識
      • ユーザの発話を推論する。けっこう間違うことがある。
      • 間違う場合は、NLUのフィードバックを受けて再度推論を行う。
    • NLU
      • 自然言語理解
      • ASRのアウトプットを受け取り、言語を推論してユーザーの意図を判断する
    • エンティティ認識
      • 意味概念を保存しているエンティティカタログがクラウド上に存在するので、ASRとNLUがやりとりした結果を使って、エンティティカタログへ照合を行う。
      • 照合結果が膨大な数になる場合もある。推論の精度を高めるため、照合結果を絞り込むこともデザイナが担当する。
      • 例）「日本の宿が知りたいな」と言われても、日本の宿は膨大にあるので、追加の質問をして結果を絞り込む。ユーザと認識を合わせる。
    • モーダルアクション
      • 電話を掛けるときは、間違い電話を防ぎたい。
      • しかし一度掛けたらアクションを取り消せないので、その前にユーザに確認する。
      • 失敗するとヤバイ場合に利用する。
    • インテントの理解アルゴリズムの例
      • 
      • 
    • ウェイクワード
      • 音声デバイスを起動するフレーズ。誤作動を防ぐため、音声認識学的に特徴のある一意の言葉にするとよい。
    • フレーズ認識
      • 推論ゲームである。
      • 複数の推論結果から、最適なものを選ぶ。これは信頼度数の高低で判断する。
      • 例）「パイレーツオブカリビアン」
        • 映画（信頼度数 0.7）
        • 音楽（信頼度数 0.82）
        • テーマパーク（信頼度数 0.4）
      • 推論の材料が足りなければ、追加の質問をして文脈理解を行う
• 音声デザインの制約
  • 自然言語が適切か？
    • エレベータの音声操作なら、そこまで会話の種類はない。決められた会話のできるグラマーベースのインタフェースで良い。
    • 制限された環境下なら、自然言語処理はオーバースペック。
      • オフライン環境（海底、地下）
      • 応答の遅延が許されない救急医療分野
  • マイク（入力センサー）
    • 手に持って喋っているのか、遠くから喋っているのか。
      • ニア・フィールド・マイクロフォン（近くで発話）
      • ファー・フィールド・マイクロフォン（遠くで発話）
  • 音響
    • 聞き分けられなければ、音声デザインとしてはNG
    • ユニークなウェイクワードである必要はあるが、短すぎるとユニークだと認識できない。
    • 「ON」と「OFF」は、コンピュータからするとかなり似通った音。
    • 正確にするために、長いワードにするのも手だ。
    • あえて、ミスを避けるために一般的でない言い回しを使う場面もある。
      • 例）車の運転時はミスが許されないので、言い間違いのないようなフレーズにして誤作動を避ける。
    • 照明が付いてる状態で「オン」と発話されたら、「付いてる状態でオンとあえて言うことはないだろう」と判断して「オフ」と認識させることもある。
  • 対話の長さ
    • ワンショット対話：１回で終わる
      • 例）「アラームを６時にセットして」
    • マルチターン対話：何回かやりとりをする
      • 例）「アラームをセットして」
      • 「何時にしますか？」
      • 「６時で」
      • 「わかりました」
    • マルチターン対話の場合、会話の精度を上げるために「区別しやすい」言い回しを提案する場合がある
      • 例）「アラームをセットして」
      • 「朝の１時から８時の間で選択してください」
      • 「７時で」
    • 対話をするときには、質問形式で行う。答えの出ない質問はしない
      • 例）「そうなんですね！」とデバイスに言われても返答できない。話が前に進まない
  • マルチモーダルインプット
    • 音声、タッチ、など、複数のモードでやりとりできること
    • 複数のモード間の状態を同期しておく必要があり、複雑
    • ショッピングサイトでバーチャル試着ができる場合、着たい服を伝えたら写真をスマホで確認する。このとき音声デバイスとスマホは状態を同期している必要がある。
    • 非常にチャレンジングな分野
  • 方言や年齢、性別
    • ユーザーが偏っていると、音声認識にバイアスが生じる
    • 例）白人、男性、若年のみ
    • ユーザーの多様性を考えてデザインする。ターゲット外のユーザーにもリーチする必要がある
    • 例）赤ん坊、ご年配、これまでコンピュータデバイスがターゲット外としていた人々
  • 多言語コミュニケーション
    • カーナビを使っててフランスからドイツに入ったらどうする？
    • それまでフランス語用の認識をしていたのにドイツ語の認識にいきなり変えるのは難しい。
• 音声デザインのガイドライン
  • 返答内にユーザーの発話を含める
    • ユーザーがチェックできるようにするため。
    • 会話は目に見えない。
    • ファミレスの「ご注文を繰り返します」みたいな感じ。
  • GUIと同じにする必要はない。それはゴールではない。
    • 音声ならではのコミュニケーション、情報アーキテクチャにする
    • 「前のページに戻れ」「次のページに進め」など、GUIと同じインタラクションを適用する必要はない
    • 音声なら、検索ワードを打ち込む手間は省ける
    • 音声アーキテクチャは、深堀り型より水平なアーキテクチャのほうが良い。
      • 単純でよく繰り返されるアクションのほうが音声インタフェース向き
  • 簡潔さ
    • 場合によっては話しかけてほしくないときがある
    • 車を運転してるときにはストレスが掛かっているので、長ったらしい会話をいちいち聞いている余裕はない
    • もうベッドに入って寝たいときに音声デバイスと丁寧なやりとりはしたくない。
  • 人格はユーザーが余裕のあるときに出す。
    • 「ユーモア」は最小限にする。やらないといけないときにだけ使う。
      • コストの問題ではなく、不快感を与えないため
    • Cortanaは、機械的な音声。Google Assistantは人間的な音声。相槌まで再現していた。
    • Alexaは、ハイブリッド型。
    • システムを擬人化させるのは、リスクが伴う
      • 不気味の谷
      • 音声デバイスとの会話は人間と同じ感情で出来ない
    • マルチターン対話でユーザーを良く導く
      • マイクを起動して待ってるだけではダメ
      • 対話を重ね、積極的に情報を引き出す
      • 答えを求めるクエスチョンを入れる
        • 「そうなんですね」と相槌を打たれても、要望が聞けるわけではない
    • サンプル会話は録音して視聴しよう
      • 実際に聴くと、イントネーションがおかしい箇所が見つかる
      • SSML(音声合成マークアップ言語）で、音の調整が出来る
      • 録音するときはできれば両側からオーディオ機器で録音する
    • イアコンの使用について
      • 控え目にする
        • Alexaでは最終的に外した。
      • 繰り返しの対話では、対話の最初と最後を識別できるのは便利。
      • 「ここから自分の番だな」が分かる
  • ガイドラインが真実ではないが、ガイドラインから外れる場合は意図的に外すこと。
• 音声デザインプロセスの実践（ワークショップ）
  • シナリオのスケッチ
    • ストーリーボードを作る
      • ターゲットの文脈を知る
      • いろんなシチュエーションを考える
      • 絵で描く。
      • 色を付ける必要はないが、ワークショップでは色付きのものが紹介された
        • ベゾスにプレゼンするからだったという
    • この段階でリスクも考慮する。
      • 「音声インタフェースいらないね」となったら、ここで余計な作業を回避できる
    • 実作業では、ここですごく時間を掛ける。
  • インテントの定義
    • 顧客には提示しないが、内部でコミュニケーションを取るために非常に重要
    • わかりやすいインテント名を考える
    • インテントの概要を考える
      • ユーザーは何を完了したいのか書く
    • サンプル発話を考える
      • ユーザーの典型的なリクエストフレーズを2,3個ほど
  • スロットとエンティティを定義
    • 変動する値と、システムが理解しているべき概念を定義
      • 祝日の種類などはユーザーの国によって異なる
  • サンプル会話の作成
    • 実際にユーザーとシステムとの会話を考える
    • スロットがすべてそろったワンショット対話と、そろってないマルチターン対話の2パターンから考えるとやりやすい
  • 他人に読んでもらう
    • いちばん簡単なユーザーテスト
    • システムの問いかけが自然なものかどうかをチェックできる
  • ボイスフローを作る
    • 実際のシステムの流れを書く
      • プログラミングするときに書くフローチャートのようなもの
    • Cherylは自分で独自のアイコンを作り、フローを作っていた
    • プロンプトも記載するが、文字の数が多くなるのでフローが巨大になる
      • アイコンをクリックしたらプロンプトのリストに飛べるようなハイパーリンクを作って対応した
    • 外部データへの接続はシステムパフォーマンスに関わるので慎重に考慮する
    • エンジニアチームには非常に重宝される。
      • これしか見ないほど
      • バイブルとして扱ってくれる

感想

8時間の長丁場でした。とても難しい内容だったと思います。

Cherylの話を聞いていると簡単にデザインできそうな気分になりますが、
実際にやってみると全くそんなことはなかったです。

最後のボイスフローなど、時間内にはまったく作れませんでした。

知るとやるとではえらい違いです。

とても素晴らしいノウハウを提供していただきましたが、やらないことにはまったく意味がないです。
継続して、少しずつでも、ワークショップで経験したことを実生活に活かしてゆきたいと思います。

まずは、自分の音声スキルを一通り作りきるところまでやってみます。

どうもありがとうございました、Cheryl。とても貴重な時間を頂けたと思います。