Googleは2026年6月24日、Gemini 3.5 FlashでComputer Useツールのパブリックプレビューを開始した。

この機能はブラウザ、モバイル、デスクトップ環境を対象とし、画面を認識してクリック、入力、スクロールなどの操作を計画する。簡略化された意図ベースのアクション、設定可能な安全ポリシー、高度なプロンプトインジェクション検知も含まれる。

何が可能になるか

Computer Useは、APIだけでは操作できない画面をエージェントが扱うための機能である。

  • Web管理画面への入力
  • ブラウザ上の情報収集
  • 社内SaaS間の転記
  • UIの回帰テスト
  • モバイルアプリの操作
  • デスクトップアプリの定型手順
  • 予約や申請の補助
  • API未提供のレガシーシステム操作

ただし、画面操作はAPI統合より不確実である。レイアウト変更、ポップアップ、遅延、権限不足、誤認識により、同じ手順でも結果が変わる。

Computer Use特有のリスク

プロンプトインジェクション

エージェントが閲覧するWebページ、メール、文書、チャットには、操作方針を変更させる命令が埋め込まれる可能性がある。画面上の文章はデータであり、システム指示ではないと区別しなければならない。

検知機能があっても、すべての攻撃を防げると仮定してはいけない。重要操作は技術的に制限し、人間承認を組み合わせる。

誤操作の連鎖

誤ったクリックが次の画面、入力、送信へ連鎖する。最終結果だけを確認するのではなく、各操作の前提と対象を検証する必要がある。

過剰な権限

人間の管理者アカウントをそのままエージェントへ渡すと、閲覧、更新、削除、送信、権限変更を一度に許すことになる。専用アカウントと最小権限が必要である。

監査困難

API呼び出しと異なり、画面操作は「何を見て、なぜそのボタンを押したか」が追跡しにくい。スクリーンショット、アクション、URL、時刻、結果を一連の監査ログとして保存する。

UI変更

ボタン名、配置、ダイアログが変わると、正常だったフローが突然失敗する。固定座標だけに依存せず、意味、状態、確認画面を検証する。

操作をリスク別に分類する

リスク操作例推奨制御
低閲覧、検索、下書き作成自動実行、詳細ログ
中入力、設定変更、社内更新条件付き実行、事後確認
高外部送信、購入、公開、削除実行直前に人間承認
禁止権限付与、秘密情報抽出、安全制御解除ツール側で技術的に拒否

「モデルに禁止と伝える」だけではなく、ブラウザ、OS、アプリケーション、ネットワーク側で実行不能にする。

導入時の設計

1. 隔離された実行環境を使う

個人端末や管理者セッションではなく、専用ブラウザ、仮想環境、コンテナ、テスト端末を使う。セッション終了時に状態を破棄できる構成が望ましい。

2. 専用アカウントを発行する

業務単位の最小権限アカウントを作る。個人アカウント、共有管理者、長期セッションCookieの流用を避ける。

3. 許可リストを設ける

アクセス可能なドメイン、アプリ、画面、操作、ファイル種別を限定する。外部リンク、短縮URL、未知のダウンロード、ポップアップを既定で拒否する。

4. 高リスク操作を承認制にする

送信、削除、購入、公開、契約、権限変更、個人情報の持ち出しは、人間が対象と差分を確認してから実行する。

5. 監査ログを保存する

最低限、次を記録する。

  • セッションIDと利用者
  • 使用モデルと設定
  • 表示URLとアプリ
  • 操作前後のスクリーンショット
  • モデルが提案したアクション
  • 実際に実行したアクション
  • 人間承認者
  • エラー、再試行、停止理由
  • 外部送信したデータ

6. 緊急停止を独立させる

モデル自身に停止を依頼するだけでは不十分である。セッション切断、資格情報失効、ネットワーク遮断、ワーカー停止を外部から実行できるようにする。

評価シナリオ

通常手順だけでなく、次の異常系を含める。

  • ボタン位置や名称が変わる
  • ローディングが長い
  • セッションが切れる
  • CAPTCHAやMFAが表示される
  • 同名の対象が複数ある
  • ページ内に攻撃命令が書かれている
  • ダウンロードファイルに攻撃命令が含まれる
  • 誤った入力後に確認画面が出る
  • 外部ドメインへ遷移する
  • 高リスク操作を要求される
  • 人間が途中で中止する

成功指標

  • タスク完了率
  • 人間修正率
  • 誤操作率
  • 高リスク操作の無承認実行件数
  • プロンプトインジェクション検知率
  • 1タスク当たり操作回数
  • 平均・P95完了時間
  • 再試行率
  • UI変更後の失敗率
  • 監査ログ欠落率

編集部分析

Computer Useは、APIがない業務を自動化できる一方、画面上の情報と操作権限を同じエージェントへ与える。これは、閲覧した悪意ある内容が、そのまま実行判断へ影響する構造を生む。

安全性をモデル性能だけに依存せず、最小権限、隔離、許可リスト、承認、監査、緊急停止を重ねる必要がある。プレビュー段階では、まず読み取り中心の低リスク業務から始め、失敗時に容易に復旧できる範囲へ限定するのが妥当である。

実務チェックリスト

  • [ ] 隔離された専用環境を用意した
  • [ ] 最小権限の専用アカウントを発行した
  • [ ] 許可ドメインと禁止操作を技術的に設定した
  • [ ] 高リスク操作を人間承認にした
  • [ ] プロンプトインジェクションを試験した
  • [ ] 操作前後の監査ログを保存した
  • [ ] 緊急停止と資格情報失効を用意した
  • [ ] UI変更を含む異常系を評価した
  • [ ] 低リスク業務から段階導入する

一次情報