これは『稼働時間の方程式』の第2部です。 第1部 では、車両のコンテキストを車両上で取得しなければならない理由を説明しました。このパートでは、それを行うためにどれほどのコストがかかるかについて考察します。
あるプラットフォームチームは、トラックの後処理（排出ガス制御）システムで発生する故障を、実際に発生する数週間前に予測するモデルを開発しました。 技術的な課題は解決済みだ。しかし、プラットフォームに関する課題は未解決のままである。すなわち、このモデルをどこで実行するか、という点だ。もし、すでにトラックに搭載されているゲートウェイやテレマティクス・コントローラーで動作すれば、現行のプログラムで出荷できる。しかし、より高性能なコントローラーが必要な場合は、次期電気・電子（E/E）アーキテクチャを待つことになり、すでに走行中のトラックには決して導入されないことになる。
これは、新しいデータ活用事例が登場するたびに浮上する疑問ですが、商用車の場合、その答えの背景にある経済性は乗用車とは3つの点で異なります。
トラックの場合、計算が異なるのはなぜなのか
販売台数。米国におけるクラス8トラックの小売販売台数は 2025年には208,386台。米国における新型軽自動車の販売台数は 1,620万台で、その約78倍に相当する。中型トラックや特殊用途トラックを加えるとその差は縮まるものの、完全に埋まるわけではない。追加されるコンピューティングハードウェア1ドルごと、そして新しいコントローラーの統合や検証に費やされる1ドルごとに、そのコストはごく一部の台数に分散されることになる。
耐用年数。 米国における大型トラックの平均 12.1年 です。また、運送会社によるトラックの保有期間も長くなっており、ACT Researchのデータによると FleetOwner誌が報じたところによると によると、フリートで運用されているクラス8トラックの平均稼働年数は6.3年であり、これは2013年以来の最長記録となっている。高性能なゲートウェイ、テレマティクスユニット、ECUなどの新しいコンピューティングハードウェアは、新車にのみ導入されている。既存の車両は、出荷時に搭載されていたハードウェアを10年以上使い続けており、稼働時間の価値の多くは 稼働時間の価値 の多くは、その既存車両群に存在している。
アーキテクチャのライフサイクル。 商用車のE/Eアーキテクチャは数年単位のサイクルで更新され、多くのコントローラはOEMが完全に管理できないサプライヤーから供給されている。新しいコンピューティングハードウェアに関連するユースケースも、そのタイムラインに連動している。
これら3つの要因を総合すると、ある1つの問いに対する重要性がさらに高まります。それは、トラックに必要な知能のうち、どれだけが新しいハードウェアから得られなければならないのか、そしてどれだけが既存のハードウェアをより有効に活用することで得られるのか、ということです。車載型AI の費用を賄うには2つの方法があります。1つは機能を購入する方法、もう1つは効率性を高める方法です。
方法1：能力の購入
ハードウェアを採用するメリットは確かに存在します。集中型およびゾーン型アーキテクチャでは、ワークロードをより少数で高性能なコントローラに集約し、配線を削減できます。マッキンゼーは、これらのコントローラにはより多くの処理能力が必要となるため、 追加コストが発生する可能性がある。商用車メーカーも同様の動きを見せている。 2025年に設立されたダイムラー・トラックとボルボ・グループの合弁会社「Coretura」は、ダイムラー・トラックとボルボ・グループによる2025年に発足した合弁企業であり、共有型のソフトウェア定義車両プラットフォームを構築している。同社はまた、商用車向けの集中型高性能コントローラーの仕様策定と調達も行う予定で、最初の製品は今世紀末までに車両への搭載を目指している。
高性能なセントラルコントローラーやゾーンコントローラー、あるいは専用のAI アクセラレーターといった、より高性能なコンピューティングハードウェアは、ワークロードがそれを真に必要とする場合――例えば、カメラによる知覚、ADAS、自動運転、あるいは車両1台あたりの耐用年数にわたる価値が、生産規模を考慮した追加コストを明らかに上回るようなケース――において、最適な解決策となります。また、新しいプラットフォームを設計する際にも、こうしたハードウェアの導入は理にかなっています。
しかし、これには限界があります。この仕組みが適用されるのは、プラットフォームのスケジュールに沿って導入される新車に限られます。また、コントローラーの規模が大きくなったとしても、効率的なソフトウェアの必要性がなくなるわけではありません。共有コンピュータ上のすべてのワークロードは、同じリソースを奪い合うことになるからです。マッキンゼーによる エッジAI に関する調査に関する調査では、回答者の46％が、システムオンチップ（SoC）のリソースの制限を障壁として挙げています。
アプローチ2：効率化
ソフトウェアの活用により、既存のハードウェアの性能をさらに引き出すことが可能になります。現在、いくつかの技術が十分に成熟しています：
- モデルの圧縮。 整数量子化により、モデルのサイズは 約4分の1のサイズに縮小し、処理速度を3倍に高速化 、かつ精度の低下もほとんどありません。プルーニングと量子化を組み合わせることで、モデルの保存容量を 精度に影響を与えることなく35倍から49倍に削減できる。マッキンゼーは、マイクロコントローラーがエッジ側で軽量なAI モデルを実行できる能力をますます高めていると指摘している。
- オンデマンド実行。 モデルは、常に稼働させ続けることなく車両にインストールできます。 「常時稼働のAI モデルが商用車のリソースに負担をかける」で説明されているように、車載の共有ランタイムにより、常時稼働型や安全上重要なモデルを継続して実行しつつ、車両の状態に応じて必要となった場合にのみ、整備場での点検中にバッテリーの健全性チェックなど、その他のモデルを起動させることができます。
- イベント駆動型のデータ収集と車載圧縮。 車両は、すべてのデータをストリーミングするのではなく、イベントに関連するデータのみを保存・送信します。
- 仮想センサー。 ソフトウェアは、物理的なセンサーを追加する代わりに、車両ネットワーク上にすでに存在する信号から値を推定することができます。ある パートナー企業の事例では、CAN信号から構築されたソフトウェアのみのヘッドライトレベル調整センサーにより、1台あたり最大20ドルのハードウェアコストを削減しました。このケースでは、ソフトウェアによるアプローチはBOMコストの増加を回避するだけでなく、そのコストそのものを排除しています。
トラック分野において、ソフトウェアアプローチの最大の利点は「普及範囲」です。これは、すでに稼働中の車両に対し、その演算能力の範囲内で、また次世代アーキテクチャを待つことなく、現行のプログラム上で無線（OTA）経由で導入することが可能です。これが、 Fastlane™ Edgeこのソリューションは、専用のAI アクセラレータを必要とせず、高性能ゲートウェイ、テレマティクスユニット、中央コンピュータなど、車両がすでに搭載している演算リソース上で、AI モデル、仮想センサー、予測診断を実行します。トラックにそのような演算能力がまだ備わっていない場合、 Fastlane™ Copilot は、プロトタイプやテスト用車両において、生産アーキテクチャを変更することなく、既存の車両に高性能ゲートウェイを追加します。
しかし、これにも限界があります。ソフトウェアだけでは、ゲートウェイを知覚コンピュータに変えることはできません。ソフトウェアには、演算能力、メモリ、検証作業といった制約があり、安全性、サイバーセキュリティ、ライフサイクル管理の面でも独自のコストが伴います。
それを一つの決断として捉える
ハードウェアとソフトウェアを別々の予算として扱うのは間違いです。ソフトウェアの効率性によって、必要なハードウェアの量が決まります。プラットフォームチームにとっての実用的な手順は以下の通りです：
- まず最適化を行い、その後でハードウェアの規模を決定する。 圧縮およびイベント駆動型設計を施した後のワークロード要件を把握し、その前に判断してはならない。
- 価値がどこにあるのか、問いかけてみてください。 その価値の大部分が導入済みベースにあるのであれば、ハードウェアの道筋ではそこに到達することはできません。
- ご自身の生産数量に基づいて、価値とコストを比較してください。 車両1台あたりの耐用年数にわたる価値と、追加のハードウェアおよび統合コストを、実際の生産台数で割り振った上で比較検討してください。
- 新しいアーキテクチャの導入がすでに予定されている場合は、余裕を持たせて設計してください。 効率的なソフトウェアがその余地を埋めるという前提で計画を立てよう。
ソフトウェアにはそれなりのコストがかかります。トラックにモデルを追加するたびに、演算能力、メモリ、統合作業、検証が必要となり、さらにその車両の寿命にわたってメンテナンスを行わなければなりません。モデルを必要な時のみ実行し、1つのランタイムを共有することで、新しいユースケースが追加されるたびにコストが膨らむのを防ぐことができます。
ワークロードがオンプレミス環境に収まったら、次は「どのワークロードをオンプレミスに配置すべきか、どのワークロードをクラウドに配置すべきか」という問題になります。これについては第3部で取り上げます。
結論： 豊富な車両コンテキスト情報を収集し、車載環境でAI を実行するにはコストがかかりますが、商用車OEMメーカーは、乗用車メーカーに比べてはるかに小規模な生産規模でそのコストを負担しなければなりません。そのコストを賄うには2つの方法があります。1つは、より高性能なハードウェアを追加し、データの価値によってその投資を正当化すること。もう1つは、ソフトウェアを十分に効率化して、車両がすでに備えている演算リソース上で実行できるようにすることです。大半のメーカーは、この両方のアプローチを採用するでしょう。 しかし、生産台数が少なく、耐用年数が12年、アーキテクチャのライフサイクルが長いことを考えると、OEMはソフトウェアをデフォルトとするべきです。つまり、トラックがすでに搭載している演算リソースで新しいワークロードを実行し、カメラによる知覚処理などのワークロードで必要となる場合、あるいは新しいE/Eアーキテクチャがすでに設計されている場合にのみ、演算ハードウェアを追加するということです。