AIエージェントに作業を任せるとき、「どの方法で操作させるか」の選択がコストと安定性を決めます。GUI操作は万能に見えますが、最もコストが高く、最も壊れやすい方法でもあります。
この調査では、自動化レイヤの優先順位を階層として言語化し、推奨する構成比率まで整理しました。
この調査の概要
調査時期 | 2026年6月1日〜（検証中） |
|---|---|
やりたかったこと | 自動化レイヤ（API / MCP / DOM操作 / CLI / GUI）をどの順序で組み合わせるとコストと安定性のバランスが取れるかを整理する |
結論 | API → MCP → DOM操作 → CLI → GUI操作の階層。GUIは最後の手段 |
目標比率 | Browser Use 90% / CLI 5% / Computer Use 5% |
結論：GUIは最後の手段
この調査で確立した優先順位です。
API → MCP → DOM操作 → CLI → GUI操作理由は明確です。GUIは万能に見えますが、UI変更への耐性が低く、トークン消費も大きくなります。そのため、GUIでしかできない処理に限定します。
使い分けの基準も具体的です。
対象 | 方式 |
|---|---|
DOMが存在する操作対象（分析ツール、自動化SaaS、コード管理、チャットのWeb版等） | Browser Use + Playwright + MCP |
DOMが存在しないネイティブアプリ（エディタ、デザインツール、ファイラー、表計算のデスクトップ版等） | Computer Use を許容 |
「DOMがあるか」が分岐点です。あるならDOMを直接扱ったほうが速く、安く、安定します。
「GUI操作回数 ≒ トークン消費量」
この調査で得た最も有用なメンタルモデルです。
Computer Useの高コスト要因は、スクリーンショット取得 → LLM解析 → 次アクション決定というループを毎ステップ繰り返す構造そのものにあります。
そしてもう1つ、理解を助ける事実があります。
GUIエージェントは画面を動画的に見ているのではなく、大量の静止画を反復解析しています。
人間が画面を見る感覚とはまったく違います。1回クリックするたびに、画面全体を読み直しています。操作回数がそのままコストになる理由がここにあります。
対してBrowser Use系は、document.querySelector() や button.click() 相当でHTML構造を直接操作します。高速かつ安定し、低コストです。
GUI操作を減らす3つの工夫
GUIを使わざるを得ない場合の対処です。
- 事前に画面を準備する — 対象のチャンネルやページを開いた状態で渡し、エージェントには操作だけを担当させる
- タスクを分割する — 「確認 / 作成 / 修正」のように1ステップ完結のタスクへ分けてから渡す
- GUI探索を減らす — フォルダを辿らせず、検索機能でファイル名を入力してEnterさせるなど、キーボードショートカットを優先する
3つとも「探させない」ための工夫です。エージェントが画面上を探し回る時間が、そのままコストになります。
アーキテクチャの進化：構造化してから渡す
技術的に注目すべき動向です。
従来の「画面全部を毎回LLMへ送る」運用から、UIを構造化し、小型モデルが実行、必要時のみ大型モデルへエスカレーションする構成への移行が進みつつあります。
これを支える技術が2つあります。
技術 | 役割 |
|---|---|
スクリーンショットのUI要素パーサー | スクリーンショットからボタン・入力欄・アイコンといったUI要素を抽出し構造化する前処理 |
Planner / Executor / Grounding の分離 | 大型モデルが計画、小型モデルがクリック判定を担う構成で、精度向上とコスト削減を両立 |
「見て判断する」を1つのモデルで全部やらせない——役割を分けることで、それぞれに適したサイズのモデルを割り当てられます。
ローカルLLMという選択肢
コストを下げるもう1つの方向です。
GUI理解に強いローカルVLMとして、複数の選択肢が確認されています。GUI理解・テキスト認識・ボタン認識に強いモデルや、高解像度UI認識を重視したGUI専用寄りのモデルなどです。
ただし精度には差があります。
ローカルLLMでもComputer Useは可能ですが、精度はクラウドの大型モデルに届きません。
そのため、ローカル実行95% ＋ 高性能クラウドGUIエージェント5%という構成比率も目安として挙げられています。
難しい判断だけクラウドに投げるという設計です。
GUIとCLIを組み合わせる
実運用に乗せやすい設計として評価されている考え方です。
ファイル整理はスクリプト、変換処理はCLI、必要時のみGUI——役割を切り分ける構成です。
同じ作業でも、手段によってコストと安定性がまったく違います。全部をGUIでやろうとする必要はありません。
用途別の振り分け例
対象 | 方式 |
|---|---|
コード管理サービス | Browser Use |
分析ツール | MCP |
チャット通知 | API |
開発サーバー起動 | CLI |
エディタでの編集 | Computer Use |
同じ「自動化」でも、対象ごとに最適な層が違います。この振り分けを事前にルール化しておくと、都度悩まなくて済みます。
長期タスクへの備え
スケールしたときの課題も整理されています。
- GUI操作中心の構成はUI変更に弱く、長期タスクで失敗率が上がる
- スクリーンショット解析を繰り返すとトークン消費が線形以上に膨らむ
対策として、履歴圧縮・セマンティック要約・GUI構造化を組み合わせ、毎ターンの送信量を抑制する方針が挙げられています。
長く動かすほど、送信量の管理が効いてきます。短いタスクでは問題にならない部分です。
残っている検証課題
- ローカルLLMでのComputer Useの精度が、クラウド大型モデルにどこまで近づくか
- 実際の運用比率（Browser Use 90% / CLI 5% / Computer Use 5%）が手元の業務でも成立するかの実測
よくある質問
なぜGUI操作を最後に置くのですか？
UI変更への耐性が低く、トークン消費も大きいためです。APIやDOM操作で済むなら、そちらのほうが速く、安く、安定します。
Computer Useのコストが高い理由は？
スクリーンショット取得 → LLM解析 → 次アクション決定のループを毎ステップ繰り返す構造にあります。GUIエージェントは動画的に画面を見ているのではなく、大量の静止画を反復解析しています。
GUIを使わざるを得ない場合は？
事前に画面を準備する・タスクを分割する・キーボードショートカットを優先する——この3点でGUI探索を減らせます。
ローカルLLMで代替できますか？
可能ですが、精度はクラウドの大型モデルに届きません。ローカル実行を主体にしつつ、難しい判断だけクラウドに投げる構成が現実的です。
まとめ
- 自動化レイヤの優先順位はAPI → MCP → DOM操作 → CLI → GUI操作。GUIは最後の手段
- 分岐点は「DOMが存在するか」。あるならDOMを直接扱う
- 「GUI操作回数 ≒ トークン消費量」——GUIエージェントは静止画を反復解析している
- GUI使用時は事前に画面を準備・タスク分割・ショートカット優先で探索を減らす
- アーキテクチャはUI構造化 → 小型モデルが実行 → 必要時のみ大型モデルという方向へ進化
- ローカルLLMは可能だが精度はクラウド大型モデルに届かない
- 目安はBrowser Use 90% / CLI 5% / Computer Use 5%
自動化の設計では、何ができるかより「どの層でやるか」が結果を左右します。上位の層で済むことを下位の層でやると、コストも失敗率も上がります。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。