「スマートスピーカー Advent Calendar 2017 」 6日目です。
今日は、実際にGoogle Home向けのアプリをリリースしようとしたときに得られた知見などを簡単にお話しようと思います。
何作ったの？（宣伝）
簡単な育児日記の記録アプリです。
子供がいるご家庭だと、育児日記をつけられている家庭も多いのではないでしょうか。
「○○はいつご飯を食べたか」「△△のおむつはいつ交換したか」など日々の行動や記録をノートやアプリにつけられている場合、
我が家では「あれ、いつおむつ交換したっけー？」「ご飯何食べたっけー」などなど日頃からそういった会話が良く行われております。
何かをしたときに記録するのが一番いいですが、アプリを開くのが面倒、書くのが面倒などなどとにかくめんどくさい…
でも記録としては残したい！
であれば、「ご飯を食べさせている時」「おむつを交換している時」など何か作業をしながら記録できるのがいいのではと！
音声入力のメリットってこういうところに活かせるのかなと思い、音声入力で記録ができる育児日記アプリを作ってみました。
なお、2日前に公開された「Google Homeに話しかけて娘のおむつ交換を記録する」の記事も拝見させて頂き、
子育て中ならではの記録や共有について同じような課題を感じられている方がいらしゃったことや
スマートスピーカーを用いて解決されているところなどなど、
方向性が同じ方がいらっしゃって少しうれしく思い、是非お話してみたいと思いました（笑）
構成
今回は、Actions on Google -> Dialogflow 構成で開発しております。
※ 現在はAWS環境で動いています。（GCPじゃなくてすみません…）
会話のフロー
現状出来ることは、「いつ」「誰が」「何をした」を記録することが可能です。
・おむつを交換した時間
・ご飯を食べさせた時間
・お出かけした時間
・帰ってきた時間
・起きた時間
・寝た時間
などが現在は対応しております。
例えば、「太郎が起きた」「18時に次郎がうんちした」「三郎は、昨日の17時にご飯を食べた」などと発音することで記録が可能です。
今後のアップデートとして、「食べたご飯の種類」や「その時の様子」なども記録可能なように会話フローの調整を行っております。
また、記録を確認するときは、「OK Google、太郎の記録を育児日記で見せて」と発音することで記録を閲覧することが出来、
普段ノートに記録を取っている方でも一時的なメモとして活用することも可能です！
得られた知見
さて、上記アプリを開発するにあたって、Actions on GoogleやDialogflowの具体的な設定方法については、
他の方の記事でより詳しくまとめられているため、ここでは割愛させて頂き、
今回はこのアプリが実際にリリースされるまでに何度かリジェクトされたため、
そのときに得られた知見や状況などを共有できればと思います。
なおリジェクトの内容については、基本的に公式ドキュメントをしっかり読めば、
ある程度対応可能なことかと思いますので、皆様リリース前には隅々までしっかり熟読しましょう！
リジェクト集
その1. 表示名と呼び出し名は一緒にする必要がある
【レビュー内容】
Your name and pronunciation are too different. Your pronunciation should only differ in basic ways such as spaces, punctuation, and phonetic spelling.Actions on Googleポリシーでは、「Pronunciation」はDisplayNameと同一の読み方で作成する必要があります。
従いまして、Pronunciationを「育児日記」にご変更いただけますでしょうか。
Sample InvocationがPronunciationとトリガーワードの組み合わせて成り立つため現在のPhraseでは起動できない状態です。
初めて申請を行ったときのリジェクト内容です。
Actions on Googleの設定で、「Pronunciation」はDisplayNameと同一の読み方で作成する必要があります。初回申請時は、「DisplayNameを育児日記」、「Pronunciationを育児記録」としていたのでポリシーに反していた状態でした。
また、後ほど記載しますが「Sample Invocation」は、
「Pronunciation」に指定した値と「トリガーワード」の組み合わせてアプリを起動させることが出来るため、
これらの発音の整合性を合わせておく必要がある模様です。
その2. 適切なカテゴリの設定
【レビュー内容】
カテゴリに関してもアプリのテストが出来なかったので保留とさせて頂きますが、
子育てに関わるスケジュール管理・記録を目的としたアプリとのことでしたら、「Productivity」が適切かと存じます。
正しいカテゴリが選択されているかどうかは非常に重要です。
初回申請時は、「Health & fitness」で申請していたのですが、スケジュール管理や記録を目的としたアプリであるため、「Productivity」の選択をフィードバック頂きました。
カテゴリ: Kids & family について
申請前には、カテゴリを「Kids & family」で検討していたのですが、
対象のカテゴリを選択すると下記のような画面が表示されました。
とのことで、米国外でのアプリを配布することが出来ないとの記載があります。
気になってサポートから問合せをしてみたところ、下記のような返答がありました。
1.「Kids & family」の場合、現在USでのみ対応しており、
日本での対応は未定となっております。そのためこのカテゴリの使用はお控え頂ければと思います。
また、こちらのカテゴリは子供向けに作られたアプリに設定することを想定されています。
「Kids & family」のカテゴリは、主に子供が利用するアプリを想定されているため、
今回の記録アプリとは主旨が違う点と現状では日本は対応していないとのことでした。
その3. 確実にアプリが起動するサンプルボイスの設定
【レビュー内容】
1.Your sample invocation phrases do not always trigger your app. Please verify that all listed sample invocation phrases work correctly with the Simulator.1.Sample triggers do not work
Sample Triggerでは原則「Pronunciation + トリガーフレーズ（「〜と話す」等）」といったような、アプリが必ず起動するようなフレーズでご申請頂く必要があります。
例：「テストワンと話す」従いまして、以下のSample Invocationsではアプリ起動が確認できないため、承認致しかねます。
・育児日記に記録して
・育児日記に保存して
該当箇所を削除いただくか、本アプリがGoogleアシスタントで起動できる文言にご修正ください。
サンプルボイスに呼び出しパターンを記載しておけばそのフレーズでも起動すると思い込んでいましたが、
ドキュメントをよくよく読み返してみると、起動することをSimulatorで確認して下さいとの記載が...
今回はトリガーフレーズとしては登録していないので削除することで対応しました。
その4. ユーザが何を回答すればよいか分からないときのマイクオンは禁止
【レビュー内容】
2. During our testing, we found that your app would sometimes leave the mic open for the user without any prompt. Make sure that your app always says something before leaving the mic open for the user, so that the user knows what they can say. This is particularly important when your app is first triggered.2.Mic is open without prompt
ユーザが何を回答すればわからない（会話内容が終了したと思われる）場合、アプリ側がマイクをオープンにすることはActions on Googleのポリシーに反します。実際にアプリ内で下記のやりとりを行い、マイクがオープンになっていることを確認しました。
ユーザ：「太郎のおむつ交換」
アプリ：「太郎のおむつ交換を記録しました」→マイクが起動
この場合、アプリ側は新たに問いかけを作成し会話を継続するか、会話を終了しなければなりません。
想定では、
- ユーザ： 太郎のおむつ交換
- アプリ: 太郎のおむつ交換を記録しました。
- ユーザ: ありがとう
- アプリ: お疲れ様でした。 [終了]
みたいなイメージをしておりましたが、こんなの開発側の自己満足の流れであり、
実際に使う側となれば「どうやって終われば良いんだ」「次何喋ればいいんだ」ってなりますね。
会話のキャッチボールが音声入力としての基本でもあるため、
ここは他になにか記録するのかをユーザに問いかける形で修正することにしました。
Google Assistantは待ち状態を長時間続けるのか！？
昨日のAlexa Skillのエラーハンドリングのお話にて、
Alexaは８秒以上放置されるとaskのreprompt設定されたメッセージを喋り（多分設定したほうが良い）、更に8秒以上放置されるとセッションを終了します。
とのことで、待ち状態を時間で制限しているようなのですが、
Google Assistantでは、アプリ側からユーザに対して問合せたときに、1分以上何も発音しなくてもずっと入力待ちの状態になっており
（シミュレータ上のみの確認で、実機ではまだ試せてはいないです...）
一定時間でセッションを切るための設定や待ち状態が続いたときにアプリからユーザに対して再度問いかけてみる（出来るか知らないけど）
などの動作とかが必要なのかと少し感じました。
（詳しい人いたら教えてください><）
その5. 説明文に記載されている動作が少なくとも1つは動かなかった => 不具合
【レビュー内容】
During our testing, we were unable to complete at least one of the behaviors or actions advertised by your app. Please make sure that a user can complete all core conversational flows listed in your registration information or recommended by your app.「Unable to complete action described」
Descriptionの通りテストを行ったところ、期待する答えが返ってきませんでした。
ユーザー：「12時に太郎がお出かけしました」または「12時に太郎がご飯を食べました」
アプリ：「このアプリでは、おむつを交換、起床時間、就寝時間、お出かけ時間やご飯を食べた時間を記録することが出来ます。」
正しい返答が返されるように修正いただけますでしょうか。また、「12時に太郎が食事」とDescription通りではないが予想される話し方で話しかけたところ、
「このアプリでは、記録をつけるだけでなく、記録を確認することもできます。…」と、適当ではない文言の例外処理にはいってしまいます。
はい、お恥ずかしながら完全にデバッグ漏れでした。今回Descriptionに出来ることや発音のパターンなども細かく記載していたため、その内容をしっかりレビュアーの方でもテスト頂けたようです。
ここで得られた知見としては、下記の2つになります。
- Dialogflowで会話の文脈を細かく学習させる
- 「Fallback Intent」の適切な設定
Dialogflowで会話の文脈を細かく学習させる
Dialogflowの話になってしまいますが、会話の語尾の認識率は凄く良いと感じるのですが、
文脈理解は細かく学習をさせないといけないなぁという印象でした。
例えば、太郎くん（子供の名前と過程）のご飯を食べさせた時間を記録する時に
「ご飯を食べた」と記録するインテントに対して、
「太郎がご飯を食べた」とDialogflowに学習させていると
- 太郎がご飯を食べた
- 太郎がご飯を食べる
- 太郎がご飯を食べたよ
- 太郎がご飯を食べました
- 太郎がご飯を食べている
など語尾が多少変わってもしっかり認識してくれましたが、
「太郎が12時にご飯を食べた」とDialogflowに学習させている場合、
- 太郎が12時にご飯を食べた
- 太郎は12時にご飯を食べました
などは認識してくれるのですが、
- 12時に太郎がご飯を食べた
- 12時に太郎がご飯を食べました
など文章の順番が変わると、「ご飯を食べた」と記録するインテントに反応してくれず、
文章の意味が理解できなかったときに反応する「Fallback Intent」に反応してしまいました。
対策としては、学習させれば良いだけなのですが、
- ○○は、■■をした。
- ○○が、■■をした。
- ○○は、△時に■■をした。
- ○○が、△時に■■をした。
- △時に○○は、■■をした。
- △時に○○が、■■をした。
などの項目をそれぞれのインテントに学習させることで現状は対応しておりますが、このあたり何か良い設定方法とかがあるのかなというのは少し悩みどころです…
「Fallback Intent」の適切な設定
リジェクト理由にもありましたが、 「Fallback Intent」に引っかかったときは、
何を発音してよいかわからない時や正しく発音できていない時だろうと思い込み
「このアプリで出来ること」や「記録も見れるよ」的な内容を発音するようにしていたのですが、
結果的に会話としてなりたっておらず、音声入力の会話フローとしては残念な結果になってしまいました。
改めて 「Fallback Intent」に当てはまるときを考えてみると
- ユーザの発音が正しく聞き取れない、認識できず、違う意味で認識されてしまっている
- ユーザとしては一生懸命やりたいことを発音しているが、認識してくれない状態
- 音声入力でどのように認識されているのかを返してあげる必要がある！？
- ユーザとしては一生懸命やりたいことを発音しているが、認識してくれない状態
- 意図しない発音をしている
- ユーザとしてどんな機能や仕様で動いているかが認識できていない！？
- どんなことが出来るのか、同発音したらよいかヒントを返して上げる必要がある!?
- ユーザとしてどんな機能や仕様で動いているかが認識できていない！？
などなど、意図しない発音に対してもそれぞれの目的に応じて適切に会話を続けてあげないと、
ユーザとしてはイライラしてしまい結果的に離脱の原因につながってしまうかと思います。
このあたりは、会話の流れのエラー処理をしっかりデザイン設計する必要がありますね！
申請とレビューのスケジュール
公式サイト上には「数日でレビューできるように取り組んでいるが1週間程度はかかる可能性が」との記載がありましたが、
今回は早いときで申請当日、遅くとも2営業日以内にはレビューが行われておりました。
時期により期間は変わってくるかと思いますが、素早いレビューに感謝です。
| 申請回数 | 申請時間 | レビュー時間 | 待ち時間 |
|---|---|---|---|
| 1回目 | 2017年10月18日 16:59 | 2017年10月20日 17:55 | 約2営業日 |
| 2回目 | 2017年12月1日 3:05 | 2017年12月1日 14:41 | 当日 |
| 3回目 | 2017年12月4日 2:33 | 2017年12月5日 15:09 | 約2営業日 |
参考) Registering and Publishing Your App
今後
今回Advent Calendarの執筆と共に「リリースしましたー」とお伝えしたかったのですが、
残念ながらまだリリースすることは出来ておらず、まずはこれまで得られた知見を共有させて頂きました。
（リリース時にはまたQiita記事書きます！）
音声入力としての魅力は、個人的には両手が塞がっている時などの「ながら作業」にとても有効だと感じており、
「何かを記録する」ということにはとても向いているのかなと感じております。
Alexaの方もまだ触ったことがないので次はそちらでやってみたい！
まとめ
今回のリジェクトは、しっかりドキュメントを読み込んでいると当たり前のことが多かったかもしれませんが、
それぞれのレビューにおいて、レビュアーの方が機能面含めてとても細かく見られていたり、
またリジェクトの際にも指摘事項だけでなく、どのように修正するのが適切かを本当に丁寧に説明してくださるので、
開発側としても気持ちが良く、リジェクトの度にレビュアーの方に対して「毎度お手数おかけしてすみません...」という気持ちになってしまいました。
（日本の方が対応されているようなので、その点も安心感につながっているのですかね！）
このような経験が、アプリを申請される際の参考に少しでもなれば嬉しいです！
なお、Google Homeアプリの申請についてのTIPSは、下記記事も参考になりますので、是非！