■共通課題1　システムのアーキテクチャーの変化

車載組み込みシステムのアーキテクチャーの変化についてはいくつかの側面がありますが、最も大きな変化は「自律分散型から中央集権型システムへの転換」です。

自動運転以前の車載システムは、例えばエンジンを制御するコンピューター、ステアリングを制御するコンピュータ―など、メカやシステムが独立・分散して動いており、全体を統合して動かしていたのはドライバー（人）でした。これに対して自動運転になると人に代わってECUが車全体を制御することになり、自ずと中央集権型のシステムになります。この自動運転用のコンピューターにはAIをはじめとした最新技術が多数使われることになるので、従来に比べ飛躍的な演算能力が求められるようになります。高性能コンピューターを車に搭載するのであれば、さまざまな演算処理をそこに集中した方がコスト的にも有利です。こうした流れから現在では、ビークルコンピューター（セントラルECU）といった大きなコンピューターを中央に置き、そこから全体を制御するようなアーキテクチャーへと変化しつつあります。

■共通課題2　ソフトウェア更新（OTA）の必要性・意義

これはSDVにも深く関わる課題ですが、ソフトウェアの機動的な更新＝OTAの必要性も高まってきます。例えばセキュリティ上の脆弱性が見つかった場合には迅速な修正が求められることから、OTAでのソフトウェアアップデートは非常に有効です。ただし、危険なソフトウェアが浸入するなど「両刃の剣」になる可能性もあるため、OTAはかなり高いレベルで作り込まなくてはなりません。また、車載ソフトウェアがどんどん複雑化する中で、ソフトウェアの完成を待っていると市場投入の時期を逃してしまう懸念がありますが、OTAを活用すればソフトウェアは製品を販売した後に改善することができるため、より早い市場投入が可能になります。

この他にも、IT業界やゲーム業界といった自動車業界以外のサードパーティーを活用し、ゲームやエンターテイメント系のアプリケーションをOTAでインストールし、これをアップデートしながら自動車の魅力を高めていくことも考えられます。このようにOTAが重視されているのは、まさに自動車が持つ機能・価値の中で、ソフトウェアで実現されるものが増加してきたからです。最近の「Software Centric」や「ソフトウェアファースト」という言葉も、この自動車がソフトウェア中心になっていく流れの中で生まれてきたキーワードであり、今回のテーマである「SDV」もその一つです。

ではSDVとは何でしょうか。Software Defined Vehicleを直訳すると「ソフトウェアによって定義される車」となります。言い換えれば、「ソフトウェアを変更することで価値や機能が変えられる車」、さらには「APIによって動かせる自動車」と表現できるかもしれません（図表2）。

SDVについて期待される成果やメリットには次のようなものがあります。

■OTAによってアプリを後から追加できる

これは購入後に車の価値が上がる可能性を示しています。また車が一定時間を経ても「陳腐化しない」という言い方もできます。

■パーソナライズできる

スマホが自分好みのアプリを入れることで「自分仕様」になるのと同じように、車も同様に自分が求めるアプリを入れることで「自分仕様」になります。まさに「車のスマホ化」です。カーシェアが進んでいくと、この機能は大きなメリットになっていくと考えられます。

■継続的に収益が上がる

スマホではアプリ販売やアプリ内課金、サブスクモデルが一般的で、これによってハードウェアを販売した後も継続的に収益を上げられます。自動車でもソフトウェア更新やアプリの販売などによってこれと同様の収益構造を構築できる可能性があります。

上記のSDVのメリットはあくまで理論上の話です。では、実際問題としてSDVビジネスは将来本当にうまくいくのでしょうか。いくつか課題を挙げながら考えてみます（図表3）。

■ユーザーに買ってもらえるアプリとは

まずビジネスとしての可能性を持つアプリとしては「自動運転」が考えられます。これはすでに実例があり、テスラが「FSD（Full Self driving）」として月額199ドルで販売を開始しています。また、HMI＝インパネや操作性を自分好みにカスタマイズするアプリ、ナビやビデオ＆オーディオエンターテインメントといったIVI（In-Vehicle Infotainment）系アプリなども有力だと考えられます。アプリがビジネスとして成功するかどうかはやはりアイデアによるところが大きく、今後に期待がかかります。

■余裕を持ったハードウェアを準備できるか

販売後に多様なアプリを入れようとするとハードウェアにあらかじめ余裕が求められ、当然のことながら車両価格が高くなります。従来、自動車メーカーは必要な機能をぎりぎりのコストで実現するというマインドで車作りをしてきましたが、今後はこうしたマインドから変えていかなければいけません。車両価格は高くなりますが、それに見合った価値を提供し、ユーザーに納得してもらうだけの魅力作りが重要になっていきます。

■アプリで価値を出すためのヒント

一方、車というハードウェア資源を活用した新しいサービスの可能性もあります。プローブカーと言われるものがその一例で、これは車を動く交通観測モニターとして活用し、交通状況や周辺情報を取得するシステムです。これをうまく使えば、例えばリアルタイム版ストリートビューのような面白いサービスが作れるのではないかと考えています。

もう一つは技術面ですが、こちらもいくつかの課題があります（図表4）。

■開発工数の爆発

SDV開発で最も心配されるのはソフトウェア開発工数の爆発です。現状は、1つの車に1つのバージョンのソフトを作るだけでも手いっぱいの状況です。これが何度もバージョンアップを繰り返すことになれば車の種類×ソフトのバージョン数の開発が必要になり、工数は爆発的に増加します。当然ながら開発スタイルから変えていかなければなりません。

■安全性は担保されるのか

頻繁にソフトウェアをアップデートした時に安全性は担保されるのかという課題。ここはやはり慎重な安全性の検証が求められます。そして無難な方法としては、安全性に影響しないところから「Software Defined」していくことです。また、安全性に関わる部分をなるべく小さく限定して切り分けることも大切です。

■ソフトウェアアップデートの難しさ

OTAにも難しい面があります。特に車の場合、何十個もあるECUをバージョンの整合性を維持したままアップデートするのは容易ではありません。ただし、前述した中央集権型システムでは、OTAをするECUの数が減るためソフトウェアアップデートの負担は軽減されます。こうした意味からも中央集権型への移行は望ましいと言えそうです。

ソフトウェア開発工数を爆発させないためには、やはり開発スタイルの革新が不可欠です。そこで、今後求められるであろうポイントをいくつか挙げてみます。

■仮想環境での開発（クラウド上での開発）

実物ではなく、仮想環境＝シミュレーション環境を構築してCI（継続的インテグレーション）／CT（継続的テスト）を適用し、ソフトウェアを連続的に発展させていく手法が、車の世界にも導入されていくと考えられます。

■DevOpsの採用

こちらはCD（継続的デリバリー）の適用といったもので、ソフトウェアをリリースしながらユーザーが求めているものを見極め、本当にニーズに合ったものだけを作っていく（＝無駄な製品は作らない）というDevOpsのような開発スタイルを取っていくことが重要になります。

■ソフトウェアとハードウェアの分離

この他、私が最も重要だと思うのは「ソフトウェアとハードウェアの分離」です。従来の車の開発では車両（ハードウェア）を作る途中にソフトウェア開発プロセスが埋め込まれていました。それを転換して、ソフトウェアはソフトウェアとして連続的に開発していく、つまりハードウェアとは別の軸で開発していくことになります。

しかし、このソフトウェアとハードウェアの分離が非常に難しいところです。先ほど、ソフトウェアを繰り返しアップデートしていくと、車の種類×バージョン数のソフトウェア開発が必要になると指摘しましたが、このような「掛け算」では工数が膨大になるので、これを「足し算」にするのが理想です。車の車種+バージョン数（またはアプリの数）とすることでソフトの開発規模を抑えることができます。

また、そのためにはSDVを制御するためのAPIが重要になります。というのは、同じソフトウェアでいろいろなハードウェアを制御で可能にするためには、あるAPIをたたく（APIに要求を出して処理を実行する）と、ハードウェアの違いを吸収して動くプラットフォームがどうしても必要になります。このAPIを実現するソフトウェアが「ビークルOS」と呼ばれるものです。

そもそもOSの役割の一つに「ハードウェア資源を仮想化して管理すること」があります。例えばパソコンのOSに入っているファイルシステムにはストレージというハードウェアを仮想化する機能があり、これによって「ストレージの違い」を覆い隠しています。私たちがHDやSSD、USBメモリーといった異なるメディアを同じAPIで操作できるのは、OSがハードウェアを抽象化することによって可能になっているわけです。

ビークルOSは「車両のハードウェア資源を管理」するもので、その役割は、車両のハードウェア資源を抽象化して、一つのソフトウェアで複数の種類の車両を制御できるようにすることです。しかし、車両のハードウェアを抽象化するのは容易ではありません。まず、車両のどの部分を抽象化するのか、どの階層で抽象化するのか、どのように抽象化するのかなど、さまざまな問題があります。APIは仕事の分かれ目で定義する必要があり、つまり「どこの階層でAPIを切るか」は、自動車業界のビジネスモデルをどのように位置付けるかに大きく関係することになります。

今後の展望ですが、ソフトウェアプラットフォーム／OSが普及するには「APIの標準化」が極めて重要です。OS開発における勝ち組が市場を寡占または独占することも予想されます。またAPIの標準化だけで十分な互換性を確保するのは困難で、市場を獲ろうとするなら自らのAPIをオープンソースで公開してマーケットにおけるシェア拡大をしていく必要があると思います（図表5）。

先に、開発方法の革新していく上でソフトウェアとハードウェアの分離が重要だと述べました。しかし、これはMOT＝技術経営の議論から見ても難しく、特に日本にとっては不得意領域なのではないかと考えられます。

MOTの議論でしばしば指摘されることですが、製品のアーキテクチャーには「組み合わせ型（モジュラー）」と「すり合わせ型（インテグラル）」があり、日本は自動車のようなすり合わせ型が得意な一方で、パソコンのような組み合わせ型は得意ではありません。

SDVにおいてソフトとハードを分離することは、まさにすり合わせ型から組み合わせ型への転換していくことに他なりません。今まではソフトとハードを「掛け算」で全部すり合わせて最適解を探していたわけですが、これを「足し算」にしていくことになります。その結果、「かゆいところに手が届かない」という不満が起きないとも限らない。しかし、だからと言って組み合わせ型を否定するのではなく、今後はトータルなトレードオフで新たな最適解を考えていく必要があると思います（図表6）。

また、すり合わせ型の方が組み合わせ型より品質の良いものが作れるとされていますが、実はどちらも技術が進んでいけば品質は向上します。この品質向上がユーザー要求を超えると「過剰品質」となりかねません（図表7）。コストとユーザー要求のバランスを考えればやはりどこかで組み合わせ型への切替が必要になってくるだろうと考えます。

SDVトレンドは今後も着実に進んでいき、自動車メーカー各社はSDVの価値を生み出すために知恵を絞り、かつ開発スタイルを革新・効率化していく必要に迫られます。我々もソフトウェア業界に携わる者として、ソフトウェアの開発効率を上げるため継続的な努力が求められる中、SDVはその流れをさらに加速させることになります。我が国の組み込みシステム業界は、品質の高いものづくりに強みがありますが、今後は「最高品質」ではなく「適正品質」というものを念頭に、新しい技術に積極的に挑戦していくことが大事になっていくでしょう。