生成AIが抱えるリスクにどう対処するのか？

生成AIの活用が進み、企業でも業務に取り入れるところが増えています。それと同時に、生成AIが抱える課題やリスクも見えてきた……というよりも、当初から言われていた課題に現実的に取り組む必要が出てきた、という感じかもしれません。よくある課題としては下記が挙げられます。

• ハルシネーション：もっともらしい虚偽がアウトプットされる
• 不正利用：悪意ある利用者によって生成AIのアウトプットが脅迫・詐欺などに利用される
• プライバシー侵害・秘密漏えい：インプットが学習され、個人情報や秘密情報が流出する
• 知的財産権侵害：生成AIのアウトプットに第三者の知的財産が含まれる
• バイアス：アウトプットに差別的な内容が含まれる（人材評価において、人種や年齢などを理由に非合理的な低評価がつく、など）
• 有害性・安全性：アウトプットを実社会で利用したことで、人に危険を及ぼしてしまう（作業現場の安全性評価に生成AIを活用した結果、怪我につながる、など）

なかでも多くの企業が気にしているのがハルシネーション。認知度もかなりあがってきた印象があります。解決策は、こちらも注目されているRAGですよね。課題として認識され、対策が少しずつは進んでいる、のかな、という気がします。そして、そのほかの課題・リスクへの対策として鍵になるのが「責任あるAI」という考え方です。

責任あるAIについては、前のコラムでも紹介したのですが、AWSももちろんこれを重視しており、利用者に準拠してもらうように「責任あるAIポリシー」を用意しています。責任あるAIの8つのコア領域を実践するための指針……といったところでしょうか。これらはAWSのAIサービスを利用する際に適用されるのだそう。

責任あるAIポリシー　8つのコア領域

このポリシーのポイントは大きく3つ。まずは、生成AIサービスを利用するにあたっての責任は利用者にあるということ。生成AIを利用した意思決定や、生成AIのアウトプットにもとづいて講じた対策/講じなかった対策などは利用者が責任を負う……生成AIのせいにはしないでね、ということですね。

次は、重大な意思決定には人間が関与すること。生成AIによる自動化はいろいろと期待される領域ですが、重大な意思決定まで生成AIで自動化するのではなく、最後の判断では人が介在するフローにしましょう、という感じかなと。

最後は、禁止事項です。責任あるAIポリシーでは具体的な禁止事項が定められているので、これらに抵触しないように利用することが求められます。禁止事項としては、意図的な偽情報拡散や欺瞞行為、他人に対する危害・嫌がらせ、プライバシーの侵害、無断での他人の声・肖像の利用などが挙げられており、これらを第三者に促したり、こういった利用を認めるような使い方もNGです。あとは、基盤モデルにこのポリシーに違反する行為を促すこともダメですし、生成AIサービスの安全保護機能を意図的に回避するような使い方もダメですね。禁止事項と言われるとちょっと身構えてしまいますが、それほど違和感があるものではなく、「そりゃダメだよね」という内容かなと思います。

では、改めて、生成AIの課題やリスクに対処するにはどうすればよいのでしょうか？こちらもポイントは大きく3つあります。

まずは、課題に対応したアプリケーションを構築すること。これが基本というか、それは……当たり前では……という気持ちになりますが、大事なところ。最初から「危害を加える可能性はないか」「プライバシー侵害にならないか。個人情報を扱う可能性はないか」「重要な意思決定は人がおこなうフローになっているか」を意識してアプリケーションを設計するのも重要、ということでしょう。

そして2つ目は契約・規約・法令を遵守することです。このうちの「規約」がAWSの責任あるAIポリシーですね。契約は、AWSカスタマーアグリーメントが該当します。そして法令は、日本だと個人情報保護法、場合によって欧州のAI規制法への対応も必要かもしれません。これは、どこでサービス提供するかによっても変わるので、それぞれチェックが必要です。

そして3つ目に挙がるのがデータ管理でして、どうデータを保護し、利用するかがかなり重要になります。データ管理は「利用者の対応」と「AWSの支援」の2つ側面があり、さらに利用者側は「インプット管理」と「アウトプット管理」に分かれます。

ざっくりいうと、適切なインプットか、適切なアウトプットかを管理しよう、ということですが、まず適切なアウトプットを出すにはインプットの段階から注意する必要がある、と。たとえばアウトプットに個人情報が含まれてはいけないなら、インプットにも個人情報が入らないようにする、などの配慮が必要です。そのうえで、アウトプットにも同様の配慮に加えて、有害・違法な情報が含まれていないかなどをチェックする必要がある、というイメージです。

では、AWS側の支援は何をしてくれるのか。こちらも詳しく見ていきましょう。

まずはインプットとアウトプットの管理です。注意します、気を付けます……ではどうにもならないので、ここで使いたいのが「Amazon Bedrock Guardrail」。以前のコラムでも紹介したのですが、インプット・アウトプットを監視して、「個人情報を検知したらマスクする」などを実現します。あとは、銀行のカスタマーサービスチャットボットで、投資のアドバイスを求められたらブロックする、のような使い方もできます。これについては以前のコラムでも詳しく解説しているので、ぜひそちらも参照ください。

こちらは、秘密漏えいへの対応となりますが、Amazon Bedrockでは、プロンプトなどを含めインプット・アウトプットともに利用者のデータをモデル学習に使わないとされています。ちなみにAmazon BedrockではAWS以外の第三者が提供する基盤モデルも利用できますが、この「データがモデル学習に使われない」点はほかのモデルにも適用されるので安心です。

最後は知的財産権侵害への対策です。生成AIでつくった画像が、意図せずなにかの作品に似ていた！のようなことはあるはずですし、大きな問題につながりかねません。今も「あやうくない……？」みたいなことはあります。

AWSでは、生成AIのアウトプットに関して知的財産権侵害への補償があります。利用者がAWSの生成AIアウトプットを利用して、それにより第三者から知的財産権侵害の主張を受けたときに、その被害を補償する、と。おお！最近、そういうサービスが出てきているのは聞いていましたが、AWSでもやってるんですね。

ただし！補償には条件があります。たとえば、

• 利用者のインプットが他社の知的財産権を侵害していない
• アウトプットが他者の知的財産権を侵害する可能性を把握していない
• アウトプットの使用を停止する通知を受けていない
• サービスに関するAWSの指示に従っている（カスタマーアグリーメント、AIポリシーに違反していない）
• サービス利用にあたって契約違反を犯していない
• ガードレールを利用している

などです。つまり、最初から知的財産権を侵害させるようなプロンプトはもちろんダメだし、出てきたものがダメそうだと分かったまま使うのもNGです。あとは、ガードレールで適切にフィルターしていることも条件になるので、ここは気を付けたいところ。

「他者の知的財産権を侵害する可能性を把握していない」とかどうやって証明するんだ？という気はしますが、まぁ、まっとうな範疇かなという気がします。ここに挙げたのは、条件の一部なので、そのほかはきちんとご確認を。

ちなみに補償対象にはAmazon Lex、Amazon Qも含まれますが、Amazon BedrockはAmazon Novaのみが対象で、そのほかの第三者が提供する基盤モデルは対象外になります。基盤モデルごとにベンダーの補償が提供される場合がある、ということのようなので、こちらもそれぞれ確認が必須です。

もちろん、これらの補償内容や条件も今後変更される可能性があるので、その点はご注意ください。

生成AI活用が進めば進むほど、「おもしろいね」「便利だね」だけでは済まず、「良識の範囲内で」とも言っていられない感じになっていきます。リスクがあるのは分かるけど、どう管理すればいいんだ！というのは悩ましく、いっそ使わなければ……という悪魔のささやきもありますが、もはやそうも言ってられなくなってきました。どこまでどう実装すればいいのかは悩ましいところですが、ポリシーや各種支援、サービスがあるのは、ちょっと心強いはず。ちなみにソニービズネットワークスでは、生成AIに関する困りごとなどをエンジニアに相談できる「生成AI相談室」を実施しております。気になる方はぜひお問い合わせください。