はじめに
Gemini API の Computer Use は、モデルにスクリーンショットを渡し、画面上で次に行うべき UI 操作を返してもらうための機能です。
ざっくり言うと、従来の「テキストを返すAI」より一歩進んで、ブラウザやデスクトップの画面を見ながら、クリック・入力・スクロールなどの操作候補を返せるようにするものです。
この記事では、開発者・情シス向けに 「Computer Use Preview で何ができるのか」「検証時にどこを見るべきか」 を概要理解目的で整理します。
なお、2026-07-05時点で公式ドキュメントは 2026-06-25 更新版になっており、Computer Use の推奨モデルは gemini-3.5-flash です。一方、gemini-2.5-computer-use-preview-10-2025 は Gemini 2.5 Legacy Preview として掲載されています。
また、現在の公式ドキュメントでは Interactions API を前提にした例が中心です。従来の generateContent API 版もサポートされていますが、新しく試す場合は Interactions API 側の記述を確認するとよさそうです。
本記事では、テーマに合わせて 2.5 Preview の見方も含めつつ、現在のドキュメントでの位置づけも補足します。
まず何ができるのか
Computer Use でできることは、単に「ブラウザを自動操作する」ではなく、もう少し分解して理解すると見通しがよくなります。
モデルに渡すものは、主にユーザー指示、現在の画面スクリーンショット、直近の操作履歴です。モデルは画面を解釈し、次の操作を function_call のような形式で返します。
たとえば、以下のような操作候補が返ってくるイメージです。
- 指定座標をクリックする
- テキストを入力する
- ページをスクロールする
- 戻る、進む、URLへ移動する
- キー操作を行う
また、安全上必要な場合は、safety_decision によって人間確認が必要な操作として返されることがあります。
大事なのは、モデルが実際にブラウザやOSを直接操作するわけではない という点です。モデルは「次にこう操作するとよさそう」という候補を返し、その操作を実行するのは自分たちのクライアント側コードです。
そのため、Playwright などの自動操作ツール、スクリーンショット取得、座標変換、失敗時のリトライ、停止条件などをアプリケーション側で実装する必要があります。
代表的なユースケース
公式ドキュメントでは、Computer Use によって以下のようなエージェントを作れると説明されています。
- Webサイト上の繰り返し入力やフォーム入力の自動化
- Webアプリケーションやユーザーフローの自動テスト
- 複数サイトを横断した調査、商品情報や価格、レビューの収集
開発者目線では、E2Eテストや社内業務ツールの操作自動化がまず試しやすい領域だと思います。
情シス目線では、SaaS管理画面の定型操作、棚卸し、設定確認、証跡取得の補助などが候補になりそうです。ただし、後述するように、権限・秘密情報・取り消し不能な操作が絡むところは慎重に扱う必要があります。
実装イメージは「画面を見る、操作する、また画面を見る」のループ
Computer Use は、1回APIを呼んで終わりというより、スクリーンショット駆動のループとして考えると理解しやすいです。
流れはおおむね次のようになります。
- ユーザー指示と現在画面をAPIに送る
- モデルが画面を読み、次の操作を返す
- クライアント側でクリックや入力などを実行する
- 操作後の画面を再取得する
- タスク完了または停止まで繰り返す
疑似コードにすると、かなり単純化すれば次のような形です。
while not done:
screenshot = capture_screen()
response = call_gemini_computer_use(
instruction=user_instruction,
screenshot=screenshot,
history=action_history,
)
action = parse_next_action(response)
if action.requires_confirmation:
ask_user_confirmation(action)
result = execute_action(action)
action_history.append((action, result))
done = judge_task_completed(response, result)
実際には、座標の正規化、画面サイズ差分、クリック失敗、ページ遷移待ち、ログイン、CAPTCHA、モーダル、確認ダイアログなどが入ってきます。ここが検証の肝です。
Gemini 2.5 Preview と現在の推奨モデルの見え方
公式ドキュメントでは、Computer Use のモデルは次のように整理されています。
| モデル | 位置づけ | ざっくり特徴 |
|---|---|---|
gemini-3.5-flash |
推奨 | ブラウザ、モバイル、デスクトップ環境をサポート。操作に intent が付き、設定可能な安全ポリシーや、オプトインで有効化できるプロンプトインジェクション検知も扱える |
gemini-3-flash-preview |
Preview | Computer Use 対応のPreviewモデル |
gemini-2.5-computer-use-preview-10-2025 |
Legacy Preview | ブラウザベースの Computer Use 向けに最適化された旧Previewモデル |
2.5 Preview の操作は、たとえば click_at、type_text_at、scroll_document、scroll_at、navigate、go_back、go_forward、key_combination、drag_and_drop などのレガシー操作名で表現されます。
一方、3.5 Flash では click、type、scroll、hotkey などの操作に加えて、なぜその操作を選んだかを示す intent が含まれる形になっています。
つまり、これから新しく検証するなら 3.5 Flash を軸に見るのが自然です。ただし、2.5 Preview の資料やサンプルを読む場合は、「操作名や安全機能の形が現在の推奨モデルと少し違う」と意識しておくと混乱しにくいです。
何がすごいというより、何を検証すべきか
Computer Use 系のエージェントは、デモを見ると便利そうに見えます。ただ、実務導入の検討では「できた瞬間」よりも「安定して止められるか」を見たほうがよさそうです。
能力・品質の観点
まずは、対象業務の代表タスクを小さく切り出して、次のような観点を見ます。
- 画面レイアウトが少し変わっても追随できるか
- ログイン後の業務画面で迷わないか
- 誤クリックや入力ミスから復旧できるか
- タスク完了判定が安定しているか
- 何回のモデル呼び出しで完了するか
- レイテンシとコストが許容範囲か
特に座標ベースの操作では、画面サイズやズーム率、スクロール位置の影響を受けます。モデルの賢さだけでなく、実行環境側の設計がかなり効きます。
安全・運用の観点
情シスやセキュリティ担当が見るべきポイントは、むしろこちらです。
- サンドボックス、VM、コンテナなどで実行環境を分離する
- 本番アカウントではなく検証用アカウントから始める
- 高リスク操作は人間確認を必須にする
- 秘密情報や個人情報が画面に出る前提でログ設計する
- プロンプトインジェクションを想定する
- 監査ログとして、画面、操作、モデル応答、ユーザー確認を残す
- エージェントに与える権限を最小化する
公式ドキュメントでも、Computer Use は Preview 機能であり、重要なタスクでは監督を強めること、重大な判断や機微情報、取り返しのつかない操作には注意することが示されています。
また、gemini-3.5-flash では安全ポリシーや safety_decision によって、人間確認が必要な操作を扱えるようになっています。ただし、最終的に確認・停止・ログ記録をどう実装するかはクライアント側の責任として設計する必要があります。
向いていそうな検証テーマ
最初の検証では、いきなり「何でもできるAI社員」を作るより、次のような小さなテーマがよさそうです。
1. 社内Webアプリの定型入力
入力項目が決まっていて、失敗してもリカバリーしやすい業務です。たとえば検証用環境の申請フォーム、チケット登録、テストデータ投入などです。
見るべきポイントは、入力ミス、ラベル認識、確認画面で止まれるか、同じUIで成功率が安定するかです。
2. WebアプリのE2Eテスト補助
Playwright などのコードベースのE2Eテストを完全に置き換えるというより、探索的テストや画面変更後の軽い確認に使うイメージです。
見るべきポイントは、テスト観点の網羅性、再現性、失敗時ログ、CIに入れられるかです。
3. SaaS管理画面の読み取り・棚卸し
設定値を確認する、一覧を巡回する、スクリーンショットを保存する、といった読み取り中心のタスクです。
見るべきポイントは、誤操作しない権限設計、読み取り専用アカウント、ページ遷移の安定性、証跡の残し方です。
逆に慎重にしたい領域
以下は、PoC段階では避けるか、人間確認をかなり強く入れたほうがよい領域です。
- 送金、購入、契約、解約などの取り消し困難な操作
- メール送信、チャット投稿、外部共有
- 個人情報や機密情報を大量に扱う画面
- 本番データの削除、更新、権限変更
- CAPTCHAや利用規約同意など、人間の判断が前提の操作
Computer Use は「画面操作できる」ことが価値ですが、同時に「人間なら慎重に扱う画面にも到達できる」ということでもあります。便利さより先に、止め方と権限境界を決めるのがよさそうです。
検証時のチェックリスト
最後に、PoCの観点をチェックリストにまとめます。
- 対象タスクは小さく、成功条件が明確か
- 検証用アカウントと検証用データで実行しているか
- 操作前後のスクリーンショットを保存しているか
- モデル応答と実行結果をログに残しているか
- 高リスク操作で必ず人間確認が入るか
- 操作失敗時に停止できるか
- 連続実行時の上限回数やタイムアウトがあるか
- 入力画面に秘密情報が出る場合のログマスキングを考えているか
- 画面レイアウト変更時の失敗を検知できるか
- コストとレイテンシを代表タスク単位で測っているか
まとめ
Gemini API Computer Use Preview は、ブラウザやデスクトップの画面を見ながら UI 操作候補を返すための機能です。
できることを一言で言えば、スクリーンショットを入力にした操作型エージェントの土台 です。ただし、実際の操作実行、座標変換、失敗処理、安全確認、監査ログはクライアント側の責任になります。
開発者は、Playwright などの実行基盤と組み合わせて、どこまで安定したループを作れるかを見るのがよさそうです。情シスは、サンドボックス、権限、ログ、人間確認、プロンプトインジェクション対策を検証の中心に置くと判断しやすくなります。
現時点では Computer Use 機能としての Preview 性や、2.5系の Legacy Preview の位置づけも含むため、まずは影響の小さい業務で小さく試し、「成功率」だけでなく「止めやすさ」まで含めて評価するのが現実的だと思います。