テスラのFSDが、通行に支障がなければ一時停止標識のある交差点でも徐行しながら侵入するという不具合がリコール対象となった。この問題は既存メーカーでも起こりうるもので、今後の車両開発や安全設計にも関わる興味深い課題を提起している。少し掘り下げてみたい。
◆自動運転車の遵法運転は安全か
一時停止標識のある交差点では、徐行でもそのまま侵入したら大抵の国で違反になる（米国ルールでも違反）。自動運転や安全運転支援の車両だからという免責はない。リコール対象となるのはしごく妥当である。
だが思い出してほしい。日産のプロパイロットは高速道路でも厳密な遵法運転を行う。インターチェンジやジャンクション付近で80km/h規制がかかると律儀に減速する（手動でOFFに設定可能）。出口ランプで40km/h制限の標識があれば、高い速度で侵入するとそれなりのブレーキで減速する。この機能を「危険だ」と思った人はいないだろうか。
遵法運転は基本だが、現実には制限速度より流れにのった運転のほうが安全という場合がある。リコール対象となった機能は、米国では安全な状態ならば一時停止を厳密に守らない現実があることを反映したのかもれいない。もちろん、意思を持つ人間が行う違反と、機械が行う違反は同列に扱えないが、速度制限標識を超えたACCの速度設定が適法または合理性があるなら、自動運転でも同じことは言えるはずだ。
リコール対象になるのは妥当だが、少なくともレベル2で制御を行っているテスラFSDに、交差点徐行侵入機能があっても致命的な欠陥と言えるだろうか。ブレーキを踏んだりドライバーが介入すれば済むことで、手動OFFができるかどうかは本質ではない。
◆30年前からあるITと自動車業界の確執
テスラFSDや車両設計は、歴史ある自動車製造業の安全思想と相容れないという意見を耳にする。じつはこのような議論は今に始まったことではない。古くは1990年代、当時のマイクロソフト社長のビル・ゲイツ氏とGMが似たような論点で争ったことがある。
ビル・ゲイツ氏があるカンファレンスの講演で「GMがマイクロソフトの技術を使えば25ドルのガソリンで1000マイル走れる車が作れる」と発言した。これに対しGM側が「そんな車は毎日フリーズし故障のたびに買い替える必要があるのでは？ 高速道路で故障したらいちいちシステムをリブートするのか？」と反論したことがある。
このとき、各業界や識者の論点は主に製品の安全性についての議論に集中した。多くの自動車業界関係者は、このときのGMの感覚のままでいるのかもしれないが、30年後の現在、ビル・ゲイツ氏が述べたIT業界の技術なしに車両はまともに動かない（少なくともCASE車両は）状態にある。車両設計は、システムがフリーズしても稼働をゼロにしないフェールセーフやフェールオーバー機能を真面目に実装しなければならない。
◆価値の源泉はハード、ソフト、そしてサービスへ
筆者も（30年以上前だが）組込み系でハード・ソフト両方の経験があるが、一般論としてハードウェアエンジニアはソフトウェアエンジニアを見下す傾向がある。すくなくともそういう主張は存在する。初期のコンピュータビジネスでは、ソフトはハードに無料でついていくるもの、価格のほとんどがハードウェアコストだったからだ。
一般製造業でも、CPUなどマイコン制御は後から入ってきているため、設計の基本はハードウェアや形のある製品にこそ価値の本質があったので、ソフトよりハードが偉いという認識はそれなりに必然でもあった。
だが、現在ハード・ソフトの価値（ポジション）が逆転しているのはいうまでもない。それどころか、ソフトウェアさえもいまや「サービスビジネス」の手段となり、パッケージ販売ビジネスはほぼ崩壊し、アプリ課金やサブスクリプションビジネスに置き換わっている。
ビジネスの世界において、価値（＝マネタイズとする）の源泉は、もはや製品・技術・ソフトウェアではない。これらを組み合わせてどんなサービスやユーザー体験を提供できるかに移っている。もちろん、個々の技術や製品の品質や機能は大前提として必要だ。価値がサービスに移ったのではなく、いまの技術や品質は当然維持した上で、さらなる付加価値を与えなければならないということだ。
◆ソフトウェアの安全思想はハードウェアにも適用可能
この変革は、業界や立場によって「DX」「第4次産業革命」「Industry4.0」「MaaS革命」「CASE革命」などと呼び方は一定ではない。面倒なら、まとめて「ゲームチェンジ」と言ってしまってもいいだろう。
呼称はどうでもいいが、自動車製造業においては、製品の安全設計にも影響が及ぶ。ビル・ゲイツ氏とGMのやりとりでは、IT・自動車の安全設計や思想は相容れないものとして議論されたが、仮にそれが事実だとしても、現実は双方の分離は不可能だ。優劣を競う議論に意味はない。双方を両立させる必要がある。
たとえば、車両設計において、製品出荷後の瑕疵は人命に関わるため絶対にあってはならない。もちろん現実に100％は不可能なので、それに近づける事前の検証や実験にやりすぎはない。検証に検証を重ね、確実なものしか製品化してはならない。
だが、ソフトウェアにおいては事情が少し異なる。ソフトウェア開発においても原則はバグのない完全なものをリリースしている。鉄則だが、現実問題としてバグの100％排除は不可能だ。加えて、ソフトウェアには「脆弱性」という問題がある。プログラムは仕様を100％満たしていても、セキュリティ上の穴や想定していない機能の利用は防げない。
この問題にソフトウェア業界が出した答えが「アップデート」であり「継続的な改善リリース」である。つまり、ソフトウェアは完成することはないもので、常に改良や改修を加えていって安全性や完全性を保つものであるという考え方だ。
◆リコールとセキュリティアップデートの共通部分
ハードウェアエンジニアや製造業には理解できないかもしれないが、じつは製造業でもこの考え方は採り入れている。むしろ避けられな選択肢だ。
ハードウェア製品でも「予期なく仕様変更をすること」がある。自動車においてはリコールという制度が確立されている。ソフトウェアアップデートの考え方はこれと同じである。とくにリコール制度は、ソフトウェア業界における「セキュリティアップデート」「脆弱性ハンドリング」と呼ばれる枠組みと共通する部分が多い。
ハードだろうがソフトだろうが、人間が関わるかぎり100％は土台無理な話である。ならば、100％以外を許さないのではなく90数％をメンテナンスによって維持する考え方だ。程度の問題はあるが、ソフトウェアによって車の性能や特性が変えられるCASE車両では、安全性や設計思想についてこの考え方を受け入れる必要がある。
そのためには、ECU技術や通信技術、セキュリティ技術の向上が不可欠だが、技術面でのハードルはじつは低い。些末な問題といってもよい。80年代の車両でもECUのROM（制御マップ）を変えるだけでエンジン性能＝走行性能を変えられる。OTAも技術的なブレークスルーはほとんど必要ない。問題はECUアーキテクチャの変更だが、各社少しずつ次世代ECU、次世代E/Eアーキテクチャへの入れ替え進んでいる。
◆本当の問題はユーザーのリテラシー
本当の問題は、ハードや技術ではない。100年に一度と言われる業界革命にもっとも重要で、現在最大のハードルは、ユーザー側の受容性の問題だ。リテラシーといってもよい
たとえば、業界に関わる人間なら「リコールを出す会社＝ダメな会社」（極端なリコール例・件数を除く）ではないことを理解しているはずだ。制度の主旨としくみを理解していれば、リコールによって改修を行うのは車両の安全を高める行為であり、それを発見・対策できる能力のある企業という評価に異論はないはずだ。同様に、ソフトウェア業界でもセキュリティアップデートをしないベンダー、脆弱性ハンドリングができないベンダーは、セキュリティを考えない三流企業のレッテルを貼られる。
現状でもソフトウェア改修のみで済むリコールも存在する。OTAで対応できれば、対策漏れを相当少なくできるし、改修コストも削減できる。物理的な部品交換やメンテナンスはなくならないが、ユーザーはOTAによる機能アップデート、不具合改修はリコールと同様な安全措置であるという認識を持つ必要がある。むしろ「いつまでリコールごとに車両を整備に出さなければいけないのか」くらいの疑問を持つべきだろう。
https://response.jp/article/2022/02/07/353970.html
