自律システムの未来を切り拓く：AI時代における安全性、倫理、そして説明責任
自動運転の認識スタック（perception stack）に取り組むエンジニアの集まりに、「トロッコ問題」についてどう思うかと尋ねれば、ほとんどの人はうんざりした表情を浮かべるでしょう。この問題自体は確かに重要なものです。しかし、彼らの目の前にある実際のエンジニアリング上の課題に対するモデルとしては間違っており、なぜそうなのかを説明するには、夕食会の会話で許容される時間よりもはるかに長い時間が必要だからです。
自律システムにおける安全性の課題を正直に述べれば、哲学的なドラマ性ははるかに低く、数学的な苦労がはるかに大きいものです。それは、センサーノイズ、オクルージョン（遮蔽）、レイテンシ（遅延）が存在する中での確率論的な認識であり、ループ内のどこにも明確な二者択一が存在しない連続的なアクション空間で報酬関数を最適化しなければならない意思決定パイプラインです。そのエンジニアリングの現実を正しく理解し、それに基づいた標準や説明責任の枠組みを構築することは、どんな思考実験よりも難しく、かつ重大な問題であり、それ相応の扱いを受けるべきです。
第1部：なぜトロッコ問題はエンジニアリングの仕様として不十分なのか
トロッコ問題は、現実の自律システムが持たないもの、すなわち決定論的な世界、完璧な状態知識、明確な二者択一、そして結果に対する確実性を前提としています。実際の自動運転車の認識スタックには、そのようなものは一切ありません。そこにあるのは、ノイズの多いLiDARの戻り値、雨や低い太陽角によって劣化したカメラ映像、駐車中のトラックの背後のオクルージョン、そして「真実」ではなく、実際に何が存在するかについての確率的な信念状態だけです。
実際に内部で動作しているもの
現実の自動運転車が「部分観測マルコフ決定過程（POMDP）」や「強化学習」といった形式的な枠組みに頼るのは、世界が本質的に部分的にしか観測できないからです。システムは、あらかじめ決められた2つの運命のどちらかを選択しているわけではありません。システムは、連続的なアクション空間全体をサンプリングし、数十通りの妥当な操舵角と加速の組み合わせを試し、歩行者や対向車、自転車が次の2秒間にどう動くかという不確実性の中で、衝突回避と注意義務の閾値に基づいた報酬関数に対して期待される結果を最適化しているのです。自動運転車をプログラムしてトロッコ形式のジレンマを「解決」させることは、実際のエンジニアリング作業の簡略版ではありません。それは、思考実験が想定する形では実際には発生しない、全く別の問題を解こうとしているに過ぎません。
モラルマシン実験と、なぜクラウドソーシングによる倫理が罠なのか
MITの「モラルマシン」実験は、仮想的な自動運転車の衝突シナリオに対して数百万件のクラウドソーシングによる回答を集めました。そこで浮き彫りになった文化的な差異（例えば、若者を助けるか高齢者を助けるかといった集団レベルの選好の違い）は、社会学的には非常に興味深いものです。しかし、そのデータを使って直接倫理モジュールを学習させようとする人にとっては、深刻な警告サインでもあります。
時間的プレッシャーの下での人間の道徳的推論は義務論に偏りますが、熟考する時間を与えられると、同じ人々が功利主義に偏ります。これは、安全性に直結する制御システムに組み込むべき安定した選好関数ではありません。さらに、よく知られた視点のバイアスがあります。自動運転車の乗客として自分を想像する人は何よりも乗客を守ることを望みますが、歩行者として自分を想像する人はその逆を望みます。そのようなクラウドソーシングによる直感でモデルを学習させても、倫理をコード化することにはなりません。それは、利己的で一貫性のないものを大規模にコード化しているだけであり、この領域における倫理を民主的なデータフィッティングの演習としてアプローチしてはならない理由はまさにそこにあります。倫理には、単に大衆の感情を平均化したものではない、憲法のような構造が必要です。
トップダウン、ボトムアップ、そして実際に導入されるハイブリッド
トップダウンのアルゴリズムによる成文化は、特定の倫理的コミットメントを決定論的なロジックに直接ハードコードします。例えば、差し迫った衝突を回避する場合を除き、交通法規を破ってはならないという厳格な義務論的ルールなどです。これは監査可能で予測可能ですが、ルール設計者が想定していなかったシナリオに対しては脆いという欠点があります。
ボトムアップの機械学習は、システムがトレーニングデータから行動規範を推論できるようにするもので、複雑な現実世界の変動をはるかにうまく処理できますが、その代償として解釈可能性が失われます。ブラックボックス化されたポリシーネットワークは、なぜ特定のケースで特定の軌道を選択したのかを事後に説明することが難しく、これは事故調査や規制上の説明責任において真の問題となります。
本格的な導入において実際に現れたパターンはハイブリッド型です。ボトムアップで学習されたポリシーが、連続的で複雑な認識および軌道最適化の問題を処理し、そのポリシーが報酬関数から見てどのような提案をしようとも、アーキテクチャ上違反を禁じられた厳格なトップダウンの制約の中で動作します。学習されたプランナーの下位に配置される、明示的なルールベースの安全フィルターとして実装されるこの境界レイヤーは、産業用設定において学習されたロボット操作ポリシーをハードコードされた関節制限や衝突回避インターロックが制約するのと機能的に似ています。学習はニュアンスを扱い、決定論的なレイヤーは譲れない境界を扱うのです。
安全性の重要性は製品設計そのものの本質に織り込まれており、その開発を規定する規制の枠組みの中に如実に表れています。
機能安全とSOTIF：2つの異なる故障カテゴリ
ISO 26262は、ハードウェアの故障や体系的なソフトウェアの欠陥によるリスクを管理する、確立された規律である「機能安全」を規定しています。その自動車安全度水準（ASIL）の枠組みは、設計と検証活動の厳格さを、特定の故障が引き起こす可能性のある危険の重大度と発生確率に合わせて調整するものであり、自動車電子機器のエンジニアの多くが、まさにこの理由でASIL分解戦略について議論を重ねてきました。
業界が直面しなければならなかった真に不快な事実は、自動運転車はすべてのコンポーネントが設計通りに機能していても衝突事故を起こし得るということです。カメラは完璧に鮮明な画像を捉えています。しかし、認識ネットワークは、大雨の中で奇妙な衣装を着た歩行者を正しく分類することに失敗します。なぜなら、その特定の組み合わせはトレーニングデータの分布範囲外にあるからです。何も故障していません。システムがその瞬間の複雑さに対して不十分だっただけであり、故障リスクを中心に構築されたISO 26262の枠組みには、その故障モードを表現する語彙がありません。
ISO 21448（SOTIF：意図した機能の安全性）は、コンポーネントの故障ではなく、性能の限界や予期せぬ動作条件から生じる危険性に焦点を当てることで、そのギャップを埋めるために存在します。SOTIFの4象限モデルは、問題にラベルを貼るだけでなく、エンジニアリングチームに実際のロードマップを与えるため、詳細に理解する価値があります。エリア1は「既知の安全」なターゲット状態です。エリア2は「既知の危険」であり、チームがすでに特定し、設計変更を通じて積極的に緩和しているリスクです。エリア3は「未知の危険」であり、チームがまだこれらのエッジケースを特定できていないため、真に危険なカテゴリです。エリア4は「未知の安全」です。
SOTIFエンジニアリング、広範なシミュレーション、統計的なフィールド検証、構造化されたエッジケース発見の究極の目的は、シナリオをエリア3からエリア2へ移行させることです。そうすれば、それらは見えないリスクではなく、対処可能な設計上の問題となります。ISO 26262とSOTIFを並行して運用し、どちらか一方で十分だと考えないことが、内部の故障リスクと外部の複雑性リスクの両方を同時にカバーする唯一の方法であり、どちらかを省略すれば安全性の議論に真の欠落が生じます。
協働ロボット：ISO 10218と2025年のTS 15066の統合
人間が常に究極のフェイルセーフであるという前提を取り払うという同じ根本的なシフトが、産業用ロボット工学でも起こりました。従来の産業用ロボットは、厳格なインターロックを備えた隔離された安全柵の中で動作していました。柵を開ければ即座に電源が切れます。協働ロボットの導入は、従来のワークスペースの構成を根本的に変え、人間とロボットの共存を必要としました。
ISO 10218-2の2025年改訂版では、ISO/TS 15066が正式に統合され、単一の協働ロボット規格となりました。コボットセルを設計する際には、定義された4つの協働動作モードを完全に理解しておく必要があります。「安全定格監視停止」は、人間が侵入するとロボットを完全に停止させ、ゾーンがクリアされた後にのみ再開します。効率的で安全なワークフローを確保するため、オペレーターはロボットアームの動きを積極的に管理し、所定の場所で速度を精密に制御します。システムは、人間との相対速度と近接度の動的な計算に基づいてリアルタイムでペースを最適化し、より安全な作業環境を確保します。出力と力の制限は、機械的な接触を制限するだけでなく、衝突が定義された安全限界を超えないように電子的に安全な接触力を強制します。
新しいインテグレーターが最もよく陥る落とし穴は、規格が「いかなるロボットも単体で本質的に『安全』または『協働的』ではない」と明記している点です。リスク評価を行い、完全なシステムとして検証しなければならないのは、アプリケーション全体、特定の先端エフェクター、ワークピースの形状、周囲の治具、そして実際のタスクです。PFL（出力・力制限）に完全に準拠したロボットアームであっても、鋭利なカスタムグリッパーを取り付けていれば、ベースのロボットが協働認証を受けているという理由だけで協働アプリケーションになるわけではありません。
IEEE P7000：社会技術的倫理が形式化される場所
安全性はISO規格を推進する主要な懸念事項であり、物理的および機能的な側面を優先します。IEEEグローバル・イニシアチブ・オン・エシックス・オブ・オートノマス・アンド・インテリジェント・システムズの下で立ち上げられたIEEE P7000シリーズは、ISOの枠組みでは決してカバーできない社会技術的および倫理的な側面に対処するものであり、曖昧な理想論ではなく、具体的で対処可能な標準としてそれを行います。
IEEE P7001は透明性をターゲットとしており、自律システムが自己評価を行い、事後に人間が実際に説明可能な形で意思決定経路を公開することを求めています。これは、純粋なブラックボックス型のボトムアップ学習が追加のアーキテクチャ作業なしでは提供に苦労する機能です。IEEE P7003はアルゴリズムのバイアスに直接対処し、導入前に学習済みモデルにおける差別的な結果を特定・防止するための構造化された枠組みを提供します。IEEE P7009はフェイルセーフ設計を対象とし、システムが正常な動作を継続できない場合に、突然または予測不可能な故障モードではなく、段階的で安全な縮退動作を義務付けています。IEEE P7010は、従来のエンジニアリング標準が踏み込む範囲をさらに超え、経済的またはタスク完了の狭い指標にとどまらず、AIシステムが人間の幸福に与える実際の影響を評価するウェルビーイング指標を導入しています。
第3部：実際に通用する安全ケースの構築
ISO 26262やSOTIFに対するコンプライアンスチェックリストは必要な基礎作業ですが、それ自体が特定のシステムを現実世界で導入しても安全であるという説得力のある議論を構成するわけではありません。その議論こそが「安全保証ケース（Safety Assurance Case）」が正式に構築するものであり、構造化された主張、論理的な議論の連鎖、そして具体的な検証可能な証拠（シミュレーションログ、トラックテスト結果、フィールドテレメトリ）によって裏付けられるものです。
UL 4600：規定型ではなく目標ベース
ANSI/UL 4600は、正確な実装要件を指示する従来の規定型標準とは意図的に異なるアプローチをとっています。これは目標ベースであり、エンジニアリングチームに対して、単に固定された実装ボックスにチェックを入れるのではなく、特定のリスクカテゴリに積極的に対処することを強制する、広範な必須および推奨のプロンプトを提供します。
UL 4600は、機械学習の本質的な脆さ、稀なエッジケースの長いテール、そして実際の動作条件下での人間と機械の相互作用という厄介な現実に直接立ち向かうことを強制します。厳格に定義された「運用設計ドメイン（ODD）」、つまりシステムが実際に動作を許可される明示的な環境的、地理的、時間的な範囲（「日中、晴天、時速45マイル以下の舗装道路」などが代表例）の要件は、この標準で最も運用上重要な要件です。車両がその範囲外の条件（突然の吹雪、地図にない工事現場など）に遭遇した場合、安全ケースは、システムがそのODD違反を確実に検出し、単に認識スタックがうまく処理してくれることを期待するのではなく、真に安全なフォールバック操作を実行できることを証明しなければなりません。
SACEとAMLAS：全体的かつ環境を意識した方法論
ヨーク大学のSACE（複雑な環境における自律システムの安全保証）方法論は、AMLAS（自律システムにおける機械学習の保証）と連携し、システム自体とそのシステムが存在する運用環境の両方にまたがる真に全体的な視点をとります。
SACEの「文脈外運用保証（Out of Context Operation Assurance）」コンポーネントは、UL 4600のODD概念が示唆しつつも完全には形式化していないものに対処します。現実世界は、定義された運用ドメインモデルが完全に捉えられるよりも無限に複雑であるため、システムは必然的に定義された境界の外へ迷い出ることになります。SACEは、2つの明確な能力を明示的に実証することを要求します。第一に、システムがODM境界に近づいている、あるいはすでに超えたことを正確かつ迅速に認識できること。その境界検出自体の偽陽性および偽陰性率が慎重に検証されている必要があります（絶えずオオカミ少年を叫ぶ境界検出器は、実際の境界越えを見逃すものと同じくらい危険だからです）。第二に、ODMの外に出た際に実行可能な「最小リスク戦略（Minimum Risk Strategy）」をシステムが持っていること。それが人間への制御権の返還であれ、制御された安全停止であれ、タスクの完了よりも自己保存に焦点を当てた意図的に保守的な縮退安全モードへの移行であれ、実行可能な戦略が必要です。
なぜシミュレーションが証拠の重みを担うのか
どんなに大規模なフリートであっても、道路テストだけであらゆる重要な危険なエッジケースに遭遇するほどの現実世界の走行距離を稼ぐことは物理的に不可能です。天候、照明、交通行動、稀なオブジェクトクラスの組み合わせは、合理的なプログラム期間内では統計的に絶望的です。道路ネットワーク記述のためのASAM OpenDRIVEや動的操作仕様のためのOpenSCENARIOのような標準化されたシミュレーションフレームワークにより、エンジニアリングチームは高度にパラメータ化された仮想環境を構築できます。そこでは、故障を意図的に注入し、天候や照明条件を体系的に変化させ、物理テストでは到底不可能なほど高速かつ網羅的に数百万通りのシナリオを試行できます。これが、SOTIFやUL 4600の安全議論が依拠する証拠基盤の大部分を生成し、ソフトウェアが物理ハードウェアに触れる前に検証を完了させるのです。
第4部：説明責任 — エンジニアリングと法律が交差する場所
自律システムが死亡事故を引き起こしたとき、即座に公衆が抱く本能的な疑問は、機械が道徳的な選択をしたかのように、「機械は何を『決定』したのか」というものです。そのフレーミングはカテゴリエラーであり、エンジニアやこの技術を取り巻く法的枠組みが、意図的にそれに抵抗することが重要です。
なぜ機械は道徳的または法的な主体性を持ち得ないのか
自律システムは、アーキテクチャの洗練度に関わらず、数学的な報酬関数を最適化するものです。法律や古典的な倫理が認めるいかなる意味においても、意図性、自由意志、真の道徳的理解を持っておらず、それに主体性を帰属させることは、責任が実際にどこにあるのかを明確にするのではなく、むしろ曖昧にしてしまいます。機械には法的人格や「犯意（mens rea）」の能力がないため、システム自体に刑事責任を問うことはできません。
その代わりに観察されているのは、「道徳的クランプルゾーン（衝撃吸収帯）」の形成です。例えば、自動化システムを監視する安全ドライバーなど、故障に最も近い位置にいる人間が、実際の因果関係への寄与に不釣り合いな法的・道徳的非難を一身に受ける一方で、実際に故障状態を生み出した体系的なエンジニアリングや組織的な決定は、同等の精査を免れるという現象です。その非対称性は、高度な技術を運用する上での許容可能な結果ではなく、真の説明責任の欠如です。
Uber ATGの事故をエンジニアリングと組織のケーススタディとして
2018年にアリゾナ州テンピで発生したUber ATGの死亡事故は、公的な議論において現実世界のトロッコ問題として誤って特徴付けられることがよくあります。実際の技術調査は、哲学的にははるかに興味が薄く、実用的にははるかに教訓的な物語を伝えています。それは、認識スタックの故障と、組織の安全文化の欠如が複合した事故でした。
自動運転システムによる、自転車を押して道路を横断する女性の分類は、オブジェクトがシーンを移動するにつれて「車両」「自転車」「その他」の間で繰り返し振動していました。再分類のたびにシステムはそのオブジェクトの軌道予測をリセットしており、そのリセットサイクルこそが、トロッコスタイルの意図的な選択ではなく、ブレーキ応答を遅らせ、手遅れになる原因でした。これは、マルチオブジェクト追跡および分類パイプラインにおいて非常によく理解されている故障モードであり、不安定なクラス予測が後続のモーション予測を破壊するものです。これは、より成熟したセンサーフュージョンアーキテクチャであれば、連続するフレーム間でのより強力な時間的一貫性の制約によって、公道導入前の検証テストで十分に捕捉できたはずの種類の問題です。
その技術的な失敗の上に直接積み重なっていたのは、別の、そしておそらくより非難されるべき組織的な失敗でした。Uberは、頻繁な誤警報による「アラーム疲労」を減らすために、安全ドライバーへの緊急警告通知を意図的に抑制しており、その安全ドライバーの役割に対する運用上の安全義務も、そもそも明確かつ厳格に定義されていませんでした。それらの組織的な決定のどちらも、認識スタック単体の技術的な根本原因分析には現れません。そして、まさにそれが重要な点です。完全な説明責任の枠組みは、衝突の瞬間に動作していたソフトウェアだけでなく、システムライフサイクル全体を検証しなければならないのです。
ライフサイクル全体を通じた役割責任の定義
有意義な説明責任は、システムの開発と運用のあらゆる段階を通じて明示的に追跡されなければなりません。トレーニングデータの収集とキュレーションを担当する組織とプロセス、ニューラルネットワークアーキテクチャを設計・検証したエンジニア、UL 4600の安全ケースをまとめ承認した安全エンジニア、商業的圧力の下で導入スケジュールとリスク許容度を設定した経営陣、そして現実世界の条件で日々システムを管理するフィールドオペレーターです。
そのライフサイクル全体を通じたトレーサビリティこそが、IEEE P7001のような、透明で再構築可能な意思決定経路を義務付ける標準が、純粋な技術的関心を超えて重要である理由です。そのような再構築可能な記録がなければ、事故後の調査は、実際の故障状態がどこで発生したのかというライフサイクル段階まで因果責任を正確に追跡できず、説明責任は、たまたま故障時に物理的に最も近くにいた個人に押し付けられることになります。しかし、そこは実際のエンジニアリング責任が存在した場所であることは稀なのです。
ここから先、実際に進むべき道
安全性に直結する自律システムを責任を持って導入することは、哲学的な思考実験をより巧妙に解決することで解決する問題ではありません。それは、ISO 26262に基づくコンポーネントレベルの機能安全分析、SOTIFに基づく環境および性能限界のカバー、統合されたISO 10218協働ロボットフレームワークに基づくアプリケーションレベルのリスク評価、IEEE P7000に基づく社会技術的な説明責任構造、そしてUL 4600やSACEのような枠組みに基づく構造化された証拠に裏打ちされた安全性の議論という、地味で厳格で、真に困難な作業を通じて解決されるものです。
これらの枠組みは個別に問題を解決するものではなく、だからこそ本格的なエンジニアリング組織は、単一の標準を十分なカバー範囲として扱うのではなく、それらを組み合わせて運用しているのです。Uber ATGの事例と、このレベルの厳格さで調査されたその後のすべての事故から得られる正直な教訓は同じです。これらのシステムが行うことに対する責任は、機械が刻々と決定を下しているからといって機械に移転するわけではありません。それは、認識パイプラインを設計し、運用境界を定義し、安全ケースを承認し、そのすべてのエンジニアリングが実際に行われた組織的優先順位を設定した人間に、真っ直ぐに残るのです。死亡事故の後にその欠如を発見するのではなく、最初からその責任をプロセスに組み込むエンジニアリングこそが、この分野がまだ直面している真の課題です。