前置き

この記事は OPENLOGI Advent Calendar 2017- Qiita の１日目です。

⬆︎こんな感じのを作ります。

こんにちは WMS作ってますか
我々は、 未来のWMS を作っています。WMSを知らない人のために説明すると
Warehouse Management system の略で、物流のための在庫管理システムです。
興味のある方は、是非とも弊社に遊びに来て下さいね

最近、私は Google Home mini と Amazon Echo Dot を 買って毎日スピーカーとお喋りするのにハマっています❗️
今年になってGoogle アシスタント対応アプリを日本語で作ることができるようになったので、今回はスマートスピーカー🔉(Google Home )を使って未来のWMSを作ってみましょう!
Amazon Echo dot を使ってみたい気持ちはあるのですが、2017年12月1日現在では、招待制のため、買えない人もいるかと思うので、今回は手に入りやすい Google Home を使っていきたいと思います。
あと、現時点ではGoogleの合成音声の方がAmazonの合成音声よりなめらかな日本語で聞きやすいです。

業務システムとしてのスマートスピーカー

スマートスピーカーは家で使う形で現在は特化していますが、業務用途でもかなり活用できるのではないかと私は考えています。

タブレットやPCなどのGUI端末よりスマートスピーカーが業務システムとして優れている点を以下に挙げてみました。デメリットについては読者の皆様は死ぬほど思い付くと思うので、それらのデメリットを考慮しても以下のメリットが勝る場合は導入を検討してみてはどうでしょうか?

• 両手がふさがっているときも操作できる
• GUIでは何度もボタンを押して画面遷移が必要な機能を音声の自然なインタラクティブなUIで実現できる
• GUIがないので、開発工数が少なくてすむ
• ユーザーがOSの管理をしないので、端末ごとの環境統一がしやすい
• スピーカーなので現場でのアナウンス用の端末として使える
• 端末が6,000円程度から購入できるので業務端末としては格安で導入しやすい(10台買っても60000円❗️)
• 近くの人が何をシステムを使って実現したいのかわかる → 仮にスマートスピーカーが答えられない質問でも近くの熟練者が答えてくれるかもしれない
• GUI端末だと使っている人しか操作がわからないため操作方法が普及しづらいが、スマートスピーカーを使うと、実際に使っている様子が他の人にもわかるため、システムの使い方が普及しやすい
• 年配者などITリテラシーの低い人間にも操作しやすい
• コンシューマー向けの場合は、何を言えばどんな動作するのかユーザーはわからないため、それをカバーするUXを実現するのが大変だが、業務用システムの場合、事前にこの言い方で話しかけて下さいとマニュアルなどで周知すればよいので、その点については考慮しなくてよい
• マニュアルを作りやすい(画面のスクリーンショットとか要らないよ!)

次に開発にあたって知っておいた方がよい Google Home 周りの用語について説明します。

用語解説

Google Home

「OK Google」、「ねぇGoogle」 と話しかければ、Google Assistant が利用できるGoogle製のスマートスピーカーです。
2017年10月23日 にGoogle Home Mini という廉価版も発売されました。上位機種との違いは大きさと音質とボタン操作可能かの違いがあります。
実は、Google home mini では機体の上部をタッチすれば操作が可能だったが、バグが発生したため、オミットされてしまいました😂
参考 URL
https://japan.cnet.com/article/35108585/

普通のBluetoothスピーカーとしても使えるので、スマートフォンとBluetooth接続すればスマートフォンの中にある音楽を再生することが可能です。しかも、Bluetoothスピーカーとしては使用している間も 「OK Google」 といえば「Google Assistant」 の機能を利用できます。

公式サイト
https://store.google.com/product/google_home

Google Assistant

Google が 2016年に発表した音声アシスタントプラットフォームの名称、Google Home だけでなく、他メーカーが開発したスマートスピーカーでも使えます。
さらにAndroidではOS標準の機能として使えますし、iPhoneでもiOSアプリとして提供されています。
各々のハードウェアの特性(Androidフォンでは「自撮りして」というと自撮りをしてくれる。)によって、できることに違いはありますが、それ以外の中心的な機能については共通です。
「OK google 10面ダイスを2個振って」なんていうと、きちんとサイコロを振って目を出してくれるので、急なボードゲーム🎲にも最適です。

現在は以下の言語によって利用出来ます。
アルファベット圏以外では日本語だけが第一級の言語になっているみたいです。
Androidとは全然異なりますね💦

English, French, German and Japanese
 (also Hindi, Indonesian, Portuguese and Spanish via Google Allo)
英語、フランス語、ドイツ語、日本語   
(ヒンディー語、インドネシア語、ポルトガル語、スペイン語)

https://ja.m.wikipedia.org/wiki/Googleアシスタント
公式サイト
https://assistant.google.com

Actions on google

スマートフォンで言うところのアプリ。
サードパーティが開発するソフトウェア。インストール不要なので、内蔵ソフトのような感覚で使えます。

https://robotstart.info/2017/10/26/best_teacher.html

Google Assistant SDK

端末にGoogleアシスタントを埋め込むことができるSDK。主にraspberry pi で google アシスタントを動かすためのSDKですが、macOS Windowsなどでも使えるという噂です。

公式サイト
https://developers.google.com/assistant/sdk/

Dialogflow（旧 api.ai） と Actions SDK

Google Developers Japan - Google アシスタント対応アプリを日本語で開発してみよう より 引用

Dialogflow を利用すると自分でサーバーを用意することなく、アシスタント対応のアプリを作成できます。開発者はユーザの入力とそれに対応する応答のパターンを GUI 上で登録していくことで、簡単な会話型のアプリを作ることができます。またパターンに漏れたものや Dialogflow 上だけでは処理できない情報も、その後ろにフォールバック サーバーを設けることで対応できます。会話型エージェントシステムを作成する際に肝となる形態素解析の大部分を Dialogflow に任せることで、アプリの開発をより速く進めることが可能となります。

Actions SDK は Google アシスタントとの直接連携や Dialogflow のフォールバックを作成する際に必要な HTTP での JSON のやり取りを用意にするためのクライアント ライブラリです。現状では node.js 版が提供されています。定型句だけの対応であれば 直接 Actions SDK で連携して構いません。Dialogflow を利用する場合にも認証などが必要なときは Dialogflow のフォールバック先に Actions SDK を利用することで実装が容易になります。多くのサンプルも用意していますので、自分のユースケースにあったものを参考にしてください。

VUI(Voice User Interface) 論考

スマートスピーカーのインターフェースはGUIとは異なり声のみなので、GUIやCUIアプリを開発する時とはUXが異なります。その為、開発する前にある程度の指針と方針を決めましょう。

こちらに Actions on Google の チュートリアルの日本語訳 があるのでそれをを参考にして自分なりの指針を作ります。
Design in Action "Design Principles and Methodology"を日本語訳しました

既存のモバイルアプリやデスクトップアプリを「会話に変換する」ことに誘惑されないでください。会話はスピードとシンプルさをもたらしますが、他のやり取りの様式に基づいた際には簡単に過度に複雑となります。

どのようなタイプのユースケースが会話のやり取りにうまく移行するか、に関するいくつかのガイドラインがあります。

人々が思いつきで答えることができること。 基本的なユーザー情報、場所、時間、日付など、使い慣れた入力を求めるアクションです。ユーザーが知っている情報は、尋ねられたときに簡単に思いつくことができ、記憶しやすいので、今後の利用のためにアクション内で費やされる時間を最小限に抑えることができます。
迅速、しかし説得力のある有益なアクション。 これらは、通常、ユーザに費やされる時間がほとんどない場合に多くの利益をもたらします。たとえば、数秒で食べ物を注文して30分後に出てきたり、乗車を求めてタクシーが数分であなたの戸口に来たり、ということです。その他の便利なアクションには、答えを探したり、速やかに計算したり、情報の記録や追跡、携帯電話を取り出したり紙切れを探すといった、他の動作が一時中断しないようにする何かが含まれます。
本質的に声によく適したアクション。 これらは、通常、料理中にレシピを聞くことや、運転中に覚えておくことなど、ハンズフリーでやりたいことです。これらのタイプのユースケースは、実際に手で操作するやり取りを必要とする画面を備えたデバイスにも非常によく結びつきます。これは、画面とのやりとりには、UIが迅速かつハンズフリーな操作に特化している場合に、実行が容易になるタップやジェスチャーが必要になるためです。

UIで行うこと、行わないこと

行うこと

• 基本的な会話のルールと毎日の音声パターン（挨拶を含む）に従う。
• Grice’ Maximの原則を適用する。
• さまざまな発声スタイルに対応する。
• 人々が（教えることなく）何ができるかの直感的な例を提案する。
• システムが聞いていることを示すために、肯定応答を使用する。
• UIサウンドをより自然にするために、肯定応答をランダムにする。
• 重要な要求を明確にするために明示的な確認を使用し、要求を実行する危険性が低い場合は暗黙的に確認する。
• より意味のある（そして自然な）相互作用の機会として「エラー」を使用する

以上のことを元に以下の3つの方針を立てたいと思います。

• 実装時にメッセージを自分で読み上げてみよう

  • 読む分にはよい文章だとしても、聞くと良い文章とは限りません。そのメッセージをスクリプトに書き込む前に、自分で発声してみましょう。

• エラーメッセージに愛嬌を

  • エラーメッセージは音声として相手の耳に届くもので、読まれるものではありません。 同じエラーを何回も言われると腹が立ってきます。 言い回しを少し変えるなどして少なくとも5種類は用意しましょう。(5種類の理由は3種類だとユーザーにパターンで返してるなと思われやすいからです。本当はもっと多い方がいいと思いますが、あまりに多いと大変だと思うので、とりあえず5種類にしてみました。)

• できるだけ短く答えよう

  • 日本語は英語と異なり、動詞と否定が文の後ろになるので、文を長くするとユーザーをいらだたせます。できるだけ短く返すようにしましょう。特に業務システムは遊びで使われる訳ではないので、単刀直入に返信しましょう。

仕様

ここではちょっとした在庫問い合わせシステムを作ってみたいと思います。
ユースケースは 倉庫の人が特定の商品がどこに何個あるかを問い合わせるために利用するシチュエーションを想定しています。

ユーザー 「OK google 倉庫管理と話す」
google  「こんにちは。在庫管理です」
ユーザー 「ピカチュウのぬいぐるみは何個ある?」
google 「30個です」
ユーザー 「ぬいぐるみは何個ある?」
google 「ぬいぐるみに該当する在庫は3つあります。読み上げますか?」
ユーザー 「はい」
google 「1 ピカチュウのぬいぐるみ 2 ドラえもんのぬいぐるみ 3 みかんのぬいぐるみ です」
ユーザー 「2」
google 「ドラえもんのぬいぐるみは20個です」
ユーザー 「どこにある?」
google 「倉庫の入り口にあります」
ユーザー 「ありがとう 」
google 「どういたしまして」

こんな感じで答えてくれるシステムです。
商品を問い合わせたときに名前が似たような商品が4つ以上ある場合は聞いている人がつらいので、適切なメッセージをユーザーに伝える必要があります。
「候補の商品は10あります。もう1度聞いてください」 というようなエラーメッセージがよいでしょう。

続く……。

ここまでお読み頂きありがとうございました
次回(12/12)は以下の2つのブログなどを参考にしながら、上記の要件を満たすシステムを使ってみます。

Dialogflow（api.ai）とCloud Functionsを使ってチャットボットを作ってみた
Actions on Google と AWS Lambda で Google Home から Slack にポストする - ユニファ開発者ブログ

弊社でも、スマートスピーカーでWMSを使えるようになるのはなってはいないので、机上の空論的な部分がありますが、実践的なアドバイスなどをコメントなどで教えて頂けると幸いです。

私はペーペーですが、今後は毎日、弊社の誇る神エンジニアたちが素晴らしい記事を書いてくれますので、興味を持った方は、是非とも毎日こちらのアドベントカレンダーをのぞきに来て下さい。