ローカルVLMでデスクトップ操作を自動化｜OmniParser前処理で視覚トークン負荷を抑える

ローカルVLM自動化とは、スクショを視覚モデルに渡してGUIを操作する手法。

スクリーンショットを撮ってローカルの視覚言語モデル（VLM）に丸ごと渡し、「このボタンを押して」と指示する。動くには動くのですが、小さなアイコンを取り逃し、画面が出てから反応が返るまでがやけに重い——海外のRedditコミュニティ（r/LocalLLaMA）で、Apple Silicon上の量子化VLMでデスクトップGUIを自動操作しようとした人が、この詰まりを投稿していました。基本操作はこなせるのに、密集したUIと小アイコンで崩れる。しかも1枚あたりの視覚トークン数が想定よりはるかに多く、prefill（入力処理）を詰まらせる。同じ壁に当たった人は少なくないようで、コメント欄には具体的な突破口がいくつも挙がっていました。その中心が、OmniParserのような領域分割の前処理です。

この記事の要点

スクショ直渡しの最大のボトルネックは、画面全体が大量の視覚トークンに変換されprefillを圧迫すること
YOLOv8系の検出・OCR・Florence-2系のキャプションで画面をラベル付き要素に構造化する前処理が突破口。後段にテキスト要素だけを渡す設計なら画像由来の視覚トークンを大きく減らせる（Reddit上では5〜10倍削減という未検証報告もあるが、削減幅は実装しだい）
ローカルで動かすなら30B級MoEのQwen3-VL系などが候補。前処理・操作の部品や参考実装は公開されているが、ローカル構成で精度・座標変換・確認フロー・失敗回復まで整えるには用途に応じた統合が要る

スクリーンショット直渡しで詰まる2つの壁
1. 小さいアイコンが「縮小で消える」現象
2. 1枚のスクショが入力を支配する
なぜ視覚トークンが膨らむのか
1. パッチ化と解像度の関係
2. ローカル環境ではprefillが効いてくる
OmniParser前処理という突破口
1. 検出・OCR・キャプションで「読む前に区切る」
2. トークン削減はどこまで効くか（報告値の扱い）
ローカルで使えるモデルとフレームワーク
1. スクショ理解に向くローカルVLM
2. ブラウザ自動化とデスクトップ全体操作の難度差
クラウドAIのcomputer-useと何が違うか
1. 指示を超えて動くクラウドAIの自律性
2. ローカルは「足場」を自分で組む段階
それでも、ローカルで動かす理由
まとめ
よくある質問
参考資料

スクリーンショット直渡しで詰まる2つの壁

VLMにデスクトップ操作をさせる素朴な手順は、画面を撮る → 画像とテキスト指示をモデルに渡す → 出力された座標やアクションを実行する、という流れです。メモ帳を開く、決まった位置のボタンを押すといった単純な操作なら、これで十分機能します。問題は、本番のアプリケーションUIに踏み込んだ瞬間に表面化する。Reddit上の報告でも「基本はいけるが、小さいアイコンと密なUIがつらい」と整理されていました。崩れ方には大きく2系統あると筆者は見ています。

スクショをそのままVLMへ丸投げする方式は、要素が小さいほど消えやすくなります。トグルスイッチ、ツールバーの小さなアイコン、密集したメニュー項目など、ピクセル数の少ないターゲットほど取りこぼしのリスクが上がる点に注意してください。

小さいアイコンが「縮小で消える」現象

VLMやランタイムは、入力上限に合わせて画像を縮小したり、複数タイルに分割したりして処理します。画面全体を縮小して渡す構成では、十数ピクセル程度のアイコンは輪郭や文脈情報が失われやすくなります。一方、タイル分割で細部を保つ設計では、そのぶん視覚トークン数が増えやすいというトレードオフがあります。Reddit上でも、密なUIではグラウンディング（要素の位置特定）が崩れるという声が出ていました。大きなボタンは拾えても、ステータスバーの通知アイコンや小さなチェックボックスになると途端に当たらなくなる。これは個々のモデルの賢さというより、画面の渡し方そのものに起因する構造的な弱点だと考えられます。

1枚のスクショが入力を支配する

もう一つの壁が、視覚トークンの量です。視覚トークン数はモデルと画像前処理に依存します。テキストの指示文がせいぜい数十トークンで済むのに対し、たとえばInternVL2系では448ピクセル四方のタイルを256トークンに変換し、高解像度では最大40タイル×256でおよそ一万トークン、LLaVA-OneVisionのanyres_max_9構成では単一画像が最大7,290トークンに達します。高解像度UIを毎ステップ入力する構成では、画像入力がprefill負荷の主要因になりやすい。つまり、ユーザーの指示よりも「画面を見るためのトークン」が入力の大半を占める。自動操作はワンショットでは終わらず、操作するたびに新しいスクショを撮り直す前提です。その都度この巨大な視覚入力を処理し続けることになる、というのがローカル運用で効いてくるポイント。

なぜ視覚トークンが膨らむのか

視覚トークンが膨らむ仕組みを押さえておくと、後で出てくる前処理が「なぜ効くのか」が腑に落ちます。鍵になるのは、画像がどうトークン化されるか、そしてそのトークン量がローカル環境のどこに効いてくるか、の2点です。

パッチ化と解像度の関係

多くのVLMは、画像を一定サイズの小さな正方形（パッチ）に分割し、各パッチを1つ以上のトークンとして埋め込みます。つまり、画像が大きく解像度が高いほどパッチ数が増え、それに比例して視覚トークンも増えていく。テキストなら「OKボタンを押す」は数トークンですが、その同じ画面を画像で渡すと、何も書かれていない余白や背景まで含めて全面がトークン化されます。デスクトップ全体のような情報密度の高い大判画像を毎回渡せば、入力長が膨らむのは避けられない構造です。視覚トークンが入力を支配していくのは、こういう仕組みからです。

ローカル環境ではprefillが効いてくる

入力トークンが多いと、まずモデルが入力全体を読み込むprefillの段階が重くなります。クラウドの大規模なアクセラレータなら吸収できる負荷でも、限られたVRAMで動かすVRAM 16GBのローカルGPUでは、この入力処理が応答の遅さとして直に表面化する。Redditの投稿者も「視覚トークン数が想定以上で、prefill速度を殺している」と書いていました。ローカル運用は、VRAMとprefillという有限の予算の中でやりくりする世界です。視覚トークンが増えるほどKVキャッシュも膨らみ、実効的に使えるVRAMが目減りしていく。だからこそ「画面をどう渡すか」が、モデル選び以前の設計上の分かれ目になります。

OmniParser前処理という突破口

Redditのコメントで繰り返し挙がっていた解が、OmniParserのような領域分割の前処理を一段かませる方法です。考え方はシンプルで、VLMにピクセルを直接解釈させるのをやめ、先に画面を「読める形」に区切ってから渡す。マイクロソフトが公開したOmniParserは、ファインチューニングしたYOLOv8系の検出モデル、OCR、そしてアイコンの説明を生成するFlorence-2系のモデルを組み合わせ、UIスクリーンショットを構造化されたラベル付き要素の一覧に変換するツールです。

設計の転換点は「ピクセルを丸投げして読ませる」から「先に構造化してから渡す」への切り替えです。検出（detect）→ 文字認識（OCR）→ ラベル付け（label）→ 推論（reason）という流れに分けることで、後段にこの要素リストを渡す設計なら、後段のLLM／プランナーは画面全体を眺める代わりに整理済みの情報を相手にできます（注釈付きスクリーンショットも渡す構成では画像トークンは残ります）。

検出・OCR・キャプションで「読む前に区切る」

前処理の核は、後段のモデルに渡す前に検出・OCR・キャプションのモデル群が画面を構造化してしまう点にあります。YOLOv8系の検出モデルがクリック可能な要素（ボタン、アイコン、入力欄など）の位置を拾い、OCRが画面上のテキストを読み取り、Florence-2系のキャプションモデルがアイコンの意味を言葉で補う。その結果として「要素ID・種類・座標・ラベル」という構造化データが手に入る。後段のLLM／プランナーはこの整理済みの要素リストをもとに「どの要素を操作するか」を判断でき、生のピクセルから位置を割り出す重労働を減らせます。画面全体を縮小するVLMでは失われやすい小アイコンも、専用の検出モデルを前段に置くことで候補要素として残しやすくなります。ただし、実際の検出率はアイコンの大きさ、コントラスト、画面倍率、UIテーマ、検出閾値に左右されます。処理の概念的な流れは次のようになります。

# 概念的な前処理パイプライン
screenshot      = capture_screen()              # 画面を撮る
boxes           = yolo_detect(screenshot)            # 操作対象の要素を検出 (YOLOv8系)
texts           = ocr_read(screenshot)               # 画面内テキストを認識 (OCR)
icons           = caption_icons(boxes, screenshot)   # アイコンの意味を補う (Florence-2系)
labeled_regions = build_elements(boxes, texts, icons)  # 要素ID+座標+ラベルに構造化
action          = planner_decide(instruction, labeled_regions)  # LLM/ルールベースのプランナーが判断
execute(action)                                 # 座標をクリック/入力

ポイントは、後段にテキスト化された要素リストだけを渡す設計にできること。その場合は入力に占める画像由来の視覚トークンが大きく減り、prefillの負荷も連動して軽くなります。一方、注釈付きスクリーンショットもVLMへ渡す構成では視覚トークンは残るため、削減幅は後段の入力設計しだいです。

OmniParser型の前処理パイプライン。画面を丸ごとVLMに渡すのをやめ、検出・OCR・キャプションで要素リストに構造化してから渡すことで、入力の視覚トークンを抑える。

トークン削減はどこまで効くか（報告値の扱い）

どれだけ減るのか。Reddit上では、OmniParser型の前処理で視覚トークンを5〜10倍ほど削減できたという未検証の体感報告があります。ただし、使ったモデルや画像解像度、スクショ枚数、計測方法、OCR結果をテキストだけで渡したのか注釈済み画像も渡したのかが示されておらず、再現可能なベンチマーク値ではありません。実際の削減率は、画面解像度、検出要素数、そして後段モデルに画像を渡すかテキストだけを渡すかによって大きく変わります。一般論として、高解像度画像を全面入力する代わりに関係領域だけをクロップしたり構造化テキストへ置き換えたりすれば入力長を大きく抑えられる余地はありますが、その幅はモデルの画像処理方式と実装に依存します。

OmniParser側の改良も公表されています。マイクロソフトの説明によると、OmniParser V2はアイコン説明モデルが扱う画像サイズを縮小することで、前バージョンと比べてレイテンシを60%削減したとされます。精度面でも、グラウンディングのベンチマークScreenSpot Proで、OmniParserと組み合わせたGPT-4oが平均39.6を記録し、GPT-4o単体の0.8を大きく上回ったと報告されています。Microsoftが公表したScreenSpot Proの評価条件では、OmniParserを組み合わせた構成がGPT-4o単体を大きく上回りました。構造化前処理がグラウンディング改善に寄与し得ることを示す結果ですが、すべてのUI・モデル構成で同程度の差が出ることを意味するものではありません。

ローカルで使えるモデルとフレームワーク

前処理で入力を絞ったら、次は「何で推論するか」です。スクリーンショット理解と要素の位置特定をこなせるローカルVLMと、その上に操作ロジックを載せるフレームワークの組み合わせを見ていきます。

スクショ理解に向くローカルVLM

まず役割を整理します。注釈付きスクリーンショットも後段へ渡すハイブリッド構成では、Qwen3-VLのようなVLMが後段の候補になります。一方、OmniParserの出力をテキスト要素リストだけとして渡す構成なら、後段は通常のLLM／プランナーでもよく、VLMは前段の検出・キャプション処理に限定できます。そのうえで、ローカル運用の候補としては、オープンソースで高性能なVLMがいくつか存在します。例えば、QwenのVLM系列はその一つです。Qwen3-VLはPC・モバイルのGUI要素認識とグラウンディングに対応しており、スクショ理解と要素位置の特定をローカルで回せる。中でもMoE版のQwen3-VL-30B-A3Bは、トークンあたりのアクティブパラメータを約3Bに抑える構成で、計算量やデコード時のメモリ帯域では有利になり得ます。ただし、総30B規模のモデル重みと視覚エンコーダを保持・配置する必要は残るため、必要VRAMが3B級になるわけではありません。ローカル運用では、量子化、CPU/RAMオフロード、複数GPU分割を含めて考える必要があります。ネイティブのコンテキスト長は256Kトークン（最大1Mまで拡張可）とされ、構造化した要素リストや複数ステップの履歴を載せる余地もある。

Redditのコメントには「35B MoEや27B denseで良い結果が出た」という報告もありましたが、モデル名が明示されておらず、どのQwen系列を指すかは断定できません。Qwen3-VLには30B-A3BのMoE版と32Bのdense版があり、別系列のQwen3.5にも35B-A3B（A3B MoE）のような画像対応モデルがあります。元コメントの数字を特定モデルへ直接対応付けるのは避け、ここでは「30B級のローカルVLM」として捉えておくのが安全でしょう。VRAM収支の感覚をつかむために、同規模のMoEモデルの挙動を当サイトの実測から添えます。当サイトの検証環境（RTX 5080単体・VRAM 16GB）で実測したのは、画像入力にも対応するQwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）を、テキスト入力条件で動かした値です。VLMの画像入力時VRAMを直接示すものではなく、モデル規模とCPU/RAMオフロード時の挙動を把握するための参考値として見てください。ただしこのモデルはQ4_K_M量子化でも24GB級のため、16GBのVRAMに完全常駐したわけではなく、Ollama側のCPU/RAMオフロードを含む実行結果です。実際、単体時のGPUメモリ使用量は15.39GiB（nvidia-smi memory.used・デスクトップ等のベースライン込み）で、モデル全体には届いておらず、速度も19.0 tok/sにとどまりました。ここに2枚目のRTX 5060 Ti（VRAM 16GB）をOculinkで足すと、125.3 tok/sまで大きく改善しました。ただし物理VRAMが合計32GBになっても、これは単一の32GB VRAMプールとして自由に使えるわけではありません。モデルやKVキャッシュの配置、GPU間の分割方式、接続帯域はランタイム依存で、この速度向上をそのまま一般化はできない。単一GPUでは速度が伸び悩み、2枚でオフロードが減ると改善する、という関係が読み取れる範囲の参考値です。測定に使ったモデルタグ・量子化・コンテキスト長・Ollama版などの条件は計測ごとに変わり得るため、同じ数値が自分のPCで再現するとは限りません。ローカルランタイムの選び方は姉妹サイトのTextGenとLM Studio/Ollamaの違いを解説した記事も参考になります。

ブラウザ自動化とデスクトップ全体操作の難度差

操作ロジック側のフレームワークも揃いつつあります。ブラウザ操作にはbrowser-useという確立されたフレームワークがあり、Reddit上でも「端末やブラウザへのアクセスを与えるのは比較的やさしい」と整理されていました。一方、フルデスクトップのナビゲーションは依然として難しいというのが共通認識のようです。ブラウザはDOMやアクセシビリティツリーを利用しやすいのに対し、デスクトップにもWindows UI AutomationやmacOS Accessibility APIはあるものの、アプリごとの実装差や権限、Canvas・Electron・独自描画UIなどの事情で構造化情報が十分に取れない場面が多い。そうした場面では視覚ベースの解析が重要になり、ここが難度の差を生んでいると考えられます。

デスクトップ寄りの足場としては、Simular AIのAgent-S（Agent S2）が候補に挙がります。人間のようにコンピュータを操作するオープンなエージェントフレームワークで、公表値ではAgent S2がOSWorldの50ステップ評価で34.5%（OpenAIのCUA/Operatorの32.6%を上回る）、AndroidWorldで54.3%を報告しています。数字だけ見ると「まだ半分前後」ですが、フルデスクトップ操作という難題の現在地としては着実な水準。Redditの実装報告でも「Qwenのローカルモデルでブラウザ操作・コンピュータ操作を自作したらよく動いた。ただし、その上に独自の制御ロジックを組む必要がある」とされていました。素のモデルをそのまま使うのではなく、公開された部品や参考実装を土台に、前処理とスキャフォールド（足場）を自分の用途へ統合・調整していく段階、というのが正直な温度感だと筆者は見ています。

ただし、Agent S2論文の代表スコアは、Claude 3.7 Sonnetを中核に、視覚グラウンディングのUI-TARS-72B-DPO、テキストグラウンディングのTesseract OCR、構造グラウンディングのUNOなどを組み合わせた評価構成によるものです。Agent S2の設計思想やコードをローカル構成へ取り入れることと、QwenなどのローカルVLMだけで論文の34.5%を再現できることは別の話になります。

クラウドAIのcomputer-useと何が違うか

ローカルで足場を組む手間を考えると、「クラウドのcomputer-useと何が違うのか」が気になるところ。比較の材料として、Simon Willison氏が報告したクラウド側コーディングエージェントの挙動が分かりやすい。氏のブログによると、横スクロールバーの不具合をスクリーンショットと簡単な指示だけで調べさせたところ、エージェントはブラウザ操作の明示的な命令がないままFirefoxとSafariを自動で開いて確認し、不具合を再現するための独自HTMLを作り、Pythonスクリプトで画面キャプチャを取得し、テンプレートを直接編集してダイアログをtrigger させた、という流れだったとされます。

指示を超えて動くクラウドAIの自律性

ここで見えるのは、クラウド側のエージェントが「ツールを自分で組み合わせて目標に到達する」能動性を持っている点です。これはクラウド・プロプライエタリのコーディングエージェントの事例であって、ローカルVLMによるデスクトップ自動化の代表例ではありません。カテゴリが違う話として切り分けておく必要があります。とはいえ対比の軸としては有用で、違いは「モデルの賢さ」だけにあるのではない、と整理できる。ツール統合の作り込み、与えられた自由度、前提となる実行環境——これらがクラウド側では最初から手厚く用意されています。

ローカルは「足場」を自分で組む段階

対してローカルVLM自動化は、検出・OCR・ラベル付け・操作ロジックといった足場を、運用者が自分で組み上げるところから始まります。OmniParserのような前処理を挟み、Agent-Sのようなフレームワークを土台に、Qwenのようなローカルモデルを載せる。クラウドが「最初から組み上がった一式」だとすれば、ローカルは「部品を選んで自分で組む自作PC」に近い、と捉えると分かりやすいかもしれません。手間はかかりますが、そのぶん中身を完全に把握でき、構成を自分の用途に合わせて削れる自由がある。

それでも、ローカルで動かす理由

足場を自前で組む負担を背負ってでもローカルで動かす動機は何か。最大の理由は、画面情報という機微なデータを外に出さずに自動化できる点にあると筆者は考えます。デスクトップ操作の自動化は、その性質上、画面に映るあらゆるもの——メール、社内ツール、認証画面、作業中のファイル——をモデルに見せることになる。これをクラウドに送り続けるのは、用途によっては受け入れがたい。ローカルで完結させれば、外部の推論APIへ画面を送らない構成にできます。

ただし「ローカルだから一切外に出ない」と無条件に言い切るのは正確ではありません。モデルがWeb検索機能や外部API連携を持つ場合、その経路でデータが外に出る可能性は残る。外部の推論サーバーへ画像を送らない構成にしたうえで、Web検索・外部API・テレメトリ（ログ送信）・モデル更新の取得といった外部通信を、必要に応じて無効化・管理することが前提になります。そこを押さえたうえでなら、画面情報を自分の管理下に置いたまま自動操作を組める。これは前処理でVRAMとprefillを節約する話とも地続きです。ローカルで完結させるには限られた資源で回す必要があり、だからこそ視覚トークンを構造化前処理で削る設計が効いてくる。

ご自身がデスクトップ自動化を組むとしたら、スクショをそのまま渡す手軽さを取りますか。それとも前処理を一段挟んで、視覚トークンとprefillの予算を確保しにいきますか。扱う画面の機微さと、手元のVRAMの余裕しだいで、答えは変わってくるはずです。

まとめ

ローカルVLMでデスクトップを自動操作するとき、最初に当たる壁はモデルの賢さではなく「画面の渡し方」でした。スクショをそのまま渡す構成では、小アイコンが縮小・圧縮で見失われやすく、視覚トークンが入力を支配してprefillが詰まりやすい。ここを突破するのが、YOLOv8系の検出とOCR・キャプションで先に画面を構造化し、ラベル付き要素を後段のLLM／プランナーに渡すOmniParser型の前処理です。まず確認してほしいのは、自分のパイプラインが画面を丸ごと渡していないか。次に試すべきは、前処理を一段挟んで視覚トークンを構造化データに置き換えること。Reddit上では5〜10倍ほど削減できたという未検証報告もありますが、実際の削減幅は後段にテキストだけを渡すか画像も渡すかなど実装しだいです。そのうえで、Qwen3-VL-30B-A3Bのような30B級ローカルVLMを土台に、Agent-Sのようなフレームワークで足場を組む。前処理で入力を絞り、量子化モデルをローカルVRAMに収め、外部に画面を送らない構成にすれば、手元のGPUでもデスクトップ自動操作は実運用に近づきます。最も効く一手は、やはり「ピクセルを丸投げしない」という設計の切り替えです。

よくある質問

Q. OmniParserのような前処理は必須ですか？

単純で要素の大きい操作だけなら、スクショ直渡しでも動きます。ただし密集したUIや小さなアイコンを扱う、あるいはローカルのVRAM・prefill予算が厳しい場合は、こうした構造化前処理が有力な選択肢になります。Reddit上では視覚トークンを5〜10倍ほど削れたという未検証報告もあり（削減幅は実装しだい）、小アイコンの取りこぼしも減らせるため、本番UIを相手にするなら導入する価値が高い。

Q. ローカルでQwenのVLMを動かすにはどのくらいのVRAMが要りますか？

用途と量子化しだいですが、30B級MoEのQwen3-VL-30B-A3Bが候補の一つです。VRAMの目安として、当サイトの検証環境では同規模の30B級MoE（qwen3.5:35b-a3b、画像対応モデルをテキスト入力で実測）がRTX 5080（VRAM 16GB）単体でGPUメモリ使用量15.39GiBを示しました。ただしこれはテキスト入力時の値で、画像を入力すると視覚エンコーダや画像由来の視覚トークンが加わり、所要VRAMはさらに大きくなりがちです。Qwen3-VL-30B-A3B自体が16GBに必ず収まるとは限らず、量子化の強さや扱う解像度しだいで上振れします。実際の所要量は使う量子化版で確認するのが前提で、収まらなければ2枚目のGPUにオフロードする構成が現実的です。

Q. ブラウザだけでなくデスクトップ全体も操作できますか？

技術的には可能ですが、難度はブラウザより高いのが現状です。ブラウザはDOMやアクセシビリティツリーを使いやすいのに対し、デスクトップはWindows UI AutomationやmacOS Accessibility APIといった仕組みがあってもアプリ差や独自描画UIで構造化情報を得にくく、視覚ベースの解析に頼る場面が多いため。Agent S2はデスクトップ環境のOSWorld評価で34.5%を報告しており、着実に進んではいるものの、前処理と独自の制御ロジックを組み合わせる足場づくりが前提になると考えられます。

Q. 画面のデータは外部に送られますか？

外部の推論APIへ送らない構成にできます。ローカルでモデルを動かし、外部連携を切れば、画面情報を手元に留めたまま自動化できる。ただし、モデルがWeb検索や外部API機能を持つ場合はその経路でデータが出る可能性が残るため、必要に応じて該当機能を無効化することが条件になります。

Q. 視覚トークンを減らす方法は前処理だけですか？

視覚トークン数を直接減らす主な方法は、操作対象の領域だけをクロップする、入力解像度を必要十分まで下げる、画像トークンの間引き機能を使う、または画面を構造化テキストへ置き換えることです。量子化は視覚トークン数を減らす手段ではありません。ただし、モデル重みのVRAM使用量を抑え、KVキャッシュや画像入力に割ける余裕を増やす補完策になります。入力側の構造化と、モデル側の量子化は別系統の対策として併用できます。