タクシー車載器ならではの不具合を解決するログ
MoTはタクシーアプリ「GO」、決済の「GO Pay」、後部座席タブレットの広告表示、乗務員支援用アプリ、さらにMaaSにつながるスマートドライビングや次世代向けの開発も幅広く手がけている。
今回はタクシー車内にある車載器の開発と運用を担うMoT IoT統括部の松島氏と佐々木氏が車載器について解説する。車載器のなかでも中心的な役割を果たすのが、乗務員の使用する端末や後部座席にあるタブレットだ。これらはAndroidデバイスでできている。他にも車載器にはタクシーメーター、乗務員端末と接続するためのBluetooth機器、決済機、ドライブチャート（AI搭載のドラレコ）があり、MoTはこれらの車載器をハードからソフトウェアまで一貫して開発している。
タクシー車載器はタクシーに搭載されているゆえの課題がいくつかある。トンネルや山中などで通信が途切れる、あるいは寒さや暑さなど過酷な状況下で稼働することにより生じる不具合だ。そのためには稼働している車載器の状態を監視すること、障害や不具合の改善に役立つ情報を収集することが重要になる。
その鍵となるのがログである。佐々木氏は「車載器ならではの難しさ、逆に面白さがあります」と話す。一般的なスマートフォンであれば端末の所有者がいて、人間がアプリの起動や終了操作を行う。またそれは人間にとってある程度、心地よい環境で使われるということも意味する。しかし車載器はIoT機器。常時稼働しており、人間の操作がないことも多い。人間がアプリを注視しているとも限らないため、異常が起きていても気づきにくく、つまりユーザーからのフィードバックも得られにくいということだ。これは改善の機会を得ることが難しいというデメリットにつながる。
今ではタクシー車載器はタクシー業務には欠かせないものだ。顧客のGOアプリからの注文受付、料金の支払、広告など、タクシー業務を隅から隅まで支えている。もし車載器が機能停止すると業務に支障が出る。障害が起きても乗務員が状況を把握することは難しい。そのためログを収集し、分析することが重要になるのだ。
稼働状況を把握するために必要なログには次のようなものがある。まず乗務員用端末とタクシーメーターとのBLE（Bluetoothの低消費電力の通信モード）接続状況。乗務員用端末はタクシーメーターの情報を起点に動作するため、常時接続している必要がある。同様に乗務員用端末と決済機とのUSB接続状況。接続が切れると支払処理に悪影響が出る。加えて車載器のバッテリー（充電率や給電）状態、端末の温度、通信状態や通信量も必要だ。
特に最近ではキャッシュレス決済が浸透し、現金をあまり持ち歩かない人も多い。決済方法はクレジットカードだけではなく、電子決済も多種多様。もし決済機が正常稼働しないと顧客が支払いできない事態に陥ってしまう。
佐々木氏が「最も重要なログ」と挙げるのが乗務員の操作ログ。車載器は操作が介在しないことが多いものの、乗務員の操作は機能改善ための貴重な情報源となる。タクシー会社や地域により、独特な操作や運用をすることがあるためだ。例えば操作する順番を変える、あるいは何らかの操作をスキップするなど、MoTが想定していない操作が起こりうる。MoTがあらゆる運用状況を把握することは難しいため、ログから確認することが重要になる。
ログを解析することで、いろんな改善につながった。バッテリーや端末温度からはプログラムの効率化や、端末の配置を変更するように提案したこともある。端末間の接続状況からは頻度や傾向から接続不良の発生率を下げることにつなげたり、接続不良を通知する機能を追加したりすることにもつながった。また乗務員の操作ログからは操作ミスが多い機能のUIを直感的なものに改善し、想定外な操作にも対応できるように改善した。
ElasticsearchとBigQueryで実現する膨大なログの解析とその活用
「ログを分析することで改善につなげる」というと簡単そうに聞こえるが、ログの分析や管理はそう簡単ではない。なにせ量が多い。最近ではログデータは1日あたり数億ものレコード、数百GBものサイズに膨れ上がっている。必要な情報を適切に抽出し、またインサイトをもたらすように可視化していかなくてはならない。
ログの集積と分析に使うツールはMoTのなかで試行錯誤を続けてきたものの、現時点では短期データはElasticsearch、長期データはGCPのBigQueryに落ち着いている。
Elasticsearchは分散型でRESTfulな全文検索エンジン。MoTが採用した理由は、NoSQLなのでそのままデータを放り込めて、検索が簡単であるからだ。単語から全文検索も可能で、SQL的なもので詳細な条件指定も可能だ。加えてElasticsearchとセットで使えるデータ可視化ツールKibanaの存在も大きい。Kibanaのダッシュボードからは簡単にデータの集計や可視化ができて、ログの有効活用につながっている。
BigQueryはSQLが使えるDBMSでデータウェアハウスとしてよく使われている。もともとMoTのデータ分析基盤として使われていたため、それに相乗りするような形で使っている。分析の専門チームが長期間のデータを集計している。
ログ分析基盤はマルチクラウドで構成されている。基本的にはAWSで、BigQueryはGCPを使う。車載器からのログデータはALB（Application Load Balancer）を通じて、EKS（Amazon Elastic Kubernetes Service）のアプリケーションサーバーで処理され、Elasticsearchで分析し、Kibanaのダッシュボードで可視化される。
データを活用するユーザーが直接目にしているのはKibanaとなる。主に開発エンジニアと顧客からの問い合わせ対応を行うヘルプデスクがKibanaを参照している。BigQueryは分析エンジニアがデータの抽出や集計を行い、日々の利用実績などKPIを出している。
Kibanaは難しい構文を使わなくても検索しやすいのが特徴だ。下図はBluetoothで接続された機器の稼働状況。棒グラフの水色が正常で、赤が失敗を表す。ほとんど正常ではあるものの「100％を実現するために、まだやらなくてはならないことがあるのが現状です」と話す。画面下半分には失敗部分のエラーログが表示されていて、どのような状況で失敗したのかを把握できるようになっている。
ヘルプデスクもKibanaを参照することで、問い合わせに対応している。その90％はヘルプデスクで解決され、残り10％が開発への調査依頼となる。
先に少し触れた、独特な操作や運用についてもログから実態を把握することができる。標準的なタクシーのステータスでは、誰も賃走していない時は「空車」、アプリから注文を受け付けると「迎車」、顧客を乗せると「賃走」、夜間なら「割増」、目的地に到着すると「支払」となる。しかしまれに「迎車」にする操作をせず「空車」のステータスのまま顧客のところに向かうために、二重に注文を受けてしまう場合がある。こうした不具合はログから確認できるので、ここから多様な運用や操作に対応できるようにUI改善を進めることができる。
ログ解析について佐々木氏は「まだ課題はあります。何か起きた後の詳細調査はできるのですが、検知のアラートが課題となっています。サーバー監視だと、しきい値でアラートを設定することができるのですが、車載器の不具合はログに出ないものが多く、検知しにくいのです」と説明する。
ログ解析は「移動の未来」に何をもたらしたのか
MoTがログ解析の基盤を構築し、改善を繰り返しつつ運用を続けて4年になる。会社が統合したのが2年前なので、ログ解析開始前を知る社員は意外と少ない。松島氏は2016年に当時のJapanTaxiに入社したため、ログ解析がなかった時代を知っている貴重な一人だ。
松島氏によると、車載器の不具合は高温や通信状態が悪いなど特定の条件下でのみ発生するものが多いという。電話などのやりとりでどうしても解決できないと、現地に赴いて解析することもあった。
例えば「ちゃんと動かない」と苦情が来て、松島氏がオフィスで検証しても不具合が再現できなかった。結局現地に赴いて確認すると、ケーブルは挿さっていたものの運転の振動でケーブルが劣化し、断線と再接続が繰り返されていたことが原因と判明した。このインシデントは後にハードウェアの接続部分を強化するという改善につなかったものの、不具合が起きた場所が遠方だと移動だけでも大変だった。
こういうことは振動や過酷な気温などがないオフィスではなかなか気づけない。長時間ログを取れるようになり、素早く気づくことができた。遠方で起きた問題でも素早く対応することが可能になった意義は大きい。
松島氏は次のようなメッセージでセッションを締めくくった。「今日はログ収集の重要性とログ基盤を中心に紹介させていただきました。参考になれば幸いです。これをきっかけに『移動の未来を一緒に作って行きたい』、『その課題を一緒に解決したい』と思っていただけたら、ぜひお声かけください。興味があれば、いつでも遊びに来てください。雑談でも大歓迎です」
