Gemini 3.5 Flash の Computer Use は、ブラウザだけでなく mobile と desktop も対象にした UI 操作エージェントを組める新機能です。2026年6月24日の Google 公式発表では、Gemini API と Gemini Enterprise Agent Platform から使い始められると案内されました。単なる『画面を見てクリックする』機能ではなく、意図付きアクション、安全ポリシー、プロンプトインジェクション検知まで含めて企業導入しやすくした点が今回の変化です。
Gemini 3.5 Flash の Computer Use で何が変わる？
Google AI for Developers のドキュメントでは、Computer Use はスクリーンショットを見てクリックや入力などの UI 操作を返す仕組みと説明されています。Gemini 3.5 Flash では browser・mobile・desktop の3環境を標準で扱え、各アクションに intent を持たせられるため、エージェントが『なぜその操作をするのか』をログとして追いやすくなりました。さらに 2026年6月24日のリリースノートでは public preview として提供が始まり、簡略化されたアクション、設定可能な安全ポリシー、高度な prompt injection detection が追加されています。
どんな業務に向く？ browser / mobile / desktop の使い分け
向いているのは、手順が決まっていて画面操作の再現性が高い業務です。たとえば browser ならフォーム入力、検証環境でのE2Eテスト、競合サイトの情報収集。mobile なら営業アプリや社内承認アプリの導線確認。desktop なら社内ツールの定型オペレーション確認や、マルチウィンドウ前提の事務処理補助です。逆に、重要な送金、顧客データの本番更新、取り消し不能な操作を完全自動にするのはまだ早いです。Google も preview 機能として、重要タスクや機微情報、重大な誤りを修正できない操作では厳重な監督を推奨しています。
実務での判断軸は『Structured API で足りるか、それとも本当に UI を触る必要があるか』です。API があるSaaSなら、まずは API 連携や function calling を優先し、UI 操作は API がない部分、権限上 UI でしか触れない業務、既存システムがレガシーである領域に限定したほうが安全です。既存の Computer Use 記事で論点になりやすかったコストや不安定さに対しても、今回は環境対応と安全制御がセットで前進した、と整理すると分かりやすいです。
導入前に確認したい 4 つのガバナンス項目
1つ目は実行環境の分離です。Google の実装ガイドでも、ホストから隔離した sandboxed VM や container 上で動かすことが前提になっています。2つ目は承認ポイントの定義で、機密操作や不可逆操作では user confirmation を必須にするべきです。3つ目は prompt injection 対策で、スクリーンショット走査による検知を有効化し、怪しい指示が見つかったら自動停止させる設計が必要です。4つ目は監査ログで、intent・操作対象画面・実行結果を残し、失敗時に人が追跡できる状態にしておくことが重要です。
特に enterprise 観点では、Computer Use を『便利な自動化』ではなく『承認付きオペレーション層』として扱うほうが失敗しません。Google の公式発表でも、明示確認を要求する仕組みと、間接的な prompt injection を検知したら停止する仕組みが optional safeguards として示されています。つまり、精度向上だけでなく『止める設計』が前提です。PoC の時点で、どこまでを自動、どこからを人手確認にするかを決めておく必要があります。
最小実装の流れ: PoC をどう始めるか
最初の PoC は browser から始めるのが無難です。Google のサンプルでは Interactions API で model に gemini-3.5-flash を指定し、tools に computer_use と environment=browser を渡します。クライアント側では Playwright などでクリック・入力・スクリーンショット取得を担当し、モデルの function_call を受けて実行し、結果の画面を再び返すループを回します。この設計なら、既存の QA 自動化や業務検証の延長として始めやすく、mobile や desktop に広げる前に監査・再実行・停止条件を固められます。
モデル仕様面では gemini-3.5-flash は 1,048,576 の入力トークン上限と 65,536 の出力トークン上限を持ち、Computer Use は preview 対応です。長い手順や大量コンテキストを持ち込める一方、Live API は非対応なので、まずは同期的な操作ループ前提で設計するのが現実的です。社内導入では『1画面ごとに判断を返すエージェント』として扱い、失敗時のリカバリを人が引き取れるようにしておくと運用しやすくなります。
FAQ: いま記事を読んだ企業担当者が押さえるべき点
Q. すぐ本番導入してよいですか？ A. まだ preview なので、まずは検証環境か限定業務から始めるべきです。Q. browser だけで十分ですか？ A. 多くの企業は browser で価値検証できます。mobile や desktop は社内アプリ依存が強いため、承認フローと監査要件を先に決めた方が安全です。Q. なぜ intent が重要ですか？ A. エージェントの行動理由をログで確認しやすくなり、レビューや是正の負担を下げられるからです。
Computer Use は『人の代わりに全部やる魔法の操作員』ではなく、『画面しか触れられない業務を段階的に自動化する部品』として見ると失敗しにくいです。Gemini 3.5 Flash で注目すべきなのは、環境対応の広さだけではなく、安全制御と理由付けが一緒に前進したことです。PoC の評価軸も、成功率だけでなく、停止判断・承認設計・監査しやすさまで含めて置くべきでしょう。
Gemini や Computer Use を使った業務自動化の設計、承認フロー、検証環境の整備まで整理したい場合は、 お問い合わせはこちら 。HelloCraftAI では、PoC で止まらない運用設計まで支援しています。
