BEV乗りの為のアプリ〜走る前に計算し、走りながら更新するCharging Planner〜

（はじめに）

ブラックボックス化はしません。出来るか分かりませんが、この記事を生成AIに入れるとアプリが作れる事を意識して書いてます。

なお、これはbz4XTouring（ADW）に特化させてます。骨格を流用すれば、どんなメーカーのBEVでも使えるハズです。

■日本人の特性とBEVの相性の悪さ

一部を以て全てを語る訳では無いですが、日本人の特性はグローバルから見れば独特です。

日本においてBEVの普及が諸外国に比べて緩やかである背景には、単純にインフラだけでなく、日本人の心理的・社会的特性（いわゆる国民性）が強く影響していると分析されています。

無論、そんな私も例外では無いと思ってます。

■BEVを避ける日本人の特性

1. 失敗や不確実性を避ける「強いリスク回避傾向」

日本市場の消費者は、「電欠」や「充電難民」への不安: 「万が一、高速道路でバッテリーが切れたら」「立ち寄った充電器が故障していたら」といったリスクを強く懸念する傾向があります。

2. 加点方式ではなく「減点方式」の厳しい品質・利便性要求

製品やサービスに対して極めて高い「完璧さ」と「ノーストレス」を求めます。

利便性の悪化を許容しにくい: ガソリン車であれば「数分で満タン」になるのに対し、急速充電でも「30分拘束される」「航続距離が季節によって変動する」といった点は、どれほど静粛性や加速性能が良くても大きな「減点要素」として評価されがちです。

3. ハイブリッド車（HEV）に対する圧倒的な「信頼感と満足度」

かく言う私自身もそう、「現実的で実用的な完成度」を重視します。

HEVという成功体験は、トヨタのハイブリッド車は、長年の実績により「壊れにくく、燃費が良く、ガソリンスタンドで数分給油するだけ」という完成された世界を生み出しました。

心底思う、「HEVで十分すぎるほど経済的だし快適」

4. 「横並び意識（同調圧力）」

意外かな？と思われるかも知れませんが、日本人は永らく集合住宅が一般的です。それが生み出した、目立つことへの抵抗感。

一戸建てであっても「ご近所でまだ誰もBEVに乗っていないから様子を見よう」という、同調圧力や横並び意識が働いてしまいます。

5. リセールバリューと長期保有に対する「堅実な金銭感覚」

車は決して安い買い物では有りません。私の様に「車キチガイ」でもそれは同じ。

となると、HEV以上にバッテリーの経年劣化（これは日産がやってしまったとも正直思ってます）や技術革新の早さにより、「数年後の下取り価格が読みにくい」ことがあると思います。

と言う事で、こんなにも環境意識の高い日本でBEVが広まりにくいのは、あんまり複雑な理由では無く文化から来ているんですね。

■BEVの意識を変える為の開発

車の使い勝手を含め、車自体を設計をするのはメーカーの開発の仕事です。

ただよく思うのが、「ユーザー側もその車を楽しめる工夫をしても良いのでは？」って事です。

いつもなら、設計の弱みや、自分のクセに合わせて「車体をいじる」のですが、BEVは「考え方をいじる」必要があると思います。

今回は、その意識を変える為の開発チャレンジです。

■BEVの最大にして唯一の弱点、不安。

「純正ナビの予想航続距離を信じて走っていたら、峠越えの手前で急激にバッテリー残量が削られて肝を冷やした」

なんて話は、よく聞く話。

市販のカーナビやGoogleマップ、既存のEVスポット検索アプリは、基本的に「フラットな道路を一定の平均電費で走ること」を前提とした簡易的な計算しか行っていません。しかし実際の道路には、急激な高低差、季節による外気温の変化、向かい風、エアコンによる消費電力、そして急速充電器の出力制限（いわゆる30分ルールやSOC上昇に伴う充電制御）といった極めて非線形な変数が渦巻いています。

こうした「BEVの設計をしないと知らない事」に対処すべく開発したのが、トヨタ bZ4X Touring AWD（車両重量2,080kg / Cd値0.29）の物理特性に特化した「実測＆物理モデル融合型 EV走行・充電プランナー＆リアルタイム走行監視システム」です。

コダワリは、とにかく最小限の入力で、道沿いはもちろん、充電価値（私自身が持つ時間の値段も考慮）まで点数化し、コスパの良い充電スポットを提案するものです。

リストアップされた充電スポットは、触れば詳細リンクへ飛びます。

これらは、全て無料の公開情報を利用します。

第1部：特徴と既存システムに対するアプローチ

1. 「既存ナビ」との差別化、リアルタイム走行状態監視と動的リプランニング

今回のシステムの真価は、出発前のルート計画に加え、走行中、スマホのGPSとリアルタイムに連動し、「事前予測した物理モデルの電費」と「実際の走行データ（速度・標高変化・SOC消費速度）」を秒単位で比較検証し続けます。

リアルタイム差分監視: 気象変化や想定外の渋滞、あるいはペースオーバーによって予定以上の電力が失われた場合、システムが即座に異常値を検知。

動的リプランニング: 次の目的地や予定していた充電スポットに到達できないと判断された場合、現在地から最適な代替急速充電スポットを自動で抽出し、ルートと充電計画をリアルタイムに再構築。

いわば、車載コンピューターの裏で「専属のコ・パイロット」が常に残量と風向・勾配を計算し続けている状態を作り出します。

要は、マイクロソフトのCopilot思想をパクったわけですね（笑）

2. 既存ナビ・Webサービスに対するアドバンテージ

既存の各種サービスは沢山ありますが、本システムの違いは、計算の根底にある「解像度」です。

簡易的な比較表をちょいとズルしてAIに出力させてみました。

比較項目	一般的な純正ナビ / Googleマップ	既存EV専用アプリ	本システム（bZ4X Touring AWD専用設計）
ルート計算	距離と標準所要時間のみ	距離＋平均電費固定	OSRM＋Open-Meteoによる高低差・風向・気象統合モデル
高低差の影響	考慮なし（または極小）	標高差の簡易補正	位置ごとの斜度 θ から勾配抵抗 m × g × sin(θ) を厳密計算
充電シミュレーション	充電器の公称出力（kW）で直線計算	充電器出力の簡易適用	SOC・バッテリー温度に依存する非線形「充電カーブ」を積分計算
走行中の監視	案内ルートの追従のみ	現在地表示のみ	実測消費電力とモデル値の乖離を監視し動的リプランニング
自己学習機能	なし	なし	走行・充電実績からSOH（劣化率）と電費補正係数（K値）を自動学習

3. 走れば走るほど精度が上がる「SOH自律推定＆電費補正アルゴリズム」

どんなにクソ真面目な物理モデルを組んでも、経年劣化によるバッテリー容量の減少（SOH: State of Health）や、装着タイヤ・ドライバーの癖による電費誤差を無視することはできません。

今回のシステムは、急速充電を行った際の実測値（充電開始SOC、終了SOC、受電電力kWh）をローカルに蓄積し、SOC差15%以上のセッションからバッテリーの有効容量を逆算します。さらに、直近の走行データから自車固有の補正係数（K値）を抽出し、次回以降の予測ロジックへ自動フィードバック。乗れば乗るほど、自分の愛車の特性へフィッティングされたシステムへと学習します。

第2部：技術仕様・内部アーキテクチャ（詳しい人向け、だけどブラックボックス化はしない！）

今回も、この記事をAIに喰わせれば何となく作れる様に、システムの内部挙動、物理数式、通信設計、および自己学習ロジックの肝となる仕様を公開します。要はブラックボックス化をしません。

これが今回一番やりたい、BEVへの意識を変えるお手伝い、です。

1. スタンドアロン＆ハイブリッド通信アーキテクチャ (bz4x_launch.py)

ブラウザのセキュリティ制約（file:// スキームにおける Geolocation API / Secure Context 制限）および異種オリジン間通信（CORS）制限を回避するため、Python標準ライブラリのみで構成されたローカルプロキシサーバーを稼働させています。


[ ブラウザ (HTML5/ES6 Frontend) ]
    │
    ├── (1) HTML5 Geolocation API (Secure Context: http://127.0.0.1:PORT)
    │
    ├── (2) 直接外部API通信 (CORS許可サーバー)
    │      ├── OSRM API (ルーティング・ジオメトリ取得)
    │      ├── Open-Meteo API (標高・気象・風向風速取得)
    │      ├── Nominatim API (逆ゲオコーディング・地名検索)
    │      └── OpenChargeMap API (充電スタンドPOI取得 / Keyless Fallback)
    │
    └── (3) ローカルプロキシ経由通信 (CORS制限サーバー回避)
           └── bz4x_launch.py (:127.0.0.1) ──> JARTIC API (交通量・渋滞情報)

ポート動的バインド: pick_port() 関数により使用可能ポートを自動探索し、127.0.0.1 にバインド。ブラウザ側で位置情報パーミッションを正常に保持。

ゼロ依存性: サードパーティ製ライブラリ（Flask, FastAPI, Requests等）を一切使用せず、http.server と urllib.request のみでプロキシ・パイプラインを構築。

2. 物理運動モデルに基づく微分消費電力計算

1区間（ステップ）あたりの全走行抵抗 R_total は、以下の運動方程式に基づき算出されます。

【全走行抵抗の計算】

R_total = R_r + R_a + R_g

1. 転がり抵抗 (R_r):
R_r = C_r × m × g × cos(θ)
・ m = 2,080 kg ＋積載量（車両総重量）
・ C_r : 転がり抵抗係数（降雨・路面状態フラグにより動的補正）
・ θ : Open-Meteo 標高データから得られる道路斜度

2. 空気抵抗 (R_a):
R_a = 0.5 × ρ(T_amb) × C_d × A × (v + v_wind)²
・ C_d = 0.29（bZ4X公称空気抵抗係数）
・ A : 前面投影面積 (2.58 m²)
・ ρ(T_amb) : 外気温 T_amb に依存する空気密度関数
・ v_wind : ベクトル分解された対地風速（向かい風成分）

3. 勾配抵抗 (R_g):
R_g = m × g × sin(θ)

4. パワートレイン統合効率と補機電力加算:
車輪端要求電力 P_wheel = R_total × v に対し、AWD前後モーター駆動時と回生時で効率補正を分離します。

・ 駆動時 (P_wheel ≧ 0) のバッテリー消費電力:
P_battery = ( P_wheel / η_drv ) + P_aux(T_amb, T_target)

・ 回生時 (P_wheel < 0) のバッテリー回収電力:
P_battery = ( P_wheel × η_reg ) + P_aux(T_amb, T_target)

η_drv : AWD統合駆動効率 (0.91)、η_reg : 回生ブレーキ効率 (0.68)

P_aux : 空調（HVAC）およびECU・補機類消費電力。外気温 T_amb と設定温度 T_target の差分から非線形モデルで算出。

3. DC急速充電（ChAdeMO）の非線形ステップダウンモデル

急速充電における到達SOCの予測は、固定出力（kW）による単純計算ではなく、時間 t に対する非線形充電出力関数 P_chg(SOC, T_bat) の定積分として処理されます。

【増加SOC（ΔSOC）の推移計算】

ΔSOC = [ ∫ P_chg(SOC(t), T_bat) × η_chg dt ] / ( E_nominal × SOH )

充電カーブ制限テーブル:
- SOC < 50% : 機器最大出力（例: 90kW / 50kW）制限
- 50% ≦ SOC < 75% : 出力抑止（Step-down 1）
- 75% ≦ SOC < 90% : 急激な電流絞り込み（Step-down 2）
- SOC ≧ 90% : トリクル充電領域

30分制限タイマー: 日本国内の標準ChAdeMO規格（30分制限）を上限とし、制限時間内での到達可能SOCと最大受電電力量を確定。

4. 統計的外れ値除去（Trimmed Mean）によるSOH・電費補正学習

充電時および走行時に記録された履歴データから、ノイズを排除してSOH（State of Health）と電費補正係数 K_ext を算出する閉ループ制御アルゴリズムです。

1. 有効容量逆算条件:
充電セッションにおいて ΔSOC = SOC_end - SOC_start ≧ 15% が満たされた場合のみ算定対象とします。

2. トリミング平均（Trimmed Mean）アルゴリズム:
蓄積された N 個の推定容量サンプル S = {E₁, E₂, ..., E_N} を昇順ソートし、上下 α = 15% の外れ値（計量器誤差、温度過渡応答ノイズ）をカットした平均値を採用します。

SOH = [ Σ E_(i) ] / [ (N - 2k) × E_nominal ]
（※ i は k+1 から N-k まで加算。ただし k = floor(N × α) ）

3. K値（電費補正係数）のリアルタイム適用:
算出された SOH および実走行でのモデル消費量との乖離比率から補正係数 K_ext を更新し、次回計算時の基本走行抵抗モデル全体を定数倍補正（R'_total = K_ext × R_total）することで、車両個体差やタイヤ摩耗に最適化させます。

1)自作アプリランチャーから起動