AI画像認識を活用したゲーム内決済処理検証の自動化

by gree_tech

Embed

Start on current slide

Slide 1

Slide 1 text

AI画像認識を活用したゲーム内決済処理検証の自動化株式会社WFS 佐々恵 / 伊藤一樹 2026.07.23 ©WFS

Slide 2

Slide 2 text

自己紹介 NAME 名前佐々恵 AFFILIATION 所属株式会社WFS / Customer & Product Satisfaction部 / QAグループ ROLE & ACTIVITIES 主な活動  ヘブンバーンズレッド QA管理  テスト⾃動化

Slide 3

Slide 3 text

アジェンダ 1. 導入 2. 開発 3. 運用結果 4. まとめと今後の展望 ©WFS

Slide 4

Slide 4 text

SECTION 01 導入 1-1. 自動化対象タイトルの紹介 1-2. 自動化の概要 1-3. 決済処理検証とは 1-4. 決済処理検証を自動化することにした背景 1-5. 技術選定 1-6. 自動化の範囲と開発の流れ

Slide 5

Slide 5 text

自動化対象タイトルの紹介『ヘブンバーンズレッド』ライトフライヤースタジオとKeyが共同制作したシングルプレイRPG ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key

Slide 6

Slide 6 text

自動化対象タイトルの紹介『ヘブンバーンズレッド』ライトフライヤースタジオとKeyが共同制作したシングルプレイRPG iOS∕Android∕Steam ⽇本、韓国、繁体字圏多くの地域で配信中検証⼯数も膨⼤なため⾃動化するメリットあり ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key

Slide 7

Slide 7 text

自動化の概要テスト実行 AI⾃動テストエンジン運用者 Cloud Service LLM Service

Slide 8

Slide 8 text

自動化の概要テスト実行操作指示 AI⾃動テストエンジンデバイス運用者 Cloud Service LLM Service

Slide 9

Slide 9 text

自動化の概要テスト実行操作指示 AI⾃動テストエンジン運用者 Cloud Service LLM Service ゲーム画像デバイス

Slide 10

Slide 10 text

自動化の概要テスト実行操作指示 AI⾃動テストエンジン運用者 Cloud Service LLM Service ゲーム画像購入デバイス付与サーバー

Slide 11

Slide 11 text

自動化の概要テスト実行ログ操作指示 AI⾃動テストエンジン運用者 Cloud Service LLM Service ゲーム画像購入デバイス付与サーバー

Slide 12

Slide 12 text

SECTION 01 - 03 決済処理検証とは

Slide 13

Slide 13 text

決済処理検証の目的情報の整合性購入フローの完了履歴記録の正確性 PFごとの価格表⽰、アイ決済PFからアプリ内への即時のアイテム付与と、テム名称、説明⽂がユートランザクションが異常バックエンドへの正確なザーに正しく提⽰されてなく完了するか履歴情報の記録いるか

Slide 14

Slide 14 text

決済処理検証の目的サムネ画像の表⽰崩れ情報の整合性⽂字の途切れもチェック PFごとの価格表⽰、アイテム名称、 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key 説明⽂がユーザーに正しく提⽰されているか ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key

Slide 15

Slide 15 text

決済処理検証の目的購入決済購入フローの完了 iOS Android Stam 決済PFからアプリ内へのトランザクションが異常なく完了するかデバイス通知付与サーバー決済PF

Slide 16

Slide 16 text

決済処理検証の目的履歴記録の正確性即時のアイテム付与と、 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key バックエンドへの正確な履歴情報の記録利用履歴SS ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key

Slide 17

Slide 17 text

SECTION 01 - 04 決済処理検証を自動化することにした背景

Slide 18

Slide 18 text

決済処理検証を自動化することにした背景 ①環境の複雑性 ②検証手順の単純性

Slide 19

Slide 19 text

決済処理検証を自動化することにした背景 ①環境の複雑性 ● 配信地域によって通貨が異なる ● ゲームサーバーが複数ある ● 決済PFが複数ある

Slide 20

Slide 20 text

決済処理検証を自動化することにした背景 ①環境の複雑性決済処理検証のパターン対象国‧地域 ● 配信地域によって通貨が異なるゲームサーバー⽇本 JP版 ● ゲームサーバーが複数ある韓国 KR版 ● 決済PFが複数ある台湾 AP版⾹港 AP版マカオ AP版 Android iOS PC (Steam) ―

Slide 21

Slide 21 text

決済処理検証を自動化することにした背景 ①環境の複雑性決済処理検証のパターン対象国‧地域 ● 配信地域によって通貨が異なるゲームサーバー⽇本 JP版 ● ゲームサーバーが複数ある韓国 KR版 ● 決済PFが複数ある台湾 AP版⾹港 AP版マカオ AP版対象地域、PFの数に⽐例してコストが増える Android iOS PC (Steam) ―

Slide 22

Slide 22 text

決済処理検証を自動化することにした背景 ②検証手順の単純性 ● 決まった⼿順を繰り返す ● 画⾯遷移が変わりづらい ● タップ操作が中⼼ゲーム開始画⾯遷移決済処理検証は⾃動化しやすい購⼊付与確認

Slide 23

Slide 23 text

SECTION 01 - 05 技術選定

Slide 24

Slide 24 text

技術選定テスト自動化の手法画像認識スクリプト AI 特性: 画⾯からターゲット特性: DOM構造やオブジェ特性: 画⾯を意味として理画像を探して操作クト構造のIDを指定して解して操作操作

Slide 25

Slide 25 text

技術選定テスト自動化の手法画像認識スクリプト AI 特性: 画⾯からターゲット特性: DOM構造やオブジェ特性: 画⾯を意味として理画像を探して操作クト構造のIDを指定して解して操作操作ゲームレガシーシステム

Slide 26

Slide 26 text

技術選定テスト自動化の手法画像認識スクリプト AI 特性: 画⾯からターゲット特性: DOM構造やオブジェ特性: 画⾯を意味として理画像を探して操作クト構造のIDを指定して解して操作操作ゲームレガシーシステム⾃動⾞（組み込み）銀⾏の基幹系

Slide 27

Slide 27 text

技術選定テスト自動化の手法画像認識スクリプト AI 特性: 画⾯からターゲット特性: DOM構造やオブジェ特性: 画⾯を意味として理画像を探して操作クト構造のIDを指定して解して操作操作ゲームレガシーシステム⾃動⾞（組み込み）銀⾏の基幹系 EC‧SaaS スマホアプリ

Slide 28

Slide 28 text

技術選定アプリゲームの傾向対応端末が多い＝解像度の種類が多い 1720×1084 640×480 画像認識は端末差異の吸収が難しい

Slide 29

Slide 29 text

技術選定アプリゲームの傾向 UIが刷新される頻度が高い（構造変更が多い） ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key 画像認識、スクリプトの保守コストが高くなる

Slide 30

Slide 30 text

技術選定各手法の特徴画像認識スクリプト AI (LLM) 柔軟性 (UI変更への強さ) × 低い △ 普通 ○ ⾼いアプリ側実装 ○ 不要 × 必要 ○ 不要端末差異の吸収 × 不可 ○ 可能 ○ 可能運⽤コスト △ 普通 ○ 低い × ⾼い保守コスト × ⾼い △ 普通 ○ 低い

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

技術選定各手法の特徴画像認識スクリプト AI (LLM) 柔軟性 (UI変更への強さ) × 低い △ 普通 ○ ⾼いアプリ側実装 ○ 不要 × 必要 ○ 不要端末差異の吸収 × 不可 ○ 可能 ○ 可能運⽤コスト △ 普通 ○ 低い × ⾼い保守コスト × ⾼い × ⾼い ○ 低い

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

技術選定決済検証における AI(LLM)の技術的優位性柔軟な環境吸収非破壊的導入 UI変更の吸収端末の差異を吸収可能アプリ側への実装が不要 LLMの推論に基づいた外部操作のみで完結操作決定が可能 ↓ 全PFで実⾏可能 ↓ ↓ 本番環境で実⾏可能 UI変更後も実⾏可能

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

技術選定決済検証における AI(LLM)の技術的優位性柔軟な環境吸収非破壊的導入 UI変更の吸収端末の差異を吸収可能アプリ側への実装が不要 LLMの推論に基づいた外部操作のみで完結操作決定が可能 ↓ 全PFで実⾏可能 ↓ ↓ 本番環境で実⾏可能 UI変更後も実⾏可能決済検証自動化のコア技術として AIを選択

Slide 42

Slide 42 text

技術選定 AI（LLM）のみだと精度が低い & API費⽤がかさむ

Slide 43

Slide 43 text

技術選定 AI（LLM）のみだと精度が低い & API費⽤がかさむ ↓ ⼿法を組み合わせる

Slide 44

Slide 44 text

技術選定組み合わせ ①スクリプト＋AI(LLM) ②画像認識＋AI (LLM)

Slide 45

Slide 45 text

技術選定組み合わせ手法の特徴スクリプト＋AI(LLM) 画像認識＋AI (LLM) 構造取得＋テキスト画像＋テキスト柔軟性 (UI変更への強さ) ○ ⾼い ○ ⾼いアプリ側実装 × 必要 ○ 不要端末差異の吸収 ○ 可能 ○ 可能保守コスト ○ 低い △ 普通運⽤コスト × ⾼い × ⾼い全環境コード共通化 × 不可 ○ ほぼ可能画⾯要素検出⼿法

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

SECTION 01-04 自動化の範囲と開発の流れ

Slide 50

Slide 50 text

自動化の範囲自動化と手動の役割分担運⽤フローテスト準備ゲーム開始画⾯遷移購⼊付与確認エビデンス保存 OKNG 判断

Slide 51

Slide 51 text

自動化の範囲自動化と手動の役割分担運⽤フローテスト準備ゲーム開始画⾯遷移購⼊⾃動化 ※テスト項⽬の変更なし付与確認エビデンス保存 OKNG 判断

Slide 52

Slide 52 text

開発体制エンジニアと QAの協働エンジニア（ 2名） QA（2名）ハードウェア構築、Agent/Action実装、要件定義、運⽤、保守‧改修 CI/GUI整備

Slide 53

Slide 53 text

開発の流れ⼯程内容主担当要件定義⾃動化の範囲決め QA 実装 AI Agent 開発導⼊実機での動作確認エンジニア/QA 改修トラブル対応、改修 QA エンジニア

Slide 54

Slide 54 text

開発の流れ⼯程内容主担当要件定義⾃動化の範囲決め QA 実装 AI Agent 開発導⼊実機での動作確認エンジニア/QA 改修トラブル対応、改修 QA エンジニア

Slide 55

Slide 55 text

SECTION 02 開発

Slide 56

Slide 56 text

自己紹介 NAME 名前伊藤⼀樹 AFFILIATION 所属株式会社WFS/スタジオ本部/リードエンジニア ROLE & ACTIVITIES 主な活動  サーバーサイドエンジニア  AIを活⽤したツール作成や基盤構築

Slide 57

Slide 57 text

実装したもの ENGINE INTERFACE ワークフローエンジン実⾏確認⽤のGUI ⾃動化処理の中核を担う実⾏制御システムエンジンの動作状況をリアルタイムで可視化

Slide 58

Slide 58 text

本題に入る前に ... 出⼒A 「きのこ派」⼊⼒プロンプト「きのこ派？たけのこ派？」出⼒B 「たけのこ派」決定論的(Deterministic) ⾮決定論的(Non-Deterministic) 同じ⼊⼒ → 同じ出⼒同じ⼊⼒ → 異なる出⼒

Slide 59

Slide 59 text

本題に入る前に ... 出⼒に揺らぎが⽣じる出⼒A 「きのこ派」⼊⼒プロンプト「きのこ派？たけのこ派？」出⼒B 「たけのこ派」決定論的(Deterministic) ⾮決定論的(Non-Deterministic) 同じ⼊⼒ → 同じ出⼒同じ⼊⼒ → 異なる出⼒

Slide 60

Slide 60 text

自動化で実現したいフローゲーム開始ホーム画⾯遷移ショップ画⾯遷移アイテム購⼊購⼊アイテム確認

Slide 61

Slide 61 text

自動化で実現したいフローゲーム開始ホーム画⾯遷移ショップ画⾯遷移アイテム購⼊購⼊アイテム確認フロー⾃体は決定論的(同じ⼊⼒で同じ出⼒を期待)

Slide 62

Slide 62 text

目指すべきワークフローエンジン⾮決定論的なLLMを⽤いて決定論的なワークフローを回すためのフレームワーク

Slide 63

Slide 63 text

目指すべきワークフローエンジン 2022年プロンプトエンジニアリング 2025年コンテキストエンジニアリング 2026年初頭ハーネスエンジニアリング要するに Computer Use系におけるハーネスエンジニアリングとガードレールの実装

Slide 64

Slide 64 text

用意したハードウェア PC ミラーリングソフト OS間での差異を減らす PC版ゲームアプリケーション画像認識 ↓ PC上で操作(クリック等) が⾏えるようにする iPhone Android

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

実装したワークフローゲーム開始してショップ画⾯まで遷移アイテム購⼊成功購⼊アイテム確認成功 AgentNode AgentNode TaskNode 完了判定完了判定完了判定

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

AgentNode 開始プロンプト注⼊ Agentic Loop 完了条件のチェック AgentNodeとは本ワークフローの核⼼部分画像認識でPC操作を⾏う Gemini Live APIによるAgentic Loop(知覚→思考→⾏動)を⾏う完了の状態を返す

Slide 72

Slide 72 text

AgentNode プロンプト注⼊開始 Agentic Loop 完了条件のチェック User Instruction 何をするか（このAgentの具体タスク) 例: ショップで◯◯を購⼊する System Instruction ⾏動規範例: 出⼒形式‧制約‧画⾯定義‧利⽤可能アクション完了の状態を返す

Slide 73

Slide 73 text

AgentNode 開始プロンプト注⼊ Agentic Loop 完了条件のチェック完了の状態を返す User Instruction スタートボタンをタップしてゲームを開始すること。ホーム画⾯が開いたらXXボタンを押してショップ画⾯を開くこと。 System Instruction 出⼒形式、役割、画⾯定義、ゲーム内ドメイン知識思考フィールド、選択できるアクション

Slide 74

Slide 74 text

Slide 75

Slide 75 text

AgentNode 開始プロンプト注⼊ Agentic Loop 完了条件のチェック Agentic Loop 知覚 ● 1秒おきに画⾯のスクリーンショットを送り続ける思考 ● 与えられたタスクから何を⾏うか選択する⾏動 ● LLMが選択した⾏動を実際に⾏う完了の状態を返す

Slide 76

Slide 76 text

AgentNode プロンプト注⼊開始知覚 Agentic Loop Gemini Live API 完了条件のチェック完了の状態を返す思考 - 状態画⾯分類⾏動の選択理由⾏動選択⾏動 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key - クリック待機ショートカットキー等

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

AgentNodeの知覚プロンプト注⼊開始知覚 Agentic Loop Gemini Live API 完了条件のチェック完了の状態を返す思考 - 状態画⾯分類⾏動の選択理由⾏動選択⾏動 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key - クリック待機ショートカットキー等

Slide 80

Slide 80 text

AgentNodeの知覚開始プロンプト注⼊ Agentic Loop 完了条件のチェック完了の状態を返す典型的なAgenticLoop このシステムのAgenticLoop ループ処理逐次的 (知覚→思考→⾏動は順番に⾏う) ⾮同期的 (知覚と思考→⾏動は別ループ) セッション呼び出しごとに再構築永続的な双⽅向セッション向いている⽤途静的‧離散的なUI リアルタイムに変化するUI

Slide 81

Slide 81 text

AgentNodeの思考開始プロンプト注⼊ Agentic Loop 毎ターンLLMが⽣成する構造化出⼒(JSON) - 画⾯に⾒えるものを詳細に記述 - 画⾯分類の根拠 - 画⾯分類 - ⾏動選択の根拠 - ⾏動選択完了条件のチェック完了の状態を返す

Slide 82

Slide 82 text

AgentNodeの思考開始プロンプト注⼊ Agentic Loop 完了条件のチェック完了の状態を返す毎ターンLLMが⽣成する構造化出⼒(JSON) - 画⾯に⾒えるものを詳細に記述 - 画⾯分類の根拠 - 画⾯分類 - ⾏動選択の根拠 - ⾏動選択前から順番にトークン⽣成

Slide 83

Slide 83 text

AgentNodeの思考開始プロンプト注⼊ Agentic Loop 完了条件のチェック毎ターンLLMが⽣成する構造化出⼒(JSON) { “画⾯に⾒えるものを詳細に記述”: “右下にメニューボタンがある”, “画⾯分類の根拠”: “メニューボタンが右下にあるため”, “画⾯分類”: “ホーム画⾯”, “⾏動選択の根拠”: “ホーム画⾯ではメニューボタンを押下し、ショップ画⾯を開く必要がある” “⾏動選択”: “メニューボタンを押下”, } 完了の状態を返す

Slide 84

Slide 84 text

Slide 85

Slide 85 text

AgentNodeの行動開始プロンプト注⼊ Agentic Loop 完了条件のチェック完了の状態を返す要素クリックパスワード⼊⼒待機完了

Slide 86

Slide 86 text

AgentNodeの行動開始プロンプト注⼊ Agentic Loop 完了条件のチェック完了の状態を返す要素クリックパスワード⼊⼒待機完了

Slide 87

Slide 87 text

AgentNodeの行動(要素クリック ) 開始プロンプト注⼊処理フロー - ⾃然⾔語で対象指定 - 座標検出 - クリック Agentic Loop 完了条件のチェック完了の状態を返す⾃然⾔語で対象指定メインLLM(Gemini Live API)がクリックするべき要素を⾃然⾔語で記述 - 効いたか検証例緑⾊の四⾓いボタン

Slide 88

Slide 88 text

AgentNodeの行動(要素クリック ) 開始プロンプト注⼊処理フロー Agentic Loop 完了条件のチェック完了の状態を返す座標検出ロジック - ⾃然⾔語で対象指定 1. 登録された固定座標 - 座標検出 2. OpenCVテンプレートマッチング - クリック 3. Gemini APIによる2Dバウンディン - 効いたか検証グボックス検出

Slide 89

Slide 89 text

Slide 90

Slide 90 text

Slide 91

Slide 91 text

Slide 92

Slide 92 text

AgentNodeの行動(要素クリック ) 開始プロンプト注⼊ Agentic Loop 完了条件のチェック完了の状態を返す処理フロー画⾯検証 - ⾃然⾔語で対象指定 1. 画⾯に変化があることを期待する - 座標検出 - クリック - 効いたか検証か？(しないならそこでOKとする) 2. OpenCVで差分検出

Slide 93

Slide 93 text

Slide 94

Slide 94 text

Slide 95

Slide 95 text

AgentNode 開始プロンプト注⼊ Agentic Loop 完了条件のチェック完了条件のチェック LLMがタスク完了を通知してきたら決定論的にチェックする ● 画⾯の再検証とﬁnish条件の確認 ● エビデンス(証拠スクリーンショット)の存在確認未達なら再度Agentic Loopに処理を戻す完了の状態を返す

Slide 96

Slide 96 text

AgentNode 開始プロンプト注⼊完了の状態を返すタスクの状態を成功/失敗で返す ● 成功: 次のNodeに遷移 ● 失敗: ワークフローを中断 Agentic Loop 完了条件のチェック完了の状態を返す

Slide 97

Slide 97 text

Slide 98

Slide 98 text

TaskNode 開始タスク実⾏ TaskNodeとは⾮AIで決定的な⼿続き処理 ● アプリの再起動処理 ● 確実に漏れなく遂⾏してほしい処理 ● 座標検出にのみLLMを使⽤完了の状態を返す

Slide 99

Slide 99 text

TaskNode 開始タスク実⾏ TaskNodeの使⽤箇所(確実に実⾏してほしい) ギフトボックスにN個あるアイテムを順番に受け取る 1. ギフトボックスをタップ 2. ギフト詳細画⾯でスクリーンショット 3. ギフト受け取り 4. ギフトが存在する限り1から再度実⾏完了の状態を返す

Slide 100

Slide 100 text

AgentNodeとTaskNodeの使い分け判断軸 AgentNode TaskNode 手順の確定度状況次第で変わる完全に確定・毎回同じ処理速度遅い(ターンごとに思考 ) 早い(判断オーバーヘッドなし ) 保守コスト低い(動的にLLMが判断) 高い失敗許容度探索的でリカバリ前提確実に完遂が必要な操作

Slide 101

Slide 101 text

Slide 102

Slide 102 text

ガードレール開始プロンプト注⼊ワークフローの無限実⾏を阻⽌ - LLMの消費トークン数 - 実⾏時間 - エラー連続N回 Agentic Loop 完了条件のチェック完了の状態を返す

Slide 103

Slide 103 text

ハマりどころ開始プロンプト注⼊ Agentic Loop 完了条件のチェック完了の状態を返す Gemini Live API - 接続時間が⻑くなるとセッションが切れがち - 反応がないときにこちらから「続けて」と指⽰を出す必要がある

Slide 104

Slide 104 text

SECTION 02-02 導入時の課題と解決方法

Slide 105

Slide 105 text

課題1：開発者と運用者の環境差異による運用エラー現象：開発者のMac環境と運⽤者の環境で解像度、解決策パス、権限、設定が異なり、運⽤開始時にエラー ‧dotenvxによる環境変数の暗号化管理が発⽣ ‧Google Cloud Secret Managerでの認証情報⼀元管理 ‧CLIコマンドとWebベースGUIによる環境差異の吸収

Slide 106

Slide 106 text

課題2：運用者の技術スキルへの配慮現象：当初はターミナルでのコマンド操作が必要だったが、⾮エンジニアのQA担当者には敷居が⾼かった解決策 ‧CLIコマンドにインタラクティブモード実装 ‧前回の実⾏設定を記憶し、2回⽬以降の実⾏を簡略化 ‧WebベースのGUIを開発し、更新、ログ確認、エビデンス確認、アップデートなど、運⽤に必要な機能は全てそこで⾏えるようにした

Slide 107

Slide 107 text

課題2：運用者の技術スキルへの配慮 WebベースのGUI

Slide 108

Slide 108 text

SECTION 02-03 QAによる改修

Slide 109

Slide 109 text

QAによる改修改修事例①：ワークフローの追加購⼊までのワークフロー実装ゲーム開始してショップ画⾯まで遷移アイテム確認アイテム購⼊購⼊アイテム確認 AgentNode AgentNode AgentNode TaskNode 完了判定完了判定完了判定完了判定

Slide 110

Slide 110 text

QAによる改修改修事例①：ワークフローの追加購⼊までのワークフロー実装ゲーム開始してショップ画⾯まで遷移アイテム確認アイテム購⼊購⼊アイテム確認 AgentNode AgentNode AgentNode TaskNode 完了判定完了判定完了判定完了判定ここまで

Slide 111

Slide 111 text

QAによる改修改修事例②： NodesLoopの実装特定のAgentNodesを指定回数実⾏する複合ノードの実装改修前：1回の実⾏で購⼊できるアイテムは1回のみ何回も実⾏する必要がある ↓ 改修後：1回の実⾏で指定回数分購⼊できる基本1回の実⾏でテスト完了できる

Slide 112

Slide 112 text

QAによる改修改修事例②： NodesLoopの実装特定のAgentNodeを指定回数実⾏する複合ノードの実装ゲーム開始してショップ画⾯まで遷移アイテム購⼊成功購⼊アイテム確認成功 AgentNode AgentNode TaskNode 完了判定完了判定完了判定ここをLoopさせる

Slide 113

Slide 113 text

SECTION 03 運用結果

Slide 114

Slide 114 text

削減効果 14.7人日自動化前（人日 /月）自動化後（人日 /月） 4.4人日 ▲ 10.3人日/月削減⼯数 70% コスト削減率

Slide 115

Slide 115 text

初期導入コストと運用コスト初期導入コストエンジニア工数 80人日 QA工数 15人日運用コスト APIコスト約 1.9万円/月 QA工数 4.4人日/月

Slide 116

Slide 116 text

現在の課題（ 1/3） HW/インフラ面ミラーリングアプリケーションの⻑時間接続安定性停電‧ネットワーク障害時における物理復旧の必要性金曜日正常にミラーリング接続されている状態休日月曜日物理復旧微細な瞬リモートでのミラーサーバールームへ赴断やOSのスリープにリング再開が不可能き、実機を⼿動操作無⼈稼働より接続が切断して再接続

Slide 117

Slide 117 text

現在の課題（ 2/3） UI要素認識失敗 ‧ホーム画⾯からクォーツショップ遷移ボタン ‧Steamプラットフォームの購⼊ボタン ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key

Slide 118

Slide 118 text

現在の課題（ 3/3）自動化の範囲の拡張ボタン操作以外の複雑なカメラ‧移動操作への対応が困難⾮決定的なUI（演出アニメーション等）の評価が困難ワイルドエリア 3D移動の動画 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key 初期SSのEXスキル演習動画 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key

Slide 119

Slide 119 text

SECTION 04 まとめと今後の展望

Slide 120

Slide 120 text

Slide 121

Slide 121 text

まとめと今後の展望まとめ ‧QAとエンジニアの協働により、実運⽤に耐えるシステムを構築 ‧LLMと画像認識の組み合わせにより、柔軟な画⾯認識と⾃動操作が可能に約70%のQA⼯数削減を達成 QAが定型作業から解放され、より専⾨性の⾼い業務に集中できる ©WFS

Slide 122

Slide 122 text

まとめと今後の展望まとめ ‧QAとエンジニアの協働により、実運⽤に耐えるシステムを構築 ‧LLMと画像認識の組み合わせにより、柔軟な画⾯認識と⾃動操作が可能に約70%のQA⼯数削減を達成 QAが定型作業から解放され、より専⾨性の⾼い業務に集中できる半年以上稼働継続使えば使うほど⼯数が削減される ©WFS