生成AIでテスト設計はどこまでできる？ 「テスト粒度」を操るテーラリング術

2025/12/06
ソフトウェアテスト自動化カンファレンス2025
https://testautomationresearch.connpass.com/event/361747

アーカイブ動画はこちら
https://youtu.be/RcHGNePT8no

#ソフトウェアテスト自動化カンファレンス2025 #STAC2025

Transcript

1. 生成AIでテスト設計はどこまでできる？ 「テスト粒度」を操るテーラリング術 エムスリー株式会社 草場翔太
2. 自己紹介 • 草場翔太 / Shota Kusaba • QAエンジニア ◦ 担当プロダクトの品質計画作成、テスト実施、自動テスト作成 ◦ 全社横断したQAでの生成AI活用 • 2025年5月入社 • 前職はSIerで金融系のSE＋パッケージ開発 • Claude Codeがメイン
5. 裁量の大きな多数のチーム エムスリー 経営会議 ・ Unit1 MR君 ・ Unit3 新領域 ・ Unit4 サイトプロモ ・ Unit5 コンシューマ 各チームエンジニアは平均6名程度 採用チーム 取締役 CPO/CAIO 山崎 聡 マネジメントチーム GM、HRBP、技術顧問と共に活動 事業チーム（9） 横断チーム（10） ・ Unit6 キャリア ・ Unit7 BIR ・ Unit9 治験 ・デジカル ・デジスマ ・ SRE ・ 基盤 ・ マルチデバイス ・ AI機械学習 ・ グループ会社支援 ・ セキュリティ ・ QA ・ グローバル支援 ・ プロダクト支援 ・ データ基盤 5 ゼネラルマネジャー VPoE 河合 俊典 ゼネラルマネジャー CTO 大垣 慶介
6. 詳細はこちら
8. 目次 • AIとテスト設計の現状 • 自動化事例１：テスト対象分析に使うテストベースの 収集と分析の自動化 • 自動化事例２：必要十分で過剰でないテストケース作成を 自動化 • 今後の課題・Tips
9. AIとテスト設計の現状
10. AIで変わるQA活動 • AIの活用が当たり前になり、テストの設計も自動化の対象としてチャ レンジしやすくなった ◦ テスト実行→テスト設計 • 多くの組織でテストケース作成の取り組みが進められている • エムスリーのQAチームでも活用を推進中
11. エンジニアリンググループでのAI活用 • 2023年以降、生成AI関連のツールを積極的に活用 https://speakerdeck.com/vaaaaanquish/llmgaji-jie-xue-xi-fen-ye-tota-fen-ye-niqi-kositakiyazumukarajian-ji-meruenzinianowei-lai-xiang?slide=7
12. QAチームの立ち位置 プロダクトA PdM エンジニア QA デザイナー プロダクトB PdM エンジニア QA デザイナー • 各プロダクトチームに QAが所属 • テストは内容によって エンジニアとQAの どちらで行うか 振り分け「全員QA」 • ＋横串のQAチームで 全社課題に取り組む QA チーム
13. 開発プロセス • 週１回リリース • QAはリリース予定の機能のシステムテストを実施 • 必要に応じて機能グループやシステム全体の品質計画を検討 • ユニットテストは開発エンジニアが作成、E2EテストはQAが作成 • 全員QA　開発エンジニアもテストする
14. 全員QA • テスト活動にチーム全員で取り組む • 開発エンジニアからテスト実施担当の振り分け相談をもらう • QAは開発内容をみて開発エンジニアとQAのどちらが テストをするか振り分ける • 詳しくはエムスリーTechブログをご覧ください ◦ m3.com における全員 QA への取り組み ◦ https://www.m3tech.blog/entry/2025/06/09/170000
15. 全員QAのプロセス エンジニア QA • 各エンジニアが 担当バックログを開発 • 全員QA：開発内容で テスト担当を振り分け ◦ シンプル・軽ければ　　　 エンジニアで実施 ◦ 複雑・重ければ　　　　 QAで実施 週１回 リリース 開発 テスト QA 開発内容を確認 テストケース検討 担当を振り分け
16. QAが振り分け時に苦労していたこと • 開発内容を確認 ◦ テストベースの収集が大変 ▪ Confluence・Figma・Github、変更要件・注意点・過去の不具合 ◦ 開発内容の理解が大変 • テストケース検討 ◦ 都度、収集したテストベースとQAの観点資料を組み合わせて検討 QA 時間がかかる作業 複数の依頼が同時に来ると頭の切り替えも大変だった
17. AIで振り分けとテスト設計を効率化したい • 速やかに振り分け判断することが、高回転な開発プロセスに繋がる • エンジニアを待たせずにテスト対象分析と設計を終わらせて 振り分け連絡したい
18. まずはラフに使い始めた • リリース予定の機能について、テストケースを作成してみた。 • 『Hello Claude, この機能のテストケースを作成して』 　 –ConfluenceのURL
19. ラフに使い始めたら…使いこなすのが大変だった • 大量のテストケースを提案してくる ◦ 同値分割できているとは言い難いケースを提案 • 省いても良さそうな観点も省略せずに全て提案してくる ◦ 大量データでの検証や高セキュリティの検証など、実施コストとのバランスを考慮して計画 的に実施するテストを、毎回含めてくる • 存在しない機能に対してのテストを提案してくる ◦ 一般的にありそうな機能を挙げて、テスト対象に含めてしまう • システム特有のエッジケースや注意点の考慮が甘い 参考にはなるが、そのまま使いにくい箇所が多く、 QAエンジニアの手直しが大量に必要な叩き台レベル
20. • QAはプロセス全体で品質確保する活動なので、 開発プロセスの色々な箇所で色々な方法で品質を確保している ◦ 必ずしも週1回のリリース時のシステムテストというタイミングで　　 テストすることが最適でないテストも、含んで提案されている うまくいかなかった理由を考察
21. • QAは経験や知見を積み重ねて使う活動なので、 ◦ 追加仕様内容や最新コード状態だけからテストを作るのでは無く ◦ 現在は修正済みだが過去に発生した不具合や、 ◦ 普段の設計では意識しきれない特殊なシステムの使い方や　　　　　　 データの状態も理解してテストしなければいけない ◦ AIにその状態が渡せていない。 ◦ もしくはアクセスできるようになっているが実際には使用されていな い。 うまくいかなかった理由を考察
22. • 生成されたテストケースが実際の開発フローに合わない ◦ テストケースが多すぎる ◦ 荒すぎる • 実際に使えるようにQAの手直しが必要 ◦ QAでの作業不要にしないと、開発者に使ってもらいにくい ◦ QA自身で使う場合でも、手直しが大変で使われない • (使わないと)AI活用のノウハウが貯まらない 素のAIだけでは、まだ現実的には活用しにくい
23. チームの利用場面に合った内容で出し分けたい エンジニア QA QA 開発内容を確認 テストケース作成 担当を振り分け チームの利用場面に合わせた内容で出せば 手直し無く・すぐに使えて・また使いたくなる • シンプル・軽いテスト • 実施が必要なテストだけを箇条書きしてあ ると使いやすい • テスト対象機能の解説は不要 • 複雑・重いテスト • テスト対象分析のプロセスも明記して妥当 性を確認したい • テスト対象機能の解説も欲しい
24. • そういえば昔プロジェクトマネジメントの勉強をしていた時、 「チームに合わせて最適化する」という手法を見た気がする ◦ ”テーラリング”だった チームの利用場面に合わせるといえば…
25. • 利用者、利用タイミングに応じた使い分け ◦ テーラリング 服のサイズやデザインを個人の体に合わせて調整すること ◦ PMBOKにおけるテーラリング ▪ プロジェクトの状況や環境に合わせて、PMBOKの管理方法・プロ セス・ツール・成果物などを調整・最適化すること。 ▪ 画一的な方法を適用するのではなく、プロジェクトの特性に合わせ て柔軟にカスタマイズすること ◦ 今回の文脈では、重厚長大に網羅したテストケースを使うのではなく、 状況に適したケースや資料構成になるように調整すること ”テーラリング”とは？
26. • “テーラリング”というワードは、 ◦ 「全社の標準的プロセスを、プロジェクトに合わせて最適化する」とい う文脈で大企業などで使われることが多いですが、 ◦ エムスリーのようなスタートアップにおいても、　　　　　　　　　 「小さなチームの中でも利用場面に応じて最適化する」という文脈で、 今回の発表で用いています。 補足
27. • テスト対象分析に使うテストベースの収集と分析の自動化 • 必要十分で過剰でないテストケース作成を自動化 取り組んだテーラリング適用
28. 自動化事例１：テスト対象分析に使うテストベースの 収集と分析の自動化
29. • 機能要件、ユーザーストーリー：Figma • 画面デザイン：Figma • 設計方針：Confluence • 実装、テストコード：Github • 過去に発生した不具合：Confluence • 既存のテスト環境やデータ：AWS • エッジケース　普段の設計では意識しきれない特殊なシステムの使い方やデータ の状態：Confluence • 既存のテスト成果物（テスト対象分析、テストケース、テスト観点一覧、ガイド ワード）：Confluence 必要なテストベース
30. 「AIがアクセスできる」だけでなく 「高速に完了できること」を意識 テストベースをAIReadyに整備
31. • Figma,Confluence,Github・AWSは、MCP・API・CLIでアクセスできるように 事前に設定 • AIの作業時間を最小化する　　　　　　　　　　　　　　　　　　　　　　　 （情報取得にかける時間は積み上がると無視できない） • Confluenceに点在する仕様や不具合対応歴を機能カテゴリや観点で整理した　　 インデックスページを作成 • Figmaのアイテム構造や効率的な探し方を明文化 • Claudeのカスタムスラッシュコマンドで、テストベースを収集・分析する • 同機能のSubAgentsも作成していて、利用しやすい方を選ぶ テストベースをAIReadyに整備
32. Claude カスタムスラッシュコマンド例
33. Claude カスタムスラッシュコマンド例
34. • 実装内容の解説 • UMLの作成（フローチャート、シーケンス図） • ユニットテスト、E2Eテストのテストコード実装状況 実現できた自動化
35. コマンド実行から5分でAIの分析資料作成が完了 QAがテスト対象分析にかける時間は1/3以下に大きく削減 自動化の効果
36. 自動化事例２：必要十分で過剰でないテストケース作 成を自動化
37. • ClaudeCodeルールに記載 ◦ テスト対象分析でハルシネーションがあれば、　　　　　　　　　 テストケース作成させない ▪ 存在しない機能に言及している等 ◦ テスト対象分析がしっかりと書かれていることは、　　　　　　　 QAがテストケースの妥当性を確認する時に重要な資料。 ▪ これが無いとケースの検証ができない。 自動化の方針
38. • ClaudeCodeルールに記載 ◦ テスト作成時は、システム特有の使い方やエッジケースを参照させる ▪ 重要な機能グループは、QAが事前にテスト観点一覧や　　　　　 テストケース資料を作成している ▪ 該当する機能のテストでは、必ず資料を踏まえた言及をさせて　 抜け漏れさせない 自動化の方針
39. • ClaudeCodeルールに記載 ◦ 開発プロセス全体の品質活動と照らし合わせて、　　　　　　　　 不要に過剰にテストしないようにする ◦ 自動作成するテストの種類を決めておく ◦ ◎：機能適合性の正常系、準正常系 ◦ △：セキュリティ、ユーザビリティ 自動化の方針
40. • これらのテストケースはAIで積極的に自動作成 ◦ 正常系、準正常系（想定される異常状態のケース） • 正常系と準正常系は機能要件やデザイン設計に詳細に定義できていること が多く、AIからアクセス可能であれば抜け漏れなく抽出できる • フローチャートやシーケンス図を活用して、状態やパスの網羅 • 事前作成した観点一覧やガイドワードを組み合わさせる • システム特有の観点：「前回利用時の問診データがある場合の表示は…」 • - ガイドワード：「短い間隔（連続）で…、長い間隔で…」 ◎：機能適合性の正常系、準正常系
41. (今後の課題でもありますが) 現時点では丁度良い粒度のケースを出せないため、観点の列挙に留めている • セキュリティ ◦ AIはセキュリティ観点を重要度大・必須として多数提案しがちな印象 ◦ 実際に提案される観点はシステムテスト以外のプロセスで　　　　　　　 担保されているものが多いが、AIに上手く情報を渡せていない（課題） ◦ コードレベルの基本的な観点はコードレビューやCIで担保 ◦ 別途テストが必要な、高リスク機能領域（診察・薬・金銭）に　　　　　 該当するかを言及させる。QAで内容確認して判断。 △：セキュリティ
42. (今後の課題でもありますが) 現時点では丁度良い粒度のケースを出せないため、観点の列挙に留めている • ユーザビリティ ◦ AIからのテストケース提案も曖昧な内容に止まることが多く、　　　　　 明確な基準・指標でテストするには至っていない ◦ 別途、QAエンジニアが探索的テストを実施することが多い △：ユーザビリティ
43. • 長い状態遷移 ◦ 0件時 → 1件 → 複数件 → 削除して1件… ◦ 複数のステータスを経由する複雑なフロー • 逸脱行動を含むシナリオ ◦ パスの途中で戻る、離脱して復旧 ◦ 意図的にエラー状態を作り出してから回復 • 探索的テストをやることでケースに気づくこともあり、今後も一定残る • AI実行が複雑でも安定して高速に動作するようになればいずれは… QAによる実施が残っている領域 - 探索的テスト
44. 今後の課題・Tips
45. • そもそもMCP経由で情報収集すること自体が速度のネック ◦ AIが直接利用可能なローカルドキュメントやRAGの利用を検討 • 自動化△→◎に変えていきたい ◦ ペルソナ・ユーザーストーリーからデザインやフローの使用性評価 ケースに派生させるなど • システムテストを自動化したいが、PlaywrightMCPでの実行が遅い ◦ 速度改善して、AI自動テストの割合を上げたい • 人手が前提のテスト配分ではなく、AIによるテストが前提のテスト配分に 根本的に変えていきたい 今後の課題
46. • 生成AIによるテスト設計を活用するには、チームの開発プロセスに合う　 テスト種類・ケース数・所要時間に調整する ◦ ここが不十分だと毎回QAの手直しが必要で ◦ 仕事完了までの所要時間が延びてしまい ◦ QAの負荷も減らない • 設計のインプットに必要な資料化は、利用時の結果を確かめながら進める • 試しに１つの領域を資料化して、利用し続けられる所要時間や内容かを　 確認する等 トライしていただくうえでのTips
47. エムスリー公式テックチャンネル https://www.youtube.com/channel/UC_DkAOcwgmtQnJLDctci4rQ 社内勉強会やブログなど面白い話題がたくさん！ エンジニア公式Xアカウント https://x.com/m3_engineering
48. QAエンジニア募集中！！！