VUI設計その2

前回はVUI設計の手順を説明しました。今回は実際にフローチャートを見ながら、音声アプリケーションのVUI設計がどんなものかお伝えできればと思います。

題材は、路線の運行情報を答える「Yahoo!路線」のAlexaスキル/Google アクションです。公開(2018年7月)後、改修を重ねる中でわたしたちがVUIを設計する上で工夫してきたポイントを解説します(掲載するフローチャートでは説明の都合上、一部処理を省略していたり、実際のアプリケーションとは動作が異なっていたりします。ご了承ください)。

フローチャートの書き方

フローチャートの注意点

音声アプリケーションのVUI設計をまとめる際に便利なフローチャートですが、次のような欠点もあります。自分たちの音声アプリケーションや開発の進め方に合った作成方法、使い方を見つけてください。

• 会話の流れを確認しづらい
  フローチャートは処理側のロジックに沿った表現になるため、ユーザーがどの状況でどんな会話のやりとりをすることになるのか、まとめて把握するのが難しいです。会話の流れやスクリプトが自然なものになっているかは、台本形式で確認しましょう。

• 複雑な対話フローの場合はすべて書き出せない
  今回の例にする「Yahoo!路線」は必須スロットが路線名の1つのみのため全経路を書いていますが、ユーザー発話によって埋める変数(スロット)が多い場合、それは難しいでしょう。スロットを埋める順序や個数を固定しないようなフローチャートの書き方を工夫してください。

記述ルール

わたしたちはVUIフローチャートに次のような記号を用いています。このほか実際には、音声PFごとの仕様差異、設定アプリ(Alexaアプリや Google アシスタントアプリ)へのカード表示や通知、画面付き端末での画面表示・動作についてもルールを定め、同じフローチャートに記載しています。

• 

  フローチャートの凡例

なお「ASK」というのは、アプリケーションがセリフを話し終わった後、自動的に聞き取り状態になることを示します。ASKの場合、ユーザーはウェイクアップワード(「アレクサ」や「OK Google」)を省略して話し始めることができます。次の会話を促すのにとても有効ですが、ユーザーの発話を待ち受けることになるので、ASKの後にはユーザー発話による分岐が必要です。

書き方

ユーザーの発話や、発話以外の情報(設定住所や発話履歴等)を分岐条件として、その結果の音声アプリケーション側の応答を矢印で結んでいきます。以下は「Yahoo!路線」を例にしています。

【手順1】
VUI設計のステップ2で用意したハッピーパスをフローに書いてみます。

• ハッピーパス① ：「ヤフー路線で東西線の運行情報」と聞けば該当の路線情報を答える。

• ハッピーパス② ：「ヤフー路線で運行情報」と聞くと登録路線を答える。

すると、以下のようなフローチャートができます。

• 

  フローチャート1

【手順2】
次にハッピーパス以外の経路を足します。例えば、「カレーの運行情報を教えて」と言われたら？登録路線がなかったら？のようなケースを追加すると、フローチャートが下のように変わります。

• 

  フローチャート2

【手順3】
このあとはVUI設計のステップ3で検討した設計方針に沿って、経路を網羅します。

VUI設計に関する4つのポイント

ここからは「Yahoo!路線」のVUI設計で工夫している点を4つ、フローチャートを交えながらお伝えします。

VUI設計ポイント① ユーザーの発話を省く

運行情報を知りたいのは、いつもの通勤・通学で使う路線であることが多いでしょう。そこで「Yahoo!路線」では、路線名をわざわざ言わずに「ヤフー路線を開いて」と発話するだけで、決まった路線を答えられるようにしています(ハッピーパス②に該当)。また、なるべくその経路に入る人が増えるように設計しました。

• 

  フローチャート3

VUI設計ポイント② 使い方を知らせる

VUIでは、その音声アプリケーションがどんなことができるか、適切なタイミングで知らせる必要があります。例えば、アカウントリンクするともっと便利になることを、どのように知ってもらえばいいでしょう？ 起動するたびに案内していては、VUIの長所を損ねてしまいます。

使い方を知らせるのに向いている場面は、ヘルプ発話があったとき、初めてそのアプリケーションを呼び出されたとき、タスク完了時(成功回答のあとに別の機能を紹介する)などです。

「Yahoo!路線」の場合、アプリケーション終了時に伝えています。また、その内容はユーザーの状況によって出し分けています。ただ毎回案内されると冗長なため、このフローを適用するのは複数回に1回の割合にしています。

• 

  フローチャート4

VUI設計ポイント③ 次の会話を促す(ただし適度に)

手順2で解説したフローチャート2では、「カレーの路線情報」に対して「カレーという路線名は見つかりません」と答えて終了していました。ユーザーは恐らく聞きたい情報を得られず、その会話に満足できないでしょう。こんな場合は、ASKで次の会話を進めてユーザーの協力を得ながら、成功回答を目指します。

このような場面ではプロンプトの内容も聞き返す回数によって変更しています。1回目は音声認識の誤りもあり得るので言い換えをお願いする、2回目はユーザーに認識結果を添えてフィードバックをする、それでもダメなら3回目は謝って終わる、という設計です。

• 

  フローチャート5

また、ASKのプロンプト内で、「どの路線を調べますか？」のような疑問文は最後に来るようにします。疑問を投げかけると、それは話者交替(ターンテイキング)のサインとなり、人はすぐ答えようとしてしまうためです。「Yahoo!路線」では、必須スロットである路線名が埋められない場合のASKプロンプトをこのように修正しました。

• 

  フローチャート6

ASKは会話促進の強力な方法ですが、留意点として、ユーザーが会話を終わらせたいタイミングでのASKは使い勝手を悪くします。わたしたちがVUI設計で失敗した例として、ユーザーが求める運行情報を回答したあとに必ず「ほかに聞きたい路線はありますか？」と次の発話を促すようにしたことがあります。素早く1つの路線情報だけを聞きたい場面で、ユーザーが質問に回答する手間を増やしてしまったのです。現在はその経路に流れる条件を変更し、頻度を下げています。

VUI設計ポイント④ 受け付け発話を広げる

最後に、フローチャートでは把握しづらい部分ですが、VUI設計にはユーザー発話への対応が欠かせません。ユーザーはさまざまな言い方をします。設計者はできる限りそれを想定し、受け付けられる発話の幅を広げてハッピーパスにつながる経路を太くします。具体的には、インテントのサンプル発話、スロットの拡充です。

特にフローチャートの遷移に変更を加えたときには、ウォークスルーテストだけでも実施しましょう。リリース後はもちろんログを見て改善します(Alexaなら「インテント履歴」、Google アクションなら「Training機能」を活用)。

まとめ

今回は、「Yahoo!路線」のフローチャートを実例としたVUI設計を解説しました。実際のところまだ改善点を残していますが、具体的な例として参考になればと思います。

そして、ここまで音声アプリケーションの企画からVUI設計までの説明をお届けしてきましたが、今回で虎の巻の前半パートは終わりです。次回からは後半の技術パートに入り、エンジニアたちが音声アプリケーションの開発ノウハウをご紹介していきます。どうぞお楽しみに。