はじめに
Windows操作からスクリーンショット付き手順書を作る「Local Manual Maker（LMM）」を個人開発しています。
クリック対象の情報を取得する方法としてWindows UI Automationを利用していますが、画面によっては対象名を十分に取得できません。
そこで、記録した画面画像から操作対象を読み取るため、小型のVision Language Model（VLM）を比較しました。
この記事では、2026年9〜10月の開発時に行った比較と、モデルを選ぶまでの経緯を整理します。一般的なモデルランキングではなく、Windowsの操作画面からクリック対象を説明する用途に限定した記録です。
1. 精度以外にも、外せない条件があった
今回の用途では、次の条件も検討対象でした。
- 画像や説明文を外部のクラウドAIへ送らず、PC内で処理できること
- 商用利用とモデルの同梱配布について条件を確認できること
- WindowsのCPU環境で実行を検討できること
- アプリの配布容量が大きくなりすぎないこと
- 推論時間やメモリ使用量が用途に見合うこと
精度が高ければ、そのまま採用できるわけではありません。アプリに組み込んで配布するところまで含めて選ぶ必要がありました。
なお、ここでいうローカル実行は推論処理の話です。ダウンロードや購入などの通信まで不要という意味ではありません。
2. 比較したモデル
比較対象は次の4モデルです。
| モデル | 比較で確認したこと |
|---|---|
| Qwen3.5-2B | 対象認識と、文章処理も含めた統合の可能性 |
| Holo-3.1-0.8B | 小さいモデルの速度・容量と対象認識 |
| Qwen3-VL-2B-Instruct | 画面画像の認識と入力方法による違い |
| LFM2.5-VL-1.6B | 同じ評価セットでの対象認識 |
初期のQwen3-VLのPoCでは、Windows x64のCPU環境とllama.cppを使いました。Qwen3-VLの当該条件はQ4_K_MとQ8_0のprojector、Qwen3.5の別の評価条件はQ4_K_Mとf16のprojectorです。
モデルごとに構成が異なるため、「パラメーター数だけをそろえた公平な能力比較」とは扱っていません。
3. JSONが返ることと、対象を正しく読めることは別だった
最初に確認したかったのは、クリックした場所を適切に説明できるかです。
入力方法も変えて試しました。
- 元の画像とクリック座標
- マーカーを付けた画像とクリック座標
- マーカー画像、周辺の切り抜き画像、座標、UI Automationなどの情報
初期のQwen3-VL評価では、12ケース×3条件の36出力すべてが有効なJSONでした。しかし、クリック対象の取り違えは残りました。
マーカーを付ければ必ずよくなるわけでもありません。マーカー自体を操作対象として答える例もありました。
このため、評価は少なくとも次の二つに分けました。
- 形式の評価：JSONとして読み取れるか
- 内容の評価：クリック対象と説明が合っているか
形式が整っていても、画像内の別のボタンを選んでいれば、そのまま手順書には使えません。
4. 評価画像を分けると、結果の見え方が変わった
一般的な画面でよい結果が出ても、UI Automationの情報が弱い画面で同じように使えるとは限りません。
そこで、評価セットを分けました。
- 一般の画面：20件
- 比較的読み取りやすいUIA-weakの画面：10件
- 小さい文字や対象が密集したHard UIA-weakの画面：20件
最初の一般20件は、その時点では未使用の評価用データでした。ただし、後の条件修正でも同じデータを再利用しています。再測定の段階まで「新しい未使用データ」と呼ぶことはできません。
5. モデルの差だと思う前に、実際の入力を確認した
比較中に、PowerShell経由とC#経由で結果が一致しない問題がありました。
調べると、今回のWindows PowerShell 5.1から長い複数行のプロンプトを引数で渡す経路では、JSON schemaのキーを囲む二重引用符が、子プロセスに届くまでに欠落していました。
コード内に同じ文字列があることと、推論プログラムが同じ文字列を受け取ることは別でした。
実際に受信した引数を取得し、引用符が欠けた文字列を別経路から再入力したところ、Qwen3.5とHoloのそれぞれで、Hard 20件の旧出力を20件とも再現できました。
これは認識精度100%という意味ではありません。以前の結果を再現できた、という確認です。
その後、C#側ではProcessStartInfo.ArgumentListを使って引用符を保持する経路にそろえ、再測定しました。
モデルの出力が変わったときは、モデル名や生成設定だけでなく、実際に受信したプロンプトまで確認する必要がありました。
6. 修正後の結果も、評価セットごとに見る
以下は、引用符の問題を修正した後の記録を、PASS件数で整理したものです。PARTIALはPASSに含めていません。
| モデル | 一般20件 | Easy 10件 | Hard 20件 |
|---|---|---|---|
| Qwen3.5-2B | 13/20 | 8/10 | 8/20 |
| Holo-3.1 | 8/20 | 5/10 | 4/20 |
| Qwen3-VL-2B | 9/20 | 9/10 | 2/20 |
| LFM2.5-VL | 9/20 | 1/10 | 1/20 |
少数の用途別テストなので、この表からモデル全般の優劣は判断できません。画像セットや採点条件、量子化・実行設定の全情報もこの記事だけでは提供できていないため、再現可能な公開ベンチマークではありません。
また、Qwen3.5のHardが8/20だったことは、「Windows操作全般で成功率40%」という意味ではありません。難しい画面を集めた、この評価セットの結果です。
Qwen3-VLはEasyではよい結果でしたが、今回のHardでは差がありました。採用判断では、自分が補いたい画面に近いデータを見る必要があります。
7. Holoの速さも魅力だったが、まず単独構成を選んだ
最終候補では、Qwen3.5とHoloの実行時間や容量も比較しました。
当時のRuntime評価では、処理時間はHoloが約23秒、Qwen3.5が約65秒でした。これは当時の評価条件での値であり、現在のアプリの処理時間を保証する数値ではありません。
配布容量も、当時の追加ファイルの集計で次の違いがありました。
- Holoのみ：約0.78 GiB
- Qwen3.5のみ：約1.97 GiB
- 両方：約2.70 GiB
小さいモデルを先に使い、難しい場合だけ大きいモデルへ回す構成も考えられます。ただし、そのためには「最初の回答を信用してよいか」を判定する仕組みが必要です。
今回は、その判定を十分に確立できていませんでした。対象認識の結果、構成の複雑さ、配布容量を合わせて考え、まずQwen3.5-2B単独で進めることにしました。
8. 最後は文章と画像でモデルを共用した
もともとの文章処理用モデルと、Vision用モデルを別々に同梱すると、配布容量が増えます。
その後の開発では、Qwen3.5で文章と画像の両方を扱う構成を検証し、モデルを一本化しました。
10月7日の開発ビルド比較では、圧縮MSIXが約3.042 GiBから1.855 GiB、展開後のpayloadが約3.965 GiBから2.166 GiBへ減りました。
これは、その開発ビルド間での配布物の容量比較です。メモリ使用量の削減率や、認識精度の向上を示す数字ではありません。
モデル選定と、実際に配布できる構成への整理は、別の確認として進めました。
9. 同梱するファイルの出所も確認する
同梱配布では、モデルの名前やモデルカードだけでなく、実際に使う量子化ファイルやprojectorの出所も確認しました。
今回のQwen3.5では、配布元のファイルサイズとSHA256を照合し、使用したGGUFとprojectorの出所を確認しています。
利用条件は、モデル本体だけでなく、変換物や推論ランタイムも含めて確認する必要があります。この記事を、各モデルの商用利用や再配布を一律に保証するものとしては扱わないでください。
まとめ
今回の比較で確認すべきだったのは、精度の数字だけではありませんでした。
- JSONが有効でも、認識内容が正しいとは限らない
- 読み取りやすい画面と難しい画面を分けて評価する
- コード内の文字列だけでなく、実際に届いた入力を確認する
- 速度・メモリ・配布容量は、それぞれ別の指標として見る
- 複数モデルを使うなら、切り替え判断の仕組みも必要になる
- 最後は、アプリに組み込んだ状態で確認する
小型VLMを選ぶ作業は、モデルのランキングを見るだけでは終わりませんでした。自分の用途に合う評価画像と、実際に動かす経路を用意することが重要だと感じました。
開発しているアプリ
Local Manual Maker（LMM）は、Windows操作を記録し、スクリーンショット付きの手順書をWord／Excelへ出力するアプリです。主要処理はPC内で完結し、AIによる説明文の補助は記録後に任意で実行する構成です。