注意
本記事の内容は個人的な勉強・備忘録を目的としており、勤務先や関係者とは一切関係ありません。
人間の運転思考をモデルとして、三層に分けてみる
人間の運転行動を3つの階層に分解し、AIに対応させる。
| 層 | 人間の機能（イメージ） | 自動運転での実装 | 役割 |
|---|---|---|---|
| 長期記憶 | 計画・知識、地図、ルート、交通ルール | ルート計画エージェントや交通ポリシー作成 | 数分〜数十分の目的地への経路選択や状況判断 |
| 短期記憶 | 状況判断、信号、周囲の車、工事現場 | E2E 運転ポリシー(End-to-End AI) | 数秒〜十数秒の右左折、車間調整 |
| 反射 | 生命維持・回避、飛び出しブレーキ、横滑り制御 | 安全監視・低レベル制御 | ミリ秒の緊急回避、車両安定化 |
筋が悪い分け方
直感的に理解しやすいが、下記のように問題がある分け方である
- 筋が悪い主な理由：
- 時間スケールでの分け方は、現実の処理ときれいに対応しない
- 法的責任・安全認証の軸とズレる
- 学習・データの観点でも、別々のAIにしすぎると非効率
利点としては人に理解してもらうにはよいモデル構造であり、産業構造的にマッチしていると思っている。
エコシステム｜「分業」で実現する次世代の自動運転
各層を得意なプレイヤーが担当する「水平分業モデル」
- 長期記憶層（地図・ルート）
- 担当：Googleやトヨタなどのプラットフォーマー
- 理由：膨大な地図データの維持・更新能力
- ポイント：膨大なデータ処理にかかるコスト問題
- 短期記憶層（運転ポリシー）
- 担当：ティアフォー、チューリング、Waymoなどの新しい取り組みがある会社
- 理由：大規模モデル（VLM等）やE2E技術のスピード感ある開発
- ポイント：新しいアプローチを試せる環境（研究開発）
- 反射層（安全装置・制御）
- 担当：自動車メーカー
- 理由：ブレーキ、ステアリングなど実車ハードウェアと直結する安全責任
- ポイント：車の特性や運転制御などを把握しており、シナリオ検証のノウハウが必須
個人的な見解
課題：バラバラのAIエージェントをどうやって安全に統合するか？
答え：複数のエージェントを束ねる「自動運転 OS」が必要である。
チューリングの「Turing Tech Talk #16 自動運転を支えるLinuxベースのミドルウェア開発」でも出てきたけど、AIが誤った判断するのはよくあること...
全て正しいけどおかしい経路というものも自動運転では存在して、「この気候では全て正しいリミットの中の加速度だし切れ角だけど、壁の方に行ってしまう」ようなものは実験の時に乗っているドライバーが判断して止める仕組み
なので、自動運転OS内で安全を確保するのがよいと思っており、形式検証を利用して、地道に行う必要があると思っている。ティアフォーでは、北陸先端技術大学院大学の「次世代車載基盤システムのための形式手法と検証ツールの創出」で、自動運転を支える基盤の安全性と信頼性を担保しているみたい。現在動作しているECUでも、モデル検査で安全性を確保している。
「自動運転 OS」の役割
単なる基本ソフトではなく、異なる「脳」を調停するプラットフォーム
OSが担う5つのコア機能
-
リソース管理・リアルタイム性
- 各エージェントの計算デッドライン（締切）を厳守させる
-
安全パーティショニング（隔離）
- E2E（AI）が暴走しても、反射層（安全装置）は巻き込まれずに動作させる
-
API / メッセージ定義
- 長期「目標車線は右」
- 短期「右へ移動する軌道生成」
- 反射「その軌道は安全か判定」
-
アップデート管理
- 地図やAIモデルは頻繁にOTA更新。反射層は堅牢に維持
-
監視・フェイルセーフ
- エージェント応答停止時に「最小リスク状態（路肩停止など）」へ移行
反射層の実装「RSS (Responsibility-Sensitive Safety)」
「これ以上近づいたら物理的に止まれない」を数式化し、監視する
RSSの基本概念と仕組み
-
左側：安全距離の定義
- センサーで自車・他車の速度や距離を計測
- 数式 $d_{safe} = f(v_r, v_f, \rho, \dots)$ を用いて、「前走車が急ブレーキを踏んでも、自車が反応遅れ $\rho$ を含めて間に合うギリギリの距離」を計算する
-
右側：監視と介入のフロー
- AI（E2E）からの制御指令を、RSSが常に監視する
- 現在の車間距離 $d$ が安全距離 $d_{safe}$ 以上（Yes）なら、AIの指令をそのまま通す（SAFE状態）
- 安全距離を割り込んだ（No）場合、DANGEROUS状態と判断し、AIの指令を無視して強制的に介入する
- PROPER RESPONSE（適切な回避行動）として、定義された最小限の減速度でブレーキをかける
RSSを「状態遷移モデル」に落とし込む
安全検証のために、連続的な物理現象を5つの離散状態（State）に分類
-
SAFE（安全）
- $d \ge d_{safe}$
- AI（E2E）の制御指令をそのまま通す
-
DANGEROUS_PRE_RESPONSE（危険・反応時間内）
- 危険だが、人間（またはシステム）が認識するまでのラグ（$\rho$秒間）
- アクション：加速禁止
-
DANGEROUS_PROPER_RESPONSE（危険・回避中）
- 反応時間を過ぎた状態
- アクション：全力ブレーキ（RSSが定める適切な回避行動）
-
SAFE_STOP（安全停止）
- 危険状態で停止完了。安全が確認されるまで動かない
-
VIOLATION（違反）
- あってはならない状態（検証でここに入らないことを証明する）
モデル検証
「理論上、絶対に事故らない」を数学的に証明する
シミュレーション（数万km走らせる）だけでは不十分。
時間オートマトン検証ツールを使い、全パターンを網羅的に検査する。
モデルの構成要素
- Plant: 車の物理挙動（$v_{next} = v + a \cdot \Delta t$）
- Planner: E2Eプランナー（ランダム/無茶な値を出すように設定）
- RSSController: 状態遷移マシン
証明すべきクエリ（問い）
-
安全性の証明
A[] not (d == 0 && vr > vf)- 意味：未来永劫、追突状態にはならない
-
設計の正当性
A[] rss_state != VIOLATION- 意味：安全装置自体が設計ルールを破ることはない
所感
このあたりは、10年近く前からルールベースでも、議論されていた話である。大学院にいるときは、自動運転を実現するにはルールだけでは無理だと判断したが、LLMの台頭で、ルールではない方法で運転して、安全はルールで解決をすれば、自動運転の実現は可能だと思い始めた。
まとめ
「賢いAI」を「確実な数式」で包み込むアプローチがいいのではないか？
- 構造化: 自動運転を「長期・短期・反射」に分け、人間の認知機能と同様に扱う
- プラットフォーム: 異なるベンダーのAIを統合する「自動運転 OS」が競争の鍵
- 安全性保証: 数理的な安全ルールとモデル検証を組み合わせることで、ブラックボックスになりがちなAI自動運転に対して「証明可能な安全性」を付与できる