ナビタイムが「データ活用」で開く新境地〜クラウド・AIを使って新事業を創る方法

2018年1月時点で、月間UUは4100万人。うち1割強の480万人が有料会員ーー。

これは、徒歩や電車、自動車、バスのようなさまざまな移動手段で、日本全国のありとあらゆる経路検索サービスを提供してきたナビタイムジャパンの数字だ。

2000年の設立以降、ナビタイムジャパンは「経路探索エンジン技術で世界の産業に奉仕する」を理念に、さまざまなユーザーの交通ナビゲーションを支援してきた。その過程で蓄積してきた各種データは膨大な量になる。

そこで近年は、データを駆使した新ビジネス（トラベル事業や訪日観光客に向けたインバウンド事業、交通コンサルティング事業など）を展開しているという。

こうした多角化の動きや、事業の裏側を支えるエンジニアリングについて伝えるべく、ナビタイムジャパンはさる1月30日にTECH PLAYで「ナビタイム Meetup #1」を開催。CTOやエンジニアによる話を通じて、一般に認知されている「地図・ルート検索のナビタイム」とは別の顔が見えてきた。

創業以来、重視してきたのは「データの精度とUX」

最初に登壇した取締役副社長兼CTOの菊池新さんは、「エンジニア集団としてのナビタイムジャパン」を紹介する中で、今後の開発戦略を説明した。

もともと乗換検索エンジンの研究をしていた菊池さんと、大規模道路ネットワークデータにおける経路検索の研究者だった大西啓介さん（現・代表）の2人が立ち上げたナビタイムジャパンは、今では社員数が約400名、エンジニアの人数が約330名という組織に成長した。

この日は仕事の都合でスーツ姿で登壇した菊池さんだが、「普段はスーツは着ない」とエンジニアらしい一面も

この成長を支えてきたのは、データの精度とユーザーの利便性（UX）をとことん追求する姿勢にある。

例えばナビタイムの自動車ルート検索で表示される「目的地までの所要時間」に関して、同社ではVICS（道路交通情報通信システム）から得る情報とプローブ交通情報（実際に道路を走行中の自動車から位置や車速などを受信して生成される道路交通情報）の2つを利用することで、到着予測時間の約90％がプラスマイナス5分以内になるまで精度を高めている。

また、2018年1月には、約12年をかけて全国のバス会社515社の運行情報をデータ化。紙で情報を入手するしかない路線情報も、社員の努力によってすべてデジタルに変換し、ナビタイムジャパンのサービス内では、全国全てのバス会社の時刻表・経路検索が可能になった。

その他、Amazon Alexaへの対応で、注目を集める音声アシスタント機能の開発にもいち早く着手。技術でユーザビリティを高めることに余念がない。

そんな同社の今後は、「マルチクラウド化」と「データ解析」という2つのキーワードに集約されるという。

「当社は2016年まで、データセンターを利用して約3500台のサーバを使っていましたが、そこから一気にクラウドへシフトしました。ただ、使い勝手の面でいくつかあるクラウドサービスそれぞれに良い点と悪い点があるので、現在はマルチクラウド＆コンテナ技術を使ってデータを運用する体制にしています」（菊池さん）

加えて、データ解析についてはバックエンドでのHPC（GPA/FPGA）活用で膨大なデータをリアルタイムに分析・提供する体制を構築。経路検索の処理時間で、CPUだと0.5秒かかっていたのを、GPUで0.1秒に短縮したという。

そして、最も力を入れて取り組んでいるのがAIの活用だ。

「一部のサービスでは、チャットボットのようなUXの向上につながる機能を搭載済みです。今後は、これまで人手をかけていた『地図や運行情報のデータ化』についても、AIでやれるようにしたいと考えています」（菊池さん）

マルチクラウドへの移行時に整えた運用体制とは

続いて登壇したのは、菊池さんの挙げた2つのキーワードに該当する業務を行っているお二人。

サーバーグループ プロジェクトマネージャ
萱島 克英さん

メディア事業部 兼 トラベル事業部 部長
毛塚 大輔さん

萱島さんは、ナビタイムジャパンが採用したマルチクラウドの体制を説明しつつ、コンテナ管理サービスとしてAWSのAmazon EC2 Container Service（ECS）とGoogle Cloud PlatformのGoogle Kubernetes Engine（GKE）を利用して感じたことを語った。

サーバーグループのプロジェクトマネージャとして、国内向けサービスのクラウド移行を推進してきた萱島さん

まず、同社がバックエンドシステムのクラウド移行を決めた理由は、アプリケーションサーバのコンテナ化でオートスケールする仕組みを導入すると共に、DevOpsにおける膨大なデータを処理するリードタイムを短縮するためだ。

ただしベンダーロックインを避けるべく、現在は乗換案内アプリ「乗換NAVITIME」をECS環境で、バス専用乗換案内アプリ「バスNAVITIME」をGKE環境で運用。この移行時に重視したことの一つが、環境構築手順のコード化だった。

その際、各ベンダーのプロビジョニングサービスを活用し、ECS環境ではCloudFormationを、GKE環境ではDeployment ManagerとKubernetesを使ったという。

「クラウド環境の構築手順をコード化する作業は非常に大変でしたが、この作業を先に進めておくと、他のサービスをクラウド移行する際に定義ファイルをコピーすれば容易にできるようになるなどのメリットがあります。今後のことを考えると、先に行っていてよかったと思っています」（萱島さん）

一方、サーバ監視では各ベンダーの提供しているツールだけではなくECS / GKEの双方でPrometheusとGrafanaを導入。これで必要なメトリクスを可視化するなどして、マルチクラウド化による管理工数の増加を抑える工夫も行っている。

「ただ、管理について補足しておくと、クラウドでオートスケールを導入した場合はスケールイン・スケールアウトが設定した通りに動作しない可能性もあるので、起動しているTaskやPod数を定期チェックするという作業が発生します。これだけは欠かすことができないため、ナビタイムジャパンでは朝と夕方の複数回、監視ツールでチェックする体制にしています」（萱島さん）

チャットボット機能を搭載・運用する際の注意点

では、残る注力分野であるデータ解析やAI活用は、どんな進展を見せているのか。

萱島さんの次に登壇した毛塚大輔さんによると、2016年に新規事業として始まった旅行の予約・プランニングサービス「NAVITIME Travel」が、社内で先駆的な事例になっているという。

2007年に入社後、メディア事業部や「NAVITIME Travel」の立ち上げでリーダーを務めてきた毛塚さん

「NAVITIME Travel」とは、ナビタイムジャパンが持つ精密なナビゲーション技術を活用することで、ユーザーの行きたい場所付近にある宿泊施設や観光スポットへの移動時間・位置関係が一目で把握できるサービスだ。

この特徴を活かして旅行プランの作成も簡単に行うことができるが、「何となく旅行に行きたくなった」「どこに行くかは決めていない」という状態でサービスを利用するユーザーも少なくない。

この点が、これまでナビタイムジャパンが提供してきた「目的が明確なユーザーに最適・最短なルートを表示するサービス」とは決定的に異なる。毛塚さんは、この目的が曖昧なユーザーに対するユーザビリティ向上施策として、同社の持つ豊富なデータとAIを組み合わせた機能を検討した。

その結果生まれたのが、チャットボットをUIの一つに採用するというアイデアだ。

「例えば『癒されたい』『景色のいいところへ行きたい』といったようなざっくりした希望をチャットするだけで、ボットとのやり取りを通じて行きたい場所が見つかるようになっています」（毛塚さん）

このチャットボットでは、ナビタイムジャパンが独自に開発した自然文解釈エンジンに加えて、マイクロソフトのクラウドプラットフォームMicrosoft Azureと、同社のAI自然言語解析サービスである「Cognitive Services Language Understanding Intelligent Service（LUIS）」を併用している。

また、ユーザーがWeb検索時や旅行中に見つけた「どこかは分からない場所」や「食べ物」に興味を持った時、写真をチャットボットに送信して質問すると、スポット名や詳細情報を返す「画像検索」も同時に提供。

これは、独自の固有表現抽出エンジンとマイクロソフトの画像検索API「Bing Image Search API」で類似画像を探し出し、その結果を「NAVITIME Travel」内で保有する10万件超の観光スポットデータを組み合わせることで実現した。

チャットボットと画像検索を運用する上で苦心しているのは、やはりというべきか「AIの回答精度を上げる部分」だという。

「今回は、先にユーザーストーリーマッピングを行って検索ワードと関連しそうなワードを定義しておき、それをAIに学習させました。『癒し』という言葉を含む質問を投げかけられたら、ボット側で『休みたい』などの関連ワードと紐付けし、検索結果としてスパのようなスポットを回答させる、というような仕組みです。

それでも、例えばユーザーの問いかけの文体が『だ・である』調か『です・ます』調かで回答が変わってしまうようなケースがまだ散見されるので、そういうズレを潰していくためにPDCAを回すのが大事だと感じています」（毛塚さん）

データ解析を「安価で簡単」にするのがエンジニアの役割

最後は、データ分析そのものを別のビジネスに活用したケースの紹介として、

交通コンサルティング事業部 エンジニア
塚本 周平さん

が手掛けた「道路プロファイラー」の開発事例を語った。

ナビタイムジャパンがナビゲーションサービスで培ってきたデータ・技術・ユーザー基盤を活かしたコンサルティングを行う塚本さん

まず、塚本さんが所属する交通コンサルティング事業がどんなことをしているのかを説明しておこう。

同社のWebページには、「ナビタイムジャパンが保有する『プローブ交通情報』や『検索実績』といった移動に関するビッグデータを活用し、道路交通分析や移動需要予測など、交通の最適化や街づくりへの改善提案などの各種コンサルティングを行う」と明記してある。

アウトプットとしては、警視庁向けの「東京都内の交差点渋滞情報」や、内閣官房まち・ひと・しごと創生本部に提供している「インバウンド促進に向けた情報」などがあるという。

「こういったデータ分析ビジネスでは、大容量データの保管やデータを高速に処理する分析基盤の構築、さらに分析結果を可視化するためのノウハウが必要になります。これらすべてを持っている当社ならではの強みを活かして、データを安価に、素早く、簡単に分析するためのビジネスを展開しているのです」（塚本さん）

中でも、塚本さんらが手掛けた道路プロファイラーは、「分析結果を可視化」して「簡単に分析する」目的で開発された。

「これは、ある道路を通った人がどこから来て、どこに行ったか？ を簡単に描画・分析できるようにしたWebアプリケーションです。用途として、例えば高速道路会社様が工事を実施した時、交通量や通過時間にどんな影響があったか？ などを調査する際に使われています」（塚本さん）

道路プロファイラーによる分析事例（ナビタイムジャパンのニュースリリースより抜粋）

開発に際して留意したのは、データの匿名化と、安価で使えるようにする点、そして結果表示の高速化だった。

最初に匿名化に関して、もともとナビタイムジャパンでは合意のないユーザーの個人情報は取得・利用できないようにしているが、他にも工夫を凝らしているという。

「道路プロファイラーでは、ユーザーの出発地点と到着地点の前後数百メートルをデータとしてカットすることで、自宅や勤務先などを特定できないようにしています。さらに、最低3人以上の交通データがないとデータを提供しないようにするなど、個別ユーザーの特定につながるようなリスクはすべて排除しています」（塚本さん）

そして、残りのポイントである「安価」と「高速化」については、AWSの提供するサーバレスクエリサービスであるAmazon Athenaを活用することで課題を解消した。

これでSQLを介してAmazon S3内に収集したデータを直接分析できるようになる上、データベースへデータをロードする時間も削減された。従来は同じ情報を分析・表示するまで80分もかかっていたところ、たった20秒で行えるようになったそうだ。

「データ解析に多大なコストと時間がかかっていた頃は、最初に何を分析するか？ の仮説を立て、次に社内承認を取って...としている間に別の仮説が出てくるような課題がありました。しかし、Amazon Athenaのようなサービスを使えば、高速で分析できる分、短期間でいろんな仮説を試せるようになります」（手塚さん）

今の時代、新サービスの企画〜運用を手掛ける際は、クラウドやAIに関する最新サービスを知っておく必要があるーー。毛塚さんの話や上述したナビタイムジャパンの事例は、まさにこの事実を象徴する内容といえるだろう。