ローカルVision AIを約半分の時間にできたのに、採用しなかった理由

Posted at 2026-10-19

はじめに

Windowsの操作から、スクリーンショット付きの手順書を作る Local Manual Maker（LMM）を個人開発しています。

今回は、画像からクリック対象を読み取り、説明文を補正するVision機能の高速化を試した話です。

当時は1件あたり約25秒かかっていました。同じモデルのまま入力画像や出力を軽くして、10〜15秒を目指したところ、約13秒になった条件もありました。

ただ、最終的にはどれも採用せず、元の設定を残しました。

対象は2026年10月13日に行った、開発中の LMM 2.0.2・内部ビルドb38での検証です。現在の製品の処理時間を示すものではありません。

13件は、採用済み説明文を正解とした9件と、別途保全していた4件です。文字付き項目、ファイルやフォルダー、小さなアイコン、既知の誤認識も含めました。

この記事では、当時のログと比較スクリプトを読み直して集計を確認しています。推論の再実行はしていません。

基準は「全体画像＋クリック周辺の切り出し画像」です。切り出しだけにする、画像トークン上限を減らす、出力を軽くする条件を試しました。

条件	2件目以降の平均	正しい	表記差	誤り	要目視
基準のb38	26.3秒	9	2	1	1
切り出し画像のみ	12.9秒	5	1	6	1
画像トークン上限512	20.3秒	6	1	5	1
切り出しのみ＋上限512	13.0秒	5	1	6	1
出力軽量化を試みた条件	27.9秒	9	2	1	1

時間は各条件の初回を除く12件の平均で、中央値ではありません。正誤の件数は初回を含む13件です。

計測区間は、画像加工や要求データ作成を終えた後の、HTTP要求から応答の解析までです。サーバー起動や画像準備を含む、アプリ全体の待ち時間ではありません。基準の初回25.3秒も、モデル起動込みの時間とは扱えません。

この表は、固定の正解表との文字列比較です。

大文字・小文字は区別しません。実行失敗と空ラベルは別区分で、今回はともに0件でした。

つまり、意味を人が一件ずつ採点した認識精度とは違います。「表記差」「要目視」を成功に合算した正答率にもしていません。

クリック周辺の切り出し画像だけにすると、平均時間は約半分になりました。ただし、判定上の誤りは1件から6件へ増えました。

当時の報告には、「Windows (C:)」を「Users」と答える例もありました。クリック周辺だけでは、画面全体の位置関係や周辺情報が足りなくなる可能性があります。ただし、原因まで切り分けた実験ではありません。

基準の --image-max-tokens 1024 を 512 にした条件では、平均20.3秒、判定上の誤りは5件でした。

512は画像トークンの上限です。「画像を512ピクセルに縮小した」という条件ではありません。

evidence を省く変更を試みた条件では、平均27.9秒で短縮効果を確認できませんでした。

ただ、原記録を見直すと、入力トークン数は基準と全件同じで、生成トークン数の平均もほぼ同じでした。送信したプロンプトや応答全文は残っておらず、意図した削減が実際に効いたかは未確認です。

この結果だけで「出力を減らしても速くならない」と一般化することはできません。変更した設定が実際の要求に反映されたかも、比較の前提になります。

手順書に別のボタン名やフォルダー名が入ると、そのまま使えません。人が提案を確認する前提でも、修正が増えれば作業時間に影響します。

約13秒という目標には届きましたが、従来と同じ結果を保った高速化は確認できませんでした。当時の報告では、b38の設定を維持し、製品コードも変更しませんでした。

一般的なクライアントPCでの利用を考えているため、GPUを前提にすることも見送りました。GPUなら何倍になるかは測っていません。

13件・各条件1回の小さな比較です。各ログに同じ13件の識別子があることは確認しましたが、画像原本や正解ラベルの目視再検証はしていません。CPU構成も当時の報告に基づき、今回独立に確認したものではありません。

既知の「閉じる」を「Pictures」と答える誤認識も残っていました。基準設定も完全ではありません。

次に測るなら、正解ラベルを画像と照合し、未使用の画像と複数回の測定を加えたいところです。さらに、人が確認・修正して手順書を完成させるまでの時間も見る必要があります。

今回残せたのは、速くなった条件と、そこで変わった回答の記録でした。採用を見送った結果も、次の改善を考える材料になりました。