雑記

◆ HTC Ariaをカーナビ化

6月頭にPocketWiFiをHTC Ariaに変更してたんですが、before iPhone(Nokia N82)で止まっていたことを後悔したり、でもafter iPhoneで最初に触れたのがこれだったことや、コンテンツが充実したこのタイミングで切り替えたのは良かったのかもと思ったりする日々を過ごしてます。

さて、先週、幕張-有明-三郷とドライブした時にひやかし半分でGoogle マップ ナビを試してみたところ、地図は当然最新のうえ*1、精度・案内とも全く問題なかった*2ので本格的に車載することに。

ナビで使うには電源供給できる物が必須なので、車載用のホルダーはElecomのFMトランスミッター内蔵スマートフォンホルダーLAT-MPSH01を選択。 次に設置場所を決める。ダッシュボード中央、バックミラーの横などを試すが視界を結構遮るので、ドライバー専用と割り切って運転席右に置くことに。ただこいつ、シガーソケット側のケーブル長が83cmしかない*3ため、ケーブルの延長＆引き回しが必要に。幸い運転席の右下にはヒューズケースがあるので、ここから電源を取ることにしました。以下、作業の模様を写真付きで。

カーショップに行って買ってきたターミナルソケット。

◆ Googleマップナビ vs. KENWOOD DVZ−919TV

高速道路の休日特別割引最終日ということもあり、昨日車載したHTC Ariaの運用試験をしてみました。目的地は那須温泉の鹿の湯。対するカーナビは11年前発売、地図も6年前で止まってる物です。以下、Google マップナビは「マップナビ」、DVZ-919TVは「カーナビ」と書きます。

経路探索

マップナビの目的地音声入力の認識率がすばらしく、しばらく遊んでました。ただ、「鹿の湯」では岐阜県の同名温泉が出てきて、かつ修正できない。住所を（音声）入力*1して回避。カーナビには音声入力機能は無いので、キーワード入力。

マップナビでは探索時の経路オプションとして、「高速道路を使わない」、「有料道路を使わない」が選択可能。カーナビも「標準」、「別ルート」、「距離」、「一般道のみ」が選べるので、ほぼ互角。ただ、カーナビの地図には北関東自動車道が存在していないので、外環道経由の道しか出てこないのは仕方ないところ。

あと、マップナビでは通過点の編集や追加ができません。カーナビでは通過点に加えて高速を使う場合に出入りするICの変更もできるので、このあたりの機能はカーナビの方が充実してました。

通信

最初、ナビを無視してガソリンを入れに近所のスタンドに向かったらマップナビがハングアップ。その後、アプリやOSを再起動しても直らず、調べてみると無線とネットワークの設定の「モバイルネットワーク」が無効になってました。どうも、

• 案内路から外れ、再探索する時にネットワークにアクセス
• 通信がタイムアウト
• OSがモバイルネットワーク全体が利用不可になったと判断して勝手に無効化
• 再起動しても無効化された状態のまま

という現象が起きたらしいです。電波が弱い所で曲がる所を通過してしまうと怖いかも。

音声案内

細かな違いがありました。

• カーナビは「この先、右（左）、○○方面です」と地名付きで案内するが、マップナビは「右（左）方向です」としか言わない
• 音声案内のタイミングが違い、カーナビは「3km先、左です」と残り3.2kmぐらいのタイミングで案内を始めた所で、マップナビは「2km先、左です」と残り2kmを切った時に案内し始める。一般道でも同じ調子なので、地名入りの音声案内はマップナビの今の実装では無理*2っぽい。
• 画面Off(電源ボタンちょい押し）でも案内し続ける。SAでトイレに向かっている時に「この先、右方向合流です」と言われてビビった。

表示

今日は薄曇りで時々日差しがあるような天気でしたが、電源管理ウィジェットで明るさを最大にすれば問題無しでした。電源管理ウィジェットはボタンを押すだけで3段階に明るさを切り替えられるので非常に便利ですね。

UIもよく練られていて、次のイベントまでの残り距離だけ大きな太字になってたりしているので、欲しい情報がまっさきに目に飛び込んでくる印象。あと、これは個人的な事情なのですが、モニタの位置が運転席右前とダッシュボード中央下なので、マップナビの位置の方が視線移動が少なく、前方を視界に入れたまま画面を見られる分、むしろ安全です。

マップナビは案内モードに入ると拡大・縮小はできないのかな。といっても標準の俯瞰ビューは見やすく、交差点や進入路では自動的に拡大されるので問題無いです。2D表示は無いのかと思っていたら、コンパスのマークを押すと切り替わるそうです。カーナビは2Dの北固定モードで使ってるんですが、できるのかな？ググってもよく分かりませんでした。

マップナビの渋滞情報はどこで見ても「この地域の渋滞情報はありません」にしかならないと思ったら、未対応でした。

あと、カーナビにあってマップナビに無く、ちょっと不便だと思った機能は、

• ハイウェイモード：先3つのIC,SA,PAとそこまでの距離を表示
• 交差点での信号の有無表示。前後に信号の無い交差点があったりする時に分かりやすい
• 車線案内：どの車線を走っておくと良いか教えてくれる。首都高では必須の機能。
• 到着予想時刻：ヘルプにはあるけど未実装？

経路の探索

近所の細かな道と、帰りをあえて郡山JCT経由にして高速での再探索も試しました。全体的な再探索のスピードはマップナビの方が速い*3んですが住宅街などでは逆に遅くなりました。おそらく、経路探索に使う道路の幅に制限を設けていないため、格子状のブロックに入ると組み合わせ爆発が起きているんじゃないかと。前に書いたハングアップも純粋に通信の問題というよりは、こちらのせいかも。もしかすると京都じゃ使い物にならなかったりして。

帰り道カーナビは白河IC、マップナビは鏡石PAを過ぎたあたりで折り返し誘導をあきらめました。これは両者とも距離で計算しているが、カーナビ側が北関東自動車道とスマートICの存在を知らないために、早々に外環道ルートをあきらめたんだと思われます。

精度

GPSの精度はマップナビの方が良かったです。ただし、マップナビはトンネルに入ると推定モードに入り、それなりにがんばってはいるけどどうしてもワープします。カーナビは車速も見ているのでずれません。一本道のトンネルはいいけどマップナビで首都高の案内は厳しそう。

地図

比較の余地は無いんですが、逆にマップナビの地図が細かすぎて、鹿の湯への入り口を勘違いしてとんでもない細道に突入。源泉だから最後はこんなもんかと勘違いして行き詰まり、100mほど崖沿いの1車幅の道をバックするはめに。

まとめ

マップナビは十分実用的で、Googleは地図の無料アップデートを続けると思われる以上、車速センサーなどのない後付けタイプのカーナビには本当に未来が無いかも。渋滞情報とかがいまだに利用可能になってないのは不思議ですが、逆に各メーカがやってるようなソーシャルな渋滞情報の共有をGoogleが始めたらVICSいらずにできそうな気もします。 一方で細かな機能では（11年前の）カーナビの方が行き届いているといった印象でした。逆に考えると、11年前のカーナビに機能的に追いついていないとも言え、地図さえ最新になれば今のカーナビで十分なんですが…。

余談

今回ナビの比較をして改めて思ったのですが、11年前のカーナビにふんだんに盛り込まれていた「おもてなし」の精神がAriaとの比較でいじった日本製Android端末に感じられなかったのは、ちょっと寂しいですね。日本メーカがんばれ！

◆ アクセストークン方式での情報保有機関どうしの直接通信はフラットモデルと同じぐらい論外、だと、思う

高木さんの6月26日付けのエントリ「技術音痴なIT企業CTOが国のWGで番号制度の技術基盤を歪める」を読みました。ベンダーが自社の利益誘導のために、そこで使われる技術を歪めるということは絶対にあってはなりません。しかし、このエントリにおいてその論拠となっている「技術論として完全に誤った情報」の部分については事実誤認があるのではないかと思うので、指摘しておきます。

高木さんは「情報保有機関AとBの権力者が結託して両者の保有する情報を突合しようとしても（情報連携基盤が結託しない限り）、直ちにはできないようにする」には、「アクセストークン方式」でも可能であるとして、次のようなサンプルを示しています。

「リンクコードXb」の指定でアクセス要求を受けた情報保有機関Bは、予測困難な受付番号を暗号論的乱数で発行し（トランザクションIDなどと呼ばれる）て、その受付が「リンクコードXb」についての要求だということを記憶する。そして、その受付番号をアクセス要求元である情報保有機関Aに渡し、情報保有機関Aはその受付番号でもって直接、情報保有機関Bにアクセスを要求する。情報保有機関Bは、受付番号からそのアクセス要求が「リンクコードXb」についてのものだとわかるので、国民Xの属性情報を情報保有機関Aに返す。

このサンプルでは、表向きは

• 情報保有機関Bに渡されるXbからXaの再現は不可能
• 情報保有機関Aに渡される受番からXbの再現は不可能

となっているため、XaとXbの名寄せは出来ていないように見えます。が、上の図をよく見ると、 情報保有機関Aから受番が渡された時点でXaとXbは情報保有機関AとBの間で共通のID "fd95fdae"で突合が完了しています。このため、初回だけは情報連携基盤を経由しないと情報を受け取ることはできませんが、2回目以降は(情報連携基盤を無視して)受け番"fd95fdae"を使って直接リクエストすれば、A-B間でそれぞれが保有する情報のやり取りができてしまいます。おそらく高木さんはXaとXbの突合さえできなければよい、と勘違いしてしまったのでしょうが、上の図の手法は

情報保有機関Aと情報保有機関Bが結託するまでもなく、自動的に（受番によって）A-B間のDBの突合がアクセスの度に行われていく

という重大な欠陥を含んでおり、わざわざ情報連携基盤を間に挟んでXaやXbを使うようにした意味を無くしてしまうため、複雑なだけで本来の要件を満たせない、それこそ請け負ったベンダーが潤うだけの設計になってしまっています。

受番により突合が完了しているという説明で分かりにくい人のために、高木さんの設計ではより直接的にXaとXbを突合できてしまう、という図も書いてみました。

• 情報保有機関Aは、自分が情報保有機関Bに問い合わせようとしている対象のIDがXaであることを知っているので、情報連携基盤から受け取った受番(fd95fdae)にXaを付けて送信することが可能
  • 情報保有機関Bは、受番(fd95fdae)がXbに対応するIDだと知っているので、この時点でXb = Xaの突合が情報保有機関B上で完了する
• 情報保有機関Bは、リクエストに含まれる受番(fd95fdae)がXbに対応することを知っているので、情報保有機関Aに対して、Xbを属性情報に付けて送信することが可能
  • 情報保有機関Aは、情報保有機関Bから受け取った属性情報がXaに対する応答だと知っているので、この時点でXa = Xbの突合が情報保有機関A上で完了する

ちょっと補足すると、結託して情報の突合をしようとしている情報保有機関どうしが律儀に通信プロトコルを守る義理は無いですし、そこを監視したりフィルタリングするぐらいなら、ゲートウェイ方式の方がはるかに簡単に安全なシステムを実現可能でしょう。

また、私の理解する限りでは、どんなに複雑な方法を使ったとしても、

情報保有機関BでXbであると認識可能な識別子を使って、情報保有機関A*1から直接リクエストを受ける

という条件を満たしている時点でAとBの間での突合が完了しますので、長島哲也さんの「この問題点は2者間通信の前提では解決できないため、3者間通信を前提とせざるを得ない」という主張は技術的にも間違っていないと思います。

ゲートウェイ方式で突合できない理由

高木さんの図をベースに、ゲートウェイ方式ではデータのやり取りがどうなるのかを示したのが上の図です。アクセストークン方式と比較して、

• Xaという識別子に関わるすべての通信は、情報連携基盤と情報保有機関Aとの2者間で閉じている
• Xbという識別子に関わるすべての通信は、情報連携基盤と情報保有機関Bとの2者間で閉じている

という点が重要で、この前提から外れていないが故に

「情報保有機関AとBの権力者が結託して両者の保有する情報を突合しようとしても（情報連携基盤が結託しない限り）、直ちにはできない」

という条件を満たしているのです。この状態で仮に情報保有機関Aと情報保有機関Bが結託してXaとXbの突合をしようとしても、手がかりとすべき情報が一切情報保有機関AおよびBに与えられていない、ということが見て取れるかと思います。

まとめ

• アクセストークン方式での情報保有機関どうしの直接通信は設計として論外、の、はず
• 各情報保有機関が持つ情報の識別子がどんな形であれ他の情報保有機関に渡った時点で突合は完了する
• 各情報保有機関のIDと紐づけられるすべての通信が、個々の情報保有機関と情報基盤の2者間だけで閉じている、という前提から外れてはならない

余談

PPIDや情報連携基盤については5/18にも書いてますので、よろしければこちらも読んでみてください。