小説で学ぶ自動車ソフトウェア開発 (その2) 序章
前回は、本書全体の導入として、自動車ソフトウェア開発がなぜ他のソフトウェア開発と異なるのか、そしてA-SPICE、ISO 26262、SOTIF、OTA、AUTOSAR、自動運転という6つの世界が、どのように一つの車の上でつながっているのかを概観した。
今回から、物語はいよいよ「プロジェクト・カイト」の現場へ入っていく。主人公の成田剛志は、Web系エンジニアから車載ソフトウェアの世界へ飛び込み、初めてその巨大さと複雑さに向き合うことになる。
序章 カイトという名のプロジェクト
2026年4月初旬、東京郊外。アイソー株式会社 本社・大会議室。
「これが、プロジェクト・カイトの全貌だ」
大会議室の壇上に立った社長の和泉屋 俊宏さんが、そう言ってリモコンを押した。背後のスクリーンに、一台の車のレンダリング画像が現れた。流れるような曲線のルーフ、フラッシュサーフェスのドアハンドル、ヘッドライトのところに目立たないようにあしらわれたLiDARのアレイ。一見しただけでは「次世代EV」というありふれた言葉でしか説明できない。だが、和泉屋社長が次に映し出したスライドを見て、僕は思わず息を呑んだ。
そこには、車の輪郭線の上に、まるでカルテに描かれた人体の臓器のように、無数の部品が描かれていた。100以上のECU。十数本のバス。バッテリー、モーター、インバータ、センサー、通信モジュール、ゲートウェイ。そしてそれらの下に、こう書かれていた。
「総コード行数：2億行」
「2億行」と社長は繰り返した。「これがカイトに乗るソフトウェアの規模だ。比較のために言うと、Boeing 787の機内ソフトウェアは約1,400万行、Linuxカーネルが現在約3,000万行、Windows 10で約5,000万行。我々が来年量産を始める一台の車には、それらをすべて足したより多くのコードが、走りながら毎秒動き続ける」
会議室のあちこちで、誰かが小さく息を吐く音が聞こえた。僕は二週間前にここに来たばかりで、まだスライドを撮影してもいいのかどうかすら、よくわかっていなかった。
「そして、そのソフトウェアは、6つの世界の合流点で書かれることになる」
社長は次のスライドに進んだ。そこには、六角形のような図が描かれていた。中心に「カイト」と書かれ、その周りに六つのラベルが配置されていた。
① 開発プロセス（A-SPICE）
② 機能安全（ISO 26262・ASIL）
③ SOTIF（ISO 21448）
④ OTA・SDV（ISO 24089・UN-R156）
⑤ AUTOSAR（Classic／Adaptive）
⑥ 自動運転技術（従来型パイプライン・E2E）
「カイトを世に出すには、この6つを、一つの製品の上で同時に成立させなければならない。一つでも欠けたら、出荷できない。一つでもおざなりにしたら、人が死ぬ」
「私は今日、皆さんに難しい話をしようと思っていない。むしろ、シンプルな話をしたい」
和泉屋社長は壇上を一歩前に進んだ。眼鏡の奥の目が、何かに焦点を合わせた。
「カイトは、ただの車じゃない。これは、私たちが30年かけて作ってきた"車載ソフトウェアの全部"を、一台に詰め込もうとしている挑戦だ。私はこのプロジェクトに、社運を賭けている」
「皆さんの中には、エンジン制御出身の人がいる。ボディ系の人がいる。情報系から転職してきた人がいる」――そう言うと、社長は一瞬、会場の前方に座っていた僕の方を見たような気がした。気のせいかもしれない。――「Webやモバイルの世界から来た若い人もいる。みんな違う世界から集まった。だが、これから1年半、カイトを世に送り出すまで、皆さんには"一つの世界"を見てもらう必要がある」
「6つのテーマは、別々の本に書かれている。別々の規格に書かれている。別々の専門家がいる。だが、一つの車の上では、それらは絶対に分けられない。なぜか」
社長はスライドを進めた。さっきの六角形に、線が引かれていった。中心の「カイト」から放射状にではなく、外側の6つのラベル同士が、互いに、複雑な蜘蛛の巣のように繋がれていく。
「A-SPICEは、開発プロセスの"基盤"だ。これがないと、他の5つの規格が要求する開発の証拠が揃わない。だがA-SPICEだけでは、安全な車は作れない」
「ISO 26262は、機能安全の規格だ。これがないと、ECUが壊れたときに人が死なないことを保証できない。だが、26262だけでは、AIが間違える"故障ではない誤動作"を扱えない」
「ISO 21448、SOTIFは、その"故障ではない誤動作"――つまり、システムが正しく動いているのに、結果として危ない、という新しい世界の安全を扱う規格だ。E2E自動運転の安全認証は、ここなしには成立しない」
「ISO 24089とUN-R156は、OTAの規格だ。これがないと、量産後のソフトウェア更新を、安全に、合法的に、世界中の何百万台の車に届けられない。OTAは便利な機能じゃない。これからの自動車のビジネスモデルそのものだ」
「AUTOSARは、車載ソフトウェアの共通言語だ。これがないと、何百のサプライヤーが作ってくるソフト部品が、一つのECUの上で噛み合わない。AUTOSAR Classicは従来型ECUの基盤。AUTOSAR Adaptiveは、SDV時代の高性能ECUの基盤」
「そして、自動運転技術。これがカイトの差別化要因だ。L3対応で出して、将来的にはL4へ進化させる。従来型のパイプラインと、E2EのAIモデル、両方を載せたハイブリッドアーキテクチャで」
「この6つは、一つでも欠けたら、カイトは飛ばない」
そう言うと、社長は一拍置いた。
「だから、皆さんがこれから1年半、自分の専門分野だけを見て仕事するのは、許されない。隣の世界がどう動いているか、自分の決定が隣の世界にどう響くか、常に意識しながら作業してほしい」
「カイトという名前は、凧（たこ）から取った」
社長は少し笑った。
「凧というのは、一本の糸でしか地上と繋がっていない。でも、その糸が切れたら、もう取り戻せない。逆に、糸さえちゃんと持っていれば、どんなに高くまで上がっても、必ず戻ってこられる。我々が作るのは、そういう車だ。空高く飛ぶけれど、地上の人間からは絶対に離れない。それが、車載ソフトウェアエンジニアの仕事だ」
会議室は静まり返っていた。僕は、自分が手にしているスマホのメモアプリに、「凧の糸」「絶対に離れない」と書きつけていた。書きつけながら、頭の片隅で、社長が言ったあの六角形の絵を思い出していた。あれは、たぶん、これからの一年半、僕が何度も見返すことになる図だった。
社長がスライドを閉じようとしたその瞬間、後方の席から声が上がった。
「和泉屋さん、一点だけ」
振り向くと、五十代前半の体格のいい男性が立っていた。プロジェクトマネージャーの林 英男さん（52歳）だった。眉が太く、声にやや圧がある。
「カイトのマイルストーン、一覧表を作ってください。来週の顧客説明に使います」
社長は一瞬だけ顔を上げ、「林さん、その話は後で」と短く答えた。林さんは「了解です」とだけ言って座ったが、どこか不満そうに手帳に何か書き込んでいた。
----なんか、雰囲気が変わった気がした。あの人が、このプロジェクトのPMなんだろうか。
僕の横では、今日初めて隣に座った同期らしき人物が、小声でこちらに話しかけてきた。「あの人、林PMですよね。スケジュールのことになると目の色が変わるって、先輩に聞きました」と言った。
「......成田といいます。今日からカイトプロジェクトに配属で」
「太田です、同じく今日から」と彼は笑った。太田 悠季生（おおた ゆきお）、26歳。前職はFA機器メーカーのエンジニアで、組込みは多少経験があるが、車載の世界は今日が初めてだという。明るくてよく笑う。話しぶりからは、あまり深刻に考えすぎない性格が滲んでいた。
会議が終わって、皆が立ち上がる中、僕の隣に藤谷さんが立っていた。
「成田くん、いまの話、わかった？」
「半分くらい、わかった気がします。半分は、まだ何の話かわからないです」
「うん、それでいいの。今日わからなかった半分が、これからの1年半で埋まる。私たちはあの六角形を、一個ずつ、君と君の同僚たちに渡していくから」
「順番、ありますか？」
「もちろん。最初は①、A-SPICE。これがないと他が建てられないから。次に②機能安全。これがないと③SOTIFが理解できないから。次に④OTA。これがないと⑤AUTOSARのAdaptiveの意味がわからないから。そして⑥自動運転。これは6つを全部統合した先にあるから」
「順番にも、理由があるんですね」
「そう。順番にも、構造がある。それを次の章で全部見せるから、覚悟しておいて」
藤谷さんはそう言うと、ニヤッと笑って会議室を出ていった。僕は、しばらく自分のスマホのメモを見つめていた。
「凧の糸」「絶対に離れない」
そのあと、もう一行、僕は書き足した。
「6つは、ひとつ」
地図の章 6つの問いと、それを繋ぐ一本の線
全体像 ―― 本書のすべての章は、この一枚の地図の上を歩く
翌日、藤谷さんは僕を会議室C-3に呼んだ。ホワイトボードには、何も描かれていなかった。
「成田くん、座って」
藤谷さんは、マーカーを手に取った。
「昨日、社長があの六角形の話をしたよね。今日はもっとちゃんとした地図を渡す。私たちの社内の研修プログラムでは、これを"6つの問い"と呼んでる」
藤谷さんは、ホワイトボードに大きく問いを書いていった。
問い① 車載ソフトウェアの開発を、世界共通の物差しでどう測るか？ → A-SPICE（Part 1）
問い② ECUが壊れても人が死なないようにするには？ → 機能安全 / ISO 26262（Part 2）
問い③ ECUが壊れていないのに、AIが間違えるとき、誰が責任を取るのか？ → SOTIF / ISO 21448（Part 3）
問い④ 量産後、世界中の何百万台の車のソフトをどうやって安全に更新するか？ → OTA / SDV / ISO 24089 / UN-R156（Part 4）
問い⑤ 100社以上のサプライヤーが作るソフト部品を、一つのECUに乗せて噛み合わせるには？ → AUTOSAR Classic / Adaptive（Part 5）
問い⑥ 自動運転は、従来のソフトウェア工学では作れない。じゃあ、どう作るのか？ → 自動運転技術 / 従来型パイプライン / E2E（Part 6）
「6つの問い。それぞれは独立した問いに見えるよね」
「見えます」
「でも実は、一本の線で繋がってるの。今日、それを見せる」
藤谷さんはマーカーを置いて、ホワイトボードの右側に、上から下へ縦に書いていった。
① A-SPICEは、何の上に立つか？ → "プロセスで品質を作る" という思想
② 機能安全は、何の上に立つか？ → A-SPICEのプロセスの上に、"安全関連の追加プロセス" を乗せたもの
③ SOTIFは、何の上に立つか？ → 機能安全（26262）が扱えない領域 ―― "AIの誤動作" を新しく定義したもの
④ OTAは、何の上に立つか？ → ①②③で保証された安全な車を、"量産後も継続的に進化させる" 仕組み
⑤ AUTOSARは、何の上に立つか？ → ①〜④すべてを実現可能にする、"共通のソフトウェア基盤" そのもの
⑥ 自動運転は、何の上に立つか？ → ①〜⑤すべての集大成。プロセスも、安全も、SOTIFも、OTAも、AUTOSARも、ぜんぶ要る
「見える？」
「あ、これって......」
「そう、積み重なってるの。下から積んでいく。一番下が①A-SPICE、その上に②機能安全、その上に③SOTIF、その上に④OTA、その上に⑤AUTOSAR、てっぺんに⑥自動運転」
「これが、本書の章立ての順序そのもの」
全体地図
本書の6つのPart の積層構造
Part 6 自動運転（すべてが集約される頂点）
Part 5 AUTOSAR（①〜④を技術として実装する基盤）
Part 4 OTA・SDV（製品を継続進化させる仕組み）
Part 3 SOTIF（"故障ではない危険" を扱う新領域）
Part 2 機能安全（"故障による危険" を防ぐ古典領域）
Part 1 A-SPICE（すべての開発プロセスの基盤＝OS）
※下の Part を理解しないと、上の Part の意味は半分しか掴めない。だから順番に読む。
6つの世界はどう連携するか ―― シナリオで見る
「もう一個、見せ方を変える」と藤谷さんは言った。「同じ六つを、"カイトに起きうる出来事" の順で並べたらどうなるか」
藤谷さんは、ホワイトボードの下半分に、一連の流れを書いた。
【シーン1：開発が始まる】
OEMから契約書が届く。"A-SPICE L3で開発してください"。
→ Part 1（A-SPICE）の話。プロセスの物差しを揃える。
【シーン2：安全要件を引き出す】
L3自動運転をやるなら、システム要求の中に "ASIL D" の機能が含まれる。
→Part 2（機能安全）の話。ハザード分析、ASIL分解、フェイルセーフ設計。
【シーン3：AIの誤動作をどう保証するか】
自動運転にCNNやTransformerを使うが、AIは "壊れていないのに間違える" ことがある。
→Part 3（SOTIF）の話。性能限界の識別、ODD定義、統計的検証。
【シーン4：出荷後にバグが見つかる】
量産後、世界中で走る車のソフトに、後から脆弱性や改善点が見つかる。
→Part 4（OTA・SDV）の話。安全なソフトウェア更新、ロールバック、型式認証の継続性。
【シーン5：そもそも、これら全部はどんなソフト基盤の上で動くのか】
ブレーキECUとADC（自動運転ドメインECU）は別の "性格" を持つ。前者はリアルタイム性最優先、後者は計算量最優先。
→Part 5（AUTOSAR）の話。Classic（古典的ECU向け）とAdaptive（高性能ECU向け）、二つのスタック。
【シーン6：そして、自動運転そのものはどう作るのか】
Perception → Planning → Control の従来型パイプラインか、それともE2EのAIモデルか。Waymo型か、Tesla型か。
→Part 6（自動運転）の話。①〜⑤の知識をすべて使って、最後に "車を運転するソフト" を作る。
「これがカイト・プロジェクトのライフサイクル全体。最初から最後まで、6つの世界を横断する」
相互関連の例 ―― 一つの設計判断が、6つの世界に響く
「具体例を一つ出す」と藤谷さんは続けた。
「カイトでは、ある日、自動運転ドメインECU（ADC）のソフトウェアアーキテクチャに、ある変更が入ったとする。具体的には、E2E型のNNモデルを、従来型のセンサーフュージョン部分の代替として導入する」
「これは、Part 6の自動運転技術の世界の話。だけど、その変更がどんな波紋を起こすか、見てみよう」
・Part 1（A-SPICE）への影響：SWE.2のソフトウェアアーキテクチャ変更。SUP.10の変更管理プロセスを通す。SYS.3のシステムアーキテクチャにも影響、SYS.2のシステム要求まで遡って確認。
・Part 2（機能安全）への影響：ASIL D機能をNNで実装する場合、ISO 26262が "NNに対するASIL D割当ては慎重に" と言ってる。アーキテクチャ全体の安全分析（FMEDA、FTA）を再実施。
・Part 3（SOTIF）への影響：NNの導入は SOTIF の領域そのもの。新しい "性能限界シナリオ" を識別し、ODD制限・統計的検証を再設計。
・Part 4（OTA）への影響：NNモデルは数GB。OTA更新のサイズ・帯域・検証戦略が変わる。Canary releaseの戦略を見直し、ロールバック手順も再定義。
・Part 5（AUTOSAR）への影響：NN推論はClassic AUTOSARでは荷が重い。Adaptive AUTOSARベースの実装に移行。POSIX対応、サービス指向アーキテクチャ、動的なリソース割当。
・Part 6（自動運転）への影響：当然、自動運転アーキテクチャそのもの。従来型と E2E のハイブリッドをどう統合するか、UniAD的アプローチか、Tesla FSD型か。
「ね、一つの変更で、六つの世界が全部動くの。だから、エンジニア一人が一つの世界だけ知ってればいい、っていうのは通用しない。最低限、隣の世界のことを知っておく必要がある」
本書は、その"最低限"を、ちゃんと小説形式で伝えるために書かれてる。難しい規格書を読む前に、まずは"あの6つはこういう関係なんだ"という肌感覚を掴んでほしい
本書の読み方
本書の読み方の三つの原則
- 順番に読む。Part 1 → Part 6 へ、下から積み上げる構造になっている。上の Part を読むときに、下の Part の知識が前提として使われる。
- 地図を時々眺める。各Partの最後で「いま自分がどこにいるか」を確認する。本書では各Partの終わりに "剛志のノート" として、これまで習った全体を振り返る場面がある。
- 分からなくても、進む。最初の通読で全部わかる必要はない。むしろ、一度通読してから二周目に入ると、各Partの相互関連がはっきり見えてくる。
「これが今日の話。地図を渡したからね」と藤谷さんは言った。「ここから1年半、私たちはこの地図の上を、一緒に歩く」
「お願いします」と僕は言った。
「じゃ、まずはPart 1。A-SPICEから入るよ。」
その夜、僕はノートの最初のページに、社長の言葉と、藤谷さんの六つの問いを書き写した。
剛志のノート（序章）
・カイト＝凧。空高く飛ぶが、糸で地上と繋がっている。それが車載ソフト。
・6つの世界：A-SPICE／機能安全／SOTIF／OTA・SDV／AUTOSAR／自動運転。
・6つは独立しているように見えて、一本の積層構造で繋がっている。
・Part 1（A-SPICE）が一番下＝OS。Part 6（自動運転）が一番上＝集大成。
・一つの設計変更が、6つの世界に響く。だから "隣の世界" を知っておく必要がある。
・本書はこの6つを順番に小説で読み解く。次章からPart 1：A-SPICEへ。