「同じソフトウェアなのに、なぜここまで違うのか― Web/ネイティブ・自動運転・車載ネットワークを OSI で読み解く ―」

1．大きな地図：開発分野ごとの立ち位置

Webアプリケーションやネイティブアプリの開発、自動運転システムの開発、そして車載ネットワーク技術は、いずれも「ソフトウェア開発」という同じ言葉で括られる分野である。しかし実際には、扱っている抽象度、責任範囲、そして前提としている世界観は大きく異なる。これらの違いは、OSI参照モデルとコンピュータの構成という視点から整理すると、単なる技術の差ではなく「設計思想の差」として浮かび上がってくる。

2. OSI参照モデル×開発分野

3. Webアプリ開発は「OSIの上で完結する世界」

まず、Webアプリケーション開発はOSI参照モデルの最上位であるアプリケーション層を主な舞台とする分野である。開発者はHTTPやRESTといった高レベルなプロトコルを用いて処理を記述し、パケット分割、再送制御といった下位層の複雑な問題は、OSやネットワークスタックに委ねられている。通信が失敗しても再試行すればよく、多少の遅延や順序の入れ替わりはUXの問題として扱われる。この世界では「通信は不安定である」という前提そのものが設計に組み込まれており、結果として下位層を強く意識しなくてもシステムが成立する。

4. ネイティブアプリは「OSとの境界」が主戦場

ネイティブアプリケーション開発では、Web開発と同様にアプリケーション層が中心となるものの、OSとの距離は一段近くなる。メモリ管理やスレッド制御、ファイルI/Oといった要素が現実味を帯び、OSのスケジューリングやリソース管理を意識しないと性能や安定性に影響が出る。とはいえ、ネットワークスタックやデバイス制御の多くは依然としてOSによって抽象化されており、物理層やデータリンク層を直接扱うことはほとんどない。ネイティブアプリは「OSのルールを守って書くソフトウェア」であり、ハードウェアと直接向き合うことは稀である。

5. 自動運転アルゴリズムは「物理世界を直接扱う」

一方、自動運転開発における自己位置推定、経路計画、車両制御といったアルゴリズムは、理論的にはアプリケーション層の処理に分類される。しかしその実装は、OSI参照モデルの上位層だけでは完結しない。センサデータの取得タイミング、時刻同期の精度、通信遅延やジッタといった下位層の特性が、そのまま推定精度や制御の安定性に影響を与えるためである。ここでは「通信が遅れる」ことはUXの問題ではなく、制御対象の挙動が変わるという物理的な結果を伴う。自動運転では再試行や後戻りが許されず、誤った判断は即座に現実世界の挙動として表出する。この点が、Webや一般的なアプリケーション開発との決定的な違いである。

6. 車載ネットワークは「OSIを下から作る世界」

車載ネットワークであるCANやLINは、OSI参照モデルの下位層、特に物理層とデータリンク層を中心に設計された技術である。これらはIP通信を前提とせず、限られた帯域と厳しいリアルタイム制約の中で、確実かつ決定論的にデータを伝送することを目的としている。フレームの欠落や遅延は安全性に直結するため、通信は「失敗したら再送する」ものではなく、「そもそも失敗しないように設計する」思想に基づいている。近年普及が進むAutomotive EthernetではIPやUDP、DDSといった上位層技術が導入されているが、それでもリアルタイム性と信頼性が最優先される点は変わらない。ここでは通信は利便性のための手段ではなく、安全性を成立させるための基盤である。

7. コンピュータそのものの構成の違い

さらに、これらの違いはコンピュータそのものの構成にも明確に表れている。Webアプリやネイティブアプリが動作する汎用PCは、高性能なCPUや豊富なメモリを備え、ある程度の遅延やジッタを許容する設計となっている。

一方、車載ECUは限られた計算資源の中で、常に同じ時間で、常に同じ結果を返す決定論的な動作と高い安全性を保証する必要がある。そのためリアルタイムOSやセーフティ機構が重視され、動的メモリ確保や例外処理といった便利な言語機能でさえ制限される。同じC++という言語を用いていても、その書き方や許される表現が大きく異なるのは、この実行環境の差によるものである。

8. OSIを超えた「責任境界」の違い

このように、Webアプリやネイティブアプリ開発は主にOSI参照モデルの上位層に閉じた世界で完結するのに対し、自動運転開発はアルゴリズムから通信、ハードウェア、さらには物理世界までを縦断的に扱う必要がある。そして車載ネットワークは、その最下層を支える基盤として機能している。これらの違いを理解することは、単なる技術選定の話にとどまらず、異なる分野のエンジニア同士が前提の違いを理解し、協調してシステムを設計するための重要な視点となる。