AI／機械学習の品質保証が抱える課題に開発者はどう対応すべきか：「QA4AIガイドライン」とは（1/2 ページ）

＠ITは2019年11月19日、「＠IT ソフトウェア品質向上セミナー 2019 冬〜不確実性が高まるDX時代のソフトウェアテスト／品質保証はどうあるべきか」を開催した。本稿では、AIプロダクト品質保証コンソーシアム 副運営委員長の石川冬樹氏の基調講演「『うちのAI大丈夫？』と言われた開発現場が慌てないための指針〜AIプロダクトと非AIプロダクト、テスト／品質保証の違いと共通点とは」の模様を要約してお伝えする。

[高橋睦美，＠IT]

AIプロダクト品質保証コンソーシアム 副運営委員長
国立情報学研究所 准教授
石川冬樹氏

　機械学習／人工知能（AI）の活用領域は広まるばかりだ。期待が高まる一方で、「人の生命に影響を及ぼしかねない事故や不適切な判断につながるのではないか」と議論を呼ぶこともある。

　2019年11月19日に開催された「＠IT ソフトウェア品質向上セミナー 2019 冬〜不確実性が高まるDX時代のソフトウェアテスト／品質保証はどうあるべきか」の基調講演において、AIプロダクト品質保証コンソーシアム 副運営委員長であり、国立情報学研究所 准教授を務める石川冬樹氏は、「不確実性」をはじめとするAIの特質を踏まえながら、どのように品質を保証していくかについてのヒントを紹介した。

「帰納法」で作られる機械学習システムにまつわる品質保証上の課題

　石川氏はソフトウェア工学に関する研究に携わりつつ、機械学習システム開発、運用に関わる工学的手法の確立、体系化に取り組む「日本ソフトウェア科学会 機械学習工学研究会」（MLSE）や、AIプロダクトの品質保証に関する調査、体系化を目的とした「AIプロダクト品質保証コンソーシアム」（QA4AI）の立ち上げに関わってきた。

　この数年、ディー・エヌ・エーがアニメキャラクターの画像を生成できるAIを開発したり、Uberが自動運転技術の開発を進めたりと、さまざまな取り組みが進んでいるが、一方で、残念ながら自動運転車による事故が発生したり、人種差別や不適切な判断につながったりするといった問題も浮上してきた。中には、「オオカミ」の画像を認識する識別器を作ったのはいいが、実は「雪の写っている画像ならばオオカミである」という規則を学んでいた、というケースも報告されている。

AI開発における社会的影響の大きな例、技術的限界の例（石川氏の講演資料から引用）

　こうした事例を踏まえ石川氏は、「果たして結果さえ合っていればいいのか。品質保証の中で、どのようなルールで学習したかという『規則』の妥当性確認も必要ではないか」と述べた。さらに、こうした問題は全て不具合であり、直すべき問題なのか、技術的限界のため直せない問題もあるのではないかといった課題があり、「その中でどう品質を保証するのかが問われている」とした。

　これまでのソフトウェアの作り方は「演繹（えんえき）法」によるものだった。軽減税率への対応が一つの例だが、まず何らかの要求や規則があって、それに沿ってソフトウェアや部品を作っていたが、AI、特に機械学習の場合は帰納法のやり方でシステムを作っていく。このため、「自分たちが作ったプロダクトなのに、何をするのか直接コントロールしていないことになる。これは大きな違いだ」（石川氏）。

従来（非AIプロダクト）と機械学習（AIプロダクト）における要求と実装の対応の違い（石川氏の講演資料から引用）

　何をやっているか分からないのに、訓練に基づいてシステムが作られていく――それ自体はすごいことだが、「100％うまくいくかどうか分からない」「作ってみるまでできるかどうか、性能が出るかどうか分からない」ということでもある。果たして「できるかどうかは分かりませんが、一緒に頑張りましょう」というやり方が、システム発注者、特に経営層にとって納得できるかというと、非常に難しい。

　また、機械学習には大量の適切なデータが必要になる一方で、もし「訓練していないデータ」「試していないデータ」に遭遇した場合、どう振る舞うかは分からない。その上、「なぜこうした結果が出たのか」も説明できない。

　こうしたもろもろの機械学習の特質を考えると、「根本的に今までのソフトウェアとは違う」と石川氏は述べた。機械学習工学という分野を立ち上げ、これまでのソフトウェア工学とは異なる設計やテスト、品質保証について検討を始めた背景には、そうした問題意識があったという。

人の営みに関わるが故の「不確実性」を踏まえた新しいアプローチを

　要求工学や設計、テスト、品質保証といった各ステップで機械学習ならではの難しさを多くのエンジニアが感じていることは、MLSEが2018年に実施したアンケート結果からも明らかだ。ソフトウェア開発に関しては10年以上と豊富な経験を持つエンジニアからは、「どれだけテストすればいいのか見積もりが難しい」「やってみたらやってみたで、精度が出ることもあれば出ないこともあり、非常に試行錯誤が多い」「テストでうまくいったからといって、同じように動くといえるかというと難しい」などの声が寄せられたそうだ。

MLSEが2018年に実施したアンケート結果（石川氏の講演資料から引用）

　特に、「要求・受け入れ」「テスト品質」「デバッグ」の領域で、「今までのやり方が全然通用せず、根本的に異なる新しいやり方が必要だ」と多くのエンジニアが感じているという。

　中でも「要求・受け入れ」の部分には課題が多い。事前に「何ができるか」「どこまでできるか」を約束できないまま取り組まざるを得ないため、「一緒に頑張りましょう」で始めたとしても、後出しの文句が出やすくなる。また、出来上がったら出来上がったで、「10回に1回は失敗するものが完成しました」と言われて、顧客が納得できるかというと難しい。制度も不確かなため、「PoC止まり」に終わったり、本番導入してもうまくいかなかったりすることも少なくない。「不確実性が高く、安心し納得して導入してもらうことが難しくなっている」（石川氏）

　ただ、「これは、善いか悪いかではなく、『本来の人の営み』に関すること、確実に答えが出るとは限らないことを処理するようになったためだ」と石川氏は述べ、その上でどのような価値が出るかを考えなければいけないとした。

　100％の正解がなく、いくらでも「例外」があり得る上に、作り手によっても、また世の中の変化によっても、結果がブレる可能性がある機械学習。あちこちで不確実性が紛れ込むことを前提にしていかにリスクを抑え込むか――それには、どのようなアプローチが考えられるのだろうか。

　例えば自動運転用の機械学習を開発する際に「10万件のデータで検証を行った」としても、雪道や山道、逆光など、レアケースは無限にある。「これだけの多くの数で検証し、95％認識できるようになりました」という説明だけで「めでたしめでたし」とはならず、検証に使われたデータセットの内容が大きな問題になる。

自動運転の認識における「不確かさ」（石川氏の講演資料から引用）

　石川氏はヒントとして、「100％の精度」という基準の代わりに、クリック率や工場の回転率といった何らかの「上位目標」を測定するしかないのではないかと述べた。「これだけできれば十分だ」という水準を自分たちで決め、不完全なものを取り入れ、役立てていくアプローチだ。「結局は人の営みそのものであり、社会を生きることなので、完全ではないことを嘆くのではなく、不完全でもハッピーだということを追求していかなければならない」（石川氏）

　また、Googleのように一歩先を行く企業の中には、テストに関するガイドラインやチェックリスト、テストストアなどをまとめ、公表しているところもある。これらも参考になるだろう。

　なお、「一般に『テスト』というと、『製品をリリースする前にしっかり確認を尽くすこと』と思うかもしれない。これに対しGoogleの論文が示しているのは、訓練時のデータを基に、『なぜこのシステムはうまく動作するのか』という前提、想定が崩れていないかを見張り続けていくテストだ」という。つまりリリース前の確認ではなく、運用開始後に明らかになる「不確実性」や「変化」を確認するアプローチだ。