Google Home アプリ、リジェクトされまくって分かった申請のポイント（その２）
前回のエントリーの続きです。自分用の覚書でもありますので、有用でないこともつらつらと書いていますが、その辺は読み飛ばすなどしてくださいませ。
ちなみに最近作ったGoogle Homeアプリはこちら。Google Homeでサンタさんにクリスマスプレゼントをリクエストできるというものです。ぜひお試しください。
お願いサンタ！
他にも公開中のアプリいろいろありますのでご興味ありましたら↓。Facebookでいいねでもしていただけるとたいへん嬉しいです。
VoiceApp Lab ー ボイスアップラボ
リジェクト３回目：with なりきり独裁者
３回目のリジェクトは、２本目のアプリ「なりきり独裁者」を申請したときです。
おうむ返しくんでおおよその感覚がつかめたので、少しだけ趣向を凝らしたものにしたいと考えました。音声ならではの表現として、テキストでなく、サウンドファイルでの応答も実験してみることに。
ユーザーを「独裁者」に見立て、何か喋るたびに、ウワーっと歓声が起こるのはどうだろう。歓声だけではアレなので、ブーイングや、笑いなども入れて変化をつけよう。という、単純な発想で完成したのが「なりきり独裁者」です。
なりきり独裁者
そしてやってきたリジェクトがこちら。
−Testing Instructions通りにテストが出来ないことを確認致しました。
・４回目のブーイングがなく歓声だけ繰り返される。
・悪口に反応がない。
アプリの仕様、テスト方法に変更が生じたのかご確認していただけますでしょうか。
これは原因は単純でございまして、サーバが落ちていたのでした汗。その結果、サーバにアクセスが届かず、インテント内にデフォルトで設定してあった「歓声」のみが繰り返されてしまっていたのです。
このときサーバをherokuの無料枠で使っていたのですが、起動時間超過に引っかかってしまい、アクセス制限されてしまっていたのでした。お恥ずかしい限りです。にわかサーバーエンジニアのありがちなミスでございます。
herokuの有料版は実験用途にはコストが見合わないため、急遽VPSを用意して、そちらに移して常時稼働にしました。これでなんとか動くはず。
自分のようなサーバ開発初心者に向けてアドバイスするなら、
ポイント④：サーバは確実に稼働すべし。
ですね。各所からツッコミが来そうですが、自戒をこめて挙げておきます。
サウンドファイルの注意点
リジェクトとは関係ありませんが、サウンドファイルまわりで気づいた点がいくつかあったので書いておきます。
サウンドファイルはmp3なら自由につかえる、と安易に考えていたのですが、いくつか縛りがありました。
ドキュメントを見ますと、
Format: MP3 (MPEG v2)
24K samples per second
24K ~ 96K bits per second, fixed rate
となっていました。このフォーマット合わせる必要があります。
さらに、全てのフォーマットで下記の制限がありました。
For all formats:
Single channel is preferred, but stereo is acceptable.
120 seconds maximum duration.
5 megabyte file size limit.
Source URL must use HTTPS protocol.
Our UserAgent when fetching the audio is "Google-Speech-Actions".
中でもサウンドの尺は注意が必要です。「120 seconds maximum duration」とありますが、これは１ファイルのことでなく、一回の応答の全ての長さを合わせて120秒以内におさめないといけない、ということなので、サウンドメインでコンテンツを作るときは気をつけましょう。
SSMLのお役立ちモジュール
サウンドはSSMLの中を使うことになります。SSMLとは、例えば、
<speak>こんにちは<audio src="hoge.mp3"/>よろしくね！</speak>
のような「HTMLライクなマークアップ言語」です。便利なのですがこれ、毎回整形するのってダルいんですよね。
と思っていたら、良いツールを発見しました。Node.js用のモジュールで、
ssml-builder
です。これを使うと、タグを直接書く必要がありません。下のように直感的に記述が可能です。
var speech = new require('ssml-builder');
speech.say('こんにちは');
speech.audio('hoge.mp3');
speech.say('よろしくね！');
var ssml = speech.ssml() // SSMLがレンダリングされる
いかでしょう。とっても分かりやすいですよね。このモジュールのおかげで凡ミスが減り、たいへん助けられました。使い方はこちらの記事に詳しいです。
[Alexa] SSMLの組み立てが超便利なssml-builderについて
リジェクト４回目：with なりきり独裁者
そしてすぐに次のリジェクトがやってきました。
APP側が会話が最後まで続かない場合（本アプリの場合はエンドレスに会話が続くことを意味します）は、Actions on Googleのポリシーに反しますのでご確認ご修正いただけますでしょうか。
修正例ですが、ユーザが「以上です。」というと会話アプリが終了するようにご修正頂き、また、アプリ内でユーザに会話アプリの終了方法をご提案いただけますでしょうか。
このあたりは、音声アプリを作ってみないと分からなかったことです。
前回の「おうむ返しくん」では、ひたすらおうむ返しをするため、終了方法についてそれほど考えていなかったのですが、一点だけ、終了用のインテントを作り「終了、ストップ、停止」などを検知して終了するようにしていました。これが良かったようです。
それを「なりきり独裁者」では、おろそかにしていました。
Google Homeはデフォルトで「止める」と言えばアプリが終了するようになっています。テスト段階からこれを使っていましたので、終了処理に問題ないと判断していました。
改めて実行してみると、「止める」というワードを知らなければ、ひたすら歓声が返ってくるのみで、どうしてよいか分からなくなるということが分かりました。これは確かに欠陥です。
とりあえず、おうむ返しくんの終了用インテントをコピーし、同様の終了処理を追加することにしました。
ここでちょっと感動したのは、Googleの審査スタッフが修正例をあげてくれた点です。
ユーザが「以上です。」というと会話アプリが終了するように…
ふつうアプリを終了したければ、前述したような一般的な終了ワードをハンドルしておけば良いはずです。
ですがこのスタッフさんは「以上です。」を使え、と言ってきたのです。これは、独裁者の演説というアプリの世界観を理解し、ユーザーの気持ちにならないと出てこないアドバイスだと思います。僕自身も思いつかないものでした。
ありがたく彼の案を採用し、「以上」で終了するように改良、またアプリの冒頭でそれについて触れるようにしました。
ちなみにAlexaではAMAZON.StopIntentやAMAZON.Cancelといった停止専用のインテントがあり、それをハンドルすることがマストなのですが、Google Homeは自前で用意する必要があるので、このようなミスも生じやすいです。注意が必要ですね。
このリジェクトから学んだポイントは、
ポイント⑤：終了の方法はきちんと用意すべき。コンテンツの世界観にあった終了方法あればベスト。
ということになります。
ここまでのまとめ
いかがでしたか？ まとめますと、
ポイント④：サーバは確実に稼働すべし。
ポイント⑤：終了の方法はきちんと用意すべき。コンテンツの世界観にあった終了方法あればベスト。
ということですが、今回は自分の無能ぶりが出てしまい、あまり有用な内容ではありませんでしたね。まあご容赦くださいませ。
５回目以降のリジェクトについてはまた後日書きたいと思いますので、ご興味ありましたら是非フォローください。
では、良いGoogle Homeライフを！