はじめに
近頃のVUIの勢いが凄まじく、Twitterを眺めていると毎週何かしらのVUIのカンファレンスが見かけている気がします。
ここはVUIのビックウェーブに乗ろうではないか！とAlexaスキルやClovaスキルを作成し公開した中で得たVUIの設計知見を簡単にまとめてみたいと思います。
(Google Homeについても近々追記したいです)
VUIスキル作成の流れ
- 要求分析
- ストーリー設計
- 外部設計
- 詳細設計
- 実装
- テスト
ソフトウェア開発と大きく変わらないと思っています。
ただ、VUIスキルを作成する上で「ストーリー設計」が大変重要です。
ストーリーがブレると後工程ほぼやり直す、といったことが起きかねません(これはソフトウェア開発で上流工程が重要であることと同じですね)。
1. 要求分析
Alexa開発者コンソールの音声デザインガイドに沿って開発するとある程度ブレることなく開発できると感じました。
しかし、少し検討が不十分だと感じたため、以下に補足したいことを加えました。
スキルの目的と機能の明確にする
- スキルはユーザーに何を提供するのか
- ユーザーがスキルを使うことによって何ができるのか
目的と機能を定めることで、設計を進めていくうちに目的以上に機能を盛ってしまう、なんてことを防ぐことができます。
私のように作っているうちに目的を忘れ迷走する人はスキル作成中はよく見える場所に貼っておくと良いです (戒め)。
VUIに向いているかどうか検討する
スキルの目的と機能が決まったらそのスキルはVUIに向いているかどうか検討しましょう。
VUIに向いていないスキルを作るとのちのち痛い目を見ます地獄です。
せっかくならIFが音声であることのメリットが活かせると良いですね。
VUIが向いているか検討するときは以下を考えてました。
スキルを使う場所が適切か
声を発しやすい、発話が聞き取りやすい環境で使われる。スキルを使う状況が適切か
デバイスから (声が届く範囲で) 離れている、両手がふさがっている状況の場合、恩恵を受けやすい。ユーザーがスキルを使う目的がはっきりしているか
目的なくスキルを使われると発話を受けて処理するのは非常に厳しい (自由発話を受けて処理するのが難しい)。
目的をもってユーザーに発話してもらうことが大事です。目的に達成するまでのやり取りが少ないか
対話を何度する、ユーザーからのインプットが多く必要になる機能はユーザーの負担が大きいためVUIに向いていない可能性があります。
しかし、エンターテインメント性の高いものは、成り立つ場合もあります。
ただ、前回の発話内容を覚えている等ユーザーとやり取りを少なくする工夫は必須です。
また、デバイスからの発話が多い機能の場合、VUIではデバイスが発話している間は別のインテントに移ることができないため(中断はできる)それでもユーザーは困らないかどうか確認する必要があります。デバイスからの発話に感情を表すことでスキルの魅力が増すか
VUIはキャラクター性を持たせたりユーザーを褒めたりと、ユーザーへ感情を伝えることが得意です。
感情を伝えることでプラスの価値が生まれるスキルだとより適性があるといえそうです。
2. ストーリー設計
あえて要求分析と分けたのは「ストーリー設計」が大変重要だと思ったからです(2回目)。
VUIは、対話フローの作成が肝です。
Alexa音声デザインガイドの対話フローの作成 では、対話フローの作成で以下を検討するように記載されています。
終了までの最短ルートの書き出し
別のルートによる意思決定フローの書き出し
システムロジックがバックグラウンドで実行すべき処理の書き出し
ユーザーヘルプの書き出し
アカウントリンキングプロセスの書き出し(必要な場合のみ)
実際スキルを作成して上記だけでは足りないと感じた内容を以下に挙げます。
別のルートによる意思決定フローの書き出し(補足)
ソフトウェア開発でいう例外フローの作成します。
ユーザーの発話内容は常に自由な入力が可能な点に注意して例外フローを作成しましょう。
また、ユーザーの発話内容が必須かどうか確認し、必須の場合は聞き返す、必須でない場合はデフォルト値で動くなど決めておくと例外処理を決めるのが楽になります。ユーザーの発話の洗い出し
機能に対しユーザーがどういう発話をするか予め洗い出しておくと実装での手戻りをぐっと減らせます。
さらに、対話の中で聞き出したい単語は予め定義されたスロットタイプにあるかデバイスが聞き取りやすい単語かを確認しておくとよいです。
また、発話内容はスロットとして想定された単語か否かしか分からない点に注意しましょう(自由発話が取れるデバイスもありますが精度はイマイチ)。起動直後に遷移できる機能の書き出し
VUIは複雑な分岐は苦手です。
よって、起動直後にやりたいことがすぐ出来る方が望ましいです。
起動時にすぐ機能に遷移するという意味ではコマンドを叩くCUIの遷移に近いのかもしれません。
複雑な分岐が必要な場合はVUIに向いているか検討しなおした方が良いかもしれません。対話終了までのフローの洗い出し
最短ルートだけだと漏れが生じるため実装の時、設計を詰めたことがあります。
インテントから特定の別のインテントに移った時に発話内容が変わるようなスキルを考える場合もあるため、フローは洗い出しておくと安心です。
この時、デバイスの台本も考えておくと良いです。
VUIは音声でやり取りするため、CUIやGUIと比べユーザーが一度にデバイスから得られる情報が少なくなってしまいます。そのため、情報を簡潔に分かりやすく伝える台本が重要になってきます(画面がない場合特に)。
フローの洗い出しは、対話フロー図を作成するとフローの漏れに気づきやすくなります。
詳しくは事前に設計を行って気づいたVUI設計で気を付けることに記載しました。(2019/3/23追記)
スキル名の検討
スキルを使う上で最も発話されるものはスキル名です。
他のスキル名と被らない、発話しやすい、音声認識率の高い名前を検討すべきです。
スキルを公開する際には、単語を2つ以上くっつける等、制約もあるため注意が必要です。スキル名およびユーザーの発話の音声認識率の確認
まだまだ、音声認識率には課題がある印象です。
また、GUI・CUIと異なり個人差が大きい所(聞き取りやすい声等)も痛いです。
スキルがきちんと動くように正常系のフローの音声認識率はしっかり確認しておくべきです。
認識率の確認は発話内容をSlackに投稿するスキルを使って認識率を確認しました。おすすめ。(2019/3/23追記)
音声認識率について補足
音声認識率もデバイスごとに異なる気がします(調査中)。
Alexaは、ビュやピュを含む単語を聞き取るのが苦手です。
Clovaは、基本的な単語が聞き取れず何度も聞き返される印象がです(ヤンデレが読んでると聞き取られたり…)。
自由発話について補足
自由発話の認識精度が悪く自由発話を取ることが難しいため「ストーリー設計」で自由発話が必要なスキルになった場合、スキルの目的を絞る必要があるかもしれません。
Clovaは自由発話が取れず、Clovaスキルを作った時には実装中に対話フローを練り直した経験があります。
Alexaは自由発話を取ることができますが、以下のようにサンプル発話を
Intent
{自由発話}を削除して
{数値}を削除して
を同じインテントにしていると数値か数値でないかで判定されてしまいます。
上記のサンプル発話を異なるインテントにしても
Intent1
{自由発話}を削除して
Intent2
{数値}を削除して
数値のインテント(Intent2)ばかり拾ってしまいます。
このようにAlexaが安定しないためやはり自由発話を取るのは工夫が必要で難しい印象です。
3. 外部設計
- デバイスの選択
デバイスによって、特徴も異なります。
| デバイス | 説明 |
|---|---|
| Alexa | スキルの数が多く参考になる文献も多いため開発難易度は低い印象です。スロットタイプが多いのも魅力的です。 |
| Clova | LINEとの連携が容易で、Botを作って連結させたいならこっちです。 |
さらにデバイスによってバックエンド処理の選択も変わるため、詳細設計と合わせて検討しましょう。
DB設計
AlexaでDynamoDBを使っていた時、対話フローに合わせてテーブル設計をきちんと考えていなかったため仕様が変わったり、Queryで効率よくデータを取ってこれなかったりと散々でした。やはりDB設計大事です。
画面遷移図を作成するとDB設計の役に立つと思います。画面遷移図の作成
画面付きのスキルを考える場合、インテントごと画面設計と画面遷移図はあった方がよいです。
表示させる画面によって、必要な情報が異なるからです。
例えば、以下のようにDB内のデータをリスト表示する画面仕様だとDB操作の有無に関わらず、DBからデータを持ってこなければいけません。
しかし、ユーザーがDBに追加したい発話内容だけ表示する画面仕様だとDBからデータを持ってこずに済みます。
ただ、画面ありきのスキルを考えるとVUIの良さ(デバイスとの距離が離れていても使える等)が損なわれる可能性があるので、注意すべきです。
- マルチユーザーへの対応
開発していると忘れがちですが、スキルがマルチユーザーに対応していることが大切です。 1デバイス1ユーザーではないため他の人が使っても問題ない作りであるかは確認しておくべきです。
4. 詳細設計
エラー時の対応
VUIのユーザー入力はGUIでいうTextBoxのように常に自由な入力が可能です。そのため、常に予期しない発話を検討しなければいけません。
ユーザーに入力させる内容はスロットである程度決め打ちにしておき、あとは弾くようにする必要があります。バックエンド処理の検討
デバイスによって選択肢が変わってくるためよく検討しましょう。
AlexaならASKでLambdaと簡単に紐づくためコード実行部分はLambdaを使う例が圧倒的です。
ClovaはAlexaのようにHTTPリクエストとコード実行部分に強力な連結がないためAPIGateway+LambdaだったりAzure Functionsを使ったり、開発者がより自由に選択できる気がします。ログ出力の検討
スキルを公開するならば改良に役立てるためログを取っておくと良いでしょう。
開発者コンソールなどで使用されたインテント数などグラフで可視化できるデバイスもありますが、改良するには情報量が少ないと感じます。
5. 実装
設計に沿ってひたすら実装します。
実装でよく躓いたのは非同期処理でしょうか。
非同期処理にしていると、先に発話処理が終わっていて非同期処理が出来ていなかった、なんてことがあったので注意しましょう。
6. テスト
テストに関する知見はあまりないんですが、簡単にまとめます。
基本的に「作りながらデバックする」のが確実だと思います。
また、デバックには3ケースあり、時々結果が異なります。最終的には対話終了までのフローを網羅的に実機でデバックすると良いです。
- Lambdaスクリプトの単体テスト
- Alexa開発者コンソールによるテスト
- 実機でのデバック
以下、バグが見つかりやすいタイミングです。
- 既存のインテントから別のインテントに処理が移る時
- スキル終了後、すぐに起動する
- スキルが終了して暫く経過した後、起動する
- スロット値に何も入らない時
Lambdaを使っていてグローバル変数が残っていたり、Clovaの公式SDKを使用してセッション情報が残ってしまったりして意図しない挙動になる場合があるので、気を付けましょう(何度もやらかしている人より)。
まとめ
- スキルを作成する前に実現したい機能は本当にVUIであるべきか、VUIであることで価値が高まるのか考えよう
- ストーリー設計は、VUI設計の肝！スキル終了までの対話フローや想定されるユーザーの発話を洗い出しておこう
CUIのようにユーザーへ簡潔で一方的なやり取りでなく、
GUIのようにユーザーへ一度に多くの情報を伝えるだけでなく、
VUIはユーザーとデバイスが同じくらいの情報量を交互にやり取りできることが魅力です。