VLM（Vision-Language Model）によるUI画像認識という選択肢
はじめに
ゲーム画面解析やUI認識といったタスクでは、これまで
- OpenCV + ルールベース
- OCR（Tesseractなど）
- 小型CNNによる数字分類
といった手法が王道でした。
一方で近年は VLM（Vision-Language Model） が実用レベルに到達し、「画像を見て、意味のある構造化データを返す」ことが可能になっています。
本記事では、特定のリアルタイム対戦型モバイルゲームの対戦画面を対象に、
- VLMはUI数値認識に使えるのか？
- 速度は実用レベルか？
を 実測ベンチマーク に基づいて検証した結果をまとめます。
※2026/1/10時点
なぜVLMを試すのか
対象ゲームの画面には以下のような情報があります。
- 時刻タイマー（右上：M:SS）
- 数値エネルギー量（下部：0〜10）
- 数値HP（状況によって表示）
これらは
- 位置が固定
- 表示形式が安定
- 人間には一瞬で読める
という特徴があり、VLMが一番得意そうにも見えます。
一方で懸念もあります。
- 推論が重いのでは？
- フル画面だと遅すぎるのでは？
そこで、実際に測って判断するため、専用のベンチ環境を作りました。
ベンチ環境
評価パイプライン
以下の流れで検証しています。
- scrcpyで取得したプレイ画面フレーム（jpg）※1080×2400
- 正解データ（gt.jsonl）を人手で作成
- VLM predictor で推論
- JSONLで出力
- 精度・レイテンシを自動評価
評価指標
- timer_acc：時刻タイマー一致率
- energy_acc：数値エネルギー一致率
- avg_latency_ms：1枚あたり平均推論時間
検証したモデル
Qwen2.5-VL-3B-Instruct
- VLMの定番
- OCR / UI理解に強い
Qwen3-VL-2B-Instruct
- より軽量（2B）
- 新世代VLM
どちらも Transformers + CUDA（GPU） で実行しています。
計測環境
CPU：AMD Ryzen 7 5700
MEM：32GB
GPU：GeForce RTX 5060Ti(16GB)
CUDA：12.8
ベンチ結果
Qwen2.5-VL-3B（フル画面）
images: 50
timer_acc: 1.0
energy_acc: 0.676
avg_latency_ms: 7848
- タイマーは完全に読める
- 数値リソースはブレあり
- 約8秒/枚 → 実用不可
Qwen3-VL-2B（フル画面）
images: 50
timer_acc: 1.0
energy_acc: 1.0
avg_latency_ms: 4959
- タイマー・数値リソースとも 100%
- レイテンシは約5秒/枚
👉 精度は大幅改善、速度はまだ厳しい
考察：VLMは使えるのか？
精度面
- UI数値（timer / elixir）は VLMで十分に読める
- 特に Qwen3-VL-2B は非常に安定
速度面
- フル画面VLMは重い
- 録画フレーム（高解像度）は最悪ケース
実運用を考えると
重要なポイントはここです。
scrcpyウィンドウを直接キャプチャする場合
- 解像度は 540〜720px 程度
- フルHD録画より 画素数が1/3以下
- Vision Encoderの計算量が大きく減る
👉 2〜3倍の高速化は現実的
ROI（部分切り出し）を併用すると
- timer / energy 領域のみを入力
- 入力画像が極小化
👉 0.5〜1秒/枚 まで落とせる可能性あり
結論
-
VLMはUI数値認識の有力な選択肢
-
フル画面では遅いが、
- 小さな入力
- ROI
- 低頻度推論
を前提にすれば 実用圏内
-
Qwen3-VL-2B は
- 精度：◎
- 速度：△（工夫前提）
次のステップ
- scrcpyキャプチャ前提で再ベンチ
- ROI版VLM predictorの実装
- CV/OCRとのハイブリッド構成
VLMは「万能」ではありませんが、
使いどころを選べば、非常に強力な道具になると分かりました。
以上