目次
Googleは2026年10月30日、Gemini のComputer Useツールを一般提供しました。ブラウザーだけでなくモバイルとデスクトップの画面をスクリーンショットから読み取り、クリック、入力、スクロールなどの操作候補を返す機能です。Interactions APIと従来のGenerateContent APIの両方で利用できます。
一般提供で変わるのは、プレビュー専用モデルを単独で呼ぶ構成から、Gemini 4やGemini 3.xの対応モデルへ組み込まれたツールとして選べる点です。ただし、画面操作そのものをGoogle側が実行するサービスではありません。実行環境、スクリーンショット取得、座標変換、操作実行、停止判定はアプリ側で実装します。本稿は公式資料を基に、APIの選び方、最小ループ、モデル選択、費用と評価項目を整理するもので、実環境での成功率を測定した結果ではありません。
スポンサーリンク
Computer Useは画面操作を返すクライアント実行型ツール
Gemini APIには、Google SearchやCode Executionのようにサーバー側で処理を完結するツールがあります。Computer Useはこれらと異なり、モデルが操作を提案し、利用者のアプリが実行するクライアント実行型です。公式ドキュメントが示す一巡は、現在画面と依頼を送る、モデルからfunction_callを受け取る、アプリが操作する、新しい画面をfunction_resultとして返す、という四段階です。
モデルが返す座標は0〜999の正規化値です。実行側は現在の画面幅・高さへ換算し、Playwrightなどでクリックや入力を行います。操作後はURL、成否、最新スクリーンショットを同じ呼び出しIDに対応する結果として返します。最終テキストが返る、定めた最大手数へ達する、回復不能なエラーになる、利用者へ引き継ぐ、のいずれかでループを止めます。
この責務分担を最初に理解しておかないと、API呼び出しだけでブラウザー自動化が完成すると誤解しやすくなります。画面サイズ、初期URL、ログイン状態、ページ読み込み待ち、ポップアップ処理を再現できる実行環境が必要です。公式例は1440×900のChromiumをPlaywrightで動かしますが、この値が全用途の推奨サイズという意味ではありません。対象サービスの画面崩れや切り替えを避けられるサイズを固定して評価します。
新規実装はInteractions APIから始める
Computer UseはInteractions APIとGenerateContent APIの両方で一般提供されました。GoogleはInteractions APIを新規プロジェクト向けの標準として推奨し、GenerateContent APIをレガシーと位置付けつつ、引き続きサポートしています。既存システムを直ちに移行する必要はありませんが、新規実装で両者を同列に比較する必要もありません。
| 選択肢 | 向く状況 | 実装上の違い |
|---|---|---|
| Interactions API | 新規の画面操作エージェント、複数ターンの観測と操作を追いたい場合 | Interaction内の実行ステップを読み、previous_interaction_idで前回状態をつなげられる |
| GenerateContent API | 既存のGemini統合へComputer Useを追加し、移行範囲を抑えたい場合 | 既存のコンテンツと関数呼び出しの履歴をアプリ側で組み立てて返す |
Interactions APIは会話状態をサーバー側へ保存し、previous_interaction_idで次の操作へつなげられます。保存を使いたくない場合はstore=falseのステートレス動作も選べます。画面操作ではスクリーンショットが各ターンに入り、履歴が長くなりやすいため、状態管理とデータ保持を分けて決めます。既存のGenerateContent実装は、評価ケースを固定したまま移行し、操作回数、完了率、遅延、トークン量が変わらないかを比較してください。
スポンサーリンク
Interactions APIで最初の一手を要求する
はgoogle-genai 2.7.0以降を使います。次の例はブラウザー環境を指定し、最初の操作候補を要求する最小構成です。設定、Playwrightの起動、スクリーンショット取得、応答の実行部分は省略しています。
from google import genai
client = genai.Client()
interaction = client.interactions.create(
model="gemini-3.8-flash",
input=[
{"type": "text", "text": "商品検索画面で条件を入力し、結果を一覧にする"},
{"type": "image", "data": screenshot_base64,
"mime_type": "image/png"},
],
tools=[{
"type": "computer_use",
"environment": "browser"
}],
)
応答のstepsからfunction_callを取り出し、名前と引数を許可した操作へ対応付けます。ブラウザーではclick、type、scroll、navigate、go_backなどが定義されています。未知の関数名や不足した引数を黙って実行せず、エラー結果として次のターンへ返すか停止します。操作後は最新スクリーンショットと現在URLを含むfunction_resultを作り、前回のInteraction IDへ続けます。
next_interaction = client.interactions.create(
model="gemini-3.8-flash",
previous_interaction_id=interaction.id,
input=function_results,
tools=[{
"type": "computer_use",
"environment": "browser"
}],
)
本番コードでは一回の呼び出しだけでなく、最大操作数、ターンごとの期限、ページ遷移待ち、同じ操作の連続回数を設定します。例えば同じ座標を三回続けてクリックした、URLと画面が変わらない状態が続いた、といった条件を記録すると、モデルの誤りとページ側の読み込み不良を切り分けやすくなります。
環境とモデルは用途別に固定して比較する
環境はbrowser、mobile、desktopから選びます。ブラウザー環境にはURL移動や履歴操作、モバイルにはアプリ一覧や長押し、デスクトップにはダブルクリックや右クリックなど、異なる定義済み操作があります。実行環境と合わない種類を指定すると、モデルが返せる操作とクライアントの実装がずれます。単なるラベルではなく、利用可能な操作集合を決める設定として扱います。
2026年11月2日に公式資料で確認できる対応モデルは、複雑な推論向けのgemini-4-argon、GoogleがComputer Useの推奨としているgemini-3.8-flash、低遅延・低費用を重視するgemini-3.5-flash-lite、プレビューのgemini-3-flash-previewです。旧gemini-2.5-computer-use-preview-10-2025は2026年7月28日に停止済みです。プレビュー用の旧モデル名を設定へ残したまま、一般提供へ移行したと判断しないでください。
モデル比較では、同じ業務を各モデルで十数回ずつ実行し、最終完了だけでなく一手ごとの精度を見ます。定型フォーム入力はFlash-Lite、レイアウトが変わる複数画面の操作は3.8 Flash、長い判断を伴う作業はArgonという仮説を置けますが、公式説明だけで自社画面の優劣は確定しません。モデル名を決め打ちする前に、成功率と一件当たりの総ターン数を比較します。
スポンサーリンク
費用は一回のAPI単価ではなく操作ループ全体で見る
Computer Useは無料枠では利用できず、有料枠で選択モデルの通常トークン料金が適用されます。ツール自体の一律追加料金ではありません。一方、画面操作はスクリーンショットと結果を何度も送り、モデルから操作と推論を受け取るため、同じ最終結果でも手数によって総トークンと待ち時間が変わります。
費用評価では、リクエスト数だけでなく、入力・出力トークン、操作回数、スクリーンショット数、再試行数、完了までの秒数を一件単位で記録します。失敗した実行も分母から外しません。十回中八回成功し、成功時平均が12手でも、失敗二回が最大手数まで走れば、業務一件当たりの費用は成功時平均より高くなります。固定ので済む作業は従来の自動化と比較し、画面理解が必要な範囲だけComputer Useへ任せる方が、費用と再現性を管理しやすくなります。
本番前は完了率より失敗の位置を記録する
評価セットは、正常系だけでなく、読み込み中表示、同名ボタン、画面外の項目、入力エラー、モーダル、一覧のページ送りを含めます。各ターンについて、受け取った画面、intent、提案された操作、実行結果、次画面を保存します。intentは操作理由を追う手掛かりになりますが、正しさの保証ではありません。説明が自然でもクリック先が誤っていれば失敗として扱います。
指標はタスク完了率、初回完了率、平均・上位パーセンタイルの操作数、平均・上位パーセンタイルの時間、人への引き継ぎ率、同一操作の反復率に分けます。失敗原因も、画面認識、座標変換、クライアント実装、ページ待ち、認証切れ、終了判定へ分類します。最終回答だけを採点すると、APIの判断ミスと実行基盤の不具合を同じ「失敗」にまとめてしまいます。
継続評価の作り方は、関連記事「Google AQuAで本番AIエージェントを継続評価する方法」で整理しています。とアプリ側実行の責務を分ける基礎は「構造化出力とツール呼び出しはどう違う？」も参考になります。
導入時に決める停止条件と人への引き継ぎ
Computer Useには通常実行、確認要求、ブロックの判断が返る場合があります。アプリは確認要求を実行せず、利用者へ予定操作を示します。定義済み操作をexcluded_predefined_functionsで外し、独自のyield_to_user関数へ置き換える構成も公式例にあります。認証、CAPTCHA、曖昧な選択肢など、自動化できない場所で再試行を止める運用設計です。
Googleは重要な判断、機密データ、取り消せない結果を伴う作業での厳重な監督を勧めています。一般提供は、あらゆる画面操作を無人で任せられるという意味ではありません。最初は読み取り、検索、テストなど結果を確認しやすい用途から始め、送信、購入、削除、外部公開の直前で止めます。予期しない画面や未実装の操作を受け取った場合も、推測で続行せず人へ戻します。
一般提供後の導入チェックリスト
- 新規開発はInteractions API、既存統合はGenerateContent継続との比較理由を記録する
- ブラウザー、モバイル、デスクトップの環境指定と実行ハンドラーを一致させる
- 旧Computer Useプレビューモデルから対応モデルへ移行する
- 画面サイズ、初期状態、待ち時間、最大操作数、終了条件を固定する
- 一件当たりのトークン、操作数、時間、失敗実行を含めて費用を測る
- 画面認識とクライアント実装の失敗をターン単位で分ける
- 確認要求、未知の操作、反復、認証切れで人へ引き継ぐ
Computer Useの一般提供により、専用プレビューを試す段階から、通常のGeminiモデルとAPI設計へ組み込む段階へ進みました。採用判断の中心は「画面を操作できるか」だけではありません。どのAPIで履歴を管理し、どのモデルが必要な精度と速度を満たし、何手で完了し、失敗時にどこで止まるかを測ることです。固定スクリプトで安定する処理は残し、画面理解が価値を持つ部分から小さく導入してください。
スポンサーリンク
