Clova搭載のナビアプリ「LINEカーナビ」開発の舞台裏　スマートフォンと車を連携させる“SmartDeviceLink”の仕組み

LINEカーナビとSmartDeviceLink

庄司久人氏：こんばんは。LINEカーナビとSmartDeviceLinkの取り組みに関して解説させていただきます。今日は30分もいただいていて30分もしゃべられるかちょっと不安ですが、よろしくお願いします。

最初に自己紹介です。2015年にLINEに入社しまして、最初はLINEアプリを作っていました。その前はメーカーに在籍していました。

弊社には社内公募という仕組みがありまして、興味のあるポジションが新しくできたりすると異動することができまして、この制度を利用してClovaに異動してきました。

最初はClova Friends、キャラクター型のスマートスピーカーや、画面付き端末の通信周りをやったり、ソニーさんが出している「Xperia Ear Duo」というイヤホンにはClovaの機能が入っていて、その対応をやっていました。

去年から、iOS・Androidチームのエンジニアリングマネージャーをやっています、庄司と申します。よろしくお願いします。

最初に、本日お越しいただいているみなさんがどういうバックグラウンドをお持ちの方なのか質問をお伺いしたいと思います。iOS・Androidエンジニアだって方いらっしゃいますか？

（会場挙手）

けっこういますね、なるほど。企画畑だという方？

（挙手なし）

いない。PM畑？

（挙手なし）

ベリフィケーション、QAの方？

（会場挙手）

いらっしゃいますね。なるほど。R&D？

（会場挙手）

なるほど、デザインだっていう方？

（会場挙手）

おっ、デザインの方はいらっしゃるんですね。意外とiOS・Androidの方もいらっしゃるみたいなので、ちょっとAndroid・iOSのテクニカルな事例も出しながら説明しようと思います。

では、SmartDeviceLinkという規格について、聞いたことがある方？

（会場挙手）

なるほど。ではSmartDeviceLink対応の自動車を持っている方？

（挙手なし）

0人。なるほど。わかりました。

SmartDeviceLinkとはカーナビのアプリを作るための規格です。カーナビのアプリと言われると、「カーナビのハードウェアの中に入れなきゃいけないの？」と思われる方もいるかもしれませんが、そうではありません。あくまでスマートフォンで動くAndroidやiOSのアプリです。

最近ではSmartDeviceLinkでJavaScript対応も進めているので、将来的にはHTML5で書ける時代が来るかもしれません。今のところアプリとして多い事例はAndroidとiOSアプリになります。

「どうやってアプリ作るのか？」、すごく簡単に言うと、スマホアプリから画面のデータを送って、カーナビからタッチしたというイベントをもらって処理して返せば、なんとなくアプリができるような気がしますよね？　「CarPlayとかAndroid Autoと同じじゃないか」と言われたらそのとおりなんですが、そのような技術的なバックグラウンドで作っています。

人によっては「ハードウェアと作る」というと、自動車会社さんのすごく厳しいQAを通らなければいけないのではないかと思われるかもしれません。ですがバグがあったら基本的にはアップデートしたアプリをApp Store・Google Playからリリースすればいいという感じです。基本的に普通のAndroid・iOSアプリの開発と同じような開発サイクルで作ることができます。

SmartDeviceLinkとは何か？

意外とSmartDeviceLinkをご存じの方が多かったのですが、今回初めて聞くという方もいらっしゃると思うのでご説明したいと思います。

SmartDeviceLinkは、有志グループのコンソーシアムによって作られています。もともとはアメリカのFord Motorさんがはじめた規格なんですけれども、現在はスズキさんやトヨタさん、それからマツダさんとスバルさん、このスライドには載っていませんがダイハツさんなど、数多くの自動車メーカーが参加しています。

その中にゴールドレベルのメンバーとしてLINEも入っていて、みんなでSmartDeviceLinkを推進していきましょうというような団体になります。

先ほどGitHubを調べたら、Fordさんが2014年ぐらいにオープンソースで始めたようです。

日本の自動車メーカーさんも入っているので、今後流行っていくといいなと思っている規格になります。

具体的にどうやってSmartDeviceLinkが開発されているのかについて紹介させていただきます。先ほど少しお話しましたが、このプロジェクトはGitHubでオープンソースとして公開されています。

ここにあるのは車載器、いわゆるカーナビの中に入れるソフトウェア。それからiOSやAndroidのSDKなどが、基本的に全てオープンソースで入っています。

あとはエミュレータなんかもあるので、ご自身でビルドしていただいてLinuxにインストールしてしまえば、Android・iOSアプリのデバッグもできます。もちろん本物のカーナビのほうがデバッグはしやすいのですが、エミュレータも用意されています。

みなさんがイメージする自動車会社の雰囲気とここいら編が違うかなということを感じていただければと思います。

例えば、カーナビのハードウェアとスマートフォンアプリが通信をしている一番下のRPCのspecがマークダウンで書かれていたりします。

参考：https://github.com/smartdevicelink/rpc_spec/tree/4.5.1

ほかにも、毎週水曜日にFordさんやトヨタさんなど、先ほど名前を出した会社だけでなく、コンソーシアムのメンバーが一堂に会して水曜日の朝7時から電話会議を毎週やっています。

参考：https://github.com/smartdevicelink/sdl_evolution/issues/872

事前にGitHubでイシューを立てることが決まっていて、この中で論点整理をして、水曜日に、場合によっては投票を行ったりしています。「プランAがいいか、プランBがいいか」というディスカッションして、AとBでどちらがよいかを合議制で決めています。

自動車会社の間でフレキシブルに連携

このように、普段イメージする自動車会社の取り組みとは少しイメージと違うということを感じていただければと思います。

先ほども言いましたが、毎週朝7時にオンラインで電話会議をしていますが、それだけだとなかなか通じにくいところもあるので、オフラインの会もあります。Fordさんの本社がデトロイトにあるので、つい先日もデトロイトに行ってきました。

デトロイトでFordさんと議論している写真を本当は撮ればよかったんですけど、議論が白熱してしまって写真を撮るのを一切忘れてしまいました。

コンソーシアム参加企業間のコミュニケーションもかなり柔軟で、たとえばオフラインの会後の飲みの席でポッと出た話から「じゃあミーティングしよう」とすぐ行動に移るような、そんな雰囲気で作っています。これはなかなかないことだと思っています。

Fordのほとんどの車がスマートフォンとつながる

また、せっかく遠路はるばる十何時間かけてデトロイトまで行ったので、現地のサービスの実態をちゃんと調べておくのがエンジニアとしてものすごく大事だと思ったので、Fordのディーラーまで行って「SmartDeviceLinkの説明してくれよ」と話を聞いてきました。

いろいろ説明をしてくれまして。例えば、後ろにキャンピングカーをつなげている、いかにもアメリカンな感じの大きなピックアップトラック。

これもSmartDeviceLinkに対応していて、例えば「Pandora」でミュージックを聴いたり「AccuWeather」で天気を確認したり、北米ですと「Waze」というカーナビアプリがすごく強力で、それにも対応しています。

このクルマでアウトドアだとオフラインでつながらないんじゃないかと思ってたのですが、ほとんどのFordの車種はスマートフォンで動くということを現地で確認してきました。

また、ディーラーさんに話を聞くだけでは面白くないので、実際にクルマを借りまして、FordのEscapeの2018年モデルを借りました。いわゆるSUVで、実際どうやって動いているかを確認しました。

我々の「LINEカーナビ」以外に、「LINE MUSIC」アプリもSDLと連携して動かすことができます。実際に「LINE MUSIC」を起動して音楽をかけてみて、「ああ、動いた！」みたいな話をしたりしました。

LINEカーナビというアプリは、普通のiOS・Androidアプリと比べるとちょっと特殊なところがあります。何が特殊かというと、動作試験がすごく大変なんです。

例えばLINEアプリそのものであれば、自分で机の上でだいたい機能はテストできます。ところが、カーナビの場合は、ユーザーさんがどう感じるかは本当にクルマに乗ってみなければわかりません。ですので、実際にクルマに乗ってみるということをすごく大切にしています。

日本におけるSmartDeviceLinkの現状

では日本国内の情勢はどうなのかという話です。ダイハツさんが新型の「ROCKY」というクルマで、SmartDeviceLinkに対応します。これはカーメディアの前評判もいいみたいでして、けっこう売れるのではないかと期待しています。

それから、トヨタさんは新型カローラを発表しまして、そこからSmartDeviceLinkの対応をはじめています。トヨタさんでは「ディスプレイオーディオ」といっているのですが、これに対応している車種がさらにいくつかあります。

参考：https://toyota.jp/dop/navi/displayaudio/

「カローラ」「カローラ　ツーリング」「カローラ　スポーツ」以外にも、「グランエース」や「C-HR」「カムリ」が追加されていまして、今後もどんどん増えてくれればいいなと思っています。

コンソーシアムに参加している自動車メーカーが次々と対応していけば、日本の市場のデファクトになれるのではないかと考えています。

SmartDeviceLinkの技術的な仕組み

ここまで「SmartDeviceLinkとは何ぞや？」という話と、それから「国内でこんなふうに広がっていったらいいな」「こんなふうに広がっていってるんですよ」というお話をさせていただきました。ここからは、せっかくミートアップということなので、少しテクニカルな話をしたいと思います。

まずは、どうやって動いているかという話をさせていただきます。

みなさんから見て左側がスマートフォンで、右側がカーナビの画像です。LINEカーナビの中には、「SDL Proxy」と呼ばれているSDLのSDKを入れてあります。カーナビには「SDL Core」を入れる決まりになっています。

では、単純にカーナビと通信するだけかというと、実は自動車から車速のデータなどがあげられる仕組みになっています。

先ほども画像データをスマホアプリからカーナビに送って、Touch Eventなどを返せばアプリとして成立するという話をしましたが、より具体的に言うと、少なくとも現在のLINEカーナビの仕様としては、画像自体はH.264のVideo Streamingを流し込んでいます。Touch Event、あるいは車速、あるいはサイドブレーキを引いたというようなイベントは、LINEカーナビにはJSONのデータとして送られてくるようになっています。

そのままこれを実装してくださいと言われると大変です。とくにiOS・Androidエンジニアだと、「えー、自分でVideo Streamingするんですか」とか「JSON Data Eventをもらって、それ自分でモデルデータを作って判読するんですか?」といった感じでちょっと大変かなと思います。でも、SDL Proxyがこういった面倒なことをやってくれます。

iOSやAndroidエンジニアからすると、iOSでは基本的にはViewControllerに画面描画すると暗黙的にHead Unitの画面に出てくるようにできています。なので、描き込むと内部的にH.264に変換されてVideo Streamになります。Touch Eventなんかも通常どおり取れるようになっています。

ただ、少し大変なところもあって。カーナビアプリなのでOpenGLで書くことが多いのですが、OpenGLだと自分でレンダリングして渡してあげたりとか。

あとは、カーナビアプリなので普通のTouch Eventではないところもあって。例えばピンチ・ズーム、スワイプをやったりするのですが、そのmotion diretionのところは少し特殊なので、基本的にViewControllerで描けばいいのですが、そういったところはある程度自前で作る必要があります。

Androidのほうは実はもう少し大変でして、DialogのSubclassになっているように見えます。なので、Viewをはめること自体は、setViewすれば絵を描けるし、Touch Eventは来るのですが、画面の遷移をDialogで作るのはすごく大変です。

というのはDialogのSubclassになっているので、AndroidのOSのただのポップアップとして普通は使うであろうクラスの中で、LINEカーナビを作ってしまっているので、そこが大変です。

遷移系の処理で揉めたんですが、エンジニアの1名からの提案で、「最近、Googleさんが発表したAndroid Architecture Componentの中にNavigation Componentがありますよ。

Navigation Component自体はActivityやFragmentを前提とした基本的には設計だったんですが、View以外でもできることになっています。」これはいいということで、これを使ってGUIの遷移を処理しています。

参考：https://developer.android.com/guide/navigation/navigation-getting-started

Navigation Componentを見たことのない方のために、一応貼っておきました。けっこうAndroidのUIの遷移は面倒くさいところがあるので、Abstractに書けるようにしようよ、というのがあるので、それらを使っています。

iOSの場合はViewControllerで書けばいいのでこれらこのことはやる必要はありません。ですので、Androidはちょっと大変です、という感じです。

CarPlay・Android Autoとの比較

今まであえてあげませんでしたが、「CarPlayでやればいいじゃん」と思っていらっしゃるかもしれないので、比べてみました。

先日開催したLINE Developer Dayでも、「これってCarPlayなんですか？」「CarPlayとどう違うんですか？」と聞かれることが多かったので比べてみました。

SmartDeviceLinkとAndroid AutoとCarPlayを比べると、まず作っている人が違います。CarPlayはAppleさん。Android AutoはGoogleさん。SmartDeviceLinkはオープンソースでコミュニティが作っているので、みんなでディスカッションして、自動車会社とか、我々のようなアプリケーションベンダーが一緒に開発を行っています。オープンソースだったら必ず成功するかとか、オープンソースだったら何でもかんでも良いんだというわけではないんですが、自動車会社さんと一緒に議論をしながら作っているということが1つ違いかなと思います。

それから、CarPlayはiOSのみで、Android AutoはAndroidのみです。SmartDeviceLinkに関しては、iOSもAndroidも対応できます。なので、例えば、なるべく画面、同じ画像で作っています。基本的にAndroid・iOSでそれぞれのソフトを書かなければいけないのは当然ですが、やっていること自体はVideo Streamingなので、AndroidとiOSで同じようなGUIフローでアプリとして作る事が可能です。

それから作成可能なアプリですが、現状はAndroid Autoではナビゲーションアプリを作ることはできません。CarPlayでは可能なのですが、テンプレートに従って作成することになります。

SmartDeviceLinkですと、Video Streamingなので自分たちで自由に画面設計できます。逆に言うと、安全運転ができる、ユーザーさんの邪魔をしない、例えばぴかぴか光ったりしないような、アプリをちゃんと作るという責任は、アプリ事業者、つまり我々のような会社が負っていかなければいけないという設計思想になっています。

SmartDeviceLinkのプロジェクトで苦労したこと

ここまでSmartDeviceLinkの話をしてきましたが、やってきて苦労したことについてお話したいと思います。

走行試験をしなければ発生しないバグがありました。やはり長時間使われるので、例えば1時間、2時間、3時間のロングドライブでアプリが落ちないのは当然ですが、やっぱり大変です。

「3時間浜松から走ってきて、世田谷で動かなくなりました」と言われると再現がめっちゃ大変です。ですがこういったことは結構あります。結局そのケースにおける原因はメモリリークだったのですが、こういった問題が起こるので厳しいなと思います。

検証チームには実際に走っているチームもいるんですが「サービスエリアで落ちました」「そう言われましても」みたいこともあります。

それから、2つめは、日本でSmartDeviceLinkに詳しい人がなかなかいません。SmartDeviceLinkのSlackでFordの人に「ねえ、これってどういう意味？」みたいなことを聞いて、十何時間時差で返答が返ってくるみたいな状況です。

日本からの他の参加企業も、新規格であるSmartDeviceLinkに詳しいわけではないですし、どうすればいいかわからず、LINEのエンジニアが質問先に困って「うーん」と唸って前出の「Fordさんに聞いてみるか？」という話になったり。そんなところはなかなか大変です。

逆に言うと、SmartDeviceLinkに詳しい人がいないので、ここで詳しくなっておいて、SmartDeviceLink対応の自動車が増えてくれば、（LINEカーナビアプリが）良いポジションに入れますし、個人としても良いキャリアパスになるのではないかと思っています。

先ほども言いましたが、定例がなんと水曜の朝7時です。ですので僕は家から参加しています。起きてすぐの髪がぼさぼさの状態ですが、別に顔が映るわけではないので、いいかなと思って自宅から参加しています。

ただ、どうしても東京時間とデトロイト時間が絶望的に合わないという問題があって、これはちょっと大変です。水曜の朝に起きて眠い頭で電話会議に参加して、デトロイトの人がバーってしゃべって「LINEはどう思う？」と言われたりすることはなかなかつらいかなと思っています。

再現性の低いバグと向き合う

先ほど走行試験しないと発生しないバグがあるとお話ししました。AndroidやiOSのエンジニアの方であれば、「そんなのちゃんとテストコード書けばいいじゃん」とか「ちょっとQAの品質が悪いんじゃないの？」と思われるかもしれないので、実際にどのようなことが起こるのかをお話ししたいと思います。

トヨタさんに「新型カローラの発表イベントがあるからお台場で一緒にデモしようよ」と言われました。9月の発売です。

発表イベントは、お台場にある「MEGA WEB」というトヨタさんのショールームだったんです。お台場に大観覧車があるのをご存じの方が多いと思うのですが、そこのたもとにある場所でやることになりました。

当然ここまでデモの内容とか詰めて散々リハーサルしてきたんです。ところが、前日リハでなぜか今までちゃんと動いてたラジオスキルが動かず、エラーが返ってきてしまった。さて、なんででしょう？

わからないですよね。リハをやっている我々もぜんぜん想像していませんでした。このスキルはユーザーの現在位置の都道府県によって、再生できるラジオ局が切り替わるサービスになっています。

場所はお台場です。MEGA WEBというショールームの室内にカローラを設置して、その上でデモをやる。室内だとGPSの電波がすごく弱くて、現在地の判定が曖昧だったんですね。現在地の判定が曖昧だったゆえに、首都高の海の上の橋のところに現在地がありました。

そうすると何が起きるか？　橋の上なので住所がないんです。住所がないということは、当時の我々のスキルだと都道府県の判定ができなくて、結果エラーに。ラジオの再生ができませんでした。

これはいくらオフィスの中でテストしようとしてもなかなか出てこないタイプのバグでして。こういったこともあるので、やはり実際の環境で確認していくことには非常に大きな学びがあると感じています。

KPTを用いて継続的に改善

先ほどもお話しましたが、iOS・Androidエンジニアとはいえコードを書いていればいいというわけではなく、例えば現地に行って動作確認をしたり、クルマに乗ってみたり、あるいはあれは良かったよね、悪かったよねというフィードバックを常に受けながら改善していくことが大切です。

「KPT」はご存じの方も多いと思いますが、「この1週間、何があった」「何が悪かった」「もっとこうやればよかった」みたいなことをチームメンバーで常に出し合いながら、今週ミスしたことは来週解決するということ繰り返すことが大切です。

最後に、LINEカーナビは、スマホでダウンロードして使っていただけます。まだインストールしていないという方がいらしゃったらぜひインストールして帰っていただきたいのですが、カローラは大変人気車種なようで納車にも時間がかかると思いますので、本日は特別にカーナビを用意しました。

（会場笑）

画面がちょっと小さいので、あとで見たいという方は前に来て触ってみてください。できることは基本的にスマートフォンの横画面と似たような感じです。

ねえ、Clova、明日の天気は？

（Clovaが応答）

こんな感じで、まるでカーナビのように、かつ、例えば「音楽をかけて」とか、「家のクーラーつけて」など、従来のカーナビをイメージするとなかなかない機能だと思います。

当然ですが、スマホ単体でも使っていただくこともできます。そのために我々はVUI、声だけで操作を完結できる機能ですが、対応の自動車であれば、大きい画面で慣れたカーナビの画面の上で声で操作することができるという体験は、今後も推進していきたいなと考えています。

以上です。どうもありがとうございました。

（会場拍手）