QA4AIガイドラインの概要

AIの品質に関する注目の高まり

2000年代から現在まで続く第3次AIブームをきっかけに、ビジネスの現場や日常生活でAIの活用が進んでいます。しかしAIには品質の把握が困難などの特性があり、従来の品質保証の手法が通用しないという課題があります。安全性や基本的人権を脅かす懸念もたびたび指摘されており、欧米ではAIの利用を規制する法的な枠組み案が示されています。

欧州では、AIの信頼性を高めるためにリスクベースでのアプローチが取られており、AIの利用目的に応じて「容認できないリスク」「高リスク」「低・最低限のリスク」という3段階のリスクが設定され、段階別の規制を設けるという法案も提出されています。例えば、高リスクにおいては運用開始前の開発段階に加えて、運用開始後の品質管理も求められます。一方、米国の規制方針では、特にバイアス（先入観、偏見）や倫理面などの面から、公平性に関する対応（データの点検や説明責任など）を企業に求める考えが示されています。

AIが普及するにつれ、社会の変化に合わせてAIのモデルを変化させなければならない状況も増えてきています。 例えば、自動運転に使われるAIであれば、交通ルールの変更や、社会の要請の変更などに応じて、モデルを対応させていく必要があります。そのため、DevOps ^※1の機械学習版ともいえるMLOps（Machine Learning Operations）など、AI品質を継続して管理する取り組みにも注目が集まっています。

こうした背景から、AIの品質に関わる各種標準やガイドラインが国内外で多数公表されています。これから解説する「QA4AI ^※1ガイドライン」もその1つです。

※1：システムの開発チームと運用チームが連携・協調しながらシステムの運用開始後も継続的に改善を続ける仕組みや考え方のこと。
※2：Quality Assurance for Artificial-Intelligence-based products and services

QA4AIガイドラインとは

QA4AIガイドラインは正式名称を「AIプロダクト品質保証ガイドライン」といいます。国内の産学の関係者でつくるQA4AIコンソーシアムが発行しており、AIプロダクトの品質保証における共通の指針となることを目的としています。2019年6月の初版から年次改訂を繰り返し、2021年9月に最新版がリリースされています（ 無料でダウンロード可能）。

AIとその品質保証は日進月歩で進化しており、QA4AIガイドラインも新たな技術や内容の追加・修正が随時行われています。ご紹介する事例も、検討当時のQA4AIガイドラインを私たちなりに理解して使ってみた内容となります。ガイドラインの適用を検討する際はこのような性質についてご留意いただき、最新版で確認いただければと思います。

AIプロダクト品質保証の5軸

QA4AIガイドラインでは、次の5つをAIプロダクトの品質保証の軸としています。

• Data Integrity（データがきちんとしているか）
• Model Robustness（精度が高く頑健性が確保されたモデルであるか）
• System Quality（システム全体として品質が確保できているか）
• Process Agility（開発プロセスは機動的か）
• Customer Expectation（顧客の期待は高いか）

これを図式化したものが図表1です。ガイドラインでは各軸にチェックリストが用意されています。これら用いて十分な検討や処置が実施されているかを判断します。

QA4AIガイドラインはAIプロダクト（AIモデルだけでなく従来型のソフトウェアも含めたシステム全体）の品質保証を対象としているため、この5軸の内容のうちAIモデルのみを対象としているものは比較的少ないと言えます（図表2）。軸ごとに必要となる知見はAI寄りだったりプロダクト寄りだったりするものの、全体としては両方の知見が求められます。したがって、AIの専門家だけでAIプロダクトの品質保証を行うことは困難だと考えています。

チェックリストの質問項目を補う

QA4AIガイドラインに示されたチェックリストの質問項目はいずれも具体的ですが、担当者の習熟度によっては理解が難しい部分もあるでしょう。そこでHACARUSと一緒に取り組んだのが、元の質問の意図をより明確にするための質問や解説の追加です。

例えば、System Qualityの中の「事故発生の回避性」には次のようなチェック項目があります。

システムの安全性に通じていれば問題なく理解できる内容ですが、その知見がないと「十分」という言葉の解釈を誤る可能性があります。そのために補足したのが次の解説です。

「事前に合意したリスクレベルに到達する（までリスクを低減させる）」こと、これがシステム安全性の文脈における「十分」の解釈です。このように、QA4AIガイドラインを用いる際はチェックリストを使う担当者の知識レベルを想定した上で、組織ごとに解説を追加することをお勧めします。

チェックリストの評価

QA4AIガイドラインには、5軸とそのチェックリストの評価結果が例示されています（図表3）。全ての軸が高評価となることが良いプロダクトというわけではなく、フェーズやシステムの特性によって満点は変わります。つまり、レーダーチャートを可能な限り大きくすることが必ずしもその時点での正しいアプローチではないということです。ガイドラインを用いてAIプロダクトを評価する際はこの性質をよく理解しておく必要があります。

QA4AIガイドラインを実プロジェクトで活用する際に考慮すべきこと

ここまでのまとめとして、QA4AIガイドラインを実プロジェクトに適用する際に考慮すべきことを確認しておきましょう。

5つの評価軸はチェックの際に求められる知見がそれぞれ異なる

AIとプロダクトの品質保証の両方に精通した人材はそう多くありません。AIの品質はAIの専門家が、プロダクトの品質は品質保証の専門家が評価するというように、分担して実施することをお勧めします。

チェックリストの項目は使う人の知識レベルに合わせて補足する必要がある

チェックリストは、担当者の習熟度に応じて解説の追加や質問項目の詳細化をお勧めします。ソフトウェアテストでは一般的にテストケースの詳細度を実行者ごとに変えますが、これと同様にチェックリストも適宜、補足説明を加えるなど内容を見直すと良いでしょう。

改善目的で使う場合は各チェック項目の対策まで準備する

評価結果を改善にまでつなげるには、対策まで準備しておくと理想的です。

フェーズ（PoC／本開発／運用）ごとに見るポイントが異なる=満点が異なることを考慮に入れる

評価に使うレーダーチャートの形やサイズの目標は、開発から運用までの各フェーズで変わってきます。常に満点を目指すのではなく、フェーズごとに到達点を判断することが大切です。

実プロジェクトのアセスメント事例

ここからは、QA4AIガイドラインを使って実プロジェクトをアセスメントした際の流れについて、HACARUSの染田が順を追ってご説明します。 私たちの実践では、ガイドライン適用の目的を確認した後、「準備」と「適用」の２つのステップに分けて実施しました。

目的の設定

新しい取り組みをするときには、まず目的を関係者間で共有することが重要です。HACARUSの場合はAIプロダクトの開発が専業のため、品質の視点がAIモデルの性能に行きがちです。しかし、本番環境に導入する際は、開発時には想定していなかったデータが入ってきた時の振る舞いなど、AIモデル以外の部分も含め、システム全体で品質を保証する必要が出てきます。こうした経験を重ねるにつれ、AIプロダクトをシステムとして網羅的な視点から評価したいと考えるようになりました。これが私がQA4AIガイドラインに興味を持ったきっかけで、システム全体の品質について、現状を把握することを目的として定めました。

ガイドライン適用に向けた準備

・質問項目の見直し・説明追加

QA4AIガイドラインのチェックリストは一定の方向性を示すものですから、実際の評価の際はプロジェクトに合わせて内容をかみ砕き、必要に応じて補足する必要があります（図表4）。

例えばData Integrityにある「学習データの量の十分性」という項目には、次のような質問があります。

これをこのまま評価に使うと担当者の知識レベルや経験に左右されることになります。そこで、次のような初歩的な質問を設定しました。

ポイントは、担当者が迷わないようにYes／Noの回答形式にしたことです。これにYesと答えた場合のフォローアップとして、次の質問を追加しました。

これに対して、「学習に使うデータ量を変えて、そのAIモデルの性能がどう変わるかを検証した」といった具体的な施策を実施した場合は1点、実施していない場合は0点と点数化し、その項目の対策の有無を評価の基準としました。なお、今回の実践では点数の重み付けは行わず、その時点での5軸の凸凹の状態をつかむことを目指しました。

・フェーズの導入

AI開発のプロジェクトは、いくつかのフェーズを経た後に本番運用に入ります。図表5は私たちが取り扱うAIプロダクトを例に、ガイドラインの5軸と開発・運用フェーズの関係性を表したもので、色が濃いほど重要度が高くなります。例えば、Data Integrityの軸であれば、PoC
（Proof of Concept ^※3）の計画から実施の準備までのPoC設計フェーズにおける重要性が高いのに対し、System Qualityの軸では、PoCの評価後、システムの開発・設計がスタートするタイミングで重要度が一気に高まります。この情報を使い、フェーズごとに5軸のどこを注視すべきかを整理しています。

※3：新しい概念や理論、あるいはアイデアの実証を目的とした試作開発の前段階における検証、デモンストレーションのこと

・質問票の例

これまでの話を踏まえて私たちが準備した質問票が図表6です。

左からの2列はQA4AIガイドラインをそのまま使用したもの、同3列目の「実施内容を確認するための質問項目」は私たちの用意したものです。評価と最高点を挟んで右にPoC設計やPoC評価など開発フェーズを示す列を設けています。先ほどのフェーズごとの重要度に基づき、質問項目単位で評価する／しないを判断し、評価対象とする質問項目には丸印を付けています。

・ガイドラインの適用

質問票が整ったら、ガイドラインに基づきアセスメントを実施していきます。作成した質問票を使って、ここはできた、ここはまだ考慮が必要、というようにプロジェクトを評価し、その結果からどんな改善項目があるのかを考察します。

ご紹介したプロセスは私たちの目的に合わせて作成したものですので、他の進め方もあるでしょう。ただ、実際にこうしたガイドラインの項目をもう一段噛み砕くステップを踏むと、QA4AIガイドラインをより有効に活用することができると考えています。

実践例1：画像認識

ユースケースにガイドラインを適用した具体例をご紹介します。まずは、AIプロダクトでは比較的よく見られる、画像認識のユースケースです。このプロジェクトはPoC段階で評価できないチェック項目が多くなっています。

そのため、着手している／していないという「進行度」と、できている／できていないという「達成度」、この2つの観点を新たに追加し、その結果を基にPoCの初期と後期で評価を試みました。その結果が図表7で、ブルーが進行度、オレンジが達成度を示しています。

図左のPoC初期では達成度（オレンジ）のチャートは小さいのですが、「未達成だが考えられている」という進行度（ブルー）のチャートを加えることで、全体のバランスを視覚的に捉えることができます。

PoC後期になると、例えば初期にSystem Qualityで発見した問題を改善したことによって、進行度、達成度ともにチャートが広がったことが図右から見て取れます。

実践例2：画像からの物体検知

固定カメラに写った画像からAIに特定の状況を検知させるもので、これもAIのポピュラーなユースケースです。試験運用中のものを対象にアセスメントを実施した結果が図表8で、左がPoC終了時、右が試験運用中の評価です。

PoC終了時では、Model RobustnessとSystem Qualityが低い評価となっています。Model Robustnessの方は試験運用を通じて改善を図るつもりでいたため予想通りだったのですが、System Qualityに関しては考慮不足がありました。

ここで分かったのは、AIの性能はシステムの提供価値とは必ずしも一致しないということです。この例で言えば、画像から特定の物体を検出する、あるいは特定の状況を一定の精度で検出するというのがAIの性能で、これらはPoCの段階で十分に考慮していました。しかし、システム全体として本来提供すべき価値は、例えば検出した結果をシステムのユーザーにフィードバックして何らかの効率改善をもたらすものであるはずです。このことに気付き、継続的に考慮を重ねていったことで、試験運用の段階ではSystem Qualityも大きく伸張する結果となりました。

・実プロジェクトでのアセスメント実施を経て気付いたこと

今回の実践によってあらためて認識したことは、PoCのような初期フェーズでは、システム全体のユースケースにおける品質課題にまでは考慮が至りにくいということでした。こうした課題に気付いた結果、実践例2では顧客への提案やアプリケーション仕様への反映など、具体的な改善策に結び付けることができました。

・QA4AIガイドライン適用の実践に向けたヒント

・質問票の利用範囲の検討

質問票を作成する際、さまざまなプロジェクトでの利用を目的としてしまうと質問が抽象的になり、担当者によっては理解が困難になります。反面、単独案件に特化した質問票にすると利用範囲が狭くなります。汎用性と個別性のバランスをうまく調整する必要があります。

・担当者の知識・スキルレベルの把握

評価のばらつきをなくすため、AIと品質管理についての担当者の知識・スキルレベルを正確に把握する必要があります。AIと品質管理のどちらかに寄っている場合は、それを補完する人材を確保する必要があります。

・質問作成と評価実施の分担

質問の作成と評価を兼任すると、どうしても自分の経験がベースとなり、評価の際にバイアスが掛かりがちです。質問作成と評価実施の担当者は分けることを強くお勧めします。

・改善対策の定型化

評価結果が出た後の対策についても、実施すべき事柄をある程度まとめたものが欲しいところです。それがあれば、アセスメント結果を改善策へとスムーズにつなげることが可能になります。

・対象プロジェクトの選定

アセスメントの対象には、なるべくPoC終了後のプロジェクトを選ぶことをお勧めします。実践例1でご紹介した通り、PoC段階では評価結果のチャートが小さくなりがちですが、質問の作り方に課題があるのか、プロジェクト自体の問題なのかの判断は困難です。開発フェーズ以降にあるプロジェクトの方が、5軸をバランス良く多面的に評価することが可能です。ただし、PoCにおいても課題を事前にできる限り把握しておくことが望ましいため、チャート化まではせずともData IntegrityとCustomer Expectationについては念頭におくことが望まれます。

おわりに

AIプロダクトの品質保証は、ビジネスの現場でAIを使っていくために避けて通れないものです。それを支援するQA4AIガイドラインは大変有用なドキュメントですが、まだまだ発展途上の側面もあります。これを補完するものとして、私たちの実践例が皆様の参考になると共に、これからトライをする方々の後押しになれば幸いです。