長期運用タイトルにおけるAIを活用したテスト設計効率化の事例

GREE Tech Conference 2026で発表された資料です。
https://techcon.gree.jp/2026/session/TrackB-4

Transcript

1. 長期運用タイトルにおける AIを活用したテスト設計効率化の事例 株式会社WFS QAエンジニア 中野 玄真 山本 幸寛
2. 山本 幸寛 株式会社WFS QAエンジニア 家庭用ゲームやモバイルゲームのQA業務を経験 後、2021年グリー株式会社（現：グリーホール ディングス株式会社）に入社。入社後はライトフ ライヤースタジオのQAチームに所属し長期運用タ イトルのQA業務を担当。 合わせて上流工程からより品質を高めるためユー ザーテストに関連する対応も担当している。 2
3. 中野 玄真 株式会社WFS QAエンジニア 2021年にアルバイトとしてグリー株式会社（現： グリーホールディングス株式会社）に入社。ライ トフライヤースタジオにおける複数タイトルのテ スト業務を経て、現在は管理業務を担当。 障害削減による品質向上や、費用効率化などのコ スト最適化にも取り組んでいる。 3
4. 目次・アジェンダ • はじめに • AI活用事例の紹介 • 活用しての効果 • 今後の展望 4
5. はじめに 5
6. 発表の背景 対象タイトル：アナザーエデン 来年10周年を迎えるシングルプレイ専用スマートフォンRPG ©WFS Developed by WRIGHT FLYER STUDIOS 6
7. 発表の背景 体制 担当歴の長いQAエンジニアが、過去の知見と仕様書を元に テスト設計〜テストケース作成を担当 運用の変化 来年10周年を迎える中で、ゲーム内システム、既存機能、コードが年々膨大化 （＋多様な新規施策の追加） 7
8. 発表の背景 長期運用に伴う体制の限界 運用の長期化により、把握/考慮すべき情報量が増加 結果 個人の知見に頼る体制だと、考慮漏れが防ぎにくい 8
9. 発表の背景 長期運用に伴う体制の限界 運用の長期化により、把握/考慮すべき情報量が増加 結果 個人の知見に頼る体制だと、考慮漏れが防ぎにくい 個人の知見に頼る設計から脱却し、 AI活用でテスト設計の精度向上を試みた 9
10. AI活用事例の紹介 10
11. 現状の問題： 長期運用によって仕様が複雑化しており、仕様書に記載されていない条件や過 去の仕様の組み合わせなどで発生する「仕様書定義外」の障害が増加している 仕様書：【クエストAの流れ】 ①：〇〇が仲間になる 仕様書定義外 クエストAを進行中に 別クエストを進行させると ➔ 進行不能 ②：武器「▢▢」が手に入る ③：ボス「△△」と戦闘 ボスと戦闘する前に 武器「▢▢」を強化/売却してしまうと ➔ 進行不能 11
12. 現状の問題： テスト設計時にも考慮はしているが、設計者の「主観と知見」を頼りに作成し ているため、どうしても「仕様書定義外」の障害が防ぎきれない OUTPUT： 作成されるテスト観点 INPUT： 設計のインプット 仕様書ベースの観点 仕様書情報 主観と知見 経験や知識からの観点 ⚠ 仕様書定義外の観点 （検知できず漏れてしまう）
13. 対策： 膨大な情報をAIに読み込ませ、人間が拾いきれない「仕様書定義外」の観点を 出してもらう 体系的な情報 コード 過去の不具合 AI 「仕様書定義外」 観点 仕様書情報 13
14. AI活用時にも様々な課題が発生した 14
15. AI活用時の課題①： 曖昧な指示だとAIの憶測でテスト観点が出力され使い物にならない 曖昧な指示 ----------------------------読み込ませた仕様書から 検証項目を作成して～ 多分これ 出力されたデータ ------------------------・曖昧なフォーマット ・雑なテスト観点 ・具体性のない手順 AI 15
16. AI活用時の課題①への対策： 禁止事項で曖昧な表現をなくし、テスト技法をAIに選択させることで根拠のあ る出力を行うように 役職付与 多分これ 多分これ 出力ルール 事前情報 禁止事項 テスト 技法 出力 ルール AI テスト技法の定義 16
17. AI活用時の課題②： 指示を分けないと荒い出力になってしまい、重要な検証項目が2つしかなかっ たり、画面遷移をかなり細かく見ていたりなど粒度に偏りが出る 共通の指示 重要な検証項目 最低限でよい検証項目 【粗すぎる / 件数不足】 【細かすぎる / 冗長】 ・手順通りに動作すること ・A⇒Bに遷移できること ・手順から外れたら動作しないこと ・B⇒Aに遷移できること ・B⇒A⇒Bに遷移できること ・A⇒B⇒Aに遷移できること 17
18. AI活用時の課題②への対策： 「テスト設計」と「ケース作成」で役割を分けることで正確な指示が可能に 分析AI 項目作成AI テスト設計への指示 ケース作成への指示 テスト設計 ケース作成 • テスト設計技法の選択 • 分析AIの情報から検証項目の出力 • 優先度の切り分け • フォーマットの指定 • 正常系/例外系の観点出し • 施策ごとのシート切り分け 18
19. AI実装ポイント： 分析AI Step1 要素分解 Step2 仕様書 分析 項目作成AI Step3 網羅的な 観点 Step4 設計技法 選択 Step5 項目作成 3原則 Step6 AI レビュー 19
20. Step1：要素分解(1/2) 読み込ませた仕様をコアメカニクス / メタメカニクスの要素に分解し、テスト の優先度や検証の細かさなどの指標を持たせる コアメカニクス メタメカニクス ゲーム体験の核となる、プレイヤーが繰り返し行う直接 的な操作やルールのこと プレイヤーに継続的なプレイ動機を与える育成や進行の 仕組み メニュー 画面操作 歩く/ 走る 攻撃/ 防御/ スキル キャラ 育成 装備強化 図鑑 20
21. Step1：要素分解(2/2) メタメカニクスからプロダクト影響の分析を行い、観点の粒度に対する指標を 持たせる メタメカニクス プレイヤーに継続的なプレイ動機を与える育成や進行の 仕組み キャラ 育成 装備強化 図鑑 【ガチャにより入手できる】 【ゲーム内のアイテムのみ】 【敵の討伐数、入手アイテムなど】 ※優先度が高い ※優先度がやや高め ※優先度が低い 検証粒度を細かめに 検証粒度は標準 検証粒度は最低限 21
22. Step2：仕様書分析 仕様書の矛盾や曖昧な記載を学習させておき、エラーとして検知させる AIの視点 検知される例 AIによる精密分析 AIが検知するエラー具体例 解析手法 全仕様書データを構文解析し、論理的な整合性を検 証 【矛盾点】 ページ間の数値・仕様の食い違い 例：P.10「攻撃力+10%」とP.20「攻撃力+15%」 強み 主観や先入観（バイアス）を100%排除し、記述の 不整合を客観的に特定 【曖昧さ】 定義不足な表現の検出 例：「適切に処理する」「高確率で発生」 【考慮漏れ】 特定組み合わせでの挙動未定義 例：ロボ搭乗時のエリア移動仕様欠落 22
23. Step3：網羅的な観点(1/2) 正常系（ハッピーパス）を学習させておき、 仕様書に記載されている理想的な振る舞いを定義させ、期待結果を出力させる 正常系フロー（ハッピーパス） エラーやトラブルが一切起きない正常なルート （シナリオ）のこと STEP 1: ボスを倒す STEP 2: ストーリーが進行する STEP 3: 伝説の剣を入手する 23
24. Step3：網羅的な観点(2/2) 正常系の内容から、漏れがちな例外系の観点を出力させる 正常系フロー（ハッピーパス） 例外系(アンハッピーパス) STEP 1: ボスを倒す 戦闘必須キャラがいない場合 戦闘が開始できないこと STEP 2: ストーリーが進行する 必須フラグを満たしているか STEP 3: 伝説の剣を入手する 獲得瞬間にタスクキルした場合の挙動 24
25. Step4：設計技法選択 設計技法を学習させておき、仕様の特性から最適な設計技法をAIに選択させる ことで、検証観点の出力における根拠を持たせる 仕様の特性 仕様の特性 複数条件で分岐する シナリオ 下限上限のある数値 アイテムスロットや武器の強化など 最適な設計技法 最適な設計技法 最適な設計技法 デシジョンテーブル 境界値/同値分割 状態遷移テスト 仕様の特性 画面UIの遷移 25
26. Step5：項目作成3原則 出力を安定させる3つのプロンプト原則を定義しておき、 運用していくうえで欠かせないルールを学習させておく 1項目1観点の徹底 ーーーーーーーーーーー ルール 1つのテストケースに 複数の検証観点を 含めないこと トークンの最適化 ーーーーーーーーーーー ルール ・口語の禁止 ・手順説明の簡略化 ・冗長表現の削除 標準フォーマットを定義 ーーーーーーーーーーー ルール 出力時のヘッダー 構文をフォーマットに 沿って作成すること 26
27. Step6：AIレビュー 出力結果をAI自身にセルフレビューさせることで、ハルシネーションの発生を 抑制する [分析AI] 出力データ [項目作成AI]セルフレビュー 削除項目の報告： AIの自己判断で削除した項目がないか [項目作成AI] ルールにそって項目化 未生成項目の報告： 設計内容から生成出来ていない項目がないか [項目作成AI] 生成物をセルフレビュー 27
28. ハイブリッドレビュー 成果物を「人」と「AI」の2軸でレビューを行い、最終的な品質の保障をする 人のレビュー AIのレビュー 強み 強み 各メンバーの主観と知見によってプロダクトの深い知 識や「暗黙知」に基づく柔軟な判断 過去の膨大な情報からの「網羅的」な解析と処理能力 役割 役割 ・ユーザー体験や「面白さ」など、AIが判定しづらい 感性的側面の検証 ・属人性を排除した、機械的な抜け漏れや矛盾のア ラート ・過去の経験則に基づく、複雑な仕様の意図の汲み取 り ・大量のテストケースに対する高速な要件カバレッジ 確認 28
29. 活用しての効果 29
30. 活用しての効果 「仕様書定義外」の障害に対して AIによる過去の膨大な情報から 体系的かつ網羅的なケース作成に成功 人によるチェック/手直しで運用可能と判断 30
31. 活用しての効果 「仕様書定義外」の障害に対して ハイブリッドレビューにより １施策あたり１〜２項目の新たな観点を追加 「仕様書定義外」の潜在不具合を事前検知 31
32. 活用しての効果 副次効果： テストケース作成工数について ある施策のテストケース作成工数 80% 削減 32
33. 活用しての効果 副次効果： 属人性について テスト観点＋テストケース自動生成により 属人性の排除にも成功 33
34. 活用しての効果 Before After 【テスト設計・品質】 【テスト設計・品質】 個人の主観・経験に依存 ➡｢仕様書定義外｣障害増加 AI生成＋ハイブリッドレビュー ➡｢仕様書定義外 ｣を事前検知 できる体制 【業務影響】 ケース作成・仕様確認で手一杯 【業務影響】 工数削減の結果、人は知見をフル活用し レビュー精度向上にフォーカス可能に 34
35. 今後の展望 35
36. 今後の展望 テストケース作成 テスト実行 一部施策から全施策への適用 AIを活用し効率化 今後はテスト設計とテスト実行の両軸で活用し、 効率化・高品質化を目指す！ 36
37. ご清聴ありがとうございました 37