安全性と評価 — 「十分に安全」はどう作り、どう示すか

自動運転の最難関は走ることではなく、安全であることを示すことです。ODD とミニマルリスク動作、走行距離の統計の壁とシナリオベース評価、冗長設計、そして機能安全と SOTIF — 信頼を作る工学の全体像を、動かしながら掴みます。

1. 「どれだけ安全なら十分か」という問い

前章で見たとおり、学習ベースのシステムには「この関数は仕様どおり」という証明が原理的に馴染みません。そこで実務では、安全性は単一のテストで証明するものではなく、複数の証拠を積み上げて論証するもの（セーフティケース）と捉えます。その論証の柱が、(1) 動作条件を限定する ODD、(2) 統計・シナリオ両面の評価、(3) 故障してもなお安全側に倒れる冗長設計です。本章はこの3本柱を順に見ていきます。

2. ODD — 「どこでなら安全か」を先に決める

ODD（Operational Design Domain, 運行設計領域）は、そのシステムが安全に動作できると設計・検証された条件の集合です: 道路種別、天候、時間帯、速度域、地理的範囲など。重要なのは、ODD の境界で何が起きるかまで含めて設計する点です。ODD を外れそうになったら、システムは運転者への引き継ぎ（フォールバック）か、それが不可能ならミニマルリスク動作（MRM） — 減速して路肩などへ安全に停止し、最小リスク状態（MRC）へ移行します。

ODD ダッシュボード — 条件を変えると判定とふるまいが変わる
このデモの ODD 定義（例）: 高速道路・豪雨でない・夜間の雨でない・100 km/h 以下。走行中に「豪雨」を押すなど ODD を外すと、システムはミニマルリスク動作に移行して減速し、路肩へ寄せて停止します（市街地では路肩がなく車線内停止になる＝より危険、という点にも注目）。条件を ODD 内へ戻すと運行を再開します。
POINT — ODD は「限定」ではなく「約束」 ODD を狭く取ることは性能の敗北ではない。「この条件下では人間より安全」という検証可能な約束に責任範囲を絞り込む設計行為であり、ロボタクシーが特定都市・特定天候から始まるのはこのためだ。ODD 逸脱時の MRM までを含めて初めて、約束は閉じる。

3. 統計の壁 — 走らせるだけでは証明できない

「人間並みに安全」を実走行の事故率で統計的に示そうとすると、途方もない距離が必要です。死亡事故は約 1.5億 km に 1件のオーダーでしか起きないため、無事故走行で信頼水準 95% を得るだけで数億 km、「人間より確かに良い」ことを比較で示すには数百億 km 規模が必要になります（RAND の試算が有名）。さらにソフトウェアを更新するたびに実績はリセットされる。そこで実務は、実走行＋シミュレーションによるシナリオ網羅の組み合わせに移行しました。危険なパラメータ領域（歩行者の飛び出し速度×遮蔽物距離など）を系統的に振って大量のシナリオを生成し、失敗モードを「距離」ではなく「網羅」で探すアプローチです。

必要走行距離の壁と、シナリオ網羅というもう一つの道
上＝対数スケールの距離軸。緑＝スライダーの信頼水準で「無事故」を示すのに必要な距離、オレンジ＝実車テストの累計（業界最大級で 10⁸ km 台）、水色＝シミュレーション累計（10¹⁰ km 台）。チェックを入れると「人間との差」を統計的に示すための距離に跳ね上がります。下＝シミュレーションでパラメータを振ってシナリオを大量生成し、失敗（赤）を探す網羅のグリッド。
N = ln(1−C) / ln(1−p) ≈ −ln(1−C) / p 故障率 p（≈1件/1.5億km）を信頼水準 C で棄却するのに必要な無事故走行距離。C=95% で約 4.5億 km（Kalra & Paddock, RAND 2016 の枠組み）
注意 — 「累計◯◯km 走破」は安全性の証明ではない 走行実績の大半は平穏な巡航であり、安全性を決めるのはまれな危険事象での挙動。距離の宣伝値と統計的な証拠力は別物だ。またシミュレーションも万能ではなく、シミュレータと現実の差（sim-to-real ギャップ）、そして「想定してモデル化した範囲しか検証できない」という本質的限界を持つ。実走行・シミュレーション・クローズドコース試験は互いの穴を塞ぐ補完関係として使う。

4. 冗長性 — 壊れることを前提に設計する

無人運転では「異常時は人間が引き継ぐ」が使えません。したがって単一の故障で危険な状態に陥らないこと（単一障害点の排除）が構成上の要件になります。センサ・計算機・電源・ブレーキを多重化し、故障を検知したら健全な系統へ切り替え、性能を落とした縮退運転で MRM を完遂できるだけの能力を残す — この「壊れ方の設計」がフェイルセーフ/フェイルオペレーショナル設計です。

冗長構成とフェイルセーフ — 壊してみて、止まれるかを見る
冗長構成では、どれか1つを壊すとバックアップ系が引き継ぎ、故障検知 → 切替 → 縮退運転（60 km/h 制限）→ 路肩停止（最小リスク状態）のシーケンスが走ります。「単一系統構成にする」を押してから同じ故障を注入すると、引き継ぐ相手がなく即座に制御喪失 — 「1つ壊れたら全滅」の危険な構成との違いを比べてください。

5. ミクロな安全の物差し — 衝突余裕時間 TTC

システム全体の話から一段降りて、瞬間ごとの危険度を測る代表的な指標がTTC（Time To Collision, 衝突余裕時間）です。前方の車との距離 d と相対速度（接近速度）Δv から、このまま何秒で衝突するかを見積もります。TTC はリスク評価・自動緊急ブレーキ（AEB）の発動判定・シナリオ評価の合否基準など、あらゆる場面の基礎になります。

TTC メーター — 距離と相対速度から余裕を読む
TTC が 4秒を切ると要注意、1.5秒を切ると危険域というのが典型的な目安。下段の必要減速度は「今ブレーキを踏んだら衝突回避に何 m/s² 必要か」— 乾燥路の物理限界（約 8 m/s²）を超えたら、制動だけでは回避できず操舵回避か衝突被害軽減の領域に入ります。
TTC = d / Δv,    areq = Δv² / 2d d = 車間距離、Δv = 接近速度。areq が路面摩擦の限界 μg（≈8 m/s²）を超えると制動のみでの回避は不可能

6. 制度の地図 — 機能安全と SOTIF

ここまでの工学的手段は、国際規格の体系に位置づけられています。混同しやすい2つの軸を押さえておきましょう: 「壊れたときの安全」と「壊れていなくても起きる危険」です。

一歩先へ — ISO 26262 と SOTIF（ISO 21448）の役割分担 ISO 26262（機能安全）は、電子系の故障に起因するリスクを扱う。ハザードの深刻度・曝露頻度・制御可能性から ASIL（A〜D）を割り付け、それに応じた冗長化・診断・開発プロセスを要求する — 第4節の冗長設計はこの世界の道具だ。一方 SOTIF（ISO 21448）は、故障がなくても生じる危険 — センサの性能限界、認識アルゴリズムの誤判断、想定外シナリオ — を扱う。学習ベースの認識・判断の弱点はまさにここで、「既知の安全/既知の危険/未知の危険」の領域を評価とシナリオ発見で狭めていくことを求める。さらにシナリオベース評価の方法論（ISO 34502）や、無人運転全体の安全論証をまとめる枠組み（UL 4600 など）が周囲を固める。2026年時点では、各国の認可制度（型式認証や州ごとの許認可）もこれらのセーフティケース提出を軸に運用されている。
POINT — 安全は機能ではなくプロセス 安全は「安全機能モジュール」を1個足せば得られる性質ではなく、ODD の定義 → 危険源分析 → 設計（冗長・縮退）→ 評価（統計＋シナリオ）→ 運用データからの学習 → 更新の再検証という終わらないループの性質だ。ソフトウェア更新のたびに論証を維持し続ける組織能力までを含めて、はじめて「安全なシステム」と呼べる。

7. まとめ