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は「万能」ではありませんが、
使いどころを選べば、非常に強力な道具になると分かりました。

以上