株式会社ベリサーブ
研究企画開発部　部長
松木 晋祐

概念の整理

AIと品質保証技術の関わりについては、これまで「AI by QA」、
「AI with QA」などさまざまな呼称がありましたが、近年では
「QA4AI」と「AI4QA」という言葉・概念で統一されてきたように 思います。二つの概念の違いを整理すると、「QA4AI」はAIが搭載された製品に対して品質技術をどのように適用していくかという「考え方」なのに対し、「AI4QA」はAI技術を品質技術にどのように活用していくかという「アプローチ」です。昨今、AI4QAを具体化したものとして、AI技術の搭載によってより高い精度で、より効率の良い処理を実現した「より良いツール」がテスト自動化ツールを中心に数多く登場しています。

品質保証技術を俯瞰してみると、ソフトウェア品質のマネジメントからテストの実行まで、技術の領域は多岐に及びますが、AIが得意とする分野は現在まだ一部にとどまっています。AIを活用した新しいツールがどの技術をカバーするものであるかを意識して初めて、その効果を最大限に活かせるようになります。「AI技術を品質保証技術にどう活かすか」について考えることが、テスト技術者の役割であると言えます。

出典：http://www.qa4ai.jp/QA4AI.JaSST-Tokyo.20190327.pdf

図1：AIプロダクト品質保証ガイドラインの5つの軸と
顧客の期待とのバランスを見る評価の一例

QA4AI

QA4AIに関して、AIプロダクトに対する品質保証の考え方がまとめられている代表的な二つのガイドラインをご紹介します。

１．AIプロダクト品質保証ガイドライン

一つは日本の有識者団体であるAIプロダクト品質保証コンソーシアムによる「AIプロダクト品質保証ガイドライン ^※1」です（2019年初版発行、2020年8月改定）。この中では、AIプロダクトに対して普遍的に適用しうる「5つの軸」を策定し、製品ドメインごとに注力すべき軸のバランスを変えるというアプローチ（図1）を中心に、説明可能AI （XAIなどと呼ばれます）技術への言及、実践的な品質技術のカタログ、各ドメインにおける具体的な成果物などが掲載されています。
中でも品質技術のカタログには、いくつかの軸に対応した性能指標やデータの評価、頑健性、公平性について、具体的にどのように品質保証を行うべきかという指針が示されています。特に、教師あり学習モデルに対する性能指標は非常に具体的に記述されていて参考になります。

※1：http://www.qa4ai.jp/QA4AI.Guideline.202008.pdf（2021年2月15日参照）

２．機械学習品質マネジメントガイドライン

もう一つは、国立研究開発法人産業技術総合研究所（AIST）と国立情報学研究所（NII）が民間企業や大学と共同でまとめた「機械学習品質マネジメントガイドライン ^※2」（2020年6月初版発行）です。こちらにはAIを採用するシステムのライフサイクル全体における品質マネジメントについて、必要な取り組みや検査項目が掲載されています。ISO25010-10利用時品質モデルや、機械学習要素に対する外部品質、内部品質の測定法を定義しており、これまでISO25000シリーズを運用してきた企業などにとっては違和感のない構成で、受け入れられやすいのではないかと思います（図2）。

※2：https://www.cpsec.aist.go.jp/achievements/aiqm/

図2：機械学習品質マネジメントガイドラインでの製品品質実現の全体構造

AI4QA

ここからは、AI技術を品質保証技術に応用して、その精度や効率を向上する「AI4QA」のさまざまなアプローチについて見ていきます。

１．AI自動テストツール

まず、AI4QA分野において著しい進化が見られるものの一つに自動テストツールがあります。進化の段階を三つの世代に分けると（図3）、第一・第二世代はその過渡期でもあり、テスト対象の仕様変更に伴う、テスト実行スクリプトの保守などの面において課題も少なくありませんでした。第三世代になりAI自動テストツールが登場すると、テスト対象のコード変更に対する影響箇所の特定や、画像解析を利用したテストコードの自動生成などが可能になり、これまでの課題はスマートに解決されるようになりました。

図3：AI自動テストツールの三世代

一方で、AI自動テストツールによって次々にテスト作成が行われるようになった結果、テストケースが数万件という単位で膨張する事態が発生します。テストの実行時間が長大化し、テストレポートの仕分けなど人間がチェックすべき要件も数千件単位で増加します。ここから考えると、次世代のAI自動テストツールは「チェックをいかに効率化するか」あるいは「実行するテストの数をいかに減らすか」のいずれかのアプローチを歩むことになると思われます。

２．自動テストの実行時間を短縮： Launchable

「実行するテストケースを絞る」というアプローチにトライしているのが「Launchable」（Jenkinsの開発者・川口耕介氏が開発したクラウドサービス）です。このサービスはテスト対象製品のソースコードの変更に基づいて起こるテストケースの失敗（Failed）を予測し、失敗する可能性の高いテストケースを提案します。ソースコードの変更と関連の深いテストだけを実行することにより自動テストの時間を短縮することができます。

プログラマがソースコードをコミットする際、リグレッションテスト（変更したコードが他の機能に害を及ぼしていないことを確認するテスト）を長時間かけて全ケース実行するよりも、ある程度高い精度のテストケースのみに絞り込んで実行し、結果が出るまでの時間を短縮することを重視する。万が一、不具合が起こった場合も、対応の確認まで短時間で済むという安心感を開発者に与え、スピードを落とさず開発できるようになる。このようなコンセプトがLaunchableの面白いところだと思います。

３．ニューラルファジング

次にニューラルファジングというアプローチを紹介します。こちらは「Microsoft Security Risk Detection（MSRD）」に含まれる製品です。ファジングは、ソフトウェアに対して予測不可能な入力データ（fuzz）を与えて不具合の発生を確認する手法です。かねてより機械学習と非常に相性のいい技術だと思っていたところ、やはりツールとして具体化する企業が現れました。
ニューラルファジングは、グレーボックスファザー（テスト対象のプログラム構造は意識しないが、過去の挙動をもとに以降の入力データをガイドする機能を有するファジングツール）に機械学習のアプローチの一種であるディープニューラルネットワーク ^※3を活用することでソフトウェアの脆弱性を発見しようとする試みです。「American Fuzzy Lop」(AFL)というオープンソースのグレーボックスファザーで実験を行ったところ、ニューラルAFLは通常のAFLに比べてより多くのクラッシュが確認でき、高い検証成果を得ました。ニューラルファジングは現在非推奨となっていますが、2020年末にはオープンソース化して再登場する予定になっています。

※3：GitHub社が運営するクラウドの開発プラットフォーム。ソースコード管理やコードレビュー、プロジェクトの管理など、チームでのソフトウェア開発に便利な機能が備わっている。　https://github.co.jp/

４．コードレビューの自動化

コードレビューを自動化する試みとしては、Amazon.com社の「Amazon CodeGuru」という製品があります。これはAmazon.com社内の数十万のブロジェクトやGitHubに載っている1万件以上のオープンソースのプロジェクトのコードレビューをもとに、教師あり学習モデルを利用して、コードの問題があると思われる部分、パフォーマンス低下につながりそうな部分を指摘してくれるサービスです。コードの品質に関して
CodeGuru-Reviewerが指摘してくれるポイントを図4にまとめています。
GitHubはオープンソースのプロジェクトであれば、プログラマがコミットしたコードに対して、プロジェクトに参加している人がどういったコメントを付けているか誰でも見ることができます。似たようなコードには似たような指摘が入るため、これを学習すれば成果が上がると考えられるわけですが、実際にアイデアを具現化したところが素晴らしいと思います。

出典：https://aws.amazon.com/jp/codeguru/features/

図4：Reviewerがコードの品質に関する問題を指摘する様子

５．ベリサーブの取り組み

ベリサーブの取り組みについてもいくつか紹介します。当社では技術者のテスト観点についての知見をまとめた「テスト観点のデータベース」を有しています。現在、このデータベースを利用し、テスト設計の際、テスト対象の仕様文章を入力すると、仕様に適用できそうなテスト観点を推薦してくれるサービスを開発し、社内提供しています。先述した「Amazon CodeGuru」に近いもので、熟練のテスト技術者の描くテスト観点をフォローできるメリットがあります。その他、システムやネットワークから吐き出される膨大なログから不具合につながる箇所を検出する技術なども研究を進めています。

今後のAIと品質技術

ここからは今後の「with AI」と呼ばれるAIが当たり前にある時代の中で、私たち品質技術者がどのように活動していくべきかについて考えていきたいと思います。

１．DevOpsへの組織的な投資で生じる「差」

今後、開発→品質保証→開発というプロセスはさらに加速していきます。開発と品質保証のターンアラウンドタイムもますます短縮化され、同時に、開発と品質保証の境界はより曖昧になっていきます。先ほどからご紹介しているような品質保証技術を活用できる組織（エリートパフォーマー）と活用できない組織（ローパフォーマー）では、製品の新バージョンを届けるまでのリードタイムに大きく差が生じ、その差は実に100倍と言われます。

図5はJaSST '20 Niigataにおける和田卓人氏（タワーズ・クエスト株式会社）の基調講演資料の引用ですが、リードタイムを含め4つのキーメトリクスが紹介されています。しかし、これらの差は個人の資質だけの問題ではなく、DevOpsへの組織的な投資の差による部分が大きいとされています。エリートパフォーマーがパフォーマンスを向上させるために用いる技術の多くは、従来の品質技術をベースにAIを活用した新しい技術でフォローできる領域です。“安全な実装”または“その実装が安全であること”をツールでフォローできる体制をいかに整えられるかという点に着目すべきだと思います。

出典：JaSST'20 Niigata 基調講演 和田 卓人 氏　https://twitter.com/t_wada/status/1310496998341005312
引用元：https://www.slideshare.net/DevOpsWebinars/2019-accelerate-state-of-devops-survey-results-are-in

図5：エリートパフォーマーとローパフォーマーのリードタイム比較

２．DevOpsをつなぐQAの役割

それでは、私たちは今後何をするべきでしょう。折しもDevOpsの中心に入るエンジンとして、AI4QAという心強い武器が登場しました。
DevOpsはDevelopmentとOperationからなりますが、本来この間には「QA」があるべきです（DevQAOps）。DevOpsによっていくら早く走れるようになっても事故を起こしては意味がありません。 DevからOpsに渡す時に、価値を確定するQAが入るシーンはこれから増えていきます。その時、「今回のリリースに対して何が十分なのか」をAIの力を借りて判断し、ジャスト・イン・タイムで必要なテストを届ける。今後はこういったインテリジェントなQAが必要になってくると思われます。

おわりに

開発のスピードが求められる現代は、ソフトウェアテストをはじめ品質技術をAI4QAのような形でソフトウェア化すること、またそれを支えるための指針を示す技術者の育成が急務となっています。同時にそれはベリサーブの使命でもあります。私たちはこれまで培ってきた技術やノウハウを最大限に活かしながら、これからもお客様とともにソフトウェア品質技術の未来を創っていきたいと思っています。