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

CEDEC2026で発表された資料です。
https://cedec.cesa.or.jp/2026/timetable/detail/s6985894967a5d/

Transcript

1. AI画像認識を活用した ゲーム内決済処理検証の自動化 株式会社WFS 佐々 恵 / 伊藤 一樹 2026.07.23 ©WFS
2. 自己紹介 NAME 名前 佐々 恵 AFFILIATION 所属 株式会社WFS / Customer & Product Satisfaction部 / QAグループ ROLE & ACTIVITIES 主な活動  ヘブンバーンズレッド QA管理  テスト⾃動化
3. アジェンダ 1. 導入 2. 開発 3. 運用結果 4. まとめと今後の展望 ©WFS
4. SECTION 01 導入 1-1. 自動化対象タイトルの紹介 1-2. 自動化の概要 1-3. 決済処理検証とは 1-4. 決済処理検証を自動化することにした背景 1-5. 技術選定 1-6. 自動化の範囲と開発の流れ
5. 自動化対象タイトルの紹介 『ヘブンバーンズレッド』 ライトフライヤースタジオとKeyが 共同制作したシングルプレイRPG ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key
6. 自動化対象タイトルの紹介 『ヘブンバーンズレッド』 ライトフライヤースタジオとKeyが 共同制作したシングルプレイRPG iOS∕Android∕Steam ⽇本、韓国、繁体字圏 多くの地域で配信中 検証⼯数も膨⼤なため ⾃動化するメリットあり ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key
7. 自動化の概要 テスト実行 AI⾃動テスト エンジン 運用者 Cloud Service LLM Service
8. 自動化の概要 テスト実行 操作指示 AI⾃動テスト エンジン デバイス 運用者 Cloud Service LLM Service
9. 自動化の概要 テスト実行 操作指示 AI⾃動テスト エンジン 運用者 Cloud Service LLM Service ゲーム画像 デバイス
10. 自動化の概要 テスト実行 操作指示 AI⾃動テスト エンジン 運用者 Cloud Service LLM Service ゲーム画像 購入 デバイス 付与 サーバー
11. 自動化の概要 テスト実行 ログ 操作指示 AI⾃動テスト エンジン 運用者 Cloud Service LLM Service ゲーム画像 購入 デバイス 付与 サーバー
12. SECTION 01 - 03 決済処理検証とは
13. 決済処理検証の目的 情報の整合性 購入フローの完了 履歴記録の正確性 PFごとの価格表⽰、アイ 決済PFからアプリ内への 即時のアイテム付与と、 テム名称、説明⽂がユー トランザクションが異常 バックエンドへの正確な ザーに正しく提⽰されて なく完了するか 履歴情報の記録 いるか
14. 決済処理検証の目的 サムネ画像の表⽰崩れ 情報の整合性 ⽂字の途切れもチェック PFごとの価格表⽰、アイテム名称、 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key 説明⽂がユーザーに正しく提⽰され ているか ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key
15. 決済処理検証の目的 購入 決済 購入フローの完了 iOS Android Stam 決済PFからアプリ内への トランザクションが異常 なく完了するか デバイス 通知 付与 サーバー 決済PF
16. 決済処理検証の目的 履歴記録の正確性 即時のアイテム付与と、 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key バックエンドへの正確な 履歴情報の記録 利用履歴SS ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key
17. SECTION 01 - 04 決済処理検証を自動化することにした背景
18. 決済処理検証を自動化することにした背景 ①環境の複雑性 ②検証手順の単純性
19. 決済処理検証を自動化することにした背景 ①環境の複雑性 • 配信地域によって通貨が異なる • ゲームサーバーが複数ある • 決済PFが複数ある
20. 決済処理検証を自動化することにした背景 ①環境の複雑性 決済処理検証のパターン 対象国‧地域 • 配信地域によって通貨が異なる ゲーム サーバー ⽇本 JP版 • ゲームサーバーが複数ある 韓国 KR版 • 決済PFが複数ある 台湾 AP版 ⾹港 AP版 マカオ AP版 Android iOS PC (Steam) ―
21. 決済処理検証を自動化することにした背景 ①環境の複雑性 決済処理検証のパターン 対象国‧地域 • 配信地域によって通貨が異なる ゲーム サーバー ⽇本 JP版 • ゲームサーバーが複数ある 韓国 KR版 • 決済PFが複数ある 台湾 AP版 ⾹港 AP版 マカオ AP版 対象地域、PFの数に⽐例してコストが増える Android iOS PC (Steam) ―
22. 決済処理検証を自動化することにした背景 ②検証手順の単純性 • 決まった⼿順を繰り返す • 画⾯遷移が変わりづらい • タップ操作が中⼼ ゲーム 開始 画⾯ 遷移 決済処理検証は⾃動化しやすい 購⼊ 付与 確認
23. SECTION 01 - 05 技術選定
24. 技術選定 テスト自動化の手法 画像認識 スクリプト AI 特性: 画⾯からターゲット 特性: DOM構造やオブジェ 特性: 画⾯を意味として理 画像を探して操作 クト構造のIDを指定して 解して操作 操作
25. 技術選定 テスト自動化の手法 画像認識 スクリプト AI 特性: 画⾯からターゲット 特性: DOM構造やオブジェ 特性: 画⾯を意味として理 画像を探して操作 クト構造のIDを指定して 解して操作 操作 ゲーム レガシーシステム
26. 技術選定 テスト自動化の手法 画像認識 スクリプト AI 特性: 画⾯からターゲット 特性: DOM構造やオブジェ 特性: 画⾯を意味として理 画像を探して操作 クト構造のIDを指定して 解して操作 操作 ゲーム レガシーシステム ⾃動⾞（組み込み） 銀⾏の基幹系
27. 技術選定 テスト自動化の手法 画像認識 スクリプト AI 特性: 画⾯からターゲット 特性: DOM構造やオブジェ 特性: 画⾯を意味として理 画像を探して操作 クト構造のIDを指定して 解して操作 操作 ゲーム レガシーシステム ⾃動⾞（組み込み） 銀⾏の基幹系 EC‧SaaS スマホアプリ
28. 技術選定 アプリゲームの傾向 対応端末が多い＝解像度の種類が多い 1720×1084 640×480 画像認識は端末差異の吸収が難しい
29. 技術選定 アプリゲームの傾向 UIが刷新される頻度が高い（構造変更が多い） ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key 画像認識、スクリプトの保守コストが高くなる
30. 技術選定 各手法の特徴 画像認識 スクリプト AI (LLM) 柔軟性 (UI変更への強さ) × 低い △ 普通 ◦ ⾼い アプリ側実装 ◦ 不要 × 必要 ◦ 不要 端末差異の吸収 × 不可 ◦ 可能 ◦ 可能 運⽤コスト △ 普通 ◦ 低い × ⾼い 保守コスト × ⾼い △ 普通 ◦ 低い
31. 技術選定 各手法の特徴 画像認識 スクリプト AI (LLM) 柔軟性 (UI変更への強さ) × 低い △ 普通 ◦ ⾼い アプリ側実装 ◦ 不要 × 必要 ◦ 不要 端末差異の吸収 × 不可 ◦ 可能 ◦ 可能 運⽤コスト △ 普通 ◦ 低い × ⾼い 保守コスト × ⾼い △ 普通 ◦ 低い
32. 技術選定 各手法の特徴 画像認識 スクリプト AI (LLM) 柔軟性 (UI変更への強さ) × 低い △ 普通 ◦ ⾼い アプリ側実装 ◦ 不要 × 必要 ◦ 不要 端末差異の吸収 × 不可 ◦ 可能 ◦ 可能 運⽤コスト △ 普通 ◦ 低い × ⾼い 保守コスト × ⾼い △ 普通 ◦ 低い
33. 技術選定 各手法の特徴 画像認識 スクリプト AI (LLM) 柔軟性 (UI変更への強さ) × 低い △ 普通 ◦ ⾼い アプリ側実装 ◦ 不要 × 必要 ◦ 不要 端末差異の吸収 × 不可 ◦ 可能 ◦ 可能 運⽤コスト △ 普通 ◦ 低い × ⾼い 保守コスト × ⾼い × ⾼い ◦ 低い
34. 技術選定 各手法の特徴 画像認識 スクリプト AI (LLM) 柔軟性 (UI変更への強さ) × 低い △ 普通 ◦ ⾼い アプリ側実装 ◦ 不要 × 必要 ◦ 不要 端末差異の吸収 × 不可 ◦ 可能 ◦ 可能 運⽤コスト △ 普通 ◦ 低い × ⾼い 保守コスト × ⾼い × ⾼い ◦ 低い
35. 技術選定 各手法の特徴 画像認識 スクリプト AI (LLM) 柔軟性 (UI変更への強さ) × 低い △ 普通 ◦ ⾼い アプリ側実装 ◦ 不要 × 必要 ◦ 不要 端末差異の吸収 × 不可 ◦ 可能 ◦ 可能 運⽤コスト △ 普通 ◦ 低い × ⾼い 保守コスト × ⾼い × ⾼い ◦ 低い
36. 技術選定 各手法の特徴 画像認識 スクリプト AI (LLM) 柔軟性 (UI変更への強さ) × 低い △ 普通 ◦ ⾼い アプリ側実装 ◦ 不要 × 必要 ◦ 不要 端末差異の吸収 × 不可 ◦ 可能 ◦ 可能 運⽤コスト △ 普通 ◦ 低い × ⾼い 保守コスト × ⾼い × ⾼い ◦ 低い
37. 技術選定 決済検証における AI(LLM)の技術的優位性 柔軟な環境吸収 非破壊的導入 UI変更の吸収 端末の差異を吸収可能 アプリ側への実装が不要 LLMの推論に基づいた 外部操作のみで完結 操作決定が可能 ↓ 全PFで実⾏可能 ↓ ↓ 本番環境で実⾏可能 UI変更後も実⾏可能
38. 技術選定 決済検証における AI(LLM)の技術的優位性 柔軟な環境吸収 非破壊的導入 UI変更の吸収 端末の差異を吸収可能 アプリ側への実装が不要 LLMの推論に基づいた 外部操作のみで完結 操作決定が可能 ↓ 全PFで実⾏可能 ↓ ↓ 本番環境で実⾏可能 UI変更後も実⾏可能
39. 技術選定 決済検証における AI(LLM)の技術的優位性 柔軟な環境吸収 非破壊的導入 UI変更の吸収 端末の差異を吸収可能 アプリ側への実装が不要 LLMの推論に基づいた 外部操作のみで完結 操作決定が可能 ↓ 全PFで実⾏可能 ↓ ↓ 本番環境で実⾏可能 UI変更後も実⾏可能
40. 技術選定 決済検証における AI(LLM)の技術的優位性 柔軟な環境吸収 非破壊的導入 UI変更の吸収 端末の差異を吸収可能 アプリ側への実装が不要 LLMの推論に基づいた 外部操作のみで完結 操作決定が可能 ↓ 全PFで実⾏可能 ↓ ↓ 本番環境で実⾏可能 UI変更後も実⾏可能
41. 技術選定 決済検証における AI(LLM)の技術的優位性 柔軟な環境吸収 非破壊的導入 UI変更の吸収 端末の差異を吸収可能 アプリ側への実装が不要 LLMの推論に基づいた 外部操作のみで完結 操作決定が可能 ↓ 全PFで実⾏可能 ↓ ↓ 本番環境で実⾏可能 UI変更後も実⾏可能 決済検証自動化のコア技術として AIを選択
42. 技術選定 AI（LLM）のみだと 精度が低い & API費⽤がかさむ
43. 技術選定 AI（LLM）のみだと 精度が低い & API費⽤がかさむ ↓ ⼿法を組み合わせる
44. 技術選定 組み合わせ ①スクリプト＋AI(LLM) ②画像認識＋AI (LLM)
45. 技術選定 組み合わせ手法の特徴 スクリプト＋AI(LLM) 画像認識＋AI (LLM) 構造取得＋テキスト 画像＋テキスト 柔軟性 (UI変更への強さ) ◦ ⾼い ◦ ⾼い アプリ側実装 × 必要 ◦ 不要 端末差異の吸収 ◦ 可能 ◦ 可能 保守コスト ◦ 低い △ 普通 運⽤コスト × ⾼い × ⾼い 全環境コード共通化 × 不可 ◦ ほぼ可能 画⾯要素検出⼿法
46. 技術選定 組み合わせ手法の特徴 スクリプト＋AI(LLM) 画像認識＋AI (LLM) 構造取得＋テキスト 画像＋テキスト 柔軟性 (UI変更への強さ) ◦ ⾼い ◦ ⾼い アプリ側実装 × 必要 ◦ 不要 端末差異の吸収 ◦ 可能 ◦ 可能 保守コスト ◦ 低い △ 普通 運⽤コスト × ⾼い × ⾼い 全環境コード共通化 × 不可 ◦ ほぼ可能 画⾯要素検出⼿法
47. 技術選定 組み合わせ手法の特徴 スクリプト＋AI(LLM) 画像認識＋AI (LLM) 構造取得＋テキスト 画像＋テキスト 柔軟性 (UI変更への強さ) ◦ ⾼い ◦ ⾼い アプリ側実装 × 必要 ◦ 不要 端末差異の吸収 ◦ 可能 ◦ 可能 保守コスト ◦ 低い △ 普通 運⽤コスト × ⾼い × ⾼い 全環境コード共通化 × 不可 ◦ ほぼ可能 画⾯要素検出⼿法
48. 技術選定 組み合わせ手法の特徴 スクリプト＋AI(LLM) 画像認識＋AI (LLM) 構造取得＋テキスト 画像＋テキスト 柔軟性 (UI変更への強さ) ◦ ⾼い ◦ ⾼い アプリ側実装 × 必要 ◦ 不要 端末差異の吸収 ◦ 可能 ◦ 可能 保守コスト ◦ 低い △ 普通 運⽤コスト × ⾼い × ⾼い 全環境コード共通化 × 不可 ◦ ほぼ可能 画⾯要素検出⼿法
49. SECTION 01-04 自動化の範囲と開発の流れ
50. 自動化の範囲 自動化と手動の役割分担 運⽤フロー テスト 準備 ゲーム 開始 画⾯ 遷移 購⼊ 付与 確認 エビ デンス 保存 OKNG 判断
51. 自動化の範囲 自動化と手動の役割分担 運⽤フロー テスト 準備 ゲーム 開始 画⾯ 遷移 購⼊ ⾃動化 ※テスト項⽬の変更なし 付与 確認 エビ デンス 保存 OKNG 判断
52. 開発体制 エンジニアと QAの協働 エンジニア（ 2名） QA（2名） ハードウェア構築、Agent/Action実装、 要件定義、運⽤、保守‧改修 CI/GUI整備
53. 開発の流れ ⼯程 内容 主担当 要件定義 ⾃動化の範囲決め QA 実装 AI Agent 開発 導⼊ 実機での動作確認 エンジニア/QA 改修 トラブル対応、改修 QA エンジニア
54. 開発の流れ ⼯程 内容 主担当 要件定義 ⾃動化の範囲決め QA 実装 AI Agent 開発 導⼊ 実機での動作確認 エンジニア/QA 改修 トラブル対応、改修 QA エンジニア
55. SECTION 02 開発
56. 自己紹介 NAME 名前 伊藤⼀樹 AFFILIATION 所属 株式会社WFS/スタジオ本部/リードエンジニア ROLE & ACTIVITIES 主な活動  サーバーサイドエンジニア  AIを活⽤したツール作成や基盤構築
57. 実装したもの ENGINE INTERFACE ワークフローエンジン 実⾏確認⽤のGUI ⾃動化処理の中核を担う実⾏制御システム エンジンの動作状況をリアルタイムで可視化
58. 本題に入る前に ... 出⼒A 「きのこ派」 ⼊⼒プロンプト 「きのこ派？たけのこ派？」 出⼒B 「たけのこ派」 決定論的(Deterministic) ⾮決定論的(Non-Deterministic) 同じ⼊⼒ → 同じ出⼒ 同じ⼊⼒ → 異なる出⼒
59. 本題に入る前に ... 出⼒に揺らぎが⽣じる 出⼒A 「きのこ派」 ⼊⼒プロンプト 「きのこ派？たけのこ派？」 出⼒B 「たけのこ派」 決定論的(Deterministic) ⾮決定論的(Non-Deterministic) 同じ⼊⼒ → 同じ出⼒ 同じ⼊⼒ → 異なる出⼒
60. 自動化で実現したいフロー ゲーム 開始 ホーム 画⾯遷移 ショップ 画⾯遷移 アイテム 購⼊ 購⼊ アイテム 確認
61. 自動化で実現したいフロー ゲーム 開始 ホーム 画⾯遷移 ショップ 画⾯遷移 アイテム 購⼊ 購⼊ アイテム 確認 フロー⾃体は決定論的(同じ⼊⼒で同じ出⼒を期待)
62. 目指すべきワークフローエンジン ⾮決定論的なLLMを⽤いて 決定論的なワークフローを回すための フレームワーク
63. 目指すべきワークフローエンジン 2022年 プロンプトエンジニアリング 2025年 コンテキストエンジニアリング 2026年初頭 ハーネスエンジニアリング 要するに Computer Use系における ハーネスエンジニアリング と ガードレールの実装
64. 用意したハードウェア PC ミラーリングソフト OS間での差異を減らす PC版ゲーム アプリケーション 画像認識 ↓ PC上で操作(クリック等) が⾏えるようにする iPhone Android
65. 用意したハードウェア PC ミラーリングソフト OS間での差異を減らす PC版ゲーム アプリケーション 画像認識 ↓ PC上で操作(クリック等) が⾏えるようにする iPhone Android
66. 用意したハードウェア PC ミラーリングソフト OS間での差異を減らす PC版ゲーム アプリケーション 画像認識 ↓ PC上で操作(クリック等) が⾏えるようにする iPhone Android
67. 実装したワークフロー ゲーム開始して ショップ画⾯まで遷移 アイテム購⼊ 成功 購⼊アイテム確認 成功 AgentNode AgentNode TaskNode 完了判定 完了判定 完了判定
68. 実装したワークフロー ゲーム開始して ショップ画⾯まで遷移 アイテム購⼊ 成功 購⼊アイテム確認 成功 AgentNode AgentNode TaskNode 完了判定 完了判定 完了判定
69. 実装したワークフロー ゲーム開始して ショップ画⾯まで遷移 アイテム購⼊ 成功 購⼊アイテム確認 成功 AgentNode AgentNode TaskNode 完了判定 完了判定 完了判定
70. 実装したワークフロー ゲーム開始して ショップ画⾯まで遷移 アイテム購⼊ 成功 購⼊アイテム確認 成功 AgentNode AgentNode TaskNode 完了判定 完了判定 完了判定
71. AgentNode 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック AgentNodeとは 本ワークフローの核⼼部分 画像認識でPC操作を⾏う Gemini Live APIによるAgentic Loop(知覚→思考→⾏動)を⾏う 完了の状態 を返す
72. AgentNode プロンプト 注⼊ 開始 Agentic Loop 完了条件の チェック User Instruction 何をするか（このAgentの具体タスク) 例: ショップで◯◯を購⼊する System Instruction ⾏動規範 例: 出⼒形式‧制約‧画⾯定義‧利⽤可能アクション 完了の状態 を返す
73. AgentNode 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 完了の状態 を返す User Instruction スタートボタンをタップしてゲームを開始すること。 ホーム画⾯が開いたらXXボタンを押してショップ画⾯を開くこと。 System Instruction 出⼒形式、役割、画⾯定義、ゲーム内ドメイン知識 思考フィールド、選択できるアクション
74. AgentNode 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 完了の状態 を返す User Instruction スタートボタンをタップしてゲームを開始すること。 ホーム画⾯が開いたらXXボタンを押してショップ画⾯を開くこと。 System Instruction 出⼒形式、役割、画⾯定義、ゲーム内ドメイン知識 思考フィールド、選択できるアクション
75. AgentNode 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック Agentic Loop 知覚 • 1秒おきに画⾯のスクリーンショットを送り続ける 思考 • 与えられたタスクから何を⾏うか選択する ⾏動 • LLMが選択した⾏動を実際に⾏う 完了の状態 を返す
76. AgentNode プロンプト 注⼊ 開始 知覚 Agentic Loop Gemini Live API 完了条件の チェック 完了の状態 を返す 思考 - 状態 画⾯分類 ⾏動の選択理由 ⾏動選択 ⾏動 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key - クリック 待機 ショートカットキー等
77. AgentNode プロンプト 注⼊ 開始 知覚 Agentic Loop Gemini Live API 完了条件の チェック 完了の状態 を返す 思考 - 状態 画⾯分類 ⾏動の選択理由 ⾏動選択 ⾏動 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key - クリック 待機 ショートカットキー等
78. AgentNode プロンプト 注⼊ 開始 知覚 Agentic Loop Gemini Live API 完了条件の チェック 完了の状態 を返す 思考 - 状態 画⾯分類 ⾏動の選択理由 ⾏動選択 ⾏動 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key - クリック 待機 ショートカットキー等
79. AgentNodeの知覚 プロンプト 注⼊ 開始 知覚 Agentic Loop Gemini Live API 完了条件の チェック 完了の状態 を返す 思考 - 状態 画⾯分類 ⾏動の選択理由 ⾏動選択 ⾏動 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key - クリック 待機 ショートカットキー等
80. AgentNodeの知覚 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 完了の状態 を返す 典型的なAgenticLoop このシステムのAgenticLoop ループ処理 逐次的 (知覚→思考→⾏動は順番に⾏う) ⾮同期的 (知覚と思考→⾏動は別ループ) セッション 呼び出しごとに再構築 永続的な双⽅向セッション 向いている ⽤途 静的‧離散的なUI リアルタイムに変化するUI
81. AgentNodeの思考 開始 プロンプト 注⼊ Agentic Loop 毎ターンLLMが⽣成する構造化出⼒(JSON) - 画⾯に⾒えるものを詳細に記述 - 画⾯分類の根拠 - 画⾯分類 - ⾏動選択の根拠 - ⾏動選択 完了条件の チェック 完了の状態 を返す
82. AgentNodeの思考 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 完了の状態 を返す 毎ターンLLMが⽣成する構造化出⼒(JSON) - 画⾯に⾒えるものを詳細に記述 - 画⾯分類の根拠 - 画⾯分類 - ⾏動選択の根拠 - ⾏動選択 前から順番にトークン⽣成
83. AgentNodeの思考 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 毎ターンLLMが⽣成する構造化出⼒(JSON) { “画⾯に⾒えるものを詳細に記述”: “右下にメニューボタンがある”, “画⾯分類の根拠”: “メニューボタンが右下にあるため”, “画⾯分類”: “ホーム画⾯”, “⾏動選択の根拠”: “ホーム画⾯ではメニューボタンを押下し、ショップ画⾯を開く必要がある” “⾏動選択”: “メニューボタンを押下”, } 完了の状態 を返す
84. AgentNodeの思考 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 毎ターンLLMが⽣成する構造化出⼒(JSON) { “画⾯に⾒えるものを詳細に記述”: “右下にメニューボタンがある”, “画⾯分類の根拠”: “メニューボタンが右下にあるため”, “画⾯分類”: “ホーム画⾯”, “⾏動選択の根拠”: “ホーム画⾯ではメニューボタンを押下し、ショップ画⾯を開く必要がある” “⾏動選択”: “メニューボタンを押下”, } 完了の状態 を返す
85. AgentNodeの行動 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 完了の状態 を返す 要素クリック パスワード⼊⼒ 待機 完了
86. AgentNodeの行動 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 完了の状態 を返す 要素クリック パスワード⼊⼒ 待機 完了
87. AgentNodeの行動(要素クリック ) 開始 プロンプト 注⼊ 処理フロー - ⾃然⾔語で対象指定 - 座標検出 - クリック Agentic Loop 完了条件の チェック 完了の状態 を返す ⾃然⾔語で対象指定 メインLLM(Gemini Live API)が クリックするべき要素を ⾃然⾔語で記述 - 効いたか検証 例 緑⾊の四⾓いボタン
88. AgentNodeの行動(要素クリック ) 開始 プロンプト 注⼊ 処理フロー Agentic Loop 完了条件の チェック 完了の状態 を返す 座標検出ロジック - ⾃然⾔語で対象指定 1. 登録された固定座標 - 座標検出 2. OpenCVテンプレートマッチング - クリック 3. Gemini APIによる2Dバウンディン - 効いたか検証 グボックス検出
89. AgentNodeの行動(要素クリック ) 開始 プロンプト 注⼊ 処理フロー Agentic Loop 完了条件の チェック 完了の状態 を返す 座標検出ロジック - ⾃然⾔語で対象指定 1. 登録された固定座標 - 座標検出 2. OpenCVテンプレートマッチング - クリック 3. Gemini APIによる2Dバウンディン - 効いたか検証 グボックス検出
90. AgentNodeの行動(要素クリック ) 開始 プロンプト 注⼊ 処理フロー Agentic Loop 完了条件の チェック 完了の状態 を返す 座標検出ロジック - ⾃然⾔語で対象指定 1. 登録された固定座標 - 座標検出 2. OpenCVテンプレートマッチング - クリック 3. Gemini APIによる2Dバウンディン - 効いたか検証 グボックス検出
91. AgentNodeの行動(要素クリック ) 開始 プロンプト 注⼊ 処理フロー Agentic Loop 完了条件の チェック 完了の状態 を返す 座標検出ロジック - ⾃然⾔語で対象指定 1. 登録された固定座標 - 座標検出 2. OpenCVテンプレートマッチング - クリック 3. Gemini APIによる2Dバウンディン - 効いたか検証 グボックス検出
92. AgentNodeの行動(要素クリック ) 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 完了の状態 を返す 処理フロー 画⾯検証 - ⾃然⾔語で対象指定 1. 画⾯に変化があることを期待する - 座標検出 - クリック - 効いたか検証 か？(しないならそこでOKとする) 2. OpenCVで差分検出
93. AgentNodeの行動(要素クリック ) 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 完了の状態 を返す 処理フロー 画⾯検証 - ⾃然⾔語で対象指定 1. 画⾯に変化があることを期待する - 座標検出 - クリック - 効いたか検証 か？(しないならそこでOKとする) 2. OpenCVで差分検出
94. AgentNodeの行動(要素クリック ) 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 完了の状態 を返す 処理フロー 画⾯検証 - ⾃然⾔語で対象指定 1. 画⾯に変化があることを期待する - 座標検出 - クリック - 効いたか検証 か？(しないならそこでOKとする) 2. OpenCVで差分検出
95. AgentNode 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 完了条件のチェック LLMがタスク完了を通知してきたら決定論的にチェックする • 画⾯の再検証とfinish条件の確認 • エビデンス(証拠スクリーンショット)の存在確認 未達なら再度Agentic Loopに処理を戻す 完了の状態 を返す
96. AgentNode 開始 プロンプト 注⼊ 完了の状態を返す タスクの状態を成功/失敗で返す • 成功: 次のNodeに遷移 • 失敗: ワークフローを中断 Agentic Loop 完了条件の チェック 完了の状態 を返す
97. 実装したワークフロー ゲーム開始して ショップ画⾯まで遷移 アイテム購⼊ 成功 購⼊アイテム確認 成功 AgentNode AgentNode TaskNode 完了判定 完了判定 完了判定
98. TaskNode 開始 タスク実⾏ TaskNodeとは ⾮AIで決定的な⼿続き処理 • アプリの再起動処理 • 確実に漏れなく遂⾏してほしい処理 • 座標検出にのみLLMを使⽤ 完了の状態 を返す
99. TaskNode 開始 タスク実⾏ TaskNodeの使⽤箇所(確実に実⾏してほしい) ギフトボックスにN個あるアイテムを順番に受け取る 1. ギフトボックスをタップ 2. ギフト詳細画⾯でスクリーンショット 3. ギフト受け取り 4. ギフトが存在する限り1から再度実⾏ 完了の状態 を返す
100. AgentNodeとTaskNodeの使い分け 判断軸 AgentNode TaskNode 手順の確定度 状況次第で変わる 完全に確定・毎回同じ 処理速度 遅い(ターンごとに思考 ) 早い(判断オーバーヘッドなし ) 保守コスト 低い(動的にLLMが判断) 高い 失敗許容度 探索的でリカバリ前提 確実に完遂が必要な操作
101. AgentNodeとTaskNodeの使い分け 判断軸 AgentNode TaskNode 手順の確定度 状況次第で変わる 完全に確定・毎回同じ 処理速度 遅い(ターンごとに思考 ) 早い(判断オーバーヘッドなし ) 保守コスト 低い(動的にLLMが判断) 高い 失敗許容度 探索的でリカバリ前提 確実に完遂が必要な操作
102. ガードレール 開始 プロンプト 注⼊ ワークフローの無限実⾏を阻⽌ - LLMの消費トークン数 - 実⾏時間 - エラー連続N回 Agentic Loop 完了条件の チェック 完了の状態 を返す
103. ハマりどころ 開始 プロンプト 注⼊ Agentic Loop 完了条件の チェック 完了の状態 を返す Gemini Live API - 接続時間が⻑くなるとセッションが切れがち - 反応がないときにこちらから「続けて」と指⽰を出す必要がある
104. SECTION 02-02 導入時の課題と解決方法
105. 課題1：開発者と運用者の環境差異による運用エラー 現象： 開発者のMac環境と運⽤者の環境で解像度、 解決策 パス、権限、設定が異なり、運⽤開始時にエラー ‧dotenvxによる環境変数の暗号化管理 が発⽣ ‧Google Cloud Secret Managerでの認証 情報⼀元管理 ‧CLIコマンドとWebベースGUIによる環境 差異の吸収
106. 課題2：運用者の技術スキルへの配慮 現象： 当初はターミナルでのコマンド操作が必要だったが、 ⾮エンジニアのQA担当者には敷居が⾼かった 解決策 ‧CLIコマンドにインタラクティブモード実装 ‧前回の実⾏設定を記憶し、2回⽬以降の実⾏ を簡略化 ‧WebベースのGUIを開発し、更新、ログ確 認、エビデンス確認、アップデートなど、運⽤ に必要な機能は全てそこで⾏えるようにした
107. 課題2：運用者の技術スキルへの配慮 WebベースのGUI
108. SECTION 02-03 QAによる改修
109. QAによる改修 改修事例①：ワークフローの追加 購⼊までのワークフロー実装 ゲーム開始して ショップ画⾯まで遷移 アイテム確認 アイテム購⼊ 購⼊アイテム確認 AgentNode AgentNode AgentNode TaskNode 完了判定 完了判定 完了判定 完了判定
110. QAによる改修 改修事例①：ワークフローの追加 購⼊までのワークフロー実装 ゲーム開始して ショップ画⾯まで遷移 アイテム確認 アイテム購⼊ 購⼊アイテム確認 AgentNode AgentNode AgentNode TaskNode 完了判定 完了判定 完了判定 完了判定 ここまで
111. QAによる改修 改修事例②： NodesLoopの実装 特定のAgentNodesを指定回数実⾏する複合ノードの実装 改修前：1回の実⾏で購⼊できるアイテムは1回のみ 何回も実⾏する必要がある ↓ 改修後：1回の実⾏で指定回数分購⼊できる 基本1回の実⾏でテスト完了できる
112. QAによる改修 改修事例②： NodesLoopの実装 特定のAgentNodeを指定回数実⾏する複合ノードの実装 ゲーム開始して ショップ画⾯まで遷移 アイテム購⼊ 成功 購⼊アイテム確認 成功 AgentNode AgentNode TaskNode 完了判定 完了判定 完了判定 ここをLoopさせる
113. SECTION 03 運用結果
114. 削減効果 14.7人日 自動化前（人日 /月） 自動化後（人日 /月） 4.4人日 ▲ 10.3人日/月 削減⼯数 70% コスト削減率
115. 初期導入コストと運用コスト 初期導入コスト エンジニア工数 80人日 QA工数 15人日 運用コスト APIコスト 約 1.9万円/月 QA工数 4.4人日/月
116. 現在の課題（ 1/3） HW/インフラ面 ミラーリングアプリケーションの⻑時間接続安定性 停電‧ネットワーク障害時における物理復旧の必要性 金曜日 正常にミラーリング 接続されている状態 休日 月曜日 物理復旧 微細な瞬 リモートでのミラー サーバールームへ赴 断やOSのスリープに リング再開が不可能 き、実機を⼿動操作 無⼈稼働 より接続が切断 して再接続
117. 現在の課題（ 2/3） UI要素認識失敗 ‧ホーム画⾯からクォーツショップ遷移ボタン ‧Steamプラットフォームの購⼊ボタン ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key
118. 現在の課題（ 3/3） 自動化の範囲の拡張 ボタン操作以外の複雑なカメラ‧移動操作への対応が困難 ⾮決定的なUI（演出アニメーション等）の評価が困難 ワイルドエリア 3D移動の動画 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key 初期SSのEXスキル演習動画 ©WFS Developed by WRIGHT FLYER STUDIOS © VISUAL ARTS/Key
119. SECTION 04 まとめと今後の展望
120. まとめと今後の展望 まとめ ‧QAとエンジニアの協働により、実運⽤に耐えるシステムを構築 ‧LLMと画像認識の組み合わせにより、柔軟な画⾯認識と⾃動操作が可能に ©WFS
121. まとめと今後の展望 まとめ ‧QAとエンジニアの協働により、実運⽤に耐えるシステムを構築 ‧LLMと画像認識の組み合わせにより、柔軟な画⾯認識と⾃動操作が可能に 約70%のQA⼯数削減を達成 QAが定型作業から解放され、より専⾨性の⾼い業務に集中できる ©WFS
122. まとめと今後の展望 まとめ ‧QAとエンジニアの協働により、実運⽤に耐えるシステムを構築 ‧LLMと画像認識の組み合わせにより、柔軟な画⾯認識と⾃動操作が可能に 約70%のQA⼯数削減を達成 QAが定型作業から解放され、より専⾨性の⾼い業務に集中できる 半年以上稼働継続 使えば使うほど⼯数が削減される ©WFS
123. まとめと今後の展望 今後の展望 ‧フレームワークを汎⽤化し、他タイトルへ展開 ‧決済検証以外の定型作業の⾃動化 ©WFS
124. ご清聴ありがとうございました
125. ©WFS