AIガバナンスの成功に向けた6つのステージゲート

2022-03-25

本稿では、ガバナンスにおける3つのディフェンスライン(リスク制御と統制活動における体制を占める代表的なフレームワーク)の内の第1線(リスクオーナーとしてリスクコントロールを行う役割の部門)に焦点を当て、9つのステップのAI開発・運用時のプロセスにおける価値のスコープ設定価値の発見価値の提供価値の管理のフェーズについて、ガバナンスの観点から掘り下げていきます。

概要

9つのステップのプロセスに沿ってガバナンスに重点を置いた際、「誰がどのような論理的根拠に基づいて、どのような決定を下しているのか」という重要な問いに答えたいと思います。このプロセスには9つのステップがありますが、ここでは重要な決定を行うポイントだけを押さえていきます。9つのステップのプロセス、主要な成果物、主要な決定を行うための6つのステージゲートの関係は図1のとおりです。

図1 9つのステップのプロセスと6つのステージゲート

(Six stage gates to a successful AI governance:https://towardsdatascience.com/six-stage-gates-to-a-successful-ai-governance-14ab0787a380より引用。作成はPwC)
 

6つのステージゲートにおける主要な決定事項は以下のとおりです。

  1. AIソリューションを使う価値はありますか
  2. AIソリューションをどのように設計(構築、購入、またはレンタル)しますか
  3. モデルは私たちの期待を満たしていますか
  4. モデルを本番環境にデプロイしますか
  5. モデルを本番稼働に移行させる準備はできていますか
  6. モデルをそのまま継続するか、再トレーニングするか、再設計するか、それとも廃止する必要がありますか

ステージゲート1:AIソリューションを使う価値はありますか

ステージゲート1は、ビジネスおよびデータを理解する最初のステップで発生し、プロジェクトにおける価値のスコープ設定をします。これはプロジェクトにおいて間違いなく最も重要なステップであり、AIソリューションの導入を進めるかどうかを判断します。

AIソリューションの導入を判断するためには、以下のとおり重要な検討項目が5つあります。

  1. ビジネスへの影響:想定しているビジネス目標やユースケースについて取り上げます。どのような事業活動、意思決定、行動をより効率的に、または効果的に行おうとしていますか。そのAIソリューションは今までにない全く新しいプロセスですか、それともシステムのための機会ですか。AIソリューションをデプロイする組織に対してはどのようなビジネス上での影響(例えば、時間の節約、コストの削減、収益の増加、エクスペリエンスの向上など)を及ぼしますか。
  2. データへのアクセスと利用:AIソリューションを開発する際、データがアクセス可能かつ利用可能であるのか、倫理的においても利用できるかどうかを把握する必要があります。例えば、モデルを構築するための十分な量のデータはありますか。データは適切にラベル付けされていますか、もしくは適切なラベルを付けることができていますか。履歴データはどの程度保存してあり、利用できますか。データは動的ですか。どれくらいの頻度で大幅に更新されていますか。
  3. モデルの利用状況:モデルが本番環境に移行した際、どのように利用されるかを理解しておく必要があります。例えば、このモデルの利用者は誰ですか。このモデルの利用者は、どの程度のレベルでビジネスまたは技術を理解していますか。ヒューマン・イン・ザ・ループ(HITL:Human-in-the-Loop)、ヒューマン・オン・ザ・ループ(HOTL:Human-on-the-Loop)、ヒューマン・アウト・オブ・ザ・ループ(HOOTL:Human-out-of-the Loop)など、人間との相互作用(人間による仲介や監視)は必要ですか。
  4. 社会的影響と危害の評価:AIソリューションが与える広範な社会的影響や倫理的影響を理解する必要があります。例えば、どの程度の人が影響を受けますか。個人の自由やプライバシーの喪失など、人権を侵害したり、環境に悪影響を及ぼしたりしないでしょうか。身体的、感情的、心理的または経済的危害を引き起こす可能性はありますか。人々の意見を操作したり、誤解させたりする可能性はありませんでしょうか。
  5. リスク評価:AIソリューションにおけるリスクの重要度を定める必要があります。リスクの階層レベルは1〜3、場合によっては1〜5のスケールになります。リスクの重要度は、AIソリューションによって引き起こされる危害の重大度、頻度、ソリューションの潜在的な社会的影響に基づいています。リスクを評価するためには、以下の問いに答える必要があります。例えば、AIソリューションに伴うリスクの種類は何がありますか。将来的にリスクが起きる可能性やエクスポージャー(財務または非財務)の可能性はどのくらいありますか。考慮すべきる潜在的なリスクに対し、どのような軽減戦略やカテゴリー別の制御がありますか。

ステージゲート1のステップには、多数のステークホルダーが関わっています。本稿では、関与するステークホルダーの役割を下記のRACIマトリックス(RACI:Responsible<実行責任者>、Accountable<説明責任者>、Consulted<協業先>、Informed<報告先>)を使って説明しています。決定事項、ドキュメント、RACIマトリックスの概要を、下記のステージゲートカードに示しています。

図2 ステージゲート1 — AIソリューションを使う価値はありますか

(Six stage gates to a successful AI governance:https://towardsdatascience.com/six-stage-gates-to-a-successful-ai-governance-14ab0787a380より引用。作成はPwC)
 

ビジネスへの影響、つまり、組織に対するAIソリューションの価値と社会的影響、または潜在的なリスクの観点から、説明責任のあるビジネススポンサーの優先順位が決まります。経済的影響力が大きいほど、または潜在的なリスクが大きいほど、企業における倫理委員会の承認を得る必要性が高くなります。

事業仕様書、社会的影響、リスク評価文書は、製品所有者が作成しなければならない重要な文書です。ビジネススポンサーである説明責任者は、ソリューションの技術的な実現可能性を評価し、さらに開発を進めて問題ないかの可否を決断しなくてはいけません。開発を進めることによるトレードオフを比較・検討するためには、アプリケーションのリスクと潜在的な問題点、そして潜在的な利点の両方を明らかにすることが重要です。

ステージゲート2:AIソリューションをどのように設計(構築、購入、またはレンタル)しますか

ステージゲート2は、プロジェクトにおける価値のスコープ設定をするためにソリューション設計を実施するステップ2の段階で発生します。ステップ1で作成されたビジネスの仕様書は、このステップ2でさらに洗練され、必要なデータとモデルの両面での調査を開始します。ステップ2では、AIソリューションを新たに構築する必要があるか、それともアナリティクス、AIベンダー、クラウドプラットフォームといったプロバイダーが所有する大規模なエコシステムから購入するか、レンタルするかなどを決定します。

このステップで考慮すべき重要な検討項目は次のとおりです。

  • 成功と受け入れの基準:ステップ1で検討したビジネスの仕様書は、自動化すべき重要なアクティビティを策定したり、AIによって強化すべきアクティビティを選別したりするにあたって活用されます。そのためには、このモデルがどのように利用され、どのデータがモデルの学習に使用されるかを考慮する必要があります。これらに基づき、モデルのパフォーマンス基準(例えば、精度、特異性、偽陽性率など)、説明可能性(解釈性)、安全性、プライバシー、セキュリティ、堅牢性について合意する必要があります。これを広く成功基準と呼びます。これらの成功基準は、成功基準を満たしているかどうかを確認する一連のハイレベルなテストおよび検証手順に合致する必要があります。これを広く受け入れ基準と呼びます。
  • 構築vs購入vsレンタル:上記の成果物を使用することで、組織は必要なAIソリューションが既に世の中に存在し、マネージドサービスとしてレンタルできるかどうかを判断できます。ここで重要なのは、既存の汎用モデルが、既に組織内で合意されているビジネス要件、成功基準、受け入れ基準をどの程度満たしているかを検討することです。また、推論を行うにあたって必要なデータを、セキュリティや機密性を担保した上で保存できる場所があるのかどうか、という点も重要な判断要素になります。ソリューションをレンタルできないけれども購入できる場合には、ビジネス要件、成功基準、受け入れの基準を満たしているだけでなく、費用対効果が高いかどうかを確認する必要があるため、同様のデューデリジェンスを実行しなければいけません。また、独自のデータを使用したモデルの再トレーニングも考慮する必要があります。最後になりますが、もしモデルを構築するのであれば、全体的なソリューション設計を構築する必要があります。つまり、トレーニングフェーズにおいてはどのように構築するのか、そしてモデルを最終的にどのようにデプロイして使用するのかも検討しなくてはいけません。例えば、システムの説明可能性(解釈性)が成功基準において非常に重要である場合、より単純なモデル構造とするか、または説明可能なAI要素が追加されたソリューションとすることが必要になります。
  • (暫定版)データセットのデータシート:データセットのデータシートを用意することは、データサイエンスコミュニティで一般的な手法の1つになりつつあります。データシートの中には、データセット内の主要なデータ項目とその定義だけでなく、データ収集の動機、構成、収集プロセス、前処理、クレンジング、必要なラベル付け、推奨される使用方法、データの共有と配布、メンテナンス、データの廃止状況が記載されます。プロセス2の段階では、データシートは包括的ではない可能性がありますが、これらの要素の一部を捉えた予備のデータシートは、モデル構築の情報に基づいた合否の決定を行う際に役立ちます。
  • (暫定版)モデルカード:データセットのデータシートと同様に、機械学習におけるモデルのドキュメント化に利用されるモデルカードもデータサイエンスコミュニティで広く使用されるようになっています。モデルカードは、モデルの詳細、使用されているアルゴリズム、モデルの使用目的、倫理的な考慮事項(バイアス、公平性、説明可能性<解釈性>の要件など)、トレーニング、検証、テストデータなど、AIソリューションを構築する際のモデルの仕様を記述しています。プロセス2のような初期段階でのモデルカードは予備的なものであり、後続のフェーズで改良されます。また、モデルの仕様には、ステップ1で説明した社会的影響とリスク評価を考慮に入れておく必要があります。
  • ソリューション設計:ソリューション設計の概念は、ソフトウェアの開発にあたって広く受け入れられている手法です。より高度なAIを活用する企業となり、1つのモデルを個別にデプロイする状態から、数百・数千のモデルをデプロイし、トレーニングを半自動もしくは自動化された状態へと移行するにつれて、従来からのソリューション設計にさまざまな要素を追加し、充実させることができます。多様なモデルが互いにどのような相互作用を起こすかを保存しておく設計方法としては、ソリューション設計全体の一部分に組み入れてエンドユーザーがデータにラベル付けや検証する方法や、モデルを収集、クレンジング、処理、フィードするためにデータパイプラインを構築する方法などがあります。
  • 詳細な開発計画:上記の全ての分析を活用することで、AIソリューションの実験に必要な合理的な計画や初期費用の見積もりを作成することができます。AIソリューションの該当プロジェクト、もしくはアジャイル/スクラム開発におけるスプリント計画では、主要な役割と責任を明確に定義し、AIソリューションのトレーニング、テスト、開発のタイミングを決定する必要があります。特に、これまでにない新たなモデルに対してプロジェクトのスコープを設定する際には、より一層の注意が必要です。

※本稿はPwCが寄稿したSix stage gates to a successful AI governanceを翻訳したものです。翻訳には正確を期しておりますが、英語版と解釈の相違がある場合は、英語版に依拠してください。

このステージのステージゲートカードは以下のとおりです。

図3 ステージゲート2 — AIソリューションをどのように設計(構築、購入、またはレンタル)しますか(出典:PwC)

(Six stage gates to a successful AI governance:https://towardsdatascience.com/six-stage-gates-to-a-successful-ai-governance-14ab0787a380より引用。作成はPwC)
 

成功と受け入れ基準は、ビジネス領域の専門家とデータサイエンスチームが共同で決定します。構築vs購入vsレンタルの決定は、ビジネススポンサーと協力しながら製品の所有者が実行しなければなりません。データシートはデータの所有者とデータサイエンティストが共同で提供し、モデルカードはデータサイエンティストが主導して提供します。ソフトウェアのソリューション設計は、機械学習またはモデルの設計者およびデータ設計者と協力して、ソリューション全体の設計書を完成させる必要があります。

AIソリューションを構築するのか、購入するのか、レンタルするのか、それとも全ての作業を放棄するのかという最終決定は、製品の所有者とビジネススポンサーが共同で行います。ステップ2とステップ1で詳しく説明されたドキュメントは、全て次のプロセスへのインプットとして使用されます。

ステージゲート3:モデルは私たちの期待を満たしていますか

ステージゲート3は、プロジェクトの価値の発見フェーズの最後に発生します。ステージゲート3の到達時点では、データ抽出、前処理、モデル構築、テストを繰り返し行う反復サイクルを通じてモデルのトレーニングを完了します。この段階で重要なのは、モデルをデプロイするのか、またはモデルの開発を延期/中止するのかという決定を行うことです。このステップで考慮すべき重要事項は次のとおりです。

  • 成功と受け入れテストの結果:成功と受け入れの基準が記載されているモデルの詳細テストは、ステージゲート3より前に実施されている必要があります。テスト結果は、モデルのパフォーマンス、モデルの説明可能性(解釈性)、公平性、安全性、制御、セキュリティ、プライバシー、堅牢性、再現性について要点をまとめる必要があります。そして、合格基準が義務付けられている、または推奨されている全ての受け入れテストを実施し、評価しなければいけません。理想としては、モデルはステージゲート2において合意形成された成功と受け入れ基準を満たすべきです。ただし、場合によっては受け入れの閾値を緩和し、モデルを次のステップへと進めることを承認することがあります。これはあくまでも例外的なケースであるため、ビジネススポンサーと製品の所有者にエスカレーションし、検討してもらう必要があります。
  • データシート、モデルカード、更新されたソリューション設計:モデルのトレーニングが完了すると、ステージゲート2の主要なドキュメントを更新することができます。例えば、モデルのトレーニングに役立ったデータセットとデータ項目を可視化すべきです。また、該当するモデルを選択し、使用したハイパーパラメータ、実行した実験、最良の結果を提供したモデルのアンサンブルを文書化する必要があります。そして、モデルの設計、データのパイプライン、ソリューション設計への変更も更新する必要があります。
  • 統合とデプロイの要件:モデルのデプロイが承認されると、モデルをデプロイするための仕様書を作成できます。例えば、本番環境で実行稼働時のモデル推論はバッチモードとリアルタイムのどちらにするか、移行期間中でのモデルの検証方法はどうするか、モデルの再トレーニングが必要になる頻度(例えば、移行中のモデルのトレーニングは、継続的とするか、または定期的に実施するか)はどれくらいか、などを説明します。また、パフォーマンスチューニングと負荷テストの要件についても詳しく説明する必要があります。さらに、モデルを他のアプリケーションシステムと統合する方法(例えば、Dockerのコンテナ、もしくはAPI呼び出しとして使用されるか、独自のスタンドアロン・フロントエンドを持つか)を詳しく説明する必要があります。
  • 変更管理計画:最終的なデプロイを計画するための最後のステップは、プロセスの変更、AIソリューションの検証、トレーニング、担当者の再配置を含む変更管理計画を作成することです。

このステージのステージゲートカードは以下のとおりです。

図4:ステージゲート3 —モデルは私たちの期待を満たしていますか(出典:PwC)

(Six stage gates to a successful AI governance:https://towardsdatascience.com/six-stage-gates-to-a-successful-ai-governance-14ab0787a380より引用。作成はPwC)
 

成功と受け入れのテスト結果は、データサイエンティストとデータエンジニアが準備し、2線のモデル検証者と倫理チームが検証します。更新されたデータシートの責任はデータエンジニアにあり、更新されたモデルカードの責任はデータサイエンティストにあります。統合とデプロイの要件を決定するのはソリューション設計、ML(機械学習)エンジニア、ModelOps(モデル・運用合同チーム)の担当者となります。変更管理計画は、ビジネスチームと製品所有者が責任を持ちます。

ステージゲート4:モデルを本番環境にデプロイしますか

ステージゲート4は、ステージゲート3にてモデルのデプロイが承認された場合に限り発生します。また、ステージゲート4は、プロジェクトの価値の提供フェーズにおける、モデルをデプロイさせるステップの最後に発生します。ステージゲート4まで到達すれば、モデルをデプロイする準備が整ったと言えます。ステージゲート4の最後に行われる重要な決定事項は、本番環境で使用するためにデプロイすることです。

  • 統合とデプロイのテスト結果:ステージゲート3までのステップで定められた統合とデプロイの要件に基づき、モデルはAPIエンドポイントとするか、独自のウェブインターフェイスを持たせるか、またはUIを備えたスタンドアロンアプリケーションとするか、このいずれかの形で提供することになります。統合テストは、このステージゲート4で実行する必要があります。さらにステージゲート4では、パフォーマンステスト、負荷分散(特に本番環境でモデルを学習させる場合は注意が必要)、モデルのバイアステスト、エンドユーザーへの説明可能性(解釈性)テスト、堅牢性テスト、敵対的攻撃に対するテストのそれぞれを実行する必要があります。
  • プロセスチェックリスト:デプロイされたモデルと人間との相互作用モードに基づくプロセス(例えばHITL、HATL、HOOTL)に対する全ての変更をチェックする必要があります。モデル検証のプロセスフローは、必要に応じて、例外、エスカレーション、承認の適切な基準を使用して実施する必要があります。ModelOps、DataOps(データ・運用合同チーム)、SecOps(セキュリティ・運用合同チーム)のプロセスは、このステージゲート4のタイミングで準備する必要があります。
  • トレーニングチェックリスト:新たな役割(ModelOps、DataOpsなど)が作られたり、既存の役割を変更したりする際には、責任と活動内容を明確にした上で文書化する必要があります。多数のユーザー(一般ユーザーやパワーユーザー)に対し、新たな役割または変更された役割に関するトレーニングが必要な場合は、デプロイ前に実施する必要があります。

このステージのステージゲートカードは以下のとおりです。

図5:ステージゲート4 —モデルを本番環境にデプロイしますか(出典:PwC)

(Six stage gates to a successful AI governance:https://towardsdatascience.com/six-stage-gates-to-a-successful-ai-governance-14ab0787a380より引用。作成はPwC)
 

統合とデプロイのテスト結果は、データサイエンティスト、MLエンジニア、ソフトウェアエンジニアが作成し、2次モデル検証者と倫理チームが検証します。プロセスチェックリストとトレーニングチェックリストは、さまざまなXops(ModelOps、DataOps、SecurityOps)グループが担当します。トレーニングの責任は、ビジネスチームと変更管理の専門家が負うことになります。

ステージゲート5:モデルを通常どおりの運用に移行させる準備はできていますか

ステージゲート5は、プロジェクトの価値の提供フェーズの最後に発生します。モデルを本番稼働(BAU:Business As Usual)に移行する前に、モデルの動作を綿密にモニタリングする必要があります。

  • モデルのモニタリング結果:従来のソフトウェアを通常デプロイする場合は、ソフトウェアの稼働がセンシティブではない、もしくはデータが新しく変更されない可能性があるため、ステージゲート5は必要ありません。しかしながら、モデルの場合は、データドリフト、機能ドリフト、コンセプトドリフトなど、多くの場合において「ドリフト(予期せず変化すること)」が発生する可能性があり、そのためデプロイされたモデルの最初の数カ月間は注意深くモニタリングする必要があります。その期間がどれくらいになるかは、モデルの使用頻度とデータの到着率によって異なります。
  • BAU(本番稼働)移行チェックリスト:モデルを綿密にモニタリングした後、モデルを実稼働で使用する価値が引き続きある場合は、運用チームに業務を移行する必要があります。その際、適切な教育を受けている運用担当者が割り当てられているかどうかは、BAU(本番稼働)のモデルへと移行するための重要なポイントになります。この段階においては、持続的なモニタリング基準(パフォーマンス、バイアス、説明可能性<解釈性>など)、介入の閾値、テストの頻度を明確にし、合意を得る必要があります。

このステージのステージゲートカードは以下のとおりです。

図6:ステージゲート5 —モデルを通常どおりの運用に移行させる準備はできていますか(出典:PwC)

(Six stage gates to a successful AI governance:https://towardsdatascience.com/six-stage-gates-to-a-successful-ai-governance-14ab0787a380より引用。作成はPwC)
 

モデルの監視結果は、データサイエンティストの支援を受けて、さまざまな運用上の役割(ModelOps、DataOps)によって作成されます。BAU(本番稼働)への移行にあたっての責任は、ビジネスチームと運用上の役割が共同で負うことになります。

ステージゲート6:モデルをそのまま継続するか、再トレーニングするか、再設計するか、それとも廃止する必要がありますか

ステージゲート6は、価値の管理フェーズにおける評価の最中および、チェックインステップ中に定期的に発生します。モデルを評価する頻度は、BAU(本番稼働)に移行する段階または価値の提供フェーズの最後に決定されます。各評価で行われる決定は、変更なしでモデルを続行するか、モデルを再トレーニングするか、再設計するか、モデルを廃止するかです。この決定を行うにあたって考慮すべき重要事項は次のとおりです。

  • BAU(本番稼働)モニタリング結果:ステージゲート5までに確認していたモデルのモニタリング結果の全てを、BAU(本番稼働)のモニタリング結果に含める必要があります。また、モデルの老朽化については、当期と前期の比較、モデルのデプロイ当初とトレーニング後の結果の比較により評価する必要があります。モデルが老朽化し、不安定化してくると、モデルの再トレーニングや再設計が必要となる可能性があります。
  • ROI値:モデルの性能に加えて、ビジネスにおいてはROI、もしくはモデルの価値評価を検討事項に含める必要があります。つまり、モデルの利点(効率化、有効性、エクスペリエンスの向上、コスト削減、収益増加など)を考慮に入れ、モデルを本番環境で稼働することで得られる利点が、モデルの維持コストを上回っているかどうかを判断しなければいけません。その上で、現行のモデルを廃止するか、別のモデルや新しいモデルに置き換えるべきかを判断します。

このステージのステージゲートカードは以下のとおりです。

図7:ステージゲート6 —モデルはそのまま継続するか、再トレーニングするか、再設計するか、それとも廃止する必要がありますか(出典:PwC)

(Six stage gates to a successful AI governance:https://towardsdatascience.com/six-stage-gates-to-a-successful-ai-governance-14ab0787a380より引用。作成はPwC)
 

BAU(本番稼働)モニタリング結果は、データサイエンティストとビジネスチームの支援を受けながら、運用の役割を持つ各チーム(ModelOps、DataOps)が作成します。ROI値の分析は、データサイエンティストやModelOpsの担当者とともに協力して働いているビジネスチームが責任を負います。また、モデルの再トレーニング、再設計、または廃止するかの最終決定は、製品の所有者が行う必要があります。

本稿で解説した、モデルの開発や管理を行うための9つのステップにおいて生じる6つのステージゲートは、Software2.0における管理プロセスにおいて必要不可欠な重要なマイルストーンの1つです。本稿の中で概説した仕様書の精密さと深堀り具合は、モデルのスケール、スコープ、複雑さ、および社会的な影響度に基づいて調整することが望ましいです。

※本稿はPwCが寄稿したSix stage gates to a successful AI governanceを翻訳したものです。翻訳には正確を期しておりますが、英語版と解釈の相違がある場合は、英語版に依拠してください。

主要メンバー

藤川 琢哉

パートナー, PwCコンサルティング合同会社

Email

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}