完全自動運転とソフトウェアの課題
1月11日付の日経新聞の記事に『完全自動運転「業界全体で遅れ」』とある。2020年代初頭にも業界で実用化の動きが出始めるとされていた時期が遅れそうだとの見方が強くなっているようである。
はじめに
完全自動運転では自動車に搭載されたコンピューター・ソフトウェアが自動車と言うハードウェアの運転操作のすべてを制御する。そこで使用されるソフトウェアは極めて高度で複雑なものとなるが、その実現の難しさを関係者がようやく理解し始めた段階ではないだろうか。通常のアプリケーション・ソフトなら誰でも知っているが、システムを制御する（単なるモノの制御ではなく）ソフトウェア開発の難しさを知っている人は自動車業界にはまだそれほど多くはないのではないかと想像している。
実は自動車の完全自動運転のソフトとかなりよく似た要求条件を実現しようとしたソフトが過去にもあった。それは1980年代に米国のレーガン大統領が提唱し、紆余曲折の末実現できなかった戦略防衛構想（SDI）のソフトである。SDIのソフトウェアに比較すれば、自動車の完全自動運転は地上と言う平面上での制御に限定される点で、やや要求条件が緩いかも知れない。しかし、複雑なハードウェアで構成されたシステムをソフトウェアで制御するという本質ではそれほど違いはない。
SDIとは
戦略防衛構想（Strategic Defense Initiative, SDI）は別名スターウォーズ計画とも呼ばれ、アメリカ合衆国がかつて構想した軍事計画である。衛星軌道上にミサイル衛星やレーザー衛星、早期警戒衛星などを配備し、それらと地上の迎撃システムが連携して敵国の大陸間弾道弾を各飛翔段階で迎撃、撃墜できるシステムを構築することで、アメリカ合衆国本土への被害を最小限に留めることを目的としたものである。このシステムの実現には当時高性能化しつつあったコンピュータやその上で動作しシステムを制御するソフトウェアの能力に期待がかかっていた。
SDIには政治的、技術的に様々な問題が指摘されていたが、ソフトウェアに関してはデビッド・L・パーナス博士が反対の立場を表明し、核攻撃を防ぐと保証できるような十分な品質のアプリケーションを書くことは不可能であると主張した。
SDIのソフトウェアの実現の困難さに関しては、ディビッド・L・パーナス博士の論文、”SOFTWARE ASPECT OF STRATEGIC DEFENSE SYSTEMS” (注1) に詳しく述べられている。
タイトルからはSDIのソフトウエア限定の内容のように見えるが、この論文での議論の対象は「ハードウェアを含む大規模で複雑なシステムを制御するソフトウェア全般」であり、決してSDIだけを対象としている訳ではない。むしろ、5G、IoTの時代の組込みソフトの開発に携わる者が肝に銘じておくべき事柄のエッセンスが書かれている。また、別稿の「ソフトウェアを組み込むことによるシステムへの影響のアセスメント」に関する先駆的な試みともなっていると理解できる。
なお、パーナス博士は「オブジェクト指向の基礎となったモジュール設計の概念を生み出したソフトウェア工学の先駆者(wikipedia)」である。
パーナス博士の原論文は10ページに及ぶものだが、筆者の理解では、骨子は以下の目次に示すような点からなっている。なお、以下の内容は筆者の理解によるものである点は予めお断りしておく。筆者の理解に誤りがあればご指摘いただければ幸いである。
(注1) Software Aspects of Strategic Defense Systems. David Loger Pernas, Communications of ACM, Vol.28, No.28, pp.1326-1335, 1985
1. ソフトウェア技術と他の工学技術との差異－それによりソフトウェアには瑕疵は避けられないという事実
ソフトウェアにバグは避けられないという点はSDIに限ったことではない。この点に関するパーナス博士の主張を要約すると、
・一般の工業製品の場合
販売開始の前に十分にテストされ、製品設計が正しいこと、そしてそれが確実に機能することが保証できる状態で販売される。
・ソフトウェア製品の場合
出荷時に「バグ」が残存していて、後に機能が不完全であることが判明することはむしろ普通である。ソフトウェア製品にはしばしば特定の保証についての「否認」が付随している。このような但し書きが必要となるのは、プログラマーの質によるものと言うよりもソフトウェアの性質上避けられないものだと考える方が妥当である。
上の点はソフトウェアの開発関係者には半ば常識になっている反面、一般の人にも常識として通用するとは限らない。このことは、バグのある（かもしれない）ソフトウェアを出荷することの是非を判断するに際しての判断基準を決めるうえで、価値観(文化)の齟齬を引き起こすことにも通じる。
完全自動運転のソフトウェアでも、リリース時にバグが全くないことを保証することはおそらく難しいのではないかと思われる。問題は万が一バグが残っていたとしても、そのバグが人命にかかわる様な重大な事故を引き起こさないと確信が持てるようにする必要がある。そのためには何をすればよいか。これについてパーナス博士はさらに詳しい議論をしているが大変難しい課題である。
2. SDIソフトウェア自体が持つ、実現不可能な特性
ここではSDIに使用されるソフトウェアの特性について述べている。筆者には、以下の内容はSDIだけでなく「完全自動運転」についても概ね成立するのではないかと思えるが皆さんはどうだろうか。
SDIソフトウェアの特性として
(1) プログラムは予測できない事には対応できない
－SDIは予測できないことだらけである
(2) 「フェイルソフト」を実現するには条件が整っている必要がある
－過去に経験していないことに備えることは出来ない
(3) 利用開始前に十分なテストを行える環境を用意することは不可能である
－実戦と同じ条件でテストすることが不可能なシステムである
(4) 戦闘中にプログラムの修正をしている余裕はない
－SDIの戦闘時間(1時間以内）内にはプログラムを修正する余裕はない
(5) リアルタイム性への要求条件が事前に想定できない
－プログラムがリアルタイム性を実現できているのかを検証できない
(6) インタフェースの量が膨大で、しかもそれらは運用中に変更されうる
－フレキシブルに運用可能なプログラムは煩雑で保守が困難になる
などの項目を挙げている。
3. 十分な信頼性を持つソフトウェア開発は既存の開発技術では無理
これもSDIに限らず、ソフトウェア全般にいえることである。
パーナス博士は「一般的に教えられているプログラム設計方法は小さなプログラムを品質良く作ることは出来るが、大規模化し複雑化したプログラムでは間違いが作りこまれるのを防ぐことは出来ない」としている。
そして、それらの間違いは実際にテストされるまで分らないことが多々ある。間違いを修正すると新たな間違いを作りこむことも多い。大規模なリアルタイムプログラムを記述して理解することはプログラマーの知的能力を超えている。プログラム開発は「試行錯誤の連続」であり、「ソフトウェアがリリースされるのは、ソフトウェアが正しいことが分った時ではなく、新しいエラーを発見する速度が、管理者が許容できると考える速度まで低下したときである」と述べている点は今でもその通りだし、完全自動運転のプログラムなら事情が変わるとも思えない。
4. ソフトウェア工学の限界：SDIの構築には不十分な改善手法
これもSDIを「ソフトウェア」に置き換えても当てはまる。
パーナス博士によれば、構造化プログラミング、モジュール化、ハイレベル言語化など、ソフトウェアの品質向上策はたくさんあるが、やってみて分ったことは「言うは易く行うは難し」だということ。25年やってみて分ったことは、理論と実践のギャップは大きく、依然として大規模なプロジェクトには不十分であるとパーナス博士は主張する。さらに、今後20年経っても状況は変わらないだろうとも述べているが、実際に予言は的中しているように思われる。
筆者も構造化プログラミングの適用により生産性は向上しバグは減らせたものの、パフォーマンスの極端な低下を招いてリアルタイムシステムとしては使い物にならなくなってしまった例を知っている。
5. 人工知能(AI)はSDIに使用できるほど信頼できるものではない
AIに関しては、この論文が書かれた時代と現在とでコンピュータの処理能力や利用可能なメモリ容量には大きな差があるし、Deep Learningなどの技術は当時は無かったから、事情は変わっているかも知れない。
しかし、「AIによる学習の結果得られる規則は一貫性が無く、不完全で不正確だ」という指摘はある程度現在のAIにも当てはまる。またどうやって学習させるかも問題だし、学習の成果として得られた結果の妥当性について人間に分るように説明することの難しさを考慮すると、プログラムの妥当性の検証には難しい課題がありそうに感じる。
6. 自動プログラミングはSDIの開発には役に立たない
パーナス博士は自動プログラミングについては様々な側面からのべているが、要するに「プログラミングを高級言語化することを「自動化」と呼ぶのならばそれは可能だが、要件定義や仕様書の作成は自動化できない」ということのように理解できる。
また、SDIの基本的な問題として、「信頼できる仕様を作成するための情報が不足している」ことを挙げているが、自動運転の場合にはプログラムの仕様を設計するのに十分な情報が存在すると言えるのか？という点については、特にレベル5の完全自動運転の場合には仕様作成のための条件を収集している段階ではないだろうか。
7. プログラム検証はSDIを信頼できるものにはできない
パーナス博士はソフトウェアの信頼できるものにするには、プログラムの単体検証だけでは不十分だと述べている。つまり、「実用に供されるのと同じ条件で実機の上で動作させ、プログラムのすべてのルートを走らせて試験していないソフトウェアは信頼できない」と言っているのだと思う。
プログラムの単体検証では不十分な理由として、
(A) 一つ一つのプログラムが論理的に正しかったとしても、それでSDIソフトウェアとして正しいと言えるのか？」という点
(B) 大きく、複雑で作成者以外には分らないようなソフトは信頼できない傾向がある点
を挙げているが、これは一般論としてその通りだろう。
さらに、プログラムがロバストであるための条件として
(C) 機器の一部が破壊または無効化された状態でも機能する必要がある点
を挙げている。この(C)については、自動運転車に関しても、万が一の事故により車両の機能の一部が損傷を受けても、その時点での最善の動作をするように作りこむ必要がある、ということを意味する。
8. SDIは副次効果があるから補助金が正当化できるという議論はあたらない
この項目だけは当時の軍事技術の開発を巡る補助金交付の事情に関する話題のようなので、少なくとも日本での完全自動運転の開発には当てはまらないかもしれない。
9. まとめ
以上、筆者の理解している範囲で、パーナス博士の論文は概ねこのような論点について述べている。
これらの論点を見ていると、論文が書かれてからおよそ35年後の今日でもソフトウェアの開発技術を取り巻く状況はそれほど変化していないように思われる。論文中の「SDI」という用語を単に「ソフトウェア」と読み替えるだけで現在のソフトウェア開発、特に組み込みソフトウェア開発に通じることが多い。今から考えるとSDIのソフトウェアは実現に至らなかったものの黎明期の「大規模組込みソフト」だった訳である。
完全自動運転のソフトウェアは、インターフェースや要件定義に関する情報が与えられるものではなく、探して見つけ出さないと得られないという点で、SDIのソフトウェアに似ており、その開発の難しさは負けず劣らずのものだと思えてくる。
クルマを道に沿って走らせることはさほど難しいことではないだろう。しかし、完全自動運転では、人が飛び出してくるかもしれない、煽り運転を受けるかもしれない、自転車やバイクが割り込んでくるかもしれない、あげくの果ては反対車線でぶつかったクルマが空中から飛び込んでくるかもしれない、と言ったような状況でも正しい運転操作を求められる。そう考えると、公道を走るクルマの完全自動運転プログラムの開発は世の中の期待とは裏腹に、それほど簡単ではないことが理解できるだろう。