ふっじいのブログ一覧

​以前から検証を続けていた「Android Auto（AA）接続時のトンネル内・地下ルートでのナビ精度（自律航法＝DR）」について、Otixを用いた詳細なログ解析と、実機（SZ700、DAF9Z等）の動作比較から、DAのハードウェア構造とAAのOSアーキテクチャの「真実」が完全に解明できたので、備忘録としてまとめます。

​これからDAの導入を考えている方は、絶対に読んで損はないはずです。

​1. 「車速パルス未実装」の地雷DAを見分ける法則

​まず結論から。AAでトンネル内でも自車位置を見失わない（DRを機能させる）ためには、DA側からスマホへ「車速パルス」や「ジャイロ」のセンサーデータが誠実に引き渡されている必要があります。しかし、一部の機種（SZ500やTY-1000A-Bなど）はこれが未実装です。

​検証の結果、地雷機を回避する強力な法則（リトマス試験紙）を発見しました。

​危険信号：背面のGPSコネクタが青い「FAKRA端子」＋「中国生産」 これらはグローバル向けの安価な「中華ODM」の基板を流用しており、日本の複雑な地下網を前提とした車速連携などハナから設計されていません。前述の機種以外にもALPINE DA7-WLがこれに該当します。



​本物の証拠：従来型コネクタ ＋「タイ（自社工場）生産」 PioneerのDMH-SZ700や、ALPINEのDA7Z / DAF9Zなどは、自社工場で組み上げられた本物のハードウェアです。Otixでログを抜くと、車速はもちろん、重力加速度やZ軸ジャイロの生データをスマホへ極めて高い精度でパススルーしていることが確認できました。

​2. Android Autoとマップアプリ（GoogleマップやCOCCHi）の「したたかな分散処理」

​SZ700で上信越道のトンネルを走行中、OtixでAAの緯度経度の更新頻度を監視したところ、驚くべき事実が判明しました。

明かり区間では1Hzで更新される絶対座標が、トンネル内（直進・定速）に入った途端、更新を「サボる（ほぼ停止する）」のです。

​これはバグではなく、Googleの極めてクレバーな「リソース最適化仕様」です。

​直進時はAAのDR演算をサボる： ステアリング舵角（ジャイロ）や加減速がない状態では、OS側での複雑なセンサー演算を止め、スマホの負荷を下げます。

​「車の速度」パーミッションのあるマップアプリが自力で補間する： その代わり、マップアプリはDAから送られ続ける「Display Speed（車速）」を常時監視し、速度データだけで直線を補間して自車位置を進めています。



​カーブで目覚める： カーブ等の大きなG（ジャイロ入力）を検知した瞬間だけ、AAが再計算を行い座標を補正します。

​OSで常にフル演算を回し、アプリに絶対座標を渡し続けるCarPlay（iPhone）の力技とは対照的な、ハードウェアスペックが千差万別なAndroidエコシステムを生き抜くための「水平分業アーキテクチャ」と言えます。

​3. 大橋JCTでGoogleマップが「グレーアウト」する理由

​この仕様を踏まえると、高精度なSZ700を使っていても、大橋JCTのような「急勾配＋急旋回の連続」という異常な環境でGoogleマップが音を上げる（カーソルがグレーアウトする）理由が論理的に説明できます。

​大橋JCTでは、AAのDRアルゴリズムが「サボる（エコモード）」ことを許されず、常にフル稼働での再計算を強いられます。結果、ワイヤレス接続等のオーバーヘッドも重なり、スマホSoCの演算リソースがパンクして「OSからの座標更新が追いつかなくなった（ギブアップした）」のです。

Googleマップはそれを見越して、OSの座標を見限り、車速（推測航法）だけでルート上を走り続けるという恐ろしい自己防衛システムを積んでいます。

​4. 結論：どのDAを買うべきか？

​結論として、ナビゲーション用途としてAndroid Autoのポテンシャルを100%引き出せる「間違いのないDA（自律航法対応機）」は以下の通りです。

​Pioneer DMH-SZ700 および DMH-SFシリーズ全機種: 異常なまでの超高精度・高リフレッシュレートでセンサーデータを吐き出すモンスター機。フローティング大画面のSFシリーズも中身はSZ700と共通の信頼できるアーキテクチャです。（ただし、あまりのデータ量にスマホ側の処理限界・熱停止には注意が必要）

​ALPINE DA7Z / DAF9Z / DAF11Z: オートバックスの展示機検証でもフルセンサー仕様（車速＋ジャイロ等の生データ）のパススルーを完璧に確認。WXGAの高精細液晶や物理ボタンの操作性も相まって、現在最高峰の選択肢の一つ。私はセカンドカーのスバルサンバー用にDA7Zを手配しました。

​ディスプレイオーディオ選びは「画面の大きさ」や「ワイヤレス対応」だけで選ぶと、トンネルに入った瞬間に痛い目を見ます。「タイ生産」かつ「従来型コネクタ」の機種を選ぶことが、迷えるDA難民を救う唯一の道標になるはずです。

※本検証は純粋なディスプレイオーディオ(DA)を対象としています。AAも使用可能なナビゲーション専用機（BIG Xやパナソニック等）は元々自律航法に特化しているため比較から除外しています

直近の掲示板やコメント等で「結局どの機種がAA（Android Auto）でまともに自律航法（DR）を使えるのか、一覧にしてほしい」という声が多く寄せられた。

そこで番外編として、今回の徹底検証や有志のOtixログ提供によって判明した「主要メーカー・機種別のAA側へのセンサー実装状況」をマトリックスとしてまとめる。

DA（ディスプレイオーディオ）は単なる「スマホの画面を映すモニター」ではない。トンネル内で自車位置をロストしないためには、車載器側が「車速パルス」に加え「ジャイロ（ヨーレート）」をはじめとしたDAに備わるセンサー情報を正しくAAへパススルーしているかどうかが全てを握っている。

ナビの精度について「安物だから仕方ない」「目的地はトンネルじゃないからスマホ単体で十分」と思考停止してしまうのは簡単だ。
しかし、大橋JCTのような複雑な地下迷宮で現在地をロストすれば、平気で30分以上の遠回りを強いられるのが現実である。

DAは「最新の地図と渋滞情報が使える」ことが最大のメリットだが、それはOSとアプリ、そしてハードウェア（センサー連携）が完璧に機能して初めて享受できる。
これからDAの購入を検討している方は、カタログスペックの「車速対応」という言葉だけを鵜呑みにせず、この実測データマトリックスをぜひ参考にしてほしい。

はじめに

価格コム掲示板等で紹介したナビタイムジャパン社の技術noteを端緒に、「車速パルスがAndroid Auto（以下AA）のナビ精度にどう影響するのか」を追求してきた本シリーズ。

今回はその完結編として、日本最難関の地下迷宮「大橋JCT〜山手トンネル」から、直線11kmの長大トンネル「関越トンネル」まで、実走による限界テストを敢行した。

検証結果を見る前に、まずAAとCarPlay（以下CP）における「自律航法（DR）の決定的な構造の違い」を整理しておきたい。ここを理解しなければ、各アプリの不可解な挙動の真実は見えてこない。

1. CarPlayとAndroid Autoの「自律航法」の根本的な違い

CPとAAでは、車載センサーの処理構造が全く異なる。

・CarPlayのDR構造（OS一括処理型）
CPは車速・ジャイロ・加速度などの情報をiOS側が一括で引き取り、OS内部で高度な「自律航法による完璧な座標」を生成する。ナビアプリは、iOSが補正し切ったその完璧な座標データを受け取って描画するだけだ。そのため、アプリごとのトンネル内挙動に大きな差は出にくい。

・Android AutoのDR構造（二層分離・アプリ依存型）
AAのDR処理は、以下の「2つの層」に分離している。

Ⅰ　 AA（OS）側のDR（Hardware Locationの生成）：
車載器から渡された車速パルス・Z軸ジャイロ・加速度等を使って、AAシステムが推測座標（Hardware Location）を算出する。しかし、センサー精度や通信負荷によって「信頼性なし」と判断すると、AAは簡単にこの座標更新を諦めたり、カクつかせたりする。

Ⅱ　ナビアプリ側の独自DR（Display Speed等による推論航法）：
OS側からのHardware Locationが途絶えた際、アプリ側がどう動くかで明暗が分かれる。GoogleマップやCOCCHiのように、OS側の座標を見限って「Display Speed（車速単体の生データ）」の積算補正に切り替えるものもあれば、movilinkのように「車の速度」権限を持たず、AAからのHardware Locationが途絶えたタイミングで自前の予測航法に切り替えるアプリもある。

この「AAならではの複雑な二層構造」を踏まえた上で、以下の実走検証データを見てほしい。

2. 検証環境
車両： ランドクルーザー70
機材： カロッツェリア DMH-SZ700（5Hz車速パルス出力）
通信： AAWireless2
比較アプリ： Googleマップ / COCCHi

3. 山手トンネル（C2）の戦い：マップマッチングの限界

まずはCOCCHiの挙動。山手トンネルのような複雑な線形の地下空間ではどうなるか。

▼検証動画①（COCCHi：熊野町JCT→西新宿JCT）


強烈な吸着力でルートからの脱線を防ぐCOCCHi。一見安定しているように見えるが、出口に注目してほしい。

▼証拠画像①（スクショ：山手トンネル西新宿JCT付近）


トンネル入口から西新宿JCT出口までの走行距離は約5.4km。当日は入口付近で渋滞が発生しており、ストップ＆ゴー（頻繁な加減速）を強いられる環境だった。

結果として、出口でGPSを捕捉した瞬間、なんと約600mもの「前方へのジャンプ（ワープ）」が発生した。実に11%以上の距離ズレである。複雑なカーブの連続に加え、渋滞による不安定な車速変動が、Display Speedの積算誤差を致命的に増大させてしまった結果だ。

4. 大橋JCT「魔の螺旋」の答え合わせ

次はGoogleマップ。大橋JCTの「急勾配かつ2周の右回りループ」という、ジャイロが最も狂いやすい極限環境でのテスト。

▼検証動画②（Googleマップ：大橋JCT→熊野町JCT）


トンネルの途中で、AA側のDR（Hardware Location）が限界を迎え、カーソルがグレーアウト（GPS信号喪失状態）した。しかし、ここからがGoogleマップの真骨頂だ。

OS側の座標に見切りをつけ、バックグラウンドで「Display Speed」を用いた独自の推論航法を回し続けたのだ。結果、画面上は現在地を見失った振りをしながらも距離は完璧に積算されており、C2本線合流時やトンネル出口でのジャンプは極小に抑えられた。

5. 関越トンネル（11km）で見たCOCCHiの進化と「真の理由」

最後に、群馬と新潟を繋ぐ直線11kmの関越トンネル。ここでのCOCCHiは、山手トンネルとは全く異なる顔を見せた。

▼検証動画③（COCCHi：関越トンネル群馬側入口→新潟側出口）


▼証拠画像②（スクショ：関越トンネル新潟側出口付近）


ご覧の通り、山手トンネル熊野町JCT→西新宿JCTのほぼ倍のトンネル走行距離にも関わらずジャンプは少なめに抑制されていた。
要因の一つとして、渋滞していた山手トンネルとは異なり、約80km/hでの安定した定速クルージングができたことが挙げられる。パルス間隔が一定であることは積算において非常に有利だ。しかし、ここまで劇的に精度が向上した「最大の理由」は、アプリ側ではなく「車載器（SZ700）側」にあった。

▼証拠画像③（SZ700のセンサー学習状況）


東京・新潟間の往復テストにより、トリップは864.66km、車速パルスは2,180,141回をカウント。SZ700内部の「3Dハイブリッド学習」が完了し、距離や方位の補正精度が極限まで高まっていたのだ。

つまり、関越トンネル突入時には、「定速走行という好条件」に加え、SZ700からAAに対して「完璧にキャリブレーションされた神精度のDisplay Speed」が提供されていた。COCCHiはそれを素直に積算するだけで、11kmの暗闇を誤差を少なめに走り切れたというわけだ。
結論：ハードウェアの誠実さとアプリの「頭脳」

SZ700は単にパルスを吐き出すだけでなく、自ら学習し、極限まで補正された「5Hzの車速パルス」をAAへ提供し続ける。

この最高峰の生データを、Googleマップは「OSの限界を補うための泥臭いバックアップ（独自の積算補正）」として使い倒し、COCCHiは「車載器が磨き上げた精度をそのまま活かした極限のトレース」へと昇華させた。

CarPlayのようにOSが全てを完璧に補正してくれる世界も美しいが、Android Autoのように「ハードウェアの誠実な出力と、アプリの賢いアルゴリズム」が直接ぶつかり合う世界には、技術的なロマンがある。

AA環境における自律航法の聖戦は、まだ始まったばかりだ。

前回の「AAが独自に推測航法（DR）を行っている」という記事には多くの反響がありました。今回はさらに踏み込み、Otixのログ解析と実走テストから判明した「ナビアプリの挙動の裏側」と「ハードウェアの限界点」を書き記しておきます。

​1. 「日本海をスムーズに北上する」奇妙な現象の真実

前回追加したスクショの通り、北陸道（南西へ進行）のトンネル内で、自車位置が「日本海を真北へ向かって一直線に走る」という現象が起きました。




​AA側のジャイロドリフトが限界を超え、COCCHiの「道路への吸着（マップマッチング）」が切れて海へ放り出されたわけですが、面白いのは「海の上でも自車アイコンの動きがヌルヌルとスムーズだった」ことです。

これは、位置の基準（ジャイロ）は狂っても、SZ700から提供される「5Hzの車速パルス」だけは正確にアプリ側へ届いており、COCCHiが「CAR_SPEED」の権限を使って点と点の間を綺麗に補間（アニメーション描画）していた証拠です。

​2. 優秀すぎるStradaが「moviLink」を殺すパラドックス

ここで面白い矛盾が生じます。「CAR_SPEED」権限のないトヨタの「moviLink」などは、トンネルに入ってGPS（位置情報）が途絶えると「進入時の速度でカーソルを進める」という擬似追従モードを持っています。

​しかし、フルセンサー（車速・ジャイロ・方位）を出力するストラーダを繋ぐと、トンネル内でもAAが「現在地、把握してます！（Hardware location: Available）」と宣言し続けてしまいます。

するとmoviLink側は「あ、まだトンネルじゃないんだな」と勘違いし、結果的に自前のトンネル補正機能が発動せず、カーソルがピタッと止まってしまうのです。優秀すぎるハードウェアが、逆にアプリのフェイルセーフを殺してしまうという皮肉な現象です。（ちなみにセンサー不足のSZ500は即座に白旗を上げるため、逆にアプリの擬似追従がスッと発動しますｗ）

​3. スマホの処理能力がナビの滑らかさを決める時代

Otixで監視していて気づいたのですが、AAの自律航法時の座標更新頻度は1Hz（秒間1回）未満に落ち込み、カックカクでした。

SZ700からは5Hzで高精度なデータが送られているのに、スマホ側（AAのOS層）で行うセンサーフュージョンの演算処理が重すぎて、スマホのSoCが悲鳴を上げている（コマ落ちしている）状態です。今後、AnTuTuスコア400万点超えのモンスタースペックのスマホを使えば、このDR計算のボトルネックが解消され、1Hzの壁を越えられるのか非常に興味があります。

​4. 失われた「方位（Bearing）」の謎

かつての名機「SPH-DA05」は方位データを出力できていました。しかし最新のSZ700やトヨタのシステムはこれを省略しています。

Google（AA）の厳格なAPIフォーマットに合わせて絶対方位を算出し、保証し続けるのは、メーカーにとってコスト（開発工数）が見合わないのでしょう。その中で、あえて方位出力を実装し続けているPanasonic（ストラーダ）の開発陣の狂気（執念）には頭が下がります。

​【まとめ】いざ、究極のテストコース「山手トンネル」へ

・座標の決定権はAA（OS）

・滑らかな移動の演出はCAR_SPEED（車速）

・道路への執念はナビアプリのマップマッチング

​この3つの力関係が完全に解明されました。

いよいよこれから、日本最大の地下迷宮「山手トンネル（C2）〜大橋JCT」へ実走テストに向かいます。大橋JCTの複雑な地下ループで、COCCHiの「吸着のゴムひも」がAAのジャイロドリフトに対してどこまで耐えきれるのか。

Android Autoナビゲーションの限界バトル、しっかりと観測してきます！

先日導入した純血種のディスプレイオーディオ「DMH-SZ700」。その圧倒的なセンサー出力（5Hz車速パルス＋3軸ジャイロ）の威力を試すべく、北陸道の長距離トンネルで純正ナビアプリ「COCCHi」を走らせてきました。

​結果から言うと、途中で道から外れて海の中を走り出しました。




​「えっ、SZ700の自律航法（3Dハイブリッド）ってポンコツなの？」と思った方、ちょっと待ってください。デバッグアプリ（Otix）でシステムログを解析した結果、ディスプレイオーディオとスマホナビの間に潜む「闇（深層仕様）」が明らかになりました。

​1. 「海ダイブ」の犯人はアプリではなくOSだった

​トンネル走行中、Otixのログを見て驚愕しました。GPSが届かないトンネルのど真ん中なのに、Android Auto（AA）側のステータスが「Hardware location（絶対座標）：利用可能」のまま出力され続けていたのです。

​通常、我々は「DAが車速やジャイロの生データをスマホに渡し、COCCHi（アプリ側）がそれを計算して地図にマッピングしている」と考えがちですが、違いました。

「Android Autoのシステム（OS）自体が、車載器のセンサーを元に独自のDR（デッドレコニング）演算を行い、弾き出した『推測絶対座標』をナビアプリに強制給餌している」のです。

​北陸道のような超長距離トンネルでは、どうしてもジャイロセンサーの微小な誤差が蓄積します（ジャイロドリフト）。

AAのDR演算がズレて「現在地は海の上です」という座標を吐き出し続けると、最初はCOCCHi側の「マップマッチング（道路に吸い付かせる補正）」が耐えていますが、乖離が限界を超えた瞬間に補正がプツンと切れ、自車マーカーが海へダイブするという現象が起きていたわけです。

​2. 繰り返される歴史：SPH-DA05の記憶

​長年のパイオニアファンならピンとくるかもしれません。この現象、かつてのスマホ連携DAの元祖「SPH-DA05」時代と全く同じ構図です。

​当時、野良アプリの「AppRadioSatteliteLinker」を使ってDRを行わせると、トンネル内で社外ナビアプリはよく海や山へダイブしていました。しかし、純正の「Linkwithアプリ＋ドコモドライブネット」の組み合わせだと、アプリ側で強烈なマップマッチングをかけていたため、絶対に道から外れませんでした。

現在も、「AAが吐き出すDR座標」vs「ナビアプリのマップマッチング吸着力」という、ソフトウェア同士の主導権争い（力比べ）がOSの裏側で繰り広げられているのです。

​3. Apple CarPlay (CP) との思想の違い

​ちなみに、Apple CarPlay（CP）の場合はアプローチが少し異なります。

CPは、車載器から上がってくるセンサーデータ（車速やジャイロ）と、iPhone自身のセンサーを「CoreLocation」というAppleの強固なフレームワークで一元管理（フュージョン）し、各アプリに最適化された位置情報として分配します。Appleのエコシステム内でガチガチに統制されているため、良くも悪くも「アプリごとの挙動のブレ」が少ない傾向にあります。

​対してAndroid Autoは、Google Play開発者サービスがDR演算をゴリ押しするため、COCCHiのように独自の優秀なマップマッチング技術を持つアプリと「解釈の違い（コンフリクト）」を起こしやすい、じゃじゃ馬な側面があると言えます。

​4. ハードウェア視点での最適解（ストラーダの狂気）

​この「AA自身がDR計算をしている」という事実を前提にすると、各DAのハードウェア評価が劇的に変わります。

​Panasonic ストラーダ（CN-CE01WDA）：神ハード 実はストラーダは、車速・ジャイロに加えて「方位（コンパス）」までAAに出力しています。コンパスがあれば「ジャイロドリフト（方位のズレ）」を常に補正できるため、AAのDR演算精度が飛躍的に向上します。ストラーダはAA運用において最強のチート機です。

​Pioneer DMH-SZ700：優秀な正統派 ジャイロと車速を5Hzで叩き込む優等生。複雑な分岐（地下JCT）の旋回ではジャイロが必須なため、十分な威力を発揮します。

​Pioneer DMH-SZ500：悲しき素質（※仕様詐欺のため取り外し済み） 車速しか出ない仕様だったSZ500。実はこれが正常に動いていれば、AAは「ジャイロが無いからDR計算は無理」と諦めて座標提供を放棄します（Hardware Location: not available）。するとナビアプリ側が「車載器からの車速入力による独自の推測航法」に切り替わるため、実は「直線トンネルなら絶対に海に落ちないコスパ機」になれる素質がありました。（※実際はAPIが死んでいるので論外でしたが）

​【まとめ】次なる舞台は「山手トンネル」

​トンネル内では、ナビアプリ側が「トンネル属性」を判別してAAの絶対座標をあえて無視（棄却）し、分岐点（ノード）でのみジャイロを活かすといったアルゴリズムの成熟が今後の課題になるでしょう。

​近日、日本最大の地下迷宮「山手トンネル（C2）〜大橋JCT」へ突撃します。

海ダイブを引き起こすAAのDR演算が、大橋JCTの複雑なループと分岐でCOCCHiのマップマッチングとどう噛み合うのか。自律航法テストの「本番」の結果は、また後日ご報告します！