これは、商用車におけるエッジインテリジェンスの経済性をテーマとした連載「The Uptime Equation」の第1部です。
ある大型トラックが、断続的に故障コードを表示した状態でディーラーに持ち込まれた。整備士は、原因として最も可能性の高い部品を交換し、コードを消去してトラックを返却した。 3週間後、同じ故障コードが表示されて再び入庫した。その後も同様の現象が繰り返された。4回目の入庫時に、ようやく真の原因が判明した。それは、故障コードが示していた箇所から2つのモジュール離れた場所にある、擦り切れたワイヤーハーネスだった。これらの入庫により、フリートは1週間の大部分をそのトラックを使えない状態で過ごした。OEMは、故障していなかった3つの部品代と3回分の保証修理工賃を負担することになり、次回のフリート更新時に必要となる関係性に傷をつけてしまった。
誰も過失はありませんでした。故障コードは設計どおりに作動しました。A J1939故障コード（SPN/FMI）は は、どの信号がどのよう予想範囲を外れたかを整備士に伝えます。その「理由」までは示しません。たった1つの配線やコネクターの問題でも、複数のモジュールで同時にコードがトリガーされることがあります。商用車では長年にわたり、テレマティクスを活用したメンテナンスが行われており、DTCによって発動される作業指示書、ダッシュボード表示、アラートといった仕組みが機能しています。制限されているのは、そこに供給される信号の解像度なのです。
文脈の欠如がもたらす代償
によると ATRIの「2026年トラック輸送運営コスト分析」によると、2025年のトラック1台あたりの平均運行コストは1マイルあたり2.336ドルに達し、過去最高を記録した。修理・整備費は8.6％増の1マイルあたり0.215ドルとなり、通行料を除く各項目の中で最大の増加幅を示した。修理費が上昇する中、コードが曖昧なために生じる再点検のたびに、さらなる費用が発生している。診断の遅れはよくあることだ： マッキンゼーが2026年に実施した調査 によると、根本原因の特定には約7週間を要することが判明しており、AI を用いて品質問題を予測する際の主な障壁として、データ品質の低さが挙げられている。
OEMにとって、この曖昧さは保証費用として現れます。自動車業界全体では、2024年の保証費用は580億ドルに達し、2012年の水準の2倍となりました。これは、Sonatus のブログ記事でも指摘されている通りです。 AI が解決を目指している「580億ドルの問題」で指摘されているように、自動車業界全体で2024年の保証費用は580億ドルに達し、2012年の水準の2倍となりました。保証に基づいて不必要に交換されたすべての部品や、「不具合なし」と判断された返品も、その数字に含まれています。
稼働率は、商用車種が次回のフリート契約を獲得できるかどうかの判断材料となり、フリート各社は購入要件に稼働率や診断機能を盛り込むケースが増えています。
文脈が欠けていることには、人的なコストも伴います。アラートが曖昧だったり、遅れたり、間違っていたりすることが頻繁にあると、ドライバーはアラートに基づいて行動しなくなり、技術者はダッシュボードを手作業で確認し始めます。誰も信用しないアラートは、アラートがないことよりも悪いのです。なぜなら、それは人々に、重要なアラートを無視するよう仕向けてしまうからです。
車両全体およびトラック内部における断片化
全車両において、ブランド間の不統一が問題となっています。 『今後の展望：商用車データの標準化による新たな機会の開拓』では、フリートの90％以上が複数ブランドの車両を混在させて運用しており、独自仕様の信号フォーマットや命名規則が統合を困難にしているという事実が浮き彫りになりました。 COVESA は、商用車テレマティクス市場が2022年の330億ドルから2032年までに950億ドルへと成長すると予測しており、その成長のすべては、この断片化されたデータ層の上に成り立っている。
1台のトラック内部において、問題は所有権にあります。大型トラックのOEMメーカーは、同時にシステムインテグレーターでもあります。エンジン、トランスミッション、後処理装置、ブレーキコントローラーは、多くの場合、異なるサプライヤーから供給されており、各サプライヤーは独自の方法で故障を報告します。 OEMは車両とその保証関係を所有していますが、コードを発信するすべてのECUを所有しているわけではありません。COVESA VSSのような規格は、ブランドをまたいだコードの命名に役立ちます。しかし、それらはサプライヤー製ECUのコードには含まれていない文脈情報を補うことはできません。
「車両コンテキスト」が実際に何を意味するのか
「車両コンテキスト」とは、単にデータ量が増えることを意味するわけではありません。それは、イベントを取り巻くシグナル、システムの状態、および履歴を、適切なタイミングで捕捉することを意味します：
- コードだけでなく、その不具合を取り巻く状況全体。 トリガーの前後の信号を見ると、その状態がどのように変化したかがわかります。
- その瞬間のドメイン横断的な状態。 つまり、その時点でエンジン、後処理装置、電気系統、およびデューティサイクルがどのような状態にあったかを指します。
- イベント自体によってトリガーされる収集。 キャプチャは、すべてをログに記録したり、固定のスケジュールでサンプリングを行ったりするのではなく、質問された内容に的を絞って行われます。
- 車両に記録された履歴。 ある傾向が見られた場合、エンジニアは不具合が再発するのを待つのではなく、数週間前のデータを遡って確認することができます。
これが、次のようなイベント駆動型のデータ収集の背後にある考え方です。 Fastlane™ Collectorといったイベント駆動型データ収集の根底にある考え方であり、これは 「エージェントループ」の「Collect」段階に対応しています。また、データの有用性についても変化をもたらします。コンテキストのない障害コードでも作業指示書を作成することはできますが、予測モデルの学習材料としては不適切です。なぜなら、曖昧なラベルで学習されたモデルは、その曖昧さを学習してしまうからです。コンテキストが豊富なイベントデータこそが、AI ／MLベースの予測を機能させる鍵となります。この点については、本シリーズの今後の記事で改めて取り上げます。
なぜこれが車両ごとに決まるのか
ダッシュボードの性能がいくら向上しても、車両がそもそも捕捉していないコンテキストを復元することはできません。車両のコンテキストは、イベント発生前後の数秒間に、プラットフォームが感知・保持・送信するように設計された機能によって、車両のエッジ側で決定されます。つまり、これはOEMのアーキテクチャ上の決定事項となります。フリート運営側はこうした問題を認識し、購入要件を通じて上流にその課題を伝えています。この問題を解決できるのは、OEMのプラットフォームおよびE/Eアーキテクチャチームです。
そのコンテキストを把握するには、センシング、車載演算、ストレージ、帯域幅といったコストがかかります。OEM各社は、乗用車に比べて利益率が低く、生産台数も少ない商用車ラインナップ全体で部品表（BOM）コストを管理しているため、これは軽々しく下せる決定ではありません。結局のところ、2つの選択肢に絞られます。OEMは、高精細なデータを取得するために高性能なハードウェアに投資するか、あるいは、車両にすでに搭載されているハードウェアから必要なデータを抽出できるほど効率的なソフトウェアを開発するか、のいずれかです。
結論： 商用車fleetsはすでに車両データに基づいて行動しています。課題となっているのは「車両のコンテキスト」です。故障コードは監視対象のパラメータを示すものであり、故障した部品そのものを示すものではありません。この曖昧さが、修理の繰り返し、保証コストの増加、アラート疲労、そしてAI にとって粗すぎるトレーニングデータといった問題を引き起こしています。この問題を解決するには、イベント発生の瞬間に車両上で（エッジ側で）OEMプラットフォームによる判断を行う必要があり、それにより生じるコストのトレードオフについては、第2部で取り上げます。