「Android」タグアーカイブ

Dialogflowを使ったAIアシスタントアプリのプロトタイピング

コメントを残す

この記事は Goodpatch Advent Calendar 2017 – Qiita 8日目の記事です。
昨日は @enpipiさん、明日は @koyachiさんの予定です。

僕は普段、Prottと呼ばれるプロトタイピングツールの開発に携わっていて、今年はチーム内でデザインスプリントやユーザーテストも経験することができました。
そんな経験を生かして、最近流行りのAIアシスタントをプロトタイピングできる環境を作ってみました。

今回は、このブログでも以前とりあげた
Dialogflow(旧API.AI)を使って、AIアシスタントアプリをプロトタイピングしてみます。

DialogflowでAgentを作成する

DialogflowはGoogleアカウントでサインアップすることができます。
アカウントを作ったらさっそく始めましょう。

Agentの作成

まずはDialogflowでAgentを作成しましょう。
AgentとはDialogflowで作ることが出来る自然言語処理のモジュールです。

Default languageをJapaneseに設定しました。

作成に成功すると、 Default Welcome Intent が作成されます。
このIntentを選択して、User saysに何かキーワードを入れて保存してみましょう。

この状態で、画面右上の Try it nowに試しになにか文字を入れてみると・・・

認識してくれましたね！！

Welcome Intentは、Agentが起動された時に最初に応答するIntentです。
このタイミングで、対応する機能の説明を出力して次に自分で作成するIntentへ繋げるのが一般的な流れのようです。
もちろん、Welcome Intentをスキップして応答することもできます。

Intentを作る

さて、いよいよここからが本番です。
あなたの試したいアイデアをIntentで表現してみましょう。

簡単なプロトタイプであれば、特定のキーワードに対して固定のメッセージを応答するだけで作れてしまいます。
難しく考えなくても、プロトタイピングは検証するユーザーに実際に使っている場面を想起してもらえればいいんです。
(「オズの魔法使い」テストのように実装を前提としない手法も存在します。）

例えばこんな感じ。

Dialogflowは入力メッセージを学習して、Intentと紐付けることができるので、定義していない類似のメッセージであっても応答を返してくれます。
手間をかけなくても、テストしてもらうユーザーに自然な体験を提供できそうですね。

Androidアプリをさくっと作る

さて、Dialogflowの設定はひとまず置いておいて、今度は呼び出す側のアプリを作ります。

Dialogflowは、Google Assistantを始め、LINEやFacebook Messengerとのサービス連携に加えて、SDKを使ったアプリケーションへの組み込みにも対応しています。

Dialogflow SDKs

今回はAndroid SDKを使って簡単なAndroidアプリを作ります。
(自分にとってAndroidで作るのが一番速そうだからです。)

というわけで数時間使って作成したアプリがこちらです。
ChatUIのライブラリを使って、AIエージェント風のアプリを作成しました。
ymegane/DialogflowSample | GitHub

このプロジェクトの gradle.propertiesに定義している、CLIENT_ACCESS_TOKENにトークンを設定します。

Dialogflowのコンソールに戻って、トークンを取得しましょう。

動かしてみる

CLIENT_ACCESS_TOKEN にトークンを設定したらビルドして実行します。

動いていますね・・・！
超かしこそうなAIアシスタント（のプロトタイプ）があっという間に作れてしまいました。

おわりに

冒頭に挙げたデザインスプリントでは短い時間(1日とか)でプロトタイプを作ってユーザーインタビューを実施するという事もあります。
そんな時に、時間をかけずに出来るだけ実際に使っている場面を想像させることができるこのような手法は役に立つことがあるやもしれません。

今回は、Dialogflowの最も基本的な機能だけを使いましたが、EntityやWebhookを使えば、実際に使ってもらえる高度なサービスを作ることも可能です。
もうちょっと使いこなしていきたいですね。

ポエム

2017年はGoogle HomeやAmazon Alexa、LINEのClovaなど、AIアシスタントを搭載したスマートスピーカーと呼ばれる製品が日本に投入された年でした。

現状は、文脈の理解に限界があることや、利用できる機能を使う側が事前に把握しておく必要がある点など、一般の方がイメージするAIアシスタント(アイアンマンのJarvisみたいな)になるには、まだまだ越えるべきハードルが様々存在する分野だと思っています。

ただ、今の製品でも一旦使える環境を作ってしまえばかなり便利に使えることは確かです。
先日はかなりの安価でGoogle Homeが売られているのを目の当たりにして、これはひょっとすると本当に普及してしまうのかもしれない、と思ってしまいました。

今後も発展が楽しみな分野です。

Essential Phone PH-1を買ったのでステータスバーを見てみる

コメントを残す

ずいぶん悩んだんですが、Essential Phone買ってみました。

https://www.essential.com/jp

数日使ってみて、一番もやっとポイントであるステータスバーについてまとめました。
Androiderのみんな、Pixel2日本で発売されるといいな！こいつのことは忘れよう！

Essential社、そしてEssential Phoneについて

正式には Essential Phone PH-1です。

Essential社についてすごく簡単に説明すると、Googleの元祖Android責任者だったAndy RubinがGoogleを辞めた後に立ち上げた会社です。
発売前からすでに3億ドルの資金調達に成功したりして注目度半端ないです。

そんなEssential社の製品第一弾がこのPH-1と言うわけです。
ベゼルレスディスプレイ(画面端が極端に小さい)、アルミより硬いチタン合金のボディ、そして背面にアタッチメント方式で様々なモジュールを追加できる点なんかが特徴です。

ベゼルレスが活用されるのはWhiteListのアプリだけ

PH-1の上部には大きなフロントカメラがディスプレイの上に鎮座しています。
さて、アプリから見た時にこの領域はどのように扱われるのでしょうか。

答えは、すべてステータスバーとして扱われます。
標準的なAndroidではステータスバー高は24dpですが、PH-1では約53dpになります。

標準的なサイズのステータスバー

PH-1の開発者設定

また、Googleアプリを中心に、初期インストールアプリについてはこの大きなステータスバー領域に対応した表示が行われます。
一般のアプリの場合は、単に黒いステータスバーになります。

Google Play

Twitterアプリのスクリーンショット

Twitter

Androidでは5.0からステータスバー色をアプリごとに定義できるようになっていて、現在では独自のテーマカラーを指定するのが一般的ですが、PH-1ではこの指定は無視されます。

これは、独自のAPIやPermissionで実現しているのではなく、独自のWhiteListで管理されています。

また、Google Playでアプリとして配布されており、要望に応じて随時アップデートしていくようです。

なぜこのような仕様なのか

独自に定義した53dpのステータスバー領域が曲者です。

Material Design に照らし合わせてもステータスバーのサイズは24dpが標準です。
また、Android Framework APIとしてステータスバーの高さが定義されていないため、取得には少し工夫が必要です。

標準的なUIテンプレートに沿っている場合、このステータスバー高は意識する必要はありません。

意識するのは、例えばGoogle Photosのようにスクロール時にステータスバーにもコンテンツを描画し、かつToolbarも表示する場合です。
僕の知る限り、これを実現するにはfitSystemWindowなど標準の仕組みでは不十分で、ステータスバー分の領域を含んだ、通常より大きいToolbarを、フルスクリーンの画面に表示するしか実現方法がありません。
この時、ステータスバー分の高さを24dpなど固定値で指定してしまっていると、PH-1ではレイアウトが崩れてしまうのです。
後述する解決策を適用するとこの制限を回避できますが、この問題も顕在化してしまいます。

ステータスバーが使えないために、通常より大きな（しかしPH-1には足りない）ツールバーが表示されてしまう例。(Feedly)

おそらくEssentialは、影響のあるアプリが多かったため、安全策をとったのだと思います。また、Essentialとしては、現時点でこのアプローチから方針を変える気はないようです。

アプリ開発者としては、初期許可アプリのWhiteListと並行して、独自のPermissionを持つアプリは描画を許可するような作りが自然だったと思いますね・・。

ユーザーとしての解決策

このWhiteListは、Secure Settingsとして保持されています。
これを変更することで、任意のアプリにステータスバーへの描画を許可することが出来ます。
Secure settingsは通常のアプリでの変更は許可されていませんが、SDKツールであるADBを経由して特定のアプリに変更の許可を与えることが出来ます。

PH-1の場合は、 ESSENTIAL_LAYOUT_WHITELISTがその設定値にあたり、すでにこれを編集するアプリを作った開発者もいます。

1ユーザーとしては、今のところこの設定値を自分で編集することで大部分のアプリでステータスバーが使えるようになり、ある程度のモヤット感は払拭できます。

WhiteListに追加したTwitter

それでも、先程のFeedlyのようにアプリの実装に依存して、このようになることもあります。

Feedlyで強制的にステータスバーへの描画を許可してしまうとレウアウトが崩れる

SlackもDrawerがめりこむ。

開発者としてできること

  • ステータスバーの値は固定値で指定しない。
  • ステータスバーの影響がなく、PH-1でもいい感じに表示させたければ、WhiteListへの追加をEssentialに依頼する。

以上の2点です。重ね重ね、アプリの実装ですべてが解決できる手段を用意して欲しいです。

PH-1に思うこと

PH-2があるのなら、恐らくフロントカメラはめり込ませないのではないでしょうか。
現在のAndroid Frameworkではこのフロントカメラのめり込みをサポートできる十分な用意がありません。
将来のAndroidが何か対策を講じないかぎり、PH-2はGalaxyS8のような一般的なベゼルレスに落ち着くように思います。
PH-1のアプローチは、ユーザーにとっても開発者にとっても全く良い点がありません。ただの見掛け倒しです。

もっと言うと、すでに魅力的なハードウェアだけで勝負ができる時代は終わりました。
iPhone XであれPixel2であれ、その上で動いているアプリやクラウドサービスの受け皿でしかありません。いかにサービスを快適に使えるハードウェアかという視点しか一般ユーザーには意識されていません。

PH-1には独自のサービスなどは提供されておらず、OSも標準的なAndroid 7.1です。（Status barの件を除いて）
であれば、Pixel2に対して有利な点って何でしょう？（Pixel2はまだ発表されてもいないけど。
この視点で言えば、Nextbit Robinの方が幾分、魅力的だったと思います。
結果は残念でしたが。

相当にディスっておいた後になんですが、僕は昔からのハードウェア好きなので、このあたりのことを考えつつも、PH-1を買いました。このドタバタも楽しんでいます。
性能はすばらしく、ディスプレイも綺麗です。Android 8.0ももうすぐ対応してくれるようです。
開発者としてはPixel2も手に入れないと来年以降の開発が大変そうです😇

[追記] ステータスバーをコード上で取得するとどうなるの？

Statusbarのサイズ(高さ)を取得する。 | Qiita

override fun onWindowFocusChanged(hasFocus: Boolean) {
    super.onWindowFocusChanged(hasFocus)

    Log.v("MainActivity", "statusBar height=${getStatusBarHeight(this)}")
}

fun getStatusBarHeight(activity: Activity): Int {
   val rect = Rect()
   val window = activity.window
   window.decorView.getWindowVisibleDisplayFrame(rect)
   return rect.top
}

結果

Emulator(XXHDPI) : 72
PH-1 : 159
PH-1(WHITELIST) : 159

動的に取っていると、WHITELISTに入れてないアプリの場合、よりデザインが崩れそうだね！