LLMアプリの品質保証

Transcript

1. LLMアプリの品質保証 ～LLMの特性から全体像まで～ 2026.2 1 水谷 太一（くつしたいぬ） @dog_dog_3dog
2. 勉強会のスコープ 2 この講演の対象者 LLMアプリの品質保証に 興味がある方 LLMアプリの開発に関わる方 AIの品質保証の領域を 学びたい方 得られる知識 AI独自の品質特性 AIを使った製品の全体的な品 質保証のイメージを掴める リスク分析の手法
3. 3 01 02 03 04 COMPASからのケーススタディ LLMアプリ独自の品質特性 リスク分析 LLMアプリ全体の品質保証 流 れ 背 景 産総研主催の「AI品質マネジメント講座」を受講した際の知見を基に、 社内展開用として本勉強会を企画しました。 URL https://www.digiarc.aist.go.jp/event/aiqm-course/
4. 4 C O M PA S か ら の ケ ー ス ス タ デ ィ
5. • アメリカで広く使われた再犯予測システム • 機械学習を使って137の質問から1-10のリスクスコアを算出 • 保釈金・量刑・仮釈放の判断に影響 出典: https://edu.isc.chubu.ac.jp/hsuzuki/iip/DataScience/ethics/ethics2.html Wikipedia "COMPAS (software)" https://en.wikipedia.org/wiki/COMPAS_(software) COPMASとは？ 5
6. 再犯リスク判定の偏り 6 2016年ProPublica調査：7,214人を分析 人種による偽陽性の偏り （再犯しないのに「高リスク」と判定） 黒人の誤判定率 44.9% 白人 23.5% 実例： 軽犯罪歴ありの18歳黒人女性が自転車盗難未遂で「高リスク」判定 （実際は再犯なし） 41歳白人男性が武装強盗歴ありで窃盗「低リスク」判定 （実際は7700ドル窃盗で再犯） 出典: ProPublica “How We Analyzed the COMPAS Recidivism Algorithm” (2016) https://www.propublica.org/article/how-we-analyzed-the-compas-recidivism-algorithm 事例: ProPublica "Machine Bias" (2016) https://www.propublica.org/article/machine-bias-risk-assessments-in-criminal-sentencing
7. 偏りが生じた理由 7 137の質問： 人種は聞かないが... 評価する項目 貧困・失業・居住地域・家族の犯罪歴 → これらは構造的に人種と相関 アルゴリズムでの中立性 ≠ 社会的にみたときの公平性
8. 問題の核心：社会的文脈の見落とし • 再犯予測システムCOMPASが黒人被告に対して不公平と取られかねない判定を出していた • 社会的な差別を再生産していると取られる結果となった • 技術的な精度だけでなく、社会的影響を考慮する必要があった もし適切なテストをしていたら • 公平性の観点を含めたテスト設計により問題を早期発見できた可能性 ex:人種間での結果の差異の検証など 問題に発展したAI関連の事例は他にも多数存在する 人事評価、画像判定etc… COMPASSの事例が示す教訓 8
9. 1. AIの非決定的な振る舞い • AIの出力する結果は非決定的で、何が応答として返ってくるかわからない（すべてのパターンをテスト することは不可能） • 同じ入力でも異なる出力が生成される可能性がある 2. 変わらない責任 • 出力結果に問題がある場合は説明責任や法的責任を問われる可能性がある • AIの特性を理由に責任が免除されることはない AIの品質保証をしていくためには • 開発時点からAIに求められる品質特性を理解する必要がある • LLMの特性を踏まえた仕様レビュー、テスト設計が重要 AI独自の品質保証が必要な理由 9
10. 10 L L M ア プ リ 独 自 の 品 質 特 性
11. • この章の内容は生成AI品質マネジメントガイドラインを引用、参考に作成しています 弊社では生成AIの他社基盤を利用しての開発がメインのためこのガイドラインを利用 日本語のガイドラインはだいたい読んだが、個人的にはこれが一番体系的にまとまっている印象 • 今回の内容はとっつきやすくなるようにわかりやすさを重視 ガイドラインそのものを読むより簡略化されている箇所があります 生成AIに特化したところを抽出しているため省略した項目があります ガイドラインによって、内容に差異があるので、 詳しく知りたい場合は色々なガイドラインを読んで自分の好みのものを見つけるのが吉 引用、参考文献:産総研. 生成AI品質マネジメントガイドライン.2025. https://www.digiarc.aist.go.jp/publication/aiqm/ おことわり 11
12. これから、10個の品質特性と、そのサブ特性を紹介します（生成AI品質マネジメントガイドラインより） • 機能要求満足性 • 信頼性 • インタラクション性 • セキュリティ • 安全性 • プライバシー • 公平性 • 性能効率性 • 移植性 • 保守性 品質特性の一覧 12
13. 機能要求満足性とは • 明示的な機能要求を満たしているかどうか 仕様書や要求定義書に明記された具体的な要件の実現 • 暗黙的な機能要求が満たせているか 社会的・倫理的な期待、常識的な振る舞いへの対応 • ソフトウェアの要求を満たすように設計されているか システムアーキテクチャレベルでの要求実現の考慮 • エンドツーエンドでの定性的評価に問題がないか 部分的な評価ではなく、システム全体としての品質確認 機能要求満足性 13 システムが、システムへの要求を満たしているか AIの応答品質の精度という観点が当てはまるのはここ
14. 信頼性とは • ロバスト性（堅牢性） 想定外の入力への耐性 基準となるデータから外れた入力に対して応答の一貫性を保てるか 外れ値が入力されたとき、システム全体の安定性が保てるか • 出力一貫性 同一入力に対する出力の整合性 ユーザー体験の一貫性 信頼性（1/2） 14
15. 信頼性とは（つづき） • 可用性、耐故障性、回復性 継続的な運用可能性 障害時の適切な振る舞い 信頼性（2/2） 15 補足） 一般的なシステムでも求められる要素だが、AIの場合は計算資源やRate Limitなど、特有の事情もあるためその点の考慮が必要となる場合もある AIには不確実性を含みながらも信頼できる動作が必要
16. インタクラクション性とは ユーザーが思った通りに使えるかどうか • 適切度認識性 ユーザーが自身の期待する用途にLLMアプリが適切かを判断できること システムの能力と限界を明確に伝え、できることできないことを明確にする必要がある 例: 「このAIは一般的な質問には答えられますが、専門的な医療診断はできません」などの注釈 • 可制御性 ユーザーによる動作制御ができること LLMが過剰に何かをしようとしたときに、ユーザーがLLMを制御できるか 例:エージェントシステムで、操作前にユーザーに確認 回答生成中に、回答の出力を停止できるUIがある、などの制御の動線 インタラクション性（1/2） 16
17. • 説明性 生成されたコンテンツの生成理由についての提示が行われているか ユーザーがLLMの判断根拠を理解できるか RAGシステムの例 - 生成元となった情報源の提示 - 使用した情報の関連度や信頼性の表示 もし仮に説明が何もない場合、ユーザーはLLMの判断の根拠がわからない • 習得容易性 使い方が容易に習得できるか インタラクション性（2/2） 17 制御、説明性などこれまでと違った導線や情報提供が必要になる場合がある
18. セキュリティ • アクセス制御性 システムプロンプト、LLMモデルなどへのアクセス権が適切に設定されていること ユーザーデータが適切に管理されていること • 真正性と責任追跡性 入力元の確認（プロンプトインジェクション対策） LLMが過剰に何かをしようとしたときに、ユーザーがLLMを制御できるか 出力の生成理由の追跡可能性 監査ログの適切な記録 セキュリティ（1/2） 18
19. • 介入性 稼働中のアプリに介入できるようになっていること 例:システムを監視して、不正な挙動をするドメインがあったら止められる 必要に応じて、システムを意図的に停止できる、など • LLMアプリ独自で必要なセキュリティ対策は様々 プロンプトインジェクション攻撃への対策 生成コンテンツの悪用防止 データ漏洩とプライバシー保護の両立 などなど セキュリティ（2/2） 19
20. 安全性 • 入力制限性 危険な入力が適切にフィルタリングされているか • フェイルセーフ性 故障時であっても安全性が毀損されないこと エラー発生時に適切に処理とフィードバックが行われること • 否認防止性（AI透明性） AI生成コンテンツであることが明示されているか 例: 電子透かしやメタ情報による、なりすまし防止がされているか 出力がAIによるものであることを外部にわかる形で提示しているか 安全性（1/2） 20
21. 安全性を考えるポイント 製品の文脈に応じて安全性を設計する • 安全性は状況次第 ・状況に応じて求められる安全性の度合いは異なる 例:ガードレールの設定を子供向けは厳格に、大人向けは柔軟にする • これまでになかったリスクにも気を配る 出力によっては、権利侵害が起きるリスクもある 例:著作権やプライバシーなどを意図せず侵害するリスク 安全性（2/2） 21
22. プライバシー • 想定外の情報プライバシーの漏洩が発生しないこと 利用者のデータ 学習時に利用したデータ（プライバシー、著作権を含むものを学習していた場合） 公平性 • これまでになかったリスクにも気を配る 要配慮属性を含むデータの取り扱いに関して想定外の偏りが起きないこと 要配慮属性:社会的に配慮が必要とされる属性のこと 要配慮属性の違いによって、出力コンテンツに影響が起きないこと データが明示的に要配慮属性を持つ場合もあるし、データ処理の過程で要配慮属性 に相当する情報が付与されることもある 何が要配慮属性になるかは作る製品によって違う プライバシー・公平性 22
23. プライバシー • 想定外の情報プライバシーの漏洩が発生しないこと 利用者のデータ 学習時に利用したデータ（プライバシー、著作権を含むものを学習していた場合） 公平性 • これまでになかったリスクにも気を配る 要配慮属性を含むデータの取り扱いに関して想定外の偏りが起きないこと 要配慮属性:社会的に配慮が必要とされる属性のこと 要配慮属性の違いによって、出力コンテンツに影響が起きないこと データが明示的に要配慮属性を持つ場合もあるし、データ処理の過程で要配慮属性 に相当する情報が付与されることもある 何が要配慮属性になるかは作る製品によって違う プライバシー・公平性 23
24. 24 リ ス ク 分 析
25. 実際のテスト戦略をどうやって考えていくか？ • 品質特性だけを理解していても、それを実際のプロダクトのテスト戦略に落とし込むには別のやり方が必 要 • この勉強会では、一つのやり方としてリスク分析を紹介します • リスク分析の何がLLMアプリのテスト戦略を考えるのに向いているの？ • 製品にあるリスクと優先度を整理 • 整理したリスクに対応したテストと、テストの優先度が決めやすい • 予測できない要素が大きいLLMアプリだからこそ、リスクを同定することが効率的なテストにつなが る・・・かも リスク分析～LLMアプリのテスト戦略策定の一助に～ 25
26. 基本の流れ 1. リスクをリストアップ（考えられるリスクを洗い出す） 2. 各リスクの発生確率、影響度を評価 3. マトリクス上にプロット リスクマトリクスとは？ • 横軸：発生可能性（低・中・高） • 縦軸：影響度（軽微・中程度・重大） • 9つのセルで優先度を可視化 ※解説しているものによってマトリクスの取り方は違う AI品質での適用例 過度に利用され、想定以上にコストがかかるリスク⇨Rate Limitの導入、テストが必要 リスク分析の基本 26 発生可能性 → 影響度 → 低 中 高 軽微 中程度 重大
27. 27 L L M ア プ リ 全 体 の 品 質 保 証
28. ここまでの振り返り AI特有の品質特性について見てきました 実際のプロダクトの形 • サイボウズでは、LLMをUIでラップして提供 • ユーザーが触るのはWebアプリやモバイルアプリ • LLMの機能はシステム全体の中の一部にすぎない 製品全体で必要な品質とは？ • LLMだけをみた品質保証では不十分⇨システム全体の品質も考えるがある • 従来のソフトウェア品質＋LLM部分の品質で製品はできている LLMアプリの品質保証は、LLMだけを見ればいいとは限らない 28 AI品質とシステム品質、両方の視点が必要
29. LLMアプリの開発のパターン 29 パターン1：自社でAI基盤を開発 • モデルの学習から推論まで自社で実施 • フルコントロール可能 • OpenAI、Anthropic、Google等 特徴 ✓ データの完全管理/品質が自社で全て完結 パターン2：他社のAI基盤を利用 • OpenAI、Anthropic、Google等のAPI利用 • 基盤モデルをそのまま/プロンプトで調整 特徴 ✓ 品質保証でできることが限られる ✓ プロンプト/ファインチューニング RAGの重みづけetc ✓ 手が出せる範囲は狭い サイボウズはこっち
30. システム全体を見た時のLLMの品質ってどこでしょうか？ 30 既存のアプリケーションから、新機能のLLMアプリを呼び出す場合の一般的な構成
31. LLMの品質として語られる部分は、システム全体からすると小さい範囲 31 赤い丸で囲んだ範囲が、LLMの品質として前半で述べたところです 丸で囲んでいない範囲は、LLMのテストをするだけでは確認できません
32. AI独自の品質は全体の一部でしかない • APIの品質、UIの品質などLLMから独立した各コンポーネントの品質は依然として求められる • コンポーネントの品質だけでなく、互換性、性能など、従来の品質特性は保証し続けないといけない ※参考として見てもらうといいかも JIS25010だとたくさんの品質特性が列挙されていますが、LLMアプリであってもそれらの品質特性は依然 重要です。 LLM独自の品質は製品全体の一部でしかない 32
33. AIの応答品質のテストには多様な観点がある • LLMアプリの品質保証というと、AIの応答品質のテストが真っ先に考えられがち • だが、応答の精度以外にも多様な観点がある（信頼性、公平性、安全性etc） • 応答品質のテストには精度だけでなく多様な観点を組み込む必要がある LLMの品質は、応答品質だけじゃない • 応答品質はLLMの数ある品質のうちの一つでしかない • LLMの品質全体を見た時に、他にもたくさんの品質が求められている（性能効率性、セキュリティetc） LLMの品質とは別に、システム全体の品質が存在する • LLMの品質保証は、LLMアプリの品質保証とイコールではない • 既存のソフトウェアに求められる品質は保証し続ける必要がある 今日一番お伝えしたいこと 33
34. 図でまとめてみると。。。 34 システム全体の品質をAIの部分と従来の品質保証の部分両方で作っている
35. 今日見てきたこと • LLM独自の品質特性 • LLMアプリの構造の全体感 これまでのテストと違うところ • AIの振る舞いは非決定的 • LLMアプリにはこれまでなかったリスク、品質特性がある 伝えたいこと • AI独自の品質特性と同じくらい、従来のシステム品質も重要 まとめ 35 応答品質だけに目を向けずに、システム全体をみる視点が大切
36. ©️ Cybozu, Inc. 36