製品進化とマネジメント風景 第106話 AIによる品質保証のマネジメント
AIは情報を扱う製品であり、文字や数字を扱う情報産業との相性は良いと言えます。例えば、雑誌、書籍、広告といった読み物への適用であれば、仮に間違いがあったとしても、その影響を受けるのは限定的です。最近、GoogleのAIでも歴史上の人物の表記を間違えるというインシデンスがありました。これらは当事者たちの間では大変な騒ぎに発展するでしょう。しかし、それが直接の怪我の要因になることはありません。（もちろん、精神的な影響は生じる可能性はあります）
同じ文字でも金融や保険になると、間違いが起きた時の影響はもう少し深刻になります。金銭に直接影響するため、実際には限定的な影響しか生じない問題であっても、憶測が憶測を呼び、米国の西海岸で起こったように、銀行の１つを潰すくらいまで波及します。とはいえ、金融システム全体がしっかりしてさえいれば、一部に限定した被害で収まります。
電力、ガスなどのエネルギーインフラへのAI適用も進みつつありますが、ここでミスが発生した場合には、広い範囲で停電やガス供給停止が起こりえます。その被害は広範にわたり、経済的な損害もかなり大きくなります。ただ、人命にはそれほど影響しないでしょう。病院が停電すると大変なことになるのですが、最近の病院では非常用発電装置を装備している所が増えているからです。
医療行為そのものにもAIの適用が進みつつあり、ここでのミスは致命的になる場合があります。また、交通や輸送分野へのAI適用も進行中ですが、ここでもミスが人命に直結します。人命に直結する分野におけるAI適用は、やはり慎重に行わなければなりません。
すでに自動運転車の分野では人命が失われる事故が起きています。その中でもテスラ社とUber社の２社の事故は大きく報道されました。不完全な自動運転は致命的であることを証明したと言ってよいでしょう。
テスラ車の事故は自動運転レベル２で起こったため、運転責任は人間にありました。米国の社会ではテスラ社に対して様々な批判の声が向けられていますが、テスラ社は司法的な責任を問われていません。Uberの人身事故は、自動運転レベル３の実証試験中に起きました。これも、ドライバーが最低限必要な監視をしてさえいれば避けられたものだったので、Ｕｂｅｒではなくドライバーの責任となりました。
日本ではすでにレベル４が解禁されました。レベル４は本格的な自動運転であり、AIに起因した人身事故が起きれば、それはAIを開発した企業の責任になると推定されます。
「AIは一種のソフトウェアなのだから、従来のソフトウェアの品質保証に則って進めれば品質問題は解決できるのではないか？」という意見が出てくるかもしれません。しかし、機械学習を基礎におくAIは、従来のソフトウェアとその成り立ちが根本的に異なり、従来の品質保証の考え方をそのまま使うことは出来ないと言われています。そこで、次はその真偽を検討していきます。
品質保証という面において、従来ソフトウェアとAI、特に深層学習を用いたAIとの違いをひと言で述べるならば、前者は演繹型の開発法を取るのに対し、後者は帰納型の開発法を取ります。
わかりにくいと思うので補足します。演繹型の従来ソフトウェアでは、どういう機能を組み込み、何をどう判定し、その結果に基づいてどう動作するかがプログラムの中に明示的に記載されていました。ですから、その明示された動きを正しく再現するかどうかを試験で実証すればよかったわけです。
これに対して、帰納型のAIはデータから学習し、自ら判定基準を設定します。深層学習を用いた場合にはブラックボックスになるため、現状、人間が意図したとおりに作動するかどうかを明示的に判定できません。
製品は通常、顧客要求をフローダウンして製品仕様を設定し、それに基づいて製品を構成するここのサブシステムやモジュールを分業して作り上げ、その後、統合して最終的な製品システムの形にします。
演繹型の製品では製品仕様が明確であり、これにそって設計作業を進めることができます。また、判定基準も人間が明示的に入力することができます。これに対して帰納型の製品では、製品仕様がなく、しかもブラックボックスであるＡＩが判定基準を設定しますが、人間はこれを直接的に認識できません。
ＡＩはモノの検査など、品質を保証するプロセスへの適用が検討されていますが、上記の問題があるため、その適用に難しさがあります。AIがいくら大量のデータで学習し、ぱっと見た感じでは人間よりも優れた判定をしたとしても、それを鵜呑みにし、品質を保証するというクリティカルなプロセスに適用して良いのか否か、非常に悩むわけです。特に、品質保証が人命に影響を与える場合や、極めて大規模な経済損失につながる場合には慎重にならざるを得ないでしょう。
とは言え、AIの製品適用はどんどん進みつつあるので立ち止まっているわけにも行かず、様々なルールづくりが進行中です。日本ではQA4AIという官民共同の活動が行われています。この取り組みの中では品質特性として５つの軸をあげています。
５つの軸は、Data Integration（学習データの質量の妥当性）、学習済のAIモデルの精度と頑健さ、システム品質（AIがシステムに及ぼす影響）、プロセス機動性（フィードバックの迅速性）および顧客期待です。 しかし、正直に言うと、これらは品質保証として本当に機能する軸なのか、よく分からないとしか言わざるをえません。２つほど例をあげながらその理由を説明します。
プロセス機動性は、従来的な文脈ではPDCAを迅速に回すことを意味するのでしょうが、AIは帰納型ゆえにPDCAを明示的に回せない可能性が大です。なぜなら、同じ学習データを使っても、学習のたびに以前と異なるAIモデルになってしまうからです。バラツキが大きいということです。ですから、新しいデータを追加して学習したとしても、必ず以前から改良されたとは単純に言い切れないのです。
顧客期待という表現も理解に苦しみます。従来で考えると「顧客要求」となる所をあえて「期待」と変えています。「期待」なので満足しなくても顧客に許してもらえると言うつもりなのかもしれませんが、それではそもそも品質保証とは言えないでしょう。
このように品質保証の５つの軸についてはあまり賛同できないのですが、これとは別に「ドメイン化」という考え方が提案されています。これは対象とする用途ごとに、品質保証の内容を変えて設定しようという考え方です。
現状、自動運転、産業用プロセス、音声インターフェース、画像や動画などのコンテンツ生成、およびOCRの５つが対象のドメインです。自動運転のように人身事故が起こりうるものと、画像や動画などのコンテンツ生成では社会的な文脈が大きく異なるので、それぞれに応じた品質保証をするという考え方は妥当だと考えます。
このようにルールが定まらない状態にありますが、ＡＩの自動運転車への適用はどんどん進みつつあります。ここで自動運転におけるレベルの定義について復習しておきます。
レベル１は運転支援であり、ドライバーに責任があります。レベル２は部分運転自動化であり、やはりドライバーに責任があります。 レベル３は条件付き運転自動化です。高速道路などの渋滞（60km/h以下）時などに適用することができます。レベル３では、緊急時にはドライバーに責任が移るため、ドライバーはあまり気が抜けません。中途半端で扱いにくいかもしれません。Uberの人身事故も、ドライバーが安心して気を抜いているときに起こりました。
レベル４は高度運転自動化であり、限定領域内、つまり、あらかじめ定められたルートについて自動運転が認められます。バス、運送トラックなどの商用運送事業に適用可能です。最後のレベル５は完全運転自動化であり、条件はありません。
メーカはレベル５の自動化に向けて努力しているのですが、当然、AIの品質保証問題にぶちあたります。従来の演繹型ソフトウェア品質では、機能安全のためのISO26262が適用されていました。しかし、ここでは故障リスクしか扱っておらず、AIが起こしえる、故障以外の誤認などを扱うことができません。
そこで、ISO26262を補完するためにISO21448、通称SOTIFという規格が作られました。SOTIFでは故障以外でも起こりうるリスクを扱います。自身の性能限界も扱うし、外部環境に起因する事故リスクも扱うわけです。
これを読んでいて、「これって、結局の所、航空機の品質保証と同じだな」ということに気づきました。航空機では、半世紀以上、これと同じアプローチで対応してきました。顧客要求、あるいは製品要求の段階でHazard(深刻な危険）の状態を想定し、製品がそれを回避あるいは許容できるレベルまで低減することを目指して開発をするのです。Hazardは製品の故障だけでなく、自然という外部要因（乱気流、雷、鳥吸い込み、氷の吸い込み等）も含めて設定します。
航空機の考え方を適用すれば、AIの品質保証はできるように思われます。その理由を以下に示しましょう。
製品開発は通常、要求→製品仕様→設計→実証試験で進みます。最も重要なのは製品仕様ではなく、顧客要求あるいは製品要求です。政府が要求を設定する場合もあります。
仮に製品仕様に不明確な所があったとしても、要求を明確にし、試験実証を通してすべての要求を満たせば合格とするのです。材料強度にバラツキがある場合には、試験実証にも工夫が必要ですが、例えば、最悪の状況の製品をあえて作って試験をする、あるいは、起こりうる最大の悪環境で試験して実証します。
AIも同じアプローチで要求を満たせば製品化できると考えました。当然、試験コストは嵩むので、この部分では政府の支援も必要になるでしょう。ただし、AIには航空機よりも難しい問題を１つ抱えています。
それは、前述したように、AIは同じ学習データを使って学習しても、毎回、異なるプロダクトになってしまうことです。このバラツキを適切に予測できれば良いのですが、それは出来ません。Ｎ数を増やして統計的に証明するしか方法はないように思われます。
特にAIの保守プロセスでは、同じ学習データを再学習する、あるいはデータを増強して再学習するなどが想定されますが、再学習の結果、以前よりも必ず改善したのかどうかは自明ではありません。
出荷前試験を厳格に行えば合格、不合格を判定できるでしょう。しかし、不合格の時、再学習したからといって必ず改善させるわけではありません。人間の意図したように修正できないため、そこで苦労するでしょう。そういう意味で、ＡＩの保守は安易に扱うべき問題ではなく、慎重に扱う必要があると考えます。
貴社もAIを組み込み始めていると思いますが、その保守は、どのような考え方で進めているでしょうか？