LLMを搭載したプロダクトの品質保証の模索と学び

2025/9/8 QA Test Talk Vol.5

Transcript

1. © SmartHR, Inc. LLMを搭載したプロダクトの 品質保証の模索と学び @gonkm SmartHR 技術統括本部 品質保証部 レバレッジ推進ユニット 2025/9/8 QA Test Talk Vol.5 画像を置換
2. 中村 豪志(gonkm) 経歴 • QAEとして第三者検証会社と事業会社を 渡り歩き、2022年5⽉にSmartHR⼊社 • ⼊社後はアプリストア事業のQA→ 各プロダクトの脆弱性診断や⾃動化→ 2025年1⽉レバレッジ推進ユニットとして 活動開始 ⾃⼰紹介
3. 本⽇お話すること • LLMを搭載したプロダクトの品質保証について、 その初期アプローチでの模索と、得られた現時点での学びを 共有します ◦ AIを活⽤した品質保証‧テストの話はしません • 本⽇の話は「唯⼀の正解」ではありません ◦ あくまで、私たちの⼀事例、です。 ◦ 現在進⾏系の取り組み、です。 ◦ 何かしらのヒントや材料として持ち帰っていただければ嬉しい、です🙇 3
4. レバレッジ推進ユニットとは 部内の他ユニットや会社全体を対象として、 技術‧プロセス‧組織といった領域に レバレッジをかけることで、 SmartHR全体の品質向上を推進するユニット 4
5. レバレッジ推進ユニットとは 特徴 • 2025年1⽉に誕⽣したユニット • チーフ1名、メンバー2名の体制 • 前⾝のユニットではセキュリティエンジニアと脆弱性診断したりで セキュリティの知⾒すこしあり • 管掌プロダクトを持たず、組織と幅広く関わり合う 主な取り組み 1. 部⾨横断での品質向上へのアプローチ 2. AI活⽤プロダクトの品質保証⽅法の模索 5 今⽇はこの話をします！💪
6. もくじ 1. 背景と課題 2. アプローチと取り組み 3. 活動を通して得た学び 4. まとめと今後の取り組み
7. 背景と課題
8. 背景 • AI活⽤プロダクト開発の増加 ◦ 弊社でもAIを活⽤した プロダクト開発が活発化している • 責任あるAI活⽤の必要性 ◦ 社会的にも事業者への責任が強く が求められている 背景と課題 8
9. 背景と課題 部内の他ユニットや会社全体を対象として、 AI技術の品質保証といった領域に レバレッジをかける 9
10. 背景と課題 課題 • 社内にAI品質保証の体系化された知⾒は未整備 • AI品質保証は従来のテストとは異なる知⾒が必要 各ユニットの基盤となる情報や⽅法論の確⽴のため AI活⽤プロダクトの品質保証⽅法にレバレッジを かけていこう 10
11. アプローチ
12. 初期のアプローチ 12 まずは外部の専⾨知識をインプットを試みた • まずは「QA4AIガイドライン」など、外部の公開資料から 体系的な知識をインプット • 考慮軸やチェックリスト、品質特性まで書いてあるので これをベースに読み進めていけば⼤丈夫✌ • と安⼼したのもつかの間...
13. 13 「テスト」より「評価」 というワードが頻出... …結構ボリュームが どこから読み進める？ モデル、ファイン チューニング、MLや ⽣成AI、AI-OCR、LLM どこにフォーカス すればいいのか...
14. 有識者へのヒアリング 14 社内の有識者に助けをもとめる • Head of AI であるPMや実際に開発を⾏うPdEにヒアリング ◦ PM（プロダクトマネージャー） ▪ 社内の開発事例とロードマップ ▪ AI開発プロセス ▪ QAEとの連携の⽅向性 ▪ ドキュメント整備状況 ◦ PdE（プロダクトエンジニア） ▪ QAEへの期待や貢献できそうな箇所はどこか
15. 有識者へのヒアリング 15 PMのヒアリングでわかったこと • 社内の開発事例とロードマップ ◦ AI−OCRやLLMが中⼼で、AI−OCRは専⾨チーム、LLMは各開発チームが主体になる • AI開発プロセス ◦ 確率論的なアウトプットを扱うため、⼤量のテストデータ作成と精度評価が不可⽋ ◦ テストデータとAI出⼒の⽐較、スコアリングを⾏い、ビジネス価値に繋がるメトリク スを設定 ◦ OCRでは⽂字列の⼀致率、LLMではLLM as a Judgeによる採点などを⽤いて精度を評 価 ◦ 精度評価に基づき、リリース判断を⾏う • QAEとの連携の⽅向性 ◦ 根幹の精度評価は今はPdE中⼼だが、プロダクトの品質担保のリードはQAEが協⼒す る • ドキュメント整備状況 ◦ LLM評価指標に関するドキュメントが整備されていてた LLMが影響範囲が⼤きそ う 精度保証のための仕組み構築やソフトウェア 品質担保に協⼒できる可能性ありそう LLMが影響範囲が ⼤きいから？？ 何回も出てくる 精度評価⼤事かも 評価の指標ってタスクごとに 異なるのか
16. 有識者へのヒアリング 16 PdEのヒアリングでわかったこと • QAEへの期待や貢献できそうな箇所はどこか ◦ テストケースの作成、もしくはPdEが作成したテストケースのレビュー ◦ バグのチェック ◦ AI機能部分の負荷テスト ◦ AIに投げるデータ数が多い場合のテスト ◦ AIを使った機能の定性的な評価（⼈間の評価） ◦ AIを使った機能の定量的な評価（精度の点数化） ◦ プロンプトインジェクションなど、セキュリティ的に安全かどうかのチェッ ク ⼀般的なQAEへの期待がある パフォーマンステスト や負荷テストへの期待 過去に セキュリティテストは やってきたのでアプローチしやすそう 評価には定量と定性が あるようだ
17. PdEと現状の開発フローを整理し、必要なドキュメントやQA業務を洗い出す 17 有識者へのヒアリング
18. 18 ヒアリング による 意⾒交換 知識の インプット 期待や課題 最初に 取り組む スコープ インプットと対話で「本当に取り組むべきスコープ」を特定 • サイクルを通じ、全体の解像度を⾼める • 多くの課題から、貢献度‧レバレッジの⾼いスコープを特定する 有識者へのヒアリング
19. 貢献度‧レバレッジの⾼いスコープを特定 社内ヒアリングを実施してわかったこと（⼀部抜粋） 具体的なニーズ • LLMを使った機能の定性的評価（⼈間による評価）と 定量的評価（精度の点数化） • 💡プロンプトインジェクションなどのセキュリティ観点でのチェック • AI機能部分の負荷テストや、⼤量データを扱う場合のテスト 期待される役割 • 💡精度保証のための「仕組み作り」やソフトウェアとしての品質保証の⽀援 • 継続的な情報連携を通じて、AI開発プロセス全体に関与 • PdEが主導する精度評価の⽀援 • 統⼀的な評価基準 19 ニーズとユニットの既存スキル（セキュリティテスト 経験）で強みを出せそうな箇所で価値提供 迷わず、かつ効果的にAI活⽤プロダクトの 品質保証に取り組めるようなその基盤となる考え⽅や 具体的な⼿法の調査‧整理
20. AI品質保証におけるLLM領域への集中 組織全体への影響範囲の⼤きいLLM領域に注⼒ • LLMは⽂書⽣成や要約、分類など多く利⽤され、LLMプロバ イダーのAPIを使うことで、⽐較的容易に実装できるために、 取り組むプロダクトも多い • AI-OCRなど他のAI技術もあったが、取り組みの初期段階とし ては、限られたリソースを集中させることにした 20
21. 取り組み
22. 取り組み   22 1. 技術検証と実践 ◦ 調査で得た知識を実プロダクト に適⽤し、有効性を確かめ、 実践的な知⾒を獲得する 2. ドキュメント化 ◦ 検証で得られた知⾒を共有し、 他のチームがAI品質保証に 取り組む際の初速を上げる プロダクト での実践 実践知の 獲得 ドキュメン ト化 🔁 調査で得た 知識 「技術検証と実践」のプロセス
23. 技術検証と実践 ① 23 プロダクトへのQA⽀援 • 担当QAEからの相談をきっかけにテストに参加 • LLMの特性を考慮したテスト観点を提⽰‧適⽤ ▪ キーワードのみの曖昧な⼊⼒（想定外の返答を推論しないか、ハル シネーション発⽣しないか） ▪ ⻑過ぎる⼊⼒（⼊⼒制限があるのでその中で意味のある⽂章） ▪ 専⾨⽤語を含んた⼊⼒（特定のドメインに詳しいユーザの利⽤にな る場合を想定でユーザーのリテラシに応じた返答か） ハルシーネーション：事実に反する情報や、本来存在しない情報を⽣成してしまう現象
24. 技術検証と実践 ② 24 AIセーフティレッドチーミングの部分的実践 • ユニットのセキュリティ知⾒を活かすアプローチ • 「AIセーフティに関するレッドチーミング⼿法ガイド」を参照し ⾃社プロダクト（RAG利⽤）に対して攻撃シナリオを実施 • ガイドの内容を習得しつつ、有効性や⼿法の取り⼊れやすさを確認 AIセーフティに関するレッドチーミング⼿法：AIシステムの開発者や提供者が、対象のAIシステムに施したリスクへの対策を攻撃者の視点から評価 するための⼿法 RAG：LLMが外部の最新情報や専⾨知識を参照し、回答の正確性を向上させる技術
25. ドキュメント化 技術検証や実務経験に基づくサポートコンテンツの整備 • LLMアプリの品質保証を始めるための基礎知識まとめ ◦ 基礎知識習得の⾜がかりとして⽤意 • LLMアプリにおける評価とテストの考え⽅と⽅法 ◦ 精度「評価」とソフトウェア「テスト」の⽬的や効果を整理 • LLMアプリのマニュアルテストについて ◦ 定性的なテストの重要性と具体的な指針や⼿法について掲載 25 変化の早いAI分野では、細かい部分まで書くのではなく、概念や根本的にぶれない部分に集中してドキュメントを作成する⼯夫が必要
26. 活動を通して得た学び
27. 活動を通して得た学び 💡学び① 「評価」と「テスト」という2つの活動を整理する • 評価 (Evaluation) ◦ LLMの応答品質（⾃然さ、正確さ、有⽤性など）の良し悪しを測定‧判断する ◦ 定量的評価（精度の点数化）と、それだけでは判断できない部分の定性的評価 両⽅を実施 • テスト (Testing) ◦ プロダクト全体が要件や仕様通りに動作するか、バグがないかを確認する ◦ 妥当性確認の観点で、「評価」と⾼レイヤの「テスト」が重複することもある 両者の特徴を理解し、どこで何を確認するのか、を検討する 27
28. 💡学び② QAEの役割定義 • 社内状況把握から、PdEは既にLLMの精度評価（評価指標、 プロンプトチューニング、LLM as a Judgeなど）へ⾼い知⾒を持ち 実践していたことがわかった • そこで、⾃分たちだからこそ貢献でき、成果を最⼤化できる領域、つ まりのソフトウェアテストの専⾨性を活かせる部分や、 新たなセキュリティ領域での⽀援に注⼒することにした • PdEの専⾨性を尊重しつつ、補完関係を築くことが、 現時点でチーム全体で効果的なアプローチ 活動を通して得た学び 28
29. 活動を通して得た学び 💡学び③ 「評価基準」をチームで決める重要性 • LLMの評価は、単純な合否やスコアだけでは判断できない • プロダクトの⽬的に応じた「評価基準」の定義が不可⽋ ◦ 例：許容する品質レベル、定量的評価のスコアの閾値など • 評価基準は、PMやPdEなど関係者との議論し検討する • リリース後もオンライン評価で継続的に⾒直し‧改善が必要 29 オンライン評価：リリース後に実運⽤環境で、実際のトラフィックに対して評価を⾏う⼿法。リリース前に⽤意したデータセットで⾏なう評価はオ フライン評価という。
30. まとめ
31. まとめ 31 私たちの模索と実践 1. 課題認識 ◦ 組織的なAI活⽤プロダクトの増加と、技術的な品質保証⼿法の未整備という状況 から、新たな品質保証の基盤を構築する必要があった 2. アプローチと実践 ◦ 外部情報の体系的な収集と、社内ヒアリングによる現状把握を実施し、スコープ をLLMに絞った ◦ 実プロダクトへのQA⽀援やAIセーフティに関する技術検証を⾏い、得られた知⾒ をドキュメントとして整備した 3. 得られた学び ◦ 実践を通して、「評価」と「テスト」の活動を整理すること、開発者との役割を 定義すること、そしてプロダクトに応じた「品質基準」をチームで合意形成する ことの重要性を学ぶ
32. 今後の取り組み‧挑戦
33. • 実践の継続と活きた知⾒の体系化 • 実践的な⼿法の構築 ◦ LLM固有の特性やセキュリティを確認するための汎⽤的な確認観点 ◦ ツールを利⽤した⾃動検査 • 精度評価の⽀援の模索 ◦ 指標の明確化 ◦ 統⼀した基準の検討 ◦ 妥当なスコアを判断する考え⽅の整理 ◦ プロンプト改善への積極的な関わり • ペアでの指導やナレッジトランスファーができるような体制の構築 今後の取り組み‧挑戦 33
34. We are Hiring! ⼀緒に活動するメンバー募集中です まずはカジュ⾯おねがいします󰢛 34 カジュ⾯ 採⽤情報 https://open.talentio.com/r/1/c/smar thr/pages/103040 https://youtrust.jp/recruitment_post s/330efbd68714fe977c172e1258026b d5
35. ご清聴ありがとうご ざいました! 35
36. Appendix AIプロダクト品質保証ガイドライン https://github.com/qa4ai/Guidelines/blob/main/QA4AI.Guidelines.202 504.pdf 機械学習品質マネジメントガイドライン https://www.digiarc.aist.go.jp/publication/aiqm/AIQuality-requiremen ts-rev4.2.0.0113-signed.pdf AIセーフティに関するレッドチーミング⼿法ガイド https://aisi.go.jp/assets/pdf/J1_ai_safety_RT_v1.10_ja.pdf LLMの精度ってどう測るの？評価指標を調べてみた https://tech.smarthr.jp/entry/2025/08/05/192115 36