• 車種別
  • パーツ
  • 整備手帳
  • ブログ
  • みんカラ+

ふっじいのブログ一覧

2026年09月04日 イイね!

【完全可視化】iPhoneに車速パルスは必要なのか? Core Location生データと「311mの誤差」が暴く真実

【完全可視化】iPhoneに車速パルスは必要なのか? Core Location生データと「311mの誤差」が暴く真実皆さんこんにちは。

前回の「DMH-SZ500の車速パルス闇検証」記事では多くの反響をいただき、ありがとうございました。

​CarPlay界隈で昔からよく言われる都市伝説があります。

『iPhone本体のセンサーが優秀だから、わざわざ車載器(DA)から車速パルスを取らなくても、ナビの精度は大して変わらない』というものです。

​確かに最新のiPhoneは、トンネル内でもマップ上のアイコンをそれっぽく動かしてくれます。しかし、本当に「車載器からの車速データ」は不要なのでしょうか?前回記事で車速が出るDAなら更に精度の向上が期待できるなんて憶測を書いたもので、エビデンスを取りに行く衝動に駆られました。

今回は、iOSの位置情報システムの心臓部「Core Location」の【生データ】を特殊なアプリで可視化し、長大トンネル内で極限テストを実施しました。そこで見えてきたのは、OSがつく「嘘」と、優秀な車載器だけが引き起こす「確定演出」でした。

​■ 検証方法と「数字の罠」

長大トンネル内で約30秒間停車し、以下の2パターンの生データを比較しました。

① iPhone17単体(スタンドアローン) ※実質的にSZ500等の手抜き車載器接続時と同じ

② iPhone17 + アルパインDA7Z(正常に車速パルスを提供するDA) にCarPlay接続

​ここで注目すべきは、アプリに表示されるHorizontal Accuracy(水平誤差)の数値です。実はこれ、実際のズレではなく「iPhone自身の自己申告(自信の度合い)」に過ぎません。この罠を知らないと、真実を見誤ります。

​■ 絶望のiPhone単体:「311mのワープ」



トンネル内で停車した時のiPhone単体のデータを見ると、誤差は「40.851677m」と表示されていました。

一見「なんだ、スマホ単体でも誤差40mなら優秀じゃん」と思うかもしれません。しかし、Speed(速度)の項目は処理不能を示す「-1m/s」になっていました。

​実はこれ、iPhoneが「大嘘」をついている状態です。

GPSを失ったiPhoneは内蔵センサーだけで自律航法を行いますが、停車時の座標を計算したところ、実際の停止位置から進行方向へ【約311メートル】もオーバーシュート(ワープ)していました。

車が停まったことを正確に検知できず、300m以上も先へ突き進んでおきながら「誤差40mくらいです(ドヤ)」と申告していたのです。さらに時間が経つと、システムも自信をなくし、この数値は徐々に114mへと悪化していきました。これがスマホ単体センサーの限界です。

​■ 真実のDA7Z:確定演出の「50mロック」



次に、正常なDA7Zに繋いだデータを見てください。誤差は小数点以下なしのきっちり「50m」と表示されています。

先ほどの40.851677mより悪化しているように見えますよね? しかし、これが車載器が完璧に仕事をしている「証拠」なのです。

​DA7Z接続時、トンネル内でもSpeed(速度)は実際の車の動きにピタリと連動し、停車中は「0m/s」を示しました。実際の座標のズレも皆無(狙った停止位置にピタリと停車)です。

ではなぜ誤差50mなのか?

iOSは、車載器から確実な車速データを受け取ると、車載器から出力される車速連携の自律航法(DR)という特殊モードに入るようです。このモードではトンネルを抜けるまで「50m」という数値から一切微動だにしなくなります。ちなみにトンネル外では水平誤差5m、垂直誤差9.5mにロックされます。

​つまり、トンネルに入った瞬間にAccuracyが10倍の50mに跳ね上がり、そこから「50mで完全にロック(固定)される」ことこそが、CarPlayが車載器の車速パルスを認識し、車速連携の自律航法を発動させているサインなのです。

​■ 結論:車載器の車速パルスは「絶対に必要」

いくらiPhoneのセンサーが優秀でも、スタンドアローンや車速パルスを持たない(あるいはSZ500のように握りつぶす)車載器に繋げば、裏側では「300mのワープ」と「自信喪失の迷走」が起きています。

​トンネル内でマップがフリーズしたり、分岐を通り過ぎてから現在地が飛んだりするのはこのためです。

本当にCarPlayで使えるナビ環境を構築したいなら、「確実に車速パルスをスマホ側に提供し、トンネル内でのspeed(m/s)表示の継続と水平誤差50mロックを発動させられる車載器」を選んでください。カタログスペックには絶対に載っていない、生データだけが語る真実です。
Posted at 2026/09/04 01:33:37 | コメント(0) | トラックバック(0)
2026年09月01日 イイね!

【闇を暴く】DMH-SZ500の車速パルスはナビに一切使われていない件(CarPlay徹底検証)

【闇を暴く】DMH-SZ500の車速パルスはナビに一切使われていない件(CarPlay徹底検証)皆さんこんにちは。
今回は、パイオニアのディスプレイオーディオ「DMH-SZ500」のナビゲーション精度、特に「車速パルス(車速信号)」の闇について、徹底的に検証した結果をご報告します。

■ 発端:トンネルで完全に迷子になるAndroid Auto
事の発端は、SZ500でAndroid Auto(AA)を使って長大トンネルに入った時のこと。なんと自車位置が完全にフリーズするか、おかしな挙動をしてナビとして全く使い物になりませんでした。
取扱説明書には「車速信号を車の走った距離の検出に使用します」としっかり書かれているのに、どう考えても車速パルスを拾っている動きではありません。ただしCarPlayでiPhoneを接続した時は、車速連動しているような挙動が確認出来ました。

そこで、本当に車速パルスが機能しているのか、疑問に思って「徹底的な物理テスト」を実施することにしました。

■ 検証1:CarPlay接続時に車速線を物理的に外してみた
助手席に段ボール箱を持ち込み、SZ500を仮組みして「車速パルスを一切繋がない状態」でトンネルを走行してみました。使用したナビアプリは全てGoogleマップです。AAやiPhone17スタントアローンと結果を比較します。

結果は以下の通りです。

SZ500+AA(moto g64/車速線あり): 推測航法が起動しトンネル進入時の車速で動く。トンネル内停車しても出口まで進む。

SZ500+CP(iPhone17/車速線あり): 車速連動で正常に動く

SZ500+CP(iPhone17/車速線なし): 車速連動で正常に動く

SZ500+CP(iPhoneSE2/車速線なし): 車速連動で正常に動く

iPhone17スタントアローン:推測航法が起動しトンネル進入時の車速で動く。トンネル内停車しても出口まで進む。

お分かりいただけたでしょうか。
CarPlay(CP)は、車速線を繋ごうが繋がまいが、iPhoneが最新の17であろうが古いSE2だろうが車速連動で正常に動いてしまうのです。実は新しいiPhone17のセンサー性能が優秀過ぎてこの結果になっている事を想定し、わざわざ古いSE2を親から借りて再びトンネルに向かったのですが結果は変わりませんでした。これはつまり、「CPが正確に動いているのは、SZ500が車速パルスを提供しているからではない」という物理的な証明です。ちなみに車速パルスを提供しているSF700の場合、車速線なしだとCPでもトンネル入口でフリーズするとの事です。つまりいくらiPhoneのセンサーが優秀とはいえ、車載器側から車速(車速線なしなら常に0パルス→停車)が提供される環境では、Core locationはそちらを信頼し優先すると言う事です。

・DA7Z(車速線あり)AA 版Googleマップトンネル内停車中


・SZ500(車速線なし)CP版Googleマップトンネル内停車中

ほぼズレなし、iPhone恐るべし!

■ 検証2:車内でiPhoneをぶん回す(ダメ押しテスト)
CPが正常に動いているのは、単に「iPhoneのセンサーとCore Locationのアルゴリズムが優秀すぎるから(スマホ単体でゴリ押ししているだけ)」という仮説が立ちました。
これを証明するため、旧型のiPhone SE2をSZ500にCP接続し、トンネル内走行中と外で停車時に車内で端末をぐるぐる振り回してみました。


結果……トンネル内走行中に端末を振り回しても、全く動じません。iPhoneの加速度センサーは定常的な入力のみ信頼し、突発的な入力はノイズとして処理するようです。
停車時に振り回すとディスプレイオーディオ上の地図が、私の手の動きに合わせて激しく荒ぶりました(笑)

SZ500が車速パルスや車載ジャイロのデータをCP側に提供してないため、Core Locationが端末側のセンサーをフル活用しているようです。ただしiPhoneのCore Locationは全てのセンサーをフュージョンする仕様の為、車速やセンサーを提供している車載器でも同様の結果になる可能性はあります。

■ 結論:SZ500とは何者なのか?
一連のテストから導き出される結論はたった一つです。

「SZ500は、ナビアプリに対して一切のセンサー情報(車速パルス等)を提供していない。ただ映像を映して音声を増幅しているだけの『高級な外部モニターとアンプ』である」

兄弟機種のSZ700やSFシリーズは、実際に車速パルスを処理してナビに提供する機能を持っています(だからAAでもトンネルで現在地をトレースします)。しかしSZ500は中華ODM機のため、車速パルスを「走行中の動画視聴をロックするための単なるスイッチ」としてしか使っていません。その唯一の機能もパーキング線をGNDに接続すると機能停止します(笑)

それにもかかわらず、パイオニアはシリーズ他機種の取扱説明書やFAQの文章をそのまま流用し、「走った距離の検出に使用する」と嘘の記載をして販売していました。(※ちなみにメーカーに問い合わせたところ、「FAQと取説の記載は誤記でした、修正します。アップデートでの対応予定もありません」と開き直られました…)

■ まとめ

iPhoneユーザー(CarPlay): iPhoneのセンサーが優秀すぎるため、SZ500がポンコツでも2km程度のトンネルであればカバーしてくれます。トンネル内分岐が無ければとりあえず使えます(SZ500の手柄ではありませんが)。ただしiPhoneユーザーでもSZ500を選択する理由は全くありません。車速が出るまともなDAであれば更に精度の向上が期待できますし、SZ500並みの精度で妥協できれば、エンタメ性に優れたケンウッドや値段の安い中華DAも視野に入ってきます。

Androidユーザー(Android Auto): トンネルが多い地域を走る方は、絶対にSZ500を買ってはいけません。容赦なく自車位置を見失います。素直にSZ700やSFシリーズ、アルパインZシリーズを買いましょう。

以上、購入を検討している方の参考になれば幸いです!
メーカーの「仕様(誤記)」には気をつけましょう……。
Posted at 2026/09/01 23:14:15 | コメント(0) | トラックバック(0) | 日記
2026年08月30日 イイね!

【最終検証】CarPlayとAndroidAutoの自律航法(DR)の決定的な仕様差と、奥只見シルバーラインでの極限テスト

【最終検証】CarPlayとAndroidAutoの自律航法(DR)の決定的な仕様差と、奥只見シルバーラインでの極限テスト皆さんお疲れ様です。

以前のブログで「Android Auto(AA)接続時のトンネル内自律航法(DR)の仕組み」について解説しましたが、本日、日本屈指の過酷なダンジョン「奥只見シルバーライン」での実走テストを経て、Apple CarPlay(CP)とAAの決定的な仕様の違い、そして「なぜSZ500のような地雷DAが生まれてしまったのか」の全貌が完全に解明できたので記録しておきます。

1.CPとAAの自律航法、その決定的な「要求仕様」の違い

一部の機種(SZ500やクラリオンTY-1000A-Bなど)で、「CPでは自律航法が効くのに、AAでは一切効かない(0km/hのまま)」という奇妙な現象が起きています。これは、両OSが車載器に求める「データ形式」の違いと、車載器側の「仕様のデグレード(手抜き)」が合わさって起きる悲劇です。

■CarPlay(Apple)の要求と、取説記載の「嘘」:
CPは、車載器に対して「生の車速パルス(Wheel Ticks)」を要求します。車載器は車両からの車速パルス信号をカウントしてiPhoneに横流し(パススルー)するだけで良く、複雑な距離や速度の計算はiPhone側の強力なCPUが勝手にやってくれます。
ここで重要になるのが、SZ500の取扱説明書にある「車の走った距離を検出するために使用します」という記載との決定的な矛盾です。単にパルスの回数を数えてスマホにパススルーしているだけの処理を「距離を測る(検出する)」と称するのは、技術的にどう見ても無理があり、事実上の虚偽記載と言わざるを得ません。
さらに言えば、SZ500にはそもそもジャイロや加速度センサーが搭載されていません。そのため、いくらCPでパルス連携ができていたとしても、フルセンサーを積んだSZ700やSFシリーズ他機種と比較すれば、CPでの自律航法精度自体も劣る可能性が極めて高いです。

■Android Auto(Google)の要求:
一方AAは、車載器側で計算済みの「実際の速度(Display Speed:m/s)」を要求します。これを出力するためには、車載器のファームウェア内に「車速パルスとGPS移動距離をすり合わせて学習するキャリブレーション機能(センサー学習機能)」が絶対に必要になります。



つまり、SZ500のような中華ODM機は、この「センサー学習ロジック」をファームウェアに端から備えていません。生パルスを流すだけのCPではたまたま動いてしまうため、メーカー側は「AA向けの開発・実装」を怠ったまま、DMHシリーズの公式FAQ(【ディスプレイオーディオ】Android Auto の利用方法やポイントについて)に何の検証もしないで本機を追加し発売してしまった。これが「AAに車速情報を提供します」という悲劇を生んだメカニズムの正体です。
AAの自律航法は、「①車載器(パルス→速度変換)」「②OS(ジャイロ監視と座標補正)」「③アプリ(速度ベースの直線補間)」という三層の水平分業で成り立っています。第一走者である車載器がサボれば、当然システムは崩壊します。

※CP仕様のブラックボックス化について
Apple CarPlayの要求仕様は、強固なMFiのNDA(秘密保持契約)に守られているため、公式な仕様書(エビデンス)は表に出てきません。
私自身、過去にSZ500とiPhoneを接続してトンネル内で検証を行った際、「自律航法がしっかりと機能し、車速に連動している」という事実自体は確認できました。しかし、CPはAAのOtixのように内部通信をモニタリングできる手段がなく、完全なブラックボックスです。そのため、当時は「車載器からのパルスを拾って連動しているのか」、それとも単に「iPhone側の内蔵センサーが優秀すぎて単独で推測航法を成立させているだけなのか」をソフトウェア的に判別することができませんでした。
しかし、みんカラでのSZ500ユーザー絨毯爆撃コメントへの返信でCP環境での動作報告や、パイオニアの「CarPlayのFAQを頑なに修正しない姿勢」、クラリオンTY-1000A-Bの「ホームページやYouTube動画、PR記事が全てCarPlay環境である」といった状況証拠の積み重ねにより、点と点が繋がりました。CPの強固なブラックボックスと、メーカー側の「CPでは動くからAAの実装は省く」という都合の良さが結びついた結果が、今回のSZ500の構造的欠陥であると断言できます。
アルパインDA7-WLについてもアルパインZシリーズに存在する「自車位置学習機能」が無く、DMH-SZ500やTY-1000A-Bと同じ仕様と見ていますが、車速線接続のFAQにDA7-WLは対象機種として入っていません。
https://www.alpine-info.com/s/article/5996
また取扱説明書にも車速線接続の効果は記載されていません。不幸中の幸いな事にDA7-WLはDMH-SZ500と違い、メーカーに全く売る気がありません。価格コムのランキングでも下位に低迷しており被害者はかなり少ないのではないでしょうか。そもそもZシリーズの一員ではなく、明確に区分されています。やはり中華ODM機を大々的にプロモーションしてDMHシリーズ主力機に据えているパイオニアの異常な姿勢が際立ちます。

2.奥只見シルバーラインでの極限テストとスマホSoCの限界

この三層分業が正しく機能する純血機「DMH-SZ700」を引っ提げて、全長18km、トンネル内分岐まで存在する魔の奥只見シルバーラインへ突入してきました。
結果は「大勝利」。第八・第九トンネル群の連続するカーブの頂点や出口においても、寸分の狂いもなく自車位置をトレースしきりました。SZ700の精緻なセンサーデータとAAの連携は完璧です。
しかし最後の最後、奥只見ダム手前で突如カーソルがグレーアウトし、車速表示が「--km/h」に。
原因は明確で、「スマホ側のCPU(SoC)のリソース不足」です。
私のスマホはAnTuTu50万点程度のミドルロー機ですが、AA+GoogleマップのナビゲーションだけでCPU負荷率は80〜90%に達します。ここにバックグラウンドで重い処理(AIアプリなど)が走るとSoCがパンクし、AAは重たいDR(自律航法)の演算処理を優先順位の低さから真っ先に放棄(キル)する仕様になっています。
帰りの下りルートでは、スマホを再起動してリソースを解放したところ、見事にDRが復活し完璧に動作しました。AAのポテンシャルを100%引き出すには、車載器だけでなくスマホ側の基本スペック(頭の良さ)も極めて重要だという実証データが取れました。

3.奥只見ダム資料館で見つけた「本物のハードウェア」

テストを終えてダム資料館まで徒歩で登ると、最高に胸熱な展示がありました。
昭和32年の小出町、奥只見ダム建設のためにシルバーラインの専用道路を走るランドローバー・シリーズIと、それに続くジープ群の写真です。



現代のように複雑怪奇な電子デバイスやソフトウェアのバグに振り回されるのとは対極にある、純粋な「機械としての頑強さ」だけで未開の地を切り拓いた無骨な四駆たち。英国車の電装云々という次元ではない、ごまかしの利かない圧倒的なタフさにロマンを感じずにはいられませんでした。

4.今後の展望

現在、地雷機を虚偽記載で販売した某メーカーとは、少額訴訟の準備が最終段階に入っています。
今回の検証で、相手の「CPでは動くから」という技術的な言い逃れや、取説の「距離を検出する」という記載の矛盾を完全に封じる理論武装も完了しました。
メーカーからしっかり満額を取り返したら、その賠償金でハイエンドSoCを積んだ最新スマホへの入れ替えを検討し、処理落ち(グレーアウト)とは無縁の「究極の自律航法ナビ環境」を構築しようと目論んでいます。
Posted at 2026/08/30 21:08:58 | コメント(2) | トラックバック(0) | 日記
2026年08月29日 イイね!

【SZ500欠陥問題】パイオニア提訴へのカウントダウン。1日で外堀を完全封鎖しました。

【SZ500欠陥問題】パイオニア提訴へのカウントダウン。1日で外堀を完全封鎖しました。深夜の更新になります。
パイオニア DMH-SZ500の「車速連携しない問題(カタログ等の不実告知)」について、ついに本格的な法的措置(少額訴訟)の準備が完了しました。

今日は有休をフル活用して、一気に外堀を埋めてきました。

■ mints(民事裁判書類電子提出システム)の導入
まずは裁判所のオンラインシステム「mints」のアカウント登録。
今回の証拠は、正常な他社DA(ヤリス等)やSZ700との動作比較動画、データ解析ログなどが主力になります。紙に印刷して郵送するより、動画やPDFをそのままシステムで送りつける方が裁判官にも一目瞭然ですし、何より相手(パイオニア法務)への「ITと証拠管理に長けた厄介な原告」という強烈なアピールになります。

■ 法務局でパイオニアの登記簿謄本を取得
被告を正確に特定するため、法務局で現在のパイオニア株式会社の登記簿謄本を取ってきました。
驚いたのは、代表取締役以外の役員が「全員外国人」だったこと。かつての技術とプライドのカロッツェリアは消え失せ、外資ファンド傘下で徹底的なコストカットと合理化を図る、現在のドライな企業体質(明らかな虚偽記載でも補償は突っぱねる)の根源を見た気がしました。

■ ディーラーをハシゴして「損害」を数値化
今回はDIYで取り付け・取り外しを行いましたが、この「無駄になった労力」も不法行為による損害(逸失利益)としてきっちり請求します。
その客観的な根拠として、トヨタさんと三菱さんを回り、ランクルとデリカD:5の正規の「ナビ脱着・取付工賃の見積書」を発行してもらいました。

■ 訴状ドラフトと証拠群(全15ファイル)の完成
夜通し作業し、すべての証拠をリンクさせた訴状が先ほど完成しました。

改ざん前後のメーカー公式FAQ(魚拓付き)

SZ700や他社機とのトンネル内実走比較動画

メーカーの自白メール、販売店の見解書

取り外したSZ500本体と、現在の代替機設置写真

これらを裁判所の指定フォーマット(甲001〜甲011の枝番)に完璧にナンバリングし、本体代金、検証用レンタカー代、工賃相当額を含めた【損害合計:141,662円】を、管轄の高田簡易裁判所へ請求します。

あとは後日、裁判所へ行ってmintsの本人確認(本登録)を済ませ、送信ボタンを押すだけ。

感情論は一切抜き。客観的な証拠と法理だけで、淡々と白黒つけにいきます。
今日はよく眠れそうです。おやすみなさい。
Posted at 2026/08/29 00:36:47 | コメント(0) | トラックバック(0) | 日記
2026年08月23日 イイね!

​【検証】Apple CarPlayとAndroid Autoの残酷な格差。無料サードナビに見る「AA軽視」の憂鬱

​【検証】Apple CarPlayとAndroid Autoの残酷な格差。無料サードナビに見る「AA軽視」の憂鬱​最近、ディスプレイオーディオ(DA)の普及に伴い、スマホのナビアプリを車の画面に映して使うスタイルがすっかり定着してきました。

しかし、CarPlay(CP)とAndroid Auto(AA)のプラットフォーム仕様、そしてサードパーティ製ナビアプリ(Yahoo!カーナビやMovilink等)のトンネル内挙動を実機で徹底検証した結果、現在のナビアプリ界隈に蔓延する「圧倒的なCarPlay優遇(AA軽視)」の構造が浮き彫りになりました。

​1. トンネル内挙動で明確になるOSの壁

​最新のiPhone(CP環境)とAndroid(AA環境)で、GPSがロストするトンネル内の挙動を比較しました。

​CarPlay版の強み: CP版のYahoo!やMovilinkは、トンネル内でも車速にしっかり追従します。これはiOS側の「Core Location」が、車載器のセンサー群(車速・ジャイロ)のデータを裏でフュージョンし、補正済みの高精度な座標をアプリ側に渡しているからです。無料アプリでも実用的なハイブリッド自律航法が成立しています。

​Android Auto版の憂鬱: 対してAA版は、アプリ側の権限(車の速度パーミッション)等の壁もあり、トンネルに入ると車載器側からの高精度なデータを活かしきれず、アプリ単体の「推測航法(見なし走行)」だけでゴリ押しする仕様になっています。せっかく高精度な車速パルスを出す車載器に繋いでも、宝の持ち腐れ状態です。Movilinkに至っては車速の出ているDAの場合、推測航法も放棄しAAのDRの結果を真に受けてカクツキながらトンネル外へすっ飛びます。

​2. トヨタの純正DAとMovilinkに見る「AA軽視」

​この「Apple偏重」を最も象徴しているのがトヨタです。

トヨタの最新純正DAはいまだに「CarPlayはワイヤレス対応なのに、Android Autoは有線のみ」という露骨な仕様格差を残しています。さらに、トヨタ肝煎りのナビアプリ「Movilink」でさえ、AA版では車載器データと推測航法が上手く噛み合わず(干渉して座標がカクつくなど)、CP版に比べて明らかに作り込みが甘いのが現状です。国内最大の自動車メーカーでさえ、リソースをiPhone側に極振りしているのが透けて見えます。

​3. 「専用ナビ+AA」という選択肢のジレンマ

​「じゃあAndroidユーザーはどうすればいいのか?」という解決策の一つとして、嫁のデリカD5で使っているパナソニックのストラーダ(CN-CE01WDA)のような「AA対応の専用カーナビ」があります。

自律航法(魔境のトンネル突破)は専用ナビの強力なセンサーに任せつつ、音楽やその他の機能でAAを使えるというメリットは大きいです。ただ、これも完璧ではなく、「専用ナビの案内画面と、AAの画面(オーディオやメッセージングアプリ、アシスタントの音声検索等)をシームレスに行き来できない」というUX上の大きな欠点があります。

​総括:今後のDA・アプリ選びの最適解

​今回の検証を通じて見えてきたのは以下のリアルです。

​CarPlayユーザー: 無料のサードナビ(Yahoo!やMovilink)でも、OSの恩恵でそこそこの自律航法が得られる。

​Androidユーザー: サードアプリの推測航法に限界がある以上、自律航法が進化したAA版「Googleマップ」を使いこなすか、課金して「カーナビタイム」等のガチアプリを導入するか。あるいはUIの不便さを妥協して「専用ナビ+AA」にするか。

​ディスプレイオーディオは「スマホを繋げば何でも同じ」ではありません。OSとアプリの組み合わせによる技術的格差を理解した上で、自分の環境に最適なシステムを構築することをお勧めします。
Posted at 2026/08/23 18:29:09 | コメント(0) | トラックバック(0)

プロフィール

「サンバー20万キロ超えました」
何シテル?   04/15 15:29
@fujji_jj0fye 長年ギャランVR-4(E39A)とジムニー(SJ30、JA22)の二台体制でしたが2004年、新車で買える最後のチャンス(2014~...

ハイタッチ!drive

みんカラ新規会員登録

ユーザー内検索

<< 2026/9 >>

   123 45
6789101112
13141516171819
20212223242526
27282930   

リンク・クリップ

【完結編】純血種DMH-SZ700降臨!Otixログと給電スペックが暴く、異端児SZ500との「絶望的な格差」 
カテゴリ:その他(カテゴリ未設定)
2026/08/17 12:56:09
エムズファクトリー 地デジフィルムアンテナ 
カテゴリ:その他(カテゴリ未設定)
2026/08/02 17:01:31
PIONEER / carrozzeria DMH-SZ500 
カテゴリ:その他(カテゴリ未設定)
2026/07/04 21:17:11

愛車一覧

トヨタ ランドクルーザー70 トヨタ ランドクルーザー70
HZJ76Vの国内最終年式に新車から現在まで乗り続けています。 長年憧れだったランクル ...
ソレックス マルチトレーラー ソレックス マルチトレーラー
「牽引野郎」始めました。レジャーからゴミ出しまでマルチに活用していきたいと思ってます。
スバル サンバー スバル サンバー
延命処置が限界にきたギャランE39Aの後継車として2010/04/05にやってきました。 ...
スズキ ジムニー スズキ ジムニー
SJ30の車検を通そうか迷っていた矢先、いきなりエンジンが焼き付き。最終的には車検を通る ...

過去のブログ

2026年
01月02月03月04月05月06月
07月08月09月10月11月12月
2025年
01月02月03月04月05月06月
07月08月09月10月11月12月
2024年
01月02月03月04月05月06月
07月08月09月10月11月12月
2022年
01月02月03月04月05月06月
07月08月09月10月11月12月
2020年
01月02月03月04月05月06月
07月08月09月10月11月12月
2019年
01月02月03月04月05月06月
07月08月09月10月11月12月
2018年
01月02月03月04月05月06月
07月08月09月10月11月12月
2017年
01月02月03月04月05月06月
07月08月09月10月11月12月
2016年
01月02月03月04月05月06月
07月08月09月10月11月12月
2015年
01月02月03月04月05月06月
07月08月09月10月11月12月
2014年
01月02月03月04月05月06月
07月08月09月10月11月12月
2013年
01月02月03月04月05月06月
07月08月09月10月11月12月
2012年
01月02月03月04月05月06月
07月08月09月10月11月12月
2011年
01月02月03月04月05月06月
07月08月09月10月11月12月
2010年
01月02月03月04月05月06月
07月08月09月10月11月12月
2009年
01月02月03月04月05月06月
07月08月09月10月11月12月
2008年
01月02月03月04月05月06月
07月08月09月10月11月12月
2007年
01月02月03月04月05月06月
07月08月09月10月11月12月
2006年
01月02月03月04月05月06月
07月08月09月10月11月12月
2005年
01月02月03月04月05月06月
07月08月09月10月11月12月
ヘルプ利用規約サイトマップ
© LY Corporation