小説で学ぶ自動車ソフトウェア開発 (その9) 自動運転
本エントリーは、小説で学ぶ自動車ソフトウェア開発（車載ソフトウェア開発）のシリーズものです。
小説で学ぶ自動車ソフトウェア開発 (その3) A-SPICE (1)
小説で学ぶ自動車ソフトウェア開発 (その4) A-SPICE (2)
小説で学ぶ自動車ソフトウェア開発 (その5) ISO26262とASIL
小説で学ぶ自動車ソフトウェア開発 (その7) SDV・OTA
小説で学ぶ自動車ソフトウェア開発 (その8) AUTOSAR
前回の「その8」では、Part 5としてAUTOSARの世界を見てきた。
100社が作るソフトウェアを、一台の車の中で動かす。そのためには、各社が好き勝手に作った部品を後から無理やりつなぐのではなく、最初から共通のインタフェース、共通の基盤、共通のアーキテクチャが必要になる。AUTOSARは、そのために生まれた「車載ソフトウェアの共通言語」だった。
今回から、いよいよ最終Partである 自動運転 に入る。
ここまで見てきた5つの世界――A-SPICE、機能安全、SOTIF、SDV・OTA、AUTOSAR――は、どれも独立した知識に見える。しかし、自動運転というテーマに向き合った瞬間、それらは一つの場所に収束する。
自動運転には、要求・設計・検証を追跡するA-SPICEが必要になる。人を傷つけないための機能安全が必要になる。AIが正常に動いているのに誤る危険を扱うSOTIFが必要になる。出荷後もAIモデルやソフトウェアを改善し続けるためのOTAが必要になる。そして、それらを車載システムとして統合するためのAUTOSARが必要になる。
つまり、自動運転は、この物語で学んできたすべての知識の集大成である。
今回の「その9」では、主人公の成田剛志が、ニック墨汁とともに、自動運転の基本構造であるPerceive・Plan・Act、SAEレベル、センサー、Planning、Control、そしてE2E自動運転の世界へ踏み込んでいく。
プロジェクト・カイトは、ついに空へ向かう。
Part 6 自動運転
----空を飛ぶ凧の正体
プロセスという土台（A-SPICE）があり、安全を保証する設計思想（機能安全）があり、知覚できない危険に備える枠組み（SOTIF）があり、空中でアップデートし続ける仕組み（OTA・SDV）があり、それらを支える共通言語（AUTOSAR）がある。
そのすべてが収束する場所が、ここだ。
自動運転----凧が初めて、自ら風を読んで空を飛ぶ。
第40章 ニック墨汁が見ている世界（AD.001：自動運転の全体像とSAEレベル）
ニック墨汁さんと初めてまともに話したのは、プロジェクト「カイト」が正式にL3フェーズへ移行した週の金曜日だった。
彼女はいつも少し離れた窓際の席にいて、巨大なモニターに映った点群データ----LiDARが吐き出す三次元の世界----を見つめていた。その点群は、まるで星座のように空間に浮かんでいた。人が歩き、車が走り、ガードレールがある。現実世界のすべてが、白い点の集合として再現されていた。
プロジェクト初期のころ、ニックさんはいつも「成田さん」と呼んでいた。でも、共に半年を過ごすうちに、気づいたら「成田くん」に変わっていた。本人は気にしていないようだった。
「成田くん、自動運転って何だと思う？」
いきなりだった。僕はコーヒーを持ったまま固まった。
「......車が勝手に走ること、ですか」
「それは答えじゃない。それは現象」とニックさんは言った。「自動運転は、人間がドライビングをする時に何をやってるのかを、完全に機械で再現しようとする試みよ。人間は何をやってるの？」
「見て......考えて......ハンドルを切る、ですか」
「正解。Perceive（知覚）、Plan（計画）、Act（行動）。これが自動運転の三大機能。人間の脳と手足を、センサーとコンピューターとアクチュエーターに置き換えることが、自動運転の本質」
知識
自動運転の基本構造：Perceive → Plan → Act
・Perception（知覚）：カメラ・LiDAR・レーダーで周囲を観測し、物体（車・歩行者・標識）を認識する
・Planning（計画）：認識結果をもとに、どこに行くか・どう走るかを決める
・Control（制御）：計画通りにステアリング・アクセル・ブレーキを動かす
「で、どのくらい"自動"かを定義したのがSAEのレベル分類」とニックさんはホワイトボードに向かった。
L0。ドライバーがすべてをやる。自動化なし。今の普通の車。
L1。ステアリングか加減速のどちらか一方をシステムが補助する。車線維持か、アダプティブクルーズコントロールか。どちらか。
L2。ステアリングと加減速、両方をシステムがやる。でも、監視はドライバー。ドライバーは常時監視義務があり、原則ハンズオン前提。スバルのアイサイト、初代日産ProPILOT、テスラのオートパイロットがここ。なお、ProPILOT 2.0やGMのSuper Cruiseのように特定条件で手放し走行を許す"ハンズオフL2"も、SAE上はあくまでL2の特殊形態で、ドライバーの監視義務そのものは残る。
L3。特定条件下でシステムがすべてをやる。ドライバーは監視しなくていい。でも、システムから「引き継いでくれ」と言われたら、一定時間内に対応しなければならない。これを「条件付き自動運転」と呼ぶ。ホンダのLEGEND（2021年）が世界初の型式認定取得車。プロジェクト「カイト」の目標がここ。
L4。特定の運行設計領域（ODD：Operational Design Domain）内で完全自動。システムからの引き継ぎ要求なし。ドライバー不在でもいい。でも、ODDの外には出られない。WaymoのRoboタクシーがここ。
L5。あらゆる条件下で完全自動。ここで注意なのは、SAE J3016 はハンドルやペダルの有無をレベル定義の条件にしていないということ。よく"ハンドルなし、ペダルなし"と説明されがちだけど、定義としては"あらゆる道路・天候・運行条件で、システムが全運転タスクを担えること"。物理形状の話ではない。まだ実在しない。
知識
SAEレベルの本質的違い
L2以下：ドライバーが監視主体（システムは補助）
L3以上：システムが監視主体（ドライバーは例外対応）
この境界線は技術の問題だけでなく、法的責任の所在が変わる。L2の事故責任はドライバー。L4以上の事故責任はOEM/システム。L3はグレーゾーン----だから世界中の立法機関が今も議論している
「プロジェクト「カイト」はL3を目指している。具体的なODDは、高速道路の単一路線、時速0〜120km、昼間、天候良好、白線明瞭という条件」とニックさんは言った。「このODDを超えたら、システムはドライバーに引き継ぐ。だから、Part 3でやったSOTIF----知覚できない危険----が死ぬほど重要になる」
点群データがモニターの中で流れていた。センサーが見ている現実。そこには人間の目には見えない情報が詰まっていた。
「なぜL3が難しいか、わかる？」とニックさんが聞いた。
「......システムが監視主体だから、システムが判断を誤ったら、ドライバーが気づかない」
「そう。L2の失敗は、ドライバーがすぐ気づいてリカバリーできる。でもL3の失敗は、ドライバーが眠りかけているかもしれない瞬間に起きる。だから、L3は"十分に安全"ではなく"限りなく完璧"でなければならない」
その夜のノート。
剛志のノート（40・自動運転 L0〜L5）
① 自動運転の本質：人間の「見る→考える→動かす」をPerceive→Plan→Actで機械化。
② SAEレベルL0〜L5：L2まではドライバー監視主体。L3から監視主体がシステムに変わる。
③ L3の難しさ：システム失敗時にドライバーが気づかない状況が起こりうる。
④ ODD（運行設計領域）：システムが安全に動ける条件の定義。外れたら人間に返す。
⑤ カイトのターゲット：高速道路L3（天候良好・昼間・白線明瞭）。
第41章 センサーの目（AD.002：Perception----センサーと物体検出）
「センサーの話をしよう」とニックさんは翌週の月曜、またホワイトボードの前に立った。今日は午前中から技術勉強会が入っていた。珍しいことに泉谷さんも、藤谷さんも、中月さんも揃っていた。
「自動運転車には、人間の目に相当するものが複数必要だ。なぜ複数？」
「一つだと、死角ができる......と、あとはセンサーによって得意不得意がある？」と僕。
「その通り。センサーには三種類ある。カメラ・LiDAR・レーダーだ。それぞれを解説する」
カメラ。安価。解像度が高い。色・テクスチャ・標識の文字が読める。ただし、距離が直接わからない（三角測量や深度推定が必要）。夜・逆光・雨に弱い。人間の目に最も近い。
LiDAR（Light Detection And Ranging）。レーザー光を照射して、反射が返るまでの時間から距離を計測する。三次元点群データを生成。精度が高く、夜でも使える。ただし、コストが高い（高品質LiDARは数十万〜百万円）。雨・霧・雪に弱い（光が散乱する）。色・テクスチャは取れない。
レーダー（ミリ波レーダー）。電波を使う。距離・速度（ドップラー効果）が直接計測できる。悪天候に強い。分解能が低く、形状認識は苦手。主に先行車との車間距離計測（ACC）に使われてきた。
知識
センサーフュージョン
「一つのセンサーで完璧はない。だから複数のセンサーを組み合わせる----これがセンサーフュージョン」
・カメラ＋LiDAR：カメラで物体種類を認識、LiDARで正確な距離を取得
・カメラ＋レーダー：テスラの基本構成（ビジョンファーストアプローチ）
・カメラ＋LiDAR＋レーダー：WaymoやMobileyeが採用する三重フュージョン
フュージョンの方法：早期（センサーデータレベル）、中期（特徴量レベル）、後期（認識結果レベル）の3段階がある
「じゃあ物体検出の話」とニックさんは続けた。「カメラ画像から車・人・自転車などを検出するのは、ディープラーニングが使われている。YOLO（You Only Look Once）やDeformable DETRといったモデルが有名だ」
「ヨロ？」と藤谷さん。
「一回見るだけで検出する、という意味。従来の物体検出は"スライディングウィンドウ"方式で、画像の各領域を何度もスキャンしていた。YOLOはそれを一回のニューラルネット通過でやってしまう。リアルタイム処理に向いている」
LiDARの点群から物体を検出するのはまた別の話だった。PointNetやVoxelNetといった3D用のアーキテクチャが存在した。点群はピクセルと違って、位置情報を持つ非構造データだ。それを扱うためのモデル設計が必要になる。
「物体を検出したら次に必要なのは、トラッキング（追跡）だ」とニックさんは言った。「車は動いている。一フレームで検出しても、次のフレームで"あの車はどこに行ったか"を追い続けなければならない。カルマンフィルタやDeep SORTといったアルゴリズムを使う」
「カルマンフィルタ......アポロ計画で使われたやつ」と泉谷さんが言った。
「そう。1960年代の技術が今でも自動運転の中心にいる。数学は時代を超える」とニックさんが笑った。「それから、HDマップ（High Definition Map）も重要なPerceptionの要素だ。精度10cm以下の高精細地図をあらかじめ持っていて、センサーで取得した現在位置と照合することで、位置推定精度を上げる。これをMap-based Localizationという」
知識
Perception の出力
Perceptionが完了した時点で、システムは以下を持っている：
① 検出物体リスト（種類、位置、速度、向き）
② 自車位置（HDマップ上のどこにいるか、精度±10cm）
③ 自由空間（走れる領域）
この三つがPlanningへの入力になる
「ニックさん、LiDARを使わないテスラは大丈夫なんですか」と僕は聞いた。
「それが業界最大の論争の一つ。イーロン・マスクは"LiDARは余計なもの、カメラで十分"と言ってきた。実際、FSD（Full Self-Driving）はカメラだけで動いている。対して、WaymoはLiDAR必須と言っている。答えはまだ出ていない----これはPart 6の後半で深掘りする」
剛志のノート（41・Perception）
① センサー三種：カメラ（安価・色あり・距離弱）、LiDAR（3D・夜OK・雨弱・高価）、レーダー（速度OK・悪天候強・分解能低）。
② センサーフュージョン：複数センサーの弱点を補い合う。
③ 物体検出：YOLO系でカメラ、PointNet系でLiDAR。
④ トラッキング：カルマンフィルタ＋Deep SORTで追跡継続。
⑤ HDマップ：10cm精度の地図で自車位置を確定。
⑥ Perceptionの出力：物体リスト・自車位置・自由空間 → Planningへ。
第42章 どう走るかを決める（AD.003：Planning----行動予測と経路計画）
「Perceptionで"何があるか"がわかった。次は"どう動くか"を決める----Planningだ」とニックさんは言った。「Planningには三つの層がある。Mission Planning、Behavior Planning、Motion Planningだ」
Mission Planning。いわゆるルートナビ。出発地から目的地まで、どの道を通るかを地図上で計画する。これはGoogleマップと同じ発想。ただし自動運転では、現在の交通状況・工事情報・ODD条件も加味する。
Behavior Planning（行動計画）。局所的な意思決定層。「今、車線変更すべきか」「交差点で左折していいか」「この歩行者は横断するか待つか」を判断する。ここが自動運転で最も難しい部分の一つだ。
Motion Planning（動作計画）。Behavior Planningで決めた意思決定を、実際の軌跡（位置・速度・加速度のシーケンス）に変換する。「今から3秒間でどんな曲線を描いて車線変更するか」を計算する。
知識
行動予測（Behavior Prediction）
Planningの大前提として、周囲の車・歩行者が「次の数秒でどう動くか」を予測する必要がある。これをBehavior Predictionと呼ぶ
・物理モデル：等速直線、等加速、定曲率モデルなど。シンプルだが長期予測に弱い
・データ駆動モデル：LSTMやTransformerを使い、過去の軌跡から将来を予測。社会的相互作用（他の車との関係）も考慮
・インテンション推定：「この歩行者は横断するつもりか？」といった意図を推定する
「Motion Planningのアルゴリズムを聞いたことはある？」とニックさんが聞いた。
「RRT......ですか？ロボット工学で聞いた記憶が」と泉谷さん。
「そう。Rapidly-exploring Random Tree。ランダムにサンプリングしながら衝突回避経路を探索する。ロボットアームの軌跡計画から来た手法が自動運転にも使われている。他には、Polynomial Fitting（多項式曲線で滑らかな軌跡を生成）、Frenet Frame（道路の進行方向を基準にした座標変換で計算を簡単にする手法）などがある」
「コスト関数が重要だ」とニックさんは続けた。「安全性（障害物との距離）、快適性（加速度の変化量、ジャーク）、効率性（目的地への到達時間）、交通法規の遵守----これらをバランスさせるコスト関数を設計して、最小コストの軌跡を選ぶ。このコスト関数の設計は、ある意味でエンジニアの価値観が入る部分だ」
「価値観？」と藤谷さんが聞いた。
「"安全側に振るか、効率側に振るか"という設計判断。極端に安全側にすれば、片側一車線で大型車とすれ違うたびに止まってしまう。極端に効率側にすれば、危険な追い越しをする。この調整は純粋な技術問題ではなく、設計思想の問題だ」
Part 2で学んだ機能安全のASIL配分の話が、ここに繋がってくる。コスト関数のバランス自体が安全アーキテクチャの一部だ。
知識
フレネ座標系（Frenet Frame）
道路を基準にした座標系。道路の中心線をs軸（進行方向）、それと垂直方向をd軸とする。
この座標系を使うと「車線の中央から何メートル横にいるか（d）」「道路に沿って何メートル進んだか（s）」で表現できる。
直線・カーブ問わず同じ処理で扱えるため、Motion Planningで広く使われる
「Planningで一番難しい場所はどこですか」と僕は聞いた。
「インタラクション。人間同士は、アイコンタクトや手振りで暗黙的に"あなたが先にどうぞ"という意思疎通をする。機械にはそれがない。歩行者が"止まってくれると思って"道に踏み出した瞬間、車がまだ認識していなかったら、事故になる。人間社会の暗黙のコミュニケーションを、システムがどう再現するか----これが未解決の核心だ」
剛志のノート（42・Planning）
① Planning三層：Mission（ルート）→ Behavior（意思決定）→ Motion（軌跡計算）。
② 行動予測：周囲の車・人が次の数秒でどう動くかを予測。
③ Motion Planningアルゴリズム：RRT・多項式フィッティング・Frenet座標系。
④ コスト関数：安全・快適・効率・法規遵守のバランス。設計者の価値観が入る。
⑤ 最難関：人間同士の暗黙のインタラクションを機械で再現すること。
第43章 ハンドルを握る数学（AD.004：Control----MPCとPID）
「Planningで軌跡が決まった。次にControlがその通りに車を動かす」とニックさんは言った。「今日は制御理論の話だ」
「制御理論」と泉谷さんが少し身を乗り出した。彼は組み込みOS出身だから、この辺は馴染みがあるらしい。
「まずPID制御から始めよう。一番古典的で、一番広く使われている制御手法だ」
PID制御。Proportional（比例）・Integral（積分）・Derivative（微分）の三つを組み合わせた制御器。
目標値と現在値の「誤差」をeとする。P項：誤差に比例したフィードバック。誤差が大きければ強く、小さければ弱く動かす。I項：誤差の積分（過去の誤差の蓄積）を使う。定常偏差（ずっと微妙にずれ続ける状態）を解消する。D項：誤差の微分（誤差の変化速度）を使う。行き過ぎを防ぎ、振動を抑える。
知識
自動運転でのPID応用
・縦方向制御（速度・加速度）：目標速度との誤差をPIDでスロットル・ブレーキに変換
・横方向制御（ステアリング）：目標軌跡との横偏差をPIDでステアリング角に変換
PIDは単純だが強力。調整するパラメータが少なく、実装も簡単。ただし、モデル予測がない----今の誤差に反応するが、未来を見越した制御ができない
「PIDの次が、MPC（Model Predictive Control、モデル予測制御）だ」とニックさんは言った。「MPCはPIDより賢い。どう賢いか？」
「未来を予測する......？」と僕。
「そう。MPCは、車両の動力学モデル（車がどう動くかの数式）を持っている。そして、N秒先（ホライゾン）の未来を予測しながら、最適な制御入力を計算する。計算は最適化問題として解く。QP（二次計画法）などを使う」
具体的にはこうだ。「現在の状態（位置・速度・ヨー角）から、次の0.1秒・0.2秒・0.3秒......1.0秒（10ステップ）の車の動きを予測する。その中で、目標軌跡からの偏差・制御入力の大きさ・快適性（ジャーク最小化）を組み合わせたコスト関数を最小化する最適な制御入力列を計算する。その最初のステップだけを実行して、また次の0.1秒後に同じ計算をやり直す」
「これをReceding Horizonと呼ぶ。地平線が常に一定距離先にある、という意味だ」とニックさんは続けた。
知識
MPCの強み
① 制約を陽に扱える：「ステアリング角は±30度まで」「加速度は0.5G以下」という物理制約・快適性制約を最適化問題の制約条件として直接入れられる
② カーブ予見：前方のカーブを地図から知っていれば、手前から減速し始める（PIDにはできない）
③ 多変数を一度に最適化：縦・横の制御を同時に最適化できる
MPCの弱み：計算負荷が高い。リアルタイム性が要求される自動運転では、高速なQPソルバーと専用ハードウェアが必要
「ところで、自動運転の制御には横方向（ステアリング）と縦方向（スロットル・ブレーキ）がある」とニックさんは言った。「横方向は車線逸脱に直結するので安全クリティカル。縦方向は追突・衝突に直結する。どちらも間違えば人が死ぬ」
「Part 2の機能安全のASIL配分----横方向制御はASIL-Dになることが多い」と中月さんが口を挟んだ。「ステアリング制御の誤動作は、車線逸脱から対向車線への飛び出しに直結するから」
「そういうこと」とニックさん。「制御理論は数学だけど、その背後には人命がある。このロジックをPart 2・Part 3のチームと協調して設計するのが、統合安全設計の本質だ」
剛志のノート（43・Control）
① PID：比例・積分・微分の三項で誤差にフィードバック。シンプル・実績あり。
② MPC：車両モデルでN秒先を予測し、最適制御入力を計算。制約を直接扱える。
③ 横方向制御（ステアリング）：ASIL-D相当。車線逸脱→対向車線飛び出しに直結。
④ 縦方向制御（速度・加速度）：追突・衝突に直結。
⑤ Receding Horizon：常に未来を見ながら今を制御する、MPCの本質。
第44章 モジュールを全部捨てたら（AD.005：End-to-End自動運転の登場）
「さて」とニックさんは水曜の午後に言った。「これまで話した、Perception→Planning→Controlというパイプライン。これを、全部一個のニューラルネットで置き換えてしまえという発想が出てきた。End-to-Endと呼ぶ」
「え、全部一個で？」と僕。
「そう。カメラ画像が入力、ステアリング角とスロットルが出力。中間の物体検出も行動予測も軌跡計算も、ニューラルネットの内部に暗黙的に詰め込む」
「......でもそれ、何かあった時に何が悪かったかわからなくない？」と藤谷さんが言った。QAエンジニアの本能だ。
「その通り。でも、まず歴史から見ていこう」
E2Eの原点は、1989年のCMU（カーネギーメロン大学）のALVINN（Autonomous Land Vehicle In a Neural Network、Pomerleau 1989）に遡る。三層ニューラルネットがカメラ画像からステアリング角を直接学習した。ちなみに、よく一緒に語られるNAVLABはCMUの実車プラットフォームの名前で、ALVINNはその上で動いていたニューラルネット----車そのものではなく、頭脳のほうがALVINN、と覚えると整理しやすい。高速道路で自動走行を実証した----もう35年前の話だ。
次の大きなマイルストーンは2016年のNVIDIAのPilotNet論文。98時間のドライビングデータでCNNを訓練し、新しい道路環境でも自動走行できた。「人間が教えていない運転スキルが自然に身についた」と論文は書いた。
そして2022〜2023年、テスラがFSD（Full Self-Driving）v11以降で、従来型パイプラインから"Occupancy Network＋E2E"への移行を始めた。2024年のFSD v12では、「C++で書かれた明示的なコード（ルールベース）がほぼ消えた。ニューラルネットがカメラからコントロールを直接生成する」とイーロン・マスクが発表した。
知識
E2E自動運転の学習アプローチ
・模倣学習（Imitation Learning）：人間ドライバーの運転データを「正解」として学習。PilotNet、初期FSDはここ
・強化学習（Reinforcement Learning）：シミュレーター内で「報酬（安全に走れた）」「ペナルティ（衝突した）」を通じて自律的に上達
・両者のハイブリッド：人間データで事前学習し、シミュレーターで強化学習でファインチューニング
テスラは実道での大量データ（全世界のテスラ車からの映像）を使った大規模模倣学習が強みとされる
「なぜE2Eが注目されているのか」とニックさんは言った。「理由は二つ。第一に、ルールベースのPlanningが作れない長尾（ロングテール）問題への期待。第二に、開発効率だ」
ロングテール問題。「普通の道路走行」は無数のエッジケースを含む。工事中の道路、泥で汚れた標識、センターラインが消えかけた農道、逆走してくる自転車......。ルールベースでは、このすべてのケースをエンジニアが手書きで対処する必要がある。対して、E2Eは「十分なデータがあれば、ニューラルネットが自動的に対処を学ぶ」という期待がある。
「ただ」とニックさんは少し声のトーンを落とした。「E2Eには根本的な問題がある。それを次章で掘り下げる」
剛志のノート（44・E2E自動運転の登場）
① E2E：カメラ→ステアリング角を一つのニューラルネットが担う。
② 歴史：1989年CMUのALVINN（NAVLAB上で動作）→2016年NVIDIAのPilotNet→2024年Tesla FSD v12。
③ 学習方法：模倣学習（人間データ）＋強化学習（シミュレーション）のハイブリッドが主流。
④ 期待：ロングテール問題をデータ量で解決・開発効率の大幅改善。
⑤ 懸念：藤谷さんが直感した通り「何かあった時に原因がわからない」----次章へ続く。
第45章 ブラックボックスの内側（AD.006：E2Eアーキテクチャ詳解）
木曜。ニックさんのデスクに近づいていくと、彼女は何かの論文を印刷したものに線を引きながら読んでいた。タイトルを読もうとすると、「UniAD」と書いてあった。
「見てもいいですか」と僕が聞くと、ニックさんは椅子を引いて「座ってもいい」と言った。
「E2Eアーキテクチャの詳細をやろうと思ってたところ。ちょうどいい」
E2Eの中身は、決してシンプルではない。イメージしやすいのは「カメラ画像→CNN→ステアリング角」だが、実際の最先端システムはもっと複雑だ。
「最初に理解すべきは、Transformerが自動運転に入ってきたこと」とニックさんは言った。「NLPで言語を処理するためのアーキテクチャが、画像・点群・時系列データ全部に使われ始めた」
Vision Transformer（ViT）。CNNのような局所的な畳み込みではなく、画像全体をパッチに分割してAttentionで処理する。長距離の依存関係を捉えるのが得意。自動運転では、遠くの歩行者と近くのガードレールの関係を同時に考慮できる。
Occupancy Network。空間を3Dグリッドに分割し、各セルが「占有されているか否か」（と、物体の速度・種類）を予測するネットワーク。従来の物体検出（バウンディングボックス）と違い、形状が複雑な物体や未知の物体にも対応できる。テスラのFSD後期版で採用された。
知識
UniAD（Unified Autonomous Driving）
2023年にCVPR Best Paperを受賞した上海AI Labのモデル。Perception・Prediction・Planning を統合したEnd-to-Endアーキテクチャ。
・TrackFormer：物体追跡（Transformerベース）
・MapFormer：HDマップの局所セグメンテーション
・MotionFormer：周囲エージェントの未来軌跡予測
・OccFormer：Occupancy予測
・Planner：自車軌跡生成
各モジュールは**クエリ（Query）**を通じてAttentionで相互作用。「物体追跡の結果が地図解釈に影響し、地図解釈が動作予測に影響し、動作予測が計画に影響する」という連鎖が、単一モデル内で実現される
「UniADのすごいところは、各タスクを分離しながらも、エンドツーエンドで一緒に訓練されている点だ」とニックさんは言った。「従来の手法では、物体検出モデルを別途訓練して、その出力を行動予測モデルに渡した。情報の損失が発生する。UniADは損失なく情報を通す」
「わかってきました」と僕は言った。「E2Eって"一つのネットワーク"というより"統合されたシステム"という意味のほうが正確ですね」
「その通り。厳密なE2E定義は論者によって違う。"カメラ入力からコントロール出力まで一切の中間表現なし"（テスラFSD v12的な立場）と、"複数のモジュールが統合訓練される"（UniAD的な立場）の二つがある。どちらもE2Eと呼ばれる」
「もう一つ重要なのは、世界モデル（World Model）という考え方」とニックさんは続けた。「周囲の世界がどう動くかを、ニューラルネットで内部的にシミュレーションする能力。自動運転に限らず、汎用AI研究の最前線のテーマでもある。WayveがGAIA-1というモデルで、走行シーンを生成する世界モデルを発表した（2023年）」
剛志のノート（45・E2Eアーキテクチャ詳解）
① Vision Transformer：画像全体をAttentionで処理。長距離依存関係に強い。
② Occupancy Network：3Dグリッドで空間占有予測。未知形状にも対応。
③ UniAD：Tracking→Map→Motion→Occ→Planをクエリベースで統合。CVPR Best Paper。
④ E2Eの二義：「純粋E2E（中間表現なし）」vs「統合訓練（モジュール間情報損失排除）」。
⑤ 世界モデル：周囲のダイナミクスを内部でシミュレーション。自動運転×生成AIの最前線。
第46章 解釈できないものを信頼できるか（AD.007：従来型 vs E2E）
金曜の夕方、藤谷さんがニックさんの席に歩いてきた。珍しいことだった。
「ニックさん、聞いていいですか。E2Eって、何かあった時にどうするの？」
「どういう意味ですか？」
「テストよ。QAの視点から言うと、あるインプットに対してあるアウトプットが出るのはわかった。でも、なぜそのアウトプットが出たのかが説明できない----それって、バグを直せないってことじゃないの？」
ニックさんは少し考えて、「座ってください」と言った。藤谷さんが椅子を引いた。
「従来型パイプラインとE2Eの比較をちゃんとやりましょう」
従来型パイプラインの強みは、解釈可能性だ。物体検出が失敗したのか、行動予測が外れたのか、Motion Planningの軌跡が悪かったのか、それとも制御が追いつかなかったのか。問題を切り分けることができる。テストも各モジュール単位で行える。「Perceptionのmean AP（平均精度）が0.85以上」「Planningの軌跡追従誤差が0.1m以下」という数値目標が設定できる。
従来型パイプラインの弱みは、長尾問題とモジュール間の情報損失だ。物体検出器が「自転車」と認識した結果をBehavior Plannerに渡す際、「その自転車が左に傾いて転倒しそう」という情報は失われる。また、エンジニアが想定していないエッジケースには、ルールが存在しない。
知識
ロングテール問題（Long Tail Problem）
自動運転が遭遇するシナリオの分布は、極端に偏っている。
・頻出シナリオ（直線走行、信号停止）：全走行の99.9%を占める。従来型で十分対応。
・稀なシナリオ（工事現場の誘導員の手信号、横断歩道のない場所での横断、馬が道路に立っている）：残りの0.1%だが、事故を起こしやすいのはここ。
対処三戦略：① 大量データで学習（E2Eの期待）、② シミュレーションで希少シナリオを人工生成、③ ODD設計でそもそも稀なシナリオを除外する
E2Eの強みは、統合最適化とデータスケーラビリティだ。人間のドライビングデータが増えるほど自動的に賢くなる。モジュール間の境界での情報損失がない。エンジニアが思いつかなかった解法をデータから学ぶ可能性がある。
E2Eの弱みは、解釈不能性・テスト困難性・過学習リスクだ。「なぜ右にステアリングを切ったか」が説明できない。覆い隠されたバイアスがある場合、それを発見できない。訓練データに存在しないシナリオに対して、何をするか予測が難しい----これを「分布外（Out-of-Distribution）問題」と呼ぶ。
「藤谷さんの懸念は完全に正しい」とニックさんは言った。「従来型はテスト可能、E2Eはテスト困難----これが現実。だから自動車メーカーの多くは、純粋なE2Eではなく、モジュールの一部をE2Eに置き換えるハイブリッドアプローチを取っている」
「例えば、PerceptionだけをE2E（統合型）にして、Planning・Controlは従来型のまま。PlanningにE2Eを取り入れる場合も、モニタリング層（ルールベースのセーフティチェック）を外側に置く」とニックさんは続けた。
「Plannerの外側にSafetyチェックを置く」----ASILの多重化と同じ発想だ、と僕は思った。Part 2で学んだ独立した安全層の考え方が、E2Eの世界にも生きている。
「そう。機能安全の考え方はE2Eにも適用される。Part 2がここにも繋がってくる」
剛志のノート（46・従来型 vs E2E）
① 従来型の強み：解釈可能・モジュール単位テスト・バグ切り分け可能。
② 従来型の弱み：長尾問題・モジュール間情報損失・ルール外エッジケース無力。
③ E2Eの強み：統合最適化・データスケール・情報損失なし。
④ E2Eの弱み：解釈不能・テスト困難・OOD問題。
⑤ 現実解：ハイブリッド（一部E2E化＋外側にルールベースSafetyチェック）。
⑥ ASILの多重化思想がE2E安全設計にも適用される。
第47章 保証できるか（AD.008：E2Eと機能安全・SOTIF）
「次の問題は、E2Eを使った時に機能安全とSOTIFをどう担保するか、だ」とニックさんは言った。月曜朝から中月さんも加わっていた。
「ニューラルネットはISO 26262の要求を満たせるか、という問題がある」と中月さんは開口一番言った。「現状、答えはほぼ"直接には無理"だ」
ISO 26262は、ソフトウェアに対してMISRA準拠・MC/DCカバレッジ・ウースト実行時間（WCET）解析などを要求する。これはルールベースの手続き型コードが前提だ。数億のパラメータを持つニューラルネットに対して、MC/DC（Modified Condition/Decision Coverage）を適用することは現実的ではない。
「だから、アーキテクチャレベルで対応する」と中月さんは続けた。「NNコンポーネントをASIL-B以下（あるいはQM扱い）にして、その周囲にASIL-DのSafetyモニターを配置するという設計だ。Safety Monitorはルールベースで動き、NNの出力が危険域に入ったら即時オーバーライドする」
知識
ISO/PAS 21448（SOTIF）とE2Eの相性問題
SOTIFは「意図した機能の限界」から来る危険を扱う。E2Eにおいては、この限界がより深刻になる：
・性能限界の不透明性：従来型なら「霧でカメラ精度が落ちる」と定量化できる。E2Eでは「霧でどれだけ精度が落ちるか」が分布として存在するが、最悪ケースの定量化が難しい
・未知の未知の増大：OOD（分布外）入力に対するE2Eの挙動は予測困難。まさにSOTIFの「未知の危険シナリオ」
・評価アプローチ：ブラックボックステスト（大量シナリオのシミュレーション）、Adversarial Testing（意図的に難しい入力を生成して試す）が主要手段
「SOTIFの視点でE2Eを見ると」とニックさんが加わった。「SOTIFの4象限でいう"未知・安全でない"ゾーン----訓練データにない状況でのE2Eの挙動----が特に問題だ。これを減らすには、大量かつ多様なデータでの訓練、シミュレーションによる希少シナリオのカバー、そして継続的なデプロイ後のモニタリングが必要だ」
「デプロイ後のモニタリング」と中月さんが言った。「それは車の中でのリアルタイム監視という意味と、フリートから収集した走行データの分析という意味の両方がある。後者が、OTAとの繋がりになる」
「Part 3とPart 4がここで繋がった」と僕はノートに書いた。
さらに深刻な問題があった。「E2Eモデルの訓練データに偏りがあった場合」とニックさんは言った。「例えば、日本の道路データで訓練したモデルを、インドの道路（車・自転車・牛が混在する）に使ったら、性能が著しく落ちる。これがSOTIFのODD違反だ。訓練データのODDと実際の運用ODDを一致させなければならない」
知識
E2Eモデルの安全評価アプローチ（実践）
① Shadow Mode：E2Eモデルを実際の制御に使わず、従来型の横でサイレントに動かして出力を比較。差異が大きい場面を記録・分析
② Scenario Database：テストシナリオのデータベースを構築。自動化されたシミュレーションで毎リリース回帰テスト。参照元のひとつが ISO/TR 4804:2020――自動運転車の安全と認知に関する技術報告書で、3-pillar approach（リスク評価／能力評価／運用評価）という安全評価フレームワークを提示している。シナリオベース評価の議論はここを起点に語られることが多い
③ Coverage Metric：「何パーセントのシナリオでテストした」ではなく、「どれだけの稀な状況を網羅したか」の指標を定義
④ Uncertainty Quantification：E2Eの推論結果とともに「不確かさ（自信度）」を出力させる。不確かさが高ければSafety Monitorがオーバーライド
剛志のノート（47・E2Eと機能安全・SOTIF）
① NNはISO 26262の直接適用が困難（MC/DC不可）→ アーキテクチャ分離で対応。
② 設計：NN（ASIL-B以下）＋外側のルールベースSafetyモニター（ASIL-D）。
③ SOTIFとの相性問題：OOD入力への挙動予測困難＝未知の危険シナリオ増大。
④ 対応策：Shadow Mode・シナリオDB・不確かさ定量化。
⑤ 訓練データODDと実運用ODDを一致させることが必須。
第48章 空中でアップデートし続けるAI（AD.009：E2EとOTA）
「E2Eモデルは、いつどうやって更新するんですか」と僕は火曜にニックさんに聞いた。
「それがPart 4のOTAと繋がる部分よ」とニックさんは言った。「実は、E2EとOTAの組み合わせは、自動運転を"常時進化するシステム"にする可能性を持っている。でも、それが新しいリスクも生む」
E2Eモデルは、訓練データが増えるほど性能が上がる。フリートを走らせながらデータを収集し、そのデータで新しいモデルを訓練して、OTAで全車両に配信する----これが「フリートラーニング」サイクルだ。テスラの競争優位のひとつがここにある。百万台規模のフリートが毎日データを送り続ける。
「でも、OTAでE2Eモデルを更新するということは」とニックさんは言った。「製品（車）の主要な安全機能が、リリースのたびに変わるということだ。これは従来の"ECUソフトウェアのバグフィックスOTA"とは、安全論的に全く別の話になる」
知識
AIモデルOTAの安全課題
① リグレッション問題：新モデルが古い苦手シナリオを克服しつつ、以前は得意だったシナリオで性能が落ちることがある（Catastrophic Forgetting問題）。全シナリオで回帰テストが必要
② 認証の問題：ISO 26262では、ソフトウェアの変更は再認証が必要。E2Eモデルの重みを更新するたびに完全な認証をやり直すのは現実的でない。「AIモデル更新の軽量認証プロセス」が業界課題
③ ロールバックの問題：OTAで新モデルを配信後、フリートデータで問題が発覚した場合の緊急ロールバック。Part 4で学んだデュアルバンク方式がここでも適用される
④ フリート内のモデル不均一問題：OTA配信は段階的ロールアウト。配信中は、同じ車種でもモデルのバージョンが異なる車が混在する。フリートデータ分析にバージョン情報を紐付けることが必要
「規制の話も重要だ」と中月さんが口を挟んだ。「国連の自動車規制UNR 156は、OTAソフトウェア更新に関する要件を定めている。SUMS（ソフトウェア更新管理システム）の要件がある。ECUソフトウェアの更新に関する記述だが、AI/MLモデルの更新への適用はまだグレーゾーンだ」
「ISO/IEC 42001（AI管理システム）という規格も出てきた」と中月さんは続けた。「組織がAIシステムを責任ある形で開発・デプロイするためのフレームワーク。自動車分野への適用は始まったばかりだが、フリートラーニング×OTAのサイクルを管理する枠組みとして注目されている」
「結局」とニックさんはまとめた。「E2E×OTAは、自動運転を"一度作れば終わり"から"常時改善し続けるサービス"に変える。これはSDV（Software Defined Vehicle）の核心だ。Part 4で学んだSDVのビジョンが、自動運転のAIと結びついて初めて完成する」
「凧を一度揚げたら終わりじゃない。風を読みながら、糸を操り続ける----その糸がOTAだ」
その言葉が、和泉屋社長の序章の話と重なった。
剛志のノート（48・E2EとOTA）
① フリートラーニング：百万台のデータ→新モデル訓練→OTA配信→性能向上サイクル。
② AIモデルOTAの課題：リグレッション・認証プロセス・ロールバック・フリート内不均一。
③ デュアルバンク方式：Part 4のOTAアーキテクチャがAIモデル更新にも適用される。
④ 規制：UNR 156（OTA管理）、ISO/IEC 42001（AI管理）が整備進行中。
⑤ E2E×OTA＝SDVの核心。凧を揚げ続けるための糸。
第49章 世界の今（AD.010：世界の自動運転プレイヤーと未来）
「最後に、今の世界の自動運転競争の全体像を見ておこう」とニックさんは言った。「競争の構図を理解することが、私たちのプロジェクト「カイト」の立ち位置を理解することに繋がる」
金曜の午後、全員が集まっていた。和泉屋社長も珍しく顔を出した。
「まず、WaymoとTeslaという対極の存在から始めよう」
Waymo（Google系）。L4フォーカス。サンフランシスコ・フェニックス・LAでRoboタクシー商業運行中（2024年現在）。LiDAR必須。HDマップ必須。ODD厳格に設定。一台あたりのコストが非常に高い。スケールの限界がある。ただし、「乗ったことがある人の体験談」は業界最高品質とされる。
Tesla（FSD v12）。カメラオンリー。HDマップ不使用。大量の実走行データ。「あらゆる道路で動く」ビジョンファーストアプローチ。百万台超のフリートデータ。コストを下げることでスケールを実現。ただし、FSDは現状L2扱い（監視義務あり）で、L3以上の規制認定は未取得。
知識
主要プレイヤー比較
・Waymo：L4ロボタクシー。LiDAR＋カメラ＋レーダー。HDマップ。従来型＋学習ハイブリッド。商業展開済み（米国ODD限定）
・Tesla：FSD（カメラのみ）。HDマップ不使用。純粋E2E（v12以降）。フリートデータ。L2認定（監視義務あり）
・Wayve（英）：世界初の真のE2Eアプローチを主張。GAIA-1世界モデル。NVIDIAが出資。欧州・ロンドンで実証実験
・Mobileye：Tier1 ADASサプライヤー。RSS（Responsibility-Sensitive Safety）という形式的に数学的記述された安全条件を独自に持つ。検証手法そのものではなく、「事故が起きたとき、どちらに責任があるか」を距離・速度・反応時間などで厳密に定義する責任配分アプローチである点に注意。IDとともにL4ロボタクシーを開発中
・中国勢（百度Apollo・華為・小鵬・理想）：中国市場で急速展開。政府支援と規制の柔軟性。特に高速道路L3はすでに市販車に搭載済み
・日本勢（本田・Toyota・日産）：ホンダLEGENDが世界初L3型式認定取得。Hondaは GM Cruise との共同で2026年ロボタクシー展開を計画していたが、2024年12月のCruise事業撤退を受けて計画は再編中。Honda単独、または別パートナーとの組み直しを含めて見直しが進んでいる
「業界全体のトレンドとして、三つある」とニックさんは言った。
第一、E2Eへのシフト。Perceptionだけでなく、Planning、さらにはControlまでE2Eに取り込む動きが加速している。「2025〜2030年が、従来型パイプラインからE2Eハイブリッドへの移行期になる」という見方が多い。
第二、ODDの拡張。今は「高速道路限定L3」が主流だが、一般道L3、悪天候対応、夜間対応へと段階的に拡大していく。その都度、SOTIFのリスク評価と機能安全の再認証が必要になる。
第三、コストの問題。LiDARは2016年に1台100万円だったが、2024年には1万円以下のものも登場した。これはL4のスケール展開を可能にするかもしれない。あるいは、カメラオンリーの方向が先に普及するかもしれない。「どちらが勝つか」は2026年時点でもまだ決まっていない。
「アイソーのプロジェクト「カイト」はどこに位置づけられるか」と和泉屋社長が口を開いた。久しぶりに聞く声だった。
「私たちはTier1だ。OEMに技術を提供する立場だ。つまり、特定のL3システムを作るのではなく、OEMが選んだアーキテクチャ（LiDARベースでもカメラファーストでも）に対して適合できる、柔軟なソフトウェアプラットフォームを提供することが目標だ」
「そのために」と社長は続けた。「A-SPICEのプロセス規律があり、機能安全の設計思想があり、SOTIFのリスク分析があり、OTA・SDVのインフラがあり、AUTOSARの共通言語がある。そしてその先端に、自動運転の技術判断力がある」
「六角形の全頂点が、ここに繋がっている」
剛志のノート（49・世界の自動運転）
① Waymo：L4ロボタクシー。LiDAR必須。ODD厳格。商業展開済み。高コスト。
② Tesla：カメラのみ。E2E（FSD v12）。フリートデータ強み。L2扱い現状。
③ Wayve・Mobileye・中国勢・日本勢：各々の戦略で市場形成。
④ トレンド：E2Eへのシフト・ODDの段階的拡張・センサーコスト低下。
⑤ カイトの立ち位置：Tier1として柔軟なソフトウェアプラットフォームを提供。
⑥ 六角形（A-SPICE×機能安全×SOTIF×OTA×AUTOSAR×AD）がここに収束。