Contents
レベル３自動運転とは？
レベル3とは、一定の限定条件下でシステムがドライバーに代わって運転操作を行い、その間ドライバーは前方注視義務から解放される状態を指しますglobal.honda
reuters.com。Hondaは既に2021年に世界初のレベル3対応車「レジェンド（Honda SENSING Elite搭載車）」を発売しており、高速道路の渋滞時にシステムが運転を引き受ける「トラフィックジャムパイロット（Traffic Jam Pilot）」を実現しました。
また、メルセデスは、2025年初頭、自動運転レベル３のオプション機能である「Drive Pilot」の新たなバージョンをドイツにおいて発売すると発表。SクラスとEQSで選択できる現行バージョンは、高速道路の渋滞時に時速60km以下で利用することしかできませんでしたが、新バージョンでは、渋滞中と呼べるような状況でなくとも、前方に追随できる車両を認識できれば、右車線において時速95㎞までスピードを出すことが可能になります。
レベル3実現時には運転主体が人からクルマに変わり、ドライバーは映画鑑賞やリモート会議などのセカンダリタスクが可能になります。
ASIL対応とHARA（ハザード分析とリスクアセスメント）の概要
レベル3の自動運転システムでは、システム故障時にも安全を確保するために自動車機能安全規格ISO 26262が適用されます。この中で定められるASIL（Automotive Safety Integrity Level）は、故障が及ぼし得る危険度に応じた安全度水準です ( What Is ASIL-D? )。ASILはSeverity（重篤度）・Exposure（露出率）・Controllability（制御可能性）の3要素によるHARA（Hazard Analysis and Risk Assessment）によって決定されます。
例えば、メーターパネル上の車速表示が故障する程度であれば、運転者が容易に気付き対処できるため危険度は低く、ASILは不要（品質管理レベル=QM）から低レベルに分類されます。一方で、高速走行中にブレーキが故障すると運転制御が困難になり死亡事故につながる恐れが高いため、ASIL-D（最も厳格なレベル）に分類されます。同じブレーキ故障でも低速かつ交通量の少ない状況であれば危険度は下がり、ASILも低減され得ます。このようにHARAではシナリオごとに危険性を評価し、安全目標に対応するASILを定めます。レベル3では「ドライバーが即座に制御できない状況下で重大な危害を及ぼす故障」が想定されるため、多くの機能がASIL-D相当の対策を要します。
ASIL-D水準の安全を満たすには、単一点故障(Single Point Fault)で安全目標が損なわれない設計が必要です。具体的手法として冗長化やフェイルセーフ機構の導入があります。ASIL要求を満たすため、システム要件を独立した複数の要素に分解して二重化する「ASIL分解」を行い、それぞれを下位のASILで開発しつつ全体として目標ASILを達成することもあります。また、電子ハードウェアでは故障検知用の監視回路（ウォッチドッグや自己診断機能）やエラー検出（例: メモリのECC）を組み込み、万一の内部不良を検知したら安全状態へ移行する仕組みを持たせます (Automotive Functional Safety: The Evolution of Fail Safe to Fail Operational Architecture | NXP Semiconductors)。
レベル3システムでは、こうした安全機構に加えて物理的な二重化設計が採用されます。たとえばAptiv社は高度運転自動化向けに、計算ユニットが故障しても別の計算資源が車両を安全停止できるよう冗長コンピューティングを備え、通信ネットワークはデュアルリング構成で完全二重化、電源も2系統＋スマートヒューズでゾーンコントローラへ途絶なく供給するフェイルオペレーショナル設計を提案しています ( What Is ASIL-D? )。このように、ASIL-D対応として各構成要素に冗長性や監視機能を持たせ、安全目標を満たすアーキテクチャを構築します。
ちなみに，混同しがちな以下は区別しておきたいです．
- Fault（故障要因） は、システム内部に潜む「欠陥」や「異常状態」であり、これが原因となって将来的に問題が生じる可能性があります。
- Failure（故障） は、その欠陥（フォールト）の結果として、システムが設計通りに機能しなくなる「現象」や「障害」を指します。
例: あるセンサーに微小な誤差（fault）がある場合、通常は誤差補正機構などで対処できます。しかし、もしその誤差が大きくなったり、補正が間に合わずにシステム全体の位置推定に影響を及ぼすと、それが「failure」として現れ、システムが要求される精度を満たせなくなるということになります。
このように、「fault」 は「原因」や「内部の欠陥」であり、「failure」 はその結果として「現れる障害」や「機能不全」を指すと理解するとよいです。
メルセデス・ベンツのDRIVE PILOTにおける冗長設計（レベル3）
メルセデス・ベンツは自社のレベル3自動運転システム「DRIVE PILOT」（SクラスやEQSにオプション設定）において、フェイルオペレーショナルな冗長アーキテクチャを採用しています (Mercedes-Benz backs redundancy for safe conditionally automated driving | Mercedes-Benz Group > Innovations > Product innovation > Autonomous driving)。
安全性を最優先に、あらゆる状況でも制御を維持できるよう設計されており、主要な制御系を物理的・機能的に冗長化しています。特に以下の4つの要素について二重系としています:
- ブレーキ系統: ブレーキシステムには複数のホイールスピードセンサや油圧回路の冗長化など、どれか一つが故障しても減速機能を保てる設計となっています。
- ステアリング系統: 電動パワーステアリングは冗長なモーター／回路を備え、一次系統に不具合が生じても車線内の進行を維持できるようになっています。
- 電源系統: 自動運転用に独立した予備バッテリーと電源回路を搭載し、メイン電源喪失時にもシステムを動作継続できます。これは共通原因故障（例: 電源喪失）への備えでもあります。
- センサー/環境認識: センサーは種類の異なるものを複数搭載して機能的冗長性を確保しています。具体的にはカメラ、ミリ波レーダー、LiDARを組み合わせ、それぞれの物理特性の違いによって他センサーの弱点を補完し合う設計です。加えて超音波センサーや路面の水分センサー、マイクなど計30個以上のセンサーで360度環境認識を行います。一種類のセンサーに頼らず多様な検知手段で相互に裏付けをとることで、あらゆる状況下で安全に動作できる信頼性を実現しています。
さらに、メインの車載コンピュータ（運転判断アルゴリズム）自体も二重化されており、データ計算に用いるアルゴリズムを複製して実行しています。これにより一次系の計算ユニットに故障が生じてもバックアップが処理を引き継げるようにしています。実際にDRIVE PILOT作動中に主要システムの一つが故障した場合、システムは即座に状況を検知しドライバーへの制御権返還（テイクオーバー要求）を安全に行います。仮にドライバーが応答できない場合でも、自動で車両を減速して安全に路肩停止する緊急停止操作（最小リスク挙動）に移行し、後続車への危険を及ぼさないよう配慮されています。このようにメルセデスは冗長設計とフェイルセーフ動作を組み合わせ、レベル3自動運転時の安全性を担保しています。
ホンダのトラフィックジャムパイロットTraffic Jam Pilotにおける冗長設計（レベル3）
ホンダは日本国内向けに、世界初の市販レベル3自動運転車として「Honda SENSING Elite」を搭載したレジェンド（ハイブリッドEX）を限定リース販売しました (Honda Launches Sensing Elite Safety System With Level 3 Autonomous Driving | Motoroids)。
その中核機能である「トラフィックジャムパイロット（渋滞運転機能）」は高速道路渋滞時（低速域）にドライバーに代わって車両制御を行うレベル3システムです (Honda SENSING Elite 搭載 新型「LEGEND」を発売 | Honda 企業情報サイト)。開発にあたっては安全性・信頼性を最重視し、約1000万通りのシミュレーションと130万kmの実証走行テストによって実世界のシナリオを検証しています (Honda Launches Sensing Elite Safety System With Level 3 Autonomous Driving | Motoroids)。その上で、「万が一いずれかのデバイスに不具合が生じた場合にも安全性と信頼性を確保できるよう冗長設計を取り入れた」と発表されています。
具体的なホンダの冗長アーキテクチャについて、公表情報から読み取れるポイントをまとめます。まず外界認識センサーには非常に多くの種類・数が搭載されています。ホンダの自動運転システム開発に貢献したValeo社によれば、レジェンドの周囲監視には5個のLiDARセンサーと2つのフロントカメラが用いられており、高性能なデータフュージョンECU上でそれらの情報を統合して車両周辺360度の詳細な環境モデルを生成しています (Valeo receives Honda Supplier Award in the Development Category)。加えて周囲の物体検知や自己位置特定にはミリ波レーダーや超音波センサー、GPSや高精度3D地図（HDマップ）も活用し、車両の挙動制御に必要なデータを重層的に取得しています。これら複数種のセンサーを組み合わせることで、あるセンサーが捉え損ねた情報も別のセンサーで補完でき、センサー単体の誤検知・未検知によるリスクを低減しています。実際Valeo社は、提供した統合システムが自己診断やフェイルセーフ動作などの安全関連機能を備えていると述べており (Valeo receives Honda Supplier Award in the Development Category)、センサーやソフトウェアの異常を検知した際にはシステムが安全側に動作する仕組みが組み込まれていることが伺えます。
アクチュエータ側の冗長性について詳細な公表はありませんが、ブレーキについては本来2系統の油圧回路を持つブレーキシステムを採用し一方の系統に障害が起きても減速力を確保できるようにする、ステアリングについては電動パワステの冗長モーターや万一の電源断に備えた非常用電源を備える、といった対策が考えられます（一般論としてメーカ各社が採用する手法です）。ホンダSENSING Eliteでも、システムが故障検知した際にはドライバーへの引継ぎ要求を行い、応答が無ければ車両を減速停止させるという最低限の安全動作は確実に行えるよう設計されていると考えられます。実際、ホンダは「誰もが事故に遭わない社会」を目標に掲げており、レベル3であってもシステム単独で安全を担保できるフェイルセーフ策を織り込んでいると言えるでしょう。
なお，2025年CESでも公開された，新型EVのSALOONにも自動運転Lv3の機能が段階的に搭載されることが述べられています．https://global.honda/jp/news/2025/c250108a.html
Honda 0シリーズでは、まず高速道路での渋滞時アイズオフから自動運転技術を搭載し、OTAによる機能アップデートを通じて、運転支援・自動運転レベル3適用の範囲を拡大していきます。自動運転レベル3では、運転主体が人からクルマへと変わり、映画鑑賞やリモート会議など、これまでにはできなかった「ドライバーによる移動中のセカンドタスク」が可能となります。Hondaは、この技術を進化させることで、世界に先駆けて全域アイズオフを実現し、移動の新たな可能性を切り開きます。
テスラの自動運転システムはレベル3に該当するか？
「自動運転」と聞くと、Teslaを思い浮かべる人が多いのではないでしょうか。私の場合は、ついこの間小惑星に間違えられたこいつの印象がやはり強烈ですが笑
SAEの自動運転レベル3は「特定条件下でシステムが運転を全て担い、ドライバーは監視不要だが、要求があれば適切に引き継ぐ必要がある」段階です。一方、Teslaの現行AutopilotおよびFSD（Full Self-Driving）ベータは、この条件を満たさずSAEレベル2（部分的運転自動化）に留まります。テスラ自身も公式サポート情報で「AutopilotやFSD（監督付き）は常に運転者の全面的な注意を必要とし、現在の機能は車両を自律走行させるものではない」と明言しています
tesla.com。また2021年、カリフォルニア州DMVへの書簡でテスラ法務顧問はFSDベータ（市街地走行機能）について「SAEレベル2の能力にしっかりと留まっており、DMVの定義する自動運転には該当しない」と述べています
thedrive.com。これは、FSDベータが悪天候・複雑な交通状況・工事区域・緊急車両対応など人間の監視なしでは対処困難なケースが多々あるためで、真のレベル3やそれ以上に求められる自律性を備えていないことを示しています。
要するに、テスラのFSD/Autopilotは現状では運転補助（レベル2相当）であり、ドライバーが常時監視・即応する前提となっています
en.wikipedia.org。レベル3のように「一定条件下でシステムに運転責任を任せ、ドライバーが脇見や他の作業をできる」段階には達しておらず、テスラ自身も現行システムを法的には「運転者監視下のADAS」として扱っています。実際、米加州DMVや専門家もTesla FSDをレベル2と見なしており
、レベル3としての公的認可や機能保証は現時点で取得されていません。
この意味で、実は、Teslaの自動運転レベルはSAEの基準でいうと低いものです。ただ現状の自動運転Lv3の機能が本当にユーザーの価値につながるか、は疑問が残ります。その意味では、Lv2であってもTeslaのFSDに、価値を感じるユーザーが多いことは、製品をつくる立場にある人間が忘れてはいけない視点だと、実務の中で学びました。
ともすれば技術的に難しいことを実現するのが目的になってしまう。「何のために作るのか」常に意識したいことです。
一般的なFail-operational・Fail-safe・Fault-tolerant設計の手法
高度な自動運転システムの安全設計では、フェイルオペレーショナル (fail-operational)、フェイルセーフ (fail-safe)、フォールトトレラント (fault-tolerant)といったコンセプトが重要です。これらは故障時にシステムがどう振る舞うかの設計哲学を表します。
- フェイルセーフ (fail-safe): システムに異常が生じた際、即座に安全な状態に移行する設計です (Functional Safety Assessment of an Automated Lane Centering System) (Automotive Functional Safety: The Evolution of Fail Safe to Fail Operational Architecture | NXP Semiconductors)。例えば故障を検知したらその機能を停止し、車両であればドライバーに制御を返す、機械であればブレーキを作動させて安全に停止するといった挙動です。重要なのは安全な状態 (safe state)を事前に定義しておき、故障時にシステムが暴走せずその状態で止まることです。自動車では従来、レベル2までのADASではフェイルセーフ設計が一般的でした。ドライバーが常時監視している前提のため、システムが故障したら警告してオフにし、人間にゆだねれば安全は保てるからです。一方レベル3以上では人間の即時介入が期待できないため、フェイルセーフだけでは不十分になります。
- フェイルオペレーショナル (fail-operational): システムの一部に故障が発生しても機能を停止させずに動作を継続できる設計を指します。つまり最初の故障ではバックアップ系が直ちに代替動作し、ユーザに危険を感じさせずに制御を維持します。二重化されたどちらの系統も普段は正常時冗長を提供し、片方が故障してももう一方で「劣化運転 (degraded mode)」を続行できるのがポイントです (Functional Safety Assessment of an Automated Lane Centering System)。フェイルオペレーショナルを実現するには、独立した二系統以上の制御ユニット（故障時は自ら出力を遮断するフェイルサイレント特性を持つもの）を用意し、電源もそれぞれ別系統で供給するなど一箇所の不具合が全てを巻き込まない工夫が必要です (Automotive Functional Safety: The Evolution of Fail Safe to Fail Operational Architecture | NXP Semiconductors) (Automotive Functional Safety: The Evolution of Fail Safe to Fail Operational Architecture | NXP Semiconductors)。メルセデスの例にあったように、専用の予備バッテリーまで搭載するのは電源系の共通故障に備えるためです (Mercedes-Benz backs redundancy for safe conditionally automated driving | Mercedes-Benz Group > Innovations > Product innovation > Autonomous driving)。航空機などではエンジンが片方止まってももう一基で飛行を継続できる設計（エンジン冗長）がフェイルオペレーショナルの典型例です。自動運転車でも同様に、例えば主要センサーの1つやECUが故障しても数秒〜数分間は安全に走行を継続し、しかる後に安全停止やドライバー引継ぎを行うことが求められます (Automotive Functional Safety: The Evolution of Fail Safe to Fail Operational Architecture | NXP Semiconductors)。
- フォールトトレラント (fault-tolerant): 直訳すれば「障害許容」であり、広義にはシステムが一定の故障に耐えて機能を維持できることを指します。フェイルオペレーショナルもフォールトトレラント設計の一種ですが、フォールトトレラントはより一般的な概念で、故障検知・切り離し、冗長系への切替、自律的な復旧などを包括します (Three Things to Know About Functional Safety – NXP Semiconductors) (What is the difference between fail-safe and fail-soft?)。たとえばN冗長（N-modular redundancy）による多数決合議や、異なるアルゴリズム/コンポーネントで同一機能を実現して比較する多様化冗長 (diverse redundancy)などもフォールトトレラントの手法です。自動車では、デュアルECUのクロスモニタリング、デュアルセンサーの相互チェック、通信バスの二重経路化（デュアルCAN/Ethernet）等が一般的な実装例です。またフェイルソフト (fail-soft)とも呼ばれるフェイルディグレード (fail-degraded)動作では、故障時に機能は落としつつも安全を保った最低限の動作を続けます。例えばパワーステアリングが故障したらアシストを切って人力操舵に戻す、センサー異常時には自動運転を解除して減速走行に切り替える、といった具合です。重要なのは、いずれの場合も安全ゴールを達成すること（乗員や周囲に危害を及ぼさないこと）であり、そのために必要な冗長化・監視・フェイルセーフ措置を適切に組み合わせることがシステム設計上の工夫となります (Functional Safety Assessment of an Automated Lane Centering System) (Functional Safety Assessment of an Automated Lane Centering System)。
自動運転における認識AIの安全性確保策
レベル3自動運転ではAI技術（画像認識のディープラーニングなど）を用いた環境認識が不可欠ですが、その信頼性・安全性をどう確保するかも大きな課題です。AIは従来の明確な論理式とは異なりデータ駆動で挙動が決まるため、従来手法だけでは安全を完全に証明しにくい側面があります。このため、自動運転AIの安全性については新たな規格や多層的な安全策が提唱されています。以下では主な規格・基準, フェイルセーフ機構, 不確実性への対処法について述べます。
認識AIの安全性を保証する規格・基準
まずハード・ソフトの機能安全規格ISO 26262がありますが、これは主に決定論的なシステム上の故障対策を扱っており、AIのような機能上の不足（Perception Performance Limitations）には直接対応しません。そこで近年注目されているのがISO/PAS 21448「安全な機能の意図（Safety of The Intended Functionality, SOTIF）」です。SOTIFは「システムが意図した機能を様々な条件下で安全に遂行できること」、言い換えれば機能不全や誤使用によるリスクが許容できないレベルにないことを確認するための指針です (AI Safety Protocols: Ensuring Safety in Road Vehicles – MulticoreWare)。これはセンサーやAIが未知の状況で誤認識・未検知を起こしうるリスク（機能上の不足に起因するハザード）を体系的に洗い出し、テストや論証によって「合理的に安全である」ことを証明する枠組みを提供します。実際、SOTIFではセンサーの検知性能やAIアルゴリズムの限界に起因するシナリオを分析し、不確実な要素への対策を要求しています。
さらに、完全自動運転に向けた安全認証のための指針としてUL 4600や、各国業界団体によるガイドライン（例：「Safety First for Automated Driving」ホワイトペーパー (Safety First for Automated Driving)）なども活用されています。UL 4600は自動運転システム全体の安全性を検証する標準で、AIに関する検証項目も含む包括的な安全ケース構築を求めるものです。また、ISO規格としては今後ISO 8800シリーズ（AIの安全性に関する指針）の策定も進められています (AI Safety Protocols: Ensuring Safety in Road Vehicles – MulticoreWare)。ISO 8800ではデータやモデル、学習・検証手法などAI開発プロセス全般にわたる適切な安全保証の手順を示し、機能安全やSOTIFではカバーしきれないAI固有の不確実性に対処することが目的とされています。このように、従来の機能安全（FuSa）に加えてSOTIFやAI安全規格を組み合わせることで、認識AIの安全性を体系立てて保証しようとする動きがあります。
AIのフェイルセーフ機構やリスク低減手法
AIを用いた認識システムにおいても、故障や誤検知時のフェイルセーフ措置が重要です。まずシステム監視と異常検知が一つの柱です。AIの出力を監視して明らかに不合理な挙動を検知するモニタ（オブザーバ）を並行動作させ、異常時に警告・介入する仕組みが考えられます (Safety First for Automated Driving) (Safety First for Automated Driving)。例えば物体検知AIであれば、検出した物体の位置やサイズ、動きが物理的にあり得ないもの（急に巨大化する等）でないか現実性チェック（plausibility check）を行う、あるいはセンサー入力そのものが学習時の分布から大きく逸脱していないかを検査する手法があります。こうした観察により「AIが信用できない状態」をいち早く察知し、上位システムに安全措置を取らせます。実際メルセデスらが提唱する安全原則では、異常なニューラルネット挙動や未知の入力を検出する異常検知機構や、AIの出力が安全域から外れた際に動作を抑制する**安全エンベロープ（doer-checkerアーキテクチャ）**の導入が推奨されています (Safety First for Automated Driving)。例えばAIの制御提案に対し、並行する簡易なルールベースチェック（checker）が「それは安全か？」を監視し、危険と判断すれば自動運転を即座に最小リスク動作に切り替えるといった仕組みです (Safety First for Automated Driving) (Safety First for Automated Driving)。
またフェイルセーフ動作の設計も欠かせません。AIが誤認識で障害物を見落とした場合でも車両が衝突しないよう、多重の防護策を用意します。例として、AIの眼前障害物検知に自信が持てないときはより保守的な制御（減速・停止など）を行う、AIが検知しなくともレーダなど他センサーが反応した物体はとりあえず障害物とみなして警報・ブレーキをかける、といった対処があります。ホンダのシステムにも、自動運転ECUが異常を起こした際に作動する緊急ブレーキ機能やバックアップの制御ロジックが備わっていた可能性が高いと言えます (Valeo receives Honda Supplier Award in the Development Category)。さらに運用設計範囲（ODD）の制限もリスク低減に有効な手段です。AIが対処困難な状況（悪天候や複雑な市街地など）ではシステムを稼働させないようにし、想定外のケースに遭遇しにくくすることで安全を担保します。実際ホンダのレベル3は渋滞時の高速道路に限定しており、それ以外ではドライバーが制御するようになっています。このように検知異常の早期検知と安全側への動的切替、およびドメイン制限によって、AI起因のリスクを最小限に抑える設計が求められます。
AIの不確実性に対処するためのアプローチ
AIの出力にはどうしても不確実性（確率的なゆらぎや未知の入力によるエラー）が付きまといます。そこで近年、不確実性を定量的に見積もり安全判断に組み込む研究も進んでいます (Safety First for Automated Driving)。一つの方法は複数モデルのアンサンブルです。同じタスクに対し異なるディープラーニングモデルを独立に学習させて用意し、推論段階でそれら複数のモデルの出力結果を相互に比較・照合します。もし大半のモデルが同じ認識結果を出力していれば信頼度が高いとみなし、モデルごとの答えがばらつく場合には不確実性が高いと判断して慎重な行動をとる、といった使い方です。実際、安全設計ガイドでは多数のDNNからアンサンブル推論して結果を多数決や加重統合することで精度・信頼性を高める手法が提案されています。さらにアンサンブルだけでなく、「DNN＋簡易なルールベース」で二重チェックする多様な冗長も有効とされています。例えば物体検知をDNNに任せつつも、車線維持だけは従来型の白線検出アルゴリズムでも並行して行い結果を相互チェックする、といったアプローチです。これにより、学習ベースのAIが見落とすケースでも従来アルゴリズム側で検出できる可能性があり、安全側への補強となります。
センサーフュージョンもAI不確実性対処の重要な手段です。上記メルセデスやホンダの事例にあるように、カメラ・レーダー・LiDARなど異種センサーを組み合わせて環境認識することで、個々のセンサーの弱点を相互に補います (Mercedes-Benz backs redundancy for safe conditionally automated driving | Mercedes-Benz Group > Innovations > Product innovation > Autonomous driving)。カメラは物体分類に優れるが暗所や逆光に弱い、レーダーは距離測定に優れるが形状識別は苦手、LiDARは高精度な形状・距離データを得られるが悪天候に弱くコストも高い、といった長短があります。そこで複数種のセンサー情報をフュージョン（融合）し一貫性をチェックすることで、信頼性の高い認識結果を得ます。例えばカメラが「人」を検知したらレーダーでも対応する反射物があるか確認し、食い違いがあれば不確実と判断して減速するといった対応が可能です。実際メルセデスは「単一のセンサータイプに頼ることは高い安全基準を満たせない。我々は異なる物理原理のセンサーで互いに裏付けを取り、状況依存の欠点を補償している」と述べています。この思想がセンサーフュージョンの狙いであり、不確実性低減とフォールトトレラント性向上につながります。加えて、センサーやAIモデル間のクロスモニタリング（お互いの出力を監視し矛盾を検出）も行われます。それにより単一の誤検知がシステム全体の誤動作に直結しないようにします。
最後に、AIの不確実性対策としては広範なシナリオテストと継続的学習も重要です。未知のケースでの誤動作を減らすには、学習および検証段階でできるだけ多様な状況を経験させる必要があります。ホンダがシミュレーション1000万通り・実走行130万kmものテストを行ったのも、この網羅テストによりAIの挙動の裾野を広げ、安全でない挙動を徹底的に洗い出すためです (Honda Launches Sensing Elite Safety System With Level 3 Autonomous Driving | Motoroids)。その上で、見つかった課題に対して学習データを追加したりアルゴリズムを改良したりする改良プロセスを繰り返すことで、AIの不確実性由来のリスクを徐々に低減させていきます。今後も安全な自動運転の実現には、AIの不確実性を受け入れつつ多重のセーフティネットを用意する「防御的な設計」が不可欠と言えるでしょう。
まとめ
メルセデス・ベンツとホンダのレベル3自動運転車に見るように、フェイルオペレーショナルな冗長アーキテクチャは高度運転自動化の安全実現において不可欠です。ASIL-Dと評価されるような重大なハザードに対処するため、システムはHARAに基づき冗長化・監視・フォールトトレラント設計が組み込まれています。ブレーキ・ステアリング・電源・センサーといった要素の二重化やバックアップにより、単一故障ではシステムが破綻せず安全な動作継続や最低限の安全停止が可能です。さらに、認識AIについてもSOTIF等の基準を適用し、不確実性に対処する工夫（複数モデルの活用、センサーフュージョン、異常検知モニター、安全限界の監視など）によってリスクを低減しています。一般的な安全設計原則とAI特有の対策を組み合わせることで、自動運転システムはfail-operationalかつfail-safeな振る舞いを実現し、故障や不確実性下でも人命を守る包括的な安全性を追求しています。各メーカーはこの多層防御アプローチで安全性を担保しつつ、自動運転の実用化に取り組んでいるのです。
コメント